Zbierka esejí 2013
Home Home EN
Skupina 5
Baloga Jakub

Abstrakt. Keď sa stretne skupina ľudí, ktorí majú vytvoriť tím a spolupracovať na nejakom väčšom projekte, môžu sa stretnúť najrôznejšie povahy s rozličnými schopnosťami a skúsenosťami. Na schopnosti a skúsenosti sa pri výbere členov tímu kladie dostatočný dôraz. Nie vždy je však dostatočný dôraz kladený na to, aká bude dynamika vzťahov medzi jednotlivými členmi tímu. Belbin identifikoval 9 rôznych tímových rolí. Tieto roly nám dokážu povedať, ako budú členovia tímu spolupracovať, predpoklady pre spôsob komunikácie medzi členmi tímu, či sa prejaví synergia rolí a posunie to tím dopredu, alebo bude medzi členmi tímu vznikať napätie a budú celý tím brzdiť. V tejto eseji chcem uvažovať nad interakciami jednotlivých rolí, ich vplyvom na efektivitu tímu, možnosťami vedúceho tímu komunikovať s členmi, spôsobmi efektívnej komunikácie, možnosťami viesť ich k zaujatiu rolí potrebných pre čo najlepšie fungovanie tímu a predchádzanie možných problémov.


Demovič Ľuboš

Abstrakt. Úspech v tímovom projekte záleží na mnohých veciach – od tých najmenej podstatných až po mimoriadne dôležité aspekty. Každý úspech musí prekonať nesmierne množstvo rôznych rizík, ktoré by mali skúsení manažéri rizík vedieť čím skôr odhaliť. Zároveň by mali efektívne a spoľahlivo vyhodnotiť, ako hroziace sa nebezpečenstvo odstrániť, alebo aspoň zmierniť. Najväčšou konkurenčnou výhodou pri realizácii projektu je tímová spolupráca, ktorá má mimoriadne veľkú silu. Ale v každom tíme raz nastanú sociogénne riziká, ktoré by mohli zapríčiniť rozpad tímu. V tejto eseji priblížim hlavné príčiny zlyhania tímu a súčasne opíšem, ako tieto dôvody rozpoznať a odstrániť. Tím ľudí, ktorý dokáže ťahať za jeden povraz, môže byť veľmi rýchlo najúspešnejší v akomkoľvek odvetí.


Fritscher Eduard

Abstrakt. V softvérových projektoch, tak ako aj v projektoch z iných oblastí, hrá dôležitú rolu plánovanie. Správne odhady prispievajú k tomu, aby projekt skončil úspešne. V mojej eseji som sa zameral na porovnanie tradičných metód odhadovania, respektíve procesov pri plánovaní na základe vodopádového modelu oproti novým modelom a metód, ktoré sa používajú pri agilnom vývoji. Analyzoval som stav v manažmente plánovania a sústredil som sa najmä na odhadovanie vo vodopádovom modeli a v agilných metódach. Porovnal som metódy a techniky v odhadovaní ako aj v plánovaní. Snažil som sa poukázať na to, ako sa zmenilo odhadovanie pri projektoch a jednotlivých komponentoch s príchodom agilných metodík. Ďalej sa v eseji snažím zdôrazňovať potrebu toho, aby boli do manažmentu plánovania zainteresované aj vývojové tímy a zdôrazňujem aj benefity tohto spôsobu odhadovania.


Granec Michal

Abstrakt. Každý produkt by sa mal snažiť, čo najlepšie splniť požiadavky naňho kladené a byť čo najkvalitnejší, ako to len pôjde. Softvérový manažér kvality musí čeliť viacerým problémom, aby dosiahol úroveň kvality softvéru takú, aká je od neho požadovaná. Jedným zo spôsobov, ktorý manažér kvality používa na kontrolu kvality, je použitie softvérových metrík. Tie nám môžu pomôcť odmerať dôležité rozmery softvéru a získať o ňom hmatateľnejšiu predstavu a to aj napriek jeho vnútornej komplexnosti. Používanie metrík avšak nie je absolútne riešenie a musíme si dať pri tejto technike pozor na rôzne nástrahy, ktoré nás môžu prekvapiť. V tejto eseji analyzujem ich všeobecné uplatnenie, ale aj najčastejšie problémy, na ktoré narazíme pri ich používaní. Tieto problémy ďalej rozoberám a pokúšam sa prísť na riešenie týchto problémov.


Jendek Tomáš

Abstrakt. V súčasnosti môžu byť softvérové projekty rozsahom a počtom ľudí pracujúcich na úlohách priveľké, a teda treba riešiť manažment monitorovania projektu v snahe doručiť kvalitný softvér načas a so ziskom. Monitorovanie technických faktorov projektu nie je v súčasnosti dostačujúce a pozornosť treba venovať sledovaniu ľudských faktorov pri vývoji softvérového produktu. Efektivita a spokojnosť programátorov v tíme značne ovplyvňuje celkový výsledok vývoja. Monitorovaním faktorov ako napríklad zahltenosť úlohami, preťaženosť emailovej komunikácie a rôzne mimopracovné aktivity vykonávané počas pracovnej doby vieme včas identifikovať problémy a následne vykonať nápravné akcie. Miera monitorovania ľudských faktorov musí ostať v rozumných hraniciach, pretože prílišné zasahovanie do súkromia a pocit nepretržitého sledovania na pracovisku vedie k strate motivácie čoho dôsledkom je nižšia produktivita pri vývoji produktu.


Kandráč Ján

Abstrakt. Zvlášť v ťažkých začiatkoch IT oddelení firiem sa stáva, že dokumentácia ich produktu je podceňovaná. Zlyháva manažment dokumentácie a časom sa ukazuje, aká je situácia kritická. Problém sa týka pomalých a nekvalitných výstupov, či iných problémov, ktoré zlým vedením môžu vzniknúť. Riešení takýchto problémov je možno nájsť hneď niekoľko, avšak tieto riešenia často nespočívajú v zvrátení zlej situácie, skôr v jej predchádzaní. Väčšinou ide o opis prevencie pred tým aby zlá dokumentácia vôbec vznikla alebo o zmenu manažérskeho osadenia, ktorá je nutná kvôli nedodržaným termínom. Ako však liečiť dokumentáciu, ktorá je skutočne zlá? Alebo ako je možné ju uchopiť v akomkoľvek štádiu a dotiahnuť ju do úspešného záveru?


Kaššák Ondrej

Abstrakt. Je známym faktom, že skupina spolupracujúcich ľudí dokáže vo vhodných podmienkach dosiahnuť lepšie výsledky ako izolovane pracujúci jednotlivci. Ako však zabezpečiť správne podmienky na spoluprácu a ako zosynchronizovať tím tak, aby skutočne spolupracoval a efektívnou cestou vytvoril požadovaný výstup? Jedným z najdôležitejších aspektov v tomto procese je zabezpečenie fungujúcej komunikácie v tíme. Bez vzájomnej výmeny informácií by sa totiž tím mohol ľahko premeniť na skupinu zavadzajúcich si jednotlivcov. V súčasnosti máme k dispozícii množstvo spôsobov výmeny informácií. Nakoľko sú však jednotlivé spôsoby vhodné pre softvérové tímy? Je rozdiel medzi využívaním komunikačných prostriedkov v tímoch pracujúcich na jednom mieste a v distribuovaných tímoch? Ktoré spôsoby reálne využívajú softvérové tímy v každodennej praxi? A nakoľko sa nimi môžeme inšpirovať z pohľadu študentského tímu?


Kříž Jakub

Abstrakt. Verziovacie systémy sú v praxi bežne používané na správu zdrojového kódu v tímoch s viacerými programátormi. Používanie týchto systémov v malých alebo dokonca jednočlenných tímoch však nie je samozrejmé, pretože programátor-jednotlivec v princípe nepotrebuje správu zdrojového kódu. Ich použitie však prináša viacero menej očividných výhod, ktoré pomôžu k vytvoreniu lepšieho softvérového produktu. Verziovacích systémov existuje veľké množstvo a delia sa na dve výrazne odlišné skupiny – centralizované a distribuované. Výber správneho systému sa môže líšiť od jedného projektu k druhému. V tejto eseji opisujem moje názory na výber správneho typu a použitie verziovacieho systému jednotlivcami a tímami s menším počtom programátorov.


Kuzmík Ondrej

Abstrakt. Testovať či netestovať? Ak áno, tak kedy, čo a ako? Možnosť vytvorenia eseje využijem pre opísanie svojho názor na túto problematiku alebo aspoň vybranú časť. Priblížim svoj pohľad na tému testovania a kvality. Kedy sa testovanie oplatí, a kedy je viac menej zbytočné. Väčšinou sa testuje správnosť kódu, pričom na testovanie požiadaviek (splnenia funkcionality) sa zabúda. Túto problematiku sa pokúsim priblížiť, spolu s tým, ako môže kvalitné testovania dopomôcť ku lepšiemu softvéru, prípadne spraviť softvér výnimočným. Zameriam sa aj na tému, kto by mal byť za testy zodpovedný a ako je tento človek dôležitý pre tím.


Proksa Ondrej

Abstrakt. V súčasnosti sa kladú vysoké nároky na vývoj softvéru. Už nestačí byť len dobrý, ale musíme byť vynikajúci, pokiaľ chceme dosiahnuť viac. Jedným z kľúčových členov tímu je vedúci, ktorý zodpovedá za fungovanie, realizáciu a okrem iného aj za komunikáciu. Práca a fungovanie tímu je vždy o ľuďoch a komunikácií medzi nimi. Pre vedúceho tímu je náročné, aby vždy viedol komunikáciu správnym smerom a dokázal motivovať tím k úspechom. V tejto eseji sa venujem formám komunikácie, následne skúmam efektívnosť a výhody resp. nevýhody komunikačných nástrojov. V ďalšej časti venujem priestor správnej komunikácii v tíme z pohľadu vedúceho a tiež pripájam môj názor na efektívnu komunikáciu prepojenú s motiváciou.


Trebuľa Ján

Abstrakt. Manažment rizík je dôležitá súčasť manažmentu softvérových projektov. Prečo je tak problematické uplatniť teoretické základy riadenia rizík v praxi? Odpoveď by mohli priniesť výsledky empirickej štúdie, ktoré rozoberám v tejto eseji. V eseji taktiež predstavujem a uvažujem nad modelovacím rámcom vývoja softvérových projektov, ktorý je riadený cieľmi. Nakoľko môže byť takýto rámec efektívny? Pre aké tímy je vlastne určený? Úvahy nad podobnými otázkami spolu s potenciálnou budúcou prácou sa nachádzajú v záverečnej časti eseje.


Urbančok Maroš

Abstrakt. Pri tvorbe softvéru, hlavne rozsiahlych projektov, zohráva vhodné naplánovanie a rozdelenie úloh kľúčovú rolu. Táto oblasť sa totiž vyvíja oveľa rýchlejšie ako iné odvetvia a vývoj prináša so sebou množstvo nástrah. Tomuto pokroku treba prispôsobovať aj metódy používané pri plánovaní. No už pri vzniku plánu vieme priebežne kontrolovať to, aby sa plán neuberal zlým smerom. Ešte pred začatím jeho vykonávania je potrebné si uvedomiť vážne chyby, ktoré mohli pri plánovaní vzniknúť. Tieto je možné jednoducho detegovať už v zárodku a tým ich neskôr odstrániť alebo minimalizovať ich dôsledok. Takto detekovateľných chýb je niekoľko. Niektoré sú závažné a môžu ohroziť projekt, iné nie. No napriek tomu môžu projekt do značnej miery narušiť.


Vandlíková Diana

Abstrakt. Monitorovanie je pre úspešné dokončenie projektu kľúčové. Bez monitorovania skutočného aktuálneho stavu projektu sa môžu v závere vyskytnúť chyby, o ktorých sme nemali ani tušenia. Jednotliví členovia tímu dokážu svoje chyby dlho ukrývať. Nie je to len ich chybou, ale často aj chybou nedostatočných skúseností. Na monitorovanie sa môžeme pozerať z viacerých pohľadov. Nielen ako na monitorovanie jednotlivých častí, ale aj ako na smerovanie celku a jeho aktuálny stav. Pritom oba pohľady sú rovnako dôležité. Monitorovanie nemôžeme položiť na plecia jednotlivca – manažéra monitorovania alebo mentora, ale každý musí na monitorovaní spolupracovať. Vyzdvihujem potrebu osobnej zodpovednosti jednotlivých členov tímu a potrebu komunikácie o chybách a stave jednotlivých komponentov. Tomu má predovšetkým slúžiť stretnutie celého tímu, kde sa manažér monitorovania snaží podnietiť členov ku komunikácii o stave ich práce. Nástroje pre monitorovanie a skúsený mentor sú vhodným prostriedkom, ale nezaručujú dobrý výsledok.


Villaris Vojtech

Abstrakt. Vývoj softvérových projektov je často spätý s rôznymi vonkajšími a vnútornými rizikami, ktoré môžu spôsobovať rozličné problémy. Existuje viacero publikácií, ktoré poskytujú rozličné návody a techniky na to, ako sa s riadením takýchto rizík vysporiadať, ale drvivá väčšina z nich je určená pre veľké firmy a rozsiahle softvérové projekty. V tejto eseji sa snažím zamerať predovšetkým na menšie projekty, na ktorých pracujú menej členné tímy a tým oblasť riadenia rizík preniesť aj do prostredia semestrálnych projektov riešených v tímoch. Za týmto účelom v eseji opisujem hlavné rozdiely medzi veľkými a malými projektmi a z toho vyplývajúce aj rôzne riziká, ktorým v nich môžeme čeliť.


Višňovský Juraj

Abstrakt. Systémy na správu verzií sú základným kameňom väčšiny dnešných softvérových systémov. Manažment verzií totiž v nemalej miere rozhoduje o úspechu, prípadne neúspechu celého projektu. Dôvodom je narastajúca zložitosť vyvíjaných softvérových systémov. Z tohto dôvodu je výber vhodného nástroja na manažment verzií kľúčový. Pre všetky podporné prostriedky na správu verzií je však charakteristická príslušnosť k jednému z dvojice revíznych systémov. Tými sú centralizované a distribuované systémy na správu verzií. Táto esej analyzuje oba menované systémy, opisuje proces výberu systému z tejto dvojice a ponúka alternatívu, ktorá by ich v budúcnosti mohla doplniť, prípadne nahradiť.


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