Zbierka esejí 2013
Home Home EN
"riziká"
Bado Dávid

Abstrakt. V súčasnej dobe veľké percento IT projektov zlyháva. Preto sa veľa ľudí snaží skúmať a odhaľovať príčiny týchto zlyhaní. Výskum ukazuje, že jeden z hlavných dôvodov zlyhania softvérových projektov je nedostatočná účasť zákazníka na projekte. Esej hovorí o tom, prečo je dôležité, aby zákazník softvérový projekt monitoroval. Poukazuje na to, že tradičný vývoj softvéru tento trend nepodporuje a dokonca kladie zákazníkovi pri monitorovaní prekážky. Naopak agilné metódy zákazníka podporujú v tom, aby projekt monitoroval a aby sa na ňom podieľal. Esej apeluje na zákazníka, aby si uvedomil, že výberom metódy vývoja a svojou účasťou môže zmenšiť riziko zlyhania projektu.


Danada Ondrej

Abstrakt. Organizácie tretieho sektora majú často veľmi obmedzený rozpočet, a preto sú nútené realizovať svoje softvérové projekty vo vlastnej réžii. Tieto typy projektov majú svoje špecifické charakteristiky, a preto sa s ich prípravou a realizáciou spájajú trochu odlišné riziká ako v komerčných projektoch profesionálov. Cieľom tejto eseje je identifikovať a stručne opísať tieto charakteristiky a porovnať riziká s rizikami bežných softvérových projektov. Za najväčšie riziko možno pomerne jednoznačne považovať nedostatok personálu, ktoré hrozí vo zvýšenej miere a jeho dopady sú horšie ako pri iných typoch projektov. Možnosti predchádzania tejto hrozbe sú taktiež obmedzené a treba siahnuť po iných riešeniach. Niektoré riziká sú však vďaka určitým charakteristikám ako napríklad dobrá znalosť domény skôr zanedbateľné a hrozba, že nastanú, je minimálna.


Lihocký Michal

Abstrakt. Manažment rizík je činnosť, ktorá napriek tomu, že je všeobecne vnímaná za dôležitú, je často vykonávaná len v minimálnej miere či dokonca vôbec, čo predstavuje problém, ktorý je predmetom tejto eseje. Čo teda predstavuje prekážku pri zavádzaní manažmentu rizík do vývoja? S akými ďalšími problémami sa pri vykonávaní manažmentu rizík môžeme stretnúť? Aké sú najčastejšie riziká pri vývoji softvérových projektov? Na čo sa oplatí zamerať? Existuje nejaký prístup či metóda, ktoré sa javia byť riešením spomínaných problémov? Je takýto prístup použiteľný aj v našom projekte v rámci predmetu Tímový projekt? Práve nad týmito otázkami som sa pokúsil zamyslieť v tejto eseji.


Left Separator
plán rozvrh komunikácia softvérový projekt tím monitorovanie agilný vývoj zákazník riziká riziko Scrum plánovanie manažment rizík manažment verzií manažment nevýhody kvalita softvér extrémne programovanie párové programovanie motivácia úspech podporné prostriedky správa verzií manažment kvality dokumentácia agilné metódy vývoj softvéru úlohy softvérové metriky tímový projekt manažment dokumentácie projekt metriky vodopádový model manuál príručka podpora vývoja malé tímy použiteľnosť testovanie kvalita softvéru podporné nástroje manažment podpory vývoja konfigurácia softvéru kontrola kvality verziovací systém efektívnosť agilné metódy vývoja