Az előadás letöltése folymat van. Kérjük, várjon

Az előadás letöltése folymat van. Kérjük, várjon

Forráskód metrikák szerepe a szoftver minőségbiztosításban Szegedi Tudományegyetem Szoftverfejlesztés Tanszék.

Hasonló előadás


Az előadások a következő témára: "Forráskód metrikák szerepe a szoftver minőségbiztosításban Szegedi Tudományegyetem Szoftverfejlesztés Tanszék."— Előadás másolata:

1 Forráskód metrikák szerepe a szoftver minőségbiztosításban Szegedi Tudományegyetem Szoftverfejlesztés Tanszék

2 SZTE Szoftverfejlesztés Tanszék 2 “You can’t manage what you can’t control, and you can’t control what you don’t measure.” (Tom DeMarco)

3 SZTE Szoftverfejlesztés Tanszék 3 Szoftvermérés  termék vagy folyamat valamely jellemzőjét numerikusan kifejezni (metrika) Három fő csoport létezik  Folyamat és projekt metrikák Pl. egy hiba javításához szükséges átlagos idő  Specifikációs metrikák Pl. funkció-pontok  Termék metrikák (forráskódon alapuló metrikák) Pl. sorok száma, ciklomatikus komplexitás, osztály metódusainak száma

4 SZTE Szoftverfejlesztés Tanszék 4 Történelmi áttekintés Az első metrikákról szóló könyv 1976-ban jelent meg  Gilb T, Software Metrics, Chartwell-Bratt, Már a 60-as évek közepén használták a LOC (Lines of Code) metrikát  LOC/pm a programozók teljesítményének mérésére Az első modellek a LOC-ot használták teljesítmény, költség mérésére  Effort = f(LOC) A 60-as évek végén a LOC-ot használták minőség mérésre is  Defects/KLOC Első regressziós minőségbecslő modell (Akiyama, 1971)  A hibák sűrűséget becsülte a LOC metrika segítségével

5 SZTE Szoftverfejlesztés Tanszék 5 Történelmi áttekintés folyt. Új paradigmáknak megfelelő metrikák megjelenése  pl. objektum orientált, aspektus orientált, generatív Aggregált metrikák (attributes) megjelenése, validálása  Maintainability index, Functionality, Reliability, stb.  ISO/IEC 9126 Metrikákon alapuló modellek építése és validálása  Hibára való hajlamosság  Predikciós modellek Monitorozó rendszerek fejlesztése

6 SZTE Szoftverfejlesztés Tanszék 6 Metrikák szerepe, célja A menedzsment döntéshozatalának alátámasztása a szoftver teljes életciklusa során  Kockázat elemzés és csökkentés  Erőforrás és költségigények megjósolása Modellek építése – regressziós modellek, Bayes hálók  Szoftvertermék minőségének megbecsülése A metrikák lehetnek  Klasszikus / belső szoftver metrikák Pl. LOC, WMC, McCabe CC  Aggregált / külső metrikák – modellek Pl. karbantarthatóság, hibára való hajlamosság

7 SZTE Szoftverfejlesztés Tanszék 7 Forráskód metrikák jelentősége Általában a rendszer egyetlen hiteles leírása a forráskód Minőségirányítási rendszer bevezetésekor már létezik a szoftver egy verziója  A folyamat metrikákra nem támaszkodhatunk  A fejlesztés további része a Karbantartás és Továbbfejlesztés (termékmenedzsment) – a költségek 65%-át teszi ki 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

8 SZTE Szoftverfejlesztés Tanszék 8 Minőségbiztosítás Ipari környezetben a legelterjedtebb minőségbiztosítási eljárás a tesztelés Hátrányai:  Költséges  A teszt-kód minősége kérdéses (lefedettség)  Megelőzésre nem alkalmas (csak utólagos kezelésre) Előnyei:  Funkcionális hibák feltárására is alkalmasak  Az eredmények „könnyebben” kiértékelhetők A termékmetrikákon alapuló minőségbiztosítás pontosan a tesztelés hátrányait küszöböli ki  A tesztelés nem váltható ki vele teljes mértékben

9 SZTE Szoftverfejlesztés Tanszék 9 Forráskód metrikák helye a forráskód-alapú minőségbiztosítási módszertan rendszer- architektúrájában

10 SZTE Szoftverfejlesztés Tanszék 10 Metrikák kiértékelése A forráskód metrikák önmagukban nem nyújtanak semmit A kiértékelésükhöz (Diagnózis) szükséges:  Baseline értékek ismerete (nehéz: sok tapasztalat szükséges, domain-specifikus)  Szakértői tudás (metrikák jelentésének pontos ismerete)  Tendenciák vizsgálata Metrikus értékek változásának nyomon követése

11 SZTE Szoftverfejlesztés Tanszék 11 Baseline értékek Különböző rendszerek metrikus értékeinek szisztematikus gyűjtése  Univerzum  Nagy számok törvénye: sok rendszeren egy adott metrikára számított átlag „átlagos”. Jelenleg több nagy ipari, és open-source rendszerre vonatkozó metrikus értékekkel rendelkezünk  Méretük: 100 KLOC – 30 MLOC

12 SZTE Szoftverfejlesztés Tanszék 12 Baseline értékek folyt.

13 SZTE Szoftverfejlesztés Tanszék 13 Baseline értékek folyt. Rendszer minőségének kiértékeléséhez nem elég tudni hogy hány esetben van baseline túllépés, hanem a túllépés mértékét is figyelembe kell venni  Bonus-Malus modell  Statisztikai modellek építése

14 SZTE Szoftverfejlesztés Tanszék 14 Bonus-Malus modell Baseline index: -5,4 Baseline index: -6,02

15 SZTE Szoftverfejlesztés Tanszék 15 Bonus-Malus modell folyt. A modell hátrányai:  Diszkrét beosztás – a beosztás megválasztása önkényes  Nem szimmetrikus  Háromszög egyenlőtlenség nem teljesül Helyette precíz matematikai formalizmus szükséges

16 SZTE Szoftverfejlesztés Tanszék 16 Statisztikai modellek Bonus-Malus általánosítása Egy adott rendszer elemei rögzített metrika esetén bizonyos valószínűséggel vesznek fel egyes értékeket. Szoftvermetrikákkal kapcsolatos eloszlások:  Normális-eloszlás  Lognormális eloszlás  Pareto eloszlás Fat-tail eloszlások

17 SZTE Szoftverfejlesztés Tanszék 17 Statisztikai modellek folyt.

18 SZTE Szoftverfejlesztés Tanszék 18 Statisztikai modellek folyt. Fat-tail eloszlások  A várható értéktől messze is viszonylag nagy valószínűséggel vesz fel értéket Sok metrika Lognormális eloszlást követ  Például LOC, WMC, McCabe  Bizonyos „gráf-metrikák” is ilyenek (NI, NII)

19 SZTE Szoftverfejlesztés Tanszék 19 Statisztikai modellek folyt. Q-Q Plot μ = 0.7 σ = 1.2

20 SZTE Szoftverfejlesztés Tanszék 20 Statisztikai modellek folyt. Rendszerek összehasonlítása, rögzített metrika esetén:  Azonos eloszlás: f(μ 1, σ 1 ), f(μ 2, σ 2 )  Paraméterbecslések (maximum likelihood)  Norma definiálása  Származtatott távolság

21 SZTE Szoftverfejlesztés Tanszék 21 Forráskód metrikák csoportosítása A termékmetrikák lehetnek:  Nyelv-független (LOC)  Nyelv-specifikus (OOP paradigma) A típusuk szerint lehetnek:  Méret metrikák (LOC, NA, NM)  Öröklődés metrikák (DIT)  Komplexitás metrikák (McCabe, WMC)  Kohéziós metrikák (LCOM)  Csatolás metrikák (CBO)  Bad Smell (és Copy-Paste) metrikák (CC)  Kódolási minőség metrikák (szabálysértések)

22 SZTE Szoftverfejlesztés Tanszék 22 Méret metrikák Méret metrikák – a rendszer (elemek) mérete Legismertebbek:  LOC (Lines Of Code) – sorok száma  lLOC (Logical Lines Of Code) – nem üres, nem komment sorok száma  NCL/NST/NUN (Number of CLasses/ STructures/ UNions)  NNS (Number of Namespaces)  NA/NM (Number of Attributes, Number of Methods)  NF (Number of Functions) "Measuring programming progress by lines of code is like measuring aircraft building progress by weight." ~ Bill Gates.Bill Gates

23 SZTE Szoftverfejlesztés Tanszék 23 Méret metrikák (folyt.) LOC, lLOC  A legelső ismert/használt metrika [1]  Teljesítmény, komplexitás mérésére is használták [2] (assembly)  1983 Basili és Hutchens javasolta, hogy az összes többi metrikát a LOC metrikához viszonyítsák (normalizálás)  LOC metrikára több mint cikkben van hivatkozás Hátrányok:  Alacsony korreláció a funkcionalitással  Egyéni teljesítménymérésre nem alkalmas  Programozási nyelvek közötti különbségek  A funkciópontok számát nem befolyásolja  Fejlett GUI-eszközök figyelmen kívül hagyása

24 SZTE Szoftverfejlesztés Tanszék 24 Méret metrikák (folyt.) Statisztikai értékek: Mozilla LOClLOC FunctionMethodClassesFunctionMethodClasses Medián Átlag

25 SZTE Szoftverfejlesztés Tanszék 25 Öröklődés alapú metrikák A rendszerben található osztályok öröklődési kapcsolatait mérik Specialization és reUse metrikák  A strukturáltságot és az újrafelhasználást méri Az első öröklődés alapú metrikákat (DIT, NOC) Chidamber és Kemerer vezette be  Osztály szintű metrikák

26 SZTE Szoftverfejlesztés Tanszék 26 Öröklődés alapú metrikák (folyt.) ReUse index (U) =  Az osztályok újrafelhasználási arányát méri  Mozilla esetében ez az érték 0.38 Specialization index (S) =  Azt mutatja meg, hogy az ősosztályok mennyire sikeresen emelték ki a rendszer absztrakt tulajdonságait  A magas érték nagyfokú újrafelhasználást mutat a leszármazott osztályoknál  A Mozillánál ez az érték 2.22 ősosztályok száma összes osztály száma leszármazott osztályok száma ősosztályok száma

27 SZTE Szoftverfejlesztés Tanszék 27 Öröklődés alapú metrikák (folyt.)

28 SZTE Szoftverfejlesztés Tanszék 28 Öröklődés alapú metrikák (folyt.) DIT (Depth of Inheritance Tree)  Az mondja meg, hogy hányadik öröklődési szinten található az adott osztály  Ha túl mélyen található (DIT>5), akkor nehéz átlátni fejlesztés közben, hogy milyen tagjai vannak  karbantarthatóságot, fejleszthetőséget csökkenti Korábban vizsgáltuk a DIT és NOC illetve a hibák közti összefüggéseket  A DIT esetében „gyenge” kapcsolatot találtunk  A NOC esetében nem találtunk kapcsolatot

29 SZTE Szoftverfejlesztés Tanszék 29 Korreláció A metrikák és a hibaszámok közti korrelációs kapcsolat a Mozilla esetében BnumDITNOPNOANOCNOD Bnum1,0000,0160,1540,0670,000 DIT1,0000,2330,7830,000 NOP1,0000,4480,000 NOA1,0000,000 NOC1,0000,988 MetrikaMozilla 1.6 DIT1,52 NOP0,87 NOA1,93 NOC0,88 NOD1,95

30 SZTE Szoftverfejlesztés Tanszék 30 Komplexitás-metrikák Első komplexitás metrikákkal foglalkozó cikk 1968-ban jelent meg (Rubey [4]) A 70-es évek közepén jelentek meg a McCabe [6] és a Halstead [7] metrikák Thomas McCabe a komplexitás fogalmát a gráf-elméletből származtatta (ciklomatikus szám)  Függvények strukturális komplexitása  Alulról becsüli a lehetséges futtatható útvonalakat  Felűről becsüli a minimálisan szükséges teszt-esetek számát  McCabe által javasolt baseline érték: 10, speciális esetben 15 "The central enemy of reliability is complexity" Geer et al.

31 SZTE Szoftverfejlesztés Tanszék 31 Komplexitás-metrikák (folyt.)

32 SZTE Szoftverfejlesztés Tanszék 32 Komplexitás-metrikák (folyt.) Halstead komplexitás  Lexikális, textuális komplexitás  Operandusok, operátorok előfordulási számának felhasználásával  Azokon a részeken, ahol nagyobb mértékben szerepelnek számítási logikai megvalósítások a kód-minőség metrikák pontosabban közelíthetők Halstead metrikákkal  McCabe és Halstead egymást kiegészítik WMC komplexitás (Chidamber and Kemerer (C&K), H. Bär [8], Th. Panas [9])  A tartalmazott metódusok súlyozott összege (súlyok: McCabe, LOC, 1, stb.)

33 SZTE Szoftverfejlesztés Tanszék 33 Kohéziós metrikák Azt mérik, hogy egy osztály metódusai mennyire szorosan függnek össze egymással  Egy koherens osztály csak 1 funkcionalitást lát el, ellenkező esetben többet  Alacsony kohéziós érték rossz tervezést, magas komplexitásra utalhat (magasabb tesztelési költség) Metrikák:  LCOM{1,2,3,4} (Lack Of Cohesion on Methods) 

34 SZTE Szoftverfejlesztés Tanszék 34 Kohéziós metrikák (folyt.) LCOM5  Hitz & Montazeri  Az összefüggő komponensek számát adja meg  Egy osztályban elvileg 1 összefüggő komponensnek kellene lennie  Az összefüggő komponensek száma közelíti az osztály által megvalósított funkcionalitások számát  Mozilla: 6.18

35 SZTE Szoftverfejlesztés Tanszék 35 Kohéziós metrikák (folyt.) – LCOM5

36 SZTE Szoftverfejlesztés Tanszék 36 Csatolás metrikák Mérőszám, hogy ez egyes osztályok mennyire kapcsolódnak másokhoz  Metódushívásokon keresztül  Adateléréseken keresztül Magas csatolás érték  Alacsony egységbezárás  Újrahasználhatóság gátlása  Hibaszám növekedése (az osztály-interakciók következménye)  Alacsony tesztelhetőség  Változásra való érzékenység Legismertebbek:  CBO (Coupling Between Object classes)  RFC (Response For a Class)  COF (Coupling Factor)

37 SZTE Szoftverfejlesztés Tanszék 37 Csatolás metrikák (folyt.) CBO (Coupling Between Object classes)  Chidamber & Kemerer  Azon osztályok száma, amiket az adott osztály használ  „Ortogonális” a WMC metrikára  Hiba előrejelző modellek az irodalomból Tibor Gyimóthy, Rudolf Ferenc, István Siket [10] Hakim Lounis [11]  Döntési fa alapú modellekben a CBO a legjobb  Pl. Mozilla: CBO <=2 osztályok száma: 2286 (47 %) Lefedett hibák száma: 132 (5%)

38 SZTE Szoftverfejlesztés Tanszék 38 Csatolás metrikák (folyt.) RFC (Response For a Class)  Chidamber & Kemerer  Azon metódusok számát adja meg, amelyeket egy osztály meg tud hívni válaszul egy kapott üzenetre  RFC ~ WMC + CBO  Ha az objektum-orientáltság csökken, akkor a korreláció az RFC, WMC, CBO metrikák között csökken RFC -> WMC + CBO  Másik jelentés: Ha egy osztály túl sok választ tud adni egy üzenetre, akkor az nehezebbé teszi a tesztelését  Az átlag a Mozilla 1.6 esetében 19,4 CBORFCWMC CBO1,0000,6960,561 RFC1,0000,709 WMC1,000

39 SZTE Szoftverfejlesztés Tanszék 39 Bad Smell A szoftverfejlesztés során a keletkezhetnek nem kívánatos, kevésbé hatékony részek  Ezekre több jel is utalhat Ezeket rossz szagú (Bad Smell) helyeknek nevezzük  Nem metrikus érték, hanem a kód azon pontjainak a megjelölésére szolgál, amelyek valamilyen szempontból problematikusak  A Bad Smell-ek számának változása sokat mond a rendszer minőségének alakulásáról (ez is metrika) Nem mindig jelentenek hibát, csak felhívják a figyelmet olyan pontokra, amelyeket érdemes kivizsgálni Fowler [12], Wake [13] “If it stinks, change it." ~ Grandma Beck. Grandma Beck

40 SZTE Szoftverfejlesztés Tanszék 40 Bad Smell (folyt.) A tényleges Bad Smell javítás nehezebb mint az „egyszerű hibák” javítása  Komoly refactoringot igényel  Néha részek újratervezése szükséges Metrikákkal felismerhető Bad Smell-ek  Data Class - Adat Osztály  Feature Envy - Attribútum Irigység  Large Class - Nagy Osztály  Lazy Class - Lusta Osztály  Long Method - Hosszú eljárás  Long Parameter List - Hosszú Paraméterlista  Temporary Field – Ideiglenes mező

41 SZTE Szoftverfejlesztés Tanszék 41 Bad Smell (folyt.) - Mozilla

42 SZTE Szoftverfejlesztés Tanszék 42 Klón metrikák Copy-paste használat mérése  Karbantarthatóság Legfontosabb kapcsolódó metrikák:  CCL – Clone Classes  CI – Clone Instances  CC – Clone Coverage Paraméterek:  Klónok minimális hossza (LOC, NS, stb.)  Egyezés típusa (Teljes, Részleges)  Scope (Függvény-, Osztály-, global-scope)

43 SZTE Szoftverfejlesztés Tanszék 43 Klón metrikák (folyt.)

44 SZTE Szoftverfejlesztés Tanszék 44 Kódolási minőség metrikák Kódolási szabálysértések Scott Meyers: Effective C++ A korábbi metrikák nehézkesen használhatók egyéni teljesítmény mérésére A metrikus értékek kiértékelése az implikációk megbecsülése nehéz, sok befolyásoló tényezőtől függ, és nagy mértékben szubjektív A kódolási minőség metrikák  Könnyen megfoghatók  Közvetlen hatásuk van a kód-minőségre  „Könnyen” javíthatók  Objektíven kiértékelhetők

45 SZTE Szoftverfejlesztés Tanszék 45 Kódolási minőség metrikák (folyt.) Hátrányuk:  Csak lokális problémák felfedezésére alkalmas  Az összetettebbek nehezen számíthatók (CFG, PTA, …) – a kód részleges szemantikus értelmezése szükséges Kódolási szabálysértések osztályozása:  Bugs and Dangerous Constructs (BDC)  Memory Handling Problems (MHP)  Object Orientedness Problems (OOP)  Complexity Problems (CP)  Readability and Consistency problems (RCP)  Code Layout Problems (CLP) A csoportosításban átfedések vannak

46 SZTE Szoftverfejlesztés Tanszék 46 Aggregált metrikák Aggregált szoftver metrikák az ISO/IEC 9126 szabvány szerint  Funkcionalitás  Megbízhatóság  Használhatóság  Hatékonyság  Karbantarthatóság  Hordozhatóság

47 SZTE Szoftverfejlesztés Tanszék 47 Aggregált metr. (folyt.)

48 SZTE Szoftverfejlesztés Tanszék 48 Modellek Cél: költségek, erőforrásigények, szoftverminőség becslése Figyelembe kell venni, hogy  A metrikák sokszor szervezet- és termékfüggők  A metrikák az idő függvényében változnak  A tapasztalati tudás integrálása fontos Módszerek  Több metrika együttes vizsgálata Pl. statisztikai és gépi tanulási módszerek alkalmazása  Sok projekt esettanulmányának vizsgálata

49 SZTE Szoftverfejlesztés Tanszék 49 Modellek (folyt.) - Eszközök Lineáris regresszió  Lineáris kapcsolatot feltételez az ismert és ismeretlen mennyiségek között (metrikák vs. bugok száma)  A valóságban a kapcsolat nem lineáris  Előnye, hogy a hibaszámokat is becsli Logisztikus regresszió  Nem a hibaszámot, hanem csak a kategóriát (hibás-e) becsülhetjük vele (0 v. 1)  A kimenet egy 0 és 1 közé eső szám  Ezt az értéket kerekítettük (kisebb vagy nagyobb mint 0.5), így kaptuk meg a megfelelő kategóriát

50 SZTE Szoftverfejlesztés Tanszék 50 Eredmények (folyt.) Logisztikus regresszió CBO: MetrikaPontosság (Precision) Helyesség (Correctness) Teljesség (Completeness) WMC65.38%68.84%55.24% RFC66.01%71.89%53.60% CBO69.77%70.38%69.12% LCOM64.69%81.34%43.68% LOC66.85%72.98%54.58% Multi69.61%72.57%65.24% ModellPrecision (pontosság) Correctness (helyesség) Completeness (teljesség) Log. reg.69.77%70.38%69.12% Dönt. fa69.77%69.13%67.02% Neuronh %70.63%65.13%

51 SZTE Szoftverfejlesztés Tanszék 51 Referenciák [1] Park, Robert, E.: Software Size Measurement: A Framework for Counting Source Statements. Software Engineering Institute, Pittsburg, SEI-92-TR-020, 220 pages, May [2] Wolverton, R.W.: The Cost of Developing Large-Scale Software. IEEE Transactions on Computer, Volume C-23, No. 6, pp , June Also in: Tutorial on Programming Productivity: Issues for the Eighties, IEEE Computer Society, Second Edition, [3] L. M. Zap and B. Handerson-Sellers. Consistency consideration of object-oriented class libraries. Technical report, University of New South Wales, Sydney, Australia, research report no 93/3 [4] Rubey, R.J.; Hartwick, R.D.: Quantitative Measurement Program Quality. ACM, National Computer Conference pp , 1968

52 SZTE Szoftverfejlesztés Tanszék 52 Referenciák (folyt.) [5] Van Emden, M.H.: An Analysis of Complexity. Mathematisches Zentrum, Amsterdam, 1971 [6] McCabe, T.: A Complexity Measure. IEEE Transactions of Software Engineering, Volume SE-2, No. 4, pp , December 1976 [7] Halstead, M.H.: Elements of Software Science. New York, Elsevier North-Holland, 1977 [8] H. Bär, M. Bauer, O. Ciupke, S. Demeyer, S. Ducasse, M. Lanza, R. Marinescu, R. Nebbe, O. Nierstrasz, T. Richner, M. Rieger, C. Riva, A. M. Sassen, B. Schulz, P. Steyaert, S. Tichelaar, and J. Weisbrod. The FAMOOS Object-Oriented Reengineering Handbook. Technical report, Forschungszentrum Informatik, Karlsruhe, Software Composition Group, University of Berne, ESPRIT Program Project 21975, 1999.

53 SZTE Szoftverfejlesztés Tanszék 53 Referenciák (folyt.) [9] Th. Panas, R. Lincke, J. Lundberg,, and W. Löwe. A Qualitative Evaluation of a Software Development and Re-Engineering Project. In Proc. of the 29th NASA Software Engineering Workshop, April [10] Tibor Gyimóthy, Rudolf Ferenc, István Siket: Empirical Validation of Object-Oriented Metrics on Open Source Software for Fault Prediction. IEEE Trans. Software Eng. 31(10): (2005) [11] Hakim Lounis, Lynda Ait-Mehedine: Machine-Learning Techniques for Software Product Quality Assessment [12] Martin Fowler and Kent Beck. Refactoring: Improving the Design of Existing Code. Addison-Wesley, 2000.

54 SZTE Szoftverfejlesztés Tanszék 54 Referenciák (folyt.) [13] William C. Wake. Refactoring Workbook. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2003.


Letölteni ppt "Forráskód metrikák szerepe a szoftver minőségbiztosításban Szegedi Tudományegyetem Szoftverfejlesztés Tanszék."

Hasonló előadás


Google Hirdetések