Zborník esejí 2009

Abstrakt:Na každom produkte, ktorý bol doposiaľ vytvorený sa veľkou mierou podieľal človek alebo skupina ľudí. Každý človek je však jedinečný a preto pri vytváraní takejto skupiny ľudí, ktorá by mala úspešne pracovať v tíme treba zohľadňovať viacero faktorov. Medzi najdôležitejšie patrí kolektívna spolupráca a zamedzenie konfliktov medzi členmi takejto skupiny alebo tímu. Preto treba vyberať ľudí do tímu rozvážne a snažiť sa vytvárať také rozloženie, aby to prospelo nielen tímu, ale aj daným jednotlivcom, ktorí ho tvoria. Na to ako vybrať správnu skupinu ľudí sa treba pozerať nielen z hľadiska vedomostí a zručností samotných členov, ale aj zo strany ich jedinečných čŕt a charakteristík osobnosti. Jednoznačný postup ako vybrať to najsprávnejšie rozloženie ľudí asi neexistuje, ale môžeme sa mu aspoň pokúsiť priblížiť. K tomu nám pomáha delenie na viaceré skupiny, podľa rôznych charakteristík, čŕt a osobnostných dotazníkov. Mojim cieľom v tejto eseji bude priblížiť niektoré takéto delenia a porovnať ich. Následne skúsim spraviť jednoduché porovnanie 6 členného tímu, v ktorom sa nachádzam a ukázať správnosť alebo nesprávnosť vytvorenia takéhoto tímu.

Abstrakt:V softvérových projektoch, rovnako ako v projektoch z iných oblasti ľudskej činnosti, sa už dlhodobo používajú plány. Pri softvéri špeciálne hovoríme o vývoji riadenom plánmi. Je však použitie takéhoto prístupu aj v tomto prípade vhodné? Vytvorenie presného plánu, ktorý zohľadňuje aj potenciálne zmeny, je náročné. Obzvlášť v prípade softvéru, ktorý je do veľkej miery nevizualizovateľný. Pre riešenie problémov so správnym odhadnutím dĺžky trvania projektu ako aj pre samotné vytvorenie plánu pozostávajúceho z jednotlivých vhodne dekomponovaných úloh sa používajú rôzne metódy. V tejto eseji sa s nimi bližšie oboznámime a zhodnotíme ich silné a slabé stránky. Navzájom vybrané metódy porovnáme a pokúsime sa nájsť tú vhodnú pre tvorbu plánov v softvérovom inžinierstve.

Abstrakt:Spôsob ako zabezpečiť absolútnu bezchybnosť softvérových produktov v dnešnej dobe nepoznáme. Existuje však množstvo metód na zvýšenie kvality produkovaného softvéru. Napriek tomu nie sú systematicky využívané, hlavne v malých firmách. Dôsledkom sú problémy s testovaním a nedostatočná kvalita produktov prejavujúca sa hlavne prítomnosťou väčšieho počtu chýb. Preto je veľkou výzvou celej informatickej spoločnosti, nielen vymýšľanie nových lepších metód testovania a zlepšovania kvality, ale aj hľadanie spôsobov ako ich preniesť do praxe. Cesta k všeobecne kvalitnejšiemu softvéru by mohla viesť cez skvalitňovanie nástrojov používaných pri jeho vývoji, pretože to, čo dáva ľuďom silu v najrôznejších oblastiach, sú hlavne efektívne nástroje znásobujúce schopnosti jednotlivých osôb.

Abstrakt:Ľudia, ktorí sú súčasťou softvérových projektov väčšinou využívajú nejakú formu sledovania a manažmentu úloh, či už pomocou papierových lístkov, Outlooku, alebo softvéru na to určeného. Použitie softvérových nástrojov na tento účel môže značne zjednodušiť prácu manažmentu, avšak niekedy prináša aj nové riziká. Táto esej bude pojednávať o dôležitosti takýchto nástrojov, ako aj požiadavkách na ne. Okrem toho esej rozoberá problémy súvisiace s použitím podporných prostriedkov pre riadenie projektu a uvažuje aj o možnostiach prevencie týmto problémom za použitia agilných metód vývoja.

Abstrakt:V dnešnej dobe, pri narastajúcej konkurencií v IT odvetví, je neustále vyvíjaný na projektových manažérov väčší tlak. V takomto prostredí sa môže stať, že manažér stratí nad projektom kontrolu, pretože je vyťažovaný aj inými aktivitami, napríklad získavaním nových projektov. Je preto nanajvýš potrebné, aby mal k dispozícií moderné prostriedky na monitorovanie projektu. Predmet Tímový projekt je špecifický tým, že nie je možné počítať s nárazníkovou zónou pri dokončovaní projektu – ukončenie akademického roku je pevným a nemenným termínom, do kedy treba úspešne ukončiť prácu. Ako jeden z efektívnych prístupov k monitorovaniu projektu sa ukázala metóda EVA (Earned Value Evalution – Analýza zarobenej hodnoty). Moderné prístupy sa snažia o napojenie tejto monitorovacej metódy na metódy plánovania zdrojov, ako napríklad COCOMO II. Iné snahy smerujú ku integrácií techník na ohodnotenie softvéru (výpočet funkčných bodov) s monitorovacími metódami. Je možné tieto prístupy preniesť aj do sveta školských projektov, konkrétne tímového projektu? Vzhľadom na rôznorodosť tímových projektov je možno ťažké hovoriť o univerzálnom prístupe k monitorovaniu. Napriek tomu sa pokúsim zhrnúť postrehy, ktoré môžu byť užitočné aj pre tento typ projektov.

Abstrakt:Dnes, keď je pri vývoji softvéru dôležitá každá sekunda a klient chce vidieť výsledky okamžite, na chyby nie je priestor. Tlak prichádza z každej strany a prináša riziká, ktoré ohrozujú projekt. Riziko je často chápané ako nebezpečenstvo vzniku určitého druhu straty. Manažment rizík a príprava vhodných bezpečnostných riešení je komplexným problémom. Analýza a riadenie rizík pomáha predchádzať alebo aspoň minimalizovať situácie, ktoré by mohli ohroziť časový plán alebo čo je horšie, celý softvérový projekt. V práci sa zaoberám hlavne tým, ako odstrániť príčiny vzniku rizikových udalostí alebo aspoň obmedziť ich negatívne dôsledky na softvérový projekt. Ďalej sú tu rozobrané rôzne príčiny vzniku chýb a rizík, ktoré najčastejšie zapríčiňujú neúspech projektu a ich rozdelenie do skupín, ako napríklad predvídateľné, teda aj ovplyvniteľné a neovplyvniteľné a čo vlastne riziko znamená. Nakoniec sú spomenuté rôzne osvedčené modely vývoja softvéru.

Abstrakt:Počas celej doby životného cyklu riešeného softvérového projektu sa spolu s jeho zvyšujúcou zložitosťou zväčšuje aj opodstatnenosť otázky, ako takýto projekt riadiť. Každý projekt je totiž viazaný na obmedzené množstvo zdrojov, ktorých nesprávnym využitím sa môže výrazne predražiť. Za účelom riešenia tohto problému bolo vytvorených viacero podporných prostriedkov, ktoré napomáhajú manažérom v efektívnom spôsobe riadenia. Snahou tejto eseje je preto priblížiť čitateľovi niektoré z nich, so sústredením sa najmä na podporné prostriedky určené na sledovanie úloh a prerozdeľovanie ľudských zdrojov. Esej sa tiež zaoberá vhodnosťou ich použitia aj v malých tímoch riešiacich úlohu rozsahu tímového projektu na FIIT STU.

Abstrakt:Plánovanie tvorí neoddeliteľnú súčasť životného cyklu každého, nie len softvérového, projektu. Napriek tomu je často podceňované, ba dokonca úplne ignorované. Platí to najmä pre menšie projekty, kedy ľudia predpokladajú, že ak je projekt menší, musí byť aj logicky jednoduchší. Načo je teda dobré plánovať takýto projekt ? Veď samotný proces plánovania zaberie viac času ako jeho realizácia! Nemusí to byť vždy pravda. A často ani nie je. V skutočnosti sa môže aj jednoducho znejúce zadanie ukázať ako nejasné a komplikované. Človek je tak často nútený doslova zahodiť veľké množstvo práce a vrátiť sa až úplne na začiatok. Nakoniec strávi na projekte viac času, ako by bolo vhodné a výsledok vôbec nemusí zodpovedať očakávaniam. V tomto článku poukážem na skutočnosť, že sa oplatí dobre si naplánovať aj menší projekt a že plánovanie nie je na to, aby projekt predlžovalo, ale naopak, aby ho zjednodušovalo a zabraňovalo nejasným situáciám.

Abstrakt:Rozdelenie ľudí do tímov býva spravidla často odbavené náhodným zoskupením ľudí alebo prenechaním tejto úlohy samotným pracovníkom. Existuje však aj metóda, pomocou ktorej sa určia typy osobností jednotlivcov a na základe nich sa sformuje tím a pridelia sa funkcie. Typ osobnosti sa dá určiť rôznymi testami, najznámejší je test Myers-Briggsovej, ktorý určí typ osobnosti na základe niekoľkých otázok, na ktoré sa odpovedá áno-nie. V tejto eseji sa budem zaoberať dopadom rôznych typov osobností na softvérový projekt aj na projekt ako taký. Zhrniem typy osobností mojich kolegov z tímového projektu pomocou bezplatného testu, zistím, či sme vytvorili podľa týchto kritérii dobrý tím a priradím jednotlivým členom funkcie v rámci softvérového projektu.

Abstrakt:Každý vyvíjaný systém si vyžaduje vynaloženie určitých prostriedkov, ako je napríklad čas a peniaze, na jeho úspešnú realizáciu. Počas životného cyklu vývoja systému môže dôjsť k momentu kedy nevieme povedať v akom stave sa systém nachádza. Toto môže spôsobiť nemalé problémy ako nesplnenie časového plánu a v horšom prípade aj k nesplnenie funkčných požiadaviek. Aby sa čo najskôr takéto nedostatky odhalili je potrebné monitorovať stav v akom sa projekt nachádza. Monitorovaním môžeme dosiahnuť minimalizáciu nadbytočných prostriedkov na vývoj systému ako aj identifikovať jeho možné nepresnosti voči požiadavkám, ktoré má vyvíjaný systém spĺňať. V tejto eseji sa budem snažiť vysvetliť, prečo je potrebné monitorovať vyvíjaný systém, opíšem spôsoby akými je možné monitorovať a tiež čo treba pri vývoji monitorovať viac a čomu môžeme klásť menšiu pozornosť.

Abstrakt:Ako sa už píše v nadpise risk je zisk. Týka sa to samozrejme aj softvérových projektov. Je však veľmi potrebné mať riziká pod kontrolou, inak môže namiesto zisku softvérový projekt skončiť neúspešne. Podľa rôznych výskumov to nie je nijaký ojedinelý jav. Spoločnosti sa preto snažia riziká minimalizovať v čo najväčšej možnej miere. Na odhad a plánovanie rizík v softvérových projektoch sa využíva manažment rizík. Manažment rizík pomocou správnych prístupov identifikuje, analyzuje a kontroluje riziká v softvérovom projekte. Vďaka tomu projekt manažéri zvyšujú pravdepodobnosť úspešného ukončenia projektu bez toho, aby vzniklo časové oneskorenie alebo aby bol prekročený rozpočet. V tejto eseji sa zaoberám potrebou použiť manažment rizík počas priebehu softvérových projektov. Ďalej sa zaoberám postupmi využívanými pri analýze rizík, určovaní miery rizika a metódami slúžiacimi na zmierňovanie identifikovaných rizík.

Abstrakt:K tejto otázke ma „vyprovokovala” prax. Konkrétne moje krátkodobé pôsobenie v testovacom tíme. Môžete namietať, že krátkodobé, cca dvojmesačné pôsobenie ma neoprávňuje vyslovovať pochybnosti a dávať súdy. A možno práve naopak ma k tomu oprávňuje, keď už tak skoro vidím nedostatky. Tie v krátkosti zhrniem. Testovací tím je zvláštne označenie niečoho, čo sa tímom podľa mňa nedá nazvať. Veď tím by mal byť najmä o spolupráci, ktorá vedie k väčšiemu úžitku, ako je suma úžitkov práce jednotlivcov. V testovacom tíme toto nepozorujem. Výsledky jedného člena tímu totiž ostatní členovia nevyužívajú, a ak áno. len v obmedzenej miere. Každý člen tímu “hrabe” na svojom piesočku. Buď testuje manuálne, alebo píše automatické testy pre jemu pridelenú uzavretú množinu požiadaviek. Súdržnosť testovacieho tímu je teda malá. A to je problém. Keďže každý tester testuje svoju uzavretú množinu požiadaviek, nie je lepšie, aby bol v tíme vývojárov, ktorí tieto požiadavky implementujú? Nemal by byť bližšie k zdroju diania a možných zmien produkčného kódu? Každá minca má však dve strany. V tejto eseji sa preto pokúsim zhrnúť pre a proti samostatnému tímu.

Abstrakt:Oblasť informatiky je jedna z najdynamickejšie sa rozvíjajúcich oblastí. Rovnako dynamicky sa vyvíja aj manažment pre softvérové projekty. Vznikajú stále nové teórie ako čo najsprávnejšie a teda najefektívnejšie viesť softvérový projekt. V dnešnej dobe je neoddeliteľnou súčasťou manažmentu aj samotný softvér umožňujúci efektívne vedenie vývojárskych tímov. Cieľom článku je práve oboznámenie čitateľa s existujúcimi prostriedkami. Ich základným rozdelením a funkcionalitou. Taktiež s vyzdvihnutím všetkých výhod a rovnako rizík, ktoré s používaním podporných prostriedkov podstupujeme.

Abstrakt:Kľúč k úspešnému projektu je plánovanie. Vytvoriť plán projektu je prvá vec, ktorú by sme mali urobiť ak sa podujmeme na akýkoľvek projekt. Často je iniciatíva začať čím skôr s projektom uprednostnená na úkor projektového plánovania. Mnoho ľudí si neuvedomuje hodnotu plánovania projektu v ušetrenom čase, peniazoch a problémoch. Táto esej poukazuje na význam a dôležitosť plánovania a predostrie jednoduchý a praktický postup tvorby projektového plánu.

Abstrakt:Aj pri tvorbe menších projektov, ako je aj práca na tímovom projekte, by si mal projektový manažér, prípadne zodpovedný vedúci uvedomiť, že môže nastať počas vývoja ako aj po jeho spustení krízová situácia, kedy sa buď nestíhajú termíny, presiahol sa rozpočet, funkcionalita systému sa odlišuje od špecifikácie a podobne. Takýto jav nie je vôbec neobvyklý. Riešením je takéto nežiadúce situácie predvídať a riziká plánovať. V tejto eseji stručne rozoberám základné známe riziká pri menších projektoch, zdroje týchto rizík, ale aj niektoré metódy manažmentu a analýzy rizík. Chcel by som aj na konkrétnych príkladoch, s ktorými som sa sám stretol, poukázať na možné aplikovanie manažmentu rizík, ktoré by znamenali úspešný priebeh a ukončenie projektu narozdiel od pôvodného neúspešného konca.

Abstrakt:Vývoj rozsiahlejších, na čas a zdroje náročnejších softvérových systémov, si priamo vyžaduje zapojenie viacerých ľudí do projektu vytvorením tímov. Zostaviť tím, ktorý bude výkonný a efektívny, nie je vôbec ľahká úloha. Do úvahy treba brať nielen profesionálne kvality potenciálnych členov, ale tiež ich osobnostné charakteristiky, ktoré určujú, ako budú jednotlivci schopní riešiť rôzne problémy, ktoré nastanú, čo sa v konečnom dôsledku odrazí na efektívnosti práce celého tímu. Pri vytváraní tímu a určovaní rolí môže značne pomôcť použitie analýzy osobnosti, pričom v súčasnosti používané metodiky definujú, pre akú rolu v tíme má istý typ osobnosti predpoklady na základe vlastných povahových čŕt. Tým pomáhajú lepšie usúdiť, v akej úlohe prinesie jednotlivec tímu potenciálne najväčší prínos. V tejto eseji sa zamýšľam nad otázkou, či takúto rolu, pre ktorú jednotlivca predurčujú jeho povahové vlastnosti, musí, resp. by mal práve pre predpokladaný najväčší prínos pre tím aj zastávať.

Abstrakt:V súčasnej dobe rastú požiadavky na vytváraný softvér, a tým sa aj samotný proces tvorby softvéru stáva zložitejší a náročnejší na jeho manažovanie. Dôležitú úlohu v procese tvorby softvéru má aj monitorovanie. Monitorovanie napomáha pri zisťovaní odchýlok súčasného stavu projektu oproti pôvodným plánom. Aby sa však projekt mohol monitorovať, musia byť jasne definované pravidlá, pomocou ktorých sa vyhodnocuje súčasný stav projektu. Jedna z možností ako sa dá projekt monitorovať a kontrolovať, je integrovanie metrík na ohodnotenie veľkosti funkcionality projektu (software functional size metric), COCOMO II a analýzy prídavnej hodnoty (Earned Value Analysis) v procese odporučenom PMBoK (Project Management Body of Knowledge’s). Táto esej sa zameria na objasnenie týchto postupov.

Abstrakt:Rýchly vývoj vo svete softvéru zmenil tvár Internetu z malého množstva web stránok na veľký komplex web aplikácií, ktoré dnes poskytujú služby rôznych druhov a sú rovnocennou alternatívou tradičných softvérových produktov. Zvyšujúcou sa zložitosťou Web aplikácií vznikala potreba vývoja nových techník testovania tohto druhu softvéru, ktorá však nebola doposiaľ uspokojená. Web aplikácie sú stále testované tradičnými metódami, ktoré sú v mnohých prípadoch neefektívne a nákladné. Cieľom tejto eseje je poskytnúť pohľad autora na problematiku zabezpečenia kvality Web aplikácií. Pojednáva o zraniteľnosti nekvalitného softvéru a príčinách jeho vzniku. Chce poukázať na neefektívne testovacie techniky súčasnej doby. Rozoberá možnosti testovania Web aplikácie ako interaktívneho, viac-platformového, dynamického systému. Nakoniec sa snaží poskytnúť riešenie na zlepšenie efektívnosti testovania.