Zborník esejí 2011

Abstrakt:Pri pojme kontrola kvality si bez hlbšieho premýšľania mnoho ľudí predstaví kontrolu kvality hotového výrobku. Softvér je tiež určitým druhom výrobku a naskytuje sa otázka: Stačí overiť a skontrolovať vlastnosti výrobku, splnenie požiadaviek klienta až pri finálnej verzii produktu? Ako už iste tušíte, takýto prístup nie je správny a preto existuje mnoho metód zabezpečenia kvality softvérového produktu počas celého vývoja, ktoré si v eseji krátko priblížime a zamyslíme sa nad nutnosťou a prínosmi niektorých týchto metód. Zameriame sa na prístupy založené na vzájomných prehliadkach (peer reviews) a podporíme názor, že zabezpečenie kvality nie je len o testovaní, ale že je to komplexná záležitosť nevyhnutná pre úspešnosť softvérových projektov.

Abstrakt:Plánovanie by malo byť dôležitou súčasťou všetkých projektov väčšieho rozsahu. Pomáha lepšie odhadnúť množstvo zdrojov, potrebných na projekt, alebo rozvrhnúť čas, ktorý máme k dispozícii. V tejto eseji sa zameriavam na plánovanie v softvérovom projekte. Popíšem a porovnám niektoré spôsoby plánovania, ktoré sa v praxi používajú. Z uvedených metód bližšie opíšem metódu zreťazeného plánovania. Plány samy o sebe však nestačia a preto je rovnako dôležité vytvorený plán dodržiavať, alebo ho v prípade potreby vedieť doplniť, či upraviť. Popíšem teda aj spôsoby, ako plány udržiavať a sledovať. Na záver zhrniem význam uvedených metód pri tvorbe plánov v softvérových projektoch.

Abstrakt:Ako povedal John C. Maxwell, veľké ciele je možné dosiahnuť jedine, keď sa spoja mnohí ľudia dohromady. V tomto výroku je najdôležitejším slovíčkom slovo spoja. Nech by akákoľvek skupina ľudí objavila čokoľvek úžasné alebo prevratné, nemalo by to žiadny osoh, ak by poverili slepého zapisovaním a nemého diktovaním. V dnešnej dobe sa pri obsadzovaní pracovných miest, či už zo strany zamestnanca alebo zamestnávateľa, kladie najväčší dôraz na znalosti a skúsenosti. Napriek tomu, to čo ovplyvňuje naše pôsobenie v pracovnom kolektíve je najmä naša osobnosť. Niektorí ľudia sú rodenými vodcami, kým iní sú najspokojnejší, keď ich môže niekto viesť. Pri zostavovaní kolektívu ľudí, ktorí majú spolupracovať, je nutnosťou zohľadniť ich psychickú spôsobilosť pre danú rolu. Predkladaná esej pojednáva o dvoch najväčších smeroch v identifikácii osobnosti človeka, nevenuje sa však detailne rozdielom, ale poskytuje zamyslenie, ktoré z jednotlivých osobnostných typov sa hodia na jednotlivé miesta v tíme a ktorý smer v identifikácii osobnosti by mal prevážiť.

Abstrakt:Pri monitorovaní vývoja softvérových systémov narážame na viacero problémov. Okrem tých zjavnejších ako zložitosť a nejasnosť požiadaviek je veľkým problémom práve softvérová neviditeľnosť. Pre hladký priebeh projektu je veľmi dôležité odhadnúť množstvo úsilia, ktoré je potrebné vyvinúť na vývoj v jednotlivých etapách. Práve v tejto problematike nám môžu napomôcť softvérové metriky. Softvérové metriky predstavujú kvantitatívnu metódu merania určitých vlastností softvéru a môžu byť obzvlášť nápomocné pri monitorovaní vývoja projektu. Existuje však mnoho metrík, ktoré často môžu podávať aj protirečivé výsledky. Je potrebné zamyslieť sa, ktoré z týchto metrík nám môžu ponúknuť dôveryhodné výsledky na to, aby sme mohli plánovať ďalší priebeh projektu. Táto esej sa zameriava na metriky týkajúce sa spoľahlivosti ako jednej z dôležitých vlastností softvéru.

Abstrakt:Dôsledkom rozširujúceho sa trendu globalizácie vo vývoji softvéru sa čoraz častejšie stretávame s nasadzovaním virtuálnych tímov. Hoci tieto tímy prinášajú svoje pozitíva v tvorbe softvéru, fakt, že ich členovia musia v rámci svojej spolupráce preklenúť časové, priestorové a takisto kulturálne rozdiely, je neprehliadnuteľný. Môžeme teda tento fakt ignorovať alebo stojí za zváženie, kedy resp. za akých podmienok bude virtuálny tím pre náš projekt prínosom? V tejto eseji uvedieme čitateľa do problematiky virtuálnych tímov a taktiež sa zameriame na problémy, ktoré sú pre tento typ tímov špecifické. V ďalšej časti načrtneme, či sú momentálne existujúce softvérové systémy pre riadenie projektov postačujúce pre distribuované skupiny ľudí a pokúsime sa zamyslieť, čo týmto systémom stále chýba.

Abstrakt:Tvorba softvérových systémov je vo svojej podstate už od identifikácie požiadaviek na systém až po jeho výsledné nasadenie do prevádzky a monitorovanie veľmi komplikovaný proces. V súčasnej dobe však veľmi veľké množstvo projektov skončí neúspešne, čo súvisí aj s tým, že neustále rastú požiadavky na komplexitu systému. To sa samozrejme odvíja aj na nárokoch a záťaži na ľudí, ktorí pracujúcich na systéme. Jeden zo spôsobov ako úspešne zvládnuť proces tvorby softvéru je manažment rizík a to počas celého vývoju produktu. V tejto eseji sa zameriam na podrobnejší prehľad manažmentu rizík spolu s opisom najčastejšie sa vyskytujúcich rizík v softvérových projektoch. Taktiež sa zameriam aj na detailnejší opis jednotlivých krokov vyskytujúcich sa v rámci manažmentu rizík. Okrem toho spomeniem aj jednoduchý výpočet, prípadne odhad reálneho nebezpečenstva potenciálnych rizík.

Abstrakt:S rozširujúcou sa globalizáciou (nielen) pracovného trhu je čoraz viac spoločností tvorených zamestnancami zo všetkých kútov sveta. Tento jav je zapríčinený najmä nadnárodným charakterom firiem, ale tiež aj nedostatkom kvalifikovanej pracovnej sily na lokálnych trhoch práce. Spomenutý trend sa pochopiteľne nevyhol ani IT priemyslu, ba práve naopak – dnes je vo veľkých firmách množstvo tímov, ktorých členovia majú rôznorodý pôvod. Vzhľadom na tento fakt sa vynára niekoľko otázok. Aký dopad na efektívnosť práce tímu má jeho multikultúrne zloženie? Existuje spoľahlivý spôsob, ako vytvoriť zmiešaný tím tak, aby národnostné charakteristiky jednotlivých jeho členov boli viac prínosom, ako negatívnym faktorom? Pri rozoberaní tejto problematiky rýchlo hrozí, že sa dostaneme na tenký ľad, pretože pri prihliadaní na rôzne kultúry je generalizácia zradná. Napriek tomu existujú výskumy, ktoré sa zaoberajú kvantifikovateľnými aspektmi charakteristickými pre obyvateľov jednotlivých krajín z hľadiska ich práce v kolektíve. Sú zamerané predovšetkým na odhalenie kultúrnych slabostí a predností a spôsoby, ako sa im vyhýbať, resp. ich využívať v prospech tímu. Esej sa chce zamyslieť nad týmito možnosťami a načrtnúť základné princípy, na ktoré by mal manažér pamätať pri vytváraní a riadení zmiešaného tímu.

Abstrakt:Manažment rizík je esenciálnou zložkou akéhokoľvek projektu spadajúceho pod krídla serióznej inžinierskej disciplíny. Bez podrobnej analýzy a precízneho plánovania rizík nie je možné projekt ukončiť v predpokladanom čase a v požadovanej kvalite. Po vzore Murphyho zákonov sa totiž objavia práve také prekážky, na ktoré neexistujú v danom okamihu riešenia. To v konečnom dôsledku prácu skomplikuje, predraží a eventuálne vyústi do kolapsu a nezriedka aj predčasného ukončenia celého projektu. Vedel to už Michelangelo Buonarroti, keď v roku 1546 prijímal funkciu hlavného architekta a dozorcu nad stavbou baziliky sv. Petra. Vedia to aj manažéri, ktorí dennodenne dohliadajú na mnohomiliónové projekty v oblasti financií, stavebníctva či medicíny. Prekvapivo sa však touto otázkou často nezaoberajú manažéri a ľudia zodpovední za projekty spadajúce do jednej z najrizikovejších oblastí podnikania - vývoja softvéru. Mnohé malé a stredné, ale nezriedka i veľké projekty tak musia bojovať a nachádzať riešenia na tie isté problémy, na ktoré už dávno existujú optimálne riešenia.

Abstrakt:Vlastnosti softvérového produktu predstavujú základ pre proces vytvárania softvéru. Pri vývoji softvéru sa musí brať ohľad na každú vlastnosť softvéru, pretože výsledná kvalita softvéru sa odvíja práve od miery splnenia požadovaných vlastností. Jednou z dôležitých vlastností softvéru je aj jeho prenositeľnosť, teda schopnosť fungovať na viacerých zariadeniach(platformách). Táto vlastnosť je kľúčovou pre schopnosť softvéru presadiť sa na trhu so softvérom v čo najširšom možnom okruhu používateľov. Špeciálnou skupinou softvéru sa stal softvér pre mobilné zariadenia, ktorý v dnešnej dobe dosahuje obrovský rozmach a jeho vývoj napreduje míľovými krokmi. V tejto eseji sa zaoberám prenositeľnosťou softvéru určeného pre mobilné zariadenia. Zameriavam sa na vplyv prenositeľnosti na vývoj softvéru pri práci v tíme a na dôležitosť tejto vlastnosti pri vývoji mobilných aplikácií. V závere eseje sa pokúšam odhadnúť ako sa bude prenositeľnosť vo vývoji softvéru pre mobilné aplikácie meniť a či sa vôbec niečo oproti súčasnosti zmení.

Abstrakt:S pojmom kvalita sa stretávame dennodenne vo všetkých sférach života. Aj v oblasti softvérového inžinierstva má tento pojem strategický význam. Ale dosiahnutie kvality v softvéri je náročný proces. V súčasnosti existuje veľa spôsobov nato ako to docieliť. Jedným z nich je aj vylepšovanie zdrojového kódu. V eseji sa zameriavame na spôsoby, akými vývojári môžu vylepšiť zdrojový kód a tak zvýšiť kvalitu softvéru. Niekedy sa stretávame s postojmi, že dodržiavanie zásad, ktoré zdokonaľujú zdrojový kód, je zárukou pre kvalitný softvér. Takéto uvažovanie môže byť zavádzajúce. Na životnom cykle tvorby softvéru sa podieľa viacero fáz a jednou z nich je aj testovanie. V eseji predostrieme náš názor, či je možné dosiahnuť kvalitný softvér bez tejto fázy.

Abstrakt:Či sa jedná o projekt veľkého rozsahu alebo menšieho, stále je tu potreba riadenia, sledovania úloh a efektívneho využívania ľudských zdrojov. Všetky informácie týkajúce sa týchto potrieb nie je možné udržiavať v ľudskej pamäti. A tak sa dostávame k myšlienke používať pri riadení podporné systémy, ktoré budú potrebné informácie uchovávať za nás. Potom je už len otázkou našej šikovnosti ako s týmito informáciami naložíme a ako ich využijeme pri vedení nášho tímu. Avšak pred použitím konkrétnej podpornej aplikácie by sme sa mali zamyslieť. V prvom rade si musíme vybrať systém pre nás čo najvýhodnejší s funkcionalitou, ktorá nám postačuje a však zbytočne neprevyšuje naše potreby. Do akej miery budeme systém formálne využívať a do akej necháme komunikáciu na členoch tímu? Môže byť výhodou používať v rámci jedného projektu viac takýchto systémov?

Abstrakt:Úspešnosť vytvorenia softvérového projektu v termíne a podobe, v akej nám ho zákazník špecifikoval, závisí najmä od pripravenosti a rozdelenia práce, zdrojov a času pri vývoji. Kľúčovým faktorom je plánovanie, ktoré je neoddeliteľnou súčasťou nie len veľkých, ale aj malých projektov. Pre tvorbu a riadenie plánov vývoja softvéru máme k dispozícií široké spektrum metód, no ani jedna z nich nám nezaručí, že pri jej použití sa neobjavia nepredvídateľné skutočnosti. Z tohto dôvodu je vhodné byť pri tvorbe plánu agilný a vedieť tak promptne reagovať na nepredvídané udalosti alebo zmeny požiadaviek zadávateľa projektu. Prečo plánovať agilne? Problematikou plánovania a zmenami v projektoch sa zaoberá každý vývojový tím, ktorý chce priviesť projekt do úspešného konca. Čoraz viac sa využívajú moderné agilné metódy ako napríklad SCRUM. Je možné zmienený spôsob vývoja softvéru plánovať a zefektívniť tak vývoj softvéru? Ako odhadnúť náročnosť a čas potrebný pre úspešné vyriešenie úlohy? Táto esej sa snaží odpovedať na tieto otázky spolu s názormi a odporúčaniami ako plánovať agilný vývoj softvéru.