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

8 Eseje
efektívnejšia aj cenovo, ako testovanie, t.j. technika kontroly je dôležitá.
Avšak rôzne prístupy môžu byť rôzne efektívne pre rôzne typy chýb. Preto
ľudia musia byť motivovaní, aby kontrolovali lepšie, aby verili v to, že je
to dôležité.
Harlan Mills navrhol techniku „Cleanroom“. Technika vychádza
z motivovania programátorov, aby vizuálne kontrolovali to čo napísali
tým, že nemôžu testovať funkčnosť programov. Výsledky testovania na
skupiny študentov potvrdilo základnú myšlienku vizuálnej kontroly:
• „Cleanroom“ programátori cítili väčší význam v opätovnej kontrole
ako sústredenie sa na funkcionálne testovanie, strávili menej času pri
počítači a použili menej softvérových prostriedkov.
• Ich programy mali nasledovné vlastnosti: menej komplexné, písali
viac komentárov, viac priraďovacích operácii, ich produkty boli
blízko k požiadavkám
• Mnoho Cleanroom vývojárov modifikovalo svoj programovací štýl a
chcú ďalej používať tento prístup, teda získané výsledky pozitívne
vplývali aj na prístup k tvorbe softvéru.
Údaje o používaní metódy „Cleanroom“ v NASA ukazujú, že počet
chýb počas testovania sa znížil o 25 až 75%. Údaje takisto ukazujú, že
oprava chýb trvala dlhšie, ako jednu hodinu len u 5% chýb, kým
štandardný proces ukazuje mieru až 60%.
Druhá technika je PSP (Personal Software Process – osobný
softvérový proces), ktorého autorom je Watts Humphrey. PSP sa
sústreďuje na jadro vzniku chýb – analyzovaním chýb jednotlivcov a
vytvorením osobných kontrolných zoznamov s cieľom vyhnúť sa
opakovaným chybám. Tým docielime k značnému zníženiu chýb. PSP
tréningové kurzy ukazujú 10 krát menší počet vyskytnutých chýb po 10
cvičeniach ako počas prvého tréningu. Efekty pri reálnych projektoch sú
však viac rozptýlené, pretože efekty závisia aj od faktorov ako je zrelosť
organizácie, ochota personálu a organizácie pracovať vo vysoko
štruktúrovanej softvérovej kultúre. Keď spájame PSP s úzko súvisiacou
TSP (Team Software Process – tímový softvérový proces), miera chýb sa
zníži o 10 alebo viackrát v organizácii, ktorá je dostatočne zrelá.
Vyvíjajme vysoko spoľahlivé systémy
Náklady na vývoj jedného riadku programu sú o 50% vyššie pri vývoji
softvéru s veľkou prevádzkovou spoľahlivosťou, ako pri vývoji menej
spoľahlivých výrobkov. Teda u spoľahlivejších produktov celkové
investície sú väčšie ako morálna hodnota produktu. Ak však projekt
zahrňuje aj údržbu softvéru, potom tieto hodnoty sa vyrovnávajú. Veď
produkty s veľkou spoľahlivosťou potrebujú menej nákladov na údržbu.
Analýzou 161 projektov sa zistilo, že polovica projektov mala väčšie
náklady kvôli požadovanej spoľahlivosti softvéru, ako sa očakávalo.
Avšak odhad nákladov na údržbu v Cocomo II naznačí, že údržba menej
spoľahlivého softvérového systému je o 50% drahšia ako vývoj, pričom