Zborník esejí 2011

Abstrakt:Vývoj softvéru má svoje špecifiká. V máloktorom odvetví sa vyskytuje také vysoké percento neúspešných projektov (štúdie uvádzajú viac ako 50%) a iba pomerne malá časť projektov (približne 16%) je dokončená v dohodnutom termíne a bez prekročenia rozpočtu. Tieto čísla sa môžu zlepšiť aj používaním nástrojov na sledovanie úloh. Umožňujú lepšiu kontrolu stavu práce na projekte a sledovanie vyťaženosti ľudských zdrojov a týmto pomáhajú napr. lepšie reagovať na prípadné zmeny v plánoch. V eseji sa zameriavam na porovnanie formálneho sledovania úloh pomocou systému na sledovanie úloh a neformálneho používaním anotácii v zdrojovom kóde. Opisujem aké sú výhody formálneho prístupu k sledovaniu úloh, ktoré výhody ponúka a aké nevýhody prináša. Venujem sa úlohe neformálneho sledovania úloh ako indikátora stavu projektu a vhodný doplnkový spôsob sledovania úloh pre vývojárov. Analyzujem nakoľko je vhodné a nutné sledovanie úloh formalizovať a dôsledky takéhoto nastavenia.

Abstrakt:Vo vývoji a údržbe softvérového produktu je dôležitým aspektom správa a udržovanie mnohých verzií a konfigurácií produktu. V mojej eseji sa budem venovať práve systémami na správu verzií, ktorými možno udržovať stav zdrojových kódov, dokumentácie a testovacích dát v rôznych štádiach, čím sa akceleruje a zjednoduší celý proces vývoja softvéru. V eseji sa hlavne venujem otázkam prečo je tak dôležité verzionovať softvérový produkt, akými spôsobmi toto dosiahnuť, a ktoré sú podľa môjho názoru najlepšie systémy pre správu verzií na základe vlastných skúseností. Tiež popíšem môj pohľad na hlavné výhody a nevýhody centralizovaných systémov oproti distribuovaným systémom pre správu verzií.

Abstrakt:Ako tak plynie čas, ľudstvo stojí stále pred novými a novými výzvami, ktoré naberajú na komplexnosti. Riešenie stále zložitejších problémov je odkázané nielen na úsilie jednotlivca ale najmä aj na úsilie kolektívu. Práca v kolektíve môže byť efektívna najmä pri správnej výmene informácií medzi jednotlivými členmi. Lenže ako takúto kominikáciu organizovať? Aké sú jednotlivé formy prenášania informácií a aké majú výhody a nevýhody? Kedy sú jednotlivé formy dostatočne efektíne a majú v danej chvíli aj skutočne vzdelávací charakter? Práve hľadanie odpovedí na tieto otázky bude predmetom tejto eseje.

Abstrakt:Testovanie softvéru sa nemusí vykonať až po naprogramovaní zdrojového kódu. S príchodom agilného spôsobu vývoja softvéru a extrémneho programovania sa testovanie presunulo z posledných fáz vývoja softvéru na popredné fázy. Testovanie softvéru dostalo ďalšie kompetencie v podobe určovania vlastností kódu a smerovania vývoja malých časti kódu. Hlavnú otázku, ktorú sa snažím v eseji zodpovedať je, do akej miery je vhodné použiť testami riadený vývoj v tímovom projekte. Veľkú časť vedomostí čerpám z prieskumov, ktoré boli zrealizované na amerických renomovaných univerzitách a tým sa aspoň z časti približujem k podmienkam, ktoré máme my na univerzite. Teoretická časť eseje sa zameriava na popis fungovania testami riadeného vývoja.

Abstrakt:Ako najlepšie vyberať a rozdeľovať úlohy v tíme? Ako výrazne vplýva osobnosť človeka na prideľovanie tém? Pri zostavovaní tímu sa treba zamyslieť nielen nad odbornosťou jednotlivých členov, ale treba zohľadniť aj ich osobnostné črty. Každý jedinec má svoju vlastnú osobnosť, ktorá sa môže prejaviť v pozitívnom ale aj v negatívnom svetle. Osobnosť človeka hrá dôležitú rolu, nielen pri samotnom personálnom obsadení do tímu, ale aj pri rozdelení úloh v tíme. V eseji sa zamyslím nad výsledkami Myers-Briggsovej indikátora typov (MBTI) pre náš tím a pokúsim sa odhadnúť, ktoré úlohy sa komu najviac hodia na základe jeho osobnosti. Taktiež sa zamyslím, ktoré úlohy sa jednotlivým členom tímu neodporúča dávať.

Abstrakt:Zlyhanie softvérového projektu je aj v dnešnej dobe, v ktorej sa projekty precízne plánujú do najmenších detailov, prekvapivo bežná záležitosť. Prekvapenie, či neočakávaná udalosť dokážu v momente zastaviť alebo aj celkom zrušiť zatiaľ bezchybný vývoj softvéru. Jedným slovom - riziko. Čo sú to vlastne riziká? Riziká sú jedným z hlavných problémov pri vývoji softvéru, preto je ich potrebné identifikovať v čo najskorších fázach vývoja, keď nám v podstate ešte nespôsobia žiadne problémy. V prvej fáze, ktorou je identifikácia rizík, zohrávajú nezastupiteľnú úlohu špecializované softvéry pre simulovanie rizík, rizikových faktorov v projekte a ich vplyvu na priebeh vývoja a úspešnosť samotného projektu. Dokážu podporné softvérové prostriedky identifikovať zložitejšie riziká? Nie je celá simulácia len zbytočná strata času?

Abstrakt:Dá sa na základe osobnostného testovania vytvoriť tím, ktorý bude vykazovať čo najlepšie výsledky, ideálny tím, tím zložený z osobností, ktoré sa budú navzájom dopĺňať a popritom minimalizujú riziko neúspechu? Množstve ľudí zodpovedných za výsledky v tímoch by toto poznanie pomohlo, pomohlo by im, pokiaľ by sa dalo dopredu určiť, aké má tím vyhliadky na úspech. V dnešnej dobe vývoj softvéru nie je už iba o programovaní, ale stále viac o efektívnej komunikácii a spolupráci ľudí. Testovanie osobnosti by mohlo pomôcť k úspechu tímu, ale akým spôsobom analyzovať výsledky osobnostných testov? Predstavím metódu Meyers-Briggs Type Indicator (MBTI), zamerám sa aj na výsledky testovania menších tímov. Otestoval som môj tím v rámci tímového projektu a zhodnotím, aké sú šance z hľadiska celkového zloženia, ale aj rozloženia rolí na jednotlivých členov. Zhodnotím výsledky pozorovaní.

Abstrakt:Slovo risk bude neustále predstavovať neistotu a nie vždy sa musí vyplatiť. Pri vytváraní softvérových produktov sa riskovanie určite nevypláca a v niektorých prípadoch spôsobuje katastrofálne následky. Úlohou manažmentu rizík je minimalizovať straty a to spôsobom, kedy sa vopred identifikujú potenciálne riziká, s ktorými sa môžeme stretnúť počas procesu vytvárania produktu. Takýmto prístupom je možné problémom predchádzať a zabezpečiť vytvorenie finálneho produktu s plnou funkcionalitou v stanovenom termíne. Na tieto účely sa neustále navrhujú rôzne postupy a nástroje, ktorých úlohou je pomáhať pri riadení rizík. Dajú sa však riziká riadiť efektívne? Do akej miery majú vplyv na výsledok projektu? Najmä tieto otázky sa budeme snažiť dostatočne presne zodpovedať. Problematika ohľadne riadenia rizík leží prevažne na pleciach manažérov a existuje len zopár spôsobov, ako sa s ňou úspešne popasovať.

Abstrakt:„Aká práca taká pláca.“ Platilo kedysi a platí až dodnes. Daný fakt platí asi dvojnásobne v softvérovom inžinierstve, kde sa kvalite a manažmentu kvality prikladá obzvlášť veľký dôraz. Pretože bez ohľadu na to, aké elegantné metódy sú použité na testovanie finálneho produktu, aká kompletná je dokumentácia, či ako štruktúrované sú metodológia, vývojové plány, projektové hodnotenia, rekapitulácie, ... všetko to vyjde na nivoč a projekt zlyhá, ak manažment kvality nie je efektívny. Najfrekventovanejšou normou, ktorá sa používa na zavedenie efektívneho manažmentu kvality do firemnej kultúry je norma z rodiny ISO 9000 pre manažment kvality softvéru. V tejto práci si položíme niekoľko otázok, ktoré sa nad ňou budú niesť a ktoré si pokúsime v je závere zodpovedať. Samozrejme hlavnou otázkou je prínos normy ISO pre firmy, t.j. či sa jedná o plnohodnotné zlepšenie firemného procesu výroby alebo ISO predstavuje iba značku, bez ktorej vás už neakceptujú ako rovnocenného partnera.

Abstrakt:Jadrom eseje sú systémy, ktoré slúžia ako komunikácia medzi zadávateľmi chýb a príslušnými vývojármi daného produktu – systémy na sledovanie chýb. V eseji sa venujem výberu správneho spôsobu zadávania chýb do systému na sledovanie chýb. Predstavme si situáciu, že niekto zadal do nášho systému novú chybu. Ak túto chybu zadal príliš rozvláčne, zodpovedný človek strávi veľa času čítaním a pochopením, o čo vlastne ide. Ak však tento človek popíše danú chybu príliš stručne, môže sa stať, že v popise nebude dostatok informácií k odhaleniu a náprave chyby. Táto esej sa teda zaoberá otázkami „Ako presne definovať chybu?“ a „Ako čo najzrozumiteľnejšie a najpresnejšie zapísať chybu?“. Vo veľkých projektoch je navyše potrebné vytvoriť štandard, alebo vzor zadávania chýb. Takto každý vie, čo čakať v danej správe o chybe. Týmto sa minimalizuje čas riešenia chýb.

Abstrakt:Pre úspech akéhokoľvek softvérového projektu je veľmi dôležité, aby bol správne plánovaný. Efektívne plánovanie vyžaduje poznanie jednotlivých častí projektu a ich nárokov na zdroje. Najdôležitejším zdrojom vo väčšine softvérových projektov sú kvalifikovaní pracovníci, a preto treba všetky časti projektu medzi nich vhodne rozdeľovať. Pre tento účel je potrebné na začiatku, ale aj v priebehu celého projektu dokázať odhadnúť približnú dobu riešenia s dostupnými zdrojmi. V súčasnosti existuje viacero rôznych metód, na základe ktorých je možné takéto odhady vykonávať. Aké sú ich výhody a nevýhody? Kedy je vhodné ich použiť? V tejto eseji sa pozriem na niekoľko odlišných prístupov, ktoré je možné použiť pre odhad vyžadovaného úsilia a pokúsim sa zhodnotiť ich prínos pre plánovanie projektu.