UNIVERSITATEA POLITEHNICA BUCURESTI

METRICI ALE COMPLEXITATII

SOFTWARE

Iliuta Virgil
Balint George
GRUPA 441A

Metrici software
Metricile software sunt modele(reguli) folosite pentru a masura cantitativ anumite
caracteristici ale sistemelor informatice. Metricile software nglobeaz modele,
indicatori i proprietile acestora, precum i modaliti de evaluare i validare.
Metricile software se folosesc pentru a reduce subiectivitatea aprecierii unui program.
Definitie matematica:
Metrica software este un model matematic dezvoltat n jurul unei ecuaii de forma:
y = f( x )
Un model matematic cuprinde una sau mai multe ecuaii, inecuaii i are una sau mai
multe funcii obiectiv, iar rolul lui este de a descriestarea sistemuluiasociat. Metrica
software are rolul de a msura o anumit caracteristic a unui produs program, lund
n calcul factorii ce influeneaz nivelul caracteristicii msurate. Aplicndu-se tuturor
produselor software dintr-un lot omogen, metrica devine instrumentul prin
intermediul cruia se efectueaz clasificri i ierarhizriale produselor software. O
metric software este funcie obiectiv a modelului matematic cruia i aparine,
dac prin aplicarea ei se are n vedere maximizarea sau minimizarea nivelului
caracteristicii cercetate n funcie de toi factorii deinfluen:
f(X) < sau f(X) >
unde:
X vectorul factorilor ce influeneaz caracteristica software msurat;
i niveluri limit admise.
Metrica software este restricie a modelului matematic dac plaseaz nivelul msurat
al caracteristicii ntr-un interval definit de:
< f(X) <
n timp ce modelul matematic are ca obiectiv definirea structurii software, metrica
creeaz condiiile care permit comparareai are caracter normativ

Gestionarea eficient a oricrui proces necesit cuantificare, msurare, i

modelare. Metricile software ofer o baz cantitativ pentru dezvoltarea i validarea
modelelor procesului de dezvoltare software. Metricile pot fi utilizate pentru
mbuntirea productivitatii i calitatii software. Dei curent msurtorile i
modelele sunt cu siguran inadecvate, un numar de organizaii au rezultate
promitoare prin utilizarea lor.

Functii indeplinite:
Metricile software au rolul de a realiza:
Funcia de msurare. Cu siguran cea mai important funcie a metricilor software,
msurarea reprezint obiectivul principal n jurul cruia sunt dezvoltate aceste
instrumente. Produsele software aparin unui domeniu strict obiectiv, n care orice
realizare are fundamente matematice i caracteristici descrise de valori numerice,
deci care sunt msurabile i reprezentate prin numere. La baza tuturor indicatorilor i
chiar la baza sistemului de caracteristici de calitate definit de standardul IEEE se
gsesc datele primare, obinute prin simplele nregistrri ale nivelurilor
caracteristicilor software: numrul de linii surs, numrul de rulri, numrul de erori,
numrul de instruciuni, numrul de cicluri main. Cum n ansamblul analizei lotului
de produse software aceste date sunt considerate de baz, ele sunt supuse unor
prelucrri ulterioare prin introducerea de metrici agregate, adncind astfel cercetarea.
Rezultatul utilizrii unei metrici este exprimat n uniti concrete de msur i are o
poziie precis n sistemul de metrici software prin intermediul cruia este descris un
lot de program.
Funcia de comparare. Scopul final al utilizrii metricilor software este de a analiza
din punctul de vedere al unei caracteristici software un program i de a-l compara cu
el nsui , ncadrndu-l ntr-o categorie definit de programe, sau de a-l compara cu
alte produse software, plasndu-l pe o anumit treapt din ierarhia software.
Comparare se rezum la realizarea diferenei ntre doi termeni exprimai n aceeai
unitate de msur cu verificarea poziiei rezultatului fa de 0, sau la calcularea
raportului, cu verificarea poziiei rezultatului fa de 1.
Funcia de analiz. Rezult din dorina de a da semnificaie rezultatelor numerice
obinute prin aplicarea modelelor matematice asociate metricilor. n finalul analizei,
pe baza numerelor obinute, produsului software i se confer caliti ca fiabilitate,
economie de timp, economie de resurse, caliti care sunt mult mai puternice i mai
semnificative dect simplele valori numerice din care sunt deduse.
Funcia de sintez. n situaia cercetrii pe grupe generale de produse software, de
exemplu analiza statistica a programelor scrise n limbajul C++ i Pascal, este
imposibil verificarea tuturor programelor scrise ntr-unul din limbaje i se
construiesc loturi omogene cu numr optim de programe. Valorile msurate prin
utilizarea diferitelor metrici sintetizeaz ntr-o singur expresie numeric ceea ce este
esenial i tipic pentru ntreaga categorie de programe.
Funcia de estimare. Metrica software, asemenea indicatorilor statistici, este folosit
pentru msurarea tendinei de cretere\scdere a nivelului caracteristicii software
cercetate, plecndu-se de la ipoteza c variabilele sunt aceleai.
Funcia de verificare. Rezultatele obinute aplicnd metrica software sunt totodat
utilizate pentru a confirma i ntri sau pentru a infirma concluziile obinute prin alte
metode. Utilizarea unei metrici software n practic implic ipoteza validrii acesteia
i asigurarea independenei rezultatelor.

Criza software trebuie s fie abordata i, in msura n care este posibil,

rezolvata. Pentru a face acest lucru se necesit mai multe programe exacte i estimri
de costuri, calitate mai bun pentru produse, i productivitate mai mare. Toate
acestea pot fi realizate printr-un management software mai eficient , care, la rndul
su, poate fi facilitat prin utilizarea de metrici software.
Managementul software curent este ineficient, deoarece dezvoltarea software
este extrem de complexa, i avem doar cteva msuri de ncredere bine definite din
procese sau produse pentru a ndruma i evalua dezvoltarea. Estimarea eficienta si
exacta, planificarea, i controlul sunt aproape imposibil de realizat . mbuntirea
procesului de gestionare a lucrului depinde de abilitatea mbuntit de a identifica,
msura, i controla parametrii eseniali ai dezvoltrii proceselor. Acesta este scopul
indicatorilor Software. Identificarea i msurarea sunt esenialii parametri care
afecteaz dezvoltarea de software.
Metricile software i modele au fost propuse i folosite de ceva timp.
Rezultatele recente indic c punerea n aplicare a unei combinaii ntre un program
software si metrici poate ajuta la atingerea unor rezultate mai bune, att pe termen
scurt (pentru un anumit proiect) cat si pe termen lung (mbuntirea productivitatii
pentru proiecte viitoare). O mai bun utilizare a metricilor existente pare a fi un
factor important n rezolvarea crizei software-ului.
Definitia Metricii Software
Este important s se defineasc n continuare software-ul. n esen, softwareul se ocup cu msurtorile produsului software i a procesului prin care acesta este
dezvoltat. n aceast discuie, produsul software ar trebui s fie privit ca un obiect
abstract care evolueaz de la o declaraie iniial de necesitate la un sistem software
terminat , inclusiv codul surs i codul obiect i diverse forme de documentare
produse n timpul de dezvoltare.
n mod obinuit, aceste sunt studiate i dezvoltate pentru utilizarea n modelarea
de procese software. Aceste valori i modele sunt apoi folosite pentru a estima /
anticipa costurile produselor i s msoare productivitatea i calitatea produselor.
Informatiile obinute din msurtori apoi pot fi utilizate n gestionarea i controlul
dezvoltarii procesului de mbuntire a rezultatelor.
Msurtorile bune ar trebui s faciliteze dezvoltarea de modelele care sunt
capabile de a prezice un proces sau parametrii de produs, nu doar a le descrie. Astfel,
metricele ideale ar trebui sa fie simple si precis definite, astfel nct s fie
clar cum o metrica poate fi evaluat:
obiectiv, n cea mai mare msur posibil;
cu un cost rezonabil
uor de obinut
metrica ar trebui s msoare ceea ce este destinat s msoare
insensibila la modificri nesemnificative n procesul de dezvoltare al
produsului .

n plus, pentru utilitate maxim n studiile analitice i analizele statistice,

msurtorile ar trebui s aib valori care aparin de msuratoarea
corespunztoare.
. Caliti fundamentale necesare pentru orice sistem tehnic sunt:
funcionalitate,corectitudine, fiabilitate
performan, timp de rspuns, debit, viteza
Cost scazut, eficacitate.
Performana este cu siguran importanta, dar nu este inclusa n cadrul discuiilor
de software, cu o excepie n ceea ce privete dac produsul ndeplinete cerinele
specifice de performan pentru acest produs.
Evaluarea performantei este deseori tratata de ctre cei implicai n evaluarii de
performan, studii de renovare, dar acestea nu sunt n general incluse n ceea ce este
cunoscut ca metrica software
.
Este posibil ca, n viitor, domeniul de aplicare al metricilor software sa fie extins
pentru a include performana si evaluarea, sau ca ambele activiti sa poata fi
considerate parte dintr-o suprafa mai mare care ar putea fi numit software de
msurare.
Complexitatea software este o caracteristic de calitate care se regsete n
calculul devizelor pentru dezvoltarea software i pentru corectarea indicatorului de
producti-vitate a programatorilor.
Metricile software s-au definit pe baza a trei surse: metrici bazate pe textul
surs, metrici bazate pe graful asociat programului, metrici de comportament care
nre-gistreaz niveluri ale parametrilor n tim-pul execuiei programului.
Caracteristici:
Simplitate: Definirea si utilizarea metricilor este una simpla.
Obiective: Masuratori facute de persone diferite au acelasi rezultat.
Usor de colectat: Efortul si costurile colectarii datelor necesare este acceptabil.
Robuste: Sunt insensitive la schimba minore permitand comparatii utile.
Valide: Masuratorile facute evidentiaza situatia reala.
Exemple de Metrici
1.
Numar de linii de cod
2.
Densitatea comentariilor
3.
Fiabilitatea
4.
Mentenanta
5.
Testabilitate
6.
Interoperabilitate
7.
Corectitudine
8.
Cosistenta
9.
Lizibilitate
5

10.
11.

Bug-uri pe numarul e linii de cod

COCOMO (COnstructive COst Model)

Metrici de complexitate
1. Complexitatea ciclomatica
Utilizeaza Graful de Control al programului. Ipoteza: dificultatea de intelegere
a unui program este in mare masura determinata de complexitatea grafului
fluxului de control
Este o masura a dificultatii de testare a modulelor si a fiabilitatii la nivel de
modul.

Complexitatea unei entitati este determinata de relatiile dintre partile sale.

Partile unui modul software sunt instructiunile sale. Relatiile dintre ele se bazeaza pe
trei structuri:
Secventa: bloc maximal indivizibil de instructiuni care se executa intotdeauna in
aceeasi ordine
Selectia (conditia)
Iteratia (ciclul). Iteratia poate fi simulata prin salt la o conditie.
Complexitatea ciclomatica este definita pentru un modul pe baza grafului de control al
modulului.
McCabe defineste complexitatea ciclomatica a unui graf de control astfel:
v=e-n+2
unde:
e este numarul de arce (edges);
n este numarul de noduri.
Pentru o secventa, v=1. Este necesara o singura executie de test pentru a executa
fiecare instructiune din secventa.
Fiecare salt adaugat la un modul creste complexitatea sa cu 1 si necesita o
executie de test suplimentara pentru testarea sa.
Deci, complexiatea ciclomatica a unui modul da numarul minim de executii de test ale
unui modul, pentru acoperirea tuturor arcelor.
Grafuri de control

Grafuri de control pentru structurile de control ale

Programarii structurate

Instructiunile de decizie cu mai multe predicate trebuie sa fie separate in predicate

simple inainte de masurarea complexitatii ciclomatice. De exemplu, decizia
if(A.and.B.andC)then.. trebuie separata in 3 decizii simple.

Metoda de testare structurala: complexitatea ciclomatica a unui modul sa fie

limitata la 10. Studiile arata ca erorile se concentreaza in module cu
complexitati mai mari ca aceasta limita.

In timpul proiectarii de detaliu limitarea trebuie sa fie la 7, deoarece

complexitatea creste intotdeauna in timpul codarii. Modulele care
depasesc aceasta limita trebuie sa fie reproiectate.

2. Complexitatea ciclomatica totala

Complexitatea ciclomatica totala a unui program se obtine insumand
complexitatile ciclomatice ale modulelor sale.
Este exprimata prin formula:
v = e - n + 2p
unde p este numarul de module.
e este numarul de arce din toate modulele
n este numarul de noduri din toate modulele
O formula echivalenta este:
v = v1+v2+..+vp
unde v1, v2, , vp sunt complexitatile ciclomatice ale celor p module.

Combinand mai multe module intr-unul singur va rezulta un modul cu o

complexitate ciclomatica mai mare decat a modulelor combinate dar mai
mica decat complexitatea totala.
Descompunerea unui modul in module mai mici creste complexitatea totala
dar reduce complexitatea la nivelul fiecarui modul.

3. Complexitatea proiectarii modulelor

Complexitatea proiectarii unui modul, notata de McCabe cu iv, masoara efectul

individual al unui modul asupra proiectului programului.
Complexitatea proiectarii unui modul este evaluata plecand de la graful de control al
modulului si marcand nodurile care contin apeluri de module externe.
Graful de control este apoi redus dupa urmatoarele reguli:
1. nodurile marcate nu pot fi eliminate;
2. nodurile nemarcate care nu contin decizii sunt eliminate;
3. arcele care intorc controlul la inceputul unui ciclu care contine numai
noduri nemarcate sunt eliminate
4. arcele care unesc nodul de start al unei instructiuni case cu nodul de sfarsit
sunt eliminate daca nici una dintre celelalte ramificatii ale instructiunii case nu
contin noduri marcate.

Exemplu:

Complexitatea proiectarii modulului este complexitatea ciclomatica a

grafului redus (iv = e-n+2)
Complexitatea proiectarii modulului ignora caile acoperite in testarea
modulului, care nu contin apeluri de module externe. Caile ramase sunt
necesare pentru a testa interfetele modulului.

4. Complexitatea proiectarii unui ansamblu de module

S0 = iv1 + iv2 .. + ivn

unde iv1, iv2, ivn sunt complexitatile de proiectare ale modulelor din ansamblu.

10

5. Complexitatea integrarii
Complexitatea integrarii unui ansamblu de N module, notata de McCabe cu S1,
Este definita astfel:
S1 = S 0 - N + 1
Complexitatea integrarii a N module care nu contin ramificatii este deci 1.

Formal, complexitatea integrarii necesita masurarea complexitatii proiectarii

fiecarui modul.
In timpul proiectarii arhitecturale, de regula, nu este disponibil graful fluxului
de control al fiecarui modul. Totusi, ar trebui sa fie disponibila suficienta
informatie pentru a defini complexitatea proiectarii fiecarui modul, chiar
fara a cunoaste logica modulelor.

Figura urmatoare reda o diagrama de structura prin care se ilustreaza cum trebuie
evaluata S1 cunoscand doar conditiile de apel ale fiecarei componente, adica fluxul
controlului.
Dreptunghiurile corespund componentelor de proiectare iar sagetile marcheaza fluxul
controlului. Prin romb se indica un transfer al controlului conditional:
componenta a apeleaza fie componenta b fie componenta c
componenta b apeleaza secvential componenta d si componenta e
componenta c apeleaza una dintre componentele e, f, g sau nici una
Complexitatea integrarii modulelor reprezentate in diagrama de structura este 5.

Estimarea complexitatii integrarii folosind diagrama de structura

6. Alte metrici ale proiectarii

Numarul de parametri
11

Determina puterea cuplarii intre module.

Intelegerea modulelor cu un numar mare de parametri cere mai mult timp
si efort.
Modificarea modulelor cu un numar mare de parametri poate avea efecte
asupra altor module.

Numarul de module apelate estimeaza complexitatea intretinerii

Pentru un modul:
Fan-in: numarul de module care il apeleaza
Fan-out: cate module sunt apelate de el
Fan-in mare: un numar mare de module depind de el
Fan-out mare: modulul depinde de multe module
Cuplarea prin date
Fie tripletul (p,X,q), unde:
o p si q sunt module
o X este o variabila accesibila din p si q
Cuplarea potentiala prin date:
o X este declarata in ambele, dar nu se verifica accesul la ea
o Reflecta posibilitatea ca p si q sa comunice prin variabila X
Cuplarea prin date utilizate
o p si q utilizeaza X.
o Mai greu de determinat decat cuplarea potentiala. Necesita mai multa
informatie despre logica interna a modulului.
Cuplarea prin date efectiva
o p atribuie o valoare lui X si q o refera.
o Cel mai greu de determinat, dar indica un flux de informatie de la p la
q.
Metrici ale coeziunii
Se construieste graful de flux pentru un modul
o Pentru fiecare nod, se inregistreaza variabilele referite in instructiunile
din nod
Se determina cat de multe cai independente ale modulului trec prin fiecare
nod
o Un modul are coeziune mare daca cea mai mare parte a variabilelor
sunt utilizate pe majoritatea cailor
o Cea mai mare coeziune: toate caile independente utilizeaza toate
variabilele din modul

COMPLEXITATEA HALSTEAD
Metrica Halstead este definita prin indicatorii:
C = complexitatea programului
E = efortul de programare
12

V = volumul programului
L = nivelul programului
unde:
6

C ni log 2 ni
i 1

sau, considernd 1 n1 n2 i

2 n3 n4 n5 n5

putem scrie:

C 1 log 2 1 2 log 2 2
6

V N log 2 ni

N ni*

i 1

i 1

ni* avnd aceeai semnificaie ca i ni , dar contorizeaz totalurile, nu numai pe cele

distincte.
V*
L
V
V* este volumul minim al programului, care este calculat din numrul minim de
parametrii I/O necesar pentru a specifica operaia unui algoritm i returul rezultatului,
avnd expresia:
V * * log 2 *
* 2* 2 ,
iar2 este numrul de parametri de I/O folosii n apelul programului.
*

V
L

cu:
n1 numrul de tipuri fundamentale de date care apar distinct n program
n2 numrul de tipuri derivate de date care apar distinct n program
n3 numrul de instruciuni distincte utilizate de programator
n4 numrul de operanzi distinci care apar n program
n5 numrul de operatori distinci pentru referire care apar n program
n6 numrul de funcii distincte apelate

3. COMPLEXITATEA MCCABE
Modelul McCabe este folosit pentru evaluarea complexitatii programelor. n
ipoteza omogenitatii perfecte a instructiunilor se construiesc grafuri asociate

13

secventelor de program, pentru care se masoara complexitatea, fiecare instructiune I1,

I2, In fiind reprezentata de un nod, ordinea de executie a acestora fiind evidentiata
cu ajutorul arcelor. De exemplu, pentru secventa de program S1:
1

Fig. 1. Graful asociat secventei de program S1

C = m-n+2, unde m este numarul arcelor din graf, iar n este numarul nodurilor
grafului. n secventa de program S1, complexitatea McCabe are valoarea
C=23+2=1. Pentru o secventa S2: A=B+1;
4
1

6
5

Complexitatea McCabe a acestuia are valoarea C=66+2=2. Se observa ca

valoarea complexitatii McCabe depinde de numarul de structuri alternative si de
numarul de cicluri cuprinse n secventa analizata. Valoarea complexitatii McCabe
este egala cu numarul maxim de drumuri liniare independente din graf. Studiile au
aratat ca exista o proportionalitate directa ntre complexitatea McCabe si frecventa
erorilor. O valoare mai mica de 10 a complexitatii McCabe reflecta structuri de
program de complexitate scazuta, usor de nteles si de modificat, riscul de aparitie a
erorilor fiind redus, n timp ce valori ale complexitatii McCabe mai mari de 50
caracterizeaza secvente de program greu de nteles, avnd un risc foarte mare de
aparitie a erorilor. Complexitatea McCabe este extinsa pentru a permite masurarea
complexitatii sistemelor informatice. Valoarea complexitatii McCabe este calculata n
faze avansate ale procesului de dezvoltare de software, neputnd fi un instrument
eficient n activitatea de management a proiectelor. E folosit ca instrument de
predictie a costurilor si eforturilor viitoare consumate n procesul de mentenanta.

1. LINII DE COD LOC

Produsul software poate fi evaluat n mod direct fie indirect. Prin evaluarea
direct a procesului de inginerie software se ntelege determinarea costurilor si a
eforturilor asociate. Ea presupune calculul numrului liniilor de cod (LOC - lines of
code) scrise, determinarea vitezei de executie, a dimensiunii memoriei, precum si a
numrului de defecte raportat ntr-un anumit interval de timp.
Evaluarea indirect a produsului reprezint n fapt o analiz a functionalittii,
calittii, complexittii, eficientei, fiabilittii, ntretinerii si multor altor caracteristici.
Costul si efortul necesar pentru a dezvolta software, calculul numrului de linii
de cod (LOC) precum si alte estimri directe sunt relativ usor de estimat initial.
Totusi, calitatea si functionalitatea sau eficienta si ntretinerea sunt mult mai dificil de
evaluat si pot fi msurate doar n mod indirect.
Metodele de evaluare ale produsului pot fi descrise dup cum urmeaz:

Evaluarea productiv se concentreaza asupra rezultatelor finale ale procesului

de inginerie software;
14

Evaluarea calitativ ofer o indicatie a ct de aproape este produsul software

de cerintele implicite si explicite ale clientului;
Evaluarea tehnic evidentiaz mai degraba caracteristicile produsului software
(ex.: complexitatea logic, gradul de modularizare) dect procesul prin care
acesta a fost dezvoltat;
Evaluarea dimensional este utilizat pentru a "colecta" evalurile directe ale
rezultatelor si calittii procesului de inginerie software;
Evaluarea functional ofer o evaluare indirect;
Evaluarea orientat pe resursele umane ofer informatii asupra modului n care
programatorii dezvolt un produs software precum si asupra perceptiei
eficientei instrumentelor si modelelor de dezvoltare.

n continuare vom face o abordare detaliat a dou dintre metodele de evaluare

expuse ce sunt mai frecvent utilizate de ctre casele de soft.

1. Metoda evalurii dimensionale

Evaluarea dimensional a produsului software reprezint o estimare direct a
acestuia precum si a procesului prin care el este dezvoltat. Daca un manager de
proiect mentine nregistrri simple, poate fi creat un tabel cu datele ordonate dupa
criteriul dimensiunii. Pentru fiecare proiect, datele dimensionale uzuale sunt:

efortul estimeaz necesarul de resurse umane si se msoar n programatoripe-lun sau programatori-pe-an;

KLOC (Kilo Lines of Code) - mii de linii de cod;
valoarea este exprimarea bnesc a efortului;
pagini de documentatie;
numrul de erori raportate de utilizatori ntr-o perioad de timp (de pild un
an).
numrul de programatori care au lucrat la dezvoltarea produsului software.

Din datele primare continute ntr-un astfel de tabel poate fi realizat o evaluare a
productivittii si una a calittii, orientate dimensional, pentru fiecare proiect n parte:
Productivitatea = KLOC / Programatori-pe-lun
Calitatea = Numr de erori / KLOC
n completare, pot fi calculati alti parametrii interesanti:
Cost = Valoare / KLOC
Documentatie = Pagini de documentatie / KLOC
Utilizarea parametrilor dimensionali (KLOC, efort, etc.) este controversat si
ei nu sunt universal acceptati ca reprezentnd cea mai bun metod de evaluare a
procesului de dezvoltare software. Controversa se nvrte n jurul utilizrii liniilor de
cod LOC ca mrime principal. Sustintorii variabilei LOC afirm c aceasta este un
artefact al tuturor proiectelor de dezvoltare software si poate fi usor calculat, c
multe modele de estimare utilizeaz LOC sau KLOC ca date de intrare principale si c

15

exist deja o literatur imens (plus date asociate) dedicat LOC. Pe de alta parte,
opozantii reclam c variabila LOC este dependent de limbajul de programare, c
LOC poate penaliza programe bine proiectate dar scurte, c nu se poate asocia usor
limbajelor neprocedurale si c utilizarea ei n estimare necesit un nivel de detaliere
care poate fi dificil de obtinut (ex: managerul de proiect trebuie s estimeze numrul
de linii de cod ce trebuie produse cu mult nainte ca analiza si proiectul programului
s fi fost ncheiate).

2. Evaluarea Functional
Parametrii ce caracterizeaz din punct de vedere functional produsul software
reprezint o evaluare indirect a acestuia si a procesului prin care el este dezvoltat.
Evitnd calculul LOC, parametri functionali se concentreaza asupra
"functionabilittii" sau "utilittii" programului. Acest tip de evaluare a fost propus
pentru o abordare prin msurarea productivittii, numit metoda scorului functional.
Scorul functional (SF) este obtinut utiliznd o relatie empiric bazat pe estimri
calculabile ale domeniului de informatie al produsului precum si pe evaluri ale
complexittii aplicatiei.
Valorile domeniului de informatie se definesc n urmtorul mod:

Numrul de intrari a utilizatorului: Fiecare intrare a utilizatorului care

furnizeaz aplicatiei date distincte orientate ctre aceasta este luat n calcul.
Intrrile vor trebui distinse de interogri, care sunt calculate separat.
Numrul de iesiri a utilizatorului: Fiecare iesire ctre utilizator, care furnizeaz
acestuia informatii orientate ctre aplicatie, este luat n calcul. n acest
context termenul "iesire" se refer la rapoarte, ecrane, mesaje de eroare, etc.
Datele individuale ale unui raport nu sunt calculate separat.
Numrul de interogri a utilizatorului: O interogare este definit ca o intrare
on-line ce are drept rezultat generarea unui rspuns imediat al aplicatiei sub
forma unei iesiri on-line. Fiecare interogare distincta este luat n calcul.
Numrul de fisiere: Fiecare fisier logic de tip "master", cum ar fi o colectie
logic de date care poate fi parte a unei baze de date largi sau a unui fisier
individual, este luat n calcul.
Numrul de interfete externe: Toate interfetele citibile de ctre masin (fisiere
de date pe band sau disc dur) care sunt utilizate pentru a transmite informatii
ctre alt sistem sunt luate n calcul.

Odat ce datele de mai sus au fost colectate, un indice de complexitate este

asociat fiecrui calcul. Organizatiile care utilizeaz metoda scorului functional
dezvolt criterii pentru a stabili faptul dac o anumit intrare este simpl, medie sau
complex. Bineinteles, determinarea complexittii este un proces relativ subiectiv.
Pentru a calcula scorul functional, este utilizat urmtoarea relatie:
SF = totalul-de-calcul * 0.65 + 0.01 * SUM (Fi)
unde totalul-de-calcul este suma rezultatelor partiale obtinute prin ponderarea
valorilor domeniului de informatie. Valorile constante din ecuatia de mai sus precum
si factorii de influent care sunt aplicati calculului domeniului de informatii sunt
determinati empiric.

16

Valorile de ajustare a complexittii (Fi, i=1...14) se determin evalund

influenta a 14 factori:

Necesit sistemul back-up si recovery

Sunt necesare facilitti de comunicatii de date
Sunt necesare functii de procesare distribuit
Este criteriul performantei critic
Va rula sistemul ntr-un mediu operational utilizat intens
Necesit sistemul intrri de date n regim on-line
Necesit sistemul de intrri de date n regim on-line, ca procesul de
introducere al datelor s aib loc pe ecrane sau prin operatiuni multiple
Sunt fisierele actualizate on-line
Sunt intrrile, iesirile si interogrile complexe
Este procesul intern complex
Este codul proiectat astfel nct s fie reutilizat
Sunt conversia si instalarea programului incluse n design
Este sistemul proiectat pentru instalri multiple n organizatii diferite
Este aplicatia proiectat astfel nct s faciliteze modificarea si usurinta n
utilizare din partea beneficiarului
Fiecare factor este evaluat cu o not de la 0 la 5, avnd semnificatiile:

0 - Nu influenteaz;
1 - Incidental;
2 - Moderat;
3 - Mediu;
4 - Semnificativ;
5 - Esential;

Odat ce scorul functional a fost calculat, el este utilizat ntr-o manier

asemnatoare cu metoda LOC ca o msur a productivittii, a calittii si a altor
atribute ce definesc programul:
Productivitatea = SF / Programatori-pe-lun
Calitatea = Numr Defecte / SF
Costul =Valoare / SF
Documentatia = Pagini de Documentatie / SF
Evaluarea pe baza scorului functional a fost conceput initial pentru a putea fi
utilizat n sistemele de informatii pentru afaceri. Totusi, extinderea propus ulterior,
denumit scor caracteristic (SC), poate permite aplicarea acestei metode si n cazul
programelor din domeniul sistemelor ingineresti. Scorul caracteristic este adecvat
descrierii aplicatiilor n care complexitatea algoritmilor este nalt. Aplicatiile n timp
real, de control al proceselor precum si cele orientate spre obiecte au tendinta de a
avea o complexitate algoritmic mare si sunt prin urmare potrivite evalurii prin
metoda scorului caracteristic. Pentru a calcula acest scor valorile domeniului

17

informational sunt din nou contorizate si ponderate. Spre deosebire de calculul

scorului functional, scorul caracteristic ia n considerare nc un domeniu de
informatie (algoritmi) iar valorile de ponderare sunt fixe (vezi caseta "Calculul
Scorului Caracteristic"). Valoarea scorului caracteristic final se obtine din ecuatia:
SC = totalul-de-calcul * 0.65 + 0.01 * SUM (Fi);
De remarcat c scorul caracteristic ia n considerare o nou dimensiune a softului, si anume algoritmii. Inversarea unei matrici, decodificarea unui sir de biti sau
tratarea unei ntreruperi sunt toate exemple de algoritmi. Trebuie de asemenea
remarcat c scorul caracteristic si cel functional semnific acelasi lucru, si anume
"functionalitatea" sau "utilitatea" furnizate de ctre software. n fapt, amndou
evalurile au drept rezultat aceeasi valoare a SF-ului n situatia calculului ingineresc
conventional sau a aplicatiilor de tip gestiune a informatiilor. Pentru sistemele n timp
real, mult mai complexe, scorul caracteristic este adesea cu 20-35% mai mare dect
cel calculat prin utilizarea n exclusivitate a scorului functional. Utilizarea scorului
functional - sau a celui caracteristic - este controversat.
Partizanii ideii sustin c SF (SC) este independent de limbajele de programare,
aceasta fcndu-l ideal pentru aplicatii scrise n limbaje conventionale si
neprocedurale. Ei sustin de asemenea c el este bazat pe date ce se presupun a fi
cunoscute mult anterior n evolutia proiectului, fcnd SF (SC) mult mai atractiv ca
estimare. Pe de alt parte, oponentii ideii declar c metoda necesit putin
prestidigitatie si c realizarea calculului se face n parte pe baza unor date mai degrab
subiective dect obiective; ei mai cred c informatiile pot fi dificil de strns "dup ce
evenimentele au avut loc" si c SF (SC) nu are o semnificatie fizic direct - el este
doar un simplu numr.

18

AUTORI
Iliuta Virgil: Introducere Metrici software(definitii, functii, caracteristici)
Balint George: Metrici de complexitate(tipuri, Halstead, Mccabe)

BIBLIOGRAFIE
http://www.software-metrics.ase.ro/articole/METRICI%20%20SOFTWARE.htm
http://cristi.selfip.com/wordpress/tag/metrici-software/
http://www.scribd.com/doc/56586879/Metrici-Software
Zuse, H., Bollmann, P. - Software metrics : using measurement theory the describe the
properties and scales of static complexity metrics
SIGPLAN Notices, vol.24, 1989
Whale, Geoff - Software Metrics and Plagiarism Detection
Journal of Systems Software nr.13, 1990
IEEE Standard for a Software Quality Metrics Methodology
IEEE Std 1061/1992
IEEE Standards Collection Software Engineering
IEEE Press, New York, 1994
Scheneidewing, N.F. - Methodology for validating software metrics
IEEE Transaction on Software Engineering, vol.18, nr.5, 1992

19