Team Se@Msi: Meranie v softvérovom inžinierstve. - FIIT STU ...

Kolízie softvérových modelov – ako sa im vyhnúť 35
menšie projekty v rámci predmetov vyučovaných na fakulte, čo znamená
že prebiehaju v dosť neštandardných podmienkach, je zaujímavé
aplikovať opísané postupy aj na takéto projekty. Keďže niektoré z nich
práve bežia, je možné výsledky takej analýzy použiť na vyjasnenie zdrojov
problémov a ich zmiernenie.
Prvý z projektov, ktorý chcem spomenúť je záverečný projekt, ktorý
som riešil v poslednom roku bakalárskeho štúdia na Fakulte.
Zainteresované strany v projekte boli používateľ a vývojár, čím situácia
projektu bola podstatne zjednodušená. Výsledok projektu mal byť
interaktívna aplikácia so silnou orientáciou na užívateľské rozhranie. Už
pri samom začiatku projektu bolo jasné, že ide o vysoko rizikový projekt,
kvôli nedostatočnému poznaniu problémovej oblasti, slabej skúsenosti s
vývojovými prostriedkami a jedným z použitých programovacích jazykov,
a slabej zdokumentovanosti a rozširovateľnosti produktu, na ktorý sa mal
projekt nadväzovať. Ako model procesu bol zvolený vodopádový model.
Viedlo to ku kolízii modelov typu proces-úspech, medzi vodopádovým
modelom a modelom úspechu IKIWISI. Model IKIWISI bol zvolený, aj
keď v tom čase nevedome, z potreby vytvoriť používateľské rozhranie,
ktoré by zodpovedalo požiadavkám používateľa. Táto kolízia sa riešila
osvojením si neformálneho modelu procesu, ktorý sa podobal
špirálovému modelu. Druhý typ kolízie ,ktorý vznikol bol produktprodukt,
ktorý vznikol medzi modelom úspechu Premenlivé požiadavky
zo strany používateľa, a modelom úspechu Stabilné požiadavky zo strany
vývojára. Ďalší typ kolízie viditeľný v pavučine modelových kolízií bol
typu produkt-vlastnosť, kde prišlo do kolízii modelov Množstvo funkcií
na strane užívateľa a Uľahčenie dodržania rozpočtu a rozvrhu na strane
vývojára. Tieto kolízie neboli vyriešené a spôsobili mnoho ťažkostí počas
celej doby trvania projektu. Záverečný projekt skončil pomerne úspešne,
aj pri vysokých rizikách a problémoch, ktoré sa vyskytli.
Druhý z projektov je Tímový projekt, ktorý sa v čase písania tejto
eseje blíži k finálnej fáze. Cieľom projektu je vytvoriť systém pre
počítačovú podporu hodnotenia programov pre predmet Programovanie
jazyku C a rieši ho tím zložený z piatych osôb počas dvoch semestrov. V
jeho prípade by som chcel zdôrazniť iba jednu kolíziu modelov, a spôsob
ako sa s ňou vyrovnalo. Táto kolízia modelov sa zjavila medzi modelmi
typu úspech a produkt. Model úspechu bol zadaný ako podmienka výhry,
znejúca že systém musí byť vyskúšaný v prevádzke do konca druhého
semestra. Model produktu znel, že systém je určený pre podporu
hodnotenia programov pre predmet Programovanie v jazyku C. Pre
druhý model bol nevedome vytvorený nesprávny predpoklad, že je
systém určený pre hodnotenie programov napísaných v jazyku C. Ako sa
neskoršie zistilo, pri písaní programov pre predmet Programovanie v C je
povolené používať aj črty jazyka C++. Možné riešenia boli zakázať
používanie čŕt jazyka C++ v programoch pre tento predmet, alebo
prerobiť systém tak, aby podporoval programy vytvorené aj v jazyku C++.
Obe tieto riešenia boli nevyhovujúce, lebo ich nebolo možné uskutočniť
termíne stanovenom v podmienkach výhry. K riešeniu sa prišlo