Metrici software

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 ) = {

d ( x,y ) = | x - y |
Dacã se considerã:

x = (x₁, x₂, ..., x_n)

y = (y₁, y₂, ..., y_n)

se pot defini urmãtoarele tipuri de distanţe:

d ( x,y ) = S ( y_i - x_i )²

d ( x,y ) = S | x_i - y_i |

d ( x,y ) = max | y_i - x_i |

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

d ( x,y ) = [  (x(t) - y(t))² dt ]^1/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:



|| x || = S 

|| x || = max | _i |

|| x || = S | _i |

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,

c
Pi

Pj
a de exemplu:

f(Pi, Pj) = · 100

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 x₁, x₂, x₃, ....x_n şi în care y, variabila rezultativã, va releva comportamentul programului sau calitãţile acestuia;

- evaluarea unui nivel y₀ pentru valori date x⁰₁ , x⁰₂, .....x⁰_n 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) ₁, ₂ care permit aceastã nuanţare a delimitãrii, cu a₁ ₂ b.

Intervalul [a, ₁] corespunde zonei de respingere a programului, dacã f(Pi) [a, ₁]. Intervalul (₁, ₂].corespunde zonei de acceptare cu rezerve a programului Pi, dacã

f(Pi) (₁, ₂]. Intervalul (₂,b] corespunde zonei de acceptare cu încredere a programului Pi, dacã f (P_i) (₂,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ã:

n₁ - numãr de operanzi distinct;

n₂ - numãr de operatori distinct;

n₃ - numãr de definiţii tipuri de date

şi o mãsurã a complexitãţii

C=n₁ log₁ n₁ + n₂ log₂ n₂ + n₃ log₃ n₃

ş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 n₁, la n₂ sau la n₃ 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(x₁,x₂, ....x_n),

unde:

x₁,x₂, ...,x_n - 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

FACTORI

SUBFACTORI

Pentru fiecare factor şi pentru subfactorii sãi se constituie diagrame de legãturã care conduc spre metrici software acceptabile, figura 1.

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]

[u]

m = = [u]⁰ = [i]

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:

numãr rulãri de succes

numãr total rulãri

fiabilitatea =

numãr erori corectat

numãr total erori

mentenanţa =

numãr componente activate

numãr total componente

testabilitatea =

numãr interfeþe compatibil

numãr total interfeþe

interoperabilitatea =

numãr componente gãsite corecte

numãr total componente

corectitudine =

numãr componente libere de contradicþii

numãr total componente

consistenţã =

timp înþelegere program comentat

timp înþelegere program lipsit de comentarii

lizibilitate =

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

(p)

(p)
m = ,

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 programeleP_i şi P_j considerate se vor obţine nivelele:

(P_i)

(P_i)

(P_j)

(P_j)

m_i = şi m_j =
Deşi programele sunt diferite pornind chiar de la specificaţiile dupã care au fost realizate, este posibil ca m_i = m_j.

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) - k₁

(P) - k₂

m =
în anumite condiţii rãmâne constant, depinzând de valorile lui k₁ şi k₂ 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 (n₁) şi de la numãrul operatorilor (n₂) se construiesc relaţiile (indicatori Halstead):

 n = n₁ + n₂,

unde n reprezintã vocabularul utilizat în program.

 N = N₁ + N₂,

unde:

N₁ - numãrul de operanzi care apar în program;

N₂ - numãrul de apariţii ale operatorilor în program;

N - lungimea observatã a programului;

 C = n₁ log₂ n₁₊ n₂ log₂ n₂,

unde:

C reprezintã complexitatea estimatã a programului.

Volumul programului este definit prin:

 V = N log₂ n

Claritatea K a programului se defineşte prin:

K =

 V· n₂ N₁

2 n₁

Nivelul de implementare L este definit prin:

L =

 2 n₁

n₂N₁

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 I₁, I₂,..., I_n existente într-un limbaj de programare şi coeficienţii C₁, C₂,..., C_n 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:

R₁ = C_j P_j ,

unde:

Cj - nr. mediu de cicluri maşinã pentru instrucţiunea I_j ;

P_j - frecvenţa de apariţie a instrucţiunii I_j în structura liniarã S₁ ;

R₁ - numãrul total de cicluri maşinã asociat structurii S₁ ;

R₂ = n C_j P_j +  ,

unde:

n - numãrul de repetãri ale secvenţei S₁ 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;

R₂ - numãr total de cicluri maşinã asociat unei structuri repetitive.

R₃ = P C_j P_j + q C_j P_j +  ,

unde:

P - probabilitatea ca secvenţa S₁ sã se execute dupã testarea condiţiei;

q - probabilitatea ca secvenţa S₂ sã se execute dupã testarea condiţiei;

 - volum de cicluri asociat evaluãrii şi testãrii unei expresii numite condiţie;

R₃ - 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 C_j 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.

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.

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.

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.

i = 1

j = 1
m =  a_ij b_ij ,
unde :

a_ij - reprezintã elemente din matricea coeficienţilor definiţi ca ponderi de transformare;

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

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.

A = B =

b₁₁ =Pm, b₂₁= Mm, b₃₁ = Cm, B₄₁ = 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:

B = , unde:

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

P₁ : o metricã trebuie sã punã în evidenţã douã subclase de programe : programe utilizabile şi programe inutilizabile;

P₂ : douã programe identice conduc la valori egale ale unei metrici care le evalueazã;

P₃ : utilizarea unei metrici nu conduce la situaţii anormale când se fac studii empirice;

P₄ : dacã o metricã derivã dintr-o altã metricã, apartenenţele programelor la subclase nu se modificã;

P₅ : modificãrilor neutre din program nu le corespund creşteri sau diminuãri ale valorilor rezultate dintr-o metricã;

P₆ : modificãrilor limitate din program le corespund creşteri sau diminuãri limitate ale valorilor rezultat dintr-o metricã;

P₇ : creşterea numãrului de variabile exogene conduce la creşterea gradului de mãsurabiliate asociat metricii;

P₈ : 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 .

În figurã m₁, m₂, m₃, m₄ şi m₅ sunt module.

Fie f : m₁, m₂, m₃, m₄, m₅ [0,1]

o metricã a factorului fiabilitate şi ponderile a₁, a₂, a₃, a₄, a₅, a₆, a₇, a₈ definite astfel încât :

a₁ + a₂ + a₃ + a₄ + a₅ + a₆ + a₇ + a₈ = 1

Se construiesc relaţiile de agregare :

b₁ = a₁f(m₁) + a₂f(m₂)

b₂ = a₃f(m₃) + a₄f(m₄) + a₅f(m₅)

b₃ = a₆b₁ + a₇b₂

b₄ = a₈b₃

sau:

b₄ = a₈ [ a₆b₁ + a₇b₂ ] =

= a₈a₆(a₁f(m₁) + a₂f(m₂)) + a₈a₇(a₃f(m₃) + a₄f(m₄) + a₅f(m₅))

Se impune studierea proprietãţilor (senzibilitate, consistenţã, caracter necompensatoriu) acestui indicator nou agregat al fiabilitãţii.

Sistemul de ponderi a_i 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 (P_i)  a, programul are un nivel calitativ sau un comportament care îl fac neutilizabil, iar, dacã a  m (P_i)  1, programul poate fi utilizat, conform figurii 8.

Mãrimea m (P_i) = 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