Team Se@Msi: Meranie v softvérovom inžinierstve. - FIIT STU ...
Team Se@Msi: Meranie v softvérovom inžinierstve. - FIIT STU ...
Team Se@Msi: Meranie v softvérovom inžinierstve. - FIIT STU ...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Chyby v procese tvorby softvéru a ich príčiny<br />
Spracované podľa: Boehm, B. – Basili, V. R.: Software Defect Reduction<br />
Top 10 List. Computer IEEE, január 2001, 135-137.<br />
Zoltán Varga<br />
Abstrakt. Zložitosť softvérových systémov a rýchly vývoj<br />
je hlavným faktorom vzniku zbytočných, vyhnuteľných<br />
chýb v programoch počas vývoja. Chyby nevznikajú len z<br />
dôvodu nepochopenia požiadaviek a funkcií systémov, ale v<br />
dosť veľkej miere ich zapríčiňujú aj iné faktory ako<br />
nedisciplinovanosť, neperspektívny pohľad, zlé zvyky<br />
vývojárov. Ak poznáme zdroje chýb, potom vieme nájsť aj<br />
techniku na redukciu chýb. Použitím rôznych techník a<br />
dobrých rád počas vývoja softvéru môžeme znížiť<br />
vynaložené úsilie a náklady, čím dosiahneme väčšiu<br />
efektivitu práce.<br />
C<br />
hyby v produktoch v softvérovom inžinierstve sa vyskytujú dosť<br />
často, vyplývajú mnohokrát z vlastností softvéru ako je zložitosť,<br />
neviditeľnosť, meniteľnosť. Na tieto faktory jednoznačne vplývajú aj<br />
nedostatočné predstavy zákazníkov, čo požadujú. Každý programátor má<br />
cieľ znížiť počet chýb počas tvorby, ale neočakávané zmeny (hlavne<br />
zmeny v požiadavkách) nútia ich k stálej zmene systému. Barry Boehm a<br />
Victor R. Basili uvádzajú v [Boehm01] zoznam desiatich najzávažnejších<br />
chýb počas vývoja softvéru, a tiež dávajú návod na ich odstraňovanie.<br />
Pojem chyby treba chápať v širšom slova zmysle. Nehovoríme len o chybe<br />
počas vykonávania programu, ale zahrňuje aj nedostatky vo fáze<br />
špecifikácií požiadaviek, návrhu a implementácie.<br />
Na vine je nedostatočná špecifikácia<br />
Vyhľadanie a oprava chýb po zavedení systému do prevádzky je často 100<br />
krát drahšia ako vyhľadanie a oprava týchto chýb vo fáze špecifikácie a<br />
návrhu. Pomer 100:1 neplatí vždy, lebo sa dokázalo, že pre menšie<br />
systémy je to len 5:1. Hlavným dôvodom na zmenu je zmena požiadaviek<br />
používateľov. Avšak tento problém možno jednoducho vyriešiť neustálym<br />
prototypovaním a dobrým návrhom modulov, ktoré sú voľne zviazané.<br />
5