Metrici Software

8/6/2019 Metrici Software

1/31

METRICI SOFTWARE

Ion Ivan

Mihai Popescu

Rezumat

Aprecierea sistemelor de programe este de ordin calitativ (bun,

satisfctor, foarte bun, nesatisfctor) i de ordin cantitativ, exprimat

numeric.

Problematica definirii unui sistem de msurare a calitii genereaz

diferite abordri, pe text surs i asupra comportamentului la utilizator

al programelor.

Metricile software nglobeaz modele, indicatori i proprietile

acestora, precum i modaliti de evaluare i validare. Lucrarea i

propune s prezinte concepte de baz, modele i modaliti de utilizare

a metricilor software.

Introducere

Conceptul de metric nu este nou. Se consider o mulime de puncte M pe care se

definete o aplicaie

d : M x MR

astfel nct:1. d ( x,y ) 0 i d ( x,y ) = 0

dac x = y

2. d ( x,y ) = d ( y,x ) (axioma simetriei)

3. d ( x,y ) d ( x,y ) + d ( y,z ) (inegalitatea triunghiului)


2/31

n [6] aplicaia d se constituie ntr-o metric a mulimii M. Aceast aplicaie se

mai numete i distana de la elementul x la elementul y; x,yM.

Lucrarea [38] prezint exemple de aplicaii precum:

d ( x,y ) = {

d ( x,y ) = | x - y |

Dac se consider:

x = (x1, x2, ..., xn)

y = (y1, y2, ..., yn)

se pot defini urmtoarele tipuri de distane:

d ( x,y ) = S ( yi - xi )2

d ( x,y ) = S | xi

- yi

|

d ( x,y ) = max | yi - xi |

Pentru x(t) i y(t) se definete distana:

d ( x,y ) = [ (x(t) - y(t))2 dt ]1/2

Exist conceptul de norm i se poate stabili o legtur ntre norm i metric

astfel:

norma distanei a dou elemente se definete ca o funcie de forma:

d ( x,y ) = || x - y ||

0 dac x = y1 dac x y

n

i=1

n

i=1

1 i n


3/31

n spaiul euclidian k-dimensional Rk se pot defini:

|| x || = S

|| x || = max | i |

|| x || = S | i |

iar norma are proprietile:

|| x || > 0 pentru x 0

|| x || = | | || x ||, C

|| x + y || || x || + || y ||

Se poate spune c i n domeniul ingineriei programrii (software engineering)

utilizarea conceptului de metrici (software metrics) este acceptabil.

Definirea de metrici software revine la a construi modele, indicatori care pornesc

de la mrimi ce se msoar cu obiectivitate (numr linii surs, numr erori, numr

variabile, numr instruciuni de Intrare/Ieire, numr funcii, numr parametrii transmii,

numr nivele ale arborelui asociat).

Practica arat c exist o strns legtur ntre comportamentul efectiv al unui

program i structura lui exprimat prin mrimi ce se determin exact, obiectiv.

Indicatorii (metricile software) se construiesc n aa fel nct valorile obinute

caracterizeaz produsul. Asfel, funcia:

f(x) : R [0,1], este pus n coresponden cu aprecieri asupra comportamentului

unui program astfel:-dac f(x) = 0 se va spune c programul este lipsit de calitate i exist riscuri

pentru utilizator n cazul folosirii;

-dac f(x) = 1 se va spune c programul are un nivel de calitate deosebit, deci

utilizatorul trebuie s aib ncredere n rezultatele obinute la execuia programului;

1 i k

k

i=1

k

i=1

2

i


4/31

-dac f(x) < 1, unde este o valoare numit prag de acceptare, obinut

experimental, programul poate fi utilizat, riscurile de obinere a rezultatelor eronate

fiind minore;

-dac 0 < f(x) < , frecvena cu care se obin rezultate incorecte este att de mare

inct eforturile de a utiliza un astfel de program se dovedesc ineficiente.

Se observ c o metric astfel conceput are rolul de a poziiona un program ntr-una din

dou categorii: program acceptabil a fi n uz curent i program imposibil de utilizat.

Dac se consider mulimea programelorP={P1,P2,...,Pm}i se construiete un indicator

de performan sau de caracterizare f(x):P N, exist posibilitatea de a compara

programele.

O astfel de funcie poate fi lungimea fiierului executabil. Comparaiile sunt

directe.

Dac f(Pi) > f(Pj) se va spune c programul Pi este mai mare sau mai lung sau c

ocup spaiu de stocare (memorie extern) mai mare dect programul Pj.

Sunt interesante i comparaiile directe de forma:

f: P x P N,

ca de exemplu:

f(Pi, Pj) = 100

Dac f(Pi, Pj) > 100 rezult c programul Pi este mai lung dect programul Pj.

Dac f(Pi, Pj) < 100 rezult c programul Pi este mai scurt dect programul Pj.

Spre deosebire de mulimea M definit la nceput, n care punctele sunt omogene,

este extrem de dificil de construit mulimi omogene de programe, condiie esenial

pentru realizarea de comparaii care s aib sens.

De aceea, metricile software sunt concepute ca programul s fie raportat prin el

nsui la modele ideale (f(x)=1 sau f(x)=0).Rolul metriciilor este de a reduce subiectivitatea aprecierii unui program.

Asemeni unitilor de msur din sistemul metric internaional, cei care i propun s

construiasc metrici software trebuie s parcurg urmtoarele etape:

- definirea mrimilor obiective care pot fi msurate fie n textul surs al

programului, fie pe durata utilizrii programului la beneficiar;

PiPj


5/31

- stabilirea metodologiei de nregistrare a mrimilor obiective i de constituire a

bazei de date asociate programului;

- elaborarea modelului sau modelelor n care mrimile obiective stabilite

figureaz ca variabile independente x1, x2, x3, ....xn i n care y, variabila rezultativ, va

releva comportamentul programului sau calitile acestuia;

- evaluarea unui nivel y0 pentru valori date x01 , x02, .....x0n din baza de date a

programului;

- ncadrarea programului n una din cele dou clase (program bun, acceptabil sau

program neacceptabil);

- nregistrarea comportamentului n timp al programului i compararea

rezultatelor obinute cu ceea ce a oferit (prezis) metrica la momentul iniial; n cazul n

care se evideniaz c metrica a prezis un comportament care este confirmat de realitate,are loc validarea metricii.

Metricile software se definesc pentru caracteristici de calitate (factori de calitate,

aa cum sunt definii n [37]).

n timp, s-a acordat o atenie deosebit complexitii software [17], [35] i

fiabilitii software [19], modelele asociate acestora constituindu-se i n veritabile

metrici.

Dei iniial un program este cotat bun sau nu, n realitate aprecierile sunt mainuanate.

Pentru o metric software definit f:P [a,b], a,bR+ i a b se vor identifica

mai multe valori critice (praguri) 1, 2 care permit aceast nuanare a delimitrii, cu

a


6/31

adic posibilitatea de a aplica formula (modelul) oricrui program n mod neambiguu.

Adic mrimile obiective trebuie att de riguros definite nct oricine are la dispoziie un

program Pi i metrica, s poat obine aceleai rezultate.

De exemplu, dac se consider:

n1 - numr de operanzi distinct;

n2 - numr de operatori distinct;

n3 - numr de definiii tipuri de date

i o msur a complexitii

C=n1 log1 n1 + n2 log2 n2 + n3 log3 n3

i se precizeaz c operanzii sunt:

- constante definite n program care particip n evaluri de expresii;

- variabile elementare;- variabile de tip derivat,

se obine un grad de obiectivitate acceptabil.

Nu se includ definirile de tip derivat ci numai variabilele care sunt nzestrate cu

proprietile acestor tipuri.

Prin operator se va nelege:

- instruciunile if, for, switch, goto, while, do;

- expresii de atribuire;- apeluri de funcii;

- evaluri de expresii.

Pentru o definire neambigu se iau n considerare toate elementele unui limbaj de

programare i se stabilesc regulile de contorizare la n1, la n2 sau la n3 a fiecrui element.

Aceasta nseamn c o metric este legat de un limbaj de programare anumit.

Este rezonabil ca definirile pentru diferite limbaje de programare s urmeze aceleai

reguli. n situaia n care, pentru rezolvarea aceleiai probleme, se scriu programe n

limbaje diferite de ctre programatori cu acelai nivel de performan, trebuie ca

diferenele obinute pentru aplicarea metricii s fie nesemnificative. Dac ipotezele de

construire i utilizare a unei metrici sunt judicios concepute exist reale posibiliti de a

utiliza metrica i mai ales de a aprecia programele prin prisma nivelelor date de calculul


7/31

respectivei metrici. Este important ca mrimile obiective din care deriv metrica s fie

uor de obinut. O metric costisitor de evaluat este abandonat uor.

Factori

Calitatea software este pus n eviden cu ajutorul unor modele asociate

caracteristicilor: mentenabilitate, corectitudine, portabilitate, fiabilitate, modularitate,

funcionalitate, lizibilitate, reutilizabilitate, liniaritate, robustee, toleran la erori,

interoperabilitate [1], generalitate.Fiecare caracteristic scoate n eviden anumite nsuiri ale softwareului. Astfel,

fiabilitatea reprezint capacitatea unui program de a fi utilizat fr a genera erori sau

capacitatea de a restabili un context anterior apariiei de erori.

Mentenabilitatea este nsuirea programului de a permite corecii,

introduceri/extrageri de secvene n vedera adaptrii la noi cerine impuse de schimbri

ale formulelor de calcul din algoritmi, a schimbrii dimensiunilor unor cmpuri i

modificrilor de utilizare echipamente.

Portabilitatea este proprietatea unui program de a fi executat pe alte tipuri de

calculatoare sau interacionnd cu alte sisteme de operare.

Corectitudinea pune n eviden msura n care produsul ndeplinete cerinele

definite prin specificaii. Se compar rezultatele (structural, completitudine, precizie)

obinute efectiv cu cele proiectate la realizarea specificaiilor folosind generatoare de

exemple de test. Corectitudinea se pune n eviden fie prin testri, fie prin demonstraie.

Realizarea programului ca ansamblu de module l nzestreaz cu capaciti

specifice de deschidere, de interconectare, asociate caracteristicii de modularitate.Tehnicile de programare avansate (programarea structurat, programarea orientat

obiect) determin construcii de secvene care uureaz nelegerea semnificaiei prilor

de program att n vederea depanrii, ct mai ales la testarea ce urmeaz unui proces de

dezvoltare software. Programul, ca produs final, este mai mult sau mai puin liniar, strict


8/31

dependent de traiectoriile pe care le au sensurile execuiei instruciunilor (apeluri de

funcii, instruciuni de control, instruciuni de salt necondiionat).

La scrierea unei proceduri/funcii se are n vedere posibilitatea reutilizrii n alte

programe ca singur modalitate de a economisi munc vie, cu efecte asupra creterii

productivitii n activitatea de programare.

Reutilizabilitatea este posibil n msura n care procedura/funcia este nzestrat

cu un nivel de generalitate suficient de ridicat. Adic nglobeaz posibiliti multiple de

prelucrare, inclusiv cazuri particulare.

Lizibilitatea este caracteristica programului de a conine suficiente informaii att

prin numele de variabile, etichete, funcii legate de semnificaia lor real, ct i

comentariile lmuritoare care preced secvene de cod.

Tolerana la erori, robusteea sunt nsuiri ale produselor software care au aceeaisemnificaie pe care o ntlnim la produse industriale sau la servicii.

Interoperabilitatea unui program este nsuirea acestuia de a putea fi apelat de alte

programe, de a fi integrat n aplicaii deja n uz sau de a utiliza baze de date existente n

mod direct sau prin elaborare de interfee.

Asemeni unui produs/serviciu industrial (de serie, de mas) utilizabilitatea unui

program revine la uurina de a nelege prelucrrile pe care le execut, facilitile cu care

este nzestart, uurina de introduce date i de a selecta opiuni, uurina de a nva lucrulcu respectivul program.

Eficiena unui program este pus n eviden prin raportarea consumurilor de

resurse i a cheltuielilor bneti pe care le antreneaz realizarea i utilizarea sa la alte

programe cu specificaii identice sau foarte apropiate.

Metricile software opereaz cu factori - n realitate caracteristici de calitate.

Fiecrei caracteristici i se asociaz modele de forma:

y = f(x1,x2, ....xn),

unde:

x1,x2, ...,xn - sunt variabile exogene;

y - este variabila endogen nivel al caracteristicii de calitate.

Variabilele exogene se construiesc n baza unui sistem de ipoteze de lucru care

difer de la model la model. Sunt cunoscute numeroasele modele de evaluare a


9/31

fiabilitii unui program (Musa, Jelinski Moranda, Poisson logaritmic, Goel Okumoto).

De asemenea, pentru evaluarea complexitii software s-au construit numeroase modele

(Halstead, Mc Cabe).

Metricile schimb modul de interpretare, n sensul realizrii unor relaii (modele,

indicatori) care evalueaz nivelul caracteristicii de calitate, urmrind simultan i

posibilitatea de a-l integra n subintervale de acceptabilitate/inacceptabilitate.

Aa se explic faptul c n zona metricilor sofware se operez cu factorii:

eficien, funcionalitate, mentenabilitate, portabilitate, fiabilitate i cu subfactorii asociai

[10], tabelul nr. 1.

TABELUL NR.1

FACTORI SUBFACTORI

economie de timp

economie de resurseEFICIEN

securitatecompatibilitateinteroperabilitate

corectitudine

completitudine

FUNCIONALITATE

expandabilitatecapacitate de a corecta

test abilitate

MENTENABILITATE

PORTABILITATE

tolerane la erori

nondeficien - gradul n care nuconin erori nedetectabile

disponibilitateFIABILITATE

instabilitate

independen

reutilizabilitate

hardware

software


10/31

Pentru fiecare factor i pentru subfactorii si se constituie diagrame de legtur

care conduc spre metrici software acceptabile, figura 1.

Problema construirii metricilor este de fapt o problem a agregrii de informaii.

Rezultatul final este o mrime n general adimensional obinut dintr-o ecuaie

de forma:

m = = [u]0 = [i]

unde:

[u] - unitatea de msur a factorului

[i] - elementul neutru n mulimea unitilor de msur [u]

m - nivelul adimensional asociat factorului

[u][u]

FACTORSUBFACTORTIPMETRICMETRICduratFuncionalitateCompletitudineVolumlungimeratvolu

m textCorectitudineTestarenr. reluriSecuritatevolum activripredicieresurseCompatibilitateEfort adaptaretimp

om/lunproductivitateInteroperabilitatenumrnumr apeluriintegrrivolum interfee

Fig. 1 - Diagrama de legtur factor - subfactor - metrici

{{{{


11/31

n aceast tipologie de metrici software se definesc:

fiabilitatea =

mentenana =

testabilitatea =

interoperabilitatea =

corectitudine =

consisten =

lizibilitate =

Observm c aceste definiii se caracterizeaz prin:

- simplitatea specific raportului care presupune parte (la numrtor) i ntregul(la numitor); ambele se definesc riguros;

- nivelul obinut este cuprins n intervalul [0,1];

- definirea numitorului i a numrtorului elimin elementele subiective, bazndu-

se pe realiti direct msurabile;

- deplasarea valorilor ctre limita superioar a intervalului arat nzestrarea

programului cu caracteristica de calitate respectiv.

Aceste metrici se analizeaz n raport cu nsuirile specifice indicatorilor (caracter

compensatoriu, senzitivitate i stabilitate).

Dac se consider un program oarecare p din mulimea P, un factor F i o metric

m:P[0,1],

m = ,

numr erori corectatnumr total erori

numr componente activatenumr total componente

numr interfee compatibilnumr total interfee

numr componente gsite corectenumr total componente

numr componente libere de contradiciinumr total componente

numr rulri de succesnumr total rulri

timp nelegere program comentattimp nelegere program lipsit de comentarii

(p) (p)


12/31

unde:

(p) - un numr de elemente ce caracterizeaz o parte a situaiilor favorabile;

(p) - un numr care corespunde tuturor situaiilor posibile;

p - este un program oarecare aparinnd mulimii P, metrica ne apare ca un raport

de frecvene.

Pentru programelePi i Pj considerate se vor obine nivelele:

mi = i mj =

Dei programele sunt diferite pornind chiar de la specificaiile dup care au fost

realizate, este posibil ca mi = mj.

Senzitivitatea este proprietatea de a obine la variaii mici ale lui (P) sau (P),

variaii mari ale lui m.

Proprietile rapoartelor pun n eviden c:

m =

n anumite condiii rmne constant, depinznd de valorile lui k1 i k2 reducnd simitor

senzitivitatea acestui tip de metric.

Stabilitatea metricii se menine la un nivel satisfctor dac variaiile numitorului

rmn n zone acceptabile. Referirile se fac mai ales pentru situaiile normale, cnd

programul este realizat din start dup un minim cel puin de condiii de calitate.

n situaia n care, pentru asigurarea mentenabilitii, sunt necesare consumuri de

resurse ce depesc elaborarea unui nou produs de acelai tip, orice metric definit ca

raport nu se mai reflect prin valori de acceptabilitate/neacceptabilitate.

Clasificarea metricilor

n [9], [12], [23], [34] se descriu diferite tipuri de metrici software:

Metrici cu folosire direct a textului surs

(Pi) (Pi)

(Pj) (Pj)

(P) - k1 (P) - k2


13/31

Orice program este stocat sub forma unui fiier. Un fiier are o lungime.

Lungimea se exprim fie ca numr de baii, fie ca numr de articole. n toate cazurile

exist o aproximare grosier a lungimii fiierului ca lungime a programului.

Dac programatorul respect o serie de reguli de scriere a programului (stil de

programare), se poate obine o legtur ntre articol i numr de instruciuni program

surs ntr-un articol.

Designul programului impune pentru lizibilitate o dispersare a secvenelor cu

introducere de blancuri pe linii n textul surs.

Dac fiierul surs se normalizeaz printr-un procedeu mecanic asigurndu-se, pe

ct posibil, un raport constant ntre numrul de instruciuni pe articol, lungimea fiierului

exprim fidel o caracteristic de baz a programului - lungimea.

Programul conine: definiri de variabile, referiri de variabile, instruciuni, apeluride funcii, evaluri de expresii. Toate pot fi contorizate. Metricile pe text surs definesc

modaliti de extragere din acesta, prin numrare, a nsuirilor ficrui program n parte.

De exemplu, n [13] pornind de la numrul operanzilor (n1) i de la numrul

operatorilor (n2) se construiesc relaiile (indicatori Halstead):

n = n1 + n2,

unde n reprezint vocabularul utilizat n program.

N = N1 + N2,unde:

N1 - numrul de operanzi care apar n program;

N2 - numrul de apariii ale operatorilor n program;

N - lungimea observat a programului;

C = n1 log2 n1+ n2 log2 n2,

unde:

C reprezint complexitatea estimat a programului.

Volumul programului este definit prin:

V = N log2 n

Claritatea K a programului se definete prin:

V n2N1

2 n1

K =


14/31

Nivelul de implementare L este definit prin:

2 n1

n2N1

Dificultatea D este inversul nivelului de implementare:

1

L

O alt modalitate de a opera pe textul surs corespunde transformrii programului

n volum de operaii exprimat prin cicluri main. Se consider instruciunile executabile

I1, I2,..., In existente ntr-un limbaj de programare i coeficienii C1, C2,..., Cn care

reprezint numrul standard (mediu) de cicluri main asociat fiecrei instruciuni. Pentru

a calcula numrul total de cicluri main ale unui program, se procedeaz la

descompunerea acestuia n instruciuni care formeaz structuri liniare sau n secvene

care alctuiesc structuri neliniare (structuri repetitive i structuri alternative).

Numrul de cicluri ia n considerare tipuri de operanzi, moduri de adresare i

dispuneri n segmente.

Este important identificarea riguroas a operaiilor elementare care se asociaz

unei instruciuni.

De exemplu, n limbajul C/C + + , evaluarea unei expresii are un grad de

generalitate foarte ridicat. n acest context, expresia este i simpla apelare a unei funcii.Volumul de operaii n acest caz ia n calcul:

- apelul funciei (salt necondiionat spre prima instruciune executabil din

funcie);

- salvrile pe stiv a unor registre;

- salvarea registrului BP;

- manipularea cu operanzii transmii ca parametri n modul de adresare indirect;

- prelucrrile propriu-zise ale funciei;

- restaurare de registre pe stiv;

- salt necondiionat n funcia apelatoare.

Acest volum notat R, va conine subexpresii de forma:

R1 =j

n

=

1

Cj Pj ,

L =

D =


15/31

unde:

Cj - nr. mediu de cicluri main pentru instruciunea Ij ;

Pj - frecvena de apariie a instruciunii Ij n structura liniar S1 ;

R1 - numrul total de cicluri main asociat structurii S1 ;

R2 = nj

n

=

1

Cj Pj + ,

unde:

n - numrul de repetri ale secvenei S1 la care se includ incrementrile i testele

variabile de control, precum i salturile la secvena de repetat;

- numr constant de cicluri ce corespunde iniializrii variabilei de control i

pregtirii secvenei repetitive;

R2 - numr total de cicluri main asociat unei structuri repetitive.

R3 = Pj

n

=

1

Cj Pj + qj

m

=

1

Cj Pj + ,

unde:

P - probabilitatea ca secvena S1 s se execute dup testarea condiiei;

q - probabilitatea ca secvena S2 s se execute dup testarea condiiei;

- volum de cicluri asociat evalurii i testrii unei expresii numite condiie;

R3 - numrul total de cicluri main asociat unei structuri alternative.Se poate scrie un program care preia pe de o parte textele surs ale programelor

scrise n limbajul C/C + + i pe de alt parte modulele lor obiect corespunztoare. Se

preiau din tabele numrul de cicluri main asociat fiecrei instruciuni asembler i se

determin volumul mediu de cicluri pe instruciune/expresie din limbajul C/C + +.

Odat coeficienii Cj estimai, un alt program calculeaz volumul oricrui

program.

Metrici software cu folosirea grafului asociat programului

Instruciunile dintr-un program se consider noduri n graf. Sensul de parcurgere

(execuie) a instruciunilor reprezint arcele care leag instruciuni.

Expresiile de atribuire, apelurile de funcii, incrementrile/decrementrile

alctuiesc structuri liniare crora le corespund reprezentanta sub form de graf dat n

figura 2.


16/31

Instruciunile condiionale i operatorul condiional genereaz reprezentrile pe

graf date, respectiv, n figurile 3a i 3b.

Instruciunea alternativ multipl (switch) n limbajul C/C + + i case n limbajul Pascal

genereaz reprezentarea pe graf dat n figura 4, numrul de arce care pleac din nodul

asociat condiiei depinznd de numrul expresiilor pentru care se opereaz selectri.

Fig. 2 Instruciuni n secven liniar

Fig. 4 Implementarea structurii alternative multiple

Fig. 3 Implementarea structurii alternative

a) b)


17/31

Structurii repetitive condiionat anterior WHILE - DO i corespunde

reprezentarea pe graf dat n figura 5.

Structurii repetitive condiionate posteroir DO - UNTIL i corespundereprezenterea pe graf din figura 6.

Structurilor mbricate le vor corespunde agregri n grafuri care conduc la

creterea numrului de noduri i respectiv a numrului de arce. n [26] se face referire la

relaia propus de Mc Cabe pentru calculul numrului ciclomatic NC dat de relaia:

NC = e - n +1 ,

unde:

e - reprezint numrul de arce ale grafului;

Fig. 5 Implementarea structurii repetitive condiionate anterior

Fig. 6 Implementarea structurii repetitivecondiionate posterior


18/31

n - reprezint numrul de noduri din graf.

Pentru numrul ciclomatic mai exist i alte formule. Nodurile i arcele n aceste

modele nu sunt difereniate, dei n realitate instruciunilor le corespund numr de cicluri

main diferite, dei salturile n interiorul segmentului au alte caracteristici dect cele

intersegmente. Dac nodurilor li se asociaz numere (cicluri main) i arcelor li se

asociaz distane (etichete) este posibil construirea de metrici pe graf care s includ i

diferenele dintre noduri, respectiv arce.

Oricrui program i se asociaz o structur atunci cnd el este privit ca rezultat al

asamblrii unor module. n stadiul de proiectare se definesc module prin :

- parametrii care se transmit;

- nivel de apel al modului;

- numr de module apelate;- complexitatea prelucrrilor din modul.

Se asociaz coeficieni pentru grade de reprezentare a celor patru trsturi imetrica rezult ca o norm a unei matrice produs latin cu elemente pozitive, prin sumarea

acestora.

m = aij bij ,unde :

aij - reprezint elemente din matricea coeficienilor definii ca ponderi detransformare;

bij - reprezint elemente ale matricei numerelor extrase din program.

De exemplu n [34] se consider metric Q Chapin n care:

Pm - intrri cerute pentru prelucrare;

Mp - intrri modificate la execuia modului;

i = j =


19/31

Cm - intrri care controleaz decizia i selecia;

Tm - date care se transmit modulului, sunt utilizate dar nu sunt modificate.

Coeficienii asociai sunt dai n tabelul nr. 2

Tabelul nr. 2tip de dat coeficientPm 1Mm 2Cm 3Tm 0,5

n acest context, metrica C are asociat expresia :

Q = (3.Cm + 2Mm + Pm + 0,5 Tm ) (1 + (E/3)2),

unde E reprezint o complexitate adiional care apare cnd un modul comunic cu alte

module.

Metrica Q consider cazul particular de matrice cu o coloan i 4 linii.

A = B =

b11 =Pm, b21= Mm, b31 = Cm, B41 = Tm.

Modelul COCOMO ia n considerare ponderi pentru ase nivele ale factorilor.

Factorii pentru care se nregistreaz nivele sunt:

- cerine de dezvoltare;

- nivel cerut al fiabilitii;

- complexitate produs;- timp execuie;

- restricii de memorie;

- capabiliti analiti;

- experien n aplicaii;

- capabiliti programatori;

b11

b21

b31

b41

123

0,5


20/31

- experien n utilizarea limbajului;

- tehnici de programare utilizate;

- grad utilizare instrumente.

Ponderile sunt pentru nivelele:

- foarte sczut;

- sczut;

- normal;

- ridicat;

- foarte ridicat.

A asea coloan a matricei este destinat valorii obinute pentru evaluarea factorului.

Modelul lui ALBRECHT ia n considerare matricea de ponderi:

B = , unde:

linia 1 - numr intrri;

linia 2 - numr ieiri;

linia 3 - numr fiiere interne;linia 4 - numr fiiere externe;

linia 5 - numr cereri externe.

Cele trei coloane reprezint nivelele de complexitate:

- sczut;

- mediu;

- ridicat.

Metrica aceasta se evalueaz ca sum de produse latine ale elementelor celor dou

matrice. Este interesant de constriut metrici software pe structur cu condiia definirii

unui sistem de ponderi care reflect importana fie a legturilor dintre module, fie a

efortului de realizare / asamblare.

Metrici de comportament al programelor

3 4 64 5 77 10 155 7 103 4 6


21/31

Programele se construiesc n vederea utilizrii. Seturile de date de intrare se

caracterizeaz prin volum, dimensiune, valori particulare, repetiii, parametrii de selecie,

opiuni etc. Pentru fiecare program se definesc exact semnificaiile acestora, aa fel nct,

utilizatorii sd nregistreze cu rigurozitate i n acelai mod comportamentul programului.

Dac se consider un program care lucreaz cu un fiier, se stabilete numrul de articole

din fiier, numrul de actualizri, structurile rapoartelor finale. Utilizatorul privete sub

form tabelar standard ceea ce trebuie completat, fr a-i lsa loc pentru interpretri cu

caracter local sau subiectiv.

Se nregistreaz numai valori obiective ( numr nregistrri, numr linii, numr

coloane, numr elemente, numr actualizri, numr erori, numr reluri, numr corecii n

date, numr rapoarte, numr rnduri, durat introducere date, numr erori introducere

date, durat compilare, durat execuie, durat sortare, durat tergere etc.) n toatecazurile se specific cu exactitate elementele de pe fiecare rnd al tabelelor, fr a lsa

coloane necompletate. Toate datele culese de la utilizatori se constituie n baze de date

ale comportamentului unui program. Datele conin momente, durate, frecvene, volume,

dimensiuni. Omogenitatea, ca uniti de msur, permite efectuarea de operaii de

adunare a seriilor ( de timp).

Se calculeaz :

- durate medii ( de execuie, de compilare, de eliminare erori, de introduceredate);

- rapoarte de forma r = , unde:

a - reprezint frecvene de apariie a unui caz

selectat;

b - reprezint totalitatea cazurilor studiate;

- corelaii ntre seriile de date provenind din tabele;

- grupri dup metodele analizei de date a elementelor din tabele i clasificarea

programelor, tipurilor de probleme, erorilor;

- estimarea unor coeficieni pentru modele care pun n eviden legturi ntre

seriile de date din tabele, serii care se vor constitui n nregistrri ale unor variabile n

baze de date. n [29] , [38] sunt prezentate astfel de modele.


22/31

Se consider SM = luni/om i KDSI = mii de instruciuni scrise (estimate).

Pornind de la aceste notaii, se iau n considerare diferite proiecte. Pentru proiectele

organice, se consider expresiile:

SM = 2.4 (KDSI) 1.05 i timpul necesar realizrii proiect

TDEV = 2.5 (SM) 0..38

Pentru proiectele mixte, vom avea:

SM = 3.0 (KDSI) 1.12

TDEV = 2.5 (SM) 0.35

Metricile de comportament al programelor permit cunoaterea modului n care un

program rspunde cerinelor efective la utilizator. Dac programul este riguros testat se

obin cu baze de date de la aceast operaie parametrii care nu difer semnificativ fa de

valorile estimale ale coeficinilor metricelor de comportament. Econometria dispune denumeroase tehnici de estimare i de analiz a calitii coeficienilor. Dei aceste modele

sunt mai des ntrebuinate, fluctuaiile coeficienilor estimai depind de eantionul de

program i beneficiari cu care s-a lucrat.Fiecare dintre metricile prezentate pune n

eviden anumite laturi calitative ale programului. Ele nu se exclud ci se presupun,

completndu-se.

Este necesar s se defineasc metrici de toate tipurile pentru un produs, pentru a

rspunde cerinelor att formulate de programatori, de dealeri, ct i de utilizatoriiprogramelor. Metricile sunt cu att mai valoroase cu ct sunt mai simple de calculat i cu

ct efortul de a culege datele este mai redus. Este preferabil ca proiectanii, odat cu

lansarea unei metrici software, s ofere i instrumentele pentru culegerea automat a

datelor obiective despre programele care fac obiectul evalurii i s calculeze nivelele

pentru aceste programe.

Proprietile metricilor software

Dac metricile definite pe o mulime M se bucur de o serie de proprieti,

particularitile metricilor software genereaz alte proprieti. Astfel, n [10], [12] , [29]

sunt puse n eviden proprieti ale metricilor softaware, dup cum urmeaz:


23/31

P1 : o metric trebuie s pun n eviden dou subclase de programe : programe

utilizabile i programe inutilizabile;

P2 : dou programe identice conduc la valori egale ale unei metrici care le

evalueaz;

P3 : utilizarea unei metrici nu conduce la situaii anormale cnd se fac studii

empirice;

P4 : dac o metric deriv dintr-o alt metric, apartenenele programelor la

subclase nu se modific;

P5 : modificrilor neutre din program nu le corespund creteri sau diminuri ale

valorilor rezultate dintr-o metric;

P6 : modificrilor limitate din program le corespund creteri sau diminuri limitate

ale valorilor rezultat dintr-o metric;P7 : creterea numrului de variabile exogene conduce la creterea gradului de

msurabiliate asociat metricii;

P8 : modificrilor active din program trebuie s le corespund diminuri sau

creteri ale valorilor rezultate dintr-o metric.

Proprietile metricilor sunt puse n eviden prin parcurgerea unor pai i anume :

- construirea unui sistem al specificaiilor;

- definirea ierarhiilor asociate modulelor din care este format programul;- se calculeaz pentru fiecare modul o serie de indicatori ( pe text, structur sau

dinamic);

- indicatorii calculai se agreg rezultnd pentru fiecare modul un indicator

agregat.

Prin luarea n considerare, pentru fiecare program, a descompunerii n module, se

ajunge la reprezentarea programului sub forma unei structuri arborescente. Se consider

un sistem de ponderi care permit "recompunerea" de la baza arborescenei spre rdcin,

cu asigurarea apartenenei la intervalul [0,1] a oricrei agregri. Se consider programul P

cu structura arborescent din figura 7 .


24/31

n figur m1, m2, m3, m4 i m5 sunt module.

Fie f : m1, m2, m3, m4, m5 [0,1]

o metric a factorului fiabilitate i ponderile a1, a2, a3, a4, a5, a6, a7, a8 definite astfel nct :

a1 + a2 + a3 + a4 + a5 + a6 + a7 + a8 = 1

Se construiesc relaiile de agregare :

b1 = a1f(m1) + a2f(m2)

b2 = a3f(m3) + a4f(m4) + a5f(m5)

b3 = a6b1 + a7b2

b4 = a8b3

sau:

b4 = a8 [ a6b1 + a7b2 ] =

= a8a6(a1f(m1) + a2f(m2)) + a8a7(a3f(m3) + a4f(m4) + a5f(m5))

Se impune studierea proprietilor (senzibilitate, consisten, caracter

necompensatoriu) acestui indicator nou agregat al fiabilitii.Sistemul de ponderi ai este de mare importan n a asigura metricii veridicitatea

n confruntarea cu fiabilitatea, ca evaluare a unui comportament real ( numr rulri de

succes / numr total de rulri program).

Construirea de metrici sub forma de modele permite deplasarea proprietilor

metricii n zona axiomelor modelelor, fie cu o variabil, fie cu mai multe variabile. Dac

modelului i se identific o serie de proprieti, este necesar verificarea acestora i n

cazul mulimilor de programe pentru care metrica este construit. n cazul n care aceste

proprieti nu au corespondent n zona programelor, modelul, indiferent ct de interesant

este, va fi abandonat.

Validarea unei metrici

1

2

6

8

1

7

3

4

5m

1

m

2

1

1 m

3

m

4

m

5

Fig. 7 Arborescena asociat programului P


25/31

Metricile software se construiesc pentru a oferi informaii ct mai exacte asupra

calitii programelor. n toate cazurile, metricile au un caracter predictiv. Dac s-a

ncheiat ciclul de via al unui program explornd baza de date a comportamentului su i

prin aplicarea metricilor, ntr-adevr se vor stabili nivelele efective avute i care nu se vor

mai putea modifica. Despre acest produs, aprecierile calitative sunt la timpul trecut. n

cazul unui produs software n proces de realizare sau n uz curent, metricile ofer

informaii asupra a ceea ce este programul sau asupra unui comportament efectiv pe un

interval de timp trecut, n vederea extrapolrii comportamentului pentru intervale de timp

viitoare.

Validarea unei metrici este problema acceptrii acesteia ca modalitate de

extrapolare.Se consider mulimea noilor programe P i metrica :

m : P [ 0,1].

Astfel, dac 0 m (Pi) a, programul are un nivel calitativ sau un comportament

care l fac neutilizabil, iar, dac a m (Pi) 1, programul poate fi utilizat, conform

figurii 8.

Mrimea m (Pi) = a este considerat nivel critic.

Dup un timp, fr a efectua modificri asupra elementelor din mulimea P, prin

consultarea unui lot semnificativ al utilizatorilor de programe se identific urmtoarele

situaii :

a) elementele din submulimea P- s-au comportat inacceptabil, iar elementele din

submilimea P+ s-au comportat acceptabil;

m (Pi)

a

PP1

P2

P3

P4

neacceptat

acceptat

Fig. 8


26/31

b) au existat elemente din submulimea P-, considerate iniial inacceptabile, care s-

au comportat acceptabil, iar elementele mulimii P+ s-au comportat n totalitate

acceptabil;

c) au existat elemente din submulimea P+ care s-au comportat inacceptabil, n

timp ce elementele submulimii P- s-au comportat n totalitate inacceptabil;

d) exist elemente din submulimea P- care s-au comportat acceptabil, iar unele

elemente din submulimea P+ s-au comportat inacceptabil;

e) toate elementele submulimii P+ s-au comportat inacceptabil, iar toate

elementele submulimii P- s-au comportat acceptabil.

Dac P- i P+ sunt submulimile generate de metrica m: P [0,1], submulimile

U- i U+ sunt rezultatele aprecierii de ctre utilizatori, atunci:

P- P+ = P U- U+ = P

P- P+ = U- U+ =

Cazurile a i e sunt uor de analizat. n primul caz metrica a fost corect definit,

deci e validat, iar n al doilea caz trebuie efectuat o inversare.

Cazurile b i c presupun deplasarea spre stnga, respectiv spre dreapta a nivelului

critic a.

Cazul d ia n considerare riscul pe care l prezint migrarea dinspre submulimea

P-

spre submulimea P+

, respectiv migrarea dinspre submulimea P+

spre submulimea P-

.Aparatul statistic existent permite abordri multiple. Se construiete un sistem de ipoteze

i se definesc praguri de acceptare a lor, ceea ce permite n fond acceptarea unei metrici

ca oferind, cu un nivel de risc specificat, o apreciere corect.

De asemenea, prin identificarea unor situaii speciale, se obin grupri de

programe i se stabilesc, prin metodele analizei de date, situaiile n care o metric este

mai adecvat dect alta.

Concluzii.

Standardul IEEE 1061/1992 (IEEE Standard for a Software Quality Metrics

Methodology) reflect stadiul actual al modului de abordare cantitativ - obiectiv n zona

software.


27/31

Exist numeroase lucrri care conin tabele ce sistematizeaz modelele (metricele)

asociate caracteristicilor de calitate, cu prezentarea ipotezelor de lucru i cu descrierea

variabelelor exogene. Problema care se pune acum este aceea de a folosi indicatorii i

mai ales de a cpta ncredere n ei. Metodologia metricii exist. Ceea ce trebuie ns

delimitat, trebuie legat de implementare.

Toate modelele sunt construcii interesante. De la definirea unui model pentru

factor, pn la utilizarea efectiv, este un drum lung, aproape imposibil de parcurs.

Pentru crearea de metrici operaionale este necesar parcurgerea etapelor

urmtoare :

- definirea variabilelor exogene i a modului exact, neambiguu de msurare; prin

exemple de msurare se va pune n eviden caracterul consistent al mulimii de variabile

exogene i faptul c nu exist elemente din program care accidental nu sunt incluse nmodel, dei ele ocup un rol important n arhitectura acestuia;

- construirea de software care s msoare automat nivelele variabilelor exogene

din program;

- n toate cazurile de verificare a cestui software se va evidenia c ntr-adevr

nivelele obinute sunt corecte, neafectate de imperfeciunile de definire/ identificare

coninute n modulele acestui software;

- stabilirea de reguli exacte pentru construirea exemplelor de test sau a structurii( diversitii) cazuisticii reale prin intermediul creia se nregistreaz nivelele de

comportament; n caz contrar, se vor obine nivele ale factorilor care vor fi diferite

semnificativ de nivelele acelorai factori msurate la utilizarea efectiv la beneficiari a

programelor;

- crearea obligativitii ca productorii de software s utilizeze un acelai produs

pentru evaluarea metricii pentru un factor, asigurndu-se n acest fel compatibilitatea i

deci comparabilitatea rezultatelor; schimbarea programului de evaluare a metricii

genereaz diferene tiute fiind fluctuaiile de interpretare i de msurare a variabilelor

exogene prin automatizare.

Exist n ara noastr laboratoare pentru testarea hardware. Literatura din

domeniul calculatoarelor abund de rezulate tehnice ale testelor hardware. Laboratoarele

de certificare calitate software au activitate de pionerat. Problemele de software audit


28/31

sunt i ele la nceput. Perseverena de a construi instrumente pentru evaluarea

complexitii, pentru demonstrarea complexitii, pentru demonstrarea corectitudinii sau

pentru crearea bazei de date pentru comportamentul programelor, trebuie s caracterizeze

la nceput aceste laboratoare de testare software. n plus, obligativitatea ca fiecare produs

program s poarte un nsemn care marcheaz faptul c este produs certificat, va schimba

concepia de lansare a noilor programe pe piaa software.

Amploarea procesului de informatizare a societii romneti impune eliminarea

paralelismelor n producia de software, lansarea produciei de programe prin licitaii.

Orice alt abordare va restrnge numrul i complexitatea aplicaiilor, scznd gradul de

cuprindere a acestui proces att de necesar.Numai cuantificrile oferite de utilizarea

curent a metricilor software leag strns costul de calitatea software, singura condiie ce

asigur viabilitatea informaticii aplicate.

BIBLIOGRAFIE

1.Alexandru Balog -Estimarea calitatii sistemelor de programeTeza de doctorat, ASE, Bucuresti, 1994

2.Basili, R.V., Silby, R.W., Phillips, T. - Metric analysis and data validation acrossFORTRAN projects

IEEE Transaction on Software Engineering vol.9, nr.6, 1983

pag. 652-663

3.Bowman, J.B., Newman, A. William - Software Metrics as a Programming TrainingTool

Journal of Systems Software nr.13, 1990pag. 139-147

4.Bush, E. Martin, Fenton, E. Norman - Software Measurement: A ConceptualFramework

Journal of System Software nr.12, 1990pag. 223-231

5.Conte, S., Dunsmore, H., Shen, V. - Software Engineering Metrics and Models

Redword City CA, Benjamin Cumming Publishing Co., 1986

6.Coupal, Daniel, Pierre, N. Robillard - Factor Analysis of Source Code MetricsJournal of Systems Software nr.12, 1990pag. 263-269

7.Creanga, I., Enescu, I. -Algebreed. Tehnica-Bucuresti, 1973


29/31

pag. 205

8.Khorson, Dehnad - Software Metrics from a User's PerspectiveJournal of Systems Software nr. 12,1990pag. 111-115

9.Ejiogu, L.O. - The critical issues of software metricsACM SIGPLAN Notices, 1987pag. 59-63

10.Fenton, N.E. - Software Metrics: A Rigorous ApproachChapman and Hall, 1991

11.Fenton, N.E., Melton, Austin -Deriving Structurally Based Software MeasuresJournal of Systems Software nr.12 ,1990pag. 177-187

12.Grady, R., Caswell, D. - Software Metrics: Establishing a Company-Wide ProgramEnglerood Cliffs, N.Y. Prentice-Hall, 1987

13.Halstead, M.H. - Elements of Software ScienceElsevier-Noth Holland, Amsterdam, 1977

14.Henry, S.M., Kafura, D. - Software structure metrics based on information flowIEEE Transaction on Software Engineering, vol.7, nr.5, 1981pag. 510-518

15.Harrison, Warren -A Foreword to the Special Issue on Using Software Metrics

Journal Systems Software nr. 13, 1990pag. 87-88

16.Harrison, W., Cook, C.R. -A note on the Berry-Meeting Style MetricsCommunication of the ACM vol.29, nr.2, 1986pag. 123-125

17.Jensen, H.A., Vairavan, K. -An Experimental Study of Software Metrics for Real-TimeSoftware

IEEE Transaction on Software Engineering, vol.SE 11, nr.2, 1985pag. 231-234

18.Kafura, D., Reddy, G.R. - The use of software complexity metrics in softwaremaintenance

IEEE Transaction on Software Engineering, vol.13, nr.3, 1987pag.335-343

19.Kafura, D. ,Henry, S. - Software Quality metrics based on interconectivityJournal of System and Software nr.2, 1981


30/31

pag. 121-131

20.Khoshgoftaar, T.M. - Predicting Software Development Errors Using SoftwareComplexity Metrics

Software Reability and Testing, Hoang Pham-Editor

IEEE Computer Press, New York, 1995pag. 20-28

21.Li, H.F., Chung, W.K. -An empirical Study of Software MetricsIEEE Transaction on Software Engineering, vol.13, nr.6 ,1987pag. 697-708

22.Myrvold, Alan - Data Analysis for Software MetricsJournal of Systems Software nr. 12, 1990pag. 271-275

23.Navlakha, J.K. - A survey of system complexity metricsComputer Journal, vol.30, nr.3, 1987pag. 233-238

24.Paige, M. - A Metric for Software Test PlanningTutorial-Software QualityAssurance-a practicalapproach-Tsun Schoneditor IEEE Computer Society Press, 1984pag. 70-75

25.Paulish, D.J., Moller, K. Heinnich -Software Metrics: A Practitioner's Guide to

Improved Product Development

IEEE Press, New York, 1992

26.Perlis, A., Sayward, F., Shan, M. - Software Metrics: An Analysis and EvaluationCambridge MA.MIT Press, 1981

27.Pfleeger, S.L., Mc Gowan, C. - Software metrics in the process maturity frameworkJournal of Systems and Software, nr.12 ,1990pag. 255-261

28.Prather, P.E. - On hierarchical software metricsSoftware Engineering Journal, vol.2, nr.2, 1987pag. 42-45

29.Redmond, J.A., Reynold, Ah-Chuen - Software Metrics-A User's PerspectiveJournal of Systems Software nr. 13pag. 97-110


31/31

30.Ruhe, Gunter - An integer programming approach to optimal software metricsselection

Operations Research Proceedings 1994-Ulrich Derigs, Achim

31.Sallie, Henry, John, Lewis - Integrating Metrics into a Large-Scale Software

Development EnvironmentJournal of Systems Software nr. 13, 1990pag. 89-95

32.Samuel, E. Hon III - Assuring Software Quality through Measurements: A Buyer'sPerspective

Journal of Systems Software nr.13, 1990pag.117-130

33.Scheneidewing, N.F. - Methodology for validating software metricsIEEE Transaction on Software Engineering, vol.18, nr.5, 1992pag. 410-422

34.Shepperd, Martin, Darrel, Ince - Derivation and Validation of Software MetricsClarendon Press-Oxford, 1993

35.Singh, R., Schneidewing, N.F. - Concept of software quality metrics standardCOMPCON mars 3-6 1986, A.G. Bell editor, Los AlamosIEEE Computer Societypag.362-368

36.Zuse, H., Bollmann, P. - Software metrics : using measurement theory the describe the properties and scales of static complexity metrics

SIGPLAN Notices, vol.24, 1989pag. 23-33

37.Whale, Geoff- Software Metrics and Plagiarism DetectionJournal of Systems Software nr.13, 1990pag. 131-138

38.xxx -IEEE Standard for a Software Quality Metrics MethodologyIEEE Std 1061/1992IEEE Standards Collection Software EngineeringIEEE Press, New York, 1994

39.xxx - Mica enciclopedie matematiced. Tehnic-Bucuresti, 1980pag. 879

Metrici Software

Documents

Transcript of Metrici Software