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

“You can’t manage what you can’t control, and you can’t control what you don’t measure.” (Tom DeMarco)

Szoftvermérés Szoftvermérés Három fő csoport létezik 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 Általános fogalmak, definíciók, a metrikák csoportosítása. Mi, a jelen előadásunkban, ahogy a cím is mutatja csakis termékmetrikákkal foglalkozunk

Történelmi áttekintés Az első metrikákról szóló könyv 1976-ban jelent meg Gilb T, Software Metrics, Chartwell-Bratt, 1976. 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 Az ember szereti számokkal kifejezni a dolgokat. Nincs ez másképp a szoftverek esetében is… Az első metrikákat assembly kódra alkalmazták, és ebben a nyelvben elég jól kifejezte a kód komplexitását is. Akkoriban még a programozók teljesítményét LOC-ban mérték. Ma már tudjuk, hogy ez nem jó. Egy mai felmérés szerint egy jó programozó napi átlag 15 sor jó minőségű kódot ír. Az első becslő modellek regresszión alapultak. Az új programozási nyelvek miatt vált szükségessé új metrikákat definiálni. A régiek nem mindegyike volt alkalmazható, továbbá új paradigmák jelentek meg, amelyeket szintén „mérni kellett”.

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 Az első metrikák megjelenése óta, a következő területeket kutatják a legintenzivebben. A legújabb kutatások elsősorban modellek építésére, és a monitorozó rendszerek fejlesztésére koncentrálnak. Validálás, általaban nyilt forráskódú v. ipari rendszereken. Az ipari eredmények nagy hátránya, hogy nem megismételhetők és nem ellenőrizhetők. Általában még az ipari partner kiléte sem ismert.

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 A döntéshozatalnál a következő típusú kérdések merülhetnek fel: 1. „Egy ilyen komplexitású specifikáció esetében, és adott korlátos erőforrások igénybevételével mi az esélye annak, hogy egy elfogadható minőségű terméket kapunk?” 2. „Mennyivel csökkenthetem az erőforrásokat, ha fel vagyok készülve arra, hogy egy gyengébb minőségű szoftvert kapjak” 3. „A modell azt jósolja, hogy négy emberre van szükség 2 éven keresztül, hogy az adott szoftver elkészüljön. De csak 3 emberem van 1 évre. Ha nem akarom a minőség rovására elkészíteni a szoftvert, milyen jó minőségűnek kell hogy legyenek a csapattagok?”

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 A minőségbiztosítás alapfeltevése, miszerint a fejlesztési folyamat minősége meghatározza a termék minőségét. Ez azonban nem alkalmazható, ha a minőségbiztosítás a fejlesztési folyamat közben kerül bevezetésre. Ilyenkor a kiindulási rendszer minőségét forráskód-metrikákkal tudjuk becsülni. A termékmetrikák használata jóval olcsóbb, mint egy folyamat minőségbiztosítása, és használható a folyamat minőségének mérésére is (az alapfeltevésből kiindulva). Mindazonáltal nem helyettesíti azt.

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 Költség alatt idő-költséget értünk (általában a teljes teszt-bad lefuttatása napokat v. heteket vehet igénybe…addig áll a fejlesztés). A teszteseteken alapuló minőségbiztosítás csak azokra a kódrészekre mond valamit, amelyeken a teszt-esetek átmennek). Ez általában a rendszer teljes méretének 1 töredéke. Volt olyan, hogy 30%. Könnyen megeshet, hogy a teszt-bad fejlősével a rendszer minősége csökkenő tendenciát mutat (növekszik a lefedettség), ugyanakkor a termék minősége javul.

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

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 A szakértői tudás nagy mértékben tapasztalaton illetve, a pontos definiciok, jelentések ismeretén alapul Baseline érték minden metrikára 1 átlagos érték, amihez viszonyitott eltéréseket érdemes vizsgálni. Ilyen baseline értékek megszerzése nehéz. Sok tapasztalat, sok rendszer vizsgálata szükséges. Sok esetben valószínűleg domain-specifikus is.

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

Baseline értékek folyt.

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

Bonus-Malus modell Baseline index: -5,4 Baseline index: -6,02

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

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

Statisztikai modellek folyt.

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)

Statisztikai modellek folyt. Q-Q Plot μ = 0.7 σ = 1.2

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

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) ------------------- A LOC is lehet nyelvfuggo Inkabb ugy mondjuk, hogy programozasi paradigma fuggetlen es fuggo

Méret metrikák Méret metrikák – a rendszer (elemek) mérete "Measuring programming progress by lines of code is like measuring aircraft building progress by weight." ~ Bill Gates. 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) ---- Komment helyett legyen megjegyzes

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 10.000 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 LOC/lLOC- becsülhető vele ugyan a Maintainability, de lehetnek problémák… Általában ha lLOC<LOC, akkor a különbséget kommentek adják Kommenteken kívül lehetnek még üres sorok (fejlesztőtől függ) Makró-használat is gondot okozhat: int f() { #ifdef A … #endif }

Méret metrikák (folyt.) Statisztikai értékek: Mozilla LOC lLOC Function Method Classes Medián 13.4 6.0 36.5 5.5 27.1 Átlag 28.7 16.6 179.4 21.9 12.9 128.3 A LOC metrikákat megmérni elég könnyű, de sokszor szükség van implementáció előtt becslést adni a LOC értékre. Ezt alapvetően 2 megközelítéssel végzik: Funkció pontokból számolják Component-sizing Mindkét esetben szükség van egy gépi tanulási modellre, ami a múltbeli értékek alapján modellt épít fel. Teljesítmény mérésénél Wolverton az „utasításkód”/emberhó, és még baseline értékeket is meghatározott Egyszerű megbízhatósági modelleket építeni a LOC metrika segítségével

Ö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

Öröklődés alapú metrikák (folyt.) ősosztályok száma összes osztály száma 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 leszármazott osztályok száma ősosztályok száma

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

Ö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 Szkenárió: TOPX kiválasztása, majd megnézni a 10-es metrikájú osztály forráskódját. Látszik a forrás kód alapján, hogy ez semmi pluszt nem ad a ősosztályhoz, és 4 verzió óta nem változott a LOC.

Korreláció Metrika Mozilla 1.6 DIT 1,52 NOP 0,87 NOA 1,93 NOC 0,88 NOD 1,95 A metrikák és a hibaszámok közti korrelációs kapcsolat a Mozilla esetében Bnum DIT NOP NOA NOC NOD 1,000 0,016 0,154 0,067 0,000 0,233 0,783 0,448 0,988

Komplexitás-metrikák "The central enemy of reliability is complexity" Geer et al. 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

Komplexitás-metrikák (folyt.)

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.)

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) http://doi.ieeecomputersociety.org/10.1109/WPC.2002.1021308

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 Az LCOM2, LCOM3 metrikákat az LCOM1 hiányosságainak kiküszöbölése miatt találták ki.

Kohéziós metrikák (folyt.) – LCOM5

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)

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%) Kohézió hiányáról beszélünk, hogy konzisztensek legyünk azzal az elvvel, miszerint magas metrikus érték rosszat jelent. A bean-típusú osztályok csak adattagokat, és get/set metódusokat tartalmaznak…az egyetlen funkcionalitása az adattárolás. Ezt az egyet valósítja csak meg, ennek ellenére az LCOM1 értéke magas lesz.

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 Az újrafelhasználhatóság csökken, ha a súlyozatlan WMC növekszik, a súlyozott pedig csökken. CBO RFC WMC 1,000 0,696 0,561 0,709

Bad Smell “If it stinks, change it." ~ Grandma Beck. 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]

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ő Az egyes bad-smellek jelentése: 1. Az osztály túl sok adattagot tartalmaz (nehéz a karbantartása, javítása, fejlesztése) 2. Egy függvény minden funkcionalitása abban nyilvánul meg, hogy més osztályok függvényeit hivogatja. Saját osztályát érintő logikát nem implementál 3. Az objektum statikus példánya túl sok fizikai memóriát foglal (beágyazott rendszerek esetén lehet kritikus jelentése ennek a bad-smellnek) 4. A függvény törzse túl nagy (csökken a karbantarthatóság)…forrás metrikák: LOC, McCabe, stb… 5. A->B()->C()->D()… lusta programozóra, vagy rossz tervezésre utal. 6. A leszármazott osztály nem használja az ősosztály dolgait…újra kell gondolni a származtatás jogosságát 7. Az osztály adattagját kevés metódusa használja az osztálynak…valószínű, hogy nem tartalmaz az osztály funkcionalitásával kapcsolatos dolgokat (csak értékek ideglenes tárolására szolgál)…ez helyett, lehet, hogy paraméterként kellene átadni ezeket az értékeket a függvények között. -> LPL

Bad Smell (folyt.) - Mozilla Monitor scenario: bad-smellek valtozasa: Kiviat diagram

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)

Klón metrikák (folyt.)

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

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

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

Aggregált metr. (folyt.)

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 Cél, hogy valamilyen becslést tudjunk adni a jövőre vonatkozóan. A belső metrikák egyszerűen mérhetők. Az aggregált metrikák viszont nem. Viszont ezek sokkal jelentősebb információkat hordoznak. Az alapfeltevés az, hogy az aggregált metrikák összefüggésbe hozhatók az egyszerű belső metrikákkal. Ez empirikusan is könnyen igazolható, pl. nagy a ciklomatikus komplexitása egy függvénynek, akkor az nehezen karbantartható, javítható, fejleszthető, stb. A modellek célja ezen összefüggések leírása. Ha van egy működő modell, akkor ennek segítségével tudunk becsléseket adni a jövőre vonatkozóan. Akár egy függőségi gráf is építhető, hogy mely metrikák melyektől függnek. A modellek metrikus értékeken kívül figyelembe vehetnek más tényezőket is: változás az idő függvényében, szervezet specifikus dolgok, stb. Általában egy modell elkészítéséhez szükség van a múltbeli adatokra (ha a modell szakértői tudást tartalmaz, akkor a szakember tapasztalatára). A múltbeli értékek változása alapján pl. gépi tanulási és statisztikai módszerek segítségével építhetők fel a modellek.

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

Eredmények (folyt.) Logisztikus regresszió CBO: Metrika Pontosság (Precision) Helyesség (Correctness) Teljesség (Completeness) WMC 65.38% 68.84% 55.24% RFC 66.01% 71.89% 53.60% CBO 69.77% 70.38% 69.12% LCOM 64.69% 81.34% 43.68% LOC 66.85% 72.98% 54.58% Multi 69.61% 72.57% 65.24% Modell Precision (pontosság) Correctness (helyesség) Completeness (teljesség) Log. reg. 69.77% 70.38% 69.12% Dönt. fa 69.13% 67.02% Neuronh. 69.46% 70.63% 65.13%

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 1992. [2] Wolverton, R.W.: The Cost of Developing Large-Scale Software. IEEE Transactions on Computer, Volume C-23, No. 6, pp. 615-636, June 1974. Also in: Tutorial on Programming Productivity: Issues for the Eighties, IEEE Computer Society, Second Edition, 1986. [3] L. M. Zap and B. Handerson-Sellers. Consistency consideration of object-oriented class libraries. Technical report, University of New South Wales, Sydney, Australia, 1993. research report no 93/3 [4] Rubey, R.J.; Hartwick, R.D.: Quantitative Measurement Program Quality. ACM, National Computer Conference pp. 671-677, 1968

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. 308-320, 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.

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 2005. [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): 897-910 (2005) [11] Hakim Lounis, Lynda Ait-Mehedine: Machine-Learning Techniques for Software Product Quality Assessment. 102-109 [12] Martin Fowler and Kent Beck. Refactoring: Improving the Design of Existing Code. Addison-Wesley, 2000.

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