Zborník esejí 2011

Abstrakt:Rozvojom informačných technológií sa nám ponúka okrem softvéru uľahčujúcemu našu prácu aj softvér určený na oddych a zábavu. Do skupiny zábavného softvéru nepochybne patria aj hry. Ich bežný používateľ sa asi nezamýšľa nad tým ako boli vyvíjané alebo ako fungujú, zaujíma ho len to, či si pri nich oddýchne alebo sa zabaví. Určite sa nezamýšľa čo všetko za ich vývojom stojí a koľko rizík vývoj hry so sebou nesie. Rovnako ako aj za inými softvérovými projektmi, tak aj za vývojom väčšej hry stojí nejaký tím, ktorý treba tiež riadiť a ktorý so sebou prináša rôzne riziká a problémy. Vo svojej eseji sa chcem venovať problematike rizík pri vývoji hier. Rád by som sa zamyslel nad potrebou riadiť riziká aj pri vývoji počítačových hier a taktiež nad tým, ktoré z týchto rizík sú dôležité a ako minimalizovať ich výskyt.

Abstrakt:Každodenne sa každý z nás venuje akýmsi úlohám, ktoré nás nejakým spôsobom posúvajú vpred. Niektorí z nás si dokonca svedomito udržiavajú kalendár týchto úloh, aby sme niektorej z nich nezabudli prideliť náš drahocenný čas. Podobne je tomu aj pri manažmente projektov až na to, že nám pribudnú ďalšie kvantá času v podobe ľudských zdrojov. Pokiaľ sa pokúšame prejsť relatívne väčším projektom bez používania takéhoto projektového kalendáru, teda podporných nástrojov pre riadenie projektov, tak nám projekt zlyhá alebo to aspoň bude úplná katastrofa. Po projekte potom začneme premýšľať a hľadať, kde sa asi stala chyba, no nakoniec si však všetci uvedomíme, že keby sme mali taký projektový kalendár, tak nielenže by náš projekt pravdepodobne dopadol lepšie, ale boli by sme aj schopní naše pochybenia rýchlo nájsť a v budúcnosti sa im vyhnúť. V prípade, že sa tieto prostriedky ale používajú bezhlavo a zabúda sa na fakt, projekt je vďaka ľuďom organickým systémom, môžu byť tieto prostriedky samé dôvodom pre zlyhanie projektu. Preto je pri ich využívaní potrebné používať rozum a niekedy mať aj nevyhnutné skúsenosti. V mojej eseji sa venujem práve tejto problematike, pričom sa zameriavam na projekty vývoja zábavného softvéru, teda hier.

Abstrakt:V dnešnom svete sú plány, ako súčasť bežného života vnímané negatívne. Častokrát nevychádzajú, a tak človek len ťažko hľadá motiváciu plánovať. S podobným fenoménom sa môžeme stretnúť aj pri vývoji softvérových systémov. Vývojári sa častokrát vyhýbajú plánovaniu pre zlé skúsenosti so zlými, nevydarenými plánmi. Avšak kde je hranica medzi vydareným a nevydareným plánom? Táto esej je v prvom rade zameraná na analýzu toho, čo robí zlý plán zlým, či sem nespadajú aj ľudia, ktorí vytvoria plán, rozhodnutí ho slepo nasledovať. Snažím sa určiť hranice medzi plánom ako dogmou, plánom ako nástrojom a jednoduchým odhadom. Zameriavam sa na pozitíva a negatíva jednotlivých pohľadov na funkciu plánovania. Esej na záver rozoberá, či existujú postupy, ako vytvoriť plán, ktorý plne vyhovuje týmto jednotlivým pohľadom.

Abstrakt:Počítačové hry predstavujú špecifický typ softvérového systému. V dôsledku ich osobitých vlastností, dynamického rozvoja a pokroku, ktorý v súčasnosti podstupujú, narastá aj ich komplexnosť a otázka zabezpečenia kvality sa dostáva čím ďalej, tým viac do popredia. Od kvality hry ako softvérového produktu nakoniec závisí aj jej celkové postavenie na trhu herného priemyslu. V tejto eseji predstavujem prieskumné testovanie ako alternatívny prístup k štandardným metódam testovania a opisujem výhody jeho použitia pri testovaní počítačových hier. Opisujem dôležitosť určovania priorít zadaných požiadaviek, od ktorých sa neskôr odvíjajú aj priority chýb. Práve prieskumné testovanie je prístup, ktorý zohľadňuje tieto priority a v niektorých prípadoch je preto efektívnejšie a výhodnejšie ako klasické skriptované testovanie.

Abstrakt:Testovanie zohráva významnú úlohu pri zabezpečovaní kvality softvérového projektu. Včasným odhalením chýb možno vo vývoji softvérového produktu rýchlo a efektívne napredovať. Napriek tomu sa testerom často nedostáva patričného ocenenia a sú tŕňom v oku každého developera. V ideálnom prostredí by tester nachádzal rôznorodé chyby vznikajúce v kritických a ojedinelých situáciách. Avšak realita sa výrazne líši a tester denno-denne zápasí s množstvom včerajších problémov, chybami, ktoré vznikajú v dôsledku zlej interpretácie požiadaviek, či analýz, prípadne kontrolovaním „údajne“ vyriešených chýb. To všetko má negatívny vplyv na efektivitu práce testera predovšetkým pri prieskumnom testovaní. Táto esej vrhá svetlo na prácu testera z nevšedných uhlov s cieľom poukázať na faktory, ktoré majú dopad na efektivitu práce testerov, predovšetkým pri vykonávaní manuálnych testov.

Abstrakt:Základným predpokladom správnych výsledkov je komunikácia. Esej sa špecializuje na komunikáciu v softvérových tímoch. Tam kde je nejasný cieľ projektu, prípadne tvar jeho výstupu, vzniká nadmerná komunikácia v tíme za účelom získavania predstavy výsledného produktu. Zároveň každá komunikácia trvá určitý čas, ktorý by sa dal využiť tvorbou produktu. Hovoríme o všeobecnej komunikácii, či už priamej, alebo elektronickej, či už interaktívnej alebo neinteraktívnej. Tu vzniká otázka, čo tímu takáto konverzácia prinesie, aké druhy sú výhodné a ktoré sú priamo nežiaduce a čo v konečnom dôsledku sa v tíme deje dôsledkom komunikácie? Esej hovorí o priamych výhodách jednotlivých elektronických komunikácii, ale aj o dopade danej komunikácie na produkt.

Abstrakt:Neexistuje úspešný projekt, ktorý by sa zaobišiel bez riadenia. Ale ako riadiť projekt bez informácií? Čím je projekt väčší tým je menšia možnosť aby si manažér získal potrebné informácie sám, priamo od zdroja a práve preto sú nutné podporné prostriedky, ktoré umožnia manažérovi získať požadované informácie. V súčasnosti existujú podporné prostriedky, ktoré pomáhajú pri riadení všetkých možných aspektov projektu, či už ide o správu úloh, riadenie ľudských zdrojov, reportovanie chýb, alebo rôzne iné. Táto esej sa zaoberá práve úlohou podporných prostriedkov pri riadení softvérových projektov, najmä s dôrazom na sledovanie úloh a ľudských zdrojov. Existujú rôzne typy podporných prostriedkov, ktoré pomáhajú pri rôznych aspektoch riadenia, ale aj priamo pri vykonávaní úloh. Ale je vždy podporný prostriedok len prínosom ? Sú podporné prostriedky rovnako potrebné a významné pre veľký projekt na ktorom sa podieľajú stovky ľudí, ako aj pre malý tímový projekt piatich ľudí? Esej sa zaoberá aj týmto, teda porovnaním vhodnosti a potreby podporných prostriedkov pre rôzne veľkosti projektov a veľkosti tímov.

Abstrakt:Vývoj softvérových produktov je často veľmi komplikovaná činnosť. Podieľa sa nej množstvo ľudí, ktorí plnia rôzne úlohy. Aby bolo možné projekt úspešne dokončiť, je potrebné vývoj softvéru monitorovať. Monitorovanie softvérového projektu je dôležitá činnosť najmä z pohľadu riadenia a plánovania. Môže prebiehať pomocou rôznych monitorovacích metód, ktoré zohľadňujú viacero metrík. V tejto práci sa pokúsim poukázať na výhody použitia dvoch takýchto metód, ktoré patria k tým najrozšírenejším. Jedná sa o Rámec na monitorovanie softvéru a Analýzu získanej hodnoty. Pri tom priblížim spôsoby, ako k monitorovaniu pristupovať a predstavím metriky, ktoré sa používajú na získanie potrebných ukazovateľov. V závere sa pokúsim tieto metódy porovnať a navrhnúť spôsob a mieru ich aplikácie pri monitorovaní vývoja softvérových projektov.

Abstrakt:Dotiahnuť projekt vývoja informačného systému do úspešného konca a uspokojiť všetky požiadavky zákazníka v dohodnutom čase je veľmi ťažká a zložitá úloha. Vývoj informačného systému prechádza mnohými fázami, pri ktorých sa môžu vyskytnúť očakávané, ale aj neočakávané rizikové udalosti, pri ktorých spoločnosť, ktorá vyvíja informačný systém môže prísť o čas, finančné prostriedky, ale aj dobré meno spoločnosti. Mnohokrát sú pre projekty tým najväčším rizikom samotní ľudia – a nad tým sa v tejto eseji zamyslím. Objasním čo sú to riziká, manažment rizík, priblížim teóriu a metódy používané v manažmente rizík. Budem sa zaoberať zákazníkmi ako rizikom, kde rozoberiem akými spôsobmi môžu byť pre projekt rizikom zákazníci. A taktiež sa budem zaoberať zamestnancami ako rizikom, kde rozoberiem ako môžu samotní zamestnanci spoločnosti ohroziť získanie projektu, vývoj a zisk z úspechu.

Abstrakt:Každý človek je jedinečný. Táto jedinečnosť sa prejavuje v tom, že produktom rovnakej tvorivej činnosti dvoch rôznych ľudí sú rôzne výsledky. Nachádzame odpoveď na otázku, prečo sme každý iný. Rozdielnosť ľudí bola sa snaží byť klasifikovaná pomocou Myers-Briggsovho indikátora osobností. Popisujeme jedného konkrétneho vývojára. Popisujeme jednotlivé časti vývoja softvéru a nachádzame v nich odpovede na otázku, akí ľudia majú v týchto častiach pracovať. Tieto popisy obohacujeme o reálny príklady zo života spomínaného vývojára. Nakoniec sa snažíme nájsť odpoveď na otázku, ako zlepšiť vzťahy pri softvérovom vývoji a či je nutné vyberať pracovníkov pre softvérový vývoj aj na základe ich typov osobností.

Abstrakt:Plánovanie času je neoddeliteľnou súčasťou nielen softvérových projektov. Čas si plánujeme aj v každodennom živote, mohli by sme si preto myslieť, že v tom budeme mať prax. Z vlastných skúseností však vieme, že to tak bohužiaľ nie je. Ako ukazujú mnohé psychologické štúdie, optimizmus pri plánovaní vlastného času je úplne bežný. V eseji bližšie popíšem tento jav a budem sa mu venovať vo vzťahu k softvérovým projektom, kde sa termínom a odhadom určite nevyhneme. Jednou z metód, ktorá sa snaží dôsledky tohto javu riešiť, je evidencia vlastných časových odhadov, ako aj reálne spotrebovaného času potrebného na vyriešenie úloh. Takto si môže každý vývojár zistiť nepresnosť svojich odhadov a zlepšiť tak svoje odhady do budúcnosti. Manažéri získajú reálne odhady dokončenia projektu, a ak využijú koncept dvoch plánov a v pláne pre zákazníka zohľadnia problémy, ktoré môžu nastať, výsledkom bude splniteľný plán.

Abstrakt:O význame vedúcej osobnosti v tíme neexistujú žiadne pochybnosti. Táto pozícia ovplyvňuje tím ako celok, určuje jeho víziu a celý režim jeho fungovania. Z tohto dôvodu je nutné veľmi dobre zvažovať voľbu vhodného kandidáta. Pre podporu tohto rozhodovania existuje veľké množstvo postupov a metodológií, z ktorých asi najznámejšia a najpoužívanejšia je typológia osobnosti podľa Myers-Briggsovej. Táto typológia popisuje šestnásť typov osobností, z ktorých sú iba niektoré vhodné na vedúci post. Aplikovaním tejto typológie vieme pomerne presne určiť charakterové črty jednotlivých členov tímu a vytipovať vhodných kandidátov na vedúcu pozíciu. Dôležité je však aj to akí ľudia, aké typy osobností stoja za vedúcim tímu a podporujú ho, pretože zvyšok tímu môže mnohokrát vyvážiť svojim prístupom a správaním nedostatky, ktoré sa prejavujú u vedúceho tímu. Cieľom eseje je poukázať na spôsoby akými ostatní členovia, respektíve ich typy osobností môžu ovplyvňovať vedúceho tímu.

Abstrakt:Máloktorý projekt, a to nie len v IT sa skončí presne tak, ako sa skončiť mal. V časovom limite, bez prekročenia dohodnutého finančného zabezpečenia a pri splnení požadovanej kvality. Naopak veľa projektov skončí so zvýšenými finančnými alebo časovými nárokmi. A aj to je ten lepší prípad. Prečo je to tak? Za všetkým sú "neočakávané" udalosti a ich dôsledky. Vo väčšine prípadov sa však tieto neočakávané udalosti očakávať dajú, ba dokonca by sa očakávať mali. Úlohou mojej eseje je identifikovať riziká v softvérových projektoch a to najmä tie, ktoré sa často bagatelizujú a predsa sú významné vo vývoji. V práci sa taktiež venujem príčinám nevhodného plánovania a ďalších zaujímavých rizík vývoja softvérového projektu. Taktiež je cieľom odpovedať na otázku, či predchádzanie možným rizikám je efektívne, respektíve možné a v ktorých situáciách.