Szoftverminőség monitorozás forráskód alapján Dr. Beszédes Árpád Szegedi Tudományegyetem – Szoftverfejlesztés Tanszék 2006. május 3. Szoftvertechnológiai Fórum
Szoftvertechnológiai Fórum “You can’t manage what you can’t control, and you can’t control what you don’t measure.” (Tom DeMarco) 2006. május 3. Szoftvertechnológiai Fórum
Szoftvertechnológiai Fórum 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 2006. május 3. Szoftvertechnológiai Fórum
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) 2006. május 3. Szoftvertechnológiai Fórum
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 2006. május 3. Szoftvertechnológiai Fórum
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 2006. május 3. Szoftvertechnológiai Fórum
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) → … 2006. május 3. Szoftvertechnológiai Fórum
Szoftvertechnológiai Fórum Szoftver evolúciója 2006. május 3. Szoftvertechnológiai Fórum
Forráskód-alapú minőségbiztosítási módszertan rendszer-architektúrája Folyamatos mérés és monitorozás szükséges, melyhez eszközkészlet is kell! 2006. május 3. Szoftvertechnológiai Fórum
Szoftvertechnológiai Fórum 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ó) 2006. május 3. Szoftvertechnológiai Fórum
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 2006. május 3. Szoftvertechnológiai Fórum
utólagos dokumentálás függőségek és tervezési minták felismerése termékmetrikák Program megértés Architektúra visszanyerés Mérés C++ séma monitorozás Adatcsere Visszatervezett modell hibára való hajlamosság vizsgálata Forrás- kód Vizsgálat tényfeltárási eljárás stb. Vizualizálás Transzformált modell Módosított forráskód Újratervezés javítás, refactoring 2006. május 3. Szoftvertechnológiai Fórum
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 2006. május 3. Szoftvertechnológiai Fórum
Mérési modell, példa Eljárás paramétereinek száma Karbantarthatóság Ciklomatikus komplexitás Megbízhatóság Program mérete kódsorokban Hordozhatóság Hibaüzenetek száma Használhatóság Felhasználói kézikönyv hossza 2006. május 3. Szoftvertechnológiai Fórum
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ű 2006. május 3. Szoftvertechnológiai Fórum
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 2006. május 3. Szoftvertechnológiai Fórum
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 2006. május 3. Szoftvertechnológiai Fórum
Szoftvertechnológiai Fórum 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 2006. május 3. Szoftvertechnológiai Fórum
Metrikák és hibák kapcsolata Nincs hiba 50% Nincs hiba 36% Közepes hibaszám 38% Nincs hiba 18% Közepes hibaszám 28% Magas hibaszám 20% Közepes hibaszám 30% Magas hibaszám 35% Magas hibaszám 44% Magas kohézió Közepes kohézió Alacsony kohézió 2006. május 3. Szoftvertechnológiai Fórum
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 2006. május 3. Szoftvertechnológiai Fórum
Metrikák és hibák kapcsolata (folyt.) 2006. május 3. Szoftvertechnológiai Fórum
Szoftvertechnológiai Fórum 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. 2006. május 3. Szoftvertechnológiai Fórum
Szoftvertechnológiai Fórum 2006. május 3. Szoftvertechnológiai Fórum
Szoftvertechnológiai Fórum 2006. május 3. Szoftvertechnológiai Fórum
Szoftvertechnológiai Fórum 2006. május 3. Szoftvertechnológiai Fórum
Szoftvertechnológiai Fórum 2006. május 3. Szoftvertechnológiai Fórum
Szoftvertechnológiai Fórum Ö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 2006. május 3. Szoftvertechnológiai Fórum