Zborník esejí 2008

Abstrakt:Na to, aby mohol byť softvérový projekt úspešný je určite potrebné mať dobre zostavený plán. Existuje široké množstvo najrôznejších metód na vytváranie plánov, ale pri použití ktorejkoľvek z nich môžu vzniknúť problémy, ktoré nás donútia naše plány zmeniť. Žiaden problém nevzniká len tak, samovoľne, práve naopak… Jedným z dôvodov sú chyby, ktorých sa pri plánovaní dopúšťame. A práve týmto chybám sa budem v nasledujúcej eseji venovať. Spoločne sa pozrieme na 9 základných chýb plánovania v softvérovom projekte, na ich príčiny a dôsledky. Ďalej sa pokúsim zakomponovať do tvorby plánov aj ľudský rozmer – človeka, ako neoddeliteľnú súčasť plánovania a vývoja softvérového projektu. Človeka, na ktorom stojí a padá celé plánovanie, od ktorého závisí všetko, pretože ani človek, podobne ako žiaden plán, nie je dokonalý.

Abstrakt:Softvérové projekty čelia vysokému množstvu rizík, od štádia vytvárania až po nasadenie v praxi. Nevenovať sa téme prevencie rizík pri tvorbe softvérového projektu, môže spôsobiť spoločnosti vyššie ekonomické straty, než čas a náklady vynaložené na analýzu a plánovanie manažmentu rizík. Projekt bude úspešný vtedy, ak jeho projektový manažéri budú schopní identifikovať a zabrániť čo najvyššiemu počtu rizík. Preto tejto hrozbe treba venovať náležitú pozornosť. S akými rizikami sa môžeme stretnúť? Ako predchádzať ich výskytu? V každej fáze vývoja projektu sa objavia určité problémy. Esej nás uvedie do problematiky rizík v softvérovom projekte, poskytne nám zoznam najčastejšie sa vyskytujúcich rizík a ponúkne metódy ako im predchádzať.

Abstrakt:Každý softvérový projekt tvoria ľudia. Je len otázkou správneho manažmentu, či projekt efektívne využije tieto zdroje. Nie je vždy najlepšie vyvinúť čo najviac úsilia, ale vyvinúť ho čo v najvhodnejšej miere. Preto často je nutné používať podporné prostriedky na rozdeľovanie ľudských zdrojov podľa schopností a možností každého člena tímu. Esej sa zaoberá sledovaním úloh, maticou zodpovednosti a manažmentom ľudských zdrojov. Analyzuje niektoré funkcionality podporných prostriedkov vzhľadom na použitie v softvérovom tímovom projekte, ktorý realizujeme v rámci štúdia.

Abstrakt:Tvorba softvérového projektu vyžaduje súčinnosť viacerých osôb, ktoré tvoria pracovnú skupinu. Na podporu činností takýchto skupín existuje softvér, odborne označovaný ako groupware. Predkladaná práca sa zaoberá základnými pohľadmi na tento druh softvéru a na samotnú spoluprácu ako základný element skupiny. V ďalšej časti rozoberá 7 všeobecných požiadaviek na groupware s cieľom dosiahnutia použiteľnej softvérovej aplikácie. Samostatná časť sa venuje rozšíreniu všeobecného groupware-u pre potreby skupín pracujúcich na softvérových projektoch. Obsahuje krátky opis najčastejšie používaných modulov. V závere sa práca venuje problematike motivácie členov k používaniu podporného softvéru. Predkladá zaujímavé, kreatívne, užitočné riešenia tohto problému z pohľadu samotného člena pracovnej skupiny.

Abstrakt:Dátové skladiská, ako napríklad systémy pre správu verzií zdrojových kódov (CVS), sú v dnešnej dobe nevyhnutnou súčasťou vývoja softvérových projektov. Tieto systémy zaznamenávajú informácie súvisiace s históriou vývoja projektov, ako napríklad informácie týkajúce sa refaktorizácie zdrojových kódov. Pri skúmaní týchto údajov v dostatočne veľkom množstve je možno s použitím vhodných nástrojov zúžitkovať tieto informácie pri vývoji projektu, a tak poskytnúť užitočné informácie nielen samotným vývojárom, ktorým môže pomôcť napríklad predvídaním chýb v zdrojových kódoch, ale aj manažérom projektov, ktorí môžu efektívnejšie korigovať smerovanie projektu. Tento dokument sa zaoberá skúmaním nástrojov a metód, ktoré efektívne využívajú tieto informácie a pomocou nich poskytujú užitočný podporný prostriedok pri vývoji softvérového projektu.

Abstrakt:Testovanie má v procese vývoja softvéru svoje pevné postavenie. Môžeme sa naň pozerať ako na jednu z metód na zabezpečenie kvality. Softvér vieme testovať na rôznych úrovniach s využitím rôznych stratégií. V tejto eseji si ukážeme základné princípy testovania, ako aj začlenenie testov do plánovania projektu. Priblížime si testovanie metódou čiernej a bielej skrinky. Zameriame sa aj na kvalitu samotných zdrojových kódov, ich písanie a revízie v menších tímoch. Pozrieme sa na V-model vývoja softvéru a plánovanie testov. Na zabezpečenie kvality softvéru v menších tímoch sa jemne inšpirujeme agilnými metódami.

Abstrakt:Dekompozícia úloh v projekte (Work breakdown structure) je štruktúrovanie projektov na menšie, jednotlivcami splniteľné úlohy. Pri procese vytvárania takéhoto stromu úloh sa treba zamerať na čo najefektívnejšie rozdelenie, čo znamená podeliť úlohy na cenovo a časovo merateľné tak, aby ich členovia tímu boli schopní zvládať paralelne. Je potrebné dosiahnuť, aby prichádzalo k čo najmenšiemu počtu blokovania prác (čaká sa na niektorú nesplnenú úlohu, ktorá je nevyhnutná pre ďalšie práce). Taktiež treba prihliadať na rozdelenie z hľadiska pracovníkov, teda zvážiť pracovné časy, skúsenosti, rýchlosť a kvalitu práce členov tímu, snažiť sa kategorizovať úlohy a rozhodnúť či pracovník lepšie zvláda úlohy rovnakej kategórie alebo lepšie pracuje ak má rozmanité úlohy. Medzi úlohy musí byť podelený taktiež pracovný čas a prostriedky vymedzené na projekt. Na vytvorenie takéhoto rozdelenia môže pomôcť kvalitný softvérový nástroj, ale väčšinu úspechu má v rukách skúsenosť a šikovnosť vedúceho pracovníka. Tento dokument hľadá jednotlivé faktory ovplyvňujúce kvalitu WBS stromu, ich vlastnosti a dôležitosť s akou by na ne mal dobrý projektový manažér prihliadať.

Abstrakt:Zabezpečenie kvality softvéru je plánované a systematické zloženie aktivít ktoré zaručujú, že softvérové procesy a produkty budú spĺňať dané požiadavky, štandardy a iné špecifikované procedúry. Procesy zahŕňajú všetky aktivity počas dizajnu, vývoja, vylepšovania a udržiavania softvéru. Produkty predstavujú softvér, s ním spojené dáta, dokumentáciu a inú podporu. Na zabezpečenie kvalitu je dôležité myslieť počas celého životného cyklu softvéru, preto sa pokúsim v tomto článku porovnať niektoré vybrané metodiky vývoja softvéru (XP, MSF, ...) z hľadiska zabezpečenia kvality, a rozobrať vývoj softvéru riadený pomocou testov (tzv. Test driven development).

Abstrakt:V procese tvorby softvérového projektu hrá plánovanie činnosti a práce jednu z najpodstatnejších úloh. Nie je nič horšie ako pracovať na projekte niekoľko mesiacov a zistiť, že sa za ten čas skoro nič nevykonalo a termín odovzdania sa neúprosne blíži. Preto by som chcel v nasledovnom texte poukázať na možnosti plánovania v projekte a hlavne také, ktoré prinesú spokojnosť ako vývojárom, tak aj zákazníkom. To zahŕňa proces rozdelenia práce na časové úseky, rozdelenie projektu na moduly a v neposlednom rade rozhodnutia, kedy a čo ukázať zákazníkom, prípadne vydať. Tieto procesy je potrebné vykonať tak, aby bol plán dostatočne motivujúci pre tím, a výstupy práce tímu zas dostatočne uspokojujúce pre zákazníkov.

Abstrakt:Riziko, hlavne také, ktoré môže spôsobiť úplný koniec projektu, je niečo, na čo si treba dávať poriadny pozor, ale aj napriek tomu je zlyhanie softvérového projektu až prekvapivo bežná záležitosť. Vo väčšine týchto prípadov by sa zlyhaniu dalo zabrániť dodržiavaním určitých zásad a metód, ktoré sa označujú ako manažment rizík. Manažment rizík zahŕňa postupy ako riziká identifikovať, analyzovať a odstrániť, prípadne minimalizovať ich výskyt a dopad na softvérový projekt. V tejto eseji sa zaoberám najčastejšie sa vyskytujúcimi rizikami v softvérových projektoch, spôsobmi ako ich správne identifikovať, ako sa s nimi čo najefektívnejšie vysporiadať a ako tento boj s rizikami vplýva na celkový beh softvérového projektu.

Abstrakt:Tvorba softvérového projektu takmer vždy predpokladá prácu v tíme. Efektivita tímovej práce je podmienená rôznymi faktormi. Okrem profesionálnych kvalít ako skúsenosti a znalosti jeho členov sú nimi aj osobnostné rysy jednotlivcov, ktoré určujú akým spôsobom budú pristupovať k zvereným úlohám, riešeniu vzniknutých problémov, ale aj k samotnej interakcii medzi sebou. Určujú, kto sa hodí na rolu menežéra, kto na pozíciu analytika alebo vývojára, a ktoré typy osobností by sa v tíme radšej nemali stretnúť. V tejto eseji pojednávam najmä o výhodách a nevýhodách zloženia tímov s nízkou alebo príliš vysokou diverzitou osobnostných typov, a kedy je ktorá kombinácia vhodná z hľadiska efektivity riešenia pridelených softvérových projektov.

Abstrakt:Vývoj softvéru v tímoch, či už na komerčné, alebo akademické účely je komplikovaná úloha. Extrémne rýchly pokrok v technológiách a metódach vývoja softvéru spolu so vzrastajúcou zložitosťou vyvíjaných aplikácii predstavuje veľké výzvy pre softvérových inžinierov. Tieto výzvy sú navyše skomplikované tým, že softvérové procesy sú zamerané na človeka, čím ich môžeme charakterizovať aj ako veľmi variabilné a nepredvídateľné. Všetky tieto fakty ústia do množstva neskoro odovzdaných a predražených projektov. V tejto eseji sa budem snažiť zamerať na faktory a veličiny, ktoré by mal projektový manažér sledovať, spôsoby ako ich monitorovať a kroky, ktoré je vhodné podniknúť v prípade, že neide všetko podľa plánu.