Zbierka esejí 2013
Home Home EN
Skupina 2
Biroš Michal

Abstrakt. Pri riešení väčšieho softvérového projektu spolupracuje viacero rôznych ľudí, ktorí pracujú na rozličných úlohách. Aby bolo možné takýto projekt úspešne manažovať, je potrebné aby manažéri, ale aj zákazník vedeli zistiť v akom stave je tento projekt a aké kvalitné je dané softvérové riešenie. Tieto údaje môžu byť získavané a interpretované rôznymi spôsobmi. V súčasnosti sa venuje veľká pozornosť agilným metódam, ktoré dokážu zúčastneným stranám na projekte poskytnúť obraz o stave projektu a dodržiavania plánu jednoduchým a zrozumiteľným spôsobom. Tradičné monitorovanie však má tiež svoje opodstatnenie. V tejto eseji porovnám metódu získanej hodnoty (angl. earned value) ako metódu, ktorá sa často používa pri agilnom vývoji a GQM (Goal Question Metric) prístup ako zástupcu tradičného monitorovania.


Caban Tomáš

Abstrakt. Open-source softvér zaznamenal obrovský úspech a dnes sa s ním stretávame takmer neustále. Otvorený softvér sa rozšíril aj do komerčnej sféry, keďže si spoločnosti uvedomili jeho nesporné výhody. Stále mu je však vytýkaná nedostatočná kvalita a spoľahlivosť, pričom tieto názory sú často argumentované nevyužívaním klasických metód zaručenia kvality ako pri tradičnom vývoji softvéru. V tejto eseji sa zaoberám kvalitou open-source softvéru, metódami a prístupmi, ktorými sa dosahuje. Taktiež sa venujem otázke porovnania kvality open-source a komerčného softvéru a snažím sa odpovedať na otázku, či má open-source softvér nižšiu kvalitu ako komerčný softvér. V závere sa snažím zamyslieť nad možnosťami využitia metód, prostriedkov a techník open-source vývoja pri komerčnom vývoji za účelom dosiahnutia vyššej kvality.


Calík Jakub

Abstrakt. Každý softvérový vývojár sa snaží vytvoriť kvalitný softvér. Kvalita však nie je niečo, čo sa dá jednoducho odmerať počtom riadkov alebo podobne. Poznáme viacero aspektov, ktorých súhra a vyváženosť určujú celkovú kvalitu softvéru. Aby sa však na tieto aspekty nezabúdalo, a aby výsledkom vývoja bol naozaj kvalitný softvérový produkt, vzniklo množstvo metód a modelov pre vývoj softvéru [5]. Nie všetky metódy a postupy vývoja softvéru však kladú rovnaký dôraz na všetky aspekty kvality. Niektoré môžu vyzdvihovať až príliš, zatiaľ čo iné úplne zanedbávať. V poslednej dobe sa však stáva veľmi populárny agilný model vývoja, V tejto eseji sa preto budem snažiť objasniť, ako sa agilný vývoj softvéru postavil k aspektom kvality a ako by sa dali vylepšiť jeho nedostatky.


Gajdoš Jozef

Abstrakt. V dnešnej dobre prenikajú informačné technológie do všetkých odvetví ľudskej spoločnosti a to aj zdravotníctva. Zdravotnícky softvér sa stáva všadeprítomnou súčasťou zdravotníckych zariadení, pričom ide o veľmi špecifickú oblasť softvérových systémov. A to aj z pohľadu samotného softvérového riešenia, ako aj manažmentu rizík pri vývoji. Pri medicínskom softvéri je najväčšie riziko spojené s úmrtím pacienta alebo nevratným poškodením zdravia, a preto sa pri manažmente rizík siaha až po extrémnych opatreniach na to, aby sa tieto riziká eliminovali. V eseji porovnávam konkrétne postupy eliminácie rizika zlyhania v medicínskom softvéri s internetovým obchodom a bankovým systémom. Hodnotím vzájomnú aplikovateľnosť a zmysel riešení v týchto rôznych odvetviach.


Geier Martin

Abstrakt. Komunikácia medzi ľuďmi stojacich tvárou v tvár je zložitá a náročná, no zlepšujeme sa v nej každým dňom. Je na nej postavený úspech jednotlivcov i spoločnosti a tiež úspech ich projektov. Ako však úspešne komunikovať pri tvorbe projektu, ak sme od seba vzdialení stovky kilometrov a pritom nás delia rôzne jazyky a zvyky? V eseji opisujem výber komunikačného nástroja vhodného na komunikáciu v otvorených softvérových projektoch, umožňujúcich kolaboráciu neznámych ľudí bez priameho kontaktu. V ďalšej časti poskytujem pohľad na spôsoby komunikácie návrhu softvéru. V najväčšej časti eseje sa však venujem komunikácii o zdrojovom kóde, ktorý je dôležitým faktorom fungovania projektu. Analyzujem najčastejšie problémy, ktoré v komunikácii o projekte môžu vzniknúť a ktoré aj vznikajú. Následne navrhujem viac, či menej efektívne spôsoby ako komunikáciu k projektu usmerniť, alebo sa vyhnúť už tým častiam, ktoré usmernenie potrebujú.


Greguš Peter

Abstrakt. Nie je jednoduché vytvoriť kvalitný kód. Dosiahnuť tento cieľ je možné pomocou viacerých spôsobov. Avšak kedy vieme, že už sme vytvorili kód v požadovanej kvalite? Odpoveď na túto otázku nám poskytujú metriky kódu, ktoré nám prezrádzajú aký kvalitný kód máme. Podľa hodnôt, ktoré tieto metriky nadobúdajú, vieme posúdiť kvalitu dvoch kódov. Ak ale chceme posúdiť kvalitu samostatného kódu, musíme poznať hodnoty metrík pre kvalitný kód, aby sme dokázali určiť, či je daný kód kvalitný alebo nie. Spôsob ako z nekvalitného kódu dosiahnuť kvalitný kód je využívanie techník refaktoringu. Pomocou tohto nástroja dokážeme meniť štruktúru kódu tým spôsobom, že vylepšujeme jeho štruktúru (kvalitu), pričom nemeníme jeho vonkajšie správanie. Aplikácia refaktorizačných pravidiel sa odzrkadlí na hodnotách metrík určujúcich kvalitu kódu, avšak nie je vhodné sa ich pevne držať, ale využívať ich ako indikátory prípadných potrebných zmien v kóde. Preto je vhodné využívať refaktoring pri indikácii zmeny nevhodnými hodnotami metrík a nie ako prostriedok na vylepšovanie týchto hodnôt, nakoľko sa nám môže kód znehodnotiť. Je preto potrebné vedieť odhadnúť správnu mieru využívania refaktoringu.


Hlavenka Marián

Abstrakt. Najhoršie problémy, ktoré sa môžu objaviť počas priebehu softvérového projektu, sú tie neočakávané. Preto je nesmierne dôležité pre úspech celého projektu, vybrať správny postup manažmentu rizík hneď na začiatku projektu, aby sme určili všetky možné riziká a nestretli sa so žiadnymi neočakávanými problémami. Voľba nesprávneho alebo nevhodného postupu pre svoj tím, môže znamenať zbytočné komplikácie alebo aj kompletné zlyhanie samotného manažmentu rizík, čo môže viesť k zlyhaniu celého projektu. Ako vyberiem ten správny postup manažmentu rizík pre projekt? Ako závisí výber postupu od štruktúry tímu? Práve pre tieto otázky som hľadal odpoveď. Vybral som štyri postupy manažmentu rizík, ktoré porovnávam v ich vhodnosti pre rôzne štruktúry tímu počas všetkých fáz daných postupov. Každý postup má svoje uplatnenie v špecifických prípadoch, ale sú tu aj nedostatky, ktoré sa najlepšie odstránia kombinovaním viacerých postupov.


Hudák Miroslav

Abstrakt. Monitorovanie je dôležitou súčasťou manažmentu softvérového projektu. Cieľom tejto činnosti je včas identifikovať vzniknutý problém a podniknúť kroky k minimalizovaniu prípadných škôd. Častým dôvodom neúspechu projektu je zlý časový odhad a s tým spojené predraženie projektu. Preto je dôležité získavať relevantné informácie o stave projektu, aby sa včas dal aplikovať manažment zmien. V tejto eseji rozoberiem jednu z najpoužívanejších metód na monitorovanie projektu – analýzu dosiahnutej hodnoty, rozoberiem jej použitie pri agilnom vývoji softvéru a navrhnem jednoduchú metódu ako využiť túto techniku v malom projekte akým je študentský tímový projekt.


Kunka Tomáš

Abstrakt. Aj napriek dvom desaťročiam existencie manažmentu rizík a rozsiahlych výskumných programov je veľmi veľa softvérových projektov, ktoré končia zlyhaním. Len veľmi málo prostriedkov sa vynakladá práve na manažment rizík, aj keď je to nevyhnutná súčasť projektov. Esej rozoberá etické hackovanie ako techniku v manažmente rizík, ktorá nie je v našich končinách veľmi známa. Preberá bezpečnostné riziká etických hackerov a uvažuje ako by ich bolo možné odstrániť prostredníctvom správnej výchovy v škole. Tento proces vyučovania by sa dal zovšeobecniť a použiť vo viacerých oblastiach vzdelávania. Pripája tiež kritický pohľad na etických hackerov a hľadá miesto v procese manažmentu rizík, kde by bolo využitie tejto techniky najvhodnejšie.


Lekeň Tomáš

Abstrakt. Súčasťou každého softvérového produktu je dokumentácia najrôznejších druhov. Bežný používateľ, ktorý nie je technicky zdatný, prichádza najviac do styku s používateľskou príručkou. Práve preto by mali byť kladené najvyššie nároky na jej čitateľnosť a zrozumiteľnosť. K zrozumiteľnosti veľkou mierou prispievajú aj nové formy dokumentácie, akou sú napríklad video tutoriály, ktoré umožňujú jednoducho predviesť používanie vybranej funkcionality. Esej sa sústreďuje na problematiku čitateľnosti a jednoduchosti vytváranej dokumentácie.


Martinkovič Milan

Abstrakt. Pri vytváraní softvérového produktu je práve činnosť plánovania a tvorenia rozvrhu tou, na ktorú sa nekladie náležitý dôraz a to aj napriek tomu, že kvalitným plánovaním zabezpečíme plynulý chod celého procesu vývoja softvéru. Navyše vďaka plánovaniu sme si schopní uvedomiť určité kľúčové súvislosti v našom projekte v dostatočnom predstihu. Medzi takéto súvislosti môžu patriť jednak potrebné zdroje, ktorými sú ľudia, hmotné alebo nehmotné prostriedky a podobne. Na základe identifikácie týchto entít môžme následne odvodiť nosné vlastnosti projektu ako napríklad potrebný rozpočet a podobne. Aj napriek týmto nesporným výhodám sa však stáva, že v dôsledku zanedbania poctivého plánovania si takéto organizácie nevedome naplánujú svoj vlastný koniec. Na to aby sme znížili riziko možných chýb sa musíme dopracovať k faktoru, ktorý nám dokáže v dostatočnom predstihu napovedať o tom ako dobrý náš plán môže byť. Jedným z takýchto faktorov je napríklad skúsenosť s plánovaním, ktorá významnou mierou ovplyvňuje konečnú podobu plánu.


Šinský Peter

Abstrakt. Jednou z najdôležitejších úloh pri vytváraní plánu je odhadovanie času. Odhadovanie je súčasťou procesu plánovania a cieľom je stanoviť časový odhad, ktorý hovorí o čase potrebnom pre vykonanie úloh. Na základe takto odhadnutého času potom dokážeme vytvoriť plán, podľa ktorého sa môžeme riadiť počas celého vývoja projektu. Existuje však niekoľko spôsobov ako sa k odhadovaniu postaviť. V eseji prinášam prehľad vybraných metód odhadovania času. Na základe toho som vymyslel príklad, ako by sa dali tieto metódy skombinovať a vytvoriť tak dokonalý odhad. Ako sa na prvý pohľad zdá, skombinovať všetko a snažiť sa využiť len to najlepšie, nemusí byť výhra. Treba sa zamyslieť nad tým, aké následky takýto prístup môže priniesť. Nebude to všetko trvať príliš dlho? Bude jasno v tom, koľko času sme vlastne odhadli? Máme motiváciu takto postupovať?


Sivák Peter

Abstrakt. Použitie verziovacieho systému v akomkoľvek projekte sa považuje za nevyhnutnosť. Kedysi boli k dispozícii iba centralizované typy systémov, ale postupom času sa vyvinuli distribuované prístupy k verziovaniu – treba si vybrať jeden z nich. Distribuovaný systém sa stáva čoraz populárnejším, čo ale neznamená, že si ho automaticky vyberiem. Cieľom mojej eseje je ukázať, že obidva prístupy majú svoje výhody aj nevýhody a až po dôkladnej analýze sa dá zodpovedne zvoliť jeden z nich, ktorý bude pre projekt prínosnejší. Analyzujem tu rôzne aspekty, ktoré môžu mať vplyv na konečné rozhodnutie. Dotýkam sa tu problému prístupu k repozitáru, čo sú klady a zápory distribuovania, aké veľké tímy kooperujú na danom projekte a ktoré riešenie je pre nich lepšie. Ďalej popisujem potenciálne riziká vyplývajúce z nepravidelného ukladania verzií na server a ku koncu eseje sa venujem prechodu medzi verziovacími systémami a aké prínosy a náklady to so sebou prináša. Treba si taktiež uvedomiť, ktorý aspekt má pre vývojový tím väčšiu prioritu a aj to zahrnúť do finálneho rozhodnutia.


Staňo Filip

Abstrakt. Komunikácia je základom každého spolužitia a spolupráce ľudstva. Pri tvorbe softvérových tímových projektov je výber správnej komunikácie oporným bodom spolupráce. Aj z tohoto dôvodu sa v tejto eseji pokúsim priblížiť jednotlivé formy komunikácie v rámci softvérového projektu. Predmetom eseje bude distribuovaná a lokálna komunikácia a odôvodnenie, prečo je lokálna výhodou. Následne približujem formálne a neformálne jednanie v tíme, vplyv oboch na celkovú morálku a taktiež navrhujem správnu kombináciu oboch. V neposlednom rade opisujem aj synchrónnu a asynchrónnu komunikáciu a pokúšam sa identifikovať kritéria, kedy vybrať, ktorú z metód. V tejto eseji detailne priblížim rozdiely medzi spomínanými metódami komunikácie a následne opisujem dôsledky týchto rozdielov. Neskôr rozoberiem aplikovateľnosť jednotlivých metód v rozličných situáciach a prípadné bežné dôsledky nesprávneho výberu metódy. V eseji porovnávam vhodnosť spomínaných metód podľa toho, či sa jedná o menšiu, či väčšiu skupinu ľudí, tiež podľa toho, v akej vývojovej fáze softvéru sa tím nachádza.


Szilva Bálint

Abstrakt. Oblasť softvérových a informačných systémov sa neustále zväčšuje a každým dňom pracujú tisícky ľudí na tom, aby tieto systémy boli čo najmodernejšie a čo najspoľahlivejšie. Pre správne fungovanie týchto systémov je nevyhnutné, aby boli správne konfigurované, alebo boli konfigurovateľné. Niekedy je najlepšie, keď používateľ môže softvér nakonfigurovať a nastaviť sám pre seba. V tejto eseji sú zahrnuté najdôležitejšie myšlienky o tom, kedy sú konfigurácie vhodné a kedy nie, kedy nechať používateľovi možnosť softvér nakonfigurovať sám. V eseji sa ďalej nachádzajú úvahy o možnostiach a typov konfigurácií rôznych softvérových systémov, najlepšie cesty konfigurácie ako aj možnosti konfigurácií na určitých úrovniach softvéru.


Szórád Anton

Abstrakt. Pri procese vývoja softvéru je dôležitá jeho kvalita. Táto esej rozoberá tento pojem nielen vo všeobecnosti, ale aj ako kvalitu týkajúce sa softvérového vývoja. Aby sa softvérová kvalita mohla merať a udržiavať na vysokej úrovni, sú potrebné pomocné nástroje. V súčasnosti je ich veľa, pričom mnohé používajú iné pomocné nástroje overené v manažmente kvality v iných odvetviach Táto esej ponúka pohľad na tieto nástroje. Rozoberá možnosti použitia pomocných nástrojov s cieľom udržania kvality celého procesu vývoja, ich výhody a nevýhody a ponúka odporúčania ako tieto pomocné nástroje používať.


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