Zborník esejí 2010

Abstrakt:Podporné prostriedky pre softvérové projekty by mali slúžiť na zefektívnenie alebo priamu podporu manažmentu týchto projektov a vývoja softvéru. Avšak, príliš veľké očakávania na ich prínos môžu viesť k značným problémom pre celý projekt. Toto sa ukazuje ako veľký problém v prostrediach, kde boli doposiaľ používané vo veľmi malej miere, alebo v tom horšom prípade – neboli používané vôbec. Táto esej pojednáva o základnom prehľade podporných prostriedkov. Ďalej uvádza vyskytujúcu sa problematiku zavádzania a používania softvérových podporných prostriedkov vzhľadom na vysoké a mylné očakávania niektorých manažérov a vývojárov. V závere je na príklade Ganttových diagramov poukázané na významný prínos podporných prostriedkov pre riadenie a riešenie projektu.

Abstrakt:Súčasťou plánovania softvérového projektu je zostavenie dobrého tímu a rozdelenie úloh členom tímu. Na kvalite finálneho produktu sa podieľajú rovnakou mierou osobnostné vlastnosti členov tímu, ako aj ich skúsenosti a schopnosti. Pre manažérov nie je možné v mnohých prípadoch zostaviť tím iba z ľudí špecializujúcich sa v problémovej oblasti softvérového projektu, a preto musia využiť zamestnancov, ktorí nemajú takéto skúsenosti. Týmto vzniká otázka, či je potrebné za každú cenu vyhľadávať ľudí, ktorí sa v danej oblasti vyznajú, skombinovať expertov s ľuďmi, čo sa dokážu rýchlo učiť a prispôsobiť, alebo vybrať na projekt iba ľudí, ktorí sú flexibilní. Esej sa zaoberá vplyvom skúseností členov tímu na celkový tímový výkon a od toho odvodený vplyv schopností tímu ako celku na kvalitu finálneho softvérového produktu. Okrem toho popisuje fungovanie distribuovaného projektu ako celku a faktory, ktoré sa musia brať do úvahy a sú špecifické pre distribuovaný vývoj. Základné skúsenosti však musia získať členovia projektových tímov počas vzdelávania a v týchto prípadoch simuluje reálne prostredie a podmienky inštruktor tímu.

Abstrakt:V dnešnej dobe elektronického obchodovania môže nedostatočná kvalita webových systémov nepriaznivo ovplyvniť ziskovosť podnikov, ktoré sú závislé od týchto systémov. Preto efektívne techniky testovania výkonnosti webových systémov sú nevyhnutné pre zistenie, či daný systém spĺňa výkonnostné požiadavky pre jeho nasadenie do komerčnej prevádzky. Výkonnosť webových systémov závisí od rozličných parametrov, a tak každý jeden parameter musí byť otestovaný s rôznou úrovňou zaťaženia. Kvôli komplexnosti systémov nie je možné tieto parametre všeobecne použiť na ich otestovanie. Samotný systém sa musí rozdeliť na mnoho častí, ktoré reprezentujú rôzne biznis komponenty, a tie sa potom testujú pre niektoré parametre. Samotné pracovné zaťaženie systému musí byť charakterizované ako sekvencia medzi sebou závislých požiadaviek od jedného používateľa. Závislosti vzniknú tým, že niektoré požiadavky závisia od odpovedí na predchádzajúce požiadavky v jednej relácii. Pri testovaní systémov sa tieto závislosti musia zohľadniť. Zaoberám sa riešením tejto problematiky, a to tvorbu aplikačných modelov, pomocou ktorých je možné skúmať a modelovať závislosti jednotlivých komponentov systémov.

Abstrakt:Pojem rizika pri vývoji softvéru pozná snáď každý projektový manažér. Čo sa však líši od jedného manažéra k druhému, je pohľad, s akým sa na toto riziko pozerá a prístup, ktorým sa k riziku stavia. Niektorí analýzu rizika a jeho manažment nevykonávajú, iní venujú týmto dvom činnostiam podstatnú pozornosť s použitím rôznych podporných softvérových nástrojov. Riziko sa odstrániť nedá, avšak jeho zníženie je dôležitou súčasťou agendy každého uvedomelého projektového manažéra, či už k jeho znižovaniu pristupuje podvedome a na základe dlhoročných skúseností, alebo analyticky s dôkladným plánovaním a prípravou. V každom prípade je riziko závislé tak na technických záležitostiach ako aj, a často vo väčšej miere, na ľudskom faktore, ktorý do projektu vnáša každý člen tímu, od programátorov, cez analytikov až po projektového manažéra, ktorý musí svojimi skúsenosťami a nadhľadom pomáhať všetkým zapojeným členom projektového tímu. Zameraním tejto eseje je poukázať na ľudský faktor pri analýze a manažovaní rizika a na to, že správny úsudok skúseného projektového manažéra má niekedy, ale nie vždy, väčšiu cenu ako dlhá analýza spolu s použitím podporného softvéru na plánovanie riadenia rizík.

Abstrakt:Životný cyklus vývoja softvérového projektu prebieha vždy v niekoľkých etapách alebo cykloch. Pri každom kroku vývoja je preto potrebné manažovať exitujúce zdrojové súbory a dokumenty, ktoré sa pri procese tvorby systému používajú. Je potrebné uchovávať tieto súbory tak, aby bolo možné riešiť prípadné kolízie, vrátiť sa k predošlým verziám projektu, alebo monitorovať priebeh celého procesu. Na uľahčenie tejto práce sa v posledných dvoch dekádach používajú systémy pre manažment verzií a zmien v projektoch. V tejto eseji sa zaoberám popisom týchto systémov, spôsobom ich použitia a výhodami, ktoré prinášajú vývojárom pri práci a komunikácií v rámci tímu. Zároveň však poukazujem aj na problémové situácie, ktoré môžu nastať pri ich používaní.

Abstrakt:Úspech softvérového projektu závisí do veľkej miery predovšetkým od kvality tímu. V záujme dosiahnutia dobrých výsledkov tímy používajú množstvo nástrojov uľahčujúcich prácu na projekte a metód koordinácie ľudí. Je tu však ďalší dôležitý aspekt efektívneho fungovania tímu a to sú zdravé medziľudské vzťahy. Táto esej by sa chcela zamerať na medziľudské vzťahy v tíme z pohľadu jednotlivých typov osobností, ako ich charakterizuje test MBTI (Myers-Briggs Type Indicator), na čo sú jednotlivé typy osobností vhodné a v čom spočívajú riziká. Taktiež sa budeme zaoberať osobou tímového lídra z pohľadu toho, ktoré typy osobností sú vhodné na túto úlohu a ako má líder vplývať na ľudí, aby ich motivoval, predchádzal konfliktom v tíme a vzniknuté konflikty zručne rieši.

Abstrakt:Táto esej podáva návrh ako vhodne plánovať tak, aby výsledný projekt bol ukončený úspešne a načas. Najskôr sa venujem plánu ako celku, načo je vlastne dobrý, kvôli čomu sa oplatí vytvárať a používať ho pri tvorbe projektu. V hlavnej časti dokumentu sa venujem vytváraniu plánu. Rozoberám jednotlivé kroky a vysvetľujem, ako pri nich postupovať. Väčšinou vysvetľujem postup plánovania na projekte typu bakalárskej práce, ale miestami poukazujem na odlišnosti s tímovým projektom. Rozoberám celý proces časového manažmentu a porovnávam, aký majú význam jednotlivé kroky. Upozorňujem na najčastejšie chyby pri tvorbe plánov a snažím sa poskytnúť cenné rady, ktoré pomôžu vyvarovať sa im pri tvorbe plánov. Na záver odpovedám na otázku v nadpise, zdôvodňujem svoju odpoveď a zhodnocujem celkový prínos plánovania v projekte.

Abstrakt:Zákazníkovi pri kúpe softvérového produktu ide hlavne o to, aby tento fungoval správne a umožnil mu tak bez problémov vykonať všetko čo potrebuje. Softvér pred jeho vypustením firmy testujú, aby sa zabezpečila čo možno najväčšia správnosť. Ako je potom možné, že sa pri jeho používaní objavujú chyby? V tejto eseji uvádzam niekoľko príčin, ktoré často vedú k zlyhaniu celého procesu testovania. Obvykle ide hlavne o zanedbanie testovacej fázy pri vývoji či jej skrátenie kvôli blížiacemu sa termínu, ďalej príprava testov na poslednú chvíľu alebo zlý výber testovacích vstupov. Keďže jasné riešenia úplne všetkých problémov s prípravou a plánovaním testov neexistujú, uvádzam určité odporúčania, ktoré by mali pomôcť zefektívniť proces testovania.

Abstrakt:Napriek veľkému počtu podporných nástrojov v sebe vývoj softvéru stále zahŕňa riziká, ktorých zvládnutie je nevyhnutné pre úspešné dokončenie projektu. Oblasť riadenia rizík dnes disponuje množstvom rozdielnych postupov na ich identifikáciu a riešenie. V tejto eseji stručne zhrnieme spôsoby delenia rizík a relatívne dôležitosti jednotlivých typov v procese vzniku softvéru. Zameriame sa na holistický pohľad, ktorý neposudzuje jednotlivé kategórie rizík nezávisle, ale zaoberá sa aj ich vzájomnými podobnosťami a vzťahmi. Ďalej sa budeme venovať najčastejším problémom, ktoré sa v súvislosti s riadením rizík vyskytujú, hlavne v spojení s ľudským faktorom.

Abstrakt:Tak, ako potrebuje správca počítačovej siete kontrolovať jej stav a prevádzku, tak potrebuje manažér softvérového projektu monitorovať stav softvérového produktu a podľa toho vhodne navrhnúť, prípadne načasovať zmeny plánu, ktoré povedú k požadovanému cieľu projektu. V mojej eseji sa zaoberám vhodnými technikami monitorovania, ich porovnaním a taktiež niektorými nástrojmi, ktoré môžu použiť manažéri, ktorí chcú mať dohľad nad priebehom projektu. Okrem toho sa v eseji zamýšľam nad samotnou potrebou monitorovania a ponúkam svoj pohľad na to, ako často a v akej miere je vhodné pre manažéra monitorovať projekt a jeho súčasti, a tiež to, aké nástroje pri tom použiť s ohľadom na rozsiahlosť projektu. Esej je profilovaná čiastočne pre potreby projektu menšieho rozsahu, ako je napríklad projekt na predmete Tímový projekt.

Abstrakt:Hovorí sa koľko ľudí, toľko chutí. No neplatí to len pri stravovaní, ale môžeme to rozšíriť aj na všeobecnú rovinu. Skutočne, každý človek je iný, má odlišné správanie a zvyklosti. Aj keď môžeme namietať, že existuje v populácii veľa jedincov, ktorí vykazujú podobné správanie, vždy sa nájdu medzi nimi isté odlišnosti. Tieto odlišnosti sú tvorené rôznorodosťou vlastností každého človeka. A práve poznanie našich vlastností nám umožňuje odhadnúť, pre akú činnosť sme viac či menej vhodní. Inak tomu nie je ani v rámci tímu spolupracovníkov. Keď poznáme silné a slabé stránky každého člena tímu, môžeme efektívnejšie rozdeliť úlohy a zodpovednosti medzi jednotlivých členov. Podľa Myers-Briggsovej typového indikátoru (Myers-Briggs Type Indicator, MBTI) dokážeme rozdeliť osobnosti do šestnástich skupín. Jednotlivé typové skupiny sú predurčené podľa MBTI na určitú pracovnú pozíciu. Pomocou tejto metódy sa pokúsime rozdeliť členov nášho tímu na jednotlivé pozície, aby sa tak zefektívnila spolupráca.

Abstrakt:Riadenie softvérového projektu je neľahká úloha, dokonca aj pri projektoch menšieho rozsahu. Úspech či neúspech takéhoto projektu závisí od toho, ako sa manažér dokáže s touto úlohou vysporiadať. K tomu mu môžu pomôcť rôzne podporné prostriedky slúžiace na monitorovanie stavu úloh, rozdeľovanie ľudských zdrojov a iné funkcie súvisiace s riadením projektu. Neslúžia len pre manažéra, ale aj pre samotných členov tímu, zefektívňujú a sprehľadňujú prácu na projekte. Avšak použitie nesprávne zvoleného nástroja môže mať práve opačný účinok. Na trhu je dnes veľké množstvo podporných prostriedkov a vybrať ten správny nemusí byť vôbec jednoduché. V tejto eseji sa čitateľ dozvie, aké podporné prostriedky sa dnes využívajú, ktoré z nich sú vhodné pre projekty menšieho rozsahu, a či je vôbec treba tieto nástroje používať v malom tíme.

Abstrakt:Pri realizovaní úspešného projektu v dnešnej dobe zohráva významnú úlohu jeho riadenie. To v sebe zahŕňa prvotné naplánovanie celého projektu, rozdelenie úloh, monitorovanie ich plnenia, prípadné preplánovania a v neposlednej rade správne využitie ľudských zdrojov. Celý tento proces riadenia je do veľkej miery veľmi závislý na počte ľudí, ktorých môže vo svojich plánoch projektový manažér použiť pre dosiahnutie vytýčeného cieľa. Táto esej sa zaoberá metódami a potrebou plánovania ľudských zdrojov, správneho rozdelenia úloh a rovnomerného využitia všetkých členov tímu. V eseji sa ďalej zamýšľame nad tým, ako vďaka plánovaniu ľudských zdrojov obmedziť ich preťaženiu. Esej taktiež ponúka riešenia, s ktorými je možné zvládnuť nepredvídané preťaženie zdrojov. Na záver sa esej zameriava na problémy spôsobené zlým plánovaním ľudských zdrojov, pretože práve problémy takéhoto druhu často vedú z pohľadu projektu k neriešiteľným situáciám.

Abstrakt:Z pohľadu zákazníkov je kvalita softvérového produktu priamo úmerná jeho funkcionalite. Na strane druhej, vývojári vnímajú kvalitu ako komplexnú množinu viacerých aspektov, napríklad aj prehľadnosť a efektívnosť kódu, pretože kvantita nezaručuje automaticky kvalitu. V súčasnosti existuje viacero metód, modelov a druhov testovania, ktoré by mali viesť k znižovaniu chybovosti vyvíjaného softvérového produktu a tým aj k zvyšovaniu jeho kvality. Spomeniem napríklad vývoj riadený testovaním, V-model, systémové testy, akceptačné testy a iné. Názory na ich efektívnosť sa rôznia, avšak dôležitosť testovania je dnes už nespochybniteľná. Aj samotné testovanie má však svoje úskalia. Je potrebné vedieť kedy, ako a čo testovať. Za týmto účelom tak ako pri samotnom vývoji softvérového produktu, tak aj pri testovaní existuje pojem plán. Cielom eseje je poskytnúť čitateľovi komplexnejší pohľad na spomínanú problematiku, zmapovať súčasnú situáciu a načrtnúť možné zlepšenia do budúcnosti.

Abstrakt:Riziko ako určitý druh problému nachádzame vo všetkých sférach života. Aj v softvérovom inžinierstve je jeho prítomnosť samozrejmosťou a nikdy sa mu nedá úplne vyhnúť. Identifikáciou, analyzovaním a riadením rizík v softvérových projektoch sa zaoberá manažment rizík. Tieto procesy predstavujú obranný mechanizmus proti situáciám, ktoré by mohli ohroziť prácu pri vývoji softvéru. Ich hlavnou úlohou je minimalizácia prípadných škôd, vyplývajúcich pri zhmotnení rizík. Úspešnosť projektu je teda závislá aj od spôsobov, akými vieme dostatočne zabrániť prípadným rizikám a eliminovať ich. Množstvo vyvíjaných projektov stroskotalo práve na podcenení hroziacich rizík. V nasledujúcich riadkoch sa pozriem na základné princípy manažmentu rizík. Vysvetlím hlavné procesy pri riadení rizík a ukážem základnú kategorizáciu. Hlavná časť tejto eseje je zameraná na opis najčastejšie sa objavujúcich rizikových situácií. Položím otázky, prečo tieto situácie nastávajú a akými prostriedkami a metódami je ich možné čo najefektívnejšie odstrániť.

Abstrakt:Analýza vytvorenej hodnoty (EVA) je metóda projektového manažmentu pre kontrolu priebehu projektu. Dva problémy však spôsobujú ťažkosti v aplikovaní tejto metódy na softvérové projekty. Prvým je otázka, ako dôsledne vyjadriť základné línie softvérového projektu a merať jeho technický vývoj. Druhý problém je zapríčinený štruktúrou delenia práce (WBS), ktorá napomáha rozdelením práce na elementy lepšej organizácii a kontrole vývoja, no nemôže zachytiť a odraziť prípadné softvérové zmeny vo vývoji. Táto esej najskôr približuje prístupy používané pri monitorovaní projektov – analýzu vytvorenej hodnoty, štruktúru rozdelenia práce a metódu bodov prípadov použitia (UCP). Následne sa zaoberá problematikou a riešením použitia analýzy vytvorenej hodnoty pri softvérových projektoch, prezentuje evolučnú štruktúru delenia práce zameranú na jednotlivé elementy softvérových procesov a opisuje prevzatie prípadov použitia (UCP) ako základných softvérových línií projektu, merania efektivity a výkonu. Práca v závere hodnotí prínos analýzy vytvorenej hodnoty v spojení s metódou bodov prípadov použitia do monitorovania vývoja softvérových projektov.

Abstrakt:Každý človek má svoje túžby a sny. Motivácia k nejakej činnosti sa zvyšuje s tým, do akej miery sú naplnené potreby jednotlivca. Vedúci projektu stojí pri tvorení a riadení tímu pred neľahkou úlohou - rozdeliť úlohy tak, aby práca na spoločnom cieli napĺňala potreby jednotlivých členov tímu. Analýza osobností mu môže s touto neľahkou úlohou pomôcť. Esej analyzuje dve známe teórie rozdelenia osobnostných typov. Prvou je najpopulárnejšia metóda podľa Hippokratovho rozdelenia, pri ktorej sú dobre známe silné a slabé stránky jednotlivých temperamentov, druhou je v praxi najpoužívanejšia metóda MBTI, pri ktorej sa možno oprieť o výsledky výskumu. Dôraz je kladený na rozdelenie úloh v softvérovom projekte a na to, do akej miery sú metódy analýzy efektívne pri vytváraní a riadení tímu. Cieľom eseje je kriticky zhodnotiť použitie týchto metód.