Zborník esejí 2011

Abstrakt:Softvérové inžinierstvo ako relatívne mladé odvetvie prešlo za niekoľko desiatok rokov neskutočným vývojom. S rozvojom softvérového inžinierstva sa samozrejme menil aj spôsob, akým sa vyvíjaný softvér testuje. Testovanie softvéru sa s postupom času profesionalizovalo a automatizovalo, keďže sa vytvárané systémy stávali väčšími a zložitejšími a cena neskoro objavenej chyby rástla. Dnes máme na svete niekoľko prístupov k testovaniu softvérového produktu. V mojej eseji sa zamýšľam nad tým, kde sa testovanie nachádza teraz a kam bude tento vývoj ďalej smerovať. Spomínam niektoré známe techniky ako napríklad metóda čiernej a bielej skrinky, ale aj modernejší prístup ako testovaním riadený vývoj. V eseji uvažujem, kde je ktorú metódu vhodné použiť vzhľadom na veľkosť projektu a fázu vývoja, kto v tíme má testovať a ako. Na záver pripojím svoj názor na testovanie nášho projektu na predmete Tímový projekt.

Abstrakt:Odhad softvérového projektu môže veľmi ovplyvniť proces jeho plánovania, jeho priebeh, aj jeho výsledok. Ako ich ovplyvní, závisí od jeho presnosti. Všeobecne platí, že čím presnejší odhad, tým lepšie. Ale ako dosiahnuť presný odhad? Je to vôbec možné? Vytvorenie dobrého odhadu softvérového projektu je nákladné a náročné. Oplatí sa pre všetky projekty vytvárať odhady? Ak áno, ako by sa mali vytvárať? Na tieto, ale aj iné otázky hľadám odpoveď v mojej eseji. Venujem sa niekoľkým metódam odhadovania softvérových projektov, ich náročnosti a presnosti. Zamýšľam sa nad potrebou odhadovania rôznych typov softvérových projektov a nad tým, ako by sa mali v týchto projektoch vytvárať odhady. V neposlednom rade rozoberám aj problematiku odhadovania vzhľadom na náš tímový projekt.

Abstrakt:V súčasnosti sa pri vývoji softvéru v tíme stretávame so situáciou, kedy sa jednotliví členovia tímu môžu počas celého cyklu vývoja nachádzať na ľubovoľnom mieste na svete. Táto skutočnosť im žiadnym zásadným spôsobom nebráni vykonávať svoju úlohu v tíme. Jedným z problémov, ktoré vznikajú pri riadení projektu je, akým spôsobom kontrolovať stav projektu a taktiež vyťaženosť jednotlivých členov tímu. Cieľom mojej eseje je poukázať na prínos podporných prostriedkov, ktoré umožňujú sledovať stav projektu, či už ide o projekty riadené agilnou alebo inkrementačno-iteračnou metodológiou. V eseji uvažujem nad technikami, ktoré je možné použiť kombináciou metód zobrazovania využívaných v oboch metodológiach. Pri písaní eseje som sa snažil vyjadriž vlastný názor na danú problematiku, pričom som čerpal zo svojich doterajších skúseností.

Abstrakt:Pri tvorbe čo i len trochu väčších softvérových projektov je vhodné, aby sa na ich tvorbe podieľali viacerí ľudia a vytvorili tak čo najlepšie fungujúci tím. Poskladať takýto tím sa niekedy ukazuje ako veľké umenie. Nie je najlepším riešením obsadiť každú pozíciu tým najväčším odborníkom v danej oblasti, je potrebné brať do úvahy aj charakterové vlastnosti jednotlivých členov. Dokonca ako najlepšie riešenie sa zdá obsadiť tím čo najpestrejšie a mať v tíme čo najväčšiu rôznorodosť osobností. V tejto eseji stručne približujem vlastnosti osobností podľa často používaného Myers-Briggsovej typového indikátoru a vhodnosť osôb pre konkrétne pozície v tíme. Zaoberám sa konfliktami, ktoré pri spolupráci viacerých osôb môžu nastať a spôsobom, ako im čo najlepšie predchádzať. Zamýšľam sa nad spôsobom tvorby tímov pre účely malých projektov, akými sú napríklad tímové projekty na univerzitách. Keďže som v čase písania eseje sám súčasťou tímu, ktorý pracuje na tímovom projekte, analyzujem náš tím a na základe výsledkov testov MBTI odhadujem našu výkonnosť.

Abstrakt:Malé projekty bývajú často podceňované, preto sa pri nich nekladie veľký dôraz na analýzu a plánovanie rizík. Tento fakt môže zapríčiniť komplikácie projektu, v horších prípadoch jeho úplné zlyhanie. Z veľkej časti to má za následok zámerné prehliadanie formujúcich sa problémov a ľahkovážny prístup. Pritom by veľká časť týchto problémov vôbec nemusela nastať, alebo by sa dali veľmi ľahko vyriešiť pri správnom prístupe. Cieľom tejto eseje je zhodnotiť najzávažnejšie riziká vyskytujúce sa pri malých projektoch, pričom vychádzam aj z vlastných skúseností. Ďalším cieľom je ukázať základné princípy predchádzania týmto rizikám a zhodnotiť chyby, ktoré sa najčastejšie robia pri softvérových projektoch.

Abstrakt:Tímy pracujúce na softvérových projektoch majú medzi svojimi cieľmi splnenie termínu a dodanie kvalitného produktu zákazníkovi. Na to aby tieto ciele splnili musia mať dostatok času. Monitorovanie projektu je užitočné, lebo dokáže odhaliť prípadný časový sklz a tak prispieť k splneniu cieľov. Ak sa však venuje pozornosť sledovaniu využívajú sa na to zdroje, ktoré mohli byť vynaložené napríklad na vývoj. Je teda monitorovanie stratou času? Nestratím jeho používaním viac, ako získam? Monitorovanie progresu v softvérovom projekte má svoje výhody a nevýhody. Aké to sú? Ako správne a čo najefektívnejšie monitorovať projekt? Mali by sa členovia tímu monitorovať samostatne, alebo tým treba poveriť jedného konkrétneho človeka? V eseji sa nad týmito otázkami zamýšľam.

Abstrakt:Rozmanitosť a zložitosť softvéru vzrastá zo dňa na deň, preto musí byť zabezpečená kvalita softvéru. Kvalita softvérového systému je posudzovaná viacerými atribútmi kvality, či už je to výkon a použiteľnosť pre koncového používateľa alebo vysoká stabilita a opätovné použitie. Kladenie dôrazu na kvalitu softvéru zlepšuje vývoj systému a predchádza sa ním nejasnostiam pri samotnej implementácií. Testovanie je oproti zabezpečeniu kvality softvéru orientované na "detekciu". Pri testovaní kvality softvéru sa odhaľujú nedostatky a chyby vyvíjaného softvéru, preto je nevyhnutné testovať softvér, aj keď sa zdá, že nie je potrebné. V súčasnosti existuje mnoho rôznych metód ako správne testovať kvalitu softvéru. Esej sa sústreďuje na zabezpečenie kvality softvéru a presvedčí Vás, že vývoj riadený testami šetrí drahocenný čas a finančné prostriedky s porovnaním testovania softvéru po dokončení implementácie.

Abstrakt:Deľba práce nás sprevádza už tisícky rokov, najmä kvôli rozdielnym zručnostiam a schopnostiam každého človeka. Dodnes je tomu tak v najrozličnejších oblastiach, softvérové inžinierstvo nevynímajúc. Pre prácu na rozsiahlych tímových projektoch je potrebné množstvo ľudí rôznych zameraní – od empatického analytika cez poctivého programátora až po zodpovedných manažérov. Z výpočtu vlastností je zrejmé, že niektorí ľudia majú väčšie osobnostné predpoklady na konkrétnu prácu. Esej poukazuje na vhodnosť vytvárania rozmanitých tímov, nielen čo sa týka odborných vedomostí, ale aj po charakterovej stránke. Takáto skladba je výhodnejšia, negatíva z nej vyplývajúce sú prijateľnejšie a jednoduchšie riešiteľné ako pri uniformných tímoch. V eseji sa zameriavam najmä na menšie pracovné skupiny a na špecifiká vytvárania a fungovania školských tímov. Na záver analyzujem a vyhodnocujem študentský tím, ktorého som členom.

Abstrakt:Vývoj softvéru je spravidla zložitý a časovo náročný proces, ktorý je v každej fáze neodmysliteľne spojený s používaním rôznych súborov či dokumentov. Nie všetky súbory sú však vo finálnej podobe, ale sú predmetom ďalšej modifikácie. Najmä práca v tíme vyžaduje možnosť modifikovania spoločných súborov, kde vykonané zmeny nepredstavujú vždy napredovanie. Často je preto potreba vrátiť sa späť, k predošlej verzii. Sledovaním vývoja softvéru z tohto pohľadu sa dnes zaoberá manažment verzií a zmien. Metódy, podľa ktorých sa dá postupovať, sú rôzne. V tejto eseji vyslovujem svoj názor na jednotlivé metódy manažmentu verzií, zdôrazňujem ich výhody a nevýhody. Zamýšľam sa nad problémami, ktoré môžu pri použití jednotlivých metód vzniknúť a aký dopad to môže mať na celkový vývoj softvéru. Som presvedčený, že používať verzie jednoducho treba, ale ktorý spôsob je ten správny?

Abstrakt:Koordinácia a riadenie vývojového týmu si od projektového manažéra vyžaduje informovanosť o aktuálnom stave a rozdelení úloh v projekte. Na prehľad a správu týchto aktivít existuje široká škála podporných prostriedkov, ktoré v rámci softvérového projektu zohrávajú dôležitú úlohu. Pri veľkých projektoch sú tieto nástroje potrebnou, a priam nevyhnutnou podmienkou úspechu. Opodstatnené uplatnenie našli v komerčnej sfére, kde je motivácia k dodržiavaniu termínov odovzdávania pridelených úloh zrejmá. Esej uvažuje prípad využitia podporného nástroja pre sledovanie a riadenie úloh v rámci Open-source projektov. Pojednáva projekty, ktoré sú vyvíjané komunitou a vývojárom sa môže stať v podstate „hocikto”. Motivácia takéhoto vývojára je diskutabilná a manažér musí pri manažovaní takéhoto tímu riešiť problémy s ľudskými zdrojmi, ako je záťaž alebo čas trvania úlohy, oveľa častejšie, pričom riešenia nie sú vždy priamočiare a problémy sa môžu často opakovať.

Abstrakt:Od malička máme svoje predstavy o svojej budúcnosti, svoje sny a ciele. Na ich dosiahnutie väčšinou potrebujeme si vytvoriť plány a podľa nich sa riadiť. Nie je to inak ani v softvérovom inžinierstve. Na dosiahnutie vytýčených cieľov potrebujeme cieľavedome postupovať podľa dobre premysleného plánu. Táto esej je venovaná plánovaniu. Na začiatku si predstavujeme čo presne máme na mysli keď rozprávame o plánovaní a predstavíme niekoľko nástrojov a metód, bežne využívaných pri vytváraní plánov. Ako v bežnom živote, aj počas vývoja softvéru sa vyskytujú nepredvídané deje ktoré môžu zmeniť, alebo úplne pokaziť naše plány. Uvedieme niekoľko príkladov, aj z vlastných skúseností, na to ako sa prerábajú plány.

Abstrakt:Kooperácia väčšieho počtu ľudí pri vývoji softvéru je v súčasnosti bežnou praxou. Dôležitým predpokladom takejto spolupráce je komunikácia medzi jednotlivými členmi tímu, pričom dôraz sa kladie najmä na jej efektivitu. Komunikácia môže prebiehať rôznymi spôsobmi, a tiež môžu byť na komunikáciu využité rôzne podporné prostriedky, ktoré v značnej miere prispievajú k jej zjednodušeniu a zefektívneniu. Dôležitým faktorom hodnotenia efektivity komunikácie je taktiež porozumenie a správna interpretácia obsahu komunikácie všetkými zúčastnenými. V eseji uvádzam existujúce formy komunikácie využívané v softvérových tímoch a zaoberám sa komunikáciou z pohľadu efektivity a vplyvu na úspešnú realizáciu projektu, ako aj možnými problémami, ktoré vznikajú pri tímovej komunikácii. Načrtnem aj možnosti a výhody využitia podporných komunikačných prostriedkov v tímovej komunikácii a v závere aj aktivity na budovanie tímu ako spôsob zefektívnenia komunikácie a tým zvýšenia produktivity tímu.

Abstrakt:Vetu vraviacu „Mýliť sa je ľudské“ počul pravdepodobne každý z nás. Nečudo, veď každý zažil určite množstvo vlastných alebo cudzích pochybení. Čím zložitejšej činnosti sa človek venuje, tým náchylnejší je k tomu, že spraví niečo neželané. Softvérové systémy neustále naberajú na svojej komplexnosti - nové oblasti aplikácie, distribuovanosť, rozšíriteľnosť a nárast veľkosti nasadenia sú len niektoré z pribúdajúcich výziev pre vývojárov. So zväčšujúcou sa zložitosťou vznikajú aj ďalšie riziká a ich zmiernenie má zase na starosti človek. Pri tom väčšinu naplnených rizík má na svedomí „ľudský faktor“. Dôvodov k týmto zlyhaniam je mnoho, od slabšieho vnímania až k nedostatku skúseností alebo vedomostí. Možných riešení, líšiacich sa od seba svojou náročnosťou a efektivitou, je tiež veľké množstvo. Preto je nad tým, ako sa vyhýbať človekom spôsobeným rizikám, veľmi dôležité uvažovať. Už od Senecu totiž vieme, že mýliť sa je ľudské, ale zotrvávať v omyle je diabolské.