Participácia členov tímu na tvorbe plánu

Branišová Jana

Abstrakt. Esej sa bližšie zameriava na dôležitosť začlenenia ostatných členov tímu do rozhodovania o pláne projektu. Uvažuje sa v nej nad troma modelmi participácie tímu – diktátorský režim, hlasovanie a poradný orgán. Tieto modely mapuje na rôzne prostredia a snaží sa odpovedať na otázku, či je aplikácia modelov participácie závislá od prostredia, v ktorom tím pracuje. Ktorý z modelov dokáže priviesť projekt do úspešného konca? Pokúša sa zistiť, pre aké prostredie je najvhodnejší jeden z navrhnutých modelov participácie. Esej porovnáva vývoj tímového projektu v školskom prostredí a vývoj v prostredí firmy. Zamýšľa sa nad tým, ktorý model je vhodný pre statické, a ktorý pre dynamické prostredie.

Britvík Andrej

Abstrakt. Prieskumy ukazujú, že veľké množstvo softvérových projektov v súčasnosti zlyháva a ani v minulosti to nebolo inak. Niektoré projekty sú predražené, končia neskôr ako bolo dohodnuté, neponúkajú požadovanú funkcionalitu alebo sa vôbec nedokončia. Aj keď čísla hovoria, že sa postupne zlepšujeme a stále viac a viac projektov končí úspechom, nemusí to byť vždy pravda. Málo kto si totiž dobrovoľne prizná, že zlyhal. Na výsledok projektu vplýva veľké množstvo faktorov, ktoré sa snaží odhaliť manažment rizík a pokúša sa ich odstrániť ešte skôr, ako vôbec vzniknú. Existujú dlhé zoznamy známych rizík, ktoré sa dajú rozdeliť do mnohých kategórií, takže by nemal byť problém s identifikáciou rizík, ktoré hrozia projektu. Avšak aj v ideálnom prípade, kedy sa nájdu všetky riziká, nemusí byť zaručené, že projekt nezlyhá. V eseji sa snažím odhaliť skryté nebezpečenstvá manažmentu rizík, ktoré si ľudia možno ani neuvedomujú, ale môžu mať veľmi negatívny vplyv na výsledok projektu.

Kvalita v malom

Dupaľ Martin

Abstrakt. Kvalitný produkt je požadovaný v každom výstupe všetkých projektov. Na dosiahnutie kvalitného produktu existuje v dnešnej dobe veľa rôznych metód a ešte viac odborných prác, ktoré sa zaoberajú touto problematikou. Iba niekoľko z týchto odborných prác a metód počíta s tým, že produkt bude vyvíjať iba malý tím zložený z približne 7 ľudí. V tejto eseji budem rozoberať možnosti manažéra kvality pre malý tím, ktorý bude vyvíjať softvérový produkt. Presnejšie budem rozoberať projekt, ktorý bol zadaný môjmu tímu na predmete Tímový projekt (STU FIIT). Zameriam sa na povinnosti, možnosti a zodpovednosť manažéra kvality počas celého vývoja produktu, keďže kvalita neznamená iba nekonečné testovanie. Testovanie je len jedna z posledných povinností, ktorú musí manažér kvality zabezpečiť.

Dokumentácia nemusí byť len dokument

Dušek Martin

Abstrakt. Ku každému cieľu môže viesť viac ciest. Dnešná spoločnosť je celá riadená rôznymi softvérmi, informačnými systémami či technológiami, ktoré nám pomáhajú robiť veci efektívnejšie, rýchlejšie a kvalitnejšie. Aj pri písaní dokumentácií k softvérovým produktom treba pristupovať inovatívne a snažiť sa robiť to lepšie. Najväčší trend v písaní dokumentácie je použitie systému pre online dokumentáciu formou Wiki. V tejto eseji sa môžete dočítať niečo o tejto metóde, jej histórii, budúcnosti, výhodách, nevýhodách a o mojom názore ako ich môžeme riešiť. Ako písať dokumentáciu, je však ešte len prvý krok k jej napísaniu. Musíme vedieť, čo reálne potrebujeme v dokumentácii. Ja si myslím, že potrebujeme písať len to, čo ľudia reálne potrebujú a nie viac, ani menej.

Riadenie projektu, prečo nepostupuje vývoj podľa plánu

Gomola Matej

Abstrakt. Táto esej je zameraná na použitie nástrojov na manažment a monitorovanie postupu práce na projekte. Zavedenie nástroja na manažment projektu bude mať vplyv na veľkú časť práce na projekte, preto je vhodné si uvážiť do akej miery a rozsahu sa bude systém zavádzať. Nakoniec sa budem zaoberať možnými dôvodmi, ako sa z nástroja na manažment úloh vo väčších organizáciách môže stať príčina, prečo projekt nepostupuje ako má. Zameriam sa na časť manažmentu úloh, ale aj komunikácie a zdieľanie informácií. V závere sa vyjadrím k riešeniu a predídeniu problémov, ktoré môžu nastať pri zavedení nástrojov na manažment projektu.

Ako na riziká

Grega Jaroslav

Abstrakt. V dnešnom svete plnom neistoty je potrebné počítať s mnohými nástrahami v každej oblasti. Takou oblasťou je aj vývoj softvérových a informačných systémov. Touto esejou by som chcel čitateľa oboznámiť s problematikou manažmentu rizík. V úvode prejdem základné pojmy manažmentu rizík. Následne prejdem k samotnej problematike, v ktorej budem aplikovať poznatky z manažmentu rizík v predmete tímový projekt. Po krátkom úvode vysvetlím, prečo je manažment rizík dôležitý a prečo je dôležité sa ním zaoberať. Keďže nie každému musí byť jasné, ako postupovať pri manažovaní rizík, rozhodol som sa esejou priblížiť, ako to vidím ja na základe vlastných skúsenosti.

Dôležitosť srdca a obalu softvérového produktu

Gregor Martin

Abstrakt. Viete si predstaviť aké je to pri zlyhaní projektu? Najmä pri vývoji softvéru je kľúčovým kritériom aby projekt nezlyhal. O to sa postará manažment monitorovania, ktorý metódami kontroly vývoja a špeciálnymi metrikami dokáže určiť nielen aktuálny stav projektu, ale aj predpovedať progres vývoja a odhadnúť cenu a zdroje potrebné k jeho dokončeniu. Monitorovať sa dá aj interný aj externý stav vývoja. Po internej stránke sa myslí kvalita kódu, ktorá zabezpečí integritu, stabilitu a robustnosť systému. Externý stav sú splnené funkčné a vonkajšie viditeľné vlastnosti produktu. My sa spolu pozrieme na metódy a možnosti monitorovania vnútornej aj vonkajšej stránky vývoja a ich vplyv na výsledný softvérový produkt.

Užitočnosť monitorovania a agilný spôsob vývoja softvéru

Kollár Adrián

Abstrakt. Na uľahčenie plánovania a zlepšenie monitorovania procesu vývoja existujú rôzne metriky, ktoré sa snažia do istej miery merať, či už produkt, alebo proces samotný. Softvérové metriky však trpia niektorými problémami, ktoré vyplývajú z povahy softvéru. V eseji bude objasnená podstata týchto problémov a zodpovedaná otázka prínosu metrík pri procese vývoja softvéru. Dôležitou témou je aj agilný spôsob vývoja softvéru, ktorý v dnešnej dobe pri vývoji softvéru používa čoraz viac spoločností. V súlade s agilnou metodikou sa pri rozhodovaní spoliehajú hlavne na odborníkov a intuíciu. V poslednej dobe sa objavili rôzne modifikácie používaných metrík pre potreby agilnej metodiky vývoja. Aby tieto metriky mali výpovednú hodnotu, museli byť upravené za účelom zohľadnenia agilnej metodiky vývoja. Môžu byť tieto metriky prínosom? Je užitočné ich používať?

Radosť z monitorovania

Králik Gergely

Abstrakt. Proces monitorovania projektov je možnosť na to, aby sme dozvedeli čo najviac a najpresnejšie o stave realizácie projektu. Pomocou monitorovania projektu môžeme vedieť odhadnúť kvalitu vytvoreného programu, a zároveň aj môžeme merať úsilia jednotlivých členov realizačného tímu. V dobe keď agilný vývoj softvéru je používaný vo veľkej miere musíme investovať viac času do monitorovania projektu, aby sme vedeli presne odhadnúť možné riziká a tým predísť chyby. Pod pojmom monitorovanie projektu môžeme chápať aj monitorovanie kvality kódu, ale aj monitorovanie jednotlivých členov tímu, či postupujú podľa plánu, a ako plnia svoje úlohy. Monitorovanie pozostáva z troch hlavných prvkov: zachytávanie, analýza a vypracovanie záznamov. Esej popisuje metriky na monitorovanie jednotlivých typov projektu. Popisuje možnosti monitorovania jednotlivých členov tímu. Esej sa zameriava na opis možností pri sledovaní kvality práce, alebo pri prideľovaní jednotlivých úloh.

Softvérová kvalita naša každodenná

Kyžňanský Michal

Abstrakt. Kvalita a najmä tá softvérová predstavuje magický pojem, ktorý od vzniku slova softvér trpí svojím nenaplnením. Každý manažment je v prvom rade o ľuďoch, a preto sa ako manažér kvality zamýšľam nad prístupom k nim, ako im byť bližšie a ťahať celý vývojový tím nenásilne na novú úroveň v otázke dosahovania kvality. Manažér kvality bojuje s veternými mlynmi, pretože bezchybný softvér je utópia a zaviesť nové postupy zlepšujúce kvalitu nie je ľahká úloha. Ego programátorov a zabehnuté koľaje sú len jedným z mnohých orieškov, ktoré musí manažér kvality rozlúsknuť. Zameriavam sa na postupy a správanie, ktoré pri správnej integrácii môžu zmierniť krízu kvality. Dôležitými zbraňami manažéra kvality je citlivý prístup, získanie si dôvery na všetkých frontoch a určovanie cieľov, ktorých naplnenie bude merateľné a zvýši kvalitu produktov nielen v očiach zákazníkov, ale dá aj vývojárom pocit dobre vykonanej práce. Vlastníci aj manažéri musia jasne vidieť benefity v podobe šetrenia nákladov do budúcnosti, aby bola misia kvalitára úspešná.

Ako si nenaplánovať neúspech

Michalec Peter

Abstrakt. Plánovanie rôznych rozvrhov je v dnešnej dobe bežné nielen v školách, ale aj v rôznych firmách, či osobných životoch. Taktiež zohráva veľkú úlohu pri softvérových projektoch ako pre jednotlivcov, tak aj pre tímy ľudí. Každý sa snaží v rámci svojich schopností dobre naplánovať daný projekt, i keď miera, do akej je projekt dobre naplánovaný je ťažko merateľná. Softvér na zákazku sa tvorí už dlhé roky a vznikli viaceré rady, ktorými by sa mali manažéri držať pri plánovaní, aby sa im celý projekt nezrútil. Metodika scrum, ako jedna z agilných metód vývoja softvéru, sa snaží poskytnúť riešenie ako zlepšiť a sprehľadniť toto plánovanie softvérových projektov. Po niekoľkých rokoch skúseností s touto metodikou existujú rady, ako o niečo vylepšiť takéto plánovanie. Dôležité je však dávať pozor a snažiť sa riadiť týmito radami. Toto je hlavne dôležité pre neskúsených študentov, ktorý sa po prvý krát stretávajú s tímovou prácou na predmete tímový projekt na našej fakulte.

Písanie e-mailov. Robíme to správne?

Nagy Gábor

Abstrakt. Esej sa zaoberá výhodami a nevýhodami e-mailovej komunikácie v tímovej práci. Po vymenovaní niektorých podstatných výhod na základe výskumov sa snaží upozorniť čitateľa na to, že väčšina pozitív tohto komunikačného kanála nie je samozrejmosťou. Ich uplatnenie podmieni niekoľkými zisteniami, ktoré sa týkajú najmä spôsobu použitia a profesionálneho prístupu k tejto forme komunikácie. Hľadá chyby, uvažuje o možných riešeniach a takto sa snaží zvyšovať efektivitu komunikácie v tíme.

Aj neaktuálna dokumentácia je užitočná

Ogurčák Filip

Abstrakt. Technická dokumentácia tvorí podstatnú, no častokrát zanedbávanú časť výsledného softvérového produktu. Zanedbávanú v tom zmysle, že pozornosť je kladená prevažne na funkcionalitu výsledného produktu, a na pravidelné aktualizovanie a dopĺňanie dokumentácie sa často zabúda. Dokumentácia však neslúži iba zákazníkom, ale je dôležitá aj pre programátorov, vedúcich vývojového tímu a manažment organizácie. V tejto eseji by som sa preto rád zameral na fakt, že aj keď dokumentácia nie je práve najaktuálnejšia, a nie sú v nej zapracované najnovšie zmeny, stále má dostatočnú prídavnú hodnotu pre zákazníka, programátora a manažéra kontrolujúceho nasledovanie projektu. Podstatný je v tomto prípade pohľad na vyvíjaný produkt ako celok, ale aj spôsob prepojenia jednotlivých modulov a znázornenie celkovej funkcionality. V konečnom dôsledku sa však do popredia dostáva neprítomnosť určitého štandardu, ktorý by proces tvorby technickej dokumentácie zjednotil a zjednodušil.

Distribuovaný vývoj – krok dopredu alebo späť?

Ort Miroslav

Abstrakt. Vývoj softvéru je náročný proces, ktorého neodmysliteľnou súčasťou je participácia veľkého množstva ľudí. Vplyvom globalizácie nastupuje trend distribuovaného vývoja softvéru. Tímy analytikov, návrhárov, programátorov, testerov sú rozptýlené po celom svete. Ich vzájomná spolupráca je založená na komunikácii na diaľku. V eseji sa zaoberám dôležitosťou a dôvodom vzniku distribuovaných tímov. Zároveň rozoberám komunikačné prostriedky, ktoré distribuovaný vývojový tím k svojej práci potrebuje s výhodami a úskaliami, ktoré prinášajú. Ďalej v eseji upriamim pozornosť na efektívnosť komunikácie na diaľku a opíšem svoje vlastné skúsenosti. V závere sa pokúsim bližšie pozrieť na udržiavanie tímového ducha pri komunikácii s tímovými kolegami na druhej strane planéty.

Jedna verzia je málokedy postačujúca

Ošvát Michal

Abstrakt. Verziovať, verziovať, verziovať. Tak by mohli znieť slová jedného ruského revolucionára, prenesené zo školských lavíc na vývoj softvéru. V dnešnej dobe je pri rozsiahlejších projektoch verziovanie súčasne nevyhnutnosťou, ako aj veľmi dobrým pomocným nástrojom. Nie je tomu tak len kvôli potrebe vytvárať rôzne verzie softvéru pri vývoji, ale potreba verziovať je podmienené často aj veľkým počtom programátorov, ktorí sa na vývoji paralelne podieľajú, a to nám takýto nástroj umožňuje. V eseji sa snažím odôvodniť potrebu verziovania, ďalej sú to jeho výhody, a najviac sa zameriavam na možné problémy, ktoré sa môžu pri verziovaní vyskytnúť, a to konkrétne pri používaní Subversion. Nanešťastie ich nie je málo.

Existujú riziká manažmentu rizík?

Pakan Filip

Abstrakt. Napriek pokročilým technológiám a podporným nástrojom pre vývoj softvéru, stále veľké množstvo softvérových projektov v súčasnosti zlyhá. V posledných rokoch sa pozornosť obracia smerom k manažmentu rizík. Výskumy ukázali, že efektívnym sledovaním a riadením rizík možno výrazne znížiť pravdepodobnosť neúspechu. Prax potvrdzuje zistenia z výskumov a dokazuje, že manažovanie rizík už zachránilo mnoho projektov pred zlyhaním a mnoho finančných prostriedkov pred znehodnotením. Napriek nesporným pozitívam manažovania rizík v softvérových projektoch, v tejto eseji sa pokúšam poskytnúť svoj pohľad na negatíva manažmentu rizík. Snažím sa identifikovať a diskutovať, aké riziká a nevýhody so sebou prináša manažment rizík. Zároveň sa zamýšľam a ponúkam niekoľko vlastných nápadov, ako by bolo možné eliminovať riziká manažmentu rizík v kontexte novozloženého a neskúseného tímu vyvíjajúcom softvérový systém. Cieľom tejto eseje nie je odradiť čitateľov od integrácie manažmentu rizík do svojich projektov. Práve naopak, cieľom je upovedomiť čitateľov o potenciálnych úskaliach manažmentu rizík a ponúknuť im niekoľko užitočných myšlienok, ako manažment rizík vykonávať ešte dôkladnejšie a bezrizikovejšie ako doposiaľ.

Aj pri dymových signáloch dochádzalo k šumu

Palát Peter

Abstrakt. Obsahom tejto eseje je zamýšľanie sa nad problematikou komunikácie v tímoch, ktoré nepracujú na jednom pracovisku. Členovia takýchto tímov spolu komunikujú na minimálnej úrovni, výsledkom čoho je časté nepochopenie. Snahou tejto eseje je bližšie špecifikovať komunikáciu vo všeobecnosti. Touto témou sa v minulosti zaoberalo mnoho ľudí v rôznych vedných disciplínach ako je sociálna psychológia či filozofia. Poznatky z týchto vedných odborov sa týkajú hlavne komunikácie v rámci osobných stretnutí, preto je veľmi dôležité sa zamyslieť nad tým ako využiť moderné informačné technológie k uľahčeniu komunikácie v distribuovaných tímoch. Na konci eseje sa nachádza opis osobnej skúsenosti autora s prácou v distribuovanom tíme, v ktorej sú opísané problémy spojené s komunikáciou a ich riešenia.

Má zmysel testovať softvér manuálne?

Sucháč Filip

Abstrakt. Každá softvérová firma chce, aby bol jej výsledný produkt kvalitný. Určitá časť procesov, ktoré sa zaoberajú dosahovaním kvality softvéru, sa nazýva testovanie. Prístupov k testovaniu je viacero. Niektoré firmy sa počas implementácie viac spoliehajú na automatické testy, alebo že si vývojári svoju prácu sami po sebe priebežne testujú. Vo viacerých firmách však existuje pozícia tester, obsadená hneď viacerými ľuďmi, ktorí vyvíjaný produkt dookola manuálne testujú a upozorňujú na prípadné chyby. V tejto eseji sa zaoberám výhodami a nevýhodami manuálneho testovania, tým aké vlastnosti by mal mať správny tester, ktorý testuje manuálne, a ktoré prístupy k testovaniu je dobré si zvoliť.