Zborník esejí 2010

Abstrakt:Riadenie je jedným z najpálčivejších problémov týkajúcich sa problematiky tvorby softvérových systémov. Nesprávne riadenie väčšinou vedie k predraženiu projektu, nedodržaniu termínov alebo úplnému zrušeniu projektu. Z mnohých prístupov a prostriedkov pre podporu riadenia tvorby softvérových projektov sa v tomto článku zameriame na tie, ktoré slúžia na sledovanie úloh a využitie ľudských zdrojov. Dôležitým parametrom podporných prostriedkov pre prácu v tíme je miera ich účinnosti vzhľadom na zefektívnenie práce a kvalitu výstupov tímu. Je však vždy účinkom týchto podporných prostriedkov uľahčenie práce? Hľadaním odpovede na túto otázku postupne identifikujeme výhody a nevýhody niektorých prostriedkov pre podporu práce v tíme. Súbežne porovnaním pohľadov manažérov takýchto tímov a na druhej strane členov tímu sa pokúsime načrtnúť víziu ideálneho podporného prostriedku.

Abstrakt:Veľké množstvo projektov počas realizácie mešká alebo skončí úplným neúspechom. Existuje veľké množstvo dôvodov, prečo je tomu tak. Významnou mierou na to vplýva aj proces plánovania, vytvárania a rozdeľovania úloh. Každá z týchto činností v konečnom dôsledku predstavuje náročnú a zodpovednú úlohu. Táto práca bude zameraná najmä na problém naplánovania existujúcich úloh v projekte. Existujú zaužívané metódy rozdeľovania úloh ako PERT, CPM, Ganttove diagramy a iné. V rámci výskumu existujú algoritmy a simulácie, ktoré využívajú tieto metódy k plánovaniu úloh v tíme. Poskytujú tak pomerne silný nástroj pre plánovanie projektu a odvrátenie prípadného neúspechu súvisiaceho so zlyhaním plánovania. Táto práca sa bude venovať aj analýze dosiahnutých úspechov spomínaných algoritmov a simulácii. Bude analyzovaná najmä vhodnosť ich použitia pre malé tímy.

Abstrakt:Vývoj softvéru je nesporne veľmi zložitý proces, ktorý je vďaka svojej komplexnosti nesmierne náročný na zaistenie kvality výsledného produktu. Kvalitu softvérového produktu môžeme vnímať z viacerých hľadísk, či už z hľadiska funkčnosti, použiteľnosti, výkonnosti alebo spoľahlivosti. Záujmom zákazníka, pre ktorého sa softvér vyvíja, je pritom dostať za svoje investované financie čo najkvalitnejší softvér po všetkých stránkach. Tento dôraz na kvalitu je zo strany zákazníka rovnaký bez ohľadu na to, či je obstarávaný softvér svojim rozsahom veľký a na jeho vytváraní sa podieľa rozsiahly tím, alebo či ide o menší projekt, vytváraný užším tímom. Veľké vývojárske tímy majú zväčša vyčlenený určitý počet svojich členov, ktorých úlohou je počas celého životného cyklu permanentne sledovať kvalitu vyvíjaného produktu a takto napĺňať očakávania zákazníka v oblasti kvality. Malý vývojový tím sa musí z tohto pohľadu uskromniť, čo však určite neznamená, že by mal menej dbať na kvalitatívne kritéria vyvíjaného produktu. Cieľom tejto eseje je oboznámiť čitateľa s problematikou testovania softvéru v prostredí malého vývojového tímu a načrtnúť riešenia, akým spôsobom sa dá aj v prostredí malého vývojového tímu vytvárať softvérový produkt s vysokými kvalitatívnymi parametrami.

Abstrakt:Vývoj softvérových projektov sa stáva čoraz zložitejším procesom. Prácu na projekte ovplyvňujú mnohé faktory. Neustále vyvíjajúce sa nové technológie, rastúce požiadavky a tempo kladené na vývojárov, ako aj rôzne interné i externé faktory, môžu nepriaznivo ovplyvniť vývoj. Mnohé softvérové projekty zlyhávajú čiastočne alebo úplne. Dôvodom býva nedodržanie časového harmonogramu, prekročenie rozpočtu alebo zníženie kvality výsledného produktu. Pre spoločnosť to znamená stratu financií, dobrého mena, či v horších prípadoch i krach. Preto je nevyhnutné sa týmto problémom dostatočne venovať a včas im predchádzať. Táto esej sa zaoberá najmä identifikáciou a klasifikáciou rizík. Čitateľovi poskytuje prehľad a klasifikáciu najčastejších rizík, poukazuje na dôležitosť procesu identifikácie rizík a v závere sa zameriava i na univerzitné prostredie.

Abstrakt:Pred štartom akéhokoľvek projektu sa vypracuje plán, ktorý má viesť k jeho úspešnému ukončeniu. Tá ťažšia časť je tento plán následne dodržať. Pri tvorbe softvérových produktov sa manažéri stretávajú s mnohými problémami, ktoré ohrozujú úspešné dokončenie produktu. Ak sa produkt aj podarí dokončiť, často je to za cenu prekročenia rozpočtu, alebo nedodržania časového harmonogramu. Väčšine z týchto problémov by sa však dalo predísť, keby manažér dokázal dostatočne skoro odhaliť, že vývoj sa uberá nesprávnou cestou. Ako to ale včas zistiť? Odpoveďou je monitorovanie stavu projektu. Ide o mechanizmus, pomocou ktorého sa na základe analýzy zozbieraných údajov vyhodnotí, v akom stave sa projekt nachádza. Následne, ak je to potrebné, sa aplikujú zmeny, ktoré by mali viesť k ozdraveniu projektu. Je však samotné monitorovanie naozaj zárukou úspechu?

Abstrakt:Tak, ako k vývoju každého softvérového systému je potreba pristupovať osobitne, tak všetci, ktorí sa na ňom podieľame, sme jedineční svojím prístupom, schopnosťami a skúsenosťami. Každý jeden člen tímu má pevne stanovenú rolu, ktorú si presadil a ktorá by mala vyzdvihovať jeho nadanie v každom bode. Výber týchto rolí býva zväčša intuitívny, no nie vždy sa približuje ideálu. V praxi som už mala viac možností vyskúšať si prácu v tíme. Na každom projekte boli na pracovníkov - členov tímu kladené iné nároky na jeho schopnosti v závislosti od spôsobu vývoja projektu. Zaujímavým príkladom je agilné programovanie, ktoré je špecifické svojim dôrazom na komunikáciu a spoluprácu v tíme, ako aj so zákazníkom, čím stavia tradičnú rolu programátora do nového svetla. Táto esej porovnáva rôzne typy osobností a ich uplatnenie v tímoch využívajúcich agilné metódy vývoja.

Abstrakt:Život je taký zložitý, aký si ho spravíme. Väčšina ľudí sa vyhovára na zložitosť používaných systémov, veľa úloh, zlé plánovanie alebo iné podobné výhovorky. V skutočnom svete je to v konečnom dôsledku vždy o ľudoch. Práve o tých ľudoch, ktorí spolu riešia úlohy, ale hlavne spolu komunikujú. Jedinci neschopní komunikovať sú v dnešnom svete IT odsúdení na zánik. Možno sa paradoxne zdá, že opak je pravdou a vďaka rôznym mobilom, komunikátorom a mailom by to malo byť jednoduchšie, nie je to tak. Práve preto treba vyberať prostriedky pre podporu riadenia projektu práve s ohľadom na komunikáciu a netreba očakávať, že podporné prostriedky vyriešia problémy za nás.

Abstrakt:Dôležitou, ale často podceňovanou súčasťou dobrého projektu je komunikácia so zákazníkom, teda jeho odhad potrieb, formovanie informácií a ich správne odovzdanie zákazníkovi a vývojovému tímu. Dobre zozbierané a zanalyzované požiadavky od klienta sú potrebné na vytvorenie presného plánu, v ktorom sú správne rozvrhnuté materiálne zdroje i pracovná sila potrebná na jeho realizáciu. Nečakané požiadavky klienta a nadhodnocovanie zdrojov v softvérovom projekte sú totiž jednou z najväčších výziev, s ktorými sa manažéri stretávajú vo svojej praxi. V eseji sa venujem otázke efektívnej komunikácie so zákazníkom a tímom a jej vplyvu na vytvorenie plánu softvérového projektu. S touto témou úzko súvisí problematika zmeny, či vzniku nových požiadaviek klienta počas tvorby produktu, a tým aj potreba zmeny plánu. Je potrebné vedieť odhadnúť dostupné zdroje a rizikové faktory. Na riešenie týchto problémov je možné použiť dostupné postupy. Medzi ne patrí aj vytvorenie jedného plánu pre vývojový tím a druhého, o zdroje mierne nadhodnoteného plánu, pre koncového zákazníka. Tomuto postupu sa budem v eseji venovať tiež.

Abstrakt:V súčasnej dobe existuje nepreberné množstvo programov a softvérových produktov, no mnohé z nich nedosahujú kvalitu, ktorú by si zaslúžili, resp. ktorá by bola žiadaná. Často dochádza k znižovaniu kvality už pri samotnom vývoji produktu. Vinu na tom majú viaceré faktory, s ktorými prichádza vývojový tím do styku. Manažment kvality poskytuje prostriedky na to, aby sa negatívny vplyv týchto faktorov minimalizoval. Pomáha využívať pri vývoji osvedčené metodiky a nástroje, ktoré do určitej miery zabezpečujú udržanie kvality na prijateľnej úrovni. Esej sa venuje niektorým závažným nedostatkom produktov z hľadiska kvality, ktoré sa veľakrát objavia až po uvoľnení produktu do obehu. Hľadá príčiny vzniku týchto problémov a zamýšľa sa nad možnými riešeniami a nad tým, ako im je možné predísť.

Abstrakt:Manažment rizík je významnou súčasťou riadenia softvérových projektov a v súčasnosti sa zvyšuje jeho význam, aj keď jeho reálne uplatňovanie ako samostatnej fázy sa stále v pomerne veľa projektoch nepresadzuje. Hoci manažovanie rizík nie je esenciálnou činnosťou, významnou mierou zvyšuje pravdepodobnosť úspešného zavŕšenia projektu. Kým v prípade rozsiahlych projektov sa manažment rizík v nejakej forme zvyčajne uplatňuje, pri projektoch, na ktorých sa podieľajú malé tímy (rádovo menej ako desať členov) je tendencia túto činnosť zanedbať. Táto esej chce zdôrazniť, že manažment rizík má svoje miesto a prispieva k úspešnosti projektov bez ohľadu na ich rozsah. Malé tímy, ktoré neriešia príliš komplexné úlohy, môžu pri výskyte nejakej komplikácie (teda pri naplnení rizika) reagovať nepochybne flexibilnejšie ako veľké tímy. I tak je ale vhodné, ak si tímy sú možných rizík vedomé a majú predstavu, ako by sa s prípadnými neželanými udalosťami vyrovnali už v čase iniciovania a počiatočného plánovania, prípadne aj pred iniciovaním jednotlivých iterácií projektu. Esej sa tiež zameriava na vplyv zvolených metodík a rozoberá dopad skúseností na úspešnosť projektu.

Abstrakt:Je všeobecne známe, že pri vývoji softvéru je jednou z najväčších výziev správne odhadnúť množstvo času potrebného na jeho výrobu, testovanie a distribúciu. Samozrejme, keďže tvorba softvéru je dynamický proces, je takmer nemožné dostať dostatočne presný odhad hneď pri začiatočnej fáze plánovania. V tejto eseji by som sa chcel zamerať na monitorovanie odhadovaného a reálneho času vynaloženého na vývoj softvérového produktu. Chcel by som najmä vyzdvihnúť význam času ako primárneho zdroja vývojárskych firiem a nutnosť jeho manažmentu. Rozoberiem niektoré metódy, ktoré môžu projektoví manažéri použiť na sledovanie času stráveného nad jednotlivými časťami softvéru a vplyv týchto zistení na ďalšie plánovanie vývoja daného produktu.

Abstrakt:Je množstvo spôsobov ako zostaviť tím. Náhodným pridelením ľudí na jednotlivé pozície, vypísaním pracovnej ponuky na určitý post, ktorý chce firma obsadiť, či vytvorením skupiny ľudí, ktorým sú neskôr pridelené jednotlivé funkcie. V tejto eseji sa budem zaoberať posledným spomenutým spôsobom. Väčšinou sa funkcie prideľujú na základe osobných pohovorov a rôznych dotazníkov, v ktorých sa zamestnanci majú sami ohodnotiť. Skúmajú sa v nich vaše znalosti, vedomosti a skúsenosti v danej oblasti, v ktorej pracujete. Jeden z dotazníkov by mal slúžiť na zistenie typu osobnosti. Pri práci v tíme je veľmi dôležité aké typy osobností tím tvoria. Existuje viacero spôsobov a prístupov k rozdeleniu osobností. V tejto eseji spomeniem niektoré z nich a porovnám, ako jednotlivé prístupy môžu ovplyvniť tím v jeho neskoršom fungovaní. Pokúsim sa vybrať najlepšiu metódu na určenie typu osobnosti.

Abstrakt:Riadenie softvérového projektu je zložitá a komplexná činnosť, ktorá obsahuje viacero aktivít, ktoré musí manažér zvládať. Sú to napríklad odhadovanie, plánovanie, manažment ľudských zdrojov, organizáciu času, sledovanie stavu projektu a prijímanie potrebných opatrení. Pri súčasnom trende rastúcej zložitosti softvérových projektov je samozrejmé, že k týmto činnostiam nemôžeme pristupovať ad-hoc, ale využívame rôzne nástroje, metodiky a podporné prostriedky, ktoré zjednodušujú prístup k informáciám o stave projektu. Táto esej sa zaoberá riadením softvérového projektu ako takým. Analyzuje viaceré metódy sledovania plnenia úloh a manažmentu ľudských zdrojov ako je Ganttová schéma alebo matica zodpovednosti. A v neposlednom rade sa snaží zodpovedať otázku, či aj pri malých softvérových projektoch, ako je ten, ktorý momentálne riešim na predmete Tvorba softvérového systému v tíme, je vhodné používať integrované podporné nástroje na podporu riadenia projektu.

Abstrakt:Vývoj softvéru je zložitý a časovo náročný proces, ktorý vyžaduje mať veľmi dobre zvládnutú každú svoju časť. Pre potreby efektívneho manažovania a úspešného zvládnutia projektu je však potrebný hlavne kvalitne vypracovaný plán. Hoci existujú softvérové projekty rôzneho charakteru, tak v každej skupine sa nájde projekt, ktorý mešká, či dokonca neskončí úspešne. Ako je to možné? Prečo je to tak? A ako sa vlastne dá v maximálnej možnej miere vyhnúť zlyhaniu? Táto esej zodpovedá práve tieto otázky. Poukazuje na hlavné chyby pri plánovaní softvérových projektov a navrhuje, ako sa im vyhnúť alebo ich aspoň minimalizovať. Taktiež sa zaoberá, ako správne tvoriť plán softvérového projektu, aby viedol k úspešnému koncu.

Abstrakt:Keď sa povie riadenie kvality softvéru, väčšina ľudí si vybaví dôkladné otestovanie jeho funkčnosti. Často zanedbávaná však býva kontrola vnútornej kvality softvéru - kvalita návrhu, zdrojového kódu a dokumentácie. Zákazníci často takýto stav nepostrehnú, lebo nejde o aspekty, ktorými by sa softvér prejavoval navonok. Dodávateľ upustením od vnútornej kvality zníži svoje náklady na vytvorenie prvej verzie a navyše viac upevní svoju pozíciu u zákazníka (u projektov na mieru), lebo iná firma nebude schopná uskutočniť zmeny na dodanom softvéri. Za zložitejšie úpravy v budúcnosti navyše môže účtovať viac peňazí, lebo zákazník nemá na výber iného dodávateľa a iný dodávateľ by pýtal za úpravy ešte viac. Aký je vplyv vnútornej kvality softvéru na všetky zúčastnené strany v softvérovom projekte? V eseji sa autor zamýšľa aké teoretické, praktické aj ekonomické príčiny môžu vplývať na zníženie vnútornej kvality softvérových projektov a aké sú dôsledky takéhoto zníženia.

Abstrakt:Manažment rizík je dôležitou súčasťou práce manažéra softvérového projektu. Efektívnym manažmentom rizík sa dá predísť neúspešnému ukončeniu softvérového projektu. V tejto eseji uvediem analýzu vplyvu okolitého prostredia a vzťahov vo firme na manažment rizík. Ľudský faktor úzko súvisí s rizikami v projektoch. Ľudia sú na jednej strane zdrojom rizík, na strane druhej sú to práve ľudia, ktorí dokážu riziká minimalizovať. V eseji uvádzam prečo je potrebné venovať sa rizikám. Opisujem desať primárnych zdrojov rizík v softvérovom projekte a ukazujem ako tieto riziká súvisia so vzťahmi vo firme a ako sociálne prostredie ovplyvňuje riziká v softvérových projektoch. V závere eseji poukazujem aj na to, aby firmy podporovali dobré vzájomné zamestnanecké vzťahy, keďže môžu ovplyvňovať riziká projektov.

Abstrakt:Monitorovanie stavu a vývoja projektu je dôležitou súčasťou manažmentu softvérových projektov, bez ktorého sa dodržanie dohodnutých termínov či plánovaného rozpočtu stáva iba zbožným želaním členov tímu. Od chvíle, kedy sa do rúk manažérov dostane plán vývoja softvérového projektu, ich prvoradou úlohou sa stáva sledovanie a monitorovanie prác zúčastnených tímov. Cieľom tejto náročnej činnosti je včas identifikovať vzniknutý problém v určitej fáze projektu a podniknúť adekvátne kroky k minimalizovaniu prípadných škôd. V mojej eseji sa venujem zhodnoteniu obmedzení, ktoré nepriaznivo vplývajú na relevantnosť a precíznosť plánovania, ktoré je podkladom pre následné monitorovanie projektu. Ďalej sa zameriavam na zhodnotenie cieľov a postupov samotného procesu monitorovania spolu s identifikovaním príčin vzniknutých anomálií a spôsobu ich nápravy. Záver je venovaný možným následkom po zle zhodnotených zásahoch do vývoja softvérových systémov.

Abstrakt:Na tvorbe softvérového projektu sa väčšinou podieľa viacero ľudí a tímov. Členovia tímu by mali spolupracovať a vyvíjať projekt v rámci kolektívu. Musia medzi sebou komunikovať, vymieňať si informácie a navzájom si pomáhať. Postaviť tím, ktorého členovia si budú rozumieť, je niekedy veľmi náročné. Možno ešte ťažšie sa hľadá osobnosť, ktorá by takýto tím viedla. Pri výbere správneho vedúceho tímu je nevyhnutné dbať nie len na jeho pracovné skúsenosti a schopnosti, ale aj na jeho povahové črty. Na určenie typu osobnosti je použitý Myers-Briggsovej typový indikátor, ktorý mi pomohol pomerne presne zadefinovať povahové črty osobností. Dokonalá kombinácia vlastností neexistuje. Vďaka výskumom [1] [5] a svojím vlastným skúsenostiam som aspoň približne určil, aká by mala byť povaha úspešného vedúceho tímu.