Nejc Muršič INOVATIVNE METRIKE PROGRAMSKE OPREME Magistrsko delo Maribor, julij 2016

Transkripcija

1 INOVATIVNE METRIKE PROGRAMSKE OPREME Magistrsko delo Maribor, julij 2016

2 INOVATIVNE METRIKE PROGRAMSKE OPREME Magistrsko delo Študent: Študijski program: Študijski program 2. stopnje Računalništvo in informatika Smer: Mentor: Računalništvo in informacijske tehnologije red. prof. dr. Peter Kokol Somentor: Lektor Žiga Oset, mag.

3 i

4 ZAHVALA Zahvaljujem se mentorju red. prof. dr. Petru Kokolu za vodenje, pomoč in potrpežljivost pri izdelavi magistrskega dela. Posebna zahvala gre staršem za podporo skozi vsa leta študija. i

5 INOVATIVNE METRIKE PROGRAMSKE OPREME Ključne besede: metrike programske opreme, kakovost programske opreme, testiranje, inovativne metrike UDK: (043.2) Povzetek V magistrskem delu predstavljamo različne vrste in razvoj metrik programske opreme skozi zgodovino. Pri tem se osredotočamo predvsem na nekatere bolj inovativne pristope k merjenju različnih lastnosti programske opreme in opišemo njihovo delovanje. V drugem delu magistrskega dela testiramo nekatere standardne metrike in izdelujemo lastno implementacijo parametrične metrike programske opreme, s pomočjo katere izvedemo statično analizo na 35. različnih projektih. Dobljene rezultate nato primerjamo med seboj in predstavimo ugotovitve. S pomočjo korelacije preverimo tudi moč linearne povezanosti med metrikami. ii

6 INOVATIVE SOFTWARE METRICS Key words: software metrics, software quality, testing, innovative software metrics UDK: (043.2) Abstract In the master s thesis we present different types and the development of software metrics through history. In the process, we focus mostly on some of more innovative approaches to measuring different types of software and we describe their operations. In the second part of the master s thesis we test some standard metrics and we produce our own implementation of parametric software metrics by means of which we produce static analysis in 35 different projects. The acquired results are then compared and the ascertainments are presented. By means of correlations we also check the power of linear linkage between the metrics. iii

7 KAZALO VSEBINE 1 Uvod Metrike programske opreme Zgodovina in razvoj metrik Parametrična metrika programske opreme Demonstracija parametrične metrike na primeru Lastnosti parametrične metrike Weighted Micro Function Points Lastnosti WMFP BBN Praktična analiza Uporabljene tehnologije Omejitve in predpostavke Implementacija aplikacije Rezultati Sklep in nadaljnje delo Zaključek Literatura i

8 KAZALO SLIK Slika 2.1: Primer Control flow grafa enostavnega programa [11]... 8 Slika 3.1: Arhitektura parametrične metrike (Vir: [45]) Slika 3.2: Del kode mehurčnega urejanja Slika 3.3: Defects BBN (posplošeno) [35] Slika 4.1: Microsoft Visual Studio 2015 IDE (vir: [21]) Slika 4.2: Prikaz različne kvalitete programske kode v VS Slika 4.3: Primer vgrajenih metrik programa VS Slika 4.4: GUI lastne aplikacije Slika 4.5: Struktura aplikacije Slika 4.6: Struktura razreda CSharp v mapi LanguageDefinitions Slika 4.7: Filtriranje datotek projekta Slika 4.8: Primer izvoza podatkov v Excel formatu Slika 4.9: Algoritem računanje metrik velikosti Slika 4.10: Algoritem računanja parametrične metrike Slika 4.11: Primer prikaza rezultatov metrik za posamezni projekt Slika 5.1: Korelacija med PSM 3 in ostalimi metrikami ii

9 KAZALO TABEL Tabela 2.1: Tabela nekaj testnih metrik (Vir: [33])... 9 Tabela 2.2: Objektno orientirane metrike [19] [34] Tabela 3.1: Različni tipi metrike LOC (Vir: [29]) Tabela 3.2. Vrednosti segmentiranih atributov za mehurčno urejanje (Vir: [29]) Tabela 3.3: Število napak ter meja izdaje in stabilnosti Tabela 3.4: Rezultati eksperimenta cilja Tabela 3.5: Rezultati eksperimenta cilja Tabela 5.1: Rezultati analize programske opreme z razvojnim okoljem VS Tabela 5.2: Primer metod s slabšo kvaliteto programske kode Tabela 5.3: Rezultati analize programske opreme z implementacijo parametrične metrike 48 Tabela 6.1: Rezultati parametrične metrike iii

10 UPORABLJENE KRATICE C# objektno usmerjen programski jezik GUI (ang. Graphical user interface) grafični uporabniški vmesnik SDLC (ang. Software Development Life Cycle) življenjski krog programske opreme OO objektno orientirani NN (ang. Neural network) nevronska mreža IDE (ang. Integrated development environment) integrirano razvojno okolje VS Visual Studio, razvojno okolje podjetja Microsoft IEEE (ang. Institute of Electrical and Electronics Engineers) je strokovno društvo, katere cilj je izobraževalni in tehnični napredek. PSM (ang. Parametric Software Metric) parametrična metrika programske opreme LINQ (ang. Language Integrated Query) integrirana komponenta za podatkovne poizvedbe CSV (ang. Comma Separated Values) datotečni format, kjer so podatki ločeni z vejico ISO (ang. International Organization for Standardization) mednarodna organizacija za standardizacijo CLOC (ang. Comment Lines Of Code) število vrstic kode s komentarji NCLOC (ang. No Comment Lines Of Code) število vrstic kode brez komentarjev DLOC (ang. Declaration Lines Of Code) število vrstic kode, ki vsebujejo deklaracijo podatkov (spremenljivk, konstant ) BLOC (ang. Blank Lines Of Code) število praznih vrstic kode LSLOC število vrstic kode, ki vsebujejo več ločenih ukazov iv

11 1 Uvod Meritve uporabljamo in so nam v pomoč v vsakodnevnem življenju na različnih področjih. Vede, kot so znanost in inženirstvo, so močno odvisne od njih. Podjetjem pomagajo pri načrtovanju, spremljanju in nadzorovanju razvoja izdelka, kot tudi dajejo povratno informacijo o napredku k zadanim ciljem. S tem posledično vplivajo na kvaliteto, ki je zelo pomembna pri prodaji izdelka. Prav te meritve specifičnih atributov projekta so uporabljene za izračun metrik programske opreme in zagotavljajo nekakšno nadzorno ploščo za upravljanje projekta, procesa in izdelka. Vedno več kupcev ob nakupu izdelka podaja ali določa kakovostne metrike in ostale zahteve kakovosti kot del njihove pogodbe. Industrijski standardi in modeli, kot so ISO 9000, Software Engineering Institute's (SEI), Capability Maturity Model Integrated (CMMI ) te meritve že vključujejo. Cilj metrik je pridobiti merljive in objektivne rezultate, ki so koristni med samim razvojem, kot tudi pri prodaji izdelka. Zagotavljajo kvantitativno podlago za razvoj programske opreme. Uporabljajo se za iskanje in napovedovanje napak v kodi, napovedovanje uspešnosti in tveganja projekta. Izračunamo lahko tudi kompleksnost in prepoznamo težavnost vzdrževanja kode [6]. Ena izmed težav metrik je njihova splošna sprejetost in uveljavljenost. Prav tako ni jasno izoblikovanih načinov, kako vrednotiti metrike. Kljub temu številne organizacije in podjetja, dosegajo obetavne rezultate z njihovo uporabo. Metrike programske opreme so tudi deležne konstantnih nadgradenj in posodobitev. Še vedno se predlagajo tudi nove metrike [7]. V prvem delu magistrskega dela na kratko predstavimo tematiko, s katero se ukvarjamo. V drugem delu opišemo metrike programske opreme, ki pomagajo pri samem razvoju izdelka kot tudi pri prodaji in njihov razvoj ter napredek skozi čas. Cilj magistrske naloge se je bolje spoznati z nekaterimi bolj inovativnimi metrikami programske opreme, raziskati in 1

12 preizkusiti njihovo delovanje. Na koncu analizirati in primerjati rezultate, predstaviti prednosti in slabosti enih in drugih in tudi predlagati morebitne izboljšave. Pred samim razvojem in testiranjem smo si pogledali programski jezik C# in razvojno okolje Microsoft Visual Studio, v katerem implementiramo in preizkušamo metrike. Predstavimo tudi uporabniški vmesnik, ki smo ga razvili za lažjo navigacijo po programu in glavne komponente, ki sestavljajo našo aplikacijo. Pregledali in podučili smo se tudi o že obstoječih rešitvah in knjižnicah, s katerimi smo si pomagali pri samem razvoju. Magistrsko delo bomo sklenili s kratkim sklepom in seznamom literature. 2

13 2 Metrike programske opreme Metrike so razdeljene v dve večji skupini: projektne (project based metrics) in načrtne (design based metrics). Projektne se nadalje delijo na procesne, produktne in projektne. Načrtne pa delimo na tradicionalne in objektno orientirane metrike (Graf 2.1). Produktne metrike opisujejo statične lastnosti izvorne kode in se ukvarjajo s kvaliteto programske opreme in samega produkta. Procesne merijo proces razvoja programske opreme, kot je na primer čas razvoja, izkušnje razvijalcev ali tip uporabljene metodologije za razvoj programske opreme. Lahko se uporabljajo za izboljšanje učinkovitosti procesa SDLC (Software Development Life Cycle). Projektne metrike se uporabljajo za merjenje učinkovitosti projektne skupine ali katerega koli uporabljenega orodja. Ponekod lahko zasledimo, da se projektne metrike imenujejo metrike virov, ki merijo potrebne vire za aktivnosti procesa izdelave programske opreme. Sem spadajo osebje, material, orodja, ipd. [12] Metrike lahko delimo tudi na direktne in indirektne glede na tip merjenja. Direktne merijo neodvisne lastnosti programske opreme, kot so: velikost, število vrstic kode, hitrost in čas izvajanja, velikost pomnilnika, število napak, ipd. Indirektne merijo lastnosti, ki jih je potrebno razstaviti oziroma razbiti na različne aspekte in so odvisne od drugih meritev (kvaliteta je odvisna od števila napak). Sem spadajo kvaliteta, funkcionalnost, zanesljivost, učinkovitost, vzdrževanje, ipd. Obstajajo tudi druge delitve metrik, kot so: primitivne (primitive) in izračunane (computed), objektivne in subjektivne ali statične in dinamične. 3

14 METRIKE Projektne Načrtne Procesne Produktne Tradicionalne Objektno orientirane Projektne / Metrike virov SLOC CP CK MOOD Metrike kompleksnosti Itd... Itd... Graf 2.1: Delitev metrik (Vir: 57, [23]) Merjenje omogoča izboljšanje procesa izdelave programske opreme, pomaga pri načrtovanju, sledenju in daje oceno kvalitete, zanesljivosti, varnosti, uporabnosti, ipd. Pred samim začetkom merjenja pa je potrebno določiti, katere lastnosti bomo merili in kakšni so cilji meritev. Različna podjetja in organizacije so razvile različne metodologije in principe dobrega načrtovanja. Izraz TQM (Total Quality Management) je leta 1985 skoval Naval Air Systems Command in predstavlja opis pristopa k izboljšanju kakovosti. Preprosto rečeno, je pristop upravljanja za dolgoročni uspeh, ki je dosežen s poudarkom na zadovoljstvu strank. Implementacija TQM modela ima veliko variacij in različnih pristopov, vendar pa ima nekaj ključnih značilnosti: [2] [27] osredotočenost na kupce/stranke, kjer je cilj doseči popolno zadovoljstvo stranke. To vključuje preučevanje potreb in želj strank, zbiranje zahtev in merjenje zadovoljstva strank. Nenehno izboljševanje, kjer je cilj zmanjšati razlike v procesu in doseg nenehnega izboljševanja poslovnih in razvojnih procesov. Odločanje, ki temelji na dejstvih (merjenje in analiza). Da bi vedeli, kako dobro organizacija funkcionira, TQM zahteva, da se nenehno zbirajo in analizirajo podatki 4

15 z namenom izboljšanja odločanja in omogočanja napovedovanja na podlagi preteklih izkušenj. Udeležba vseh zaposlenih, kjer vsi delujejo v smeri skupnih ciljev. Največjo produktivnost dosežemo, ko omogočimo ustrezno in varno delovno okolje. Visoko zmogljivi delovni sistemi vključujejo stalna prizadevanja za izboljšanje delovnih procesov. Izboljševanje kvalitete, kjer je cilj nenehno izboljševanje kvalitete produktov. Nadgradnjo TQM predstavlja GQM (Goal Question Metric), ki jo je razvil Victor Basili kot prvi pristop k metrikam programske opreme. Ta pristop je bil prvotno opredeljen in namenjen za ocenjevanje napak različnih projektov v računalniškem centru pri organizaciji NASA. Zagotavlja tako imenovan ciljno usmerjen»framework«oziroma meritveni model, ki vključuje tri korake (ravni) [26]: 1. konceptualna raven (cilj). Predstavlja seznam glavnih ciljev razvoja in vzdrževanja projekta. 2. Operativna raven (vprašanje). Vprašanja, ki izhajajo iz vsakega cilja, na katera je treba odgovoriti, da ugotovimo, če je cilj izpolnjen. 3. Kvantitativna raven (metrika). Kakšne meritve bomo opravljali, da bomo lahko zadovoljili in odgovorili na zastavljena vprašanja. GQM proces je običajno opisan v šestih korakih, kjer so prvi trije koraki o uporabi poslovnih ciljev za identifikacijo pravih meritev in zadnji trije koraki o zbiranju podatkov meritev in učinkoviti uporabi le-teh za pomoč pri odločanju in izboljševanju procesov. Basili je teh šest korakov procesa GQM opisal kot [26]: zastaviti projektne cilje in tudi meritvene cilje za izboljšanje kvalitete in produktivnosti. Razviti vprašanja, ki opredeljujejo prej zastavljene cilje na čim bolj merljiv oziroma kvantitativen način. Določiti specifikacije merite, ki so potrebne, da odgovorimo na vprašanja in proces sledenja in skladnosti izdelka s cilji. Razviti mehanizme za zbiranje podatkov. 5

16 Zbrati, ovrednotiti in analizirati podatke v realnem času za zagotavljanje povratnih informacij in morebitnih korekcij in popravkov. Analizirati podatke po končanem procesu in predlagati izboljšave za prihodnost Rezultat GQM pristopa so specifikacije sistema za merjenje, ki cilja na točno določen sklop vprašanj in nabor pravil za interpretacija podatkov merjenja. [23] [26] Kasneje so sledile še nekatere druge metodologije in pristopi za izboljšanje procesov organizacij, kjer so eni izmed bolj znanih IEEE standardi in Six Sigma. Six Sigma je strategija za pospešitev izboljšav v procesu izdelave in same kvalitete produktov. Gre za celovito strategijo podjetja, usmerjeno h kupcem in podkrepljeno s podatki in statičnimi metodami. 2.1 Zgodovina in razvoj metrik Zgodovina metrik programske opreme sega skoraj tako daleč kot sam razvoj programske opreme. Začetki uporabe metrik segajo nazaj v pozna 60. leta prejšnjega stoletja, kjer se kot prve pojavijo metrike velikosti. Metrike velikosti opisujejo velikost programske opreme s štetjem različnih vrst vrstic kode, kot so [7]: vse vrstice (CountLine); vrstice izvorne kode (CountLineCode); prazne vrstice (CountLineBlank); vrstice s komentarji (CountLineComment); vrstice s podpičji (CountSemicolon), itd. Iz njih so izpeljane še nekatere druge metrike, ki predstavljajo povprečje več združenih metod, kot so: AvgLine, AvgLineBlank, AvgLineCode Najbolj pogosto uporabljena metrika je Lines of code (LOC). Uporaba teh metrik je bila možna samo ob koncu razvoja produkta. Največja pomanjkljivost teh metrik je bila seveda, da so bile lastnosti, kot so funkcionalnost, kompleksnost, ponovna uporaba, redundanca in vložen napor, prezrte. Potreba po bolj naprednih, zanesljivih metrikah in neodvisnih od programskega jezika je rasla skupaj z razvojem programske opreme in programskih jezikov. V letu 1971 Akiyama objavi prvi poskus merjenja kvalitete programske opreme z uporabo regresijskega modela števila napak na 1000 vrstic izvorne kode (number of defects per KLOC). Temu sledijo 6

17 Halstead-ove in McCabe-ove metrike kompleksnosti [8]. Cilj Halstead-ove metrike je poiskati merljive atribute programske opreme in povezave oziroma relacije med njimi. Najpogosteje uporabljena je ciklomatična metrika kompleksnosti, ki jo je leta 1976 predlagal McCabe. Ta metrika temelji na kvantitativnem merilu števila linearno neodvisnih poti skozi izvorno kodo programa. Metrika se uporablja predvsem za testiranje programske opreme z izračunom števila testnih primerov, potrebnih za temeljito testiranje določenega modula in za zaznavanje težav v izvorni kodi. Nizka ciklomatična kompleksnost lahko pomeni, da koda programa ni kompleksna z vidika metrike ali pa kaže na to, da nekatere metode s klici drugih metod in funkcij prelagajo kompleksnost na njih. To se bo kazalo v visoki ciklomatični kompleksnosti nekaterih posameznih metod ali funkcij. Ciklomatična kompleksnost je izračunana z uporabo grafa za nadzor pretoka (control flow graph) [Slika 2.1]. Lahko jo izračunamo tudi za posamezne funkcije, module ali razrede znotraj programa. Vozlišča grafa predstavljajo posamezni ukazi programa, povezave med vozlišči in zaporedna izvajanja ukazov. Dve vozlišči sta povezani, če se ukaza izvajata eden za drugim. Ciklomatično kompleksnost»c«grafa na sliki 1 se izračuna s pomočjo spodnje enačbe: [11] C = E N + 2P Tu je: E - število robov; N - število vozlišč; P število vozlišč, ki imajo izhodno točko. V primeru, če ima program več izhodnih točk ali je izhod povezan nazaj z vhodom, uporabimo enačbo: [11] C = E N + P 7

18 Slika 2.1: Primer Control flow grafa enostavnega programa [11] Leta 1979 Allan J. Albrecht, zaposlen pri podjetju IBM, predstavi analizo funkcijskih točk (function point analysis - FPA). To je bil poskus premagati težave, povezane z metrikami velikosti, kjer so vrstice kode merilo programske opreme in za pomoč pri razvoju mehanizma za napovedovanje napora oziroma truda, povezanega z razvojem programske opreme. FPA je neodvisna od programskega jezika in uporabljenih tehnologij, saj meri sistem iz funkcijskega vidika in število funkcijskih točk sistema ostaja konstantno. Najprej funkcionalne zahteve programske opreme razdelimo v pet skupin: izhodi, vhodi, poizvedbe, notranje datoteke in zunanji vmesniki. Nato se vsaki posamezni razvrščeni funkcionalnosti dodeli določeno število funkcionalnih točk glede na njeno kompleksnost. Edina spremenljivka je vložen napor, potreben za razvoj teh funkcijskih točk, kar pomeni da je analiza odlična pri ugotavljanju razlik v produktivnosti razvojnega okolja, programa ali jezika v podjetju ali organizaciji [15]. Na področju merjenja kakovosti procesa razvoja programske opreme so se razvile različne metrike in tudi modeli. Metrika DDM (Defect Density Metric) se lahko uporablja v različnih fazah razvoja programske opreme. Velika vrednost metrike DDM v fazi testiranja je indikator, da ima programska oprema veliko napak in hroščev, kar pomeni da bo potrebno vložit i veliko truda in časa za odpravo teh napak. Stopnja odkrivanja napak (Error discovery rate), ki predstavlja razmerje med vsemi najdenimi napakami in številom izvedenih testov. 8

19 Sprejemanje napak (Defect acceptance) je razmerje med številom veljavnih napak in številom vseh napak. Gostota napak pri testnih primerih (Test case defect density) je razmerje med številom neuspešnih testov oziroma preizkusov in številom vseh testov. Učinkovitost odstranjevanja napak (DRE Defect removal effectiveness) je razmerje med številom odstranjenih napak v določeni fazi razvoja in med številom napak, ki so bila najdene kasneje. Leta 1981 je Barry W. Boehm predstavil algoritmični model za oceno stroška programske opreme imenovan Constructive Cost Model (COCOMO). Osnovna različica COCOMO modela računa stroške in napor kot funkcijo velikosti programske opreme, ki jo izrazimo z oceno števila vrstic kode (LOC). Vmesna različica COCOMO modela računa napor razvoja programske opreme kot odvisnost velikosti programa in niza tako imenovanih»coat drives«, ki vključujejo subjektivno oceno potrebne strojne opreme, osebja in drugih atributov za razvoj programske opreme. Tretja različica je napredni model, ki vključuje vse značilnosti druge različice z oceno stroškov na vsakem koraku procesa razvoja programske opreme. Ene izmed bolj pomembnih metrik za merjenje in zagotavljanje kakovosti (QA quality assurance) programske opreme so testne metrike in metrike zanesljivosti. Testne metrike so pomembne za sprejemanje odločitev naslednje faze razvoja, kot so ocena stroškov in razpored prihodnjih projektov. Pomagajo tudi razumeti, kakšne izboljšave so potrebne za uspeh projekta. V spodnji Tabela 2.1 lahko vidimo nekatere metrike, ki jih lahko uporabljamo v času testiranja programske opreme. Tabela 2.1: Tabela nekaj testnih metrik (Vir: [33]) Metrika Definicaja / namen Formula Test case Productivity (TCP) Defect Acceptance (DA) Defect Rejection (DR) Uporablja se za ugotavljanje produktivnosti testnih primerov Ugotavlja število veljavnih napak najdenih v času testiranja Ugotavlja število zavrnjenih napak v času izvajanja Število pripravljenih testov / porabljen napor za teste Število veljavnih napak(defektov) / število vseh napak * 100% Število zavrnjenih napak / število vseh napak * 100% 9

20 Bad Fix Defect (B) Test case defect density Test Efficiency (TE) Test Effectiveness Test improvement (TI) Test time over development time (TD) Cost per defect unit Uporablja se za ugotavljanja učinkovitosti procesa popravljanja napak Uporablja se za ugotavljanja učinkovitosti testnih primerov Ugotavlja učinkovitost testne skupine pri ugotavljanju in iskanju napak Prikazuje razmerje med številom napak najdenih v fazi testiranja in vsemi napakami programske opreme Prikazuje razmerje med številom najdenih napak in velikostjo programske opreme Prikazuje razmerje med časom porabljenim za testiranje in časom porabljenim za razvoj. Prikazuje razmerje med porabljenim denarjem za testiranje in najdenih napakah Število napačno popravljenih napak / število vseh napak * 100% Število spodletelih testnih primerov / Število izvedenih testnih primerov * 100 (DT/(DT+DU)*100 (DT/(DF+DU)*100 Število najdenih napak / število vrstic izvorne kode Število delovnih dni, namenjenih za testiranje / število delovnih dni namenjenih za razvoj Porabljen denar za testiranje / število najdenih napak po izdaji produkta Metrike zanesljivosti (reliability metrics) nam dajejo informacijo o zanesljivosti produkta in omogočajo kupcem informacijo o vrednosti izdelka pred samim nakupom. Zanesljivost sistema se meri s štetjem števila napak v času izvajanja in primerjava teh s sistemskimi zahtevami v času okvare. Kritična programska oprema in sistemi, kot so letalski, vesoljski, sistemi v jedrskih elektrarnah, srčni spodbujevalniki, železniški, ipd. morajo biti izredno zanesljivi, saj lahko imajo njihove napake katastrofalne posledice. V to skupino spadajo metrike, kot so: [36] [37] [38] Probability of Failure on Demand (POFOD) je verjetnost, da bo sistem naletel na napako ob zahtevani operaciji oziroma storitvi. Računa se kot razmerje med število m zahtev in številom napak v odvisnosti od časa. Rate of Fault Occurrence (ROCOF) odraža stopnjo okvar v sistemu. Metrika je koristna pri sistemih, ki morajo pogosto obdelati veliko število podobnih zahtev. 10

21 Mean Time To Failure (MTTF) meri čas do sistemske napake. Vrednost MTTF za stabilne sisteme je enaka: MTTF = 1/ROCOF. Metrika je uporabna za sisteme, katerih operacije potrebujejo veliko časa, da se izvedejo. Mean Time To Repair (MTTR) meri čas potreben za popravilo napake. Mean Time Between Failure (MTBF) je podobna metriki MTTF in meri čas med opazovanimi sistemskimi napakami oziroma številom napak v določenem časovnem obdobju. Availability (AVAIL) meri čas, ko je sistem na voljo za uporabo. Pri merjenju upošteva popravljalni in čas ponovnega zagona sistema. Metrika je uporabna za sisteme, ki delujejo neprenehoma. V 90-ih so se začeli pojavljati objektno orientirani (OO) programski jeziki. Objektno orientirana analiza in načrtovanje programske opreme zagotavlja številne prednosti, kot so ponovna uporaba in dekompozicija ali razgradnja problema na manjše lažje razumljive objekte. Nekatere dosedanje tradicionalne metrike so bile koristne pri OO paradigmah, vendar pa so neuspešne pri merjenju značilnostih OO programiranja, kot so enkapsulacija, polimorfizem, dedovanje, abstrakcija objektov, lokalizacija, Definiramo lahko devet različnih razredov in njihovih aspektov, ki jih bodo OO metrike merile [18]: 1. Velikost (Size): a. populacija razredov, operacij, ipd., b. volumen (število dinamičnih objektov), c. dolžina (npr.: globina dedovanja), d. funkcionalnosti (uporabniških funkcij). 2. Kompleksnost (Complexity). Predstavlja, kako so razredi med seboj povezani. 3. Sklopljenost (Coupling). Število povezav med razredi. 4. Samozadostnost (Sufficiency). Ali razred odraža potrebne lastnosti področja problema. 5. Popolnost (Completeness). Ali razred odraža vse lastnosti področja problema. 6. Kohezija (Cohesion). Ali imajo atributi in operacije v razredu enoten, dobro opredeljen cilj. 11

22 7. Primitivnost / enostavnost (Primitiveness / Simplicity). Stopnja, do katere operacije razreda ne moremo sestaviti iz drugih operacij. 8. Podobnost (Similarity). Primerjava strukture, delovanja, obnašanja dveh ali več razredov. 9. Volatilnost (Volatility). Verjetnost, da bo prišlo do sprememb pri oblikovanju ali implementaciji razreda. Zaradi teh pomanjkljivosti sta leta 1994 prvih šest metrik predstavila Chidamber in Kemerer (C&K). Weighted Methods per Class (WMC) je enaka vsoti kompleksnosti vseh metod razreda. To je indikator, koliko truda in časa je potrebnega za vzdrževanje posameznega razreda. [18] Depth of Inheritance Tree (DIT) računa, kako globoko je razred deklariran v hierarhiji dedovanja, kjer je DIT največja razdalja od korena drevesa dedovanja. [18] Vrednost metrike Number of children (NOC) je enaka številu takojšnjih podrazredov razreda. Predstavlja meritev, koliko podrazredov bo dedovalo metode nadrazreda. [18] Coupling between object classes (CBO) za razred predstavlja število povezav z drugimi razredi. Razreda sta v povezavi takrat, kadar se vsaj eden od njiju nanaša na drugega, kar pomeni, da uporablja njegove metode ali atribute. [18] Response for a Class (RFC) računa število vseh metod in konstruktorjev, ki jih je mogoče izvesti znotraj določenega razreda. [18] Lack of Cohesion in Methods (LCOM) šteje pare metod, katerih podobnost je enaka 0, minus število parov metod, katerih podobnost je različna od 0. [18] Istega leta sta Fernando Brito in Rogerio Carpuca predstavila sklop MOOD (Metrics for Object Oriented Design) metrik. Te se nanašajo na posamezne značilnosti oziroma paradigme OO programiranja. Method Hiding Factor (MHF) je merilo funkcionalnosti in je opredeljena kot razmerje med vsoto vseh nevidnih metod v vseh razredih in med številom vseh deklariranih metod. 12

23 Nevidne metode predstavljajo odstotek vseh razredov, katerim je določena metoda skrita. [18] [22] Attribute Hiding Factor (AHF) je definirana podobno kot MHF, kjer vsoto predstavljajo atributi razreda. Idealno bi morali biti vsi atributi razreda skriti drugim razredom, kar bi pomenilo, da bi bila vrednost AHF 100 %. [18] [22] MHF = 1 - vidne metode Vidne metode = SUM(MV) / (C-1) / število metod MV = število drugih razredov, kjer je določena metoda vidna (dostopna) AHF = 1 - vidni atributi Vidni atributi = SUM(AV) / (C-1) / število atributov AV = število drugih razredov, kjer je določen atribut viden (dostopen) C = število razredov Vrednost metrike Method Inheritance Factor (MIF) je razmerje med vsoto podedovanih metod v vseh razredih in med vsemi metodami (lokalnimi in podedovanimi) vseh razredov. [18] [22]. Attribute Inheritance Factor (AIF) je opredeljena kot razmerje med vsoto podedovanih atributov v vseh razredih in številom vseh razpoložljivih atributov (lokalnih in podedovanih) za vse razrede. [18] [22] Polymorphism Factor (PF) meri stopnjo ponovno implementiranih metod znotraj drevesa dedovanja. Vrednost PF je enaka razmerju med ponovno implementiranimi metodami in med vsemi metodami, ki jih je mogoče ponovno implementirati. [18] [22] Podobno kot PF je definiran Coupling Factor (CF), ki pa predstavlja razmerje med dejanskimi in vsemi možnimi sklopi. 13

24 Uporaba običajnih statičnih metrik na sodobni OO programski opremi ni dovolj dobra in zanesljiva zaradi prisotnosti polimorfizma v času izvajanja, razrednih predlog, dinamične vezave, neizvedene kode zaradi določenih pogojev, ipd. Zaradi tega se je začel uporabljati drugačen pristop in drugačne metrike. Dinamične metrike so bolj natančne pri merjenju obnašanja med samim izvajanjem programske opreme. Nove OO metrike se še vedno razvijajo in skozi dopolnjujejo. V spodnji tabeli so naštete zgoraj predstavljene in še nekatere druge OO metrike in v kateri tip OO metrik spadajo. Kadar sta navedena dva tipa za eno metriko, je potrebno vedeti, da se meritve dinamičnih metrik opravljajo med samim izvajanjem programa. Tabela 2.2: Objektno orientirane metrike [19] [34] Tip Metrika OO atribut Razvijalec oz. avtor in leto Statična Response for a Class (RFC) Razred Chidamber, 1994 Statična Dinamična Statična, dinamična Statična Statična Statična Number of Attributes per Class (NOA) Number of Methods per Class (NOM) Weighted Methods per Class (WMC) Coupling between Objects (CBO) Data Abstraction Coupling (DAC) Message Passing Coupling (MPC) Razred Henderson, 1996 Razred Henderson, 1996 Razred Chidamber, 1994 Sklopljenost Chidamber, 1994 Sklopljenost Henderson, 1996 Sklopljenost Henderson, 1996 Statična Coupling Factor (CF) Sklopljenost Harrison, 1998 Statična, dinamična Lack of Cohesion (LCOM) Kohezija Chidamber, 1994 Dinamična Tight Class Cohesion (TCC) Kohezija Braind, 1999 Dinamična Loose Class Cohesion (LCC) Kohezija Braind, 1999 Statična Statična Statična Information based Cohesion (ICH) Method Hiding Factor (MHF) Attribute Hiding Factor (AHF) Kohezija Lee, 1995 Skrivanje informacij Skrivanje informacij Harrison, 1998 Harrison,

25 Statična, dinamična Number of Children (NOC) Dedovanje Chidamber, 1994 Statična Depth of Inheritance (DIT) Dedovanje Chidamber, 1994 Statična Statična Statična Method Inheritance Factor (MIF) Attribute Inheritance Factor (AIF) Number of Methods Overridden by a subclass (NMO) Dedovanje Harrison, 1998 Dedovanje Harrison, 1998 Polimorfizem Henderson, 1996 Statična Polymorphism Factor (PF) Polimorfizem Harrison, 1998 Statična Reuse ratio Ponovna uporaba Henderson, 1996 Statična Specialization ratio Ponovna uporaba Henderson, 1996 Zaradi vse večje popularnosti OO programiranja so nekateri prilagodili in nadgradili obstoječe metrike in pristope k merjenju programske opreme ter s tem omogočili aplikacijo le-teh na OO programski opremi. OOFP (object oriented function points) ali OODFP (object oriented design function points) je nastala z nadgradnjo analize funkcijskih točk. Objektno usmerjene funkcijske točke se predpostavljajo kot funkcija objektov, ki so del objektnega modela. Model se lahko proizvede v času analize, fazi projektiranja in načrtovanja ali pa je pridobljen iz izvorne kode. Štetje OOFP poteka v štirih fazah: [44] prepoznavanje logičnih datotek znotraj modela. Določanje zahtevnosti posameznih logičnih enot oziroma datotek s štetjem enostavnih podatkovnih elementov in atributov ali DET (simple data elements) in kompleksnih podatkovnih elementov ali RET (complex data elements). Dodeljevanje OOFP vrednosti. Seštevanje posameznih OOFP vrednosti za pridobitev končnega rezultata. OO metrike imajo svoje prednosti in slabosti. Ena izmed glavnih prednosti je, da znajo kar dobro razlikovati preproste od kompleksnih OO projektov. Seveda pa imajo zaradi njihove specificiranosti tudi pomanjkljivosti, kot so: ne podpirajo študij zunaj OO paradigem, ne ukvarjajo se z vprašanji celotnega življenjskega cikla razvoja, težko jih je uporabiti pri 15

26 testiranju in vzdrževanju programske opreme, nimajo ali imajo slabšo avtomatizacijo in imajo slabšo podporo s strani orodij za ocenjevanje programske opreme. [28] Tradicionalne metrike programske opreme so ustvarjene in razvite s pridobivanjem vrednosti iz programa in izpeljave enačb. Ta pristop deluje dobro za preproste metrike, vendar pa modeli postajajo vse bolj zapleteni. Tradicionalni proces zahteva od razvijalca popolno razumevanje odnosa med vsemi spremenljivkami metrike, kar omejuje kompleksnost metrike. Potrebno je bilo poiskati alternativni način razvijanja metrik. Nevronske mreže se uporabljajo kot napovedni model zaradi njihove sposobnosti zapletenega modeliranja in minimalnega računanja. Zaradi tega so Ulisses Brisolara Corrêa, Luis Lamb in Luigi, Carro, Lišane Brisolara in Júlio Mattos predlagali nevronske mreže (Neural Network Based Metrics), ki se učijo od korelacije med različnimi metrikami in dajejo oceno vpliva odločitev pri razvoju programske opreme na končni rezultat meritev. Na podlagi rezultatov in sposobnosti nevronskih mrež (NN), da se naučijo kompleksne nelinearne vzorce, so jih začeli uporabljati kot napovedne modele metrik programske opreme. Nevronske mreže imajo še nekatere druge prednosti. Razvijalec lahko določi samo vhode in izhode in znanja o samem procesu računanja ne potrebuje. Za razliko od tradicionalnega pristopa, kjer mora razvijalec poznati relacije med različnimi atributi, nevronska mreža samodejno ustvari te odnose. [31] [32] [33] Nekatera vodilna podjetja, kot so IBM, HP (Hewlett-Packard), NASA, Boeing in AT&T, dajejo veliko pomembnosti na kakovost programske opreme. Pomagajo si z merjenjem zadovoljstva uporabnikov. Metrike zadovoljstva uporabnikov in kupcev se pogosto merijo s pomočjo raziskav in anket po petstopenjski lestvici: zelo zadovoljen, zadovoljen, nevtralen, nezadovoljen, zelo nezadovoljen. IBM meri zadovoljstvo uporabnikov v osmih CUPRIMDSO kriterijih: zmogljivost (capability), funkcionalnost (functionality), uporabnost (usability), učinkovitost (performance), zanesljivost (reliability), namestitev (installability), vzdrževanje 16

27 (maintainability), dokumentacija / razpoložljivost (documentation / information, service) in skupno (overall). Nekateri kriteriji se prekrivajo ali si nasprotujejo, drugi se dopolnjujejo. Glede na dobljene podatke se nato izpeljejo različne metrike: odstotek popolnoma zadovoljnih kupcev, odstotek zadovoljnih kupcev (zadovoljni in zelo zadovoljni), odstotek nezadovoljnih kupcev (nezadovoljni in zelo nezadovoljni), odstotek kupcev ki niso zadovoljni (nevtralni, nezadovoljni, in popolnoma nezadovoljni). Podobno kot IBM tudi HP meri kakovost programske opreme. [2] Nekatera podjetja so razvila tudi svoja orodja za testiranje in merjenje kvalitete programske opreme: Motorola, Hewlett-Packard, IBM Rochester [2] U.S. Air Force Systems Command je razvil vrsto indikatorjev kvalitete programske opreme, ki temeljijo na merljivih lastnostih programske opreme. Z uporabo podobnih konceptov, predlaganih s standardom IEEE 982,1-1988, uporabljajo informacije pridobljene iz podatkov merjenj in arhitekturne zasnove programske opreme za izpeljavo indeksa kakovosti ali DSQI (Design Structure Queality Index), ki zavzema vrednosti med 0 in 1. Višja vrednost indeksa, boljša kvaliteta programske opreme. Za izračun DSQI je najprej potrebno izračunati naslednje faktorje: [39] S1 = Skupno število modulov, opredeljenih v programski arhitekturi. S2 = Število modulov, katerih pravilno delovanje je odvisno od vhodnih podatkov ali da so izhodni podatki uporabljeni drugje. S3 = Število modulov, katerih pravilno delovanje je odvisno od predhodne obdelave. S4 = Število predmetov podatkovne baze (vključuje podatkovne objekte in vse lastnosti oziroma atribute, ki opredeljujejo objekte). S5 = Skupno število edinstvenih predmetov podatkovne baze. S6 = Število segmentov podatkovne baze (različne evidence ali posamezni objekti). S7 = Število modulov z enim samim vhodom in izhodom (obdelava izjem ne velja za večkratni izhod). Ko so ti faktorji definirani, lahko izračunamo vmesne vrednosti: 17

28 D1: Struktura programa, kjer je D1 enak 1 v primeru da je arhitektura zasnovana z uporabo ene izmed metod programiranja in načrtovanja (OO programiranje, dataflow usmerjeno načrtovanje, ipd.), drugače je D1 enak 0. D2: Neodvisnost modulov. D2 = 1 - (S2/S1). D3: Moduli, ki niso odvisni od predhodne obdelave. D3 = 1 - (S3/S1). D4: Velikost podatkovne baze. D4 = 1 - (S5/S4). D5: Kompartmentalizacija podatkovne baze. D5 = 1 - (S6/S4). D6: Izhode/vhodne značilnosti modulov. D6 = 1 - (S7/S1). Ko so vmesne vrednosti določene, lahko izračunamo vrednost DSQI s seštevkom obteženih vmesnih vrednosti: DSQI = SUM(w i D i ) Raziskave in prakse metrik programske opreme nam pomagajo lažje razumeti delovanje in so osnova in empirična podlaga za razvoj programske opreme. Večina ciljev in meritev se lahko doseže z zelo preprostimi metrikami, mnoge od katerih bi morala biti na voljo kot del vsakega dobrega sistema za upravljanje razvoja v podjetju. To vključuje predvsem: informacije o spremembah in napakah ugotovljenih pri različnih fazah življenjskega cikla programske opreme in sledljivosti le-teh. Prav tako je zelo koristno, če so podatki in meritve podkrepljene in dopolnjene s subjektivno presojo in oceno. [35] Eden izmed izzivov metrik je tudi prenosljivost in njihova razumljivost. Metrike so orodje, ki pomagajo pri samem razvoju in nadaljnjem odločanju vodstva, zato morajo biti predstavljene v obliki, ki jih vodstvo oziroma uporabniki brez težav in enostavno razumejo in uporabljajo. To je velik izziv in cilj za razvoj metrik v prihodnosti. Njihova uporaba mora podpirati in dajati informacije, ki pomagajo pri nadaljnjem odločanju in ocenjevanju tveganja. [35] 18

29 3 Skozi razvoj metrik so nekateri predlagali in razvili zelo zanimive in inovativne pristope k merjenju različnih aspektov programske opreme. Cilj teh inovativnih metrik programske opreme je izboljšati kvaliteto in zanesljivost metrik in rezultatov, ki jih dajejo, kot tudi njihovo splošno sprejetost. V prejšnjem poglavju smo že omenili aplikacijo nevronskih mrež na že obstoječe metrike. Proti koncu 90-tih in v zadnjih letih so veliko pozornosti pritegnile Bayesian belief mreže (BBN - Bayesian belief nets) kot rešitev in podpora pri odločanju v negotovosti. Čeprav je bila osnovna teorija (Bayesian verjetnost) prisotna že dlje časa, so komaj zadnji napredki in algoritmi omogočili uspešni razvoj in izgradnjo realističnih modelov. Nekateri drugi inovativni pristopi in metrike so parametrična metrika in Weighted Micro Function Points, ki jih bomo predstavili nekoliko bolj podrobno. 3.1 Parametrična metrika programske opreme Veliko metrik ima težavo z zanesljivostjo. Dve različni metriki lahko dasta zelo različne rezultate pri merjenju enake programske opreme. Zaradi tega se uporabnik ne more pravilno odločiti. Prve metrike programske opreme so bile statične, neprilagodljive, saj so rezultati bili osredotočeni na samo en določen aspekt ali cilj (Graf 3.1). Rešitev teh težav je parametrična metrika, ki jo je mogoče prilagoditi na potrebe uporabnika. Prilagodljivi atributi nato generirajo formulo, ki se bo uporabljala za meritve. Uporabniki lahko izberejo lastnosti programske opreme glede na njihov cilj in lahko tudi preverijo formulo. To pomeni, da lahko uporabniki prilagodijo meritve programske opreme za dosego svojega cilja in dobijo ustrezne rezultate iz meritev. [29] 19

30 Atributi Metrika Rezultati Graf 3.1: Koncept metrik programske opreme (Vir: [29]) Zaradi različnih ciljev je prilagajanje parametrov metrik težko, kar parametrična metrika rešuje s kategorizacijo atributov programske opreme glede na njihov pomen. Nato definira segmentirane atribute, kot parametre metrike in s pomočjo njih sestavi formulo. Uporabniki na koncu še vnesejo vrednosti parametrov glede na njihove želene cilje in tako dobijo rezultat metrike. Kategorizirani atributi, imenovani parametri, in formula so glavne karakteristike parametrične metrike (Graf 3.2). [29] Uporabniški cilji Segmentirani atributi Parametrična metrika Rezultati Graf 3.2: Koncept parametrične metrike programske opreme (Vir: [29]) 20

31 Slika 3.1: Arhitektura parametrične metrike (Vir: [45]) Programski analizator (Slika 3.1) ustvari statične informacije o programski kodi. Metrični ocenjevalec (Slika 3.1) je najpomembnejši del parametrične metrike. Upravlja z različnimi podatki na osnovi informacij programskega analizatorja in uporabnika ter njegovih ciljev. Uporabniške informacije sestavljajo formule, programski atributi, nabor meritev, ipd. Formule predstavljajo odnose med različnimi lastnostmi programske opreme. Filter rezultatov (Slika 3.1) predstavljajo mejo atributov in ga je mogoče uporabiti za primerjavo rezultatov metrik. Na primer, če uporabnik potrebuje število vrstic izvorne kode (LOC), ki je manj kot 1000, potem je meja manj kot 1000 in atribut je metrika LOC. [45] Delovanje metrike bomo prikazali na primeru DDM (Defect Density Metric), ki je dobro poznana metrika za merjenje napak v programski opremi. Število napak in LOC sta potrebni za izračun DDM. Rezultat DDM dobimo kot ulomek med številom napak in LOC. Namesto LOC lahko uporabimo tudi število posameznih modulov oziroma funkcijskih točk (FP ali Function Points). V življenjskem ciklu programske opreme so nekatere napake, hrošči in pomanjkljivosti odkrite v času testiranja in razvoja (PREF ali PRE release failures), druge pa kasneje po izdaji programske opreme (POSF ali POSt release failures). DDM se uporablja za identifikacijo tistih programskih komponent z večjim številom napak in visokim tveganjem, da jim lahko namenimo več pozornosti in virov. 21

32 Omogoča pa nam tudi identifikacijo in primerjavo kvalitete med različnimi programskimi opremami. [29] [30] LOC se veliko uporablja v drugih metrikah. Kategoriziramo jo lahko na LOC s komentarji, kjer je rezultat število vrstic s komentarji in LOC brez komentarjev, kjer je rezultat število vrstic kode brez komentarjev. Tipi metrike LOC so predstavljeni v Tabela 3.1. Tabela 3.1: Različni tipi metrike LOC (Vir: [29]) Atribut Segmentiran atribut Opis LOC (Lines of Code) CLOC NCLOC BLOC LSLOC DLOC Število vrstic s komentarji Število vrstic kode brez komentarjev Število praznih vrstic Število vrstic, ki vsebujejo več ločenih ukazov Število vrstic, ki vsebujejo deklaracijo podatkov (spremenljivk, konstant ) Za izdelavo formule, smo definirali razmerje med segmentiranimi atributi. CLOC in NCLOC tvorita število vseh vrstic kode. NCLOC je nadalje sestavljen iz BLOC, LSLOC in DLOC, ki jih lahko vključimo glede na obseg posameznih atributov. Formulo parametrične metrike dobimo s pomočjo formule za DDM, kjer atribut C predstavlja del programske kode. [29] DDM = število napak v C velikost C ( 1 ) Kot prej omenjeno, lahko C izrazimo z LOC, ker je del programske kode fiksen. LOC lahko nato še nadalje razdelimo in dobimo formulo: velikost C = CLOC + NCLOC ( 2 ) V primeru, če koda ne vsebuje vrstic s komentarji in praznih vrstic, se formula glasi: 22

33 velikost C = NCLOC BLOC ( 3 ) V primeru če koda vsebuje samo vrstice z izvršljivo oziroma izvorno kodo (SLOC), uporabimo spodnjo formulo: velikost C = NCLOC BLOC LSLOC DLOC ( 4 ) Uporabnik lahko nato z zamenjavo velikosti C v enačbi ( 1 ) z eno izmed enačb ( 2 ), ( 3 ) ali ( 4 ) dobi končno formulo parametrične metrike. V primeru uporabe formule ( 4 ) v času testiranja in razvoja dobimo enačbo: DDM = PREF NCLOC BLOC LSLOC DLOC ( 5 ) Demonstracija parametrične metrike na primeru Demonstracijo delovanja in uporabe formule lahko prikažemo na kodi mehurčnega urejanja, ki vsebuje vse potrebne parametre metrike LOC. [29] Slika 3.2: Del kode mehurčnega urejanja 23

34 Spodnja Tabela 3.2 prikazuje vrednosti za posamezne segmentirana atribute metrike LOC, ki so potrebni za končni izračun parametrične metrike. Tabela 3.2. Vrednosti segmentiranih atributov za mehurčno urejanje (Vir: [29]) Segmentiran atribut / vrsta LOC Število vrstic Številke vrstic na Slika 3.2 Vse vrstice 128 Od 89 do 102 CLOC 23 Od 91 do 93 DLOC 21 Od 95 do 96 BLOC LSLOC 4 Od 98 do 100 NCLOC 105 Od 89 do 90 in od 94 do 102 Za izračun DDM moramo določiti vrednost, ki predstavlja mejo izdaje in stabilnosti programske opreme. Meja je določena s strani uporabnika za primerjavo z rezultatom metrike. Nižja kot je ta vrednost, bolje je, saj programska oprema vsebuje manj napak in je bolj stabilna. Če je ta vrednost 0.05 in rezultat DDM 0.02, pomeni, da lahko izdamo programsko opremo. Predpostavimo: Tabela 3.3: Število napak ter meja izdaje in stabilnosti Vrednost PREF 5 POSF 2 Meja izdaje 0.05 Meja stabilnosti / kvalitete 0.02 Zadamo si dva cilja in nato ocenimo kvaliteto programske opreme. 24

35 Cilj 1: Možnost izdaja programske opreme Cilj tega eksperimenta je izvedeti, ali lahko programsko opremo izdamo. Za vrednost napak parametra izberemo PREF. Za izračun vrednosti LOC bomo uporabili enačbe ( 2 ), ( 3 ) in ( 4 ). Tabela 3.4: Rezultati eksperimenta cilja 1 Št. Enačba PREF CLOC NCLOC DLOC BLOC LSLOC Rezultat 1 2 O O O O O O O O O O O Rezultati eksperimenta so 0,03 pri uporabi enačbe ( 2 ), 0,06 pri uporabi enačbe ( 3 ) in 0,08 pri uporabi enačbe ( 4 ). Če rezultate primerjamo s prej določenimi mejami, vidimo, da lahko programsko opremo izdamo v primeru št. 1. V primeru št. 2 in 3 bomo morali še vložiti nekaj truda in časa, preden lahko izdamo programsko opremo. Cilj 2: Ocena kakovosti programske opreme in vzdrževanja Namen tega eksperimenta je oceniti pričakovane stroške vzdrževanja po izdaji (POSF) programske opreme. Visok DDM pomeni, da ne dodeli visokih stroškov za vzdrževanje. Za izračun vrednosti LOC bomo uporabili enake enačbe kot pri Cilju 1. Tabela 3.5: Rezultati eksperimenta cilja 2 Št. Enačba c CLOC NCLOC DLOC BLOC LSLOC Rezultat 4 2 O O O O O O O O O O O Rezultati eksperimenta so 0,01, 0,02 in 0,03. To pomeni, da je programska oprema stabilna pri testu števila 4, ker je meja kakovosti, ki smo si jo zastavili, nižja od 0,02. Številka 4 bo imela tudi manjše stroške vzdrževanja kot 5 in 6. 25

36 Eksperimenta sta pokazala, da lahko različni obsegi kode dajejo povsem drugačne rezultate. S spreminjanjem obsega kode lahko spreminjamo rezultate in jih nato med seboj primerjamo Lastnosti parametrične metrike Parametrična metrika ima svoje prednosti in slabosti. Največja prednost je prilagodljivost, saj lahko uporabniki prilagodijo parametre v skladu s svojimi cilji. To pomeni, da uporabnik zaupa rezultatu in pozna podrobnosti, ker je sam vplival nanj. Zaradi prilagodljivosti uporabniki lahko primerjajo med seboj različne rezultate s spreminjanjem obsega atributov. Za uporabnika je lahko ta prilagodljivost težka, saj potrebuje razumevanje o samem delovanju in lastnostih posameznih atributov in parametrov. To pomeni tudi, da je težje avtomatizirati proces in rezultati niso takojšnji. 3.2 Weighted Micro Function Points Weighted Micro Function Points (WMFP) je sodoben algoritem, ki se uporablja za ocenjevanje velikosti programske opreme. Izumili so ga pri podjetju Logical Solutions leta 2009 in je naslednik metrik in modelov, kot so COCOMO, COSYSMO, indeks vzdrževanja, ciklomatična metrika kompleksnosti, funkcijske točke in Halstead-ova metrika kompleksnosti. Daje točnejše rezultate od tradicionalnih metrik in modelov programske opreme in zahteva manj znanja od končnega uporabnika, saj je večina ocen odvisna od avtomatskih meritev obstoječih izvorne kode. Za razliko od večine predhodnikov, ki uporabljajo SLOC metriko za merjenje velikosti izvorne kode, WMFP uporablja razčlenjevalnik za razumevanje izvorne kode, ki jo nato razčleni na mikro funkcije in izpelje različne formule ter metrike kompleksnosti in velikosti za izračun končnega rezultata WMFP. Rezultat je kombinacija več metrik programske opreme, povezanih z WMFP algoritmom. [40] [41] Flow complexity (FC) meri kompleksnost nadzora pretoka podobno kot ciklomatična metrika kompleksnosti z večjo natančnostjo zaradi uporabe uteži in upoštevanjem relacij. 26

37 Object vocabulary (OV) meri količino unikatnih informacij, ki jih vsebuje izvorna koda programa, podobno kot Halstead-ova metrika in z uporabo kompenzacije dinamičnega jezika. Object conjuration (OC) meri količino uporabljenih informacij izvorne kode oziroma inicializiranih objektov. Arithmetic intricacy (AI) meri kompleksnost aritmetičnih operacij programa. Data transfer (DT) meri manipulacijo s podatkovnimi strukturami programa. Code structure (CS) meri količino vloženega truda za strukturiranje programske kode v razrede in funkcije. Inline data (ID) meri količino truda porabljenega za implementacijo programske kode in podatkov. Comments (CM) meri količino truda porabljenega za pisanje programskih komentarjev. Algoritem WMFP je izračunan v 3 fazah: funkcijska analiza, APPW transformacija in izračun rezultata, kot je prikazano na Graf 3.3. [40] [41] WMFP APPW Rezultat FC DT CS ID CM UTEŽI Graf 3.3: Faze algoritma WMFP 27

38 Dinamičen algoritem uravnoteži seštevek merjenih elementov oziroma različnih metrik. Osnovna formula je: N K (W i M i ) D q i=1 q=1 Tu je: M - vrednost osnovne metrike izmerjena v fazi WMFP analize. W - prilagojene uteži metrike M dodeljene z APPW modelom. N - število metrik. i - številka trenutne metrike. D - stroškovni faktor, ki ga poda uporabnik z vnosom. q - številka trenutnega stroškovnega faktorja. K - število stroškovnih faktorjev. Rezultati funkcijske analize so predstavljeni kot odstotek celote in so nato pretvorjeni v čas s pomočjo statističnega modela»average programmer profile weights«(appw), ki je naslednik modela COCOMO 2 in COSYSMO. Programerske delovne ure so nato množene s ceno povprečne programerske ure. Rezultat je povprečna cena projekta Lastnosti WMFP WMFP je kompatibilen z razvojno metodologijo kaskadnega modela (waterfall software development life cycle methodology) in tudi z novejšimi metodologijami, kot so Six Sigma, Boehm spiral in agilno programiranje. Ena izmed slabosti algoritma je, da so osnovni elementi v primerjavi s tradicionalnimi modeli in metrikami, kot so COCOMO, bolj zapleteni in jih ni mogoče realno oceniti oziroma izračunati na roko. To ni mogoče niti na manjših projektih. Za izračun in analizo izvorne kode je potrebna programska oprema. Zaradi tega je težje oceniti in podati predikcije rezultatov. 28

39 3.3 BBN Velik izziv za razvoj novih programskih metrik je izdelava modelov razvoja in testiranja programske opreme, ki upoštevajo ključne koncepte, manjkajoče pri klasičnih pristopih, ki temeljijo na regresiji. Modeli, ki zmorejo delati z in obvladovati: [35] raznolike procesne in produktne spremenljivke, empirične dokaze in strokovno presojo, vzročno-posledične odnose, negotovost, nepopolne podatke. Hkrati pa se učinkovitost in hitrost procesiranja v smislu količine zbiranja podatkov ter zahtevnosti metrike ne sme poslabšati. Po obsežnih raziskavah so med leti 1993 in 1996 v času projekta DATUM prišli do zaključka, da so Bayesian belief nets (BBN) daleč najboljša rešitev danega problema. Slika 3.3: Defects BBN (posplošeno) [35] 29

40 BBN je grafična mreža (Slika 3.3) skupaj s pripadajočimi verjetnostnimi tabelami. Vozlišča predstavljajo neznane spremenljivke, povezave med njimi pa ustrezna vzročna razmerja med njimi. Verjetnostne tabele za vsako vozlišče prikazujejo verjetnosti vsakega stanja oziroma vrednosti spremenljivke za tisto vozlišče. Za vozlišča brez staršev so to le obrobne verjetnosti, medtem ko so za vozlišča s starši to pogojne verjetnosti za vsako kombinacijo starševskih vrednosti. Verjetnostne tabele ali NPT (node probability tables) se zgradijo s pomočjo empiričnih podatkov in ekspertnega znanja in odločanja [35]. Oblikovanje in izgradnja NPT podatkov je eno izmed temeljnih vprašanj, saj ne obstajajo smernice ali pravila, ki bi jih bilo mogoče uporabiti in bi bila primerna za vse vrste težav in vprašanj. BBN temeljijo na Beyes-ovem izreku, ki ga je razvil Thomas Bayes, matematik iz 18. stoletja in je izražen kot: kjer sta A in B dogodka in P(B) 0. P (R S) = P (S R)P(R) P(S) Sestavljene so iz dveh delov. Kvalitativni del, ki predstavlja razmerje med spremenljivkami v obliki usmerjenega acikličnega grafa in kvantitativni del, ki določa porazdelitev verjetnosti posameznih vozlišč modela. [46] BBN imajo več prednosti: [46] predstavljajo probabilistični pristop (% - verjetnosti). Razviti jih je mogoče z malo podatkov in hitro. Znajo računati s primeri, katerim primanjkujejo podatki ali niso na voljo. Lahko se uporabijo za modeliranje vzročnih odnosov in tudi skupinskih modelov. Strokovne podatke je enostavno vključiti. Njihova posodobitev z novimi podatki in dokazi je enostavna. Zaradi samega delovanja in strukture BBN se vrednosti in rezultati propagirajo glede na predložene podatke in dokaze. Sprememba enega podatka bo sprožila posodobitev vseh verjetnosti v celotni mreži. Ena izmed zanimivosti BBN je, da računa verjetnost za vsako stanje vsake spremenljivke glede na predložene empirične podatke in dokaze. Posledično pa pomanjkanje le-teh vpliva in povečuje nezanesljivost in negotovost rezultatov. Ena izmed 30

41 glavnih prednosti BBN pred tradicionalnimi metrikami in pristopi je, da nudijo zelo dobro podporo pri odločanju in ocenjevanju tveganja. Kljub temu pa imajo BBN tudi svoje pomanjkljivosti. Na primer, da želimo izvedeti, ali je naša programska oprema primerna za vzpostavitev v nuklearni elektrarni. BBN morda zmore bolje oceniti zanesljivost programske opreme, saj lahko združi in kombinira več različnih dokazov in podatkov. Preuči lahko tudi različne kompromise in slabosti ter vpliv različnih dejavnikov na zanesljivost programske opreme. Vendar pa ne zadošča pri sprejemanju odločitev, kot je, ali je programsko opremo mogoče vzpostaviti. [35] BBN so se izkazale zelo koristne v praktičnih aplikacijah, kot so medicinska diagnostika in diagnostika mehanskih napak. Njihova najbolj znana uporaba je bila v pisarniškem paketu Microsoft Office kot osnova čarovnika za pomoč. [8] 31

42 4 Praktična analiza V prejšnjih poglavjih smo naredili pregled obstoječe literature, ocenili trenutno stanje metrik programske opreme in njihov razvoj skozi čas. V tem delu magistrske naloge bomo implementirali različne metrike in izvedli več eksperimentov na različni prosto dostopni in odprtokodni programski opremi iz spletnega Git repozitorija GitHub. Omogoča distribuirano kontrolno revizijo ter sledenje hroščev, nadzor dostopa, funkcionalne zahteve in upravljanje opravil. Izbrali smo 35 različnih projektov. Osredotočili smo se na programski jezik C#. Pri iskanju smo bili tudi pozorni na število hroščev in napak, ki so jih uporabniki prijavili v času uporabe, saj so le-ti potrebni pri računanju parametrične metrike z DDM. Z eksperimenti smo želeli raziskati, kakšna je kvaliteta, natančnost in učinkovitost posameznih metrik ter jih med seboj primerjali in predstavili rezultate in pomen le-teh. 4.1 Uporabljene tehnologije Po izčrpnem pregledu literature in tudi zaradi enostavnosti uporabe in razvoja, smo se odločili, da za razvoj naše aplikacije in testiranje metrik uporabimo programsko okolje Microsoft Visual Studio 2015 in programski jezik C#. V veliko pomoč so nam bile tudi že obstoječe rešitve oziroma implementacije različnih metrik. Microsoft Visual Studio je integrirano razvojno okolje (IDE) [Slika 4.1], ki ga je razvilo podjetje Microsoft. Ta se uporablja za razvoj računalniških programov za Microsoft Windows in tudi spletnih strani, spletnih aplikacij in spletnih storitev. Visual Studio podpira različne programske jezike, kot so: C, C++ in C++/CLI (Visual C++), VB.NET (Visual Basic.NET), C# (Visual C#) in F# (Visual Studio 2010). Podpora drugim jezikom, kot so Python, Ruby, Node.js in M je na voljo preko ločeno nameščenih jezikovnih storitev. Prav tako podpira XML / XSLT, HTML / XHTML, JavaScript in CSS. [21] 32

43 C# je preprost, moderen in objektno usmerjen programski jezik, ki temelji na NET platformi in je potrjen pod standardom Ecma (ECMA-334) in ISO (ISO/IEC 23270:2006). Namenjen je razvoju programskih rešitev, primernih za uporabo v distribuiranih okoljih. Slika 4.1: Microsoft Visual Studio 2015 IDE (vir: [21]) Pri lastni implementaciji metrik smo si pomagali z že obstoječimi knjižnicami in vgrajenimi funkcijami, ki nam jih ponuja razvojno okolje VS Na Slika 4.3 lahko vidimo te vgrajene funkcije in analizo kode, ki vključuje indeks vzdrževanja (maintainability index), ciklomatično kompleksnost (cyclomatic complexity), globino dedovanja (depth of inheritance), sklopljenost razredov (class couplings) in število vrstic kode (LOC - lines of code). Indeks vzdrževanja meri, kako enostavno je izvorno kodo programske opreme vzdrževati, spreminjati in posodabljati. Analiza kode je opravljena na vsakem razredu in funkcijah posebej. Zavzema vrednosti med 0 in 100. Višja vrednost pomeni lažje vzdrževanje programske opreme. Vrednosti med 20 in 100 predstavljajo dobro vzdrževanje, vrednosti med 10 in 20 srednjo in vrednosti med 0 in 10 slabo [Slika 4.2]. Formula, ki jo uporablja VS 2015 za izračun indeksa vzdrževanja se glasi: IV = max (0, log(hv) 0.23 (CC) 16.2 log(loc) ), 33

44 kjer je: HV = Halstead Volume CC = Cyclomatic Complexity LOC = Lines of Code. To je samo ena izmed mnogih enačb za izračun indeksa vzdrževanja. Ciklomatična kompleksnost meri strukturno kompleksnost izvorne kode. Visual Studio razporedi rezultate v 3 razrede. Vrednosti med 1 in 10 predstavljajo dobro kompleksnost programske kode, vrednosti med 11 in 20 predstavljajo srednje dobro kompleksnost in vrednosti na 20 predstavljajo slabo oziroma previsoko kompleksnost. Ciklomatična kompleksnost je zelo pomembna saj predstavlja minimalno število testnih primerov za testiranje programske opreme. Ciklomatična kompleksnost za celotni projekt je sešteta za vse razrede in metode znotraj teh. Globina dedovanja predstavlja drevo dedovanja. Nižje, kot so vrednosti globine dedovanja, bolje je, ker večje, kot je število, slabša je razumljivost kode in težje je slediti pretoku kode ter posledično odpravljati napake in tudi analizirati programske kode. Sklopljenost razredov predstavlja povezave med razredi in meri sklope edinstvenih razredov s parametri, lokalnimi spremenljivkami, klici metod, inicializacijo predlog, baznih razredov Vrednosti med 0 in 9 predstavljajo dobro sklopljenost. Prakse dobrega programiranja in strukturiranja programske kode velevajo visoko kohezijo in nizko sklopljenost med metodami in vrstami. Visoka sklopljenost predstavlja strukturo, ki jo je težje ponovno uporabiti in vzdrževati zaradi številnih soodvisnosti z drugimi metodami in vrstami. [42] [43] Slika 4.2: Prikaz različne kvalitete programske kode v VS 2015 (Vir: 34

45 Slika 4.3: Primer vgrajenih metrik programa VS Omejitve in predpostavke Ker smo izbrali razvojno okolje VS, smo se za testiranje omejili na 36 projektov, razvitih s tehnologijo.net in programskim jezikom C#. Za bolj zanesljive rezultate smo izbrali nekaj projektov oziroma programov, ki so si med seboj podobni in nekaj programov, ki so zelo različni po velikosti in drugih lastnostih. Tako bomo lahko tudi videli, kako imajo takšni projekti vpliv na rezultate metrik. Zaradi velikega nabora podatkov je manj verjetno, da bi lahko nekateri rezultati izstopali oziroma je manjša verjetnost ubežnikov (outliers). Zaradi 35

46 razlik med programskimi jeziki in razvojnimi okolji ne moremo posploševati rezultatov zunaj razvojnega okolja, uporabljenega v tej raziskavi. Za večjo veljavnost rezultatov in možnost posploševanja bi bilo potrebno ponoviti raziskavo v drugih okoljih. Eno izmed omejitev predstavlja tudi količina informacij o posameznem projektu. Za računanju možnosti izdaje programske opreme s pomočjo parametrične metrike potrebujemo podatek o številu napak v času razvoja, ki ga ne moremo izvedeti na spletnem repozitoriju GitHub. Število napak, ki so jih prijavili uporabniki, pa ni povsem točen podatek, saj lahko ostaja še veliko neodkritih napak. 4.3 Implementacija aplikacije Pri razvoju aplikacije smo se osredotočili predvsem na enostavno, hitro in učinkovito delovanje. V ta namen smo razvili tudi grafični uporabniški vmesnik (GUI) [Slika 4.4], ki omogoča prikaz rezultatov na enostaven in pregleden način. Slika 4.4: GUI lastne aplikacije Aplikacija vsebuje naslednje funkcionalnosti: 36

47 nalaganje projektov, ki omogoča nalaganje datotek celotnega projekta, izvoz podatkov in rezultatov v različne formate (CSV, Excel in.txt), računanje metrik velikosti, računanje parametrične programske metrike, spreminjanje nastavitev. Programsko kodo aplikacije smo razdelili v smiselne enote za lažji pregled, vzdrževanje in nadgradnjo programske kode. Strukturo aplikacije sestavlja več podmap in razredov (Slika 4.5). 37

48 Slika 4.5: Struktura aplikacije Datoteke Main.cs, PsmParams.cs in SettingsForm.cs znotraj našega projekta predstavljajo vizualni del aplikacije (GUI) ter logiko in delovanje le-tega. Main je glavna forma naše aplikacije in sestoji iz 4 delov. Ukazni meni omogoča uporabniku izvajanje različnih ukazov, kot so: nalaganje projekta, izvoz podatkov, računanje metrik, nastavitve aplikacije Tabela (GridView) prikazuje podatke projektov in rezultate metrik za posamezno datoteko, ki so (Slika 4.11): 38

49 ime datoteke, relativna pot znotraj projekta, velikost datoteke, metrike velikosti: SLOC, BLOC, CLOC, NCLOC, LSLOC, DLOC in LOC, ter seštevki vrednosti oziroma rezultatov vseh stolpcev v zadnji vrstici. Polje z besedilom (RichTextBox) prikazuje dodatne rezultate metrik za celotni projekt. Statusna vrstica, ki uporabnika obvešča o trenutnem stanju aplikacije, napredku nalaganja in prikazuje druge uporabne informacije. PsmParams forma se pojavi, ko uporabnik želi izračunati parametrično metriko in od njega zahteva, da vnese število najdenih napak projekta ter mejo izdaje in stabilnosti, ki so potrebni za izračun parametrične metrike. SettingsForm forma omogoča uporabniku spremembo različnih nastavitev aplikacije, kot so privzeti format velikosti datotek, končnice dovoljenih datotek projekta in izključene datoteke ter mape projekta. Za dostop do teh globalnih spremenljivk skozi celotno aplikacijo smo uporabili knjižnico Westwind.Utilities, ki ima bogato paleto različnih funkcij. Mapa»Container«vsebuje datoteki»file.cs«(razred File) in»project.cs«(razred Project), katerih razreda nosita vse podatke naloženih projektov. Razred»Project«vsebuje atribute in podatke, kot so: ime projekta, absolutna pot do mape projekta, število datotek, posamezne datoteke ter seštevke metrik za celotni projekt. Med drugim pa vključuje tudi metode, ki vračajo rezultate in podatke za posamezni projekt ter kličejo metode za računanje in seštevanje metrik. Podobno je sestavljen tudi razred»file«, vendar pa ta nosi podatke in metode, ki skrbijo za vedenje posamezne datoteke znotraj celotnega projekta. Mapa»Extension«vsebuje datoteke in razrede, ki razširijo že obstoječe razrede z dodatnimi funkcionalnostmi.»filesizeextensions«vsebuje metode, ki pretvarjajo velikost metod v različne formate (npr. iz KB v MB) in zaokrožujejo decimalne vrednosti na želeno natančnost. Metoda znotraj razreda»richtextboxextensions«omogoča dodajanje teksta elementom»richtextbox«v različnih barvah.»languagedefinitions«vsebuje razrede s statičnimi konstantnimi spremenljivkami, ki nosijo podatke za posamezni programski jezik. To so: ime programskega jezika, kratko ime, 39

50 končnice datotek, izvzete datoteke in mape, direktive, deklaracije in ukazi programskega jezika, ipd. Primer strukture razreda lahko vidimo na Slika 4.6. Slika 4.6: Struktura razreda CSharp v mapi LanguageDefinitions Ti podatki so nam v pomoč pri nalaganju projekta in pri računanju posameznih metrik kot sta LSLOC in DLOC. Storitve znotraj mape»services«skrbijo za nalaganje projekta in izvoz podatkov. Uporabniku se ob kliku na ukaz, da želi odpreti nov projekt, odpre novo pogovorno okno kjer izbere mapo z vsebovanim projektom, ki ga želi naložiti. Ob potrditvi funkcija najprej pregleda mapo in njene podmape in najde vsebovane datoteke. Nato filtrira te datoteke s pomočjo definiranih podatkov znotraj razreda izbranega programskega jezika (privzeto CSharp) v mapi»languagedefinitions«(slika 4.7). 40

51 Slika 4.7: Filtriranje datotek projekta V primeru če uporabnik klikne na ukaz za izvoz podatkov, lahko izbira med izvozom v CSV, Excel (Slika 4.8) ali tekstovni format. Za izvoz podatkov Excel smo si pomagali s prosto dostopno knjižnico ClosedXML. Knjižnica zagotavlja in omogoča enostaven objektno usmerjen način dela in manipulacije z Excel datotekami. Uporablja in deluje znotraj.net ali VB (Visual Basic) okolja. Slika 4.8: Primer izvoza podatkov v Excel formatu Mapo»Metrics«sestavljajo modeli in statični razredi za računanje posameznih metrik. Za izračun parametrične metrike moramo najprej izračunati metrike SLOC, BLOC, CLOC, NCLOC, LSLOC, DLOC in LOC. To smo naredili tako, da smo se za vsako posamezno datoteko sprehodili skozi vse vrstice, jim odstranili nepotrebne presledke in iskali indikatorje vrste vrstice (Slika 4.9). Najprej smo povečali metriko LOC za vsako vrstico in nastavili zastavice za več vrstične komentarje. Nato smo preverili, ali je vrstica prazna in inkrementirali BLOC metriko. V nasprotnem primeru smo preverili, če je vrstica komentar, ali se nahajamo v večvrstičnem komentarju. Če se je izkazalo, da vrstica ne ustreza nobenemu izmed prejšnjih pogojev, smo preverili, ali vsebuje katerega izmed ukazov, 41

52 direktiv ali deklaracij, definiranih v razredu znotraj mape»languagedefinitions«in inkrementirali pripadajočo metriko. To smo storili z uporabo vgrajenih funkcij in Microsoft.NET Framework komponente LINQ (Language Integrated Query), ki omogoča podatkovne poizvedbe, podobno kot jezik SQL. Na koncu smo še ponastavili zastavico za večvrstične komentarje. Vrednosti metrik NCLOC smo dobili tako, da smo odšteli število vrstic s komentarji (CLOC) od vseh vrstic (LOC). Metrike je mogoče tudi izračunati posamezno s klicem pripadajoče metode znotraj statičnega razreda. Slika 4.9: Algoritem računanje metrik velikosti 42

53 Ko smo dobili rezultate metrik velikosti, smo lahko poklicali funkcije parametrične metrike (Slika 4.10) s pripadajočimi vrednostmi. Enačbe znotraj funkcij so enake enačbam ( 2 ), ( 3 ) in ( 4 ) in se prikličejo za napake v času razvoja in nato še za napake v času po izdaji programske opreme. Dobljene vrednosti smo nato primerjali z vnesenimi mejami izdaje in stabilnosti in dobili končne rezultate, ki so nam povedali, ali je projekt mogoče izdati in kakšna je stabilnost projekta. Slika 4.10: Algoritem računanja parametrične metrike Te rezultate smo na koncu izpisali v tekstovno polje in posodobili tabelo z vrednostmi metrik velikosti, kot lahko vidimo na Slika

54 Slika 4.11: Primer prikaza rezultatov metrik za posamezni projekt 44

55 5 Rezultati Rezultati raziskav so predstavljeni v vrstnem redu, kot so bile raziskave opravljene. Najprej smo nad vsemi izbranimi projekti opravili analizo z metrikami vgrajenimi v VS Za izračun povprečne ciklomatične kompleksnosti smo uporabili prosto dostopni odprtokodni program LocMetrics, ki je dostopen na povezavi Rezultate za vsak projekt posebej smo predstavili v tabelarni obliki (Tabela 5.1). Predstavljajo skupne rezultate za vsak projekt posebej. Legenda za Tabela 5.1: IV indeks vzdrževanja, CK ciklomatična kompleksnost, GD globina dedovanja, SR sklopljenost razredov, LOC število vrstic izvorne kode (Lines of Code), POSF število napak odkritih po izdaji programske opreme, Avg. CK povprečna ciklomatična kompleksnost na datoteko. Tabela 5.1: Rezultati analize programske opreme z razvojnim okoljem VS 2015 Št. Ime projekta IV CK Avg. CK GD SR LOC POSF , Base , CacheDB , CBCrypt ChecksumValidat or C-Sharp Algorithms , , DeeTree , Evernote-sdkcsharp , fastjson Filewalker ,

56 11 GitPad , GitVersionTree , Grease , HTMLMinifier , HtmlSanitizer , ImageGlass libvideo , LinqToExcel , MailChimp.NET , MathNet-Spatial , Metrics.NET , Music Player , PowerForensics , QRCoder , RadixTree-master , ReportGenerator , ScreenCapture , SidebarDiagnostic s SimulatedAnneali ng , , Slikar C# , SmartFormat.NET , SteamCleaner , SuperBenchmarke r , TinyMapper , TotalUninstaller

57 Projekti imajo v večini zelo dobro kvaliteto programske kode. Nekateri izstopajo z visoko ciklomatično kompleksnostjo, kot je Evernote-sdk-csharp in SidebarDiagnostics in drugi z visoko sklopljenostjo razredov, kot je Metrics.NET. Kot smo prej omenili, pa rezultati predstavljajo seštevek ali povprečje za celotni projekt, kar lahko skrije slabše rezultate posameznih metod. Če želimo oceniti kvaliteto programske opreme, moramo pogledati rezultate bolj podrobno. Takoj lahko opazimo nekoliko slabše rezultate posameznih funkcij. Velikokrat so to inicializacijske metode, saj te metode skrbijo za inicializacijo drugih funkcionalnosti in razredov, kar v veliki meri vpliva na sklopljenost razredov, ciklomatično kompleksnost in posledično tudi na indeks vzdrževanja. Opaziti je mogoče, da je indeks vzdrževanja dober pokazatelj kvalitete programske kode, saj so pri računanju le tega zajeti rezultati ostalih metrik. To pomeni, da slabši rezultati drugih metrik znižujejo indeks vzdrževanja in obratno. Nekaj metod z nizkim indeksom vzdrževanja ali visoko ciklomatično kompleksnostjo smo izpostavili v Tabela 5.2, dodali pa smo tudi rezultate sklopljenosti razredov za primerjavo. Tabela 5.2: Primer metod s slabšo kvaliteto programske kode Ime projekta Metoda IV CK SR QRCoder Score(ref QRCodeData) : int QRCoder CreateQrCode(string, QRCodeGenerator.ECCLevel, bool) : QRCodeData Slikar C# InitializeComponent() : void ImageGlass InitializeComponent() : void GitVersionTree Generate() : void SimulatedAnnealing InitializeComponent() : void SimulatedAnnealing panel_paint(object, PaintEventArgs) : void ChecksumValidator InitializeComponent() : void ChecksumValidator SidebarDiagnostics BuildExceptionReport(string, string, string, Exception, StringBuilder) : StringBuilder InitCPU(IHardware, MetricConfig[], bool, bool, bool, bool, double) : void SidebarDiagnostics SettingsModel(Sidebar)

58 fastjson ParseDictionary(Dictionary<string, object>, Dictionary<string, object>, Type, object) : object SuperBenchmarker Main(string[]) : void Music Player InitializeComponent() : void PowerForensics SmartFormat.NET BinXmlTemplateInstanceData(byte[], int, int) GetPluralRule(string) : PluralRules.PluralRuleDelegate Evernote-sdk-csharp Read(TProtocol) : void Evernote-sdk-csharp Write(TProtocol) : void Nato smo nad izbranimi projekti opravili še analizo z lastno implementacijo parametrične metrike in predstavili rezultate v spodnji tabeli. Legenda za Tabela 5.3: PSM 1 rezultat parametrične metrike po enačbi ( 2 ), PSM 2 rezultat parametrične metrike po enačbi ( 3 ), PSM 3 rezultat parametrične metrike po enačbi ( 4 ), POSF napake odkrite po izdaji programske opreme, LOC Število vrstic kode. Tabela 5.3: Rezultati analize programske opreme z implementacijo parametrične metrike Št. Ime projekta PSM 1 PSM 2 PSM 3 POSF LOC Base62 0, , , CacheDB 0, , , CBCrypt 0, , , ChecksumValidat or C-Sharp Algorithms 0, , , , , , DeeTree Evernote-sdkcsharp 0, , ,

59 9 fastjson 0, , , Filewalker 0, , , GitPad 0, , , GitVersionTree 0, , , Grease 0, , , HTMLMinifier 0, , , HtmlSanitizer 0, , , ImageGlass 0, , , libvideo 0, , , LinqToExcel 0, , , MailChimp.NET 0, , , MathNet-Spatial 0, , , Metrics.NET 0, , , Music Player 0, , , PowerForensics 0, , , QRCoder 0, , , RadixTree-master ReportGenerator 0, , , ScreenCapture 0, , , SidebarDiagnosti cs SimulatedAnneali ng 0, , , , , , Slikar C# 0, , , SmartFormat.NE T 0, , , SteamCleaner 0, , , SuperBenchmarke r 0, , , TinyMapper 0, , , TotalUninstaller 0, , ,

60 Iz rezultatov parametrične metrike programske opreme v Tabela 5.3 lahko vidimo, da metrika deluje konsistentno v povezavi z velikostjo in številom napak projekta. 17 projektov ima vrednost PSM 3 pod 0,01, kar kaže na dobro kakovost in enostavno vzdrževanje programske opreme in posledično nižje stroške vzdrževanja. 7 projektov ima rezultate PSM 3 pod 0,02 in 11 projektov nad 0,02, kar kaže na slabo kvaliteto in dražje stroške vzdrževanja. Še posebej izstopajo projekti HTMLMinifier, HtmlSanitizer, GitPad z vrednostmi nad 0,1. Če analiziramo te projekte, vidimo, da imajo veliko število napak pri zelo majhnem številu vrstic izvorne kode. To pa pomeni, da ni obvezno, da bodo stroški vzdrževanja visoki. Kot že omenjeno, je meja stabilnosti določena s strani razvijalcev ali uporabnika in zadovoljuje njegove potrebe. Mejo stabilnosti je potrebno določiti za vsak projekt posebej, saj so si projekti med seboj različni in v primeru teh treh projektov bi bila meja nekoliko višja. Med parametrično metriko PSM 3 in ostalimi metrikami smo izvedli še korelacijo s pomočjo orodja Microsoft Excel in funkcije CORREL, ki se računa po enačbi: (x x )(y y ) CORREL(X, Y) = (x x ) 2 (y y ) 2 Korelacija ali korelacijski koeficient je številska mera, ki predstavlja moč linearne povezanosti dveh spremenljivk. Excel izračuna Pearsonov korelacijski koeficient, ki je računan na podlagi kovariance in standardnih odklonov serij obeh spremenljivk [47]. Vrednost korelacije je lahko med 1 in -1 in nam pove moč linearne povezanosti. Korelacijski koeficient blizu 0 nakazuje, da spremenljivki nista povezani. Korelacijski koeficient +1 kaže na popolno pozitivno korelacijo, kar pomeni, če se poveča spremenljivka X, se poveča tudi Y in obratno. Korelacijski koeficient -1 kaže na popolno negativno korelacijo, kar pomeni, če se poveča spremenljivka X, se Y zniža in obratno. 50

61 Rezultate korelacije vseh metrik lahko vidimo na Slika 5.1. Slika 5.1: Korelacija med PSM 3 in ostalimi metrikami Vidimo lahko, da je povezanost med metrikami zelo šibka ali neznatna. Nekoliko večja je povezanost s številom hroščev (POSF), kar pa je smiselno saj se POSF uporablja pri računanju PSM in v veliki meri vpliva na rezultat. 51

62 6 Sklep in nadaljnje delo Glavni namen in cilj magistrske naloge je bil bolje spoznati inovativne metrike programske opreme in eno izmed njih tudi implementirati. Da bi zastavljen cilj dosegli, smo raziskali in analizirali obstoječo literaturo. S sistematičnim pregledom smo dobili vpogled v trenutno stanje in razvoj metrik. S praktično implementacijo in statično analizo smo pokazali, da je parametrično metriko mogoče implementirati in da daje konsistentne rezultate (Tabela 6.1). Ker je implementirana parametrična metrika izpeljana iz DDM, lahko z njo zelo dobro ocenimo kvaliteto in tudi zahtevnost vzdrževanja programske opreme. S pomočjo korelacije med metrikami smo pokazali, da je povezanost ciklomatične kompleksnosti in indeksa vzdrževanja s parametrično metriko šibka. Veliko težavo nam je predstavljal izbor primernih GitHub projektov za testiranje metrik, saj je bilo potrebno najti takšne z nekoliko večjo aktivnostjo, kontribucijami in prispevki s strani skupnosti in uporabnikov. Na koncu smo se odločili za 35 projektov, kjer so si nekateri podobni in nekateri različni. Tako smo lahko videli, kakšen vpliv ima njihova podobnost na rezultate. Za uspešni izračun vrednosti parametrične metrike smo pred samo izvedbo analize morali poiskati prijavljene napake in hrošče projektov ter izločiti vprašanja, predloge, izboljšave, ipd. Tabela 6.1: Rezultati parametrične metrike Vrednost PSM Število projektov PSM 1 < 0,01 28 PSM 1 > 0,01 7 PSM 2 < 0,01 24 PSM 2 > 0,01 11 PSM 3 < 0,01 17 PSM 3 > 0,

63 Kljub odličnim rezultatom je mogoče našo aplikacijo še izboljšati in nadgraditi. Zelo veliko bi pripomogel sintaktični in leksikalni analizator, ki bi bolje prepoznaval vrste kodnih vrstic, glede na vsebino. Trenutna uporaba komponente LINQ za identifikacijo vrstic lahko daje lažno pozitivne rezultate. Naslednja izboljšava je dodajanje drugih parametričnih metrik, ki bi uporabniku omogočale večjo fleksibilnost in preverjanje kvalitetein tudi druge lastnosti programske opreme. Aplikacija pušča tudi možnost preproste nadgradnje za ostale programske jezike, saj je parametrična metrika neodvisna od programskega jezika. Dodati je potrebno samo definicije programskih jezikov in izdelati algoritem za prepoznavanje leteh. Kot smo že prej omenili, pa je potrebno poudariti, da zaradi razlik med programskimi jeziki in razvojnimi okolji ne moremo posploševati rezultatov zunaj razvojnega okolja uporabljenega v tej raziskavi. Rezultati variirajo tudi v količini testiranih projektov. V našo raziskavi smo se omejili na 35 projektov, vendar bi bilo potrebno za bolj zanesljive rezultate analizo opraviti na večji količini projektov in v drugih programskih jezikih. 53

64 7 Zaključek V magistrskem delu smo raziskali področje metrik in predstavili njihovo delovanje, karakteristike, razvoj skozi zgodovino in tudi njihove prednosti in slabosti. Razdelili smo jih v različne kategorije. Pri tem smo se osredotočili na inovativne metrike in pristope k merjenju programske opreme. Med njimi smo izbrali eno, katero smo implementirali in praktično analizirali. V raziskavi smo za testiranje uporabili 35 različnih projektov programske opreme, spisanih v programskem jeziku C#. S tem smo želeli pokazati, da se implementirana parametrična metrika bolje obnese in daje zanesljivejše rezultate kot standardne metrike programske opreme. Podobnost med metrikami smo ugotavljali s korelacijsko analizo, kjer je visoka stopnja korelacije zabeležena med metrikami, ki so si podobne. Skozi izdelavo magistrskega dela smo tako spoznali nove metrike in pristope merjenja programske opreme. Pokazali smo, da je parametrično metriko mogoče implementirati in da kljub podobnostim med metrikami daje bolj zanesljive in podrobne rezultate. Uporabnik lahko tudi s svojimi parametri vpliva na izhod, kar povečuje njeno prilagodljivost, uporabniku pa daje občutek večje kredibilnosti in da lahko rezultatom zaupa. Kljub temu je potrebno poudariti, da so parametrične metrike teoretično opisane in predstavljene, praktičnih implementacij v komercialnih orodij pa še ni zaslediti. Zgodovina metrik nas uči, da kljub generalnim metrikam, obstaja potreba po metrikah, ki so specifično namenjene za določena podjetja in njihove vnose podatkov zaradi večje natančnosti, ustreznosti in prilagodljivosti. Velikokrat se podjetja ne zavedajo njihove pomembnosti. 54

65 8 Literatura [1] Software Quality Metrics. [online]. Dostopno na: [ ] [2] Bijay Jayaswal & Peter Patton. Software Quality Metrics. [online]. [ ] [3] Software metrics and measurement. [online]. [ ] [4] Software Metrics. [online]. [ ] [5] Software metric. [online]. [ ] [6] Zgubič, Matej Statični analizator za preverjanje kvalitete programske kode: Diplomsko delo [online]. Maribor. [Citirano 14. apr. 2016; 22.15]. Dostopno na spletnem naslovu: [7] Radjenović, Danijel Ogrodje za napovedovanje napak programske opreme v agilnih okoljih: Doktorska disertacija [online]. Maribor. [Citirano 15. apr. 2016; 20.25]. Dostopno na spletnem naslovu: [8] Norman E. Fenton. Software Metrics: Successes, Failures and New Directions. London: Centre for Software Reliability City University, Northampton Square, [9] Software Quality Metrics Overview. [online]. [ ] [10] Norman E. Fenton _blue/.[ ] [11] Cyclomatic complexity. [ ] 55

66 [12] Alex Boughton. Software Metrics, Dostopno na spletnem naslovu: [ ] [13] Andreas Rau, Steinbeis Transferzentrum Softwaretechnik. Dostopno na spletnem naslovu: A Whitepaper on Metrics. [ ] [14] Cem Kaner, Walter P. Bond. Software Engineering Metrics: What Do They Measure And How Do We Know. Dostopno na spletnem naslovu: o_they_measure_and_how_do_we_know. [ ] [15] Fundamentals & Introduction of Function Point Analysis. Dostopno na spletnem naslovu: [ ] [16] Function point. Dostopno na naslovu: [ ] [17] Daniel Rodriguez, Rachel Harrison. An Overview of Object-Oriented Design Metrics Dostopno na spletnem naslovu: [ ] [18] Seyyed Mohsen Jamali. Object Oriented Metrics. Department of Computer Engineering Sharif University of Technology, Tehran Iran, Dostopno na spletnem naslovu: df. [ ] [19] K.K.Aggarwal, Yogesh Singh, Arvinder Kaur, Ruchika Malhotra. Empirical Study of Object-Oriented Metrics. School of Information Technology, GGS Indraprastha University, Delhi , India Dostopno na spletnem naslovu: [ ] [20] Aman Kumar Sharma, Arvind Kalia, Hardeep Singh. Metrics Identification for Measuring Object Oriented Software Quality. International Journal of Soft Computing and Engineering (IJSCE). ISSN: , Volume-2, Issue-5, November 2012 [Citirano 11. maj 2016; 18:00] [21] Microsoft Visual Studio. Dostopno na spletnem naslovu: [ ] 56

67 [22] MOOD and MOOD2 metrics. Dostopno na spletnem naslovu: [ ] [23] Muktamyee Sarker An overview of Object Oriented Design Metrics. Master Thesis [online]. Department of Computer Science, Umeå University, Sweden. [Citirano 10. maj 2016; 16:45]. [24] Tobias Mayer & Tracy Hall. Measuring OO Systems: A Critical Analysis of the MOOD Metrics. Centre for Systems and Software Engineering (CSSE). South Bank University, London, UK. [Citirano 12. maj 2016; 14:00]. [25] Amandeep Kaur, Satwinder Singh, Dr. K. S. Kahlon and Dr. Parvinder S. Sandhu. Empirical Analysis of CK & MOOD Metric Suit. International Journal of Innovation, Management and Technology, Vol. 1, No. 5, December [Citirano 12. maj 2016; 18:00]. [26] GQM. Dostopno na spletnem naslovu: [ ] [27] Introduction and Implementation of Total Quality Management (TQM). Dostopno na spletnem naslovu: [ ] [28] Survey on Impact of Software Metrics on Software Quality. Mrinal Singh Rawat, Arpita Mittal, Sanjay Kumar Dubey. International Journal of Advanced Computer Science and Applications, Vol. 3, No. 1, Dostopno na spletnem naslovu: Survey%20on%20Impact%20of%20Software%20Metrics%20on%20Software%20Qua lity.pdf [ ] [29] Parametric Software Metric. Won Shin, Tae-Wan Kim, Doo-Hyun Kim, Chun- Hyon Chang. Software Engineering and Computer Systems. [30] Defect Density. Dostopno na spletnem naslovu: [ ] [31] Product Based Software Metrics: A Review. P.Jha, K.S. Patnaik. 1Department of Computer Science and Engineering Birla Institute of Technology, Mesra, Ranchi India. [32] Using Neural Networks In Software Metrics. Ion I. Bucur, Nicolae Begnescu. University Politehnica of Bucharest. 57

68 [33] Software Measurement and Software Metrics in Software Quality. Ming-Chang Lee, To Chang. National Kaohsiung University of Applied Science, Taiwan. International Journal of Software Engineering and Its Applications, Vol. 7, No. 4, July, 2013 [34] Dynamic Metrics are Superior than Static Metrics in Maintainability Prediction : An Empirical Case Study. Hemlata Sharma, Anuradha Chug. IT, Lal Bahadur Shastri Institute of Management, New Delhi, India [35] Software Metrics: Roadmap. Norman E Fenton, Martin Neil. Computer Science Department, Queen Mary and Westfield College, London E1 4NS, UK [36] Software Engineering and Testing: an introduction. B B Agarwal, S P Tayal, M Gupta. Sudbury, Mass. : Jones and Bartlett, [37] MTBF, MTTR, MTTF & FIT Explanation of Terms. Dostopno na spletnem naslovu: FIT.pdf, [ ] [38] Software Reliability. Bruce R. Maxim, UM-Dearborn. Dostopno na spletnem naslovu: wixtcn6jiznahwexrqkhyc2dr0qfggqmae&url=http%3a%2f%2fgroups.engin.umd.umich.edu%2fcis%2fcourse.des%2fcis376%2fppt%2flec10.ppt&usg=afqjc NEihUJofAhTH_B0oK5CjOge8a78Yw&sig2=DPoBY2mgzphkCuczkLWJg&cad=rja, [ ] [39] DSQI (Design Structure Quality Index). Dostopno na spletnem naslovu: [ ] [40] Weighted Micro Function Points. Dostopno na spletnem naslovu: [ ] [41] Weighted Micro Function Points (WMFP). Dostopno na spletnem naslovu: [ ] [42] HOW TO INTERPRET RECEIVED METRICS RESULTS?. Dostopno na spletnem naslovu: [ ] [43] Code Metrics Values. Dostopno na spletnem naslovu: [ ] 58

69 [44] Object-Oriented Function Points: An Empirical Validation. Giuliano Antoniol, Roberto Fiutem, Chris Lokan Kluwer Academic Publishers. Manufactured in The Netherlands. [ ] [45] A design of software metric tool for improving reliability and usability. Won Shin, Tae-Wan Kim, Doo-Hyun Kim, and Chun-Hyon Chang. [ ] [46] A Probabilistic Software Risk Assessment and Estimation Model for Software Projects. Chandan Kumar and Dilip Kumar Yadav. Department of Computer Applications, National Institute of Technology Jamshedpur, Jharkhand , India [ ] [47] Korelacija. [online]. Dostopno na: [ ] 59

70 60

71 61