Abstrakt. Manažment rizík v softvérovom projekte hrá dôležitú úlohu počas celého behu projektu. Jeho úlohou je včas rozpoznať a ošetriť nepredvídané situácie v projekte tak, aby a) vôbec nevznikli, b) spôsobili čo najmenšie škody. Manažment rizík pozostáva z identifikácie rizík, analýzy rizík, plánovania manažmentu rizík a riadenia rizík.
Esej dáva ucelený pohľad na jednotlivé fázy manažmentu rizík, poskytuje prehľad najzávažnejších rizikových faktorov identifikovaných skúsenými projektovými manažérmi a snaží sa poskytnúť informácie o manažmente rizík v rámci tímového projektu počas štúdia na FIIT STU.

Abstrakt. Agilné metódy programovania, kde sa za hlavného predstaviteľa pokladá práve extrémne programovanie, sú považované za mimoriadne vhodné najmä pre menšie projekty s často sa meniacimi požiadavkami. Vzniká tak však aj mylná predstava o tom, že praktiky, ktoré tvoria ich jadro, sú pre iné projekty nevhodné a spôsobujú ich zlyhania. Dostávajú sa takto do úzadia bez hlbšieho skúmania ich pravej podstaty. V poslednej dobe sa však ukazuje, že niektoré praktiky sú natoľko rozumné, že vhodný výber a ich použite môže mať pozitívny dopad na takmer ľubovoľný projekt. Je preto potrebné spoznať príčiny vzniku ako aj výhody a dôsledky týchto praktík a nezavrhovať ich hneď ako celok.

Abstrakt. Táto esej sa zaoberá predstavením pojmu Virtuálna softvérová spoločnosť a skladá sa z dvoch časti: v prvej sa zaoberám hlavne definíciou pojmu Virtuálna softvérová spoločnosť (Virtuálny distribuovaný tím) a opisom nástrojov, s ktorými VSC pracujú. Pri týchto nástrojoch sa sústreďujem na komunikáciu a nie na zdieľanie dokumentov. V druhej časti sa na základe výsledkov reálnych výskumov v tejto oblasti zaoberám problémami, s ktorými sa VSC stretávajú, aké výhody poskytujú, ale aj ich porovnaním s lokálnymi tímami.

Abstrakt. Kvalita je bezpochyby najdôležitejšou vlastnosťou každého výrobku. Základnou myšlienkou tejto eseje je pozrieť sa hlbšie na pojem kvalita softvéru, a to v kontexte manažmentu kvality. Príspevok podrobne analyzuje jednotlivé znaky kvality. Diskutuje o tom, ktoré z nich sú dôležité z pohľadu zákazníka a z pohľadu výrobcu softvéru. Rozoberie sa tu pojem chyba a taktiež jednotlivé rozpory medzi požiadavkami zákazníka a požiadavkami výrobcu na softvér. Na záver sa opisuje manažment kvality ako systém riadenia kvality.

Abstrakt. Obsahom eseje je stručný úvod do problematiky a oboznámenie sa so základnými konceptmi systémov pre manažment softvéru. V práci je vyhradený tiež priestor problematike vplyvu na manažment projektu.

Abstrakt. Táto práca sa venuje produktivite softvérového tímu najmä s cieľom pomôcť produktivitu zvýšiť. V prvej časti sú analyzované vplyvy a faktory, ktoré majú dopad na produktivitu tímu. Jednotlivé vplyvy sú kvantitatívne porovnané a najvýznamnejší vplyv - schopnosť tímu - je v ďalšej časti práce hlbšie preskúmaný. V rámci schopnosti tímu ako spôsobilosti tímu plniť zadané úlohy sa pozornosť venuje osobnostnému zloženiu menšieho tímu, pričom do úvahy sa berie vhodnosť rôznych typov osobností na jednotlivé pozície v softvérovom tíme. Táto charakteristika je opísaná pomocou typológie osobnosti MBTI (Mayers-Briggs Type Indicator). Súčasťou práce je aj úvod do psychológie osobnosti a bližší opis typológie MBTI.

Abstrakt. V tvrdej konkurencii vždy zvíťazí ten, kto dokáže najlepšie odhadnúť situáciu a pružne reagovať na podnety z okolia. Zvlášť to platí v oblasti vývoja softvérových produktov. Príspevok stručne definuje základné fázy procesu odhadovania a poukazuje na dôležitosť využitia skúseností z predchádzajúcich projektov pri jeho realizácii. Ďalej sa pokúša rozoznať najdôležitejšie problémy, ktorým musia tvorcovia odhadov čeliť a ponúka k nim možné riešenia. Nakoniec uvádza cenné rady a pripomienky, ktoré majú prispieť k lepšiemu odhadu, a teda aj k úspešnejšiemu projektu.

Abstrakt. Chyba je nerozlučiteľným partnerom akéhokoľvek softvérového projektu. Tento stav je zapríčinený viacerými faktormi. Asi najdôležitejším je osobitosť vývoja softvéru a jeho vlastnosti. Pozrieme sa na tvorcov chýb a ich skúsenosti. Popíšeme chyby z hľadiska ich viditeľnosti a následkov, ktoré z nich vyplývajú. Testovanie patrí k oblastiam, ktoré sa často podceňujú, a preto sa zameriame na dôvody tohto stavu a vzťah testovača a programátora. S chybami priamo súvisí spoľahlivosť softvérového produktu. Ako jednému zo základných modelov správania sa chyby sa budeme venovať modelu Musa. Nakoniec si porovnáme náklady, ktoré platíme za chyby a ako sa mení ich cena v závislosti od viacerých faktorov.

Abstrakt. Súčasné trendy v oblasti vývoja softvéru naznačujú čoraz väčšiu potrebu existencie vzťahu medzi zákazníkom (zadávateľom projektu) a vývojárom daného softvéru. Potreba zdokonalenia a prehĺbenia komunikácie medzi nimi je len logickým vyústením neustáleho konkurenčného boja firiem v snahe vyvinúť softvérový produkt v čo najkratšom čase. Tento článok sa venuje problémom komunikácie medzi oboma subjektmi, úrovniam komunikácie medzi nimi, ako aj samotnej úlohe zákazníka pri vývoji softvéru. Esej ďalej pojednáva o agilných metodikách ako novom trende vývoja softvéru a skúma vzťah zákazníka a vývojára pri extrémnom programovaní, hlavnom predstaviteľovi týchto metodík. Na záver upozorňuje na existenciu liniek medzi zákazníkom a vývojárom, ktoré môžu do značnej miery zefektívniť vývoj softvéru aj v budúcnoti.

Abstrakt. Napriek najlepšiemu plánovaniu, účasti najlepšieho tímu a predvídaniu všetkých možných úskalí to vyzerá tak, že softvérové projekty majú dlhoročnú prax vo vyvolávaní nepredvídateľných problémov. Jedna z možností, ako sa môžeme vyhnúť neúspešnému ukončeniu projektu, je sledovanie postupu softvérového projektu. Aby sme vôbec mohli sledovať vývoj a postup v softvérovom projekte, je veľmi dôležité vytvoriť plán. Tiež je potrebné zaviesť vhodné metriky, ktorými budeme merať postup. Metriky by nemali nútiť ľudí dosahovať lepšie výsledky v meraní, ale motivovať ich efektívne dosiahnuť vytýčené ciele projektu. Keď máme plán projektu, je možné pýtať sa, akú časť projektového plánu sa podarilo splniť, odhadovať, koľko práce ešte treba spraviť a porovnávať naplánovaný stav so skutočným stavom. V prípade rozdielov je možné plán skorigovať a nasmerovať úsilie tímu tým správnym smerom.

Abstrakt. V práci je rozoberaný vývoj tímu z hľadiska troch rôznych modelov. Ako prvý je rozoberaný Bruce Tuckmanov model "formovanie, kryštalizácia, vyjasnenie, realizácia" aj s neskôr autorom pridanou piatou fázou "ukončenie", ktorá ma špeciálny vplyv na manažment. Ako druhý je popísaný Herseyho a Blanchardov situačný vodcovský model so štyrmi fázami a podobnosť fáz týchto dvoch modelov. Posledným rozoberaným modelom je Tannenbaumovo a Schmidtovo kontinuum. Ďalej sú popísané úlohy manažéra v rôznych fázach vývoja tímu podľa modelu podobného s Bruce Tuckmanovým modelom a je dopodrobna opísaná úloha manažéra a zmeny v riadení pri siedmich stupňoch pridelenej voľnosti v modeli Tannenbaumovho a Schmidtovho kontinua.

Abstrakt. Zložitosť riadenia a vývoja v softvérových projektoch so sebou prináša aj rôzne technológie a softvérové nástroje. Pomocou nich je možné napríklad vytvárať komplexné modely, automaticky generovať zdrojové kódy a dokumentáciu alebo komunikovať s inými ľuďmi, ktorí sa na týchto projektoch podieľajú. Z veľkého množstva nástrojov a technológií, ktoré sú už v súčasnosti k dispozícii, som sa zameral na tie, ktoré pomáhajú vytvárať a udržiavať dokumentáciu k softvéru, ako aj tie, ktoré zlepšujú komunikáciu medzi členmi tímu. Pre úspech softvérového projektu je priam nevyhnutné, aby o používaných nástrojoch vedeli a rozhodovali ľudia, ktorí ho riadia. Aké nástroje a technológie použiť? Odpovedať na túto otázku nie je vôbec jednoduché.

Abstrakt. Keďže sa stále viac vývoja uskutočňuje v tímoch, vzrastá potreba riešenia konfliktov. Základom pre vznik konfliktu sú rozdiely (názorové ale aj iné). Keď sa jednotlivci stretnú v tíme, rozdiely medzi nimi prispievajú k vzniku konfliktov. Vznik konfliktov tiež podporuje nedostatok zdrojov, čo sa pri vývoji softvéru stáva pomerne často. Pri riešení konfliktov sa považuje za dôležité riešiť spory rýchlo a otvorene, aby sa predišlo negatívnym dôsledkom. Konflikt sa bežne chápe ako negatívny jav - nemusí však byť deštruktívny. Ak je správne riešený, jeho výsledok môže byť pre tím prínosom. Pri vývoji softvéru sa konflikty môžu vyskytnúť napríklad medzi vývojármi a koncovými používateľmi alebo medzi programátormi a testermi.

Abstrakt. Úvod a záver celej publikácie