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

Az előadások a következő témára: "Szoftverminőség monitorozás forráskód alapján"— Előadás másolata:

1 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

2 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

3 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

4 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

5 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

6 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

7 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

8 Szoftvertechnológiai Fórum
Szoftver evolúciója 2006. május 3. Szoftvertechnológiai Fórum

9 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

10 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

11 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

12 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

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 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

21 Metrikák és hibák kapcsolata (folyt.)
2006. május 3. Szoftvertechnológiai Fórum

22 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

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

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

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

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

27 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