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 M R
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)
 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 ) = { 0 dac x = y
1 dac 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:

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

n
d ( x,y ) = S | xi - yi |
i=1

d ( x,y ) = max | y i - xi |
1i
n

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

1/
d ( x,y ) = [ (x(t) - y(t))2 dt ] 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 ||
 n spaiul euclidian k-dimensional R k se pot defini:

|| x || = kS 2

i=1 | i |
|| x || = max i
1ik

k
|| x || = S | i |
i=1

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;
 -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 programelor P=P1,P2,...,Pm i se construiete un
indicator de performan sau de caracterizare f(x):PN, 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:
Pi
f(Pi, Pj) = 100
Pj

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;
 - 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 mai
nuanate.
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 a1 2
b.
Intervalul [a, 1] corespunde zonei de respingere a programului, dac f(Pi) [a,
1]. Intervalul (1, 2].corespunde zonei de acceptare cu rezerve a programului Pi, dac
f(Pi) (1, 2]. Intervalul (2,b] corespunde zonei de acceptare cu ncredere a
programului Pi, dac f (Pi) (2,b].
Metodologiile de clasificare a sistemelor de programe stocate n biblioteci publice de
software atribuie apartenena, respectiv la clasele de programe C,B i A dup ncadrarea
n unul din cele trei subintervale. Ceea ce este caracteristic unei metrici este generalitatea,
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
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
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 aceeai
semnificaie 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 lucrul
cu 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
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 economie de timp SUBFACTORI

EFICIEN
economie de resurse

completitudin
ecorectitudine
FUNCIONALITATE securitate
compatibilitat
einteroperabilitate
capacitate de a corecta
MENTENABILITATE expandabilitate
test abilitate
hardware
independen
software
PORTABILITATE instabilitate
reutilizabilitat
e
nondeficien - gradul n care nu
conin erori nedetectabile
FIABILITATE tolerane la erori
disponibilitate
 Pentru fiecare factor i pentru subfactorii si se constituie diagrame de legtur
care conduc spre metrici software acceptabile, figura 1.

FACTORSUBFACTORTIP
METRICMETRICduratFuncionalitateCompletitudineVolumlungimeratvolum
{
textCorectitudineTestarenr. reluriSecuritatevolum activripredicie
resurseCompatibilitateEfort adaptaretimp
om/lunproductivitateInteroperabilitatenumrnumr apeluriintegrrivolum interfee
{
{
{
Fig. 1 - Diagrama de legtur factor - subfactor - metrici

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:

[u]
m= = [u]0 = [i]
[u]
unde:
[u] - unitatea de msur a factorului
[i] - elementul neutru n mulimea unitilor de msur [u]
m - nivelul adimensional asociat factorului
n aceast tipologie de metrici software se definesc:
 fiabilitatea = numr rulri de succes
numr total rulri

mentenana = numr erori corectat

numr total erori

numr componente activate

testabilitatea =
numr total componente

numr interfee compatibil

interoperabilitatea = numr total interfee

numr componente gsite corecte

corectitudine = numr total componente

numr componente libere de contradicii

consisten = numr total componente

timp nelegere program comentat

lizibilitate =
timp nelegere program lipsit de comentarii

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 = (p) ,
(p)
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:

(Pi) (Pj)
mi = i mj =
(Pi) (Pj)

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:

(P) - k1
m=
(P) - k2

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
 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, apeluri
de 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:
K = V n2 N1
2 n1
 Nivelul de implementare L este definit prin:
L = 2 n1
n2N1
Dificultatea D este inversul nivelului de implementare:
D = 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:
n

R1 =
j1
Cj P j ,
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 ;
n

R2 = n Cj P j + ,
j1

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.
n m

R3 = P Cj P j + q Cj P j + ,
j1 j1

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.


Fig. 2 Instruciuni n secven liniar

Instruciunile condiionale i operatorul condiional genereaz reprezentrile pe

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

b)
a)

Fig. 3 Implementarea structurii alternative

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. 4 Implementarea structurii alternative multiple

 Structurii repetitive condiionat anterior WHILE - DO i corespunde
reprezentarea pe graf dat n figura 5.

Fig. 5 Implementarea structurii repetitive condiionate anterior

Structurii repetitive condiionate posteroir DO - UNTIL i corespunde

reprezenterea pe graf din figura 6.

Fig. 6 Implementarea structurii repetitive

condiionate posterior

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

metrica rezult ca o norm a unei matrice produs latin cu elemente pozitive, prin sumarea
acestora.

m = aij bij ,
i= j=
1
unde :
aij - reprezint elemente din matricea coeficienilor definii ca ponderi de
transformare;
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;
 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. 2
tip de dat coeficient
Pm 1
Mm 2
Cm 3
Tm 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.

1 b11
2 b21
A= 3 B=
b31
0,5
b41

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

3 4 6
4 5 7
B= 7 10 15 , unde:
5 7 10
3 4 6

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
 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 toate
cazurile 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 introducere
date);

- 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.
 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 de
numeroase 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 utilizatorii
programelor. 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:
 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 .


m m m m m
2 3 4 5
Fig. 7 Arborescena asociat programului P

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

 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.

m (Pi)
acceptat
a
neaccepta
t P
P1 P2 P3 P4

Fig. 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;
 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.
 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 n
model, 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
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 programe
Teza de doctorat, ASE, Bucuresti, 1994

2.Basili, R.V., Silby, R.W., Phillips, T. - Metric analysis and data validation across
FORTRAN 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 Training

Tool
Journal of Systems Software nr.13, 1990
pag. 139-147
4.Bush, E. Martin, Fenton, E. Norman - Software Measurement: A Conceptual
Framework
Journal of System Software nr.12, 1990
pag. 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 Metrics

Journal of Systems Software nr.12, 1990
pag. 263-269

7.Creanga, I., Enescu, I. - Algebre

ed. Tehnica-Bucuresti, 1973
 pag. 205

8.Khorson, Dehnad - Software Metrics from a User's Perspective

Journal of Systems Software nr. 12,1990
pag. 111-115

9.Ejiogu, L.O. - The critical issues of software metrics

ACM SIGPLAN Notices, 1987
pag. 59-63

10.Fenton, N.E. - Software Metrics: A Rigorous Approach

Chapman and Hall, 1991

11.Fenton, N.E., Melton, Austin - Deriving Structurally Based Software Measures

Journal of Systems Software nr.12 ,1990
pag. 177-187

12.Grady, R., Caswell, D. - Software Metrics: Establishing a Company-Wide Program

Englerood Cliffs, N.Y. Prentice-Hall, 1987

13.Halstead, M.H. - Elements of Software Science

Elsevier-Noth Holland, Amsterdam, 1977

14.Henry, S.M., Kafura, D. - Software structure metrics based on information flow

IEEE Transaction on Software Engineering, vol.7, nr.5, 1981
pag. 510-518

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

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

16.Harrison, W., Cook, C.R. - A note on the Berry-Meeting Style Metrics

Communication of the ACM vol.29, nr.2, 1986
pag. 123-125

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

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

18.Kafura, D., Reddy, G.R. - The use of software complexity metrics in software
maintenance
IEEE Transaction on Software Engineering, vol.13, nr.3, 1987
pag.335-343
19.Kafura, D. ,Henry, S. - Software Quality metrics based on interconectivity
Journal of System and Software nr.2, 1981
 pag. 121-131

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

Complexity Metrics
Software Reability and Testing, Hoang Pham-Editor
IEEE Computer Press, New York, 1995
pag. 20-28

21.Li, H.F., Chung, W.K. - An empirical Study of Software Metrics

IEEE Transaction on Software Engineering, vol.13, nr.6 ,1987
pag. 697-708

22.Myrvold, Alan - Data Analysis for Software Metrics

Journal of Systems Software nr. 12, 1990
pag. 271-275

23.Navlakha, J.K. - A survey of system complexity metrics

Computer Journal, vol.30, nr.3, 1987
pag. 233-238

24.Paige, M. - A Metric for Software Test Planning

Tutorial-Software Quality
Assurance-a practical
approach-Tsun Schon
editor IEEE Computer Society Press, 1984
pag. 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 Evaluation
Cambridge MA.MIT Press, 1981

27.Pfleeger, S.L., Mc Gowan, C. - Software metrics in the process maturity framework

Journal of Systems and Software, nr.12 ,1990
pag. 255-261

28.Prather, P.E. - On hierarchical software metrics

Software Engineering Journal, vol.2, nr.2, 1987
pag. 42-45

29.Redmond, J.A., Reynold, Ah-Chuen - Software Metrics-A User's Perspective

Journal of Systems Software nr. 13
pag. 97-110
30.Ruhe, Gunter - An integer programming approach to optimal software metrics selection
Operations Research Proceedings 1994-Ulrich Derigs, Achim

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

Development Environment
Journal of Systems Software nr. 13, 1990
pag. 89-95
32.Samuel, E. Hon III - Assuring Software Quality through Measurements: A Buyer's
Perspective
Journal of Systems Software nr.13, 1990
pag.117-130

33.Scheneidewing, N.F. - Methodology for validating software metrics

IEEE Transaction on Software Engineering, vol.18, nr.5, 1992
pag. 410-422

34.Shepperd, Martin, Darrel, Ince - Derivation and Validation of Software Metrics

Clarendon Press-Oxford, 1993

35.Singh, R., Schneidewing, N.F. - Concept of software quality metrics standard

COMPCON mars 3-6 1986, A.G. Bell editor, Los Alamos
IEEE Computer Society
pag.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, 1989
pag. 23-33

37.Whale, Geoff - Software Metrics and Plagiarism Detection

Journal of Systems Software nr.13, 1990
pag. 131-138

38.xxx - IEEE Standard for a Software Quality Metrics Methodology

IEEE Std 1061/1992
IEEE Standards Collection Software Engineering
IEEE Press, New York, 1994

39.xxx - Mica enciclopedie matematic

ed. Tehnic-Bucuresti, 1980
pag. 879