Abstrakt. Manažment vedomostí je komplexná oblasť, ktorá obsahuje viacero prístupov k riešeniu problematiky, či už na báze centralizovaného alebo distribuovaného prístupu. V náväznosti na predloženú problematiku sa táto esej zaoberá objasnením možných prístupov v distribuovaných peer-to-peer sieťach a ich rozšírením o možnosti automatizovania pomocou systémov, postavených na agentoch. Porovnáva vhodnosť jednotlivých spôsobov riešenia postavených na ontológii alebo na agentoch vo vzťahu k distribúcii vedomostí, napr. vzhľadom na nejaký projekt. Rozoberá aj existujúce riešenia, ktoré sú, resp. sa začínajú nasadzovať, nie len v IT prostrediach, ale aj v podnikovej sfére alebo v armáde.
Abstrakt. Proces vývoja softvéru bol dlhú dobu, a v niektorých prípadoch i naďalej ostáva, chaotickou činnosťou. Snaha systematizovať tento proces viedla k vzniku byrokratických metód, ktoré čerpali námety z iných inžinierskych disciplín ako napr. staviteľstvo. Napriek veľkej snahe nenašli tieto metódy uplatnenie, nakoľko sa nedokázali prispôsobiť dynamike neustále sa meniacich požiadaviek. V súčasnosti postupne do softvérového inžinierstva prenikajú tzv. agilné metódy. Iteračný spôsob vývoja softvéru, využitie moderných techník v programovaní ako napr. využívanie návrhových vzorov alebo refaktoring dávajú dobrý predpoklad pre vznik rozumného kompromisu medzi chaosom a prehnanou byrokraciou. Sú tieto metódy ideálnym riešením pre každého? Aké agilné sú v skutočnosti? Táto esej sa snaží vysvetliť príčiny, prečo tradičné metódy neuspeli v praxi, poukazuje na hlavné rozdiely tradičných a agilných metód no taktiež na nedostatky a riziká tejto novej metodológie.
Abstrakt. Technicky vzdelaní ľudia sa vo všeobecnosti nestávajú vrcholovými manažérmi. Donald J. Reifer vo svojom článku Catching the Brass Ring (IEEE Software, May/June 2004) upozornil na túto skutočnosť, pričom si všímal hlavne ľudí ktorí sa venujú sa vývoju softvéru. Poukázal na možné príčiny tohto stavu a taktiež naň navrhol možné riešenie. V tomto článku prezentujem a súčasne reagujem na jeho myšlienky.
Abstrakt. Esej skúma problematiku stresu pracovníkov v oblasti informačných technológií. Zaoberá sa identifikáciou zdrojov stresu a ohrozených skupín ľudí na základe primárneho zdroja eseje. Ďalej objasňuje niektoré psychologické špecifiká profesionálov v IT, ktoré môžu spôsobovať náchylnosť pracovníkov na podliehanie stresu. Časť eseje je venovaná sprievodným javom stresu na pracovisku (dobrovoľné a vynútené nadčasy, strata koncentrácie) a jeho dôsledkom (burnout). Práca čerpá z vedeckých výskumov a postrehov manažérov ľudských zdrojov deliacich sa o svoje skúsenosti.
Abstrakt. Sociologický pohľad na vývoj softvéru má v súčasnosti stúpajúci trend predovšetkým u vedúcich pracovníkov väčších projektov. Kvalitu výsledného produktu ovplyvňuje veľa faktorov, medzi ktoré môžeme určite zaradiť spôsob akým jeho tvorcovia spolu komunikujú, ako sa správajú, ale aj ako sú organizovaní. Dôsledky vyplývajúce z poznania typu softvérového tímu a pochopenia princípov jeho fungovania zo sociologického pohľadu, môžu v širokej miere ovplyvniť celý proces tvorby softvéru. Táto esej sa upriamuje predovšetkým na situácie a javy súvisiace so zaradením nového človeka do tímu konkrétneho typu.
Abstrakt. Do dnešnej doby bolo v softvérových projektoch identifikovaných mnoho rizikových faktorov. No bolo vytvorených iba málo štatistických skúmaní, ktoré by odhadli dôležitosť jednotlivých rizikových faktorov. Jednou z takýchto štúdií je "The One-Minute Risk Assessment Tool", ktorej autormi sú Amrit Tiwana a Mark Keil. V eseji je opísaná dôležitosť šiestich rizikových faktorov, ktoré boli výsledkom štúdie. V eseji načrtneme iné možné interpretácie týchto zistení. Ďalej predstavíme jednoduchý nástroj na odhad rizík softvérového projektu.
Abstrakt. Softvér s otvoreným zdrojovým textom sa stal fenoménom konca deväťdesiatych rokov, úspešné projekty majú už určitý vek, preto je potrebné zaoberať sa aj ich udržiavateľnosťou. Vývoj otvoreného softvéru dokázal, že vie byť veľmi rýchly a efektívny, dokonca rýchlejší ako vývoj uzavretého softvéru, no je potrebné sa zaoberať aj jeho dopadom na udržiavateľnosť. Pozitívny vplyv na ňu má najmä veľký entuziazmus tvorcov, negatívnym vplyvom zase môže byť sloboda, s ktorou môžu ku projektu pristupovať. S ňou súvisia napríklad neodborné zásahy, prípadne plytké opravovanie chýb. Merania však ukázali, že otvorený softvér sa dokáže udržiavateľnosťou vyrovnať uzavretému softvéru, preto je len na odbornosti jeho tvorcov ako sa so spomínanými úskaliami vyrovnajú.
Abstrakt. Nadviazanie úspešnej spolupráce medzi dvomi firmami nie je jednoduché. Ešte zložitejšie je však tento vzťah udržať na vysokej úrovni, tak aby obe strany v tomto pracovnom vzťahu boli spokojné. Ako na to? Recept Vám nikto nepovie, ale niekoľko pravidiel, podľa ktorých keď sa budete správať máte väčšiu šancu svoju spoluprácu naďalej zveľaďovať a vylepšovať. Pri obstarávaní je to ešte dôležitejšie, pretože spolupráca sa nadväzuje na dlhší čas, väčšinou ak sa obom firmám dobre spolupracuje, tak vzťah neukončia po prvom projekte. Ale na to aby sa im dobre spolupracovalo treba trpezlivosť a dodržiavanie niekoľko základných odporúčaní, ktoré som sformuloval a zdôvodnil v eseji.
Abstrakt. Článok analyzuje riziká softvérových projektov ako hlavný faktor vplývajúci na úspech projektu. Posudzuje jednotlivé rizikové faktory podľa veľkosti vplyvu na projekt a podľa miery kontroly nad rizikom. Faktory sú podľa tohto zoskupené do štyroch skupín: zákazník, požiadavky, tvorba a prostredie. Tieto sú následne charakterizované s dôrazom na spôsob odstránenia rizika. Pozornosť je venovaná aj interakciám medzi skupinami faktorov a dopadom vzájomného pôsobenia rizík.
Abstrakt. V dnešnej dobe všetky spoločnosti pri nákupe softvéru, či už generického, alebo softvéru na zákazku, očakávajú jeho vysokú kvalitu. Okrem toho je častou podmienkou nákupu aj začlenenie sankcií voči dodávateľovi, v prípade poruchy alebo výpadku softvéru. Avšak, po výskyte chyby a nutnosti zaplatenia sankcií nastáva nekonečný kolotoč vzájomného obviňovania všetkých zainteresovaných strán. Je takmer nemožné určiť jednoznačného vinníka chyby a dodávateľ, ktorý je povinný zaplatiť straty spôsobené jeho softvérom, sa snaží za každú cenu zvaliť vinu na niekoho iného. Táto esej sa snaží byť akýmsi pohľadom na to, aké príčiny sa skrývajú za vývojom chybového softvéru, a kto je vlastne v konečnom dôsledku za ne zodpovedný. V rámci manažmentu softvérového projektu však môžu výrobcovia softvéru znížiť riziká výskytu chýb vo vlastných produktoch, napríklad aj zohľadnením niekoľkých pravidiel, ktoré sú tu spomenuté.
Abstrakt. Počas procesu vývoja softvéru meranie pomáha odhadnúť časové termíny, náklady na projekt a kvalitu výsledného produktu. Tento príspevok sa zaoberá metrikami, ktoré sa používajú na určovanie a odhad veľkosti softvérového systému. Najväčšia pozornosť je venovaná metrike LOC, ktorá sa používa na určovanie veľkosti softvérového systému v etape implementácie. Použitie LOC so sebou prináša aj určité nejasnosti a problémy, ktoré súvisia s rôznym spôsobom výpočtu LOC. Časť článku je venovaná práve týmto problémom. V ďalšej časti sú stručne popísané alternatívne metriky pre určovanie veľkosti softvérového systému, nielen v etape implementácie, ale aj v iných etapách životného cyklu softvéru. V závere bude vysvetlené prečo je meranie veľkosti softvérového systému také problematické a zároveň bude načrtnutý iný pohľad na interpretáciu výsledkov merania.
Abstrakt. Zdieľanie údajov a informácií je možno považovať za základ rozvoja ľudskej spoločnosti. V dnešnej dobe sú ľudia obmedzovaní k prístupu do jednotlivých technológií, pričom údaje a informácie sa stávajú súkromným vlastníctvom ľudí a spoločností, čím sa neustále rozvíja právo duševného vlastníctva. Na ochranu myšlienok resp. postupov pred verejnosťou boli zavedené patenty, i keď sa nimi určitým spôsobom bráni ďalšiemu vývoju. Patenty sa začali udeľovať i na softvér, avšak pre niektorý softvér sa patent vôbec nehodí a pre iný softvér ho je možné použiť veľmi efektívne. Patentovanie softvéru je ešte len v začiatkoch (v USA je to už síce v pokročilejších štádiách), počet pridelených softvérových patentov z roka na rok rastie. Na rozdiel od patentu, autorský zákon (copyright) umožňuje vlastníkovi kopírovať svoju prácu.
Abstrakt. Cieľom tejto práce je pokúsiť sa identifikovať dôležité praktiky manažmentu softvérového projektu, od ktorých závisí prípadný úspech alebo neúspech projektu. Práca sa venuje niekoľkým fundamentálnym oblastiam manažmentu projektov. Jedná sa o samotného projektového manažéra, analýzu požiadaviek, odhady cien a úsilia, plánovanie, manažment rizík a postmortem analýzy. Mojím cieľom nebolo vypracovať návod na úspešné manažovanie projektov, ale radšej kladiem dôraz na identifikovanie praktík, ktoré vedú k úspechu, ako aj k neúspechu projektov. Táto identifikácia vychádza zo štatistických údajov, ktoré boli zozbierané pri prieskume in-house softvérových projektov. Výsledkom je okrem štatistických údajov aj môj osobný pohľad na problémy spojené s týmito kľúčovými otázkami manažmentu projektov.
Abstrakt. Vzťah medzi zákazníkom a dodávateľom softvéru je predmetom rozsiahleho výskumu v oblasti procesov softvérového inžinierstva. Tento príspevok sa zaoberá identifikovaním niektorých závislostí, hlavných pilierov spolupráce a vzájomných vzťahov v oblasti vývoja a dodávky softvéru z pohľadu manažmentu vzťahu so zákazníkom ako aj manažmentu dodávateľských reťazcov. Identifikované sú koncepty spolupráce pri vývoji a dodávke softvéru. Navrhnuté sú možné vylepšenia spolupráce pomocou modelov vyspelosti SA-CMM a SPIRE. Rozdielne vlastnosti dodávateľských reťazcov sú porovnané vzhľadom na rozdielne prístupy k vývoju a dodávke softvéru, pričom pozornosť je zameraná najmä na vzťah medzi zákazníkom a dodávateľom softvéru. Identifikujeme aj možné obmedzenia a negatívne vplyvy jednotlivých prístupov vzhľadom na zúčastnené strany.
Abstrakt.
Obstarávanie softvéru je od 90-tych rokov stále rozširujúcim sa trendom, ktorý nabral už globálne rozmery. Vývoj sa presúva do oblastí, kde náklady sú nízke a ľudské zdroje bohaté. Dodávatelia softvéru majú často vysunutý tím odborníkov v klienskej krajine zabezpečujúci podpornú činnosť pre zákazníka a objednávatelia zase umiestňujú svoje pracoviská do krajiny dodávateľa, pre lepšiu kontrolu veľkých projektov. V článku sa zaoberáme identifikáciou problémov spolupráce klientov a dodávateľov odlišných kultúr a poskytneme postupy na ich minimalizáciu.
Abstrakt. Často sa zvyšujúce požiadavky zákazníka, ktorých realizácia je zviazaná s čoraz kratšími termínmi, nás nútia uvažovať a realizovať zlepšenia nielen samotného procesu tvorby softvéru, ale aj zdokonaľovať samotných ľudí tvoriacich tím. Medzi základné princípy zvyšovania produktivity tímu nepochybne patrí motivácia, či už z pohľadu negatívnej alebo pozitívnej stimulácie ľudí. V neposlednej rade medzi tieto princípy patrí aj model P-CMM, ktorý popisuje odporúčania ako môžu byť realizované organizačné zmeny, umožňujúce lepší manažment a rozvoj pracovnej sily. Z pohľadu zlepšovania procesu vývoja je dôležitá integrácia tímu, ktorá môže nastávať v rôznych fázach projektu a s rôznou frekvenciou, je už len úlohou dobrého manažéra určiť kedy je najlepší čas na integráciu.