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

Kolízie softvérových modelov – ako sa im vyhnúť 31
zrážok sa projekt dostane do problémov, je zložité odhaliť pravý zdroj
problémov. Zriedkavé je, že sa pre problémy obviňujú modely. Namiesto
toho sa hľadajú povrchové lieky pre daný problém, ako sú redukcia
cieľov, pridanie ľudí do projektu, zmena manažéra, zakúpenie ďalších
vývojových prostriedkov. Tieto snahy väčšinou zostávajú bez výsledkov a
často situáciu ešte zhoršia.
Modely sa spoliehajú na rôzne predpoklady, ktoré však nie vždy
musia byť správne a zhodné s predpokladmi iných modelov. Kolízia
modelov odzrkadľuje nezrovnalosti medzi predpokladmi rozličných
modelov úspechu, procesu produktu a vlastnosti, ktorými sa daný projekt
riadi. Keď príde ku ich kolízii, vytvára sa atmosféra zmätku, nedôvery,
stresu. Chybné časti je potrebné prerábať alebo celkom zahodiť, čo
vytvára ďalšie problémy s časom a finančnými prostriedkami. Všetko toto
prispieva k tomu, aby vývojár, ale aj iný zúčastnení v projekte mali pocit,
akoby sa s obrovskou námahou ťahali cez projekt ako cez dechtovú dieru.
Názorný príklad nesprávnych predpokladov o ktoré sa model opiera
je známe Zlaté Pravidlo. Aj keď sa na prvý pohľad zdá, že toto tvrdenie
vždy musí byť správne, keď sa ono uplatní pri tvorbe softvérových
produktov stáva sa zdrojom mnohých nedorozumení, konfliktov a
neúspechov. Zlaté Pravidlo, ktoré znie Rob pre iných, ako si praješ aby
oni robili pre teba, sa v kontexte vývoja softvéru môže pretransformovať
na Vyvíjaj systém pre iných, predpokladajúc že oni tiež vyvíjajú softvér
a vedia mnoho o počítačoch. Softvérové produkty vyvíjané podľa tohto
modelu úspechu sú síce efektívne a flexibilné, ale nezrozumiteľné pre
obyčajných používateľov a považované za neúspešné. Aj keď vyhoveli
modelu úspechu Zlaté Pravidlo ktorým sa viedli, nevyhoveli modelu
úspechu víťazné podmienky držiteľov podielu (stakeholder win-win).
Dôvod neúspechu je v predpoklade, ktorým bolo Zlaté Pravidlo
podložené: Všetci sú podobní. Zrejme, toto tvrdenie je nesprávne a
väčšina používateľov ma celkom iný pohľad a požiadavky na softvér, ako
ľudia ktorý ho vyvíjajú. Ako riešenie ponúka sa Platinové Pravidlo: Rob
pre iných, ako si to oni želajú.
Kolíziu medzi modelmi typu proces a produkt dobre ilustruje príklad
kolízie medzi vodopádovým modelom a modelom využitia hotových
produktov. Predpoklady, o ktoré sa opiera vodopádový model sú, že
požiadavky a zdroje sú vopred pevne definované a neexistujú žiadne
vysoko rizikové dôsledky týchto požiadaviek. Model využitia hotových
produktov predpokladá, že sú požiadavky formované na základe
možností hotových produktov. Možné problémy vyplývajúce z týchto
predpokladov sú, že vopred zadefinované požiadavky vo vodopádovom
modeli nemusia byť realizovateľné pomocou dostupných systémov alebo
sa to nemusí oplácať. Ak sú požiadavky dané v zmluve, prichádza k
ďalším problémom a drahým súdnym sporom pokým sa nedosiahne
kompromis a nereálne požiadavky sa zrušia. Riešenie, ktoré sa môže
použiť v tomto prípade je súbežne vyvíjať požiadavky a manažment rizík
pri používaní hotových produktov.