szoftverminőség monitorozás forráskód alapján

2006. május 3. Szoftvertechnológiai Fórum 1

Szoftverminőség monitorozás forráskód alapján

Dr. Beszédes Árpád

Szegedi Tudományegyetem – Szoftverfejlesztés Tanszék

SZTE Szoftverfejlesztés Tanszék

Szoftvertechnológiai Fórum 22006. május 3.

“You can’t manage what you can’t control, and you can’t control what you don’t measure.”

(Tom DeMarco)



Szoftvermérés DeMarco: Csak mérés alapján végezhetjük a

minőségmenedzsmentet Igen, mérjünk, de mit? Minőségkezelés eredeti alapfeltevése:

Fejlesztési folyamat minősége meghatározza a termék minőségét

Erre építenek a különböző minőségirányítási rendszerek: ISO, CMMI



Szoftvermérés (folyt.) Azonban, két alapvető módon

befolyásolhatjuk a vezetői döntéshozatalt: Vezérlési metrikákkal. Folyamattal

kapcsolatosak, pl. egy hiba javításához szükséges átlagos idő (folyamat és projekt metrikák)

Prediktor metrikákkal. Termékkel kapcsolatosak, pl. LOC, ciklomatikus komplexitás, osztály metódusainak száma, kódolási szabályok megsértésének mértéke (termék metrikák)



Termékmetrikák jelentősége Minőségirányítási rendszer bevezetésekor már

létezik a szoftver egy verziója Fejlesztés további része Karbantartás és

Továbbfejlesztés lesz (termékmenedzsment) A teljes életciklus 80%-át, a költségek 65%-át teszi ki Kezdeti fejlesztési költségek többszörösét teszik ki, és

idővel csak növekednek! Szoftverváltozás elkerülhetetlen

Pl. új követelmények, új üzleti környezet, hibajavítás, teljesítmény vagy megbízhatóság javítása

Változás hatékony kezelése a kulcsprobléma



Termékmetrikák (folyt.) Stratégiák változás kezelésére:

Szoftverkarbantartás Architekturális átalakítás Szoftver újratervezése

Nagyon sokszor az egyetlen hiteles leírása a rendszernek a forráskód maga

Meg kell határozni annak kiindulási minőségét Hogy a költségeket becsülni tudjuk, és Képesek legyünk javítani a folyamatunkon

Folyamat és termék mérése együtt kell hogy történjen, egymást kiegészítve



Minőségmérés forráskód alapján Ember:

Leletkészítés → Diagnózis → Kezelés/Megelőzés → Ellenőrzés → …

Szoftver: Mérés → Megértés/Minőségjellemzők →

Refactoring/Újratervezés/Folyamatjavítás → Ellenőrzés (újabb mérés) → …



Szoftver evolúciója

MÉRÉS

DIAGNOSZTIKA

FEJLESZTÉS

MEGELŐZÉS

MÉRÉS

Projekt kezdet Kezdeti release Karbantartás és Továbbfejlesztés...

...

fejlesztő

menedzser



Forráskód-alapú minőségbiztosítási módszertan rendszer-architektúrája

Folyamatos mérés és monitorozásszükséges, melyhez eszközkészlet is kell!



Columbus technológia FrontEndART Szoftver Kft. Nagy C++ rendszerek analizálására alkalmas

Ezen belül minőség mérésére, monitorozására Eddigi tapasztalatok (1-30 MLOC)

Nokia platform kódja Graphisoft ArchiCAD Nuance Scansoft Recognita Mozilla OpenOffice/MagyarOffice (Multiráció)



Visszatervezés és újratervezés Nagy mennyiségű örökölt kód létezik

Kritikus fejlesztők elérhetetlenek Új munkatársak Programmegértés támogatása

Ún. ősrendszerek (legacy system) esetében nagyon fontos

Visszatervezés (Reverse Engineering) Forráskódból modell előállítása

Újratervezés (Reengineering) Visszatervezett modell továbbfejlesztése, új rendszer

megvalósítása



Forrás-kód

Visszatervezettmodell

Transzformáltmodell Módosított

forráskód

Architektúravisszanyerés

Vizualizálás

Programmegértés

Mérés

Vizsgálat

Újratervezés

stb.

C++ séma

tényfeltárásieljárás

függőségek és tervezési minták felismerése

hibára valóhajlamosság

vizsgálata

javítás, refactoring

termékmetrikákutólagos

dokumentálás

monitorozás



Minőségi jellemzők mérése Jellemzőket lehetetlen közvetlenül mérni

Magasabb szintű absztrakciók, sok mindentől függnek Hierarchikus összetétel (jellemzők származtatása) Sokszor szervezet- vagy termékfüggő Több metrika együttes vizsgálata Metrikák változása az idő függvényében Statisztikai technikák alkalmazása

Metrikák (belső jellemző) és (külső) jellemzők közötti kapcsolatokra fel kell állítani egy modellt Sok projekt esettanulmányának vizsgálata



Mérési modell, példaKarbantarthatóság

Megbízhatóság

Hordozhatóság

Használhatóság

Eljárás paramétereinek száma

Ciklomatikus komplexitás

Program mérete kódsorokban

Hibaüzenetek száma

Felhasználói kézikönyv hossza



Termékmetrikák forráskód alapján Dinamikus

Szorosabb kapcsolat egyes minőségi jellemzőkkel (pl. teljesítmény, hibák száma)

Statikus Közvetett kapcsolat Számtalan konkrét metrikát ajánlottak már Kritikus kérdés: hogyan következtetünk a minőségi

jellemzőkre a sok számból? Mérések (OO rendszerek esetében)

Eljárásszintű Osztályszintű Rendszerszintű



Példák egyszerű metrikákra Forráskód sorok száma: LOC (többféle) McCabe ciklomatikus komplexitás eljárásokra Kohézió: LCOM (Lack of COhesion in Methods)

Minél nagyobb, a metódusok annál kevésbé koherensek Csatolás (coupling): CBO (Coupling Between Objects). Ha

az osztály egy másik osztály attribútumát vagy metódusát használja, akkor növekszik Minél kisebb kell hogy legyen

Rendszerszintű metrikák: U (reUse ratio) = ősosztályok / összes osztály S (Specialization ratio) = származtatott osztályok / ősosztályok



További fontos metrikák Forráskód auditálás

Verifikációnál is alkalmazzák Automatikus, eszközök segítségével, pl. LINT Kódolási stílus, külalak Potenciálisan veszélyes szerkezetek felismerése Hibák, biztonsági rések statikus felfedezése Nem helyettesíti a tesztelést, de pl. hibák 60%-a

felderíthető így

Számszerűsíthető! Szabálysértések száma osztályonként



Rossz előjelek Speciálisan auditálható tulajdonságok „Bad smell”-ek Nem feltétlenül jelentenek problémát De jó alapjaik a refactoring-nak Egyszerűek is vannak, pl. túl nagy osztály Az egyik legfontosabb:

Kód-duplikáció detektálása „Klónok” felfedezése



Metrikák és hibák kapcsolata

Nincs hiba50%

Magas hibaszám

20%

Közepes hibaszám

30%

Közepes hibaszám

28%Magas hibaszám

35%

Nincs hiba36% Közepes

hibaszám38%

Magas hibaszám

44%

Nincs hiba18%

Magas kohézió Közepes kohézió Alacsony kohézió



Metrikák és hibák kapcsolata (folyt.) Kísérlet Mozilla rendszerrel (3,000 osztály), és a

Bugzilla hiba-követő rendszerével (250,000 hiba) Mozilla különböző verziói javultak (1.0 [2002] és 1.6

[2005] között) Hibák száma szerint is Metrikák szerint is

Korreláció vizsgálata a hibák száma és egyes metrikák között

Gépi tanulási modellt állítottunk elő, mellyel előre jelezhetők a problémás osztályok



Metrikák és hibák kapcsolata (folyt.)



Monitorozás A megalkotott modelleket egy monitorozó

rendszerben implementáltuk Rendszeresen méri a szoftvert Különféle vizualizációk és lekérések, pl.

Hisztogram Metrikus értékek időbeni változásai Mesterséges intelligencia

Speciális hibamodell: kódolási konvenciók megsértésének hatása a hibákra További modellek építhetők: karbantarthatóság,

biztonság, stb.



Összegzés Csak mérés alapján végezhetjük a

minőségmenedzsmentet Termékmetrikák: közvetetten irányíthatják a

minőségbiztosítási folyamatokat Karbantartás és továbbfejlesztés fázisában fontosak,

amikor meglévő rendszerről kell mondani valamit Folyamatméréssel együtt kell(ene) alkalmazni

Forráskód-alapú minőségbiztosítási módszertan 4 rétegű architektúra Eszközkészlet és monitorozás szükséges Columbus technológia

szoftverminőség monitorozás forráskód alapján

Documents

click here and type

click to type notes

mrs alapjn vgezhetjk

minsgmrs forrskd alapjnember