Zborník esejí 2010

Abstrakt:Softvérové projekty neustále naberajú na zložitosti, doba kedy stačil na vývoj jeden maximálne dvaja ľudia sa stáva minulosťou. Riadenie, respektíve spolupráca väčšieho počtu ľudí na jednom projekte ale nie je triviálnou záležitosťou. Je potrebné riešiť plánovanie, zdieľanie dokumentov, kontrolovanie úloh a iné ďalšie úlohy. Presne na tieto potreby boli však vytvorené rôzne programové nástroje, ktoré nám, ako projektovým manažérom uľahčujú život. Zároveň nám umožňujú zamerať pozornosť na skutočné problémy projektu. V tejto eseji sa zaoberám podpornými prostriedkami. Sústredím sa hlavne na menšie projekty podobného typu ako je tímový projekt. V záverečnej časti eseje sa snažím pozrieť na slovné spojenie podporný prostriedok z trocha iného pohľadu. Ide o využitie motivácie ako podporného prostriedku.

Abstrakt:Cieľom plánovania softvérového projektu je odhadnúť potrebné množstvo práce a vytvoriť samotný časový plán, ktorým sa bude projekt riadiť. Najnovšie trendy v oblasti softvérového inžinierstva, najmä agilne metódy vývoja softvéru, však pokladajú za dôležitejšiu schopnosť prispôsobovať sa zmenám, a nie striktné dodržiavanie plánu. Prispôsobivosť však neznamená úplnú absenciu plánovania, ale len iný prístup k tvorbe plánov. Na rozdiel od klasických spôsobov vývoja sa vytvárajú len krátkodobé plány, ktoré sú vytvárané celým tímom spolu so zákazníkom. Po splnení plánu je vždy vytvorený nový plán pre ďalšiu etapu vývoja. Z dlhodobého hľadiska sú identifikované len najzákladnejšie ciele projektu, ktoré však nemajú charakter plánu, ale len požiadaviek, ktoré ma hotový softvér spĺňať. Takýto systém plánovania sa ukazuje ako výhodný najmä pri menších projektoch, pri väčších projektoch nastavajú problémy. Táto esej si kladie za cieľ poukázať na výhody agilného plánovania a na možné riziká takéhoto prístupu k plánovaniu softvérového projektu.

Abstrakt:Keďže výsledkom procesu vývoja softvéru je vytvorenie určitého výrobku, nastáva otázka ako zabezpečiť jeho kvalitu. Avšak na rozdiel od iných výrobkov je kvalita softvéru ťažšie merateľná a taktiež aj ťažšie definovateľná. Nedokážeme konkrétne povedať čo je kvalitný softvér. Na kvalitu sa môžeme pozerať z viacerých uhlov pohľadu – z pohľadu programátorov, projektového manažéra, koncových používateľov atď. V dnešnej dobe je čoraz viacej firiem poskytujúcich softvérové riešenia a tak je kvalita jedným z faktorov, ktoré ovplyvňujú ich postavenie na trhu a tvoria dobré meno firmy. Jednou z metód zabezpečenia kvality softvéru je aj testovanie. V tejto eseji opíšem niektoré problémy testovania, ale hlavne porovnám rôzne prístupy k testovaniu v niektorých používaných metodikách, keďže nie každá metodika sa stavia k testovaniu rovnako. A taktiež opíšem princípy testovania využívané v agilných metodikách vývoja SW a porovnám ich s tradičným prístupom.

Abstrakt:Počas procesu vývoja softvérového produktu manažéri častokrát indikujú a následne analyzujú riziká a ich dopad v softvérovom projekte. Pripravenosť a dostatočná analýza možných rizík, ako aj následné plánovanie v zmysle pripravenej reakcie ak sa dané riziko objaví, má za následok do akej miery bude projekt úspešný. Či už vedomé alebo nevedomé nezohľadnenie, ako aj nerozpoznanie rizika, má v mnohých prípadoch za následok úplné ukončenie projektu. Medzi najhoršie riziká v projekte patrí riziko, s ktorým sa nepočíta. Napriek tomu, že v mnohých projektoch sa tento druh rizika vyskytuje, nekončia všetky projekty neúspešne. Nevyhnutný proces softvérového projektu je manažment rizík. Esej poskytuje základný pohľad na manažment rizík a jeho jednotlivé fázy. Bližšie sa venuje dvom fázam, a to fáze analýzy a fáze plánovania. Esej sa ďalej zaoberá analýzou rizika v snahe odpovedať na otázku, čo je potrebné urobiť preto, aby sme rizikový projekt dostali pod kontrolu tak, aby sme minimalizovali dopad a zhmotnenie rizika. Esej sa rovnako snaží upozorniť na najväčšie riziká spojené s vývojom softvéru získané na základe štúdie.

Abstrakt:Monitorovanie projektu poskytuje informačnú základňu neoceniteľnú pri plánovaní a riadení projektu. Softvérové metriky sú jeho matematickou bázou. Existuje veľa nástrojov na monitorovanie, analýzu a vizualizáciu vývoja projektu. Za účelom komplexnej analýzy a predikcie sa spája monitorovanie zmien v projekte s monitorovaním aktivít členov tímu. Firmy dnes majú k dispozícii kamerové systémy a iné prostriedky, ktoré môžu byť použité na sledovanie zamestnancov a ich sociálnych sietí. Esej predstavuje úvod do témy monitorovania softvérového projektu a tiež pojednáva o pozitívnych a negatívnych aspektoch monitorovania softvérového projektu a projektového tímu, od benevolentného prístupu až po kontrolu myšlienok nie nepodobnú praktikám totalitného režimu. Nastoľuje sa otázka, aká je efektívna miera paranoje pri monitorovaní projektu.

Abstrakt:Každý človek je jedinečná a nezameniteľná osobnosť, odlišná od všetkých ostatných ľudí. Táto vysoká diferenciácia je nemalým problémom, ktorý nám bráni dopracovať sa k všeobecne platnej odpovedi na otázku, aké vlastnosti alebo osobnostné predpoklady tvoria osobnosť, a akými spôsobmi či metódami tieto vlastnosti spoznáme. Pri alokácii ľudských zdrojov a vytváraní tímových skupín, na softvérovom projekte, sa zo strany manažmentu často krát neberie v úvahu iné, ako odborné zaradenie. Má z pohľadu manažmentu význam poznanie osobnosti pri tvorbe tímu? Ako vysvetliť rozdiely v reakciách medzi jednotlivými členmi tímu? Existujú stále vlastnosti osobnosti? V tejto eseji sa na všetky tieto otázky pokúsime zodpovedať, pričom budeme vychádzať najmä z vlastných, osobných skúseností. Niektoré tvrdenia podložíme aj výskumom, ktorý sa v danej oblasti uskutočnil a sledoval vplyv osobnostných charakteristík na prácu v tíme z rôznych uhlov pohľadu.

Abstrakt:Komunikácia má v tíme nepochybne nezastupiteľné miesto. Spôsobov tímovej komunikácie existuje veľmi veľa, no existuje niekoľko foriem, ktoré sú často používané, len nie vždy korektne a tým sa znižuje ich efektívnosť. V tejto eseji sa predovšetkým zaoberám spätnou väzbou v tíme, ktorá je veľmi dôležitá pre správnu motiváciu a kritiku členov tímu, no ak je nesprávne využívaná môže pôsobiť kontraproduktívne. Ďalšou časťou eseje je brainstorming, ktorý je v súčasnosti často využívanou metódou k tvorbe nových nápadov. V rámci brainstormingu je nevyhnutné dodržiavať niekoľko zásad, ktorým sa taktiež venujem v mojej eseji. Na záver mojej eseje sa vnáram do problematiky problémov v komunikácii a ich riešenia. Nezvládnutá komunikácia v tíme môže mať za následok neexistenciu spolupráce v tíme a tým aj oneskorené, no v niektorých prípadoch neúspešné ukončenie projektu.

Abstrakt:Pri riadení softvérového projektu dochádza z pravidla k viacerým problémom. Väčšina softvérových projektov končí neúspechom, mnohé projekty sú kompletne zrušené. Práve neefektívny manažment projektov je udávaný ako najzávažnejší dôvod prispievajúci k týmto zlyhaniam. Podporné nástroje pre riadenie softvérových projektov môžu do veľkej miery uľahčiť manažérom proces sledovania a riadenia. Esej sa zaoberá najmä možnosťami sledovania pridelených úloh v tíme za pomoci podporných nástrojov pre riadenie projektu. Vývoj softvérového systému v tíme je kolaboratívna aktivita, ktorá si vyžaduje, aby boli úlohy a ľudské zdroje nepretržite prerozdeľované, a to pokiaľ možno čo najefektívnejším spôsobom. Použitie podporných nástrojov na tento účel môže projektovému manažérovi značne zjednodušiť prácu. V určitých prípadoch však ich použitie prináša nové riziká a problémy, ktorými sa esej tiež zaoberá.

Abstrakt:Správny odhad softvérového projektu je dobrým predpokladom pre jeho úspešné ukončenie, najmä ak sa jedná o rozsiahlejší projekt. Základom je správne odhadnúť jeho rozmer, teda jeho veľkosť, od ktorej sa odvíja množstvo vynaložených ľudských zdrojov potrebných pre jeho zvládnutie, celkový čas potrebný na jeho dokončenie a v konečnom dôsledku jeho cena. Na určenie rozsahu projektu sa vymysleli rôzne metriky, pomocou ktorých by sme ho dokázali exaktne zmerať a mohli navzájom rôzne projekty porovnávať. V eseji zhodnocujem, či má stále zmysel odhadovať rozsah projektu dlhoročne používanou metrikou - počet riadkov kódu a či by nebolo vhodnejšie zamerať sa na jej alternatívy. Rozoberám nedostatky odhadu pomocou spomenutej metriky a prečo už dnes nemusí byť taká spoľahlivá ako v minulosti.

Abstrakt:V súčasnosti na trhu pôsobí mnoho firiem, ktoré vytvárajú veľké množstvo rôzneho softvéru. Každá firma sa snaží vytvoriť taký softvér, s ktorým by bol zákazník spokojný. Zákazníci chcú kvalitný softvér, no často sa však stáva, že s kvalitou zákazníci až tak spokojní nie sú. Táto nespokojnosť so sebou prináša aj stratu drahocenného času, nové investície, stratu zisku. V eseji sa uvažuje nad tým, ako sa dá táto nespokojnosť zákazníkov minimalizovať. Je tu niekoľko rád, ako postupovať pri tvorbe kvalitného softvéru, ako ho testovať. V eseji sa uvažuje taktiež nad dôležitosťou kvality softvéru a efektívneho testovania, ktoré by odhalilo čo najviac chýb a taktiež by preukázalo požadované vlastnosti softvéru.

Abstrakt:Analýza a plánovanie rizík sa stali časom dôležitou súčasťou cyklu vývoja softvérového produktu. Čím je projekt zložitejší, tým je potrebné klásť väčší dôraz na analýzu rizík. Na druhej stranu, pri jednoduchých projektoch je takáto analýza zväčša kontraproduktívna. My sa sústredíme na analýzu rizík z pohľadu ľudských zdrojov, rizika navýšenia nákladov a rizika neúspešnosti samotného projektu, pri nasadení najnovších nástrojov a technológií pri vývoji softvérového produktu. Nasadením najnovších technológií vznikajú nové problémy a otázky či už z pohľadu architekta systému, bezpečnostného analytika, ale aj pohľadu biznis manažérov ako možnosti potenciálneho objektu záujmu.

Abstrakt:Monitorovanie v softvérovom projekte môže zavčas odhaliť riziká ohrozujúce proces tvorby softvéru. Či sa jedná o dosiahnutie cieľa, plnenie plánu alebo splnenie požiadaviek, techniky monitorovania indikujú príznaky, vlastnosti procesu tvorby softvéru a jeho častí. V závislosti od povahy a rozsahu indikovaných príznakov môžeme predpokladať prítomnosť alebo neprítomnosť menej alebo viac vážneho rizika softvérového projektu. Riziko je buď odstrániteľné alebo minimalizovateľné zmenami, neodstrániteľné, alebo časom zanikne samo o sebe. Je potrebné vedieť, o aké riziko ide. Riziká väčšinou priamo vyplývajú z príznaku zachyteného procesom monitorovania. Vedieť však o prítomnosti rizika nestačí. Zmeny vedúce k odstráneniu rizika, či už samotná otázka riešiteľnosti rizika či krízy sú kľúčové, ak chceme zaručiť úspech softvérového projektu. Táto esej sa zaoberá procesom odhaľovania a riešenia krízových stavov a rizík, a dôležitosťou komunikácie ako efektívneho prostriedku pri tomto procese. Táto komunikácia a jej vlastnosti vyplývajú z povahy a vážnosti rizika, a je aj prostriedkom pri odhaľovaní príčin rizika. Na základe zistenej príčiny alebo príčin sa dozvieme odpoveď na otázku riešiteľnosti problému a môžeme vykonať potrebné, primerané zmeny a tým zabezpečiť plynulosť a bezpečnosť softvérového projektu.

Abstrakt:Cieľom tejto práce je ukázať rozdelenie členov tímu podľa ich osobností, poukázať na problematické charakterové črty a načrtnúť riešenie problémov spojených s týmito charakterovými črtami. Rozdelenie osobností vychádza z Myers-Briggsovej typológie osobnosti a použitia tejto schémy na rozdelenie úloh v tíme s dôrazom na vývoj softvéru. Na základe tohto rozdelenia budú pre jednotlivé úlohy v tíme a pre celkové pôsobenie v tíme identifikované problematické typy osobností respektíve zodpovedajúcich charakterových čŕt a pre tieto budú následne navrhnuté a analyzované vhodné riešenia. Tieto riešenia vychádzajú z autorových osobných skúseností s pracou v tíme a z výsledkov dotazníku ktorý bol rozoslaný skupine profesionálov pôsobiacich v oblasti vývoja softvéru. Nadpis „Kto bude nosiť kávu?“ je analógiou pre jedno z týchto riešení a to zadávať problematickým členom tímu úlohy ktoré nie sú kritické pre úspešné dokončenie projektu alebo fungovanie tímu.