inovativne metrike programske opreme · pred samim razvojem in testiranjem smo si pogledali...

Nejc Muršič

INOVATIVNE METRIKE

PROGRAMSKE OPREME

Magistrsko delo

Maribor, julij 2016

Inovativne metrike programske opreme

INOVATIVNE METRIKE PROGRAMSKE OPREME

Magistrsko delo

Študent: Nejc Muršič

Študijski program: Študijski program 2. stopnje

Računalništvo in informatika

Smer: Računalništvo in informacijske tehnologije

Mentor: red. prof. dr. Peter Kokol

Somentor:

Lektor Žiga Oset, mag.


i


i

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.


ii

INOVATIVNE METRIKE PROGRAMSKE OPREME

Ključne besede: metrike programske opreme, kakovost programske opreme, testiranje,

inovativne metrike

UDK: 004.412(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.


iii

INOVATIVE SOFTWARE METRICS

Key words: software metrics, software quality, testing, innovative software metrics

UDK: 004.412(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.


i

KAZALO VSEBINE

1 Uvod .............................................................................................................................. 1

2 Metrike programske opreme .......................................................................................... 3

2.1 Zgodovina in razvoj metrik..................................................................................... 6

3 Inovativne metrike programske opreme ...................................................................... 19

3.1 Parametrična metrika programske opreme ........................................................... 19

3.1.1 Demonstracija parametrične metrike na primeru .......................................... 23

3.1.2 Lastnosti parametrične metrike ...................................................................... 26

3.2 Weighted Micro Function Points .......................................................................... 26

3.2.1 Lastnosti WMFP ............................................................................................ 28

3.3 BBN ...................................................................................................................... 29

4 Praktična analiza .......................................................................................................... 32

4.1 Uporabljene tehnologije ........................................................................................ 32

4.2 Omejitve in predpostavke ..................................................................................... 35

4.3 Implementacija aplikacije ..................................................................................... 36

5 Rezultati ....................................................................................................................... 45

6 Sklep in nadaljnje delo................................................................................................. 52

7 Zaključek ..................................................................................................................... 54

8 Literatura...................................................................................................................... 55


ii

KAZALO SLIK

Slika 2.1: Primer Control flow grafa enostavnega programa [11]......................................... 8

Slika 3.1: Arhitektura parametrične metrike (Vir: [45]) ...................................................... 21

Slika 3.2: Del kode mehurčnega urejanja ............................................................................ 23

Slika 3.3: Defects BBN (posplošeno) [35] .......................................................................... 29

Slika 4.1: Microsoft Visual Studio 2015 IDE (vir: [21]) ..................................................... 33

Slika 4.2: Prikaz različne kvalitete programske kode v VS 2015........................................ 34

Slika 4.3: Primer vgrajenih metrik programa VS 2015 ....................................................... 35

Slika 4.4: GUI lastne aplikacije ........................................................................................... 36

Slika 4.5: Struktura aplikacije.............................................................................................. 38

Slika 4.6: Struktura razreda CSharp v mapi LanguageDefinitions ...................................... 40

Slika 4.7: Filtriranje datotek projekta .................................................................................. 41

Slika 4.8: Primer izvoza podatkov v Excel formatu ............................................................ 41

Slika 4.9: Algoritem računanje metrik velikosti .................................................................. 42

Slika 4.10: Algoritem računanja parametrične metrike ....................................................... 43

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

Slika 5.1: Korelacija med PSM 3 in ostalimi metrikami ..................................................... 51


iii

KAZALO TABEL

Tabela 2.1: Tabela nekaj testnih metrik (Vir: [33]) ............................................................... 9

Tabela 2.2: Objektno orientirane metrike [19] [34]............................................................. 14

Tabela 3.1: Različni tipi metrike LOC (Vir: [29]) ............................................................... 22

Tabela 3.2. Vrednosti segmentiranih atributov za mehurčno urejanje (Vir: [29]) .............. 24

Tabela 3.3: Število napak ter meja izdaje in stabilnosti ...................................................... 24

Tabela 3.4: Rezultati eksperimenta cilja 1........................................................................... 25

Tabela 3.5: Rezultati eksperimenta cilja 2........................................................................... 25

Tabela 5.1: Rezultati analize programske opreme z razvojnim okoljem VS 2015 ............. 45

Tabela 5.2: Primer metod s slabšo kvaliteto programske kode ........................................... 47

Tabela 5.3: Rezultati analize programske opreme z implementacijo parametrične metrike 48

Tabela 6.1: Rezultati parametrične metrike ......................................................................... 52


iv

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

Inovativne metrike p rogramske opreme Nejc Muršič

1

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


2

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.


3

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.


4

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. Implementac ija

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

METRIKE

Projektne

Procesne Produktne

Projektne / Metrike virov

Načrtne

Tradicionalne

SLOC CP

Metrike kompleksnosti

Itd...

Objektno orientirane

CK MOOD

Itd...


5

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 organizac ij i

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.


6

• 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


7

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]

𝐶 = 𝐸 − 𝑁 + 2𝑃

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]

𝐶 = 𝐸 − 𝑁 + 𝑃


8

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 funkcionalnos t i

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.


9

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čilnos t i

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)

Uporablja se za ugotavljanje

produktivnosti testnih primerov

Število pripravljenih testov

/ porabljen napor za teste

Defect Acceptance

(DA)

Ugotavlja število veljavnih

napak najdenih v času testiranja

Število veljavnih

napak(defektov) / število

vseh napak * 100%

Defect Rejection (DR) Ugotavlja število zavrnjenih

napak v času izvajanja

Število zavrnjenih napak /

število vseh napak * 100%


10

Bad Fix Defect (B)

Uporablja se za ugotavljanja

učinkovitosti procesa

popravljanja napak

Število napačno

popravljenih napak /

število vseh napak * 100%

Test case defect density Uporablja se za ugotavljanja

učinkovitosti testnih primerov

Število spodletelih testnih

primerov / Število

izvedenih testnih primerov

* 100

Test Efficiency (TE)

Ugotavlja učinkovitost testne

skupine pri ugotavljanju in

iskanju napak

(DT/(DT+DU)*100

Test Effectiveness

Prikazuje razmerje med številom

napak najdenih v fazi testiranja

in vsemi napakami programske

opreme

(DT/(DF+DU)*100

Test improvement (TI)

Prikazuje razmerje med številom

najdenih napak in velikostjo

programske opreme

Število najdenih napak /

število vrstic izvorne kode

Test time over

development time (TD)

Prikazuje razmerje med časom

porabljenim za testiranje in

časom porabljenim za razvoj.

Število delovnih dni,

namenjenih za testiranje /

število delovnih dni

namenjenih za razvoj

Cost per defect unit

Prikazuje razmerje med

porabljenim denarjem za

testiranje in najdenih napakah

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.


11

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 razuml j ive

objekte. Nekatere dosedanje tradicionalne metrike so bile koristne pri OO paradigmah,

vendar pa so neuspešne pri merjenju značilnostih OO programiranja, kot so enkapsulac ija,

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.


12

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 hierarhij i

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.


13

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.


14

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 Number of Attributes per Class

(NOA) Razred Henderson, 1996

Dinamična Number of Methods per Class

(NOM) Razred Henderson, 1996

Statična,

dinamična

Weighted Methods per Class

(WMC) Razred Chidamber, 1994

Statična Coupling between Objects

(CBO) Sklopljenost Chidamber, 1994

Statična Data Abstraction Coupling

(DAC) Sklopljenost Henderson, 1996

Statična Message Passing Coupling

(MPC) 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 Information based Cohesion

(ICH) Kohezija Lee, 1995

Statična Method Hiding Factor (MHF) Skrivanje

informacij Harrison, 1998

Statična Attribute Hiding Factor (AHF) Skrivanje

informacij Harrison, 1998


15

Statična,

dinamična Number of Children (NOC) Dedovanje Chidamber, 1994

Statična Depth of Inheritance (DIT) Dedovanje Chidamber, 1994

Statična Method Inheritance Factor

(MIF) Dedovanje Harrison, 1998

Statična Attribute Inheritance Factor

(AIF) Dedovanje Harrison, 1998

Statična

Number of Methods Overridden

by a

subclass (NMO)

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


16

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 razvija lca

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činkovito st

(performance), zanesljivost (reliability), namestitev (installability), vzdrževanje


17

(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:


18

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, data-

flow 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:

𝐷𝑆𝑄𝐼 = 𝑆𝑈𝑀(𝑤𝑖𝐷𝑖)

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]


19

3 Inovativne metrike programske opreme

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 rezultat i

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. Prilagodlj ivi

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]


20

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]

Graf 3.2: Koncept parametrične metrike programske opreme (Vir: [29])

Atributi Metrika Rezultati

Segmentirani

atributi

Parametrična

metrika Rezultati

Uporabniški cilji


21

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.


22

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 Število vrstic s komentarji

NCLOC Število vrstic kode brez

komentarjev

BLOC Število praznih vrstic

LSLOC Število vrstic, ki vsebujejo

več ločenih ukazov

DLOC Š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]

𝐷𝐷𝑀 =

š𝑡𝑒𝑣𝑖𝑙𝑜 𝑛𝑎𝑝𝑎𝑘 𝑣 𝐶

𝑣𝑒𝑙𝑖𝑘𝑜𝑠𝑡 𝐶 ( 1 )

Kot prej omenjeno, lahko C izrazimo z LOC, ker je del programske kode fiksen. LOC lahko

nato še nadalje razdelimo in dobimo formulo:

𝑣𝑒𝑙𝑖𝑘𝑜𝑠𝑡 𝐶 = 𝐶𝐿𝑂𝐶 + 𝑁𝐶𝐿𝑂𝐶 ( 2 )

V primeru, če koda ne vsebuje vrstic s komentarji in praznih vrstic, se formula glasi:


23

𝑣𝑒𝑙𝑖𝑘𝑜𝑠𝑡 𝐶 = 𝑁𝐶𝐿𝑂𝐶 − 𝐵𝐿𝑂𝐶 ( 3 )

V primeru če koda vsebuje samo vrstice z izvršljivo oziroma izvorno kodo (SLOC),

uporabimo spodnjo formulo:

𝑣𝑒𝑙𝑖𝑘𝑜𝑠𝑡 𝐶 = 𝑁𝐶𝐿𝑂𝐶 − 𝐵𝐿𝑂𝐶 − 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:

3.1.1 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

𝐷𝐷𝑀 =

𝑃𝑅𝐸𝐹

𝑁𝐶𝐿𝑂𝐶 − 𝐵𝐿𝑂𝐶 − 𝐿𝑆𝐿𝑂𝐶 − 𝐷𝐿𝑂𝐶 ( 5 )


24

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 23 97

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 stabilnos t i

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.


25

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 0.0390625

2 3 O O O 0.0609756

3 4 O O O O O 0.0877193

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 0.015625

5 3 O O O 0.0243902

6 4 O O O O O 0.0350877

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.


26

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.

3.1.2 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 prilagodljivos t i

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.


27

Object vocabulary (OV) meri količino unikatnih informacij, ki jih vsebuje izvorna

koda programa, podobno kot Halstead-ova metrika in z uporabo kompenzac ije

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]

Graf 3.3: Faze algoritma WMFP

WMFP APPW Rezultat

UTEŽI

DT

CS

ID

CM

FC


28

Dinamičen algoritem uravnoteži seštevek merjenih elementov oziroma različnih metrik.

Osnovna formula je:

∑(𝑊𝑖𝑀𝑖) ∏ 𝐷𝑞

𝐾

𝑞=1

𝑁

𝑖=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.

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


29

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]


30

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 kombinac ijo

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:

P (R|S) =P (S|R)𝑃(𝑅)

P(S)

kjer sta A in B dogodka in P(B) ≠ 0.

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


31

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]


32

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činkovito st

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]


33

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 2015. 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ževa ti,

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:

𝐼𝑉 = max (0, 171 − 5.2 × log(𝐻𝑉) − 0.23 × (CC) − 16.2 × log(𝐿𝑂𝐶) × 100 ÷ 171),


34

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: https://blogs.msdn.microsoft.com/codeanalysis/2007/10/03/new-for-visual-studio-2008-code-

metrics/)

https://blogs.msdn.microsoft.com/codeanalysis/2007/10/03/new-for-visual-studio-2008-code-metrics/

https://blogs.msdn.microsoft.com/codeanalysis/2007/10/03/new-for-visual-studio-2008-code-metrics/


35

Slika 4.3: Primer vgrajenih metrik programa VS 2015

4.2 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


36

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:


37

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


38

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


39

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,


40

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


41

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,


42

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


43

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


44

Slika 4.11: Primer prikaza rezultatov metrik za posamezni projekt


45

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 2015. Za

izračun povprečne ciklomatične kompleksnosti smo uporabili prosto dostopni odprtokodni

program LocMetrics, ki je dostopen na povezavi http://www.locmetrics.com/. 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

1 2048 69 53 7,57 7 45 215 1

2 Base62 73 44 6,5 3 9 122 1

3 CacheDB 89 220 4,8 2 50 300 2

4 CBCrypt 76 61 7 1 28 153 1

5 ChecksumValidator

80 178 10,6 7 103 712 3

6 C-Sharp

Algorithms 68 663 17,45 1 55 1330 3

7 DeeTree 88 133 5,63 2 35 228 0

8 Evernote-sdk-csharp

83 7785 59,83 2 476 25727 10

9 fastJSON 83 682 35 2 93 1319 14

10 Filewalker 73 241 6,24 7 123 922 5

http://www.locmetrics.com/


46

11 GitPad 91 30 11,5 1 27 76 14

12 GitVersionTree 70 66 7,14 7 48 373 7

13 Grease 86 232 2,4 10 128 387 2

14 HTMLMinifier 72 55 6,4 1 26 112 17

15 HtmlSanitizer 92 213 10,43 3 76 305 41

16 ImageGlass 64 615 13 7 189 3631 34

17 libVideo 86 380 6,6 2 75 551 17

18 LinqToExcel 84 519 10,86 3 144 857 72

19 MailChimp.NET 93 2033 1,06 2 259 2348 18

20 MathNet-Spatial 78 980 23,63 4 108 2226 24

21 Metrics.NET 83 2234 7,71 4 464 3692 50

22 Music Player 77 77 2,18 7 50 331 3

23 PowerForensics 77 1774 9,69 4 267 4914 43

24 QRCoder 83 485 27,8 2 89 1007 10

25 RadixTree-master 70 69 10,25 1 6 125 0

26 ReportGenerator 73 1418 9,35 2 247 2470 14

27 ScreenCapture 79 311 7,68 7 95 1065 1

28 SidebarDiagnostics

88 2196 25,86 12 295 3578 92

29 SimulatedAnneali

ng 61 437 12,41 7 92 1945 4

30 Slikar C# 63 254 9,4 7 69 1495 29

31 SmartFormat.NET 78 1387 10,83 2 117 1414 46

32 SteamCleaner 79 317 4,49 9 138 552 27

33 SuperBenchmarker

77 228 7,14 2 140 462 10

34 TinyMapper 83 551 5,92 3 147 1004 16

35 TotalUninstaller 84 107 4 10 72 187 8


47

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 29 64 7

QRCoder

CreateQrCode(string,

QRCodeGenerator.ECCLevel, bool) : QRCodeData

30 19 19

Slikar C# InitializeComponent() : void 12 1 2

ImageGlass InitializeComponent() : void 11 1 45

GitVersionTree Generate() : void 24 30 11

SimulatedAnnealing InitializeComponent() : void 20 1 25

SimulatedAnnealing panel_Paint(object, PaintEventArgs) : void

26 28 13

ChecksumValidator InitializeComponent() : void 21 1 29

ChecksumValidator

BuildExceptionReport(string, string,

string, Exception, StringBuilder) : StringBuilder

24 27 17

SidebarDiagnostics InitCPU(IHardware, MetricConfig[], bool, bool, bool, bool, double) : void

26 65 16

SidebarDiagnostics SettingsModel(Sidebar) 25 50 28


48

fastJSON ParseDictionary(Dictionary<string, object>, Dictionary<string, object>,

Type, object) : object

29 46 19

SuperBenchmarker Main(string[]) : void 23 29 51

Music Player InitializeComponent() : void 27 1 21

PowerForensics BinXmlTemplateInstanceData(byte[], int, int)

23 50 9

SmartFormat.NET GetPluralRule(string) :

PluralRules.PluralRuleDelegate 0 481 4

Evernote-sdk-csharp Read(TProtocol) : void 17 67 5

Evernote-sdk-csharp Write(TProtocol) : void 16 48 8

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



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

1 2048 0 0 0 0 215

2 Base62 0,002915452 0,004048583 0,008 1 122

3 CacheDB 0,0003773585 0,000555093 0,001001001 2 300

4 CBCrypt 0,001945525 0,002932551 0,007751938 1 153

5 ChecksumValidator

0,0008185539 0,001152074 0,002923977 3 712

6 C-Sharp Algorithms

0,000108503 0,0001777567 0,0003301783 3 1330

7 DeeTree 0 0 0 0 228

8 Evernote-sdk-csharp

0,0001814849 0,0001990406 0,0003390635 10 25727


49

9 fastJSON 0,004662005 0,005804312 0,01208981 14 1319

10 Filewalker 0,00148368 0,002596054 0,00618047 5 922

11 GitPad 0,03517588 0,05714286 0,1029412 14 76

12 GitVersionTree 0,008684863 0,01075269 0,02447552 7 373

13 Grease 0,000660502 0,00137836 0,002728513 2 387

14 HTMLMinifier 0,04260652 0,07834101 0,1504425 17 112

15 HtmlSanitizer 0,0375802 0,07765152 0,154717 41 305

16 ImageGlass 0,004264927 0,005833905 0,01748971 34 3631

17 libVideo 0,007212558 0,008966245 0,02228047 17 551

18 LinqToExcel 0,02589928 0,03817603 0,0750782 72 857

19 MailChimp.NET 0,001465082 0,002538787 0,003729024 18 2348

20 MathNet-Spatial 0,003455226 0,005367927 0,01141227 24 2226

21 Metrics.NET 0,004701016 0,006028454 0,01300728 50 3692

22 Music Player 0,004304161 0,005617978 0,01492537 3 331

23 PowerForensics 0,002419095 0,003195342 0,007254554 43 4914

24 QRCoder 0,004798464 0,005506608 0,0118624 10 1007

25 RadixTree-master 0 0 0 0 125

26 ReportGenerator 0,001608271 0,002688688 0,005335366 14 2470

27 ScreenCapture 0,0003159558 0,0004599816 0,0009823183 1 1065

28 SidebarDiagnostics

0,007969508 0,01048792 0,01744406 92 3578

29 SimulatedAnnealing

0,001126443 0,001299123 0,003333333 4 1945

30 Slikar C# 0,009440104 0,01147606 0,03068783 29 1495

31 SmartFormat.NET

0,01040959 0,01495935 0,03476946 46 1414

32 SteamCleaner 0,016081 0,01921708 0,03585657 27 552

33 SuperBenchmarker

0,009066183 0,0105042 0,02070393 10 462

34 TinyMapper 0,00310559 0,003670567 0,006993007 16 1004

35 TotalUninstaller 0,01428571 0,01785714 0,02919708 8 187


50

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:

𝐶𝑂𝑅𝑅𝐸𝐿(𝑋, 𝑌) =∑(𝑥 − �̅�)(𝑦 − �̅�)

√∑(𝑥 − �̅�)2 ∑(𝑦 − �̅�)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.


51

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.


52

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,01 18


53

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 kvalitete in 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 le-

teh.

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.


54

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.


55

8 Literatura

[1] Software Quality Metrics. [online]. Dostopno na:

http://it.toolbox.com/wiki/index.php/Software_Quality_Metrics [12. 4. 2016]

[2] Bijay Jayaswal & Peter Patton. Software Quality Metrics. [online].

http://www.developer.com/tech/article.php/3644656/Software-Quality-Metrics.htm.

[10. 4. 2016]

[3] Software metrics and measurement. [online].

https://en.wikiversity.org/wiki/Software_metrics_and_measurement. [11. 4. 2016]

[4] Software Metrics. [online]. http://www.sqa.net/softwarequalitymetrics.html. [2. 4.

2016]

[5] Software metric. [online]. https://en.wikipedia.org/wiki/Software_metric. [2. 4. 2016]

[6] Zgubič, Matej. 2015. Statični analizator za preverjanje kvalitete programske kode:

Diplomsko delo [online]. Maribor. [Citirano 14. apr. 2016; 22.15]. Dostopno na

spletnem naslovu: https://dk.um.si/IzpisGradiva.php?id=54086&lang=slv.

[7] Radjenović, Danijel. 2013. Ogrodje za napovedovanje napak programske opreme v

agilnih okoljih: Doktorska disertacija [online]. Maribor. [Citirano 15. apr. 2016; 20.25].

Dostopno na spletnem naslovu: https://dk.um.si/IzpisGradiva.php?id=43019.

[8] Norman E. Fenton. Software Metrics: Successes, Failures and New Directions.

London: Centre for Software Reliability City University, Northampton Square, 1999.

[9] Software Quality Metrics Overview. [online].

https://www.pearsonhighered.com/samplechapter/0201729156.pdf. [15. 4. 2016]

[10] Norman E. Fenton.

http://www.eecs.qmul.ac.uk/~norman/Courses/mod_903/slides/slides_2000/all_slides_

2000_blue/.[18.4.2016]

[11] Cyclomatic complexity. https://en.wikipedia.org/wiki/Cyclomatic_complexity. [18.

4. 2016]

http://it.toolbox.com/wiki/index.php/Software_Quality_Metrics

http://www.developer.com/tech/article.php/3644656/Software-Quality-Metrics.htm

https://en.wikiversity.org/wiki/Software_metrics_and_measurement

http://www.sqa.net/softwarequalitymetrics.html

https://en.wikipedia.org/wiki/Software_metric

https://dk.um.si/IzpisGradiva.php?id=54086&lang=slv

https://dk.um.si/IzpisGradiva.php?id=43019

https://www.pearsonhighered.com/samplechapter/0201729156.pdf

http://www.eecs.qmul.ac.uk/~norman/Courses/mod_903/slides/slides_2000/all_slides_2000_blue/.%5b18.4.2016

http://www.eecs.qmul.ac.uk/~norman/Courses/mod_903/slides/slides_2000/all_slides_2000_blue/.%5b18.4.2016

https://en.wikipedia.org/wiki/Cyclomatic_complexity


56

[12] Alex Boughton. Software Metrics, Dostopno na spletnem naslovu:

https://www.cs.colorado.edu/~kena/classes/5828/s12/presentation-

materials/boughtonalexandra.pdf. [23. 3. 2016]

[13] Andreas Rau, Steinbeis Transferzentrum Softwaretechnik. Dostopno na spletnem

naslovu: A Whitepaper on Metrics. http://www.it.fht-

esslingen.de/~rau/forschung/metrics.htm. [19. 4. 2016]

[14] Cem Kaner, Walter P. Bond. Software Engineering Metrics: What Do They

Measure And How Do We Know. Dostopno na spletnem naslovu:

http://maisqual.squoring.com/wiki/index.php/Software_Engineering_Metrics:_What_D

o_They_Measure_And_How_Do_We_Know. [19. 4. 2016]

[15] Fundamentals & Introduction of Function Point Analysis. Dostopno na spletnem

naslovu: http://www.softwaremetrics.com/fpafund.htm. [19. 4. 2016]

[16] Function point. Dostopno na naslovu: https://en.wikipedia.org/wiki/Function_point.

[18. 4. 2016]

[17] Daniel Rodriguez, Rachel Harrison. An Overview of Object-Oriented Design

Metrics. 2001. Dostopno na spletnem naslovu:

http://www.cc.uah.es/drg/b/RodHarRama00.English.pdf. [20. 4. 2016]

[18] Seyyed Mohsen Jamali. Object Oriented Metrics. Department of Computer

Engineering Sharif University of Technology, Tehran Iran, 2006. Dostopno na

spletnem naslovu:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.159.8788&rep=rep1&type=p

df. [10. 4. 2016]

[19] K.K.Aggarwal, Yogesh Singh, Arvinder Kaur, Ruchika Malhotra. Empirical Study

of Object-Oriented Metrics. School of Information Technology, GGS Indraprastha

University, Delhi 110006, India. 2006. Dostopno na spletnem naslovu:

http://www.jot.fm/issues/issue_2006_11/article5.pdf. [20. 4. 2016]

[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: 2231-2307, Volume-2, Issue-5, November 2012

[Citirano 11. maj 2016; 18:00]

[21] Microsoft Visual Studio. Dostopno na spletnem naslovu:

https://en.wikipedia.org/wiki/Microsoft_Visual_Studio. [28. 04. 2016]

https://www.cs.colorado.edu/~kena/classes/5828/s12/presentation-materials/boughtonalexandra.pdf

https://www.cs.colorado.edu/~kena/classes/5828/s12/presentation-materials/boughtonalexandra.pdf

http://www.it.fht-esslingen.de/~rau/forschung/metrics.htm

http://www.it.fht-esslingen.de/~rau/forschung/metrics.htm

http://maisqual.squoring.com/wiki/index.php/Software_Engineering_Metrics:_What_Do_They_Measure_And_How_Do_We_Know

http://maisqual.squoring.com/wiki/index.php/Software_Engineering_Metrics:_What_Do_They_Measure_And_How_Do_We_Know

http://www.softwaremetrics.com/fpafund.htm

https://en.wikipedia.org/wiki/Function_point

http://www.cc.uah.es/drg/b/RodHarRama00.English.pdf

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.159.8788&rep=rep1&type=pdf

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.159.8788&rep=rep1&type=pdf

http://www.jot.fm/issues/issue_2006_11/article5.pdf

https://en.wikipedia.org/wiki/Microsoft_Visual_Studio


57

[22] MOOD and MOOD2 metrics. Dostopno na spletnem naslovu:

http://www.aivosto.com/project/help/pm-oo-mood.html. [02. 05. 2016]

[23] Muktamyee Sarker. 2015. 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 2010. [Citirano 12. maj 2016;

18:00].

[26] GQM. Dostopno na spletnem naslovu: https://en.wikipedia.org/wiki/GQM [22. 05.

2016]

[27] Introduction and Implementation of Total Quality Management (TQM). Dostopno

na spletnem naslovu: https://www.isixsigma.com/methodology/total-quality-

management-tqm/introduction-and- implementation-total-quality-management-tqm/

[22. 05. 2016]

[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, 2012. Dostopno na spletnem naslovu:

https://thesai.org/Downloads/Volume3No1/Paper%2021-

Survey%20on%20Impact%20of%20Software%20Metrics%20on%20Software%20Qua

lity.pdf [24. 05. 2016]

[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:

http://softwaretestingfundamentals.com/defect-density/ [25. 05. 2016]

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

http://www.aivosto.com/project/help/pm-oo-mood.html

https://en.wikipedia.org/wiki/GQM

https://www.isixsigma.com/methodology/total-quality-management-tqm/introduction-and-implementation-total-quality-management-tqm/

https://www.isixsigma.com/methodology/total-quality-management-tqm/introduction-and-implementation-total-quality-management-tqm/

https://thesai.org/Downloads/Volume3No1/Paper%2021-Survey%20on%20Impact%20of%20Software%20Metrics%20on%20Software%20Quality.pdf



http://softwaretestingfundamentals.com/defect-density/


58

[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. 2015

[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, ©2010.

[37] MTBF, MTTR, MTTF & FIT Explanation of Terms. Dostopno na spletnem

naslovu: http://imcnetworks.com/wp-content/uploads/2014/12/MTBF-MTTR-MTTF-

FIT.pdf, [1.06.2016]

[38] Software Reliability. Bruce R. Maxim, UM-Dearborn. Dostopno na spletnem

naslovu:

https://www.google.si/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0ahUKE

wiXtcn6jIzNAhWExRQKHYc2DR0QFggqMAE&url=http%3A%2F%2Fgroups.engin

.umd.umich.edu%2FCIS%2Fcourse.des%2Fcis376%2Fppt%2Flec10.ppt&usg=AFQjC

NEihUJofAhTH_B0oK5CjOge8a78Yw&sig2=DPoBY2mgzp-

hkCuczkLWJg&cad=rja, [02. 06. 2016]

[39] DSQI (Design Structure Quality Index). Dostopno na spletnem naslovu:

http://logicalprogram.blogspot.si/p/dsqi.html, [02. 06. 2016]

[40] Weighted Micro Function Points. Dostopno na spletnem naslovu:

https://en.wikipedia.org/wiki/Weighted_Micro_Function_Points, [02. 06. 2016]

[41] Weighted Micro Function Points (WMFP). Dostopno na spletnem naslovu:

http://www.projectcodemeter.com/cost_estimation/help/GL_wmfp.htm, [03. 06. 2016]

[42] HOW TO INTERPRET RECEIVED METRICS RESULTS?. Dostopno na

spletnem naslovu: https://codemetricsviewer.wordpress.com/2011/06/26/how-to-

interpret-received-results/, [05. 06. 2016]

[43] Code Metrics Values. Dostopno na spletnem naslovu:

https://msdn.microsoft.com/en-us/library/bb385914.aspx, [05. 06. 2016]

http://imcnetworks.com/wp-content/uploads/2014/12/MTBF-MTTR-MTTF-FIT.pdf

http://imcnetworks.com/wp-content/uploads/2014/12/MTBF-MTTR-MTTF-FIT.pdf

https://www.google.si/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0ahUKEwiXtcn6jIzNAhWExRQKHYc2DR0QFggqMAE&url=http%3A%2F%2Fgroups.engin.umd.umich.edu%2FCIS%2Fcourse.des%2Fcis376%2Fppt%2Flec10.ppt&usg=AFQjCNEihUJofAhTH_B0oK5CjOge8a78Yw&sig2=DPoBY2mgzp-hkCuczkLWJg&cad=rja





http://logicalprogram.blogspot.si/p/dsqi.html

https://en.wikipedia.org/wiki/Weighted_Micro_Function_Points

http://www.projectcodemeter.com/cost_estimation/help/GL_wmfp.htm

https://codemetricsviewer.wordpress.com/2011/06/26/how-to-interpret-received-results/

https://codemetricsviewer.wordpress.com/2011/06/26/how-to-interpret-received-results/

https://msdn.microsoft.com/en-us/library/bb385914.aspx


59

[44] Object-Oriented Function Points: An Empirical Validation. Giuliano Antoniol,

Roberto Fiutem, Chris Lokan. 2003 Kluwer Academic Publishers. Manufactured in

The Netherlands. [10. 06. 2016]

[45] A design of software metric tool for improving reliability and usability. Won Shin,

Tae-Wan Kim, Doo-Hyun Kim, and Chun-Hyon Chang. [10. 06. 2016]

[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 831 014, India.

2015 [15. 07. 2016]

[47] Korelacija. [online]. Dostopno na: https://sl.wikipedia.org/wiki/Korelacija [22. 07.

2016]


60


61

inovativne metrike programske opreme · pred samim razvojem in testiranjem smo si pogledali...

Documents