Zborník esejí 2011

Abstrakt: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ý. Zle vytvorený projektový plán je najčastejším dôvodom zlyhania softvérových projektov. V eseji sa identifikujú chyby, ktoré sa môžu stať pri tvorbe plánov. Poukazuje sa na nedostatky zlého plánovania a ponúknutý je spôsob ako rozpoznať zlý plán. Esej opisuje aj najčastejšie príčiny zlyhania plánov. Ponúknutý je spôsob ako predísť zlyhaniu plánov a ukázané je, že plán nie je iba niečo, čo zaberá čas, ale viac prostriedok na vylepšenia procesu tvorby softvérových systémov.

Abstrakt:Proces vývoja softvéru musí zohľadňovať oblasť z reálneho sveta, ktorú modeluje. Problematickosť vyjadrenia špecifikácie spoločne s jej priebežnými zmenami sa stali hlavnou bariérou jednoznačne určeného cieľa pre softvérový produkt. Vývoj softvéru tak bežne musí počítať s určitou mierou neistoty a uspôsobiť plán natoľko, aby dokázal dané zmeny pokryť. Nehovoríme však o okrajovom pokrytí neočakávanej zmeny, ale o jej plnohodnotnom spracovaní pre dosiahnutie požadovanej úrovne kvality. Správne zapracovanie zmeny do systému musí byť konzistentné s doterajším stavom a naďalej musí umožňovať jeho rozširovanie prípadným, vopred málo očakávaným smerom. Rozdiely medzi pohľadmi na vývoj medzi vodopádovým modelom, iteratívnou/ inkrementálnou metodológiou a agilnými metódami vývoja sú vhodnými kandidátmi na analýzu povahy kvality. Záverečné zistenia ustanovujú, že zmeny v procese vývoja softvéru môžu byť efektívne zachytené a spracované. Dokonca samotné zabezpečenie kvality má tendenciu byť úspešnejšie u procesov, ktoré sú na zmenu stavané.

Abstrakt:Monitorovanie softvérového projektu je činnosť, ktorá zabezpečuje kontrolu nad priebehom samotného projektu a môže včas odhaliť možné problémy, ktoré môžu v rámci tohto procesu vzniknúť. Softvérové projekty sú však často rôznorodé, zložitosť ich monitorovania sa v mnohých prípadoch odlišuje, a tak boli v uplynulých rokoch vypracované rôzne metodológie na ich monitorovanie. Príkladom rôznorodosti softvérových projektov je open-source projekt na jednej strane a klasický projekt na strane druhej, kde je zrejmé, že ich monitorovanie bude prebiehať rozdielne. Táto esej poskytuje pohľad na rôzne prístupy k monitorovaniu softvérových projektov v závislosti od typu projektu, ktorý chceme monitorovať, poukazuje na faktory ovplyvňujúce tento proces a konfrontuje vybraný prístup s možnými problémami, ktoré môžu pri danom type projektu nastať.

Abstrakt:Mnohým neúspechom z oblasti softvérových projektov by bolo možné predísť investovaním dostatočnej pozornosti a energie do manažmentu rizík. V softvérovom projekte ide v prvom kroku najmä o identifikáciu potenciálnych rizík, ich analýzu, pridelenie priority. Skončiť iba tu však pre projekt znamená v budúcnosti potenciálne problémy vedúce až k úplnému zlyhaniu - plánovanie rizík a ich monitorovanie má sprevádzať celý proces. Esej pojednáva o kontinuálnom manažmente rizík a o presahu manažmentu rizík z jedného projektu do druhého. Výstupom procesov takto premysleného a cielene zapájaného manažmentu rizík v rámci viacerých softvérových projektov sú okrem iného skúsenosti a znalosti, ktoré softvérový tím s výhodou využíva pri ďalších projektoch. Odhad rizík a ich riadenie sa vďaka schopnostiam členov tímu darí zvládať lepšie, darí sa lepšie predchádzať rozvinutiu rizík. Avšak spomenuté znalosti a skúsenosti zostávajú v hlavách členov tímu. Táto esej hľadá možné odpovede na otázky ako v súvislosti s manažmentom rizík v malom projekte efektívne vyextrahovať a zhromažďovať skúsenosti a znalosti členov tímu, formalizovať, organizovať ich, zabezpečiť ich prístupnosť a tak ich zachovať aj v prípade odchodu skúseného člena tímu a znovupoužiť ich pri nových projektoch. Ponúka možnosti rozvoja manažmentu znalostí v prospech efektívneho manažmentu rizík.

Abstrakt:Nie je to dávno, keď sa pri výbere vhodného uchádzača o zamestnanie alebo o prácu na úlohe pozeralo predovšetkým na jeho odbornú kompetenciu a v mnohých spoločnostiach je tomu tak aj dnes. Avšak čoraz viac sa hlavne v popredných firmách začína klásť dôraz na osobnosť a povahové vlastnosti zamestnancov, keďže odborné znalosti sa dajú získať pomerne ľahko v porovnaní s úsilím, ktoré je nutné vynaložiť na dosiahnutie stanovených cieľov v nefungujúcom tíme. Nejedna štúdia sa už zaoberala spôsobmi zatriedenia ľudí do skupín podľa ich osobnosti a vplyvom tejto osobnosti na schopnosť pracovať v tíme a zastávať rôzne pozície v rámci tímu alebo celej organizácie. V mojej eseji sa venujem úvahe o vhodnosti jednotlivých osobností a ich atribútov pre konkrétne pozície v tíme nie len z pohľadu schopnosti plniť ich úlohy, ale aj z pohľadu ich vzájomnej kompatibility, schopnosti znášať sa a spolupracovať na ceste k spoločnému cieľu. Taktiež sa zamýšľam nad ďalšími faktormi ovplyvňujúcimi výkon tímu, medzi ktoré patrí napríklad motivácia, ktorá súvisí ako s odbornou kompetentnosťou, tak aj s osobnosťou človeka.

Abstrakt:Tvorbou a dodaním vysoko kvalitného softvéru staviame základ úspešného softvérového inžinierstva. Ako ale túto kvalitu dosiahnuť? Ciest ku kvalitnému softvéru je viacero. Dôležité je vybrať správny model pre tvorbu systému. V eseji som prediskutoval tri moderné existujúce modely, konkrétne RUP, MSF a XP. Porovnaním a skombinovaním ich vlastností získame ideálny model. Je to ale naozaj tak? Okrem výberu správneho modelu je taktiež dôležité zvoliť vhodný spôsob testovania, ktoré zvyšuje kvalitu softvéru. Testovanie je potrebné správne vybrať aj na základe zvoleného modelu. V eseji som opísal ideálne princípy testovania, na ktoré je v teoretickom svete zameraná pozornosť a snaha na ich docielenie. Dajú sa v skutočnom svete naozaj dosiahnuť? Nemalo by väčší význam zaoberať sa napríklad komunikáciou v tíme? Alebo na motiváciu vývojárov aby sa zamerali na kvalitný vývoj?

Abstrakt:Tvorba softvéru je náročný proces. Často sa na ňom podieľa mnoho ľudí, ktorí tvoria jeden alebo viacero tímov. Nato, aby sa dosiahol požadovaný úspech, nestačia len vedomosti, ale je potrebné zabezpečiť dokonalé fungovanie jednotlivých tímov. Z časti sa to dá zabezpečiť analýzou osobností. Táto analýza môže potom slúžiť ako pomôcka, určujúca, kto má na akú rolu najväčšie predpoklady. V eseji sa zaoberám dvoma metódami, pomocou ktorých sa dá určiť typ osobnosti, konkrétne Myers-Briggs osobnostný indikátor a Keirseyho triedenie povahy. Na základe týchto dvoch metód som rozanalyzoval zloženie nášho tímu v rámci predmetu Tímový projekt. Uvažoval som, aké by bolo najideálnejšie pridelenie rolí v rámci tímu, pričom som vychádzal z reálnych štúdií z oblasti softvérového inžinierstva.

Abstrakt:Žiadna skupina ľudí nemôže existovať bez toho, aby neprebiehala komunikácia či už medzi jej jednotlivými členmi, alebo medzi toutu skupinou a okolitým svetom. Inak tomu nebude ani v tíme, konkrétnejšie v tíme pracujúcom na softvérovom projekte. Pre čo najrýchlejšie či najefektívnejšie dosiahnutie výsledku by komunikácia v tíme mala byť kvalitná, vhodná, bohatá, otvorená a presná. Z tohto je jasné, že aj komunikáciu treba riadiť, plánovať, manažovať. K tomu slúžia rôzne podporné prostriedky uľahčujúce plánovanie komunikácie a komunikáciu samotnú. Ktoré prostriedky si však vybrať a ako ich správne využívať? A má zmysel použiť ich aj pri malých alebo len pri veľkých tímoch? Čo robiť, ak komunikácia zlyhala, alebo lepšie, ako takémuto scenáru predísť? Pokúsim sa odpovedať na tieto otázky a zhrnúť moje myšlienky do tejto eseji.

Abstrakt:Vývoj softvéru je komplexný proces, pri ktorom môžu mať nesprávne rozhodnutia nežiaduce následky. Je naozaj vhodné riešiť tieto následky, až keď nastanú? Nebolo by lepšie prehodnotiť rozhodnutia, a tak predísť následkom alebo ich aspoň potlačiť? Plánovanie a vytýčenie toho, čo je nutné spraviť pri vývoji softvéru, je základ, ale nestačí to. Vzhľadom na to, že projekty nebežia vždy podľa plánu, je potrebné zahrnúť do procesu aj manažment rizík. Ten umožňuje skoré identifikovanie a rozoznanie rizík a následné prispôsobenie procesu vývoja tak, aby sa riziká zredukovali alebo zmiernili ich následky. Väčšinou sa na manažment rizík pozerá z pohľadu vývojára. Treba si ale uvedomiť, že pre zákazníka je kúpa softvéru taktiež riskantný proces. Napríklad omeškanie nasadenia systému znamená problém pre obe strany. Esej sa zaoberá zahrnutím zákazníka do manažmentu rizík softvérového projektu. Analyzuje výhody a nevýhody spojené s tímovým (zjednoteným) manažmentom rizík zákazníka a dodávateľa a porovnáva ho s klasickými postupmi.

Abstrakt:Pre kontrolu dodržiavania plánu pri tvorbe softvérového projektu je veľmi dôležité jeho monitorovanie. Na sledovanie stavu projektu nám slúžia metriky, s rôznou mierou komplexnosti, spoľahlivosti ako aj výpovednej hodnoty. Výber vhodných metrík a citlivý prístup k ich vyhodnocovaniu môže mať kľúčový dopad na splnenie časového harmonogramu a vyhnutiu sa rôznym iným problémom. Táto esej sa zaoberá problematikou do akej miery sa môžeme spoliehať na metriky a vyvodzovať z nich dôsledky a súčasne skúma do akej miery nám môžu tieto metriky odhaliť pravý dôvod vzniku problému. Esej sa snaží pomocou analýzy a porovnávania rôznych techník monitorovania softvérového projektu poukázať na dôležitosť ľudského faktoru pri výbere vhodných metrík a ich správnom vyhodnocovaní.

Abstrakt:Vývoj softvéru je veľmi zložitá a rôznorodá problematika. Na jednom projekte zvyčajne pracuje viacero ľudí. Každý z nich má na starosti určitú oblasť, v ktorej je expertom. Aby bol tento proces efektívny, musí byť dobre riadený. Čo je však potrebné na úspešný manažment v procese vývoja softvéru? Dôležité je aby manažéri mali dostatočné podklady na konanie svojich rozhodnutí. Nie je však možné, aby rozumeli všetkým činnostiam, ktoré vykonávajú ich podriadení. Na riešenie tohto problému sa používajú rôzne metódy a nástroje, ktoré majú priblížiť prácu programátorov a analytikov ich nadriadeným. Tento jav platí aj z opačnej strany pri definícii požiadaviek. Existujú aj iné oblasti v manažmente vývoja softvéru, kde sa dajú použiť podporné prostriedky? V tejto eseji pojednávam o oblastiach aplikácie podporných prostriedkov v softvérovom inžinierstve. Zameriavam sa na ich využitie v oblasti vizualizácie softvéru a definície požiadaviek