METRICI SOFTWARE

Ion Ivan
Mihai Popescu

Rezumat

Aprecierea sistemelor de programe este de ordin calitativ (bun,

satisfãcãtor, foarte bun, nesatisfãcãtor) şi de ordin cantitativ, exprimat
numeric.
Problematica definirii unui sistem de mãsurare a calitãţii genereazã
diferite abordãri, pe text sursã şi asupra comportamentului la utilizator
al programelor.
Metricile software înglobeazã modele, indicatori şi proprietãţile
acestora, precum şi modalitãţi de evaluare şi validare. Lucrarea îşi
propune sã prezinte concepte de bazã, modele şi modalitãţi de utilizare
a metricilor software.

Introducere

Conceptul de metricã nu este nou. Se considerã o mulţime de puncte M pe care se

defineşte o aplicaţie
d : M x M →R
astfel încât:
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] aplicaţia d se constituie într-o metricã a mulţimii M. Aceastã aplicaţie se
mai numeşte şi distanţa de la elementul x la elementul y; x,y∈M.
Lucrarea [38] prezintã exemple de aplicaţii 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 urmãtoarele tipuri de distanţe:

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

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

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

Pentru x(t) şi y(t) se defineşte distanţa:

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

Existã conceptul de normã şi se poate stabili o legãturã între normã şi metricã

astfel:
norma distanţei a douã elemente se defineşte ca o funcţie de forma:
d ( x,y ) = || x - y ||
 În spaţiul euclidian k-dimensional R k se pot defini:

k 2
|| x || = S ε
i=1 i
|| x || = max | ε i |
1≤ i≤ k

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

iar norma are proprietãţile:

|| x || > 0 pentru x ≠ 0
|| λ x || = | λ | • || x ||, λ ∈ C
|| x + y || ≤ || x || + || y ||

Se poate spune cã şi în domeniul ingineriei programãrii (software engineering)

utilizarea conceptului de metrici (software metrics) este acceptabilã.
Definirea de metrici software revine la a construi modele, indicatori care pornesc
de la mãrimi ce se mãsoarã cu obiectivitate (numãr linii sursã, numãr erori, numãr
variabile, numãr instrucţiuni de Intrare/Ieşire, numãr funcţii, numãr parametrii transmişi,
numãr nivele ale arborelui asociat).
Practica aratã cã existã o strânsã legãturã între comportamentul efectiv al unui
program şi structura lui exprimatã prin mãrimi ce se determinã exact, obiectiv.
Indicatorii (metricile software) se construiesc în aşa fel încât valorile obţinute
caracterizeazã produsul. Asfel, funcţia:
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 obţinute la execuţia programului;
 -dacã α ≤ f(x) < 1, unde α este o valoare numitã prag de acceptare, obţinutã
experimental, programul poate fi utilizat, riscurile de obţinere a rezultatelor eronate
fiind minore;
-dacã 0 < f(x) < α , frecvenţa cu care se obţin rezultate incorecte este atît de mare
incît eforturile de a utiliza un astfel de program se dovedesc ineficiente.
Se observã cã o metricã astfel conceputã are rolul de a poziţiona un program într-una din
douã categorii: program acceptabil a fi în uz curent şi program imposibil de utilizat.
Dacã se considerã mulţimea programelor P={P1,P2,...,Pm} şi se construieşte un indicator
de performanţã sau de caracterizare f(x):P→N, existã posibilitatea de a compara
programele.
O astfel de funcţie poate fi lungimea fişierului executabil. Comparaţiile sunt
directe.
Dacã f(Pi) > f(Pj) se va spune cã programul Pi este mai mare sau mai lung sau cã
ocupã spaţiu de stocare (memorie externã) mai mare decât programul Pj.
Sunt interesante şi comparaţiile 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 decât programul Pj.
Dacã f(Pi, Pj) < 100 rezultã cã programul Pi este mai scurt decât programul Pj.
Spre deosebire de mulţimea M definitã la început, în care punctele sunt omogene,
este extrem de dificil de construit mulţimi omogene de programe, condiţie esenţialã
pentru realizarea de comparaţii care sã aibã sens.
De aceea, metricile software sunt concepute ca programul sã fie raportat prin el
însuşi la modele ideale (f(x)=1 sau f(x)=0).
Rolul metriciilor este de a reduce subiectivitatea aprecierii unui program.
Asemeni unitãţilor de mãsurã din sistemul metric internaţional, cei care îşi propun sã
construiascã metrici software trebuie sã parcurgã urmãtoarele etape:
- definirea mãrimilor obiective care pot fi mãsurate fie în textul sursã al
programului, fie pe durata utilizãrii programului la beneficiar;
 - stabilirea metodologiei de înregistrare a mãrimilor obiective şi de constituire a
bazei de date asociate programului;
- elaborarea modelului sau modelelor în care mãrimile obiective stabilite
figureazã ca variabile independente x1, x2, x3, ....xn şi în care y, variabila rezultativã, va
releva comportamentul programului sau calitãţile 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 obţinute cu ceea ce a oferit (prezis) metrica la momentul iniţial; în cazul în
care se evidenţiazã 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,
aşa cum sunt definiţi în [37]).
În timp, s-a acordat o atenţie deosebitã complexitãţii software [17], [35] şi
fiabilitãţii software [19], modelele asociate acestora constituindu-se şi în veritabile
metrici.
Deşi iniţial un program este cotat bun sau nu, în realitate aprecierile sunt mai
nuanţate.
Pentru o metricã software definitã f:P →[a,b], a,b∈R+ şi a ≤ b se vor identifica
mai multe valori critice (praguri) α 1, α 2 care permit aceastã nuanţare a delimitãrii, cu
a<α 1< α 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 apartenenţa, 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) oricãrui program în mod neambiguu.
Adicã mãrimile obiective trebuie atât de riguros definite încât oricine are la dispoziţie un
program Pi şi metrica, sã poatã obţine aceleaşi rezultate.
De exemplu, dacã se considerã:
n1 - numãr de operanzi distinct;
n2 - numãr de operatori distinct;
n3 - numãr de definiţii tipuri de date
şi o mãsurã a complexitãţii
C=n1 log1 n1 + n2 log2 n2 + n3 log3 n3
şi se precizeazã cã operanzii sunt:
- constante definite în program care participã în evaluãri de expresii;
- variabile elementare;
- variabile de tip derivat,
se obţine un grad de obiectivitate acceptabil.
Nu se includ definirile de tip derivat ci numai variabilele care sunt înzestrate cu
proprietãţile acestor tipuri.
Prin operator se va înţelege:
- instrucţiunile if, for, switch, goto, while, do;
- expresii de atribuire;
- apeluri de funcţii;
- evaluãri 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 fiecãrui 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 aceleaşi
reguli. În situaţia în care, pentru rezolvarea aceleiaşi probleme, se scriu programe în
limbaje diferite de cãtre programatori cu acelaşi nivel de performanţã, trebuie ca
diferenţele obţinute pentru aplicarea metricii sã fie nesemnificative. Dacã ipotezele de
construire şi utilizare a unei metrici sunt judicios concepute existã reale posibilitãţi de a
utiliza metrica şi mai ales de a aprecia programele prin prisma nivelelor date de calculul
respectivei metrici. Este important ca mãrimile obiective din care derivã metrica sã fie
uşor de obţinut. O metricã costisitor de evaluat este abandonatã uşor.

Factori
Calitatea software este pusã în evidenţã cu ajutorul unor modele asociate
caracteristicilor: mentenabilitate, corectitudine, portabilitate, fiabilitate, modularitate,
funcţionalitate, lizibilitate, reutilizabilitate, liniaritate, robusteţe, toleranţã la erori,
interoperabilitate [1], generalitate.
Fiecare caracteristicã scoate în evidenţã anumite însuşiri ale softwareului. Astfel,
fiabilitatea reprezintã capacitatea unui program de a fi utilizat fãrã a genera erori sau
capacitatea de a restabili un context anterior apariţiei de erori.
Mentenabilitatea este însuşirea programului de a permite corecţii,
introduceri/extrageri de secvenţe în vedera adaptãrii la noi cerinţe impuse de schimbãri
ale formulelor de calcul din algoritmi, a schimbãrii dimensiunilor unor câmpuri şi
modificãrilor de utilizare echipamente.
Portabilitatea este proprietatea unui program de a fi executat pe alte tipuri de
calculatoare sau interacţionând cu alte sisteme de operare.
Corectitudinea pune în evidenţã mãsura în care produsul îndeplineşte cerinţele
definite prin specificaţii. Se comparã rezultatele (structural, completitudine, precizie)
obţinute efectiv cu cele proiectate la realizarea specificaţiilor folosind generatoare de
exemple de test. Corectitudinea se pune în evidenţã fie prin testãri, fie prin demonstraţie.
Realizarea programului ca ansamblu de module îl înzestreazã cu capacitãţi
specifice de deschidere, de interconectare, asociate caracteristicii de modularitate.
Tehnicile de programare avansate (programarea structuratã, programarea orientatã
obiect) determinã construcţii de secvenţe care uşureazã înţelegerea semnificaţiei pãrţilor
de program atât în vederea depanãrii, cât mai ales la testarea ce urmeazã unui proces de
dezvoltare software. Programul, ca produs final, este mai mult sau mai puţin liniar, strict
dependent de traiectoriile pe care le au sensurile execuţiei instrucţiunilor (apeluri de
funcţii, instrucţiuni de control, instrucţiuni de salt necondiţionat).
La scrierea unei proceduri/funcţii se are în vedere posibilitatea reutilizãrii în alte
programe ca singurã modalitate de a economisi muncã vie, cu efecte asupra creşterii
productivitãţii în activitatea de programare.
Reutilizabilitatea este posibilã în mãsura în care procedura/funcţia este înzestratã
cu un nivel de generalitate suficient de ridicat. Adicã înglobeazã posibilitãţi multiple de
prelucrare, inclusiv cazuri particulare.
Lizibilitatea este caracteristica programului de a conţine suficiente informaţii atât
prin numele de variabile, etichete, funcţii legate de semnificaţia lor realã, cât şi
comentariile lãmuritoare care preced secvenţe de cod.
Toleranţa la erori, robusteţea sunt însuşiri ale produselor software care au aceeaşi
semnificaţie pe care o întâlnim la produse industriale sau la servicii.
Interoperabilitatea unui program este însuşirea acestuia de a putea fi apelat de alte
programe, de a fi integrat în aplicaţii deja în uz sau de a utiliza baze de date existente în
mod direct sau prin elaborare de interfeţe.
Asemeni unui produs/serviciu industrial (de serie, de masã) utilizabilitatea unui
program revine la uşurinţa de a înţelege prelucrãrile pe care le executã, facilitãţile cu care
este înzestart, uşurinţa de introduce date şi de a selecta opţiuni, uşurinţa de a învãţa lucrul
cu respectivul program.
Eficienţa unui program este pusã în evidenţã prin raportarea consumurilor de
resurse şi a cheltuielilor bãneşti pe care le antreneazã realizarea şi utilizarea sa la alte
programe cu specificaţii identice sau foarte apropiate.
Metricile software opereazã cu factori - în realitate caracteristici de calitate.
Fiecãrei 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
fiabilitãţii unui program (Musa, Jelinski Moranda, Poisson logaritmic, Goel Okumoto).
De asemenea, pentru evaluarea complexitãţii software s-au construit numeroase modele
(Halstead, Mc Cabe).
Metricile schimbã modul de interpretare, în sensul realizãrii unor relaţii (modele,
indicatori) care evalueazã nivelul caracteristicii de calitate, urmãrind simultan şi
posibilitatea de a-l integra în subintervale de acceptabilitate/inacceptabilitate.
Aşa se explicã faptul cã în zona metricilor sofware se operezã cu factorii:
eficienţã, funcţionalitate, mentenabilitate, portabilitate, fiabilitate şi cu subfactorii asociaţi
[10], tabelul nr. 1.

TABELUL NR.1 economie de timp

EFICIENÞÃ
FACTORI economie de resurseSUBFACTORI
completitudin
e
corectitudine
FUNCÞIONALITATE securitate
compatibilitat
e
interoperabilitate
capacitate de a corecta
MENTENABILITATE expandabilitate
test abilitate
hardware
independenþã
software
PORTABILITATE instabilitate
reutilizabilitat
e
nondeficienþã - gradul în care nu
conþin erori nedetectabile
FIABILITATE toleranþe la erori
disponibilitate
 Pentru fiecare factor şi pentru subfactorii sãi se constituie diagrame de legãturã
care conduc spre metrici software acceptabile, figura 1.

{
FACTORSUBFACTORTIP
{
METRICÃMETRICÃduratãFuncþionalitateCompletitudineVolumlungimeratãvolu
m textCorectitudineTestarenr. reluãriSecuritatevolum activãripredicþie
resurseCompatibilitateEfort adaptaretimp
{
om/lunãproductivitateInteroperabilitatenumãrnumãr apeluriintegrãrivolum interfeþe

{
Fig. 1 - Diagrama de legãturã factor - subfactor - metrici

Problema construirii metricilor este de fapt o problemã a agregãrii de informaţii.

Rezultatul final este o mãrime în general adimensionalã obţinutã dintr-o ecuaţie
de forma:

[u]
m= = [u]0 = [i]
[u]
unde:
[u] - unitatea de mãsurã a factorului
[i] - elementul neutru în mulţimea unitãţilor de mãsurã [u]
m - nivelul adimensional asociat factorului
 În aceastã tipologie de metrici software se definesc:

fiabilitatea = numãr rulãri de succes

numãr total rulãri

mentenanţa = numãr erori corectat

numãr total erori

numãr componente activate

testabilitatea =
numãr total componente

numãr interfeþe compatibil

interoperabilitatea = numãr total interfeþe

numãr componente gãsite corecte

corectitudine = numãr total componente

numãr componente libere de contradicþii

consistenţã = numãr total componente

timp înþelegere program comentat

lizibilitate =
timp înþelegere program lipsit de comentarii

Observãm cã aceste definiţii se caracterizeazã prin:

- simplitatea specificã raportului care presupune parte (la numãrãtor) şi întregul
(la numitor); ambele se definesc riguros;
- nivelul obţinut este cuprins în intervalul [0,1];
- definirea numitorului şi a numãrãtorului eliminã elementele subiective, bazându-
se pe realitãţi direct mãsurabile;
- deplasarea valorilor cãtre limita superioarã a intervalului aratã înzestrarea
programului cu caracteristica de calitate respectivã.
Aceste metrici se analizeazã în raport cu însuşirile specifice indicatorilor (caracter
compensatoriu, senzitivitate şi stabilitate).
Dacã se considerã un program oarecare p din mulţimea P, un factor F şi o metricã
m:P→[0,1],

m = α (p) ,
β (p)
unde:
α (p) - un numãr de elemente ce caracterizeazã o parte a situaţiilor favorabile;
β (p) - un numãr care corespunde tuturor situaţiilor posibile;
p - este un program oarecare aparţinând mulţimii P, metrica ne apare ca un raport
de frecvenţe.
Pentru programelePi şi Pj considerate se vor obţine nivelele:

α (Pi) α (Pj)
mi = şi mj =
β (Pi) β (Pj)

Deşi programele sunt diferite pornind chiar de la specificaţiile dupã care au fost
realizate, este posibil ca mi = mj.
Senzitivitatea este proprietatea de a obţine la variaţii mici ale lui α (P) sau β (P),
variaţii mari ale lui m.
Proprietãţile rapoartelor pun în evidenţã cã:

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

în anumite condiţii rãmâne constant, depinzând de valorile lui k1 şi k2 reducând simţitor

senzitivitatea acestui tip de metricã.
Stabilitatea metricii se menţine la un nivel satisfãcãtor dacã variaţiile numitorului
rãmân în zone acceptabile. Referirile se fac mai ales pentru situaţiile normale, când
programul este realizat din start dupã un minim cel puţin de condiţii de calitate.
În situaţia în care, pentru asigurarea mentenabilitãţii, sunt necesare consumuri de
resurse ce depãşesc elaborarea unui nou produs de acelaşi 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 fişier. Un fişier are o lungime.
Lungimea se exprimã fie ca numãr de baiţi, fie ca numãr de articole. În toate cazurile
existã o aproximare grosierã a lungimii fişierului ca lungime a programului.
Dacã programatorul respectã o serie de reguli de scriere a programului (stil de
programare), se poate obţine o legãturã între articol şi numãr de instrucţiuni pãrogram
sursã într-un articol.
Designul programului impune pentru lizibilitate o dispersare a secvenţelor cu
introducere de blancuri pe linii în textul sursã.
Dacã fişierul sursã se normalizeazã printr-un procedeu mecanic asigurându-se, pe
cât posibil, un raport constant între numãrul de instrucţiuni pe articol, lungimea fişierului
exprimã fidel o caracteristicã de bazã a programului - lungimea.
Programul conţine: definiri de variabile, referiri de variabile, instrucţiuni, apeluri
de funcţii, evaluãri de expresii. Toate pot fi contorizate. Metricile pe text sursã definesc
modalitãţi de extragere din acesta, prin numãrare, a însuşirilor ficãrui program în parte.
De exemplu, în [13] pornind de la numãrul operanzilor (n1) şi de la numãrul
operatorilor (n2) se construiesc relaţiile (indicatori Halstead):
• n = n1 + n2,
unde n reprezintã vocabularul utilizat în program.
• N = N1 + N2,
unde:
N1 - numãrul de operanzi care apar în program;
N2 - numãrul de apariţii 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 defineşte 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 transformãrii programului
în volum de operaţii exprimat prin cicluri maşinã. Se considerã instrucţiunile executabile
I1, I2,..., In existente într-un limbaj de programare şi coeficienţii C1, C2,..., Cn care
reprezintã numãrul standard (mediu) de cicluri maşinã asociat fiecãrei instrucţiuni. Pentru
a calcula numãrul total de cicluri maşinã ale unui program, se procedeazã la
descompunerea acestuia în instrucţiuni care formeazã structuri liniare sau în secvenţe
care alcãtuiesc structuri neliniare (structuri repetitive şi structuri alternative).
Numãrul de cicluri ia în considerare tipuri de operanzi, moduri de adresare şi
dispuneri în segmente.
Este importantã identificarea riguroasã a operaţiilor elementare care se asociazã
unei instrucţiuni.
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 funcţii.
Volumul de operaţii în acest caz ia în calcul:
- apelul funcţiei (salt necondiţionat spre prima instrucţiune executabilã din
funcţie);
- salvãrile pe stivã a unor registre;
- salvarea registrului BP;
- manipularea cu operanzii transmişi ca parametri în modul de adresare indirectã;
- prelucrãrile propriu-zise ale funcţiei;
- restaurare de registre pe stivã;
- salt necondiţionat în funcţia apelatoare.
Acest volum notat R, va conţine subexpresii de forma:
n

R1 = ∑
j=1
Cj P j ,
unde:
Cj - nr. mediu de cicluri maşinã pentru instrucţiunea Ij ;
Pj - frecvenţa de apariţie a instrucţiunii Ij în structura liniarã S1 ;
R1 - numãrul total de cicluri maşinã asociat structurii S1 ;
n

R2 = n ∑ Cj P j + α ,
j=1

unde:
n - numãrul de repetãri ale secvenţei S1 la care se includ incrementãrile şi testele
variabile de control, precum şi salturile la secvenţa de repetat;
α - numãr constant de cicluri ce corespunde iniţializãrii variabilei de control şi
pregãtirii secvenţei repetitive;
R2 - numãr total de cicluri maşinã asociat unei structuri repetitive.
n m

R3 = P ∑ Cj P j + q ∑ Cj P j + β ,
j=1 j=1

unde:
P - probabilitatea ca secvenţa S1 sã se execute dupã testarea condiţiei;
q - probabilitatea ca secvenţa S2 sã se execute dupã testarea condiţiei;
β - volum de cicluri asociat evaluãrii şi testãrii unei expresii numite condiţie;
R3 - numãrul total de cicluri maşinã 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 corespunzãtoare. Se
preiau din tabele numãrul de cicluri maşinã asociat fiecãrei instrucţiuni asembler şi se
determinã volumul mediu de cicluri pe instrucţiune/expresie din limbajul C/C + +.
Odatã coeficienţii Cj estimaţi, un alt program calculeazã volumul oricãrui
program.
Metrici software cu folosirea grafului asociat programului
Instrucţiunile dintr-un program se considerã noduri în graf. Sensul de parcurgere
(execuţie) a instrucţiunilor reprezintã arcele care leagã instrucţiuni.
Expresiile de atribuire, apelurile de funcţii, incrementãrile/decrementãrile
alcãtuiesc structuri liniare cãrora le corespund reprezentanta sub formã de graf datã în
figura 2.
     ••••• 

Fig. 2 Instrucţiuni în secvenţã liniarã

Instrucţiunile condiţionale şi operatorul condiţional genereazã reprezentãrile pe

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




 


  

 

b)
a)

Fig. 3 Implementarea structurii alternative

Instrucţiunea alternativã multiplã (switch) în limbajul C/C + + şi case în limbajul Pascal
genereazã reprezentarea pe graf datã în figura 4, numãrul de arce care pleacã din nodul
asociat condiţiei depinzând de numãrul expresiilor pentru care se opereazã selectãri.

  

  

Fig. 4 Implementarea structurii alternative multiple

 Structurii repetitive condiţionatã anterior WHILE - DO îi corespunde
reprezentarea pe graf datã în figura 5.




Fig. 5 Implementarea structurii repetitive condiţionate anterior

Structurii repetitive condiţionate posteroir DO - UNTIL îi corespunde

reprezenterea pe graf din figura 6.

Fig. 6 Implementarea structurii repetitive

condiţionate posterior

Structurilor îmbricate le vor corespunde agregãri în grafuri care conduc la

creşterea numãrului de noduri şi respectiv a numãrului de arce. În [26] se face referire la
relaţia propusã de Mc Cabe pentru calculul numãrului ciclomatic NC dat de relaţia:
NC = e - n +1 ,
unde:
e - reprezintã numãrul de arce ale grafului;
 n - reprezintã numãrul de noduri din graf.
Pentru numãrul ciclomatic mai existã şi alte formule. Nodurile şi arcele în aceste
modele nu sunt diferenţiate, deşi în realitate instrucţiunilor le corespund numãr de cicluri
maşinã diferite, deşi salturile în interiorul segmentului au alte caracteristici decât cele
intersegmente. Dacã nodurilor li se asociazã numere (cicluri maşinã) şi arcelor li se
asociazã distanţe (etichete) este posibilã construirea de metrici pe graf care sã includã şi
diferenţele dintre noduri, respectiv arce.
Oricãrui program i se asociazã o structurã atunci când el este privit ca rezultat al
asamblãrii unor module. În stadiul de proiectare se definesc module prin :
- parametrii care se transmit;
- nivel de apel al modului;
- numãr de module apelate;
- complexitatea prelucrãrilor din modul.

Se asociazã coeficienţi pentru grade de reprezentare a celor patru trãsãturi ş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 coeficienţilor definiţi 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 - intrãri cerute pentru prelucrare;
Mp - intrãri modificate la execuţia modului;
 Cm - intrãri care controleazã decizia şi selecţia;
Tm - date care se transmit modulului, sunt utilizate dar nu sunt modificate.
Coeficienţii asociaţi sunt daţi î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 adiţionalã care apare când 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:
- cerinţe de dezvoltare;
- nivel cerut al fiabilitãţii;
- complexitate produs;
- timp execuţie;
- restricţii de memorie;
- capabilitãţi analişti;
- experienţã în aplicaţii;
- capabilitãţi programatori;
 - experienţã în utilizarea limbajului;
- tehnici de programare utilizate;
- grad utilizare instrumente.
Ponderile sunt pentru nivelele:
- foarte scãzut;
- scãzut;
- normal;
- ridicat;
- foarte ridicat.
A şasea coloanã a matricei este destinatã valorii obţinute pentru evaluarea factorului.
Modelul lui ALBRECHT ia în considerare matricea de ponderi:

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

linia 1 - numãr intrãri;

linia 2 - numãr ieşiri;
linia 3 - numãr fişiere interne;
linia 4 - numãr fişiere externe;
linia 5 - numãr cereri externe.
Cele trei coloane reprezintã nivelele de complexitate:
- scãzut;
- 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 condiţia definirii
unui sistem de ponderi care reflectã importanţa fie a legãturilor dintre module, fie a
efortului de realizare / asamblare.
Metrici de comportament al programelor
 Programele se construiesc în vederea utilizãrii. Seturile de date de intrare se
caracterizeazã prin volum, dimensiune, valori particulare, repetiţii, parametrii de selecţie,
opţiuni etc. Pentru fiecare program se definesc exact semnificaţiile acestora, aşa fel încât,
utilizatorii sdã înregistreze cu rigurozitate şi în acelaşi mod comportamentul programului.
Dacã se considerã un program care lucreazã cu un fişier, se stabileşte numãrul de articole
din fişier, numãrul de actualizãri, structurile rapoartelor finale. Utilizatorul priveşte sub
formã tabelarã standard ceea ce trebuie completat, fãrã a-i lãsa loc pentru interpretãri cu
caracter local sau subiectiv.
Se înregistreazã numai valori obiective ( numãr înregistrãri, numãr linii, numãr
coloane, numãr elemente, numãr actualizãri, numãr erori, numãr reluãri, numãr corecţii în
date, numãr rapoarte, numãr rânduri, duratã introducere date, numãr erori introducere
date, duratã compilare, duratã execuţie, duratã sortare, duratã ştergere etc.) În toate
cazurile se specificã cu exactitate elementele de pe fiecare rând al tabelelor, fãrã a lãsa
coloane necompletate. Toate datele culese de la utilizatori se constituie în baze de date
ale comportamentului unui program. Datele conţin momente, durate, frecvenţe, volume,
dimensiuni. Omogenitatea, ca unitãţi de mãsurã, permite efectuarea de operaţii de
adunare a seriilor ( de timp).
Se calculeazã :
- durate medii ( de execuţie, de compilare, de eliminare erori, de introducere
date);

α
- rapoarte de forma r = , unde:
β
a - reprezintã frecvenţe de apariţie a unui caz
selectat;
b - reprezintã totalitatea cazurilor studiate;
- corelaţii între seriile de date provenind din tabele;
- grupãri dupã metodele analizei de date a elementelor din tabele şi clasificarea
programelor, tipurilor de probleme, erorilor;
- estimarea unor coeficienţi pentru modele care pun în evidenţã legãturi între
seriile de date din tabele, serii care se vor constitui în înregistrãri ale unor variabile în
baze de date. În [29] , [38] sunt prezentate astfel de modele.
 Se considerã SM = luni/om şi KDSI = mii de instrucţiuni scrise (estimate).
Pornind de la aceste notaţii, se iau în considerare diferite proiecte. Pentru proiectele
organice, se considerã expresiile:
SM = 2.4 (KDSI) 1.05 şi timpul necesar realizãrii 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 cunoaşterea modului în care un
program rãspunde cerinţelor efective la utilizator. Dacã programul este riguros testat se
obţin cu baze de date de la aceastã operaţie parametrii care nu diferã semnificativ faţã de
valorile estimale ale coeficinţilor metricelor de comportament. Econometria dispune de
numeroase tehnici de estimare şi de analizã a calitãţii coeficienţilor. Deşi aceste modele
sunt mai des întrebuinţate, fluctuaţiile coeficienţilor estimaţi depind de eşantionul 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,
completându-se.
Este necesar sã se defineascã metrici de toate tipurile pentru un produs, pentru a
rãspunde cerinţelor atât formulate de programatori, de dealeri, cât şi de utilizatorii
programelor. Metricile sunt cu atât mai valoroase cu cât sunt mai simple de calculat şi cu
cât efortul de a culege datele este mai redus. Este preferabil ca proiectanţii, odatã cu
lansarea unei metrici software, sã ofere şi instrumentele pentru culegerea automatã a
datelor obiective despre programele care fac obiectul evaluãrii şi sã calculeze nivelele
pentru aceste programe.

Proprietãţile metricilor software

Dacã metricile definite pe o mulţime M se bucurã de o serie de proprietãţi,

particularitãţile metricilor software genereazã alte proprietãţi. Astfel, în [10], [12] , [29]
sunt puse în evidenţã proprietãţi 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 situaţii anormale când se fac studii
empirice;
P4 : dacã o metricã derivã dintr-o altã metricã, apartenenţele programelor la
subclase nu se modificã;
P5 : modificãrilor neutre din program nu le corespund creşteri sau diminuãri ale
valorilor rezultate dintr-o metricã;
P6 : modificãrilor limitate din program le corespund creşteri sau diminuãri limitate
ale valorilor rezultat dintr-o metricã;
P7 : creşterea numãrului de variabile exogene conduce la creşterea gradului de
mãsurabiliate asociat metricii;
P8 : modificãrilor active din program trebuie sã le corespundã diminuãri sau
creşteri ale valorilor rezultate dintr-o metricã.
Proprietãţile metricilor sunt puse în evidenţã prin parcurgerea unor paşi şi anume :
- construirea unui sistem al specificaţiilor;
- definirea ierarhiilor asociate modulelor din care este format programul;
- se calculeazã pentru fiecare modul o serie de indicatori ( pe text, structurã sau
dinamicã);
- indicatorii calculaţi se agregã rezultând 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 arborescenţei spre rãdãcinã,
cu asigurarea apartenenţei la intervalul [0,1] a oricãrei agregãri. Se considerã programul P
cu structura arborescentã din figura 7 .
 α
8

α α
6 7
α α α α α
1 m 2 m m3 m4 m 5

1 2 3 4 5

Fig. 7 Arborescenţa 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 încât :
a1 + a2 + a3 + a4 + a5 + a6 + a7 + a8 = 1
Se construiesc relaţiile 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 proprietãţilor (senzibilitate, consistenţã, caracter
necompensatoriu) acestui indicator nou agregat al fiabilitãţii.
Sistemul de ponderi ai este de mare importanţã în a asigura metricii veridicitatea
în confruntarea cu fiabilitatea, ca evaluare a unui comportament real ( numãr rulãri de
succes / numãr total de rulãri program).
Construirea de metrici sub forma de modele permite deplasarea proprietãţilor
metricii în zona axiomelor modelelor, fie cu o variabilã, fie cu mai multe variabile. Dacã
modelului i se identificã o serie de proprietãţi, este necesarã verificarea acestora şi în
cazul mulţimilor de programe pentru care metrica este construitã. În cazul în care aceste
proprietãţi nu au corespondent în zona programelor, modelul, indiferent cât de interesant
este, va fi abandonat.

Validarea unei metrici

 Metricile software se construiesc pentru a oferi informaţii cât mai exacte asupra
calitãţii programelor. În toate cazurile, metricile au un caracter predictiv. Dacã s-a
încheiat ciclul de viaţã al unui program explorând baza de date a comportamentului sãu şi
prin aplicarea metricilor, într-adevãr 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ã
informaţii asupra a ceea ce este programul sau asupra unui comportament efectiv pe un
interval de timp trecut, în vederea extrapolãrii comportamentului pentru intervale de timp
viitoare.
Validarea unei metrici este problema acceptãrii acesteia ca modalitate de
extrapolare.
Se considerã mulţimea 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
P1 P2 P3 P4 P

Fig. 8

Mãrimea m (Pi) = a este consideratã nivel critic.

Dupã un timp, fãrã a efectua modificãri asupra elementelor din mulţimea P, prin
consultarea unui lot semnificativ al utilizatorilor de programe se identificã urmãtoarele
situaţii :
a) elementele din submulţimea P- s-au comportat inacceptabil, iar elementele din
submilţimea P+ s-au comportat acceptabil;
 b) au existat elemente din submulţimea P-, considerate iniţial inacceptabile, care s-
au comportat acceptabil, iar elementele mulţimii P+ s-au comportat în totalitate
acceptabil;
c) au existat elemente din submulţimea P+ care s-au comportat inacceptabil, în
timp ce elementele submulţimii P- s-au comportat în totalitate inacceptabil;
d) existã elemente din submulţimea P- care s-au comportat acceptabil, iar unele
elemente din submulţimea P+ s-au comportat inacceptabil;
e) toate elementele submulţimii P+ s-au comportat inacceptabil, iar toate
elementele submulţimii P- s-au comportat acceptabil.
Dacã P- şi P+ sunt submulţimile generate de metrica m: P [0,1], submulţimile
U- şi U+ sunt rezultatele aprecierii de cãtre utilizatori, atunci:
P- ∪ P+ = P U- ∪ U+ = P
P-∩ P+ = ∅ U- ∩ U+ = ∅
Cazurile a şi e sunt uşor 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 stânga, respectiv spre dreapta a nivelului
critic a.
Cazul d ia în considerare riscul pe care îl prezintã migrarea dinspre submulţimea
P- spre submulţimea P+, respectiv migrarea dinspre submulţimea P+ spre submulţimea P-.
Aparatul statistic existent permite abordãri multiple. Se construieşte 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 situaţii speciale, se obţin grupãri de
programe şi se stabilesc, prin metodele analizei de date, situaţiile în care o metricã este
mai adecvatã decât 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 lucrãri care conţin 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 cãpãta încredere în ei. Metodologia metricii existã. Ceea ce trebuie însã
delimitat, trebuie legat de implementare.
Toate modelele sunt construcţii interesante. De la definirea unui model pentru
factor, pânã la utilizarea efectivã, este un drum lung, aproape imposibil de parcurs.
Pentru crearea de metrici operaţionale este necesarã parcurgerea etapelor
urmãtoare :
- definirea variabilelor exogene şi a modului exact, neambiguu de mãsurare; prin
exemple de mãsurare se va pune în evidenţã caracterul consistent al mulţimii de variabile
exogene şi faptul cã nu existã elemente din program care accidental nu sunt incluse în
model, deşi ele ocupã un rol important în arhitectura acestuia;
- construirea de software care sã mãsoare automat nivelele variabilelor exogene
din program;
- în toate cazurile de verificare a cestui software se va evidenţia cã într-adevãr
nivelele obţinute sunt corecte, neafectate de imperfecţiunile de definire/ identificare
conţinute în modulele acestui software;
- stabilirea de reguli exacte pentru construirea exemplelor de test sau a structurii
( diversitãţii) cazuisticii reale prin intermediul cãreia se înregistreazã nivelele de
comportament; în caz contrar, se vor obţine nivele ale factorilor care vor fi diferite
semnificativ de nivelele aceloraşi factori mãsurate la utilizarea efectivã la beneficiari a
programelor;
- crearea obligativitãţii ca producãtorii de software sã utilizeze un acelaşi produs
pentru evaluarea metricii pentru un factor, asigurîndu-se în acest fel compatibilitatea şi
deci comparabilitatea rezultatelor; schimbarea programului de evaluare a metricii
genereazã diferenţe ştiute fiind fluctuaţiile de interpretare şi de mãsurare 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. Perseverenţa de a construi instrumente pentru evaluarea
complexitãţii, pentru demonstrarea complexitãţii, 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
concepţia de lansare a noilor programe pe piaţa software.
Amploarea procesului de informatizare a societãţii româneşti impune eliminarea
paralelismelor în producţia de software, lansarea producţiei de programe prin licitaţii.
Orice altã abordare va restrânge numãrul şi complexitatea aplicaţiilor, scãzînd gradul de
cuprindere a acestui proces atât de necesar.Numai cuantificãrile oferite de utilizarea
curentã a metricilor software leagã strâns costul de calitatea software, singura condiţie 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