Belanji JurajAbstrakt. Keď sa pred človeka postaví nejaký problém, prvá inštinktívna vec, ktorá ho napadne, je vytvoriť si plán na vyriešenie daného problému. Aj keď ten plán nie je oficiálne napísaný, každý človek si v mysli nejaký plán vytvorí. Na vytvorenie softvérového projektu je taktiež potrebný plán. Plán je základný kameň vytvorenia dobrého softvérového produktu. Tak ako je každý človek jedinečný, tak aj každý nový plán musí byť jedinečný. Je však možné vytvoriť plán, ktorý bude základnou kostrou na vytváranie nových plánov? V eseji sa identifikujú chyby, ktoré sa môžu stať pri tvorbe plánov. Esej ponúka iný pohľad na univerzálne plánovanie, a poukazuje, že občas univerzálne vytvorený plán zabezpečuje pozitívnejšie výsledky ako vytváranie nového plánu.Beliansky MichalAbstrakt. Každý z nás je po celý život jedinečný človek s vytýčenými cieľmi a túžbami. Všetky naše materiálne, mentálne a ľudské zdroje smerujeme k dosiahnutiu týchto cieľov. Pod vplyvom túžob si vedome alebo podvedome riadime a plánujeme život. Toto plánovanie môžeme z určitého uhla pohľadu porovnať k plánovaniu projektu. Rozsiahlejšie činnosti na uskutočnenie vytýčených snov si plánujeme dopredu, často krát sami, prípadne v spoločnosti rodiny, našich blízkych, tímových kolegov. Efektívne využívanie vizualizačných nástrojov nabitých nespočetným množstvom funkcií nie je žiadnou novinkou. Súčasné podporné prostriedky plánovania poskytujú pre nováčika mnoho funkčných prvkov, s ktorými sa v bežnom „plánovaní života“ nestretne.Brath MarekAbstrakt. Vytvorenie softvérového projektu je nesmierne zložitý proces, pri ktorom je nutné zaviesť určité spôsoby merania, ktoré umožňujú určovať vlastnosti takéhoto produktu. Pomocou softvérových metrík dokážu manažéri efektívnejšie monitorovať softvérové projekty a tým dokážu lepšie spravovať zdroje a znižovať celkový čas projektu. Hlavným záujmom firiem nie je len vytvorenie kvalitného výsledného produktu, ktorý by uspokojil zákazníka ale najmä čo najväčší zisk, v čo najkratšom čase. Práve z tohto dôvodu sa snažia zavádzať čo najefektívnejšie spôsoby merania, lenže softvérové metriky nemusia byť vždy smerodajné a preto je dôležité používať ich rozumne. Nadmerná miera monitorovania dokáže byť aj kontraproduktívna a preto sa v eseji zameriam na najznámejšie softvérové metriky a spôsoby ich efektívneho využitia.Feješ AdriánAbstrakt. Keď človek narazí na nejaký zložitejší problém, ktorý treba vyriešiť, prvé čo robí je, že začne rozmýšľať o možnostiach riešenia. Ak nájde vhodné riešenie tak sa začne sústrediť na spôsob jeho realizácie. Prejde riešenie krok po kroku, pričom uvažuje o potrebných zdrojoch. Na softvérový projekt je tiež možné pozerať ako na problém, a začať navrhovať postupnosť krokov a definovať potrebné zdroje, čím sa postupne vytvára plán projektu. Samozrejme čím väčší je rozsah projektu a čím viac ľudí sa zúčastňuje na jeho riešení, tým bude plán projektu zložitejší a stúpa jeho dôležitosť. Ako ovplyvní veľkosť projektu jeho plánovanie? Môžeme pri plánovaní malých projektov postupovať rovnako ako pri plánovaní tých väčších? Hľadanie odpovedí na tieto a podobné otázky je predmetom tejto eseje. Pričom pre nájdenie odpovedí je nutné priblížiť aj význam pojmu malý softvérový projekt.Grznár FilipAbstrakt. Dôsledkom zlej komunikácie medzi tímom a manažérom môže byť zlyhávanie celého projektu. Myslím si, že komunikácia v tíme by sa zlepšila, ak by členovia tímu lepšie porozumeli mysleniu manažéra a ak by manažér porozumel mysleniu tímu. Členovia tímu by mali mať pocit osobnej zainteresovanosti. Myslím si, že riešením je použitie kreatívnych metód skupinového riešenia problémov. Medzi tieto metódy patrí brainstorming, brainwriting a metóda DELPHI. Myslím si, že tieto metódy sú pomerne ľahko použiteľné v podmienkach malých tímov, napríklad v tímoch na predmete Tímový projekt vyučovaného na Fakulte informatiky a informačných technológií Slovenskej technickej univerzity v Bratislave. V tejto eseji sa zamýšľam nad konkrétnym prínosom týchto metód.Jašš FrantišekAbstrakt. V súčasnosti sa softvér využíva čoraz viac, zasahuje už takmer do všetkých činností ľudí. Preto stúpajú aj nároky na jeho vývoj. Požaduje sa nie len vysoká kvalita, ale aj čo najkratší čas dodania hotového riešenia. Nato, aby sa to dalo splniť je potrebné vynaložiť veľké úsilie, často až stoviek ľudí. Spolupráca tak veľkých, ale aj menších skupín ľudí si vyžaduje vysoký stupeň koordinácie. Každý jeden člen tímu musí vedieť čo ma robiť a kedy to musí byť hotové, z dôvodu dodržania stanovených termínov. Práve preto je dôležité plánovanie. Je zrejme, že pri veľkých projektoch s veľkým počtom ľudí podieľajúcich sa na riešení ,je plánovanie nevyhnutné, avšak, je potrebné aj v malých tímoch, kde koordinácia nie je ani zďaleka taká zložitá? Ako plánovať, projekty, aby ľudia neboli preťažení, ale aby sa pritom stíhali termíny? Koľko plánovať, aby sa plánovaním nestratilo priveľa času? Odpoveďami na tieto a ďalšie dôležité otázky sa budem zaoberať v tejto eseji. Okrem toho rozoberiem aj niektoré dôležité príčiny zlyhávania projektov ako z pohľadu plánovania, tak aj z inej perspektívy. Tieto faktory sú taktiež neoddeliteľnou súčasťou softvérových projektov a je potrebné brať na nich ohľad už pri plánovaní.Jendrej MarošAbstrakt. V eseji sa zaoberám kvalitou softvérových systémov. Poukazujem na prostriedky pomocou, ktorých možno zabezpečovať kvalitu softvéru. Medzi hlavné prostriedky na zabezpečovanie kvality patrí predovšetkým testovanie. Poukazujem tu na dôležitosť fáz ešte pred začiatkom testovania. Zabezpečenie kvality nie je len samotné otestovanie softvérového projektu, ale aj príprava kritérií a požiadaviek, ktoré majú byť podľa stanovenej úrovne splnené. Jeden z ďalších prostriedkov, ktorým dosiahneme lepšiu kvalitu v rozbehnutom softvérovom projekt je refaktoring. Pomocou neho sa mení architektúra softvéru bez toho, aby sa zmenilo jeho správanie a pritom sa zvýši jeho kvalita. Aplikovanie refaktoringu v projekte, však nezaručuje zvýšenie kvality. Existujú rôzne ukazovatele, pomocou ktorých zisťujeme či je refaktoring vhodný a do akej miery ho je možné uplatniť. Krajčovič JozefAbstrakt. S prudkým rozvojom informačných a komunikačných technológií sa stal vývoj softvéru čoraz komplexnejšou záležitosťou, ktorá v sebe zahŕňa veľké množstvo rôznorodých procesov a požiadaviek. To podnietilo firmy k stimulu dôslednej reorganizácie manažmentu dostupných zdrojov a k efektívnejšiemu využitiu podporných prostriedkov, ktoré sú použité v procese vývoja softvéru. Jedným s možných spôsobov ako zefektívniť proces vývoja softvéru je zautomatizovať rutinné úlohy, ktoré sú vykonávané väčšinou ručne, čo do istej miery ovplyvňuje celkovú efektivitu práce a tým pádom taktiež kvalitu produktu. V tejto eseji sa zaoberám nasledujúcimi otázkami. Môže automatizácia zostavovania a nasadzovania softvéru zvýšiť efektivitu vývojového tímu? Je využitie automatizácie prínosom aj v malých tímoch? Pri odpovediach na tieto otázky vychádzam z vlastného subjektívneho názoru na základe mojich skúseností s podpornými prostriedkami. Kráľovič AntonAbstrakt. Monitorovanie ako také v praxi znamená pravidelné sledovanie akéhokoľvek progresu v softvérom projekte. Je to činnosť ktorá má primárne dopomáhať manažérovi softvérového projektu k včasnému odhaleniu akýchkoľvek nedostatkov na jeho projekte, či už nesplnenie vopred vytvoreného časového plánu alebo nesplnenie zákazníkových požiadaviek. Takéto monitorovanie má samozrejme svoje výhody a aj nevýhody. Aké to sú a aký je ich pomer? Ako sa softvérové projekty vôbec delia a ako sa dá merať ich „spoľahlivosť“? V tejto eseji sa pokúšam odpovedať aj na tieto otázky.Kukučka JozefAbstrakt. Rovnako ako v každom softvérovom projekte, aj v tom školskom hrozia rôzne riziká. Tie môžu nepriaznivo ovplyvniť jeho výsledok. Vo všeobecnosti sa pri softvérových projektoch ako kritéria úspechu berú kvalita výrobku, vynaložený čas a veľkosť vynaložených zdrojov. V školských projektoch je čas na projekt pevne určený fixným termínom odovzdania a rozpočet nie je väčšinou žiadny. Preto za jediné relevantné kritérium pre určenie úspechu takéhoto projektu považujem kvalitu výrobku alebo inými slovami mieru úspešnosti splnenia požiadaviek. V tejto eseji diskutujem, ktoré známe riziká hrozia práve pri školských softvérových projektoch. Na základe zoznamov známych TOP rizík určím, ktoré riziká považujem za TOP 10 pri školských projektoch a ktoré naopak za kritické nepovažujem. Ďalej uvádzam, aké metódy manažmentu rizík si myslím, že je vhodné použiť pri tomto druhu projektov. Pri ich výbere je dôležitá jednoduchosť a zároveň efektívnosť. Študenti sú začínajúci vývojári, čo má za následok neskúsenosť a tú treba zohľadniť do vhodnej zložitosti používaných postupov a praktík. Takisto majú dosť obmedzený čas na vývoj, na čo treba brať takisto ohľad.Lajčin TomášAbstrakt. Definovať kvalitu v softvérovom projekte nie je jednoduché. V študentských projektoch sa jedná o náročný proces, ktorým sa zaoberá úvod eseje. Hlavnou myšlienkou tejto eseje je zamyslenie sa nad spôsobmi zvýšenia kvality v študentských softvérových projektoch. Zvýšenie kvality v študentských projektoch nie je triviálny problém. Dostávame sa do odlišného prostredia, kde neplatia klasické pravidlá pre kvalitu tak, ako vo veľkých komerčných softvérových projektoch. Zabezpečenie kvality v študentských projektoch pomocou štandardov pre kvalitu nie je také jednoduché, ako by sa na prvý pohľad zdalo. Študentské projekty sú menšieho rozsahu a vplýva na ne množstvo nových faktorov. V tejto eseji sa ďalej nachádzajú úvahy o merateľnosti kvality v softvérových projektoch, kde sa opäť objavujú štandardy. Záver eseje sa zaoberá vplyvom testovania softvérového projektu na jeho kvalitu.Lazový MichalAbstrakt. Riadenie tímu pri vývoji softvérového produktu si od manažmentu projektu vyžaduje nemalé úsilie a skúsenosti. Ak sa jedná o tím, ktorý spolupracuje naprieč viacerými geografickými regiónmi, je táto úloha ešte náročnejšia. Nasadenie medzinárodných tímov na vývoj softvéru sa stáva trendom a preto sa venuje veľké úsilie na vytvorenie prostriedkov a nástrojov, ktoré by zmiernili problémy vznikajúce pri kolaborácií a komunikácií takýchto tímov. Spravidla sa jedná o veľké projekty, v ktorých sú tieto problémy ešte výraznejšie a ich riešenie zložitejšie. Esej sa zaoberá spôsobom podpory takéhoto vývoja softvéru a tiež otázkou, ako zvýšiť efektivitu týchto tímov, pretože tu nastávajú komplikácie, ktoré môžu v konečnom dôsledku spôsobiť neúspech projektu, zníženú kvalitu výsledného produktu, alebo zvýšenie nákladov na jeho realizáciu. Macošínec BranislavAbstrakt. Táto práca poukazuje, prečo je dôležité dokumentáciu vytvárať. Dokumentácia je vo všeobecnosti považovaná za nutné zlo pri vývoji softvéru. Mojím cieľom je poukázať, že tomu tak nemusí byť a vyváranie dobrej dokumentácie dokonca podporuje proces tvorby softvéru a tým pádom úspešné ukončenie projektu. Následne rieši otázky: Čo je dokument a čo obsahuje? V tejto práci tiež ukazujem, ako sa agilný vývoj softvéru stavia ku dokumentácii. Neskôr v dokumente stručne načrtnem, čo by mala dobrá dokumentácia obsahovať. V práci sa tiež zaoberám otázkou: Prečo ľudia potrebujú dokumentáciu. Ďalej tento dokument obsahuje zásady dokumentácie a jej členenie. Na koniec sa v práci budem zaoberať popisom rozdelenia dokumentácie do oblastí. Staráček ĽubošAbstrakt. Napriek dobre naplánovanému projektu, aj napriek použitiu nástrojov pre podporu manažmentu, vývoj softvéru v sebe stále nesie nejaké riziko neúspechu. Toto riziko je možné zmierniť zavedením manažmentu rizík s tým, že mu bude venovaná aj patričná pozornosť a dôslednosť. Niektoré štúdie ale naznačujú, že v dnešnej dobe ešte stále veľa firiem v niektorých svojich projektoch nepoužíva manažment rizík. Prečo je takáto situácia? Samozrejme, existujú aj také prípady, kedy manažment rizík nie je vhodné použiť. Čo však odrádza projektových manažérov od zavedenia manažmentu rizík v takých prípadoch, kedy by manažment rizík bol vhodný? Akými spôsobmi je možné túto situáciu zlepšiť? Toto sú hlavné otázky, na ktoré v tejto eseji ponúkam vlastný pohľad a možné riešenie.Turský LukášAbstrakt. Dnešné nepreberné množstvo komunikačných prostriedkov, ktorými sme obklopení nám navodzuje myšlienku existencie univerzálneho komunikačného prostriedku. V rámci rozobratia problematiky množstva prostriedkov sú v eseji identifikované dva extrémne prístupy komunikácie. Zároveň je zavedená myšlienka komunikačného plánu ako istého základu pre popísanie spôsobu komunikovania. Na základe identifikovaných prístupov je navodená otázka aký prístup a prostriedky použiť pre manažment komunikácie v menšom a agilnejšom projektovom tíme. Esej uvádza príklad výberu prostriedkov pre konkrétny tím, pričom sa sústreďuje predovšetkým na možnosti využitia sociálnej siete ako určitej formy neformálneho univerzálneho prostriedku pre komunikáciu. Popísané sú konkrétne výhody, ktoré vyplynuli z použitia sociálnej siete na tímovom projekte, spolu s nedostatkami a ohraničeniami. Záverom je vyhodnotená správnosť výberu sociálnej siete, pričom sa esej pozastavuje nad otázkou, či sú členovia tímov schopný aj vďaka vybranému prostriedku lepšie komunikovať.
|