Zborník esejí 2011

Abstrakt:Žijeme v uponáhľanom svete, kde sa všetci snažíme čo najlepšie využívať potenciál všetkého s čím pracuje, čo najlepšie. Každý z nás by chcel dosahovať čo najlepšie výsledky pri vynaložení čo najmenšieho úsilia. Z tohto jednoduchého, ale veľmi lákavého dôvodu sa aj vo svete informačných technológií začalo vykonávať monitorovanie životného cyklu softvéru. Vďaka tomu vieme chyby oveľa lepšie eliminovať alebo úplne odstrániť a tým znižovať náklady čiže zvyšovať zisky. Každý projekt je však jedinečný a ku každému sa treba postaviť trochu inak. Nič však netreba preháňať a preto ani pri monitorovaní neplatí, že čím viac monitorujeme, tým lepšie výsledky budeme dosahovať. Tak potom na čo sa zamerať? Vieme si stanoviť tú správnu granularitu?

Abstrakt:Keď sa pozrieme na štatistiky úspešnosti softvérových projektov, odkryje sa pred nami nie celkom povzbudivý obraz. Približne každý piaty projekt končí úplným neúspechom, pričom pri takmer každom druhom projekte dochádza k problémom v podobe prekročenia rozpočtu, termínov alebo výsledný produkt nenapĺňa v plnej miere požiadavky zákazníka. Medzi najväčšie riziká pritom patrí použitie nesprávnej metodiky, nedostatočná zaangažovanosť zákazníka či neustále sa meniace požiadavky. Zlyhanie projektu je však vždy dôsledkom súhry viacerých príčin. Ako teda rizikám úspešne predchádzať? Jedným zo spôsobov je riadiť sa agilnou vývojovou metodikou Scrum, ktorá podľa môjho názoru už zo svojej podstaty niektoré riziká eliminuje, alebo ich aspoň do značnej miery minimalizuje. Avšak každá minca má dve strany a Scrum nie je všeliek, naopak prináša so sebou niektoré špecifické riziká, s ktorými musíme počítať.

Abstrakt:Spôsob vývoja, ktorý si zvolíme v softvérovom projekte, hrá dôležitú úlohu v celom životnom cykle projektu. Scrum ako vývojová stratégia výrazne ovplyvňuje spôsob plánovania projektu, rozdeľovania úloh jednotlivým členom tímu a zapracovávanie zmien do celkového plánu projektu. Keďže samotný Scrum sa delí na behy, pre ktoré sa vytvárajú špecifické plány na vopred určené kratšie obdobie dvoch až štyroch týždňov, aj plánovanie sa musí prispôsobiť tejto stratégii. Úlohy sa rozdeľujú medzi členov tímu s prihliadnutím na predchádzajúce behy, pričom plán práve bežiaceho behu nie je možné meniť, len vynechať niektoré úlohy. Výsledkom je krátkodobé plánovanie a častá revízia plánu v momente skončenia jedného z behov. Vďaka tomuto novému prístupu k vývoju softvéru nám v oblasti plánovanie vyplávajú na povrch nasledovné otázky. Ako čo najlepšie prispôsobiť plánovanie Scrumu? Prináša Scrum viac výhod, či nevýhod pre plánovanie a vedenie softvérového projektu? Vieme pomocou Scrumu lepšie rozdeliť úlohy medzi členov tímu tak, aby tím pracoval, čo najefektívnejšie?

Abstrakt:Cieľom každého zákazníka je dostať softvér v požadovanej kvalite, ktorú bude akceptovať. Samotný softvér ale môžeme vyvíjať viacerými spôsobmi. Či chceme alebo nie, zvolená metóda vývoja sa odrazí na celkovej kvalite konečného produktu. V súčasnosti sa čoraz častejšie začínajú používať agilné metódy vývoja, ktoré sa rozširujú na úkor klasických prístupov. Vďaka nim produkujeme softvér rýchlejšie, ale je nutné vedieť zabezpečiť kvalitu na požadovanej úrovni v každej etape. Na základe porovnania agilného prístupu s klasickým vývojom ukážem, ako závisí kvalita softvéru od vybraného spôsobu vývoja a čím je ovplyvnená. Aké dôsledky z toho pre nás vyplývajú? Ako ich využiť v náš prospech a maximálnu spokojnosť zákazníka?

Abstrakt:V poslednej dobe vnímame veľký vplyv obchodnej a trhovej globalizácie na mnoho odvetví. Oblasť softvérového inžinierstva nie je výnimkou. Výhody informačných technológií umožňujú vznik geograficky distribuovaných a virtuálnych tímov. Tento trend však napriek mnohým výhodám prináša aj viaceré technické, sociálne a kultúrne problémy, ktoré nie sú typické pre lokalizované projekty. Dôsledkom je, že pre efektívny manažment úloh a ľudských zdrojov už nestačia tradičné podporné prostriedky, ktoré nezohľadňujú rozdiely v manažmente lokalizovaných a distribuovaných softvérových projektov. Jedným z najvýznamnejších rozdielov je práve sledovanie pridelených úloh a využitie ľudských zdrojov. Preto je dôležité tomuto aspektu pri výbere podporného prostriedku venovať dostatočnú pozornosť. V súčasnosti však existuje veľké množstvo takýchto podporných prostriedkov. Ako zistíme, ktorý z nich je vhodný pre náš projekt?

Abstrakt:Vývoj softvérových aplikácií prebieha v dnešných časoch najmä v tíme a hlavne vďaka tímovej práci. Doby, keď bol jednotlivec zodpovedný za celú aplikáciu a vývoj softvéru sa pomaly strácajú. Manažment jednotlivca bol pomerne jednoduchý, neboli potrebné rôzne pokročilé riešenia evidencie stavu práce, evidencie stavu projektu. Jednotlivec mal prehľad o všetkom. Čo však, keď máme tím? Ako budeme sledovať jeho prácu? Ako zistíme, kde stojíme s prácou? Aké nástroje nám môžu pomôcť, aby sme vedeli prácu správne zadeliť a neplytvali časom a schopnosťami jednotlivých členov tímu? Aké vlastnosti by mala aplikácia spĺňať, aby bolo možné rozdeliť prácu efektívne? Na tieto otázky sa pokúsim zodpovedať v tejto eseji.

Abstrakt:Komunikáciu možno definovať ako výmenu informácií, myšlienok a názorov medzi osobami. Na prvý pohľad až príliš elementárna vec, ktorej nie každý venuje dostatočnú pozornosť. Jej efektívne využitie je však základným stavebným kameňom pre úspešný vývoj v softvérovom projekte. Otázkami ostáva, kto potrebuje komunikovať s kým? Aké informácie potrebuje? Ako sa k nim dostane? Tieto otázky patria medzi kľúčové prvky efektívnej komunikácie. Mojim cieľom je poukázať na význam prostriedkov na podporu komunikácie, ich výhody a nevýhody. Osobitnú pozornosť budem venovať využívaniu podporných nástrojov na komunikáciu v softvérovom tíme. Nakoniec opíšem problémy spojené s nedostatkom komunikácie a poskytujem rady na jej zefektívnenie pri práci na projektoch.

Abstrakt:Akýkoľvek druh softvéru, či už ide o malú voľne šíriteľnú aplikáciu, alebo rozsiahly účtovnícky informačný systém, ktorý pri svojej každodennej práci s počítačom používame, je označený číslom vyjadrujúcim jeho verziu. Za tímto často krát až smiešne zložito vyzerajúcim číslom sa však skrýva obrovské množstvo informácií, ktoré sú ale väčšine hlavne menej počítačovo gramotných ľudí neznáme. Bežný používateľ sa riadi len zaužívanou pravdou: “Čím viac tím lepšie!” Preto každú vyššiu verziu považujú za menej chybovú, jedným slovom lepšiu. Ale je to naozaj tak? Čo všetko nám toto číslo hovorí? Je vôbec nutné spravovať viac verzií? Dúfam, že sa mi aspoň trocha podarí odhaliť tajomstvá skrývajúce sa za touto problematikou.

Abstrakt:Odpoveď na možno esenciálnejšiu otázku, a to: “Prečo plánovať?” je veľmi jednoduchá, pretože to inak ani nejde. To je myslím postačujúcim dôvodom, prečo pokročiť o kúsok ďalej a zaoberať sa dôležitejším problémom, a to ako na to. Keďže študenti sú zväčša využívaní ako lacná pracovná sila, samozrejme toto závisí od ich schopnosti predať sa, majú len zriedka kedy príležitosť dostať sa k plánovaniu softvérového projektu, trocha na vyššej úrovni než je len harmonogram vlastných prác, ktorý im zväčša stanoví manažér bez ďalších otázok. Skôr či neskôr sa však každý stretne aj s touto činnosťou, a preto je potrebné o tomto procese vedieť niečo viac. V tejto eseji sa pozrieme čo to je plánovanie, rozoberieme si procesy plánovania softvérového projektu, určíme v ňom kritické body a prejdeme aj cez niektoré techniky plánovania. Pokúsime sa zodpovedať otázku stanovenú na začiatku a následne odpovedať aj na niektoré pod otázky vyplývajúce z tejto problematiky. Aby každý proces tvorby softvérového projektu reprezentoval efektívne využitie vynaložených nákladov, je dôležité nezaoberať sa príliš dlho otázkou ako naplánovať projekt, ale plne sa sústrediť na kvalitu výsledného produktu.

Abstrakt:Každá činnosť človeka, od najjednoduchšej až po tú najzložitejšiu, nesie určitú dávku rizika. S rastom jej dôležitosti a možnosti utrpenia straty pri jej vykonávaní, rastie aj potreba eliminácie faktorov, ktoré by mohli viesť k nepredvídaným katastrofám a veľkým stratám. Dôležitosť a potrebu manažmentu rizík v softvérovom inžinierstve dopĺňa fakt, že zlyhanie v tejto sfére nie je ničím neobyčajným. Manažment rizík predstavuje systematické metódy pre identifikáciu, analýzu, plánovanie a riadenie rizík. Táto esej pojednáva o najčastejšie sa vyskytujúcich rizikách vo väčších softvérových projektoch a vysokoškolských projektov. Vzájomne ich konfrontuje, a prináša prehľad o metódach ich identifikácie a efektívnej eliminácie rizík študentských projektov za pomoci metódy Riskit.

Abstrakt:Slovo kvalita sa s vývojom softvérových produktov spája už od počiatkov vývoja softvéru. Vieme, že kvalita má niekoľko definícií, no z pohľadu každej je kvalita vo vývoji softvéru nevyhnutná. V súčasnej dobe sa presadzujú agilné metódy pri vývoji softvéru. Agilné metódy sa používajú najmä v malých, či stredne veľkých tímoch a umožňujú vyvíjať softvér pomerne rýchlo vzhľadom na nestabilné požiadavky. Otvorenou otázkou ale je, či sú agilné metódy vhodné pre projekty každej veľkosti a zároveň, ktoré časti v manažmente kvality sú kritické. Ako teda vôbec v projektoch môžeme zabezpečiť kvalitu pri agilnom vývoji softvéru? Na čo si v malom tíme dávať pozor a aké úskalia z pohľadu kvality prinášajú? Je zabezpečenie kvality pri agilnom vývoji softvéru závislé od prostredia? Hoci na tieto otázky nie je v literatúre vyhradený názor, je potrebné sa nad nimi zamyslieť, pretože ich ignorovanie môže mať negatívny vplyv na úspech projektu.

Abstrakt:Každý člen projektu z akejkoľvek oblasti je len človek. To platí aj v softvérových projektoch, hoci domnienka spoločnosti je, že člen softvérového projektu je len nositeľom technických znalosti. Produktom softvérového projektu je softvér, ktorý je výsledok dlhodobej spolupráce skupiny ľudí. Slovo spolupráca je veľmi dôležité, pretože žiadny z členov nie je dokonalý vo všetkom. Každý vyniká inými schopnosťami nie len technického typu, ale aj schopnosťami z psychologickej oblasti ako je napríklad schopnosť komunikácie, práce v tíme a mnohými inými. V skupine existuje veľká rozmanitosť charakteristík osobností. Otvorenou otázkou však naďalej zostáva, aký je správny pomer jednotlivých schopnosti pre jednotlivé roly v softvérovom projekte.

Abstrakt:Úspech nového projektu nezávisí len od jeho podrobného spracovania. Jeho osud je tiež závislý od tímu, ktorý ho bude vytvárať. Zostavenie tímu by sme mohli prirovnať k stavbe domu. Pokiaľ ho postavíme na pevných základoch, dom sa nezrúti, nevezme ho voda, ale pokiaľ ho postavíme na piesku, pri prvej búrke či otrase nám dom spadne. Výber správnej skupiny ľudí je veľmi náročný a dôležitý proces. Ľudí je potrebné vyberať nielen podľa ich skúseností, zručností a praxe, ale správna kombinácia typov osobností je jeho nevyhnutnou súčasťou. Vzťahy medzi členmi tímu musia byť nekonfliktné, musia byť na jednej frekvencii a samotný výsledok práce tiež na vysokej úrovni. Cieľom tejto eseje je poukázať na správne vytvorenie tímu pre softvérový projekt, poukázanie na klady a zápory, špecifikovanie typov osobností vhodných na jednotlivé úlohy v rámci projektu.