Zborník esejí 2010

Abstrakt:Jeden z hlavných cieľov každého softvérového tímu by malo byť dokončiť svoj projekt. Na splnenie tohto cieľu je ale treba splniť veľa úloh a dokončiť veľa menších častí. Projektový manažér, ktorý takýto projekt riadi, preto musí mať prehľad o tom, ako sa na častiach a úlohách pracuje a ako projekt odpovedá časovému plánu. Samotné obchádzanie a kontrolovanie všetkých zamestnancov je už dlho neefektívne. Preto každý riadiaci pracovník používa podporné prostriedky na správu softvérových projektov. Zameriam sa na to, ktoré podporné prostriedky majú svoje uplatnenie v malých tímoch. Tiež bude mojim cieľom objasniť, ako tento prostriedok pomáha celému tímu a hlavne projektovému manažérovi. Aké časté môže byť ich využitie a aké časté by malo byť. Najdôležitejším aspektom však vždy ostáva výsledná efektívnosť prostriedku pre tím.

Abstrakt:Význam plánovania v softvérových projektoch je pomerne jednoznačný. Plánovať má určite zmysel, či už ide o malé alebo veľké tímy tvoriace softvérový produkt. Dokonca aj význam plánovania v školských projektoch na úrovni tímových projektov je veľmi dôležitý a očividný. Ale ako je to so školskými softvérovými projektmi, ktoré vytvára iba jeden študent? Myslím si, že plánovanie má význam aj v takomto špecifickom projekte s relatívne malým rozsahom. Ponúkam dôvody, prečo by mal študent vo svojich projektoch plánovať, pričom niektoré sa môžu zdať triviálne, ale už len ich uvedomenie zohráva významnú úlohu v procese tvorby projektu. Ukazujem, že posunutie od intuitívneho plánovania školských projektov k reálnemu plánovaniu nemusí byť veľký skok, ale na druhej strane môže mať veľký prínos pre študenta.

Abstrakt:Meniace sa podmienky sú častým úkazom pri tvorbe softvéru v tíme. Zmena špecifikácie či ďalšie želania zákazníka nás nesmú prekvapiť. Je to fakt, s ktorým sa musí každý vývojár a manažér stotožniť. Časy, kedy sa testovanie nechávalo ako posledná fáza vývoja, už nie sú aktuálne. Kladieme dôraz na to, aby sme chyby podchytili v skorom štádiu. Takýto objav nám poskytne neoceniteľný prínos ku kvalite produktu. V softvérovom vývoji dlhšie tvoríme postupy ako zabezpečiť kvalitu už od inicializácie projektu a súčasne sa vyrovnať stálym zmenám prostredia. V tejto eseji sa pozerám práve na možnosti ako zabezpečiť a udržať kvalitu projektu v malom tíme od začiatku až po koniec. Vyberiem vhodné postupy testovania a poskytnem ich hodnotenie ako sa dokážu uplatniť v malom tíme. Medzi ne patria napríklad metóda stálej integrácie, automatické testy a vývoj riadený testami. Zhodnotím správnu disciplínu a prístup vývojára pri tvorbe kvalitného produktu. Zamyslím sa nad možným vývojom testovania do budúcnosti.

Abstrakt:Pri práci v rámci predmetu Tímový projekt sa väčšinou zíde 5 - 7 študentov, ktorý počas dvoch semestrov vykazujú konzistentnú činnosť na dosiahnutie spoločného, dopredu dohodnutého cieľa. Tento cieľ je v konečnom dôsledku dvojaký v prvom rade si majú vyskúšať prácu na rozsiahlejšom projekte v rámci tímu a tímových rolí, ale netreba zabudnúť na to, že výsledkom ich práce by mal byť aj nejaký produkt. Vedomosti si študenti po skončení predmetu odnesú do praxe a produkt sa v prípade že má vyslovene vzdelávací charakter alebo teoretický prínos využije na pôde školy. Ak takéto vlastnosti nemá, zväčša zapadne prachom. Študenti väčšinou nevyužijú prípadný komerčný potenciál zadania, ktorého rozvinutie by ich nestálo príliš veľa snahy navyše, možno čiastočne preto, že si neuvedomujú čo môžu získať alebo ich brzdí nedostatok vedomostí o tom, ako taký začínajúci biznis funguje. Myslím si však, že jedným z hlavných dôvodov neprenesenia projektu do komerčnej sféry je obava, že to proste nevyjde. V tejto eseji skúsime túto obavu kvantifikovať pomocou analýzy pozitívnych a negatívnych rizík, pouvažujeme nad metodikou na úpravu ich pravdepodobností a celkovo sa zamyslíme nad tým ako úspešne absolvovať konverziu tímového projektu na komerčne úspešný projekt.

Abstrakt:V procese vývoja a tvorby softvérového produktu je potrebné mať neustály prehľad nad postupom projektu. Sledovaním jeho postupu zabezpečíme viditeľnosť projektu v každej fáze jeho vývoja. Aby sme toho dosiahli, potrebujeme sledovať kritériá, charakterizujúce atribúty softvérového projektu. Tie nám pomáhajú hodnotiť softvérový výrobok a proces, ktorý prebiehal pri jeho tvorbe. Avšak nástroje, ktoré používame pri monitorovaní projektu, nám nemusia vždy zaručiť prísun relevantných informácií o stave produktu. Získané dáta je potrebné pozorne študovať a hlavne si byť vedomý, čo v skutočnosti reprezentujú. Tieto nástroje sú preto len prostriedkom, ktorý nás môže doviesť k vytýčenému cieľu a je len na nás, ako ich využijeme. V tejto eseji vám predvediem, že je potrebné pochybovať o dátach získaných z jednotlivých metrík a tiež je opodstatnené nedôverovať samotným metrikám.

Abstrakt:V dnešnej dobe vznikajú každý deň nové softvérové produkty. Na nich sa často podieľa skupina ľudí, ktorí spolupracujú v tíme. Aby mohol takýto produkt vzniknúť v dobrej kvalite a v krátkom čase, je dôležité zloženie tímu, ktorý sa na jeho vývoji podieľa. Táto esej analyzuje jednotlivé faktory, ktoré môžu ovplyvniť tím, jeho efektivitu a spoluprácu. Rozoberá charakteristiku osobnosti z hľadiska Hippokrata, C. G. Junga a Myers - Brigss. Každý vyvinul inú metodológiu na rozlíšenie osobnosti. Ďalším nemenej dôležitejším bodom je dobrá komunikácia a schopnosť riešiť konflikty. Návod ako zostrojiť ideálny tím neexistuje, avšak ja sa pokúsim priblížiť jednotlivé faktory, porovnať ich a aplikovať na svoj tím. V neposlednom rade chcem poukázať na dôležitosť pochopenia a tolerovania chýb druhých a na ich následné vylepšenie. Je to dôležité nielen pre prácu v tíme, ale aj pre samotný život.

Abstrakt:Každý softvérový projekt potrebuje riadenie. Pokiaľ by sme ho ignorovali, viedlo by to k chaosu a všeobecnej nespokojnosti, tak vývojového tímu ako aj zákazníka. Riadenie ľubovoľného procesu nie je jednoduché a správne rozhodovanie bez kvalitných podkladov je veľmi ťažké. Reálny pohľad na aktuálny stav vývoja softvérového projektu poskytujú rôzne nástroje pre sledovanie plnenia úloh, využívania zdrojov, odstraňovania chýb, plnenia plánov a mnohých ďalších aspektov odzrkadľujúcich pokrok. To všetko si ale vyžaduje tým pádom dodatočné písanie, dokumentovanie a ďalšiu pridanú hodnotu zo strany tímu. Táto esej rozoberá, či je toto všetko potrebné len pre riadenie, ktoré má na pleciach vedúci tímu. Ako to vplýva na ostatných členov, na ich spoluprácu a produktivitu. Esej sa zaoberá hlavne odpoveďami na otázky: Komu však naozaj pomáhajú podporné prostriedky? Slúžia len vedúcemu tímu alebo celému tímu? Môžu pomôcť k lepšej motivácii?

Abstrakt:Plánovanie softvérového projektu prináša určité riziká, ktoré sa niekedy nedajú dopredu určiť. Odhady trvania prác môžu byť problematické najmä pre menej skúsených manažérov, napr. aj tých, ktorí vedú školské projekty ako Tvorba softvérového systému v tíme. Preto sa môže stať (a často sa aj stáva), že projekt nenapreduje požadovaným smerom, tempom, nastávajú časové sklzy. Vtedy je úlohou manažérov, resp. vedúceho projektu rozhodnúť sa pre alternatívy, ktorými môžeme dohnať stratu, vrátiť sa na správnu cestu. V eseji sa zamýšľam nad krízovými situáciami v projektoch a analyzujem alternatívy, ktoré sa odporúčajú pri podobných krízových situáciách (prechod na extrémne programovanie, atď.). K analýze týchto riešení pristupujem z hľadiska predmetu Tvorba softvérového systému v tíme.

Abstrakt:Kvalita v dnešnej dobe vyspelej konkurencie a uvedomelých zákazníkov predstavuje často opakované slovo na mnohých firemných poradách. Rovnaká situácia je aj v softvérovej oblasti. Firmy sa snažia vyvíjať kvalitný softvér aby uspokojili požiadavky zákazníka, získali si dobré meno, primeraný zisk a aby minimalizovali náklady na riešenie problémov súvisiacich s nekvalitným softvérom. Samotný pojem kvalitný softvér je však ťažké definovať a samozrejme existuje veľa spôsobov, ako ho vytvoriť. Myslím si, že je chybou ak sa testovanie kladie ako posledná inštancia, ktorá by mala zaručiť vytvorenie kvalitného produktu. V tejto eseji sa preto zameriam na vzťah kvality a testovania. Pokúsim sa spresniť pojem kvalitný softvér a bližšie špecifikovať úlohu testovania v procese vývoja softvéru. Táto špecifikácia by mala zabrániť nereálnym očakávaniam a nevhodnému nasadeniu testovania do vývoja produktu.

Abstrakt:Každému sa už stalo pri nejakej činnosti, že na nej pracoval dlhšie ako očakával. V rámci vývoja informačných a softvérových projektov by takéto zdŕžania znamenali neúspech, preto sa využíva pri vývoji manažment rizík. Študentské tímy pracujúce na tímových projektoch počas štúdia prichádzajú do styku s novými technológiami a úlohou ktorú ešte nemali. Ide o úlohu vedúceho tímu alebo zodpovedného za určitú časť systému. Čitateľ si môže prečítať o metódach identifikácie rizík a uvedú sa metódy, ktoré by mali byť najvhodnejšie pre malé pracovné tímy a taktiež postačujúce pokryť dostatočne oblasť projektov, na ktorých tieto tímy pracujú. Zväčša ide o projekty menšieho rozsahu a menšej zložitosti. Identifikácia rizík je len časť manažmentu rizík, takže pre ozrejmenie problémovej oblasti je v eseji uvedený základ manažmentu rizík a jeho realizácia v praxi.

Abstrakt:Pri monitorovaní softvérového projektu sa sledujú jeho vybrané metriky. Navzájom sa môžu od seba líšiť úrovňou, uhlom pohľadu na projekt a tiež svojou presnosťou. Úspešnosť projektu, jeho dynamickosť a pružnosť zabezpečuje práve monitorovanie. Preto je dôležité zamyslieť sa nad tým, ktoré metriky vyberať. Kedy nám metriky poskytujú pravdivý obraz o projekte a kedy môžu naopak zavádzať? Esej uvažuje zaužívané spôsoby merania softvérového projektu, ich kladné a záporné stránky. Okrem toho naznačuje nové myšlienky, ako s metrikami pracovať. Každý merací postup vedie k samostatným výsledkom. Môžu tieto výsledky poskytnúť viac ako priamočiaru odpoveď? Medzi zdanlivo nesúvisiacimi metrikami existujú skryté prepojenia. Výsledok jednej metriky sa možno dá vyrátať inou metrikou. Nikde to nie je napísané, ale intuitívny pohľad na problém to potvrdzuje. Esej hľadá nové súvislosti a snaží sa novými pohľadmi na vec posunúť hranice využiteľnosti merania softvérového projektu.

Abstrakt:Správne rozdelenie úloh v tíme na projektoch je náročná úloha, s ktorou sa manažéri stretávajú vždy pri ich plánovaní. Každý tím je tvorený ľuďmi, ktorí sa vyberajú pre daný projekt už nielen na základe ich vedomostí a schopností, ale aj podľa ich psychologického a osobnostného profilu. Často sa prihliada aj na celkovú komunikáciu a schopnosť spolupráce ľudí v tímoch, čo sú vlastnosti tvorené jednotlivými čiastkami jeho členov. Zatiaľ čo ich schopnosti a vedomosti vytvárajú funkčnú časť projektu, ich vlastná a jedinečná osobnosť spolu s motiváciou tvorí časť ducha celého tímu. V eseji pojednávam o osobnostných charakteristikách členov tímu. Popritom sa zameriavam na určitý súlad, alebo rozpor medzi znalosťami a samotnou osobnosťou člena tímu. Sledujem spôsob vzájomnej interakcie medzi ľuďmi a ich komunikáciu v rôznych situáciách vyplývajúce z ich charakteristických a jedinečných osobností.

Abstrakt:Moja odborná esej je ohraničená priestorom tém podporných prostriedkov pre riadenie softvérového projektu, so zameraním na využitie ľudských zdrojov a sledovanie úloh. Obsahuje úvod do problematiky riadenia softvérového projektu. Snaží sa zistiť, aké možnosti pre samotnú podporu riadenia a plánovania, prípadne sledovania úloh existujú. Je ich niekoľko, ako napríklad Ganttova alebo sieťová schéma. Skúma, ktoré vlastnosti sú pri podporných prostriedkoch softvérovými inžiniermi vyžadované, respektíve želateľné. V eseji sú priblížené niektoré komerčné a open-source nástroje pre podporu riadenia softvérového projektu, snažím sa o ich objektívne porovnanie vzhľadom na skupinu niektorých funkcií. Esej ďalej prináša autorov názor na otázku potrebnosti komplexných nástrojov pre plánovanie pri menších projektoch.

Abstrakt:Úspech každého väčšieho projektu je už od začiatku odsúdený na neexistenciu, ak započatiu prác na projekte nepredchádza plánovanie. Vytvorenie, a predovšetkým udržiavanie plánu a jeho priebežné prispôsobovanie okolnostiam je esenciálne pre udržanie správneho smeru vývoja projektu. Plán by mal hľadieť dopredu. Odhaliť situácie, ktoré by mohli nastať, a predložiť návod, ako ich zvládnuť. Aj keď práve plán by mal predchádzať všetkým nečakaným situáciám, pred prekvapeniami členov tímu dokonale ochrániť nedokáže. Preto je dôležité aktualizovať plán a nespoliehať sa na jeho prvú verziu, ktorá bola vytvorená bez znalostí o priebehu projektu. Pri vytváraní plánu je dôležité zohľadniť všetky dostupné informácie. Často sa však zabúda na zohľadnenie dynamiky progresu vývoja projektu. Táto esej sa zaoberá predovšetkým prispôsobovaním stratégie plánovania doterajšiemu vývoju, a zohľadňovaním nadobudnutých skúseností pri odhadoch budúceho vývoja.

Abstrakt:Každá činnosť vrátane zastávanie určitej pozície na práci v softvérovom projekte so sebou prináša riziko vytvárania chýb, ktoré znehodnocujú výsledný softvérový produkt, znižujú jeho akosť. Sú dve možnosti ako tento problém riešiť. Tou prvou je snaha eliminovať generovanie chýb, čo je však nadľudská a pravdepodobne neriešiteľná úloha. Naopak druhou, omnoho jednoduchšou možnosťou je snaha vyhľadať tieto chyby a zabrániť tak ich prípadnému šíreniu, čo vo veľkej miere prispeje ku kvalite výsledného softvérového produktu. Vyhľadanie chýb možno riešiť testovaním. Práve aspekty testovania, kedy a ako testovať, sa pokúsim objasniť v nasledujúcich riadkoch. Načrtnem možné spôsoby testovania a porovnám ich medzi sebou. Uvediem zaujímavú vývojovú metodiku Test Driven Development a uvediem svoj postoj k problematike.

Abstrakt:Riziko a možné problémy sa stali súčasťou všetkých veľkých projektov, či už sa jedná o softvérové alebo iné. Každý jeden vytváraný projekt je v dnešnej dobe sprevádzaný rizikami väčšieho či menšieho charakteru. Tie sa odrážajú vo finálnom výsledku, či už v jeho kvalite alebo cene, čo sú v dnešnej dobe veľmi dôležité faktory. V tejto práci sa pokúšam vysvetliť, čo presne pojem riziko znamená, ako jeho podcenenie prechádza do samotného problému. V eseji dominuje taktiež otázka, prečo vlastne riziká riešiť a prečo nepodceňovať ani analýzu. Keďže riziká sa bytostne dotýkajú aj samotných programátorov a pracovníkov, popisujem aj ich správanie sa pod vplyvom rizík a problémov.

Abstrakt:Pri vytváraní softvérového produktu môžu vzniknúť viaceré problémy v tíme a bývaju zvyčajne vážnejšie, čím väčší tím sa podieľa na projekte. Nie je žiadnou novinkou, že na ich riešenie vznikol monitoring projektov. Vďaka nemu sa manažéri snažia dosiahnuť efektívne využitie prostriedkov. Monitoring sa ale nedá brať iba jednoducho ako riešenie problému, keďže môže priniesť so sebou problémy nové. Na túto problematiku sa v eseji pozerám z pohľadu zamestnanca aj zamestnávateľa. Myslím si že monitoring prinesie svoje „ovocie“ iba pri ich dobrej súdržnosti. Podľa môjho názoru má každý člen tímu právo vedieť o monitoringu, na čo budú určené jeho výsledky, čo si zamestnávateľ nemôže dovoliť, a tak sa nebáť o svoje súkromie, čo je bližšie popísané v eseji. Taktiež by nemal zamestnávateľ brať pracovníkov iba ako svoje ovečky. Dnes teda súdržnosť a primeraný rešpekt členov tímu vždy nefunguje, preto sa pracovníci obávajú monitoringu, ktorý navyše môže prinášať zamestnávateľovi skreslené výsledky. V eseji sa preto hlavne zaoberám ako takéto problémy vznikajú, ako sa ich podľa mňa dá jednoducho vyvarovať a vytvoriť si tak funkčný tím, čim budú spokojné obe strany a monitoring sa stane produktívnym.

Abstrakt:Tajomstvo ľudskej mysle odjakživa fascinovalo nielen mnohých mysliteľov a vedcov. Spomínanú neznámu sa ľudstvu darí pomaly odhaľovať, ale stále sa jedná o natoľko komplikovaný problém, že zostáva aj naďalej otvorený a aktuálny. V tejto eseji diskutujeme vplyv pováh softvérových inžinierov nielen na ich profesionálne smerovanie, ale aj na úlohy, ktoré sú im blízke pri práci v tíme. Dotýkame sa problematiky komunikácie medzi jednotlivými členmi tímu, ako aj so zadávateľom projektu a pomenúvame niektoré úskalia, ktorým bude tím pravdepodobne musieť čeliť. Analyzujeme možnosti rozloženia povinností medzi jednotlivých členov tímu na základe ich pováh. Hľadáme vhodné rozdelenie kompetencií a zodpovednosti, s prihliadnutím na silné stránky jednotlivých osobností, ale pomenúvame aj možné problémy, prameniace zo slabších stránok niektorých pováh. Konfrontujeme teoretické výsledky so známymi typickými vlastnosťami osobností v analyzovanom projektovom tíme.