Pa Gin A 1

4
CARACTERISTICILE
DE CALITATE
ALE PRODUSELOR PROGRAM
4.1 Sistemul caracteristicilor de calitate
După cum se arată şi în definiţia dată de standardul ISO, [ISO86],calitatea

software este compusă dintr-un set de caracteristici de calitate CC1, CC2, …, CCkcc.
Acestea se împart în:
caracteristici tehnice şi de utilizare;
caracteristici economice;
caracteristici sociale.
Datorită multiplelor relaţii de interdependenţă, subordonare, ierarhizare,
sau agregare, ansamblul caracteristicilor alcătuiesc un sistem, numit sistemul
caracteristicilor de calitate, Quality Characteristics System, [BARO82].
La baza construirii unui set de indicatori care să permită măsurarea
nivelurilor de calitate pentru diferite produse program, se găsesc caracteristicile
sistemului:
¾ setul de caracteristici permite analiza completă a produsului software;
Metode statistice în analiza software
¾ este ierarhizat;
¾ indiferent de complexitatea sa, reprezintă un subsistem al unui sistem de
calitate mai cuprinzător;
¾ caracteristicile sunt ordonate în funcţie de relaţiile de dependenţă;
¾ este organizat sub forma unei structuri arborescente, figura 4.1.
QCS
CC1
CC2
CC3 CC4 CC5 CC6

…………………………………………….
Figura 4.1 Structură ierarhizată a caracteristicilor de calitate
Construirea structurii arborescente implică parcurgerea etapelor:

se consideră lotul de programe Prog1. Prog2, …, Prognprog ce conţine
nprog componente;
se evaluează caracteristicile de calitate CC1, CC2, …,CCncc pentru cele
nprog programe;
se construiesc seriile de valori xcc1, xcc2, …, xccncc având fiecare ncc
termeni, care măsoară nivelul caracteristicilor pentru fiecare program;
datele sunt înregistrate în tabelul 4.1.
Nivelurile măsurate ale setului de caracteristici

Tabel 4.1
Caracteri CC1 … CCj … CCncc
Program
Prog1 xcc11 … xcc1j … xcc1ncc
Prog2 xcc21 … xcc2j … xcc2 ncc
… … … … … …
Progi xcci1 … xccij … xcci ncc
… … … … … …
Prognprog xccnprog1 … xccnprogj … xccnprog ncc
Seria de valori xcc1 … xccj … xcc ncc
Caracteristicile de calitate ale produselor program
unde:
nprog – numărul de programe;
ncc – numărul de caracteristici de calitate;
xccj – seria de ncc termeni asociate caracteristicii CCj;
xccij – nivelul caracteristicii CCj, măsurată pentru programul Progj;
se stabilesc dependenţele dintre caracteristicile de calitate r(xj, xl),

determinate de relaţia coeficientului de corelaţie:
nprog nprog nprog

nprog ∑ xccij xccil − ∑ xccij ∑ xcc il
r (xcc j , xccl ) = i =1 i =1 i =1
⎡ ⎞ ⎤⎡
2
⎞ ⎤
2
2 ⎛ 2 ⎛
nprog nprog nprog nprog
⎢nprog ∑ xccij −⎜ ∑ xccij ⎟ ⎥ ⎢nprog ∑ xccil −⎜ ∑ xccil ⎟ ⎥
⎜ ⎟ ⎜ ⎟
⎢⎣ i =1 ⎝ i =1 ⎠ ⎥⎦ ⎢⎣ i =1 ⎝ i −1 ⎠ ⎥⎦
se ordonează descrescător dependenţele măsurate, r(xccj, xccl);

se alege nivelul cel mai mare al dependenţei şi se obţine nodul rădăcină
al arborelui şi un descendent;
se alege următorul nivel maxim al dependenţei considerată nod rădăcină
şi se obţine nodul următor descendent şi procedeul continuă.
Se consideră caracteristicile de calitate CC1, CC2, CC3, CC4, CC5, CC6. Pentru un
lot de 30 de programe s-au efectuat măsurători şi se obţin dependenţele sub forma
coeficienţilor de corelaţie liniară din tabelul 4.2.
Matricea simetrică a coeficienţilor de corelaţie ai caracteristicilor de calitate
Tabel 4.2
CC1 CC2 CC3 CC4 CC5 CC6
CC1 0,25 0,31 0,40 0,18 0,55
CC2 0,20 0,65 0,28 0,44
CC3 0,80 0,19 0,33
CC4 0,73 0,41
CC5 0,92
CC6
Obţinerea structurii arborescente asociate celor şase caracteristici are loc

după parcurgerea etapelor următoare:
se alege elementul maxim din matricea coeficienţilor de corelaţie,
r(CC5, CC6) = 0,92;
caracteristica CC5 este considerată rădăcina arborelui binar din
figura 4.2, iar caracteristica CC6 este primul descendent;
se caută pe coloana caracteristicii C5 următoarea cea mai mare valoare
care corespunde r(CC4, CC5) = 0,73. Caracteristica de calitate CC4 este
următorul nod descendent;
CC5
CC6
CC4
CC1 CC3 CC3
Figura 4.2 Structura arborescentă asociată tabelului 4.2
se caută valoarea maximă de pe coloana corespunzătoare caracteristicii

CC6, r(CC1,CC6) = 0,55;
se caută valoarea maximă pentru coloana caracteristicii CC4, r(CC2,
CC4) = 0,65. Se caută efectuarea de asocieri aşa fel încât dependenţele
cele mai mari să stabilească perechile de noduri (descendent, nod
părinte).
Structura sistemului caracteristicilor de calitate se construieşte şi sub forma

unui arbore oarecare. Dacă se iau în considerare ponderi acordate de utilizatori şi
de specialişti în realizarea de produse software, se obţin alte structuri de
dependente a caracteristicilor de calitate.
În [IEEE94] este prezentată structura de dependenţe a caracteristicilor de
calitate:
¾ mentenabilitate;
¾ corectabilitate, reprezintă gradul de efort necesar corectării erorilor şi
atingerea cerinţelor utilizatorilor;
¾ modificabilitate, descrie efortul consumat pentru a îmbunătăţi sau

modifica funcţiile produsului program;
¾ testabilitate, măsoară efortul necesar testării produsului software;
¾ dată în figura 4.3.
Mentenabilitate
Corectabilitate Modificabilitate Testabilitate
Figura 4.3. Dependenţe dintre caracteristicile de calitate
La elaborarea unui sistem de programe, utilizatorul, cel care este de fapt

client al producătorului impune o ierarhizare a caracteristicilor de calitate.
Când se stabileşte costul calităţii, cost absolut necesar a fi comunicat
clientului, se ia în considerare ierarhizarea impusă de client, [BARO84].
În contextul definirii sistemului caracteristicilor de calitate şi a stabilirii
unor ponderi a caracteristicilor se creează premisele obţinerii unui indicator agregat
al calităţii dat sub forma:
KCC
I Q = ∑ α cc i ∗ pcc i
i =1
unde:
IQ – indicator agregat al calităţii;
KCC – numărul caracteristicilor de calitate considerate;
α cc i – ponderea asociată caracteristicii de calitate CCi;
pcci – nivelul calculat al caracteristicii de calitate CCi.
Se consideră un număr de 25 de utilizatori Ut1, Ut2, …, Ut25 şi trei

caracteristici de calitate CC1 – fiabilitatea, CC2 – portabilitate, CC3 –
mentenabilitate. Utilizatorul Uti distribuie un număr de 100 de puncte neuniform
celor trei caracteristici şi se obţin ponderile din tabelul 4.3.
Ponderile date de utilizatori caracteristicilor de calitate

Tabel 4.3
Utilizator CC1 CC2 CC3 Total
Ut1 60 30 10 100
Ut2 35 34 31 100
Ut3 50 40 10 100
Ut4 90 6 4 100
Ut5 50 30 20 100
Ut6 40 39 21 100
Ut7 60 21 19 100
Ut8 70 20 10 100
Ut9 70 20 10 100
Ut10 60 10 30 100
Ut11 75 20 5 100
Ut12 50 30 20 100
Ut13 41 39 20 100
Ut14 40 35 25 100
Ut15 53 30 17 100
Ut16 70 10 20 100
Ut17 30 60 10 100
Ut18 45 25 30 100
Ut19 50 30 20 100
Ut20 60 30 10 100
Ut21 65 30 5 100
Ut22 70 25 5 100
Ut23 70 20 10 100
Ut24 60 25 15 100
Ut25 75 15 10 100
Total 1439 674 387 2500

Valoare αcci 0,5756 0,2696 0,1548 1
În ipoteza în care pentru caracteristicile de calitate CC1, CC2, CC3 sunt

efectuate evaluări folosind indicatori normaţi cu valori cuprinse în intervalul [0, 1],
indicatorul IQ, este de asemenea normat pe acelaşi interval.
IQ = 0,5756* nivelF + 0,2696* nivelP + 0,1548* nivelM

unde:
nivelF – nivelul calculat al fiabilităţii;
nivelP – nivelul calculat pentru portabilităţii;
nivelM – nivelul mentenabilităţii.
Dacă se consideră programul Prog pentru gestiunea contabilă a firmei, cu

nivelF = 0,8, nivelP = 0,4 şi nivelM = 0,7, indicele global al calităţii asociat acestui
program este IQ = 0,71.
Problema obţinerii unui indice agregat al calităţii produselor software este
în continuare deschisă dacă se au în vedere aspectele legate de modul în care se
realizează agregarea. Pentru ca acest indicator să ofere o imagine clară asupra
calităţii sunt necesare evaluări ale ponderilor cu evidenţierea stabilităţii valorilor
obţinute. Dinamica pe care o înregistrează tehnicile de programare, instrumentele
utilizate în dezvoltarea de software modifică importanţa caracteristicilor şi deci şi
coeficienţii de importanţă care stau la baza evaluării indicatorului global al calităţii.
Problematica sistemului caracteristicilor de calitate este esenţială în
dezvoltarea de produse software complexe, destinate pieţei, în contextul în care
firme producătoare trebuie să estimeze profitul ca diferenţă între volumul estimat al
vânzărilor şi cheltuielile de producţie, în care costurile calităţii sunt cu o pondere ce
variază în jur de 40% din totalul cheltuielilor firmei.
4.2 Descrierea caracteristicilor de calitate
Produsele software sunt rezultatul unui proces complex, format din etape
care:
analizează şi proiectează;
urmează scrierii textului sursa, testările, asamblarea de module;
preced intrarea în execuţie.
Acestea alcătuiesc ciclul de dezvoltare, şi se constituie în categoriile:
¾ etapa de proiectare: include iniţierea proiectului de realizare a
produsului software, stabilirea criteriilor de calitate software, stabilirea
metodelor de control şi monitorizare a proiectului, alocarea resurselor şi
realizarea proiectului iniţial;
¾ etapa de dezvoltare: odată cu definirea clară a cerinţelor se realizează
eventual un produs program prototip pe baza căruia se ajunge la
produsul final;
¾ etapa de implementare şi testare: cuprinde instalarea produsului într-un

mediu real de lucru, verificarea şi validarea softului, realizarea
documentaţiei.
Programele sunt elaborate pentru a îndeplini funcţii de prelucrare cerute de

utilizatori, fiind dezvoltate utilizând limbaje de programare diverse: limbaj de
asamblare, limbajele Pascal, C/C++, C#, Java.
Programul este un produs pentru că:
` este realizat de o echipa si este folosit de mai mulţi utilizatori,
independent de producători;
` are caracter finit din punct de vedere al resurselor utilizate, al duratei şi
resurselor întrebuinţate de către producător;
` procesul de realizare este separat de utilizarea propriu-zisa;
` reprezintă obiect comercial prin faptul că este vândut şi cumpărat;
` realizarea sa necesită echipamente speciale, parcurgerea unor etape,
consum de resurse şi forţă de muncă calificată;
` are la baza diviziunea muncii; există analişti, proiectanţi, programatori şi
utilizatori sau cumpărători;
` se utilizează tehnici si metode de analiza, proiectare si programare care
garantează obţinerea programului în timp util, la costuri care sa asigure
accesul utilizatorilor;
` însuşirile cu care programele sunt înzestrate sunt evidenţiate în timpul
rulării acestora prin intermediul rezultatelor care se obţin;
` pentru a fi utilizat, trebuie sa fie înzestrate cu caracteristici de calitate la
anumite niveluri;
` are valoare şi valori de întrebuinţare;
` este o marfă cu dimensiune, caracteristici fizice şi de comportament.
Programele sunt produse a căror existenţă fizică este dată de ansamblul

liniilor sursă ce compun codul, de zona de memorie ocupată ca informaţie stocată,
sau de informaţia folosită în execuţia operaţiilor de prelucrare.
Uzura programelor este exclusiv morală, datorată apariţiei de produse noi
care implementează metode mai eficiente sau de noi cerinţe de prelucrare a datelor.
Numărul de execuţii nu influenţează conţinutul sau calitatea programului. În cazul
programelor cu deficienţe de proiectare şi implementare, la execuţie apare procesul
de autodistrugere, manifestat prin blocarea definitivă a aplicaţiei cu pierderea
definitivă a informaţiei. Cu toate acestea programul există, putând fi activat din nou,
cu riscul repetării evenimentului.
La definirea solicitării se stabilesc o serie de detalii care vizează:
însuşirile tehnice ale programului;
însuşirile economice ale programului;
însuşirile sociale ale acestuia.
În contextul în care prin calitate se înţelege totalitatea însuşirilor tehnice,
economice si sociale cu care este înzestrat un produs, la proiectarea şi dezvoltarea
de software se urmăreşte înzestrarea cu caracteristici care să determine atingerea
obiectivelor propuse.
Însuşirile economice ale produselor software sunt legate în principal de
capacitatea acestuia de a genera efecte directe asupra reducerii costurilor de
producţie în întreprinderi, în gestiunea resurselor, la reducerea ponderii forţei de
muncă umane în etapele de prelucrare şi interpretare a datelor, respectiv, a
rezultatelor.
Latura economica vizează şi modul de fundamentare a deciziilor, atunci
când sunt luate în considerare soluţii oferite prin implementarea de algoritmi
determinişti sau euristici. Aceştia au capacitatea de selectare a variaţiilor eficiente
dintr-un număr extrem de mare de soluţii considerate realizabile.
Însuşirile tehnice privesc produsul software ca entitate cu comportament
specific bazat pe consumuri de resurse. Produsul este caracterizat prin prisma
structurii, funcţionalităţii şi a instrumentelor cu care este înzestrat. Din aceste
puncte de vedere produsul program este:
` uşor de utilizat, dacă utilizatorul nu necesită un curs prealabil de operare
sau foloseşte foarte rar documentaţia sau ajutorul interactiv;
` uşor de întreţinut, ceea ce înseamnă că duratele de timp necesare
îmbunătăţirii programului prin introducerea de noi facilităţi sau setării
parametrilor de lucru, sunt mici;
` mentenabil; volumul modificărilor în software care să repare
eventualele erori sau sa îmbunătăţească performanţele programului este
redus;
` tolerant la erori şi elimină într-o proporţie ridicată şansele apariţiei
situaţiilor care blochează execuţia aplicaţiei cu sau fără pierderea
datelor;
` cu consum mic de resurse, permiţând instalarea şi rularea produsului pe
o gamă largă de platforme hardware şi software;
` cu interfaţă user friendly; performanţele de lucru ale utilizatorul nu sunt

afectate prin modul de aranjare a interfeţei.
Caracteristicile sociale se manifesta prin efectele determinate de program în
colectivităţi largi sau în grupuri restrânse de utilizatori, sau prin rolul avut în
procesul de instruire sau de rezolvarea de cerinţe ale utilizatorilor. Însuşirile
sociale vizează efortul utilizatorilor pentru a se familiariza cu un program, dar şi
măsura în care programul răspunde aşteptărilor.
Problematica esenţiala a produselor software este dată de utilitatea pe care
trebuie s-o aibă în rezolvarea de probleme concrete, de fundamentare a deciziilor.
Programele există numai împreună cu informaţiile de intrare furnizate de
utilizatori. Calitatea programelor în sensul de măsura în care acestea răspund
cerinţelor utilizatorilor, este de cele mai multe ori influenţată de datele de intrare.
Este dificil de separat situaţia când un program nu rulează din cauze interne lui, de
cea când rularea este întrerupta datorită datelor de intrare. De cele mai multe ori,
utilizatorul asociază eşecul execuţiei cu incapacitatea producătorului de a-i oferi un
produs bun. De aceea, doar definirea detaliată a contextului, creează condiţiile
pentru a realiza astfel de delimitări.
Din punct de vedere al producătorului calitatea software este un obiectiv.
Din punct de vedere al utilizatorului calitatea este forma concreta de manifestare a
produsului software. Producătorul stabileşte şi ierarhizează caracteristicile de
calitate, ce definesc programele ca produse software:
independent de utilizatori: modularitate, mentenabilitate,
structurabilitate, testabilitate;
în funcţie de nevoile acestora: fiabilitate, toleranta la erori, generalitate,
utilizabilitate.
Nivelurile stabilite ca obiectiv pentru caracteristicile de calitate urmărite,

sunt rezultatul unui proces interactiv în care intervin:
resursele umane si tehnice disponibile ale echipei de dezvoltare
software;
cerinţele utilizatorilor;
resursele financiare pe care utilizatorul le alocă dezvoltării software;
limitările tehnice impuse de generaţiile software si hardware la un
moment dat;
restricţiile de personal ale utilizatorilor.
De cele mai multe ori, aplicaţiile la nivelul companiilor impun lucrul în

timp real pentru a permite fundamentarea de decizii. Prelucrarea în timp real
presupune eliminarea decalajului dintre momentul producerii unui eveniment şi
momentul reflectării sale în baza de date. Atingerea acestui obiectiv impune:
instruirea personalului din toate compartimentele şi de pe toate nivelurile
ierarhice şi de execuţie în utilizarea tehnicii cu ajutorul căreia se
introduce datele;
definirea de chei de control care să permită gestionarea procesului de
actualizare a bazei de date pentru aplicaţia considerata;
crearea unui sistem de protecţie a bazei de date, prin definirea nivelurilor
de acces; la nivelul de execuţie al întreprinderii, accesul vizează exclusiv
introducerea de date privind executantul, operaţia executată şi reperul,
subansamblul sau produsul obţinut, momentul la care s-a desfăşurat
evenimentul şi durata acestuia;
automatizarea operaţiilor de introducere a datelor;
asigurarea funcţionării fără incidente de prelucrare datorate
echipamentelor utilizate; nu trebuie să apară discontinuităţi majore în
procesul de actualizare.
Calitatea software este un concept complex, iar perfecţionarea sa are la

baza comunicarea permanentă între producătorul de software şi utilizatori, chiar
dacă produsul program este proiectat sa funcţioneze independent de producător.
În contextul existentei unei canal de comunicaţie, sugestiile şi reclamaţiile
utilizatorilor sunt sursele sigure pentru reproiectarea produselor program şi pentru
dezvoltarea de noi versiuni. Acestea elimină dezavantajele semnalate sau introduce
noi opţiuni de prelucrare.
În fiecare dintre etape descrise se urmăreşte obţinerea caracteristicilor de
calitate la niveluri cât mai apropiate de cele planificate.
Factorii de calitate avuţi în vedere sunt:

¾ eficienţă:
` economia de timp: capacitatea produsului de prelucra datele şi a
oferi rezultatele în intervale optime de timp;
` economia de resurse: capacitatea softului de a oferi situaţii finale
utilizând resurse software şi hardware limitate, însă având în vedere
ca raportul calitate rezultate/cost să fie optim.
¾ funcţionalitate:
` completitudine: se referă la gradul în care produsul program
cuprinde funcţiile necesare şi suficiente pentru a satisface cerinţele
utilizatorului;
` corectitudine: precizează gradul în care rezultatele sunt cât mai
apropiate de cele reale;
` securitate: calitatea de a asigura securitatea datelor împotriva
pierderilor de date şi a accesului neautorizat;
` compatibilitate: gradul în care produsul este implementat fără a
modifica major programele software deja existente;
` interoperabilitate: se referă la capacitatea de a comunica cu alte
produse software.
¾ mentenabilitate
` corectare: se referă la efortul depus pentru a corecta erorile
software, precum şi pentru a îndeplini cerinţele utilizatorului;
` dezvoltare: necesarul de resurse pentru a îmbunătăţi produsul.
¾ portabilitate
` independenţa hardware: gradul în care aplicaţia nu depinde de
anumite medii hardware;
` independenţa software: gradul în care aplicaţia nu depinde de medii
software specifice, de exemplu sisteme de operare;
` reutilizare: gradul în care softul este reutilizat în produse diferite de
cel iniţial.
¾ fiabilitatea
` toleranţa erorilor: gradul în care produsul continuă să opereze în
ciuda erorilor fără a afecta utilizatorul;
` disponibilitatea: gradul în care produsul este operaţional având în
vedere defectarea sistemului hardware sau software.
¾ utilizabilitate
` uşurinţa utilizării: reprezintă efortul depus de utilizator pentru a
înţelege şi utiliza produsul.
Portabilitatea software
Pe de o parte există programul care permite rezolvarea unei probleme şi pe

de altă parte există utilizatorul care are configuraţia sa de calcul şi structura sa
pentru baza de date.
Se consideră un program P livrat în formă executabilă. Portabilitatea este

acea caracteristică de calitate care asigură lansarea în execuţie a programul P fie
direct, fie după ce s-a realizat instalarea sa prin modificarea la nivelul acceptării a
particularităţilor hardware şi de structură a bazei de date, în vederea activării
secvenţelor care sunt definite în concordanţă cu restricţiile specifice fiecărui
utilizator.
Programele livrate în formă executabilă care nu sunt proiectate pentru a fi
executate în diferite condiţii cu specificarea acestora de către utilizator, de regulă
nu sunt portabile. Totuşi, pentru a le face portabile are loc un proces de emulare a
calculatorului pentru care au fost proiectate.
Gradul de portabilitate G utiliz
p în raport cu utilizatorii Ut1, Ut2, …, Utnut a
programului Prog este dat prin relaţia:
nut
∑ (Telab i − Tmodif i )
G utiliz
p = i =1
nut
∑ Telab
i =1
i
unde:
nut – numărul de utilizatori, Uti;
Uti – utilizatorul programului;
Telabi – timpul necesar elaborării programului pentru a satisface
cerinţele utilizatorului Uti;
Tmodifi – timpul necesar elaborării de modificări pentru a face programul
existent portabil pentru utilizatorul Uti.
Programul Prog este n – portabil dacă Tmodifi e mult mai mic decât Telabi
pentru oricare ar fi i =1, 2, …, nut. În cazul în care programul Prog este livrat sub
formă de text sursă, utilizatorul are obligaţia realizării tuturor etapelor necesare
obţinerii formei executabile. Programul P are lungimea LI data ca număr de
instrucţiuni. Pentru asigurarea portabilităţii programatorul efectuează următoarele
operaţii:
adaugă LA instrucţiuni;
modifică LM instrucţiuni;
elimină LE instrucţiuni.
Gradul de portabilitate este dat de relaţia:
LI − (LA + LM + LE )
G instr
p =
LI
Un program este proiectat să fie portabil dacă se doreşte obţinerea unei arii
foarte mari de utilizare.
Portabilitatea ia în considerare multitudinea de parametrii care definesc
configuraţia unui calculator sau a unei reţele de calculatoare. Dacă nu se creează
componenta de instalare, se impune separarea componentelor vulnerabile în raport
cu variabilitatea parametrilor aşa fel încât problematica propagării de modificări
cerute de portabilitate să fie la un nivel cât mai scăzut.
În condiţiile actuale, când circulă pe Internet numeroase componente
software, problematica portabilităţii este deplasată spre identificarea acelor
componente care să fie adăugate programului în cauză, aşa fel încât toate
obstacolele să fie eliminate. Dacă programul este dat sub forma fişierului
executabil de lungime LP, iar programele care sunt identificate pentru a fi utilizate
au lungime LX, gradul de portabilitate G pfis este dat de relaţia:
LP − LX
G pfis =
LP
De exemplu, produsul program SalSal destinat calculării salariului

angajaţilor unei firme a suferit numeroase modificări pentru a corespunde
cerinţelor utilizatorilor şi a platformelor hardware şi software pe care este instalat
din mai multe unităţi comerciale în care este implementat:
programul are în forma iniţială LI = 6450 de linii sursă şi un fişier
executabil de LP = 24 MB;
se modifică trei proceduri ale programului iniţial pentru a corespunde
noilor cerinţe ale utilizatorului; acestea totalizează LA1 = 175 linii sursă
noi adăugate, LM1 = 23 linii sursă modificate şi LE1 = 32 linii sursă
eliminate şi au necesitat un timp de modificare de Tmodif1 = 83 de minute,
iar timpul de elaborare iniţial este de Telab2 = 240 de minute;
se introduc două noi proceduri prin adăugarea de LA2 = 143 linii sursă;
modificările codului existent pentru a face legătura cu noile proceduri
au însemnat LE2 = 12 linii sursă şterse, LM = 10 linii sursă modificate şi
s-au efectuat în Tmodif2 = 110 minute; se are în vedere că timpul de

elaborare a instrucţiunilor modificate a fost de Telab12 = 168 minute;
modificările suferite de produsul program sunt transmise utilizatorilor
sub forma unui fişier de update de dimensiune LX = 4 MB.
Pe baza acestor date, se obţin gradele de portabilitate:
(240 − 83) + (168 − 110)

G utiliz
p = = 0,52
240 + 168
6450 − (175 + 23 + 32 + 143 + 12 + 10 )

G instr
p = = 0,93
6450
24 − 4
G pfis = = 0,83
24
Se observă că valoarea gradului de portabilitate este dependentă de

modalitatea de determinare.
Dacă la un moment dat portabilitatea este strict dependentă de resurse
precum compilatoare, capacitate hard disk, capacitate memorie internă, viteză de
calcul, tip calculator, în timp aceste restricţii au fost eliminate. Eliminarea de pe
piaţă a calculatoarelor necompatibile IBM, dezvoltarea unor sisteme de operare
dominante, WINDOWS NT, LINUX şi apariţia unor procesoare care din start
asigură compatibilitatea IBM au creat condiţiile necesare şi suficiente pentru
portabilitatea software.
Mai mult, schimbarea concepţiei de dezvoltare software, în ideea de a
acoperi o arie foarte diversă de utilizatori a condus la modificarea de structurare a
software destinat pieţei.
Se adoptă ideea utilizării procesului de customizare la cerere şi
transmiterea spre utilizator a produsului absolut portabil.
În cele mai multe situaţii, pentru a se elimina legătura dintre producătorul
de software şi utilizator se construieşte o componentă program care se încarcă de
orice configuraţie, numită şi configuraţie minimală. Această componentă este
lansată în execuţie şi are loc iniţializarea produsului software propriu zis prin
specificarea restricţiilor sau a opţiunilor utilizatorului. Personalizarea produsului
software se face chiar de utilizator.
Portabilitatea produsului software în raport cu datele de intrare devină

efectivă dacă şi numai dacă proiectantul a prevăzut o diversitate de modalităţi, de
terminare şi mai ales dacă a prevăzut portabilitatea de definire a lungimii
articolelor şi a poziţiei câmpurilor, a tipurilor şi lungimilor acestora.
În acest fel, produsul software are acces la orice bază de date cu condiţia ca
aceasta să conţină toate datele necesare produsului indiferent de modul în care sunt
distribuite pe suport şi indiferent de forma de reprezentare.
Portabilitatea în acest fel este deplasată la nivelul proiectantului de produse
software, ne mai fiind înţeleasă ca o caracteristică manifestată la utilizator prin
modificări asupra textului sursă. Este cunoscută nonportabilitatea generată de
modalităţile de linearizare a masivelor bidimensionale. Au existat companii care şi-
au construit compilatoare cu linearizare pe linie, în timp ce altele au efectuat
linearizarea pe coloane pentru maşinile bidimensionale. Transferul dierct de
software dintr-o direcţie spre cealaltă prin intermediul bazelor de date care
stochează date intermediare este deja imposibil, iar cuplarea de module obiect,
realizate în două unităţi producătoare era posibilă numai prin crearea de interfeţe
care să sigure compatibilitatea liniarizării.
În momentul de faţă, toţi producătorii de software proiectează programe
portabile. Cei care elaborează software local, fie au o piaţă sigură fie nu au definite
strategii de dezvoltare compatibile cu dezvoltarea pieţelor de software.
Mentenabilitatea software
Mentenanţa este un proces specific produselor software destinate să

funcţioneze pe un interval lung de timp, aceasta însemnând mai mult de trei ani. În
timp, datorită evoluţiei proceselor tehnologice, modificărilor în legislaţie
modificărilor structurale ale colectivităţilor, se impune adoptarea produselor
software aşa fel încât acestea să răspundă cerinţelor reale ale utilizatorilor.
Modificări ale algoritmilor presupun intervenţii în modulele unde sunt
evaluate expresii sau sunt efectuate selecţii ale elementelor. Pentru a elabora
software mentenabil estre necesar să se definească suficient de clar modulele.
Astfel modulele vulnerabil a fi modificate trebuie astfel definite şi astfel plasate
încât să nu afecteze alte module prin modificările care se operează asupra lor.
Modificări in date de intrare presupun creşterea volumului de date care fac
obiectul prelucrării, introducerea de noi variabile pentru descrierea elementelor
colectivităţii sau schimbarea modului de reprezentare. În toate cazurile sunt
necesare modificări în module pentru a menţine performanţa la nivelul unei
tranzacţii şi pentru a prelucra noile date. Programul este mentenabil în măsura în

care acceptă modificările în date prin procese similare. Adică, la adăugarea de
câmpuri se adaugă module de prelucrare. la adăugarea de articole se adaugă
module de realizare acces rapid. La eliminarea de câmpuri se elimină module de
prelucrare sau se dezactivează module.
Modificări la nivel hardware presupun regândirea produsului aşa fel încât
să fie acceptate modificările hardware. Profunzimea acestor modificări este de cele
mai multe ori atât de mare încât este preferabil să se achiziţioneze un nou produs.
În condiţiile în care există o abundenţă foarte mare a software care circulă liber,
problema mentenabilităţii are o altă conotaţie. Existenţa de produse foarte ieftine
care circulă pe dischete sau Cd-uri face ca utilizatorii să-şi modifice poziţia faţă de
achiziţionarea de software nementenabil, excluzând-l din start. Mai mult,
utilizatorul are în vedere dinamica structurală a produselor pentru care dezvoltă
aplicaţii informatice şi-şi dezvoltă condiţiile pentru a trece la perioade foarte scurte
de la un produs software la altul, fiecare dezvoltat după altă concepţie, cu alte
structuri hardware.
Problema mentenabilităţii se deplasează în acest caz spre date, în sensul
stocării de volum variate care să poată fi prelucrate de orice produs.
Mentenanţa la nivelul rezultatelor este privită ca necesitatea obţinerii de
rezultate exact în forma şi de calitatea cerută de utilizator. Producătorii de software
au obligaţia de a ţine seama de structurile de rezultate necesare utilizatorilor.
Produsele software se vor proiecta astfel încât prin opţiuni specifice să ofere
utilizatorilor posibilitatea de a modifica structurile de rezultate. Pentru asigurarea
mentenabilităţii se vor lua în considerare o serie de măsuri dintre care, cele mai
importante sunt:
definirea de rezerve pe suport pentru fiecare articol, pentru a aloca noi
câmpuri pe măsură ce se impune dezvoltarea bazei informaţionale de
descriere a proceselor sau elementelor unei colectivităţi;
construirea de expresii modificate care prin valori ale unor coeficienţi să
permită includerea sau excluderea unor factori; de exemplu, dacă
programul iniţial evaluează expresia:
expr = a + b + c + d;
şi dacă această expresie este vulnerabilă a fi modificată fie prin efectuarea

de scăderi fie prin eliminarea unor termeni, se implementează forma:
4
expr = ∑ α i * xi
i =1
unde:
x1 – este pus în corespondenţă cu a;
x2 – este pus în corespondenţă cu b;
x3 – este pus în corespondenţă cu c;
x4 – este pus în corespondenţă cu d.
Pentru:
α1 = α2 = α3 = α4 = 1 rezultă e = a + b + c + d.
α1 = 1, α2 = -1, α3 = 1, α4 = -1 rezultă e = a - b + c - d.
α1 = 1, α2 = 0, α3 = 0, α4 = -1 rezultă e = a - d.
introducerea de elemente care asigură variabilitate în efectuarea de

selecţii; astfel funcţia:
g1(x), dacă x ε [a1, b1];

g2(x), dacă x ε [a2, b2];
f(x) =
………………………
gn(x), dacă x ε [an, bn];
presupune utilizarea unui masiv unidimensional cu n+1 componente, a1,

a2 , …, an+1 se implementează prin definirea numărului de intervale n,
prin alocarea de memorie pentru cele n+1 componente ale masivului
unidimensional a[] şi prin definirea expresiilor analitice ale celor n
funcţii gi(x), i = 1, 2, …, n; toate ca date de intrare; programul
mentenabil este înzestrat cu interpreter care precizează expresiile
analitice ale funcţiilor gi(x) şi le evaluează.
Mentenabilitatea în raport cu evoluţiile hardware este posibilă în faza de

proiectare prin includerea de elemente care să accepte modificările care vor apare.
De regulă, noile generaţii de calculatoare acceptă produse realizate pentru
generaţiile precedente. Dezavantajele apar din imposibilitatea de a folosi facilităţile

de care noile calculatoare dispun.
De exemplu, un produs dezvoltat pentru un calculator la care calculele în
virgulă mobilă erau emulate prin folosirea de proceduri nu va folosi facilităţile
coprocesorului.
De asemenea, dezvoltarea spre multimedia presupune creşterea capacităţii
produselor software de a opera cu imagine şi cu sunet. Ataşarea de componente
care permit operaţii de intrare/ieşire multimedia compatibile reprezintă un element
foarte important în aria de manifestare a mentenabilităţii.
Mentenabilitatea se măsoară cu indicatorul Iment:
Tmodif
I ment =
Tdezv
unde:
Tmodif – timpul necesar efectuării modificărilor în produsul software
pentru a-l menţine în uz curent;
Tdezv – timpul necesar dezvoltării produsului (analiză, proiectare,
codificare, testare, implementare).
Experienţa arată că dacă 0,6 > Iment > 0,4 se impune luarea deciziei de
înlocuire în viitorul apropiat a produsului întrucât cerinţele viitoare de mentenanţă
vor presupune costuri foarte ridicate.
Dacă în mod constant Iment > 1 înseamnă că produsul nu a fost proiectat
pentru a face faţă unor cerinţe noi. În condiţiile actuale evaluarea mentenanţei pe
text sursă nu se dovedeşte elocventă datorită modalităţilor variate de asigurare a
mentenanţei, inclusiv prin construirea de translatoare care au rolul de a modifica
textele sursă, aducându-le la cerinţele noi impuse de utilizator.
Produsele software dezvoltate după tehnicile pe componente au procese de
mentenanţă reală, cu efort minim de realizare.
Reutilizabilitatea software
Programarea orientată obiect este rezultatul direct al necesităţii elaborării

de software reutilizabil. Încapsularea, proprietate esenţială a obiectelor vizează
izolarea într-un întreg de sine stătător a operanzilor şi a operatorilor (metode).
Când se defineşte obiectul se are în vedere luarea în considerare a tuturor
elementelor încât să se asigure o prelucrare completă. Operanzii şi operatorii

acoperă o arie suficient de mare şi prin garanţiile de corectitudine a calculelor şi de
generalitate sunt preluaţi ca atare.
Dacă bibliotecile de programe presupuneau existenţă procedurilor (metode)
operanzii fiind lăsaţi la latitudinea utilizatorilor atât ca definire, cât şi ca
iniţializare, obiectele exclud aportul utilizatorilor mai ales în a produce erori de
definire operanzi şi de iniţializare a acestora.
Este posibilă definirea şi utilizarea de obiecte numai atunci când în
limbajele de programare sunt implementate mecanisme specifice alocării dinamice
şi tratării diferenţiate a operanzilor şi operatorilor prin adăugarea de proprietăţi
privind accesul, referirea şi domeniile.
Moştenirea este forma cea mai clară de reutilizare software la nivelul
dezvoltării de aplicaţii. Moştenirea creează posibilitatea ca la ceea ce există să se
poată adăuga noi proprietăţi, prin construirea de clase derivate.
Polimorfismul asigură independenţa de lucru a programatorilor fără a mai
apare restricţii suplimentare asupra modului de a defini funcţii diferite ca structură
care realizează însă aceeaşi tipologie de prelucrare (scriere, calcul, sortare, desen).
Reutilizarea de software este posibilă dacă la proiectarea modulelor se
asigură generalitatea şi corectitudinea prelucrărilor.
Reutilizabilitatea asigură reducerea consumului de muncă vie şi conduce la
scurtarea duratei necesare realizării unui produs software. În primul rând, cei care
dezvoltă software trebuie să cunoască exact ceea ce există, ce modul sunt
disponibile, modul de utilizare şi măsura în care acestea sunt preluate sau sunt
disponibile.
Condiţiile de reutilizabilitate software sunt:
componentele să realizeze integral funcţia de prelucrare cerută;
nivelul calitativ al componentei reutilizabile trebuie să fie superior sau
cel puţin egal cu cel al produsului care se doreşte a fi realizat;
concordanţă între structurile de date cu care operează produsul care se
construieşte şi structurile de date ale componentei reutilizate, atât în
ceea ce priveşte intrările cât şi ieşirile acesteia;
disponibilitatea componentei prin preluarea de la un alt produs software
al firmei sau prin achiziţionarea la un preţ convenabil;
omogenitatea din punct de vedere al cerinţelor hardware şi software în
raport cu produsul care se dezvoltă şi care solicită reutilizarea.
Reutilizarea software devine operaţională vând componentele disponibile

îndeplinesc toate condiţiile şi îl conving pe programator asupra utilităţilor în
activarea sa.
Problema reutilizării este cu atât mai importantă cu cât firme producătoare
de software de bază au dezvoltat biblioteci de clase care prin preluare reduc cu
60% - 80% efortul de programare. Este posibil ca în acest fel să se demareze
realizarea de software cu grad de complexitate foarte mare chiar în cadrul unor
firme producătoare de software cu personal ce nu depăşeşte 15 persoane dar care
au o dotare şi o calificare la nivel foarte înalt. Problema reutilizabilităţii apare în
primul rând în zona dezvoltării interfeţelor.
În realizarea interfeţelor sunt predominante elementele de grafică şi de
căutare- regăsire a informaţiei. Toate acestea presupun definire de amplasări ale
textelor şi de constituire a părţilor de text care determină acţiuni sau selecţii de
operaţii.
Latura cantitativă este dominantă, motiv pentru care se impune definirea de
clase orientate spre dezvoltarea de interfeţe. De asemenea, se dezvoltă interfeţe
pentru definirea de tabele şi de prelucrare a datelor din tabele.
Problematica reutilizării intervine cu deosebire atunci când în produse
software noi trebuie incluse conversii, compresii, sortări, optimizări ca operaţii ce
reprezintă o pondere extrem de redusă în volumul prelucrărilor, dar care din punct
de vedere al efortului de programare reprezintă consumuri semnificative.
Gradul de reutilizabilitate GR este dat de relaţia:
LR
GR =
LT
unde:
LR – lungimea ca număr de instrucţiuni sau Kbytes a componentelor
reutilizate, incluse în produsul software considerat;
LT – lungimea totală ca număr de instrucţiuni sau Kbytes a produsului
software în care au fost reutilizate componentele.
De exemplu, programul CompSoft implementează operaţii pe matrice

necesare comparării nivelurilor caracteristicilor a unui număr definit de utilizator
de produse program. o serie de 15 proceduri însumând LR = 362 de instrucţiuni au
fost reutilizate prin preluarea acestora dintr-o bibliotecă de funcţii şi proceduri de
calcul cu matrice. Cum codul sursă al programului CompSoft conţine LT = 1150 de

instrucţiuni, gradul de reutilizabilitate este:
362
GR = = 0,31
1150
Când se analizează un program este necesar să se identifice:

LT – lungimea programului;
LR – lungimea componentelor efectiv reutilizate;
LRmax – lungimea maximă a componentelor care ar fi putut fi reutilizate.
În acest context se calculează gradul risipei de muncă vie inclusă în

produsul software, GS, dat de relaţia:
LRmax − LR
GS =
LT
De regulă, atunci când este apreciat un program se evaluează indicatorul

GS pentru a aduce la nivelul real costul acestuia. Risipa de muncă vie este
rezultatul necunoaşterii existenţei de componente software, aspect care nu se
impută utilizatorului, ci producătorului de software.
Modularitatea programelor
La proiectarea software se identifică operaţii de prelucrare de prelucrare

care se grupează obţinându-se module cu grad de omogenitate ridicat.
Astfel, se construiesc module care asigură efectuarea operaţiilor de
intrare/ieşire. Se definesc module pentru validarea datelor, pentru efectuarea de
conversii, pentru efectuarea de sortări, de interclasări, de calcul.
Un modul se caracterizează printr-un set de date de intrare şi printr-un set
de rezultate. Este preferabil ca în interiorul modului să nu se efectueze modificări
asupra datelor de intrare. De asemenea, este de dorit ca volumul rezultatelor finale
ale modului să fie într-un număr cât mai restrâns cu putinţă.
Modularitatea este caracteristica de calitate care evidenţiază măsura în care
proiectantul a identificat funcţiile de prelucrare omogene şi le-a legat între ele.
Această caracteristică oferă programului controlul asupra redundanţei intrinseci.
Modulele sunt înzestrate cu un grad de generalitate suficient de mare aşa

fel să fie reutilizate atât în cadrul programului cat mai ales în alte programe
contribuind la realizarea economiei de muncă vie, ore de programare care s-ar irosi
prin nereutilizabilitate.
Pentru calculul indicatorilor:
n n n n n
∑x i ∑x *y i i ∑x *y i i ∑x * y ∑w * y
i i i i
I1 = i =1
, I2 = i =1
n
, I3 = i =1
n
, I4 = i =1
n
÷ i =1
n
n
∑x
i =1
i ∑x *z
i =1
i i ∑x *z ∑w *z
i =1
i i
i =1
i i
xi − xmin n
µi = , S = ∑ ( poz ( xi ) − poz _ ord ( xi ))
2
xmax − xmin i =1
Se identifică următoarele module:
M1 – modul pentru însumare elemente masiv unidimensional;

M2 – modul pentru obţinerea masivului produs ti = xi*yi cu i = 1, …, n;
M3 – modul pentru aflare element minim;
M4 – modul pentru aflare element maxim;
M5 – modul pentru ordonare elemente masiv unidimensional cu reţinerea
poziţiei iniţiale;
M6 – modul pentru obţinerea masivului diferenţă ti = xi – yi cu i = 1, …, n;
M7 – modul pentru iniţializarea unui şir cu o valoare dată;
M8 – modul pentru obţinerea masivului cât, ti = xi/yi cu i = 1, …, n;
M9 – împărţire două numere şi afişare cât.
Structura modulară a aplicaţiei pentru calculul indicatorilor este dată în

figura 4.4.
Modul rădăcină
I1 I2 I3 I4
M1 M9 M2 M1 M9 M2 M2 M9 M2 M2 M9 M2 M2 M9 M9
M1 M1 M1 M1 M1 M1 M1
Modul rădăcină
I3 ui
M5 M6 M2 M1 M9 M3 M4 M7 M7 M6 M8
Figura 4.4 Structura modulară a aplicaţiei
Se observă că utilizarea modulelor determină o specializare a

programatorilor cu efecte pozitive asupra conceperii de componente reutilizabile
prin gradul lor mare de generalitate.
Mai mult, cei care dezvoltă module realizează activităţile în paralel şi nu
este necesar să aibă viziunea asupra întregii lucrări.
În cazul în care modulul este corect definit sunt prezentate toate datele de
test şi situaţiile critice, precum şi modul în care modulul trebuie să se comporte,
programatorul lucrează independent şi valorifică mai bine potenţialul său
productiv, marcând realizarea modulului aflat sarcina sa precum şi verificarea
calităţii acestuia. Programarea modulară permite scurtarea duratei de realizare a
produselor prin creşterea paralelismului în realizarea modulelor şi de asemenea
permite individualizarea mai accentuată a programatorilor. Prin crearea de module
ale căror caracteristici de calitate se controlează cu uşurinţă, managerul proiectului
gestionează din aproape în aproape calitatea proiectului.
În cazul în care se identifică module care operează pe acelaşi structuri de

date se creează mai întâi nucleele obiectelor, iar în timp prin adăugarea de noi
module, se efectuează o completare a obiectului până se ajunge la definirea
riguroasă a cestuia.
Modularitatea se măsoară prin indicatorul IM, dat de relaţia:
nmodule
IM =
mmodule
unde:
nmodule – numărul de modele diferite existente în program;
mmodule – numărul total de module folosite în program.
Pentru exemplul considerat în figura 4.4, nmodule = 7 + 9, mmodule = 40, iar

valoarea indicatorului este:
16
IM = = 0,4
40
Problema omogenităţii modulelor revine la gruparea operaţiilor în aşa fel

încât acestea să nu fie dispersate în tot programul. Astfel, operaţiile de intrare/ieşire
se vor grupa într-un modul sau în module distincte, respectiv, pentru intrări şi ieşiri.
Operaţiei de sortare, operaţiilor de calcul de asemenea se grupează. În acest fel se
creează premisa unei bune organizări a lucrului, unei bune gestionări a rezultatelor
intermediare.
Uneori, gruparea după criteriul omogenităţii funcţiei de prelucrare, vine în
contradicţie cu optimalitatea în raport cu volumul operaţiilor de prelucrare. În
contextul vitezei foarte mari de calcul, creşterea cu 10% - 20% a volumului de
prelucrări devine nesemnificativă în raport cu efectele pe care le generează
modularitatea.
Fiabilitatea software
Fiabilitatea software este o caracteristică de calitate importantă pentru că:

` de ea depinde numărul rulărilor în care se obţin rezultate complete şi
corecte;
` permite abordări particulare în elaborarea modelelor de estimare cu
luarea în considerare a faptului că produsele software nu au uzură fizică
şi că odată cu eliminarea cauzelor care generează întreruperea execuţiei

e posibilă obţinerea creşterii fiabilităţii;
` nivelul acestei caracteristici determină întreaga abordare în realizarea
unui produs software şi antrenează consumuri şi costuri ce depind strict
de modalităţile concrete luate în considerare pentru creşterea nivelului
fiabilităţii uneia sau alteia dintre componentele produsului.
Fiabilitatea Fiab a uni program se măsoară prin indicatorul:
rsucces
I Fiab =
rtotal
unde:
rsucces – numărul rulărilor de succes ale programului, în care s-au obţinut
rezultate complete şi corecte;
rtotal – numărul total al rulărilor programului considerat.
În timp au fost elaborate numeroase modele pentru studierea fiabilităţii

software pornind de la modulele existente din energetică în general şi din
energetică nucleară în special.
Se consideră un program Prog multiplicat în ncop copii, destinat lucrului la
utilizatorii Ut1, Ut2, …, Utnut. Utilizatorul Uti lansează în execuţie programul Prog
de muti ori într-un interval de timp ∆Tut comun tuturor utilizatorilor. Pentru
intervalul ∆Tut se înregistrează momentele de lansare în execuţie, erorile
înregistrate. Utilizatorul Uti lansează în programul Prog în execuţie la momentele
tuti1, tuti2, …, tutimi. Se consideră perechile (tutij, erj) unde erj =1 dacă rularea s-a
efectuat cu succes, respectiv erj = 0 dacă s-a înregistrat eroare în prelucrare şi
rezultatele sunt incorecte sau s-a întrerupt execuţia. Prin colectarea datelor de la cei
nut utilizatori ai programului Prog se stabilesc parametrii modelelor, estimându-se:
¾ durata medie dintre două execuţii eronate, căderi, ale programului Prog;
¾ durata medie de funcţionare corectă a programului;
¾ parametrii legilor de repartiţie ai procesului aleatoriu asociat utilizării
programului.
În realitate, odată cu semnalarea erorilor, programul Prog nu este înlocuit

cu alt program Prog identic, asemenea unui bec, ci are loc efectuarea de corecţii
(modificări de instrucţiuni, inserarea de noi instrucţiuni, eliminarea de instrucţiuni).
În acest fel se obţine programul modificat Prog’. Astfel, dacă fiecare utilizator
primeşte noua variantă, procesul fiabilităţii este studiat în continuare pe versiunea
Prog’. Modificările programului continuă pe toată durata, obţinându-se versiunile
Prog(2), Prog(3), …, Prog(k) la finalul perioadei ∆Tut.
Modelele de fiabilitate ale utilajelor sau a elementelor de iluminat sunt
dezvoltate în ipoteza menţinerii nemodificate a structurii acestora, ceea ce în cazul
produselor software nu este posibil.
În acest context este necesară abordarea fiabilităţii evolutive în condiţiile
modificării produsului program Prog cu trecerea prin versiunile Prog(2), Prog(3), …,
Prog(k).
Se ia în considerare variaţia de complexitate software.
Fie un program Prog, având nivelul de complexitate Cplx(Prog).
Pentru trecerea la programul Prog(1) are loc eliminarea secvenţei Se de
instrucţiuni, modificarea secvenţei Sm de instrucţiuni, inserarea secvenţei Sa de
instrucţiuni.
Variaţia de complexitate ∆Cplx, este dată de relaţia:
∆Cplx = Cplx(Se) + Cplx(Sm) + Cplx(Sa).
Trecerea de la versiunea Prog(1) la versiunea Prog(2) necesită o variaţie de

complexitate ∆Cplx12.
Per total, trecerea de la programul iniţial Prog la versiunea Prog(k) necesită
o variaţie a complexităţii, dată de relaţia:
∆Cplxok = ∆Cplx01 + ∆Cplx12 + ∆Cplx23 + … + ∆Cplxk-1k.
Modelul de fiabilitate include variaţia de complexitate pentru a reflecta

dinamica programului la fiecare moment, întrucât de la semnalarea unei erori are
loc corectarea ei. Evoluţia procesului de producere a erorilor de prelucrare este
marcată de calitatea corectării, de modul în care s-a identificat cauza şi de aria de
cuprindere a elementelor de din program implicate în depistarea cauzei.
Pentru fiabilitatea software este dedicată o bogată literatură cu descriere de
modele, lucrarea de faţă fiind orientată pe utilizarea de metode statistice,
accentuează pregătirea seriilor de date necesare unora dintre modelele de fiabilitate
software.
4.3 Modele de sisteme de caracteristici de calitate
Modelele cunoscute ale sistemelor de calitate software sunt rezultatul

direct al experienţei analiştilor în elaborarea de analize calitative asupra unui
număr semnificativ de produse program.
Modelele sunt structurate pe cel puţin două niveluri. Primul nivel
corespunde caracteristicilor generale agregate. Celelalte reprezintă structuri de
nivel elementar ce includ caracteristicile primare, reprezentate de subcaracteristici
şi factori.
Această aranjare provine din:
experienţa practică ce porneşte cu definirea unui set iniţial de
caracteristici, care apoi este rafinat prin descompunere în termeni de
care depinde;
ipoteza simplificatoare că toate caracteristicile de nivel înalt se obţin
prin agregarea caracteristicilor primitive.
Descompunerea caracteristicilor generale în caracteristici de nivel inferior

este necesarã deoarece astfel se urmăresc/cuantifică în procesul de elaborare,
respectivele caracteristici de calitate.
Modelele sunt definite de caracteristicile de pe nivelurile superioare, pentru
că reflectă obiectivele urmărite în caracterizarea calităţii produsului.
Subcaracteristicile şi factorii primari asigură detalierea caracteristicilor de calitate
şi constituie punctul de plecare în definirea de metrici software ale calităţii.
Modele de sisteme de caracteristici de calitate dezvoltate şi utilizate în mod

curent sunt, [TEOD01]:
Boehm;
McCall;
ICI (Institutul de Cercetări în Informatică), descris în figura 4.5;
ISO 9126;
Dromey.
aria de cuprindere
Flexibilitate extensibilitate
portabilitate
capacitatea de modificare
Corectitudine completitudine
lipsă contradicţii
consistenţă
conformitate
Fiabilitate
stabilitate
integritate
Mentenabilitate structurabilitate
simplitate
autodescriere
uşurinţa asimilării
Utilizabilitate
comoditate în exploatare
complexitatea funcţională
consum de timp
Eficienţă
resurse utilizate
precizia calculelor
Figura 4.5 Modelul ICI al caracteristicilor de calitate
Modelul McCall stabileşte relaţii între caracteristicile de calitate software

şi metrici, cu toate că nu este demonstrată obiectivitatea tuturor metricilor software.
Modelul nu ia în considerare funcţionalitatea produselor software şi tratează
problema calităţii software din trei puncte de vedere:
` al reviziilor ce descriu calitatea operaţiilor de testare şi a celor de
mentenanţă;
` al operaţiilor luându-se în considerare calitatea rezultatelor, al
prelucrărilor şi în general tot ce ţine de lucrul în mod curent cu produsul
software;
` al tranziţiei caracterizând procesul de modificare prin îmbunătăţire a
produsului program.
Fiecare din aceste perspective este descompusă în caracteristicile de

calitate din tabelul 4.4.
Caracteristicile de calitate ale modelului McCall

Tabel 4.4
Portabilitate
Revizii Flexibilitate
Testabilitate
Corectitudine
Fiabilitate
Operaţii Eficienţă
Integritate
Uzabilitate
Portabilitate
Tranziţii Reutilizare
Interoperativitate
Modelul Boehm este similar cu modelul McCall reprezentând

caracteristicile de calitate cu ajutorul unei structuri arborescente. Fiecare
caracteristică are o contribuţie la calitatea totală a produsului software. Spre
deosebire de modelul McCall, acest model ţine cont şi de caracteristicile de
performanţă ale componentelor hardware.
Organizaţia Internaţională pentru Standardizare a reunit multiplele puncte
de vedere asupra calităţii software într-un singur model. ISO 9126 reprezintă un
model ierarhic cu şase caracteristici de bază, descrise în figura 4.6. Fiecare dintre
caracteristici este detaliată într-un set de subcaracteristici cărora li se asociază

metrici software. Din această cauză, modelul este numit şi modelul caracteristică –
subcaracteristică – metrică. Identificând caracteristici de calitate interne şi externe,
este analizat şi comportamentul sistemului pe care rulează produsul software.
MENTENABILITATE FUNCŢIONALITATE
EFICIENŢĂ Modelul FIABILITATE

ISO 9126
PORTABILITATE UZABILITATE
Figura 4.6 Caracteristicile de bază ale modelului ISO 9126
Se aprofundează relaţiile dintre caracteristicile de calitate şi urmăreşte să

descrie cu exactitate proprietăţile produselor software care afectează atributele
calităţii.
Tabelul 4.5 conţine sinteza principalelor atribute ale modelelor prezentate.
Descrierea modelelor de sisteme de caracteristici de calitate

Tabel 4.5
Model
Boehm McCall I.C.I. ISO
9126
Număr de. caracteristici de nivel înalt 10 11 6 6
Număr de caracteristici de nivel scăzut 12 22 19 21
Număr total de caracteristici 22 33 25 27
Număr de niveluri în arbore 4 2 2 2
Caracteristicile de nivel scăzut Da Da Nu Nu
determinã mai mult de o caracteristicã
de nivel înalt?
Caracteristicile de calitate implementate în majoritatea modelelor sunt:

eficienţă, fiabilitate, mentenabilitate, portabilitate, uzabilitate şi funcţionalitate. Ele
sunt considerate caracteristici esenţiale ale produsului software.
Diferenţa între modele constă în numărul de caracteristici primitive, care
influenţează implicit numărul caracteristicilor de nivel înalt. Faţă de modelul ISO,
modelele McCall şi Boehm conţin un număr mai mare de caracteristici de nivel
inferior, ceea ce determină deplasarea legăturilor de interdependenţă dintre
caracteristicile structurii de nivel înalt către structura de nivel inferior.
4.4 Complexitatea software
Problema complexităţii este pusă în mod similar cu problema simplităţii.

Un program simplu, conţine puţine instrucţiuni, puţini operanzi. El este scris
fără eforturi deosebite. Mai mult, programul simplu, efectuează un număr restrâns de
tipuri de prelucrări. Un produs software este caracterizat prin:
structură definită ca proceduri care sunt apelează şi care apelează la
rândul lor; programul principal este considerat rădăcina într-o structură
arborescentă; nodurile interne ale arborescenţei sunt procedurile care
apelează şi sunt apelate; frunzele sunt proceduri apelate, dar care nu
conţin la rândul lor apeluri; structura are un număr de proceduri şi un
număr de niveluri;
tipuri de date utilizate, mod de agregare a acestora şi mod de referire; se
lucrează cu masive, fişiere, liste, arbori, grefuri, date elementare; referirea
se efectuează indirect prin pointeri sau direct prin expresii de referire în
care apar nume de variabile, indici şi constante; diversitatea este dată de
numărul tipurilor de date, numărul de niveluri de structurare şi de
numărul tipurilor de expresii de referire;
modul în care se realizează introducerea datelor, capacitatea de a asigura
lucru cu date de intrare complete şi corecte; capacitatea de a efectua
corelaţii între datele de intrare introduse într-o succesiune dată sau în
succesiunea dorită de utilizator; se verifică dacă datele sunt complete şi
dacă există criterii de validare, se verifică dacă datele sunt corecte;
diversitatea tipologiilor de rezultate care se obţin; o aplicaţie este
construită aşa fel încât să permită realizarea unui set complet de prelucrări
ce se finalizează printr-un set de rezultate care se afişează, se imprimă sau
se stochează pe suport în vederea prelucrărilor ulterioare; produsul
software se proiectează aşa fel încât să permită fie gestionarea întregului

set, fie extragerea şi gestionare (afişare, stocare, imprimare) de subseturi
de rezultate;
modalitatea de lucru în raport cu numărul utilizatorilor; aplicaţiile
monopost sunt construite în concepţia concentrării atât a modului de
introducere a datelor, a prelucrării lor, cât şi a modului de obţinere a
rezultatelor finale; numai după efectuarea prelucrărilor complete,
responsabilul monopostului procedează la difuzarea rezultatelor; înainte
de lansarea prelucrărilor, acelaşi responsabil procedează la colectarea şi
verificarea de fond a datelor, după care declanşează procesele de
introducere şi prelucrare; aplicaţiile în reţea sunt bazate pe distribuirea
informaţiei, pe acceptarea unui număr oarecare de utilizatori care lucrează
simultan şi accesează de asemenea simultan baza de date a aplicaţiei; în
acest context, problema modului de lucru omogen este esenţială;
omogenitatea este privită aici în raport cu volumul de date: toţi utilizatorii
introduc date cu acelaşi grad de acoperire a fenomenelor, cu aceeaşi
precizie şi mai ales cu acelaşi nivel de corectitudine; datele acoperă
intervalul considerat optim pentru definirea calităţii de operare în timp
real acceptată de utilizatorii finali ai rezultatelor;
existenţa de componente care adaptează în mod dinamic structura
produsului software pentru a răspunde integral la cerinţele utilizatorilor
sau pentru a prelucra noi cerinţe de prelucrare; problema de bază a
oricărui produs software este durata de utilizare, iar condiţia rămânerii în
uz a produsului software este acceptarea de către acesta a modificărilor, a
eliminării sau a adăugărilor de module care să conducă în final la
obţinerea de rezultate complete şi corecte în raport cu noile condiţii care
apar.
Complexitatea este o caracteristică importantă a produsului software întrucât

influenţează:
duratele de execuţie din cadrul fiecărei etape a ciclului de dezvoltare
software;
productivitatea muncii analiştilor, proiectanţilor, programatorilor şi
respectiv a utilizatorilor;
nivelurile resurselor necesare realizării modulelor componente;
costul de producţie şi preţul de vânzare;
raportul cerere/ofertă, întrucât pe piaţa de software producătorii oferă

multe produse cu complexitate mică sau medie, corespunzătoare
capacităţii lor de a aloca resurse în avans pentru dezvoltarea de aplicaţii
informatice.
Complexitatea software este o caracteristică evidenţiată numai prin

comparaţia între două sau mai multe produse software. Cel mai simplu program
este programul vid. Acesta nu conţine operanzi, variabile, constante şi nici
instrucţiuni.
void main ( )
{
Un program este simplu dacă are definite variabile de acelaşi tip şi utilizează un
singur tip de operatori. De exemplu programul:
void main ( )
{
static int a, b, c, d;
a++;
b++;
c++;
d++;
}
conţine numai variabile de tip întreg, iar prelucrările se realizează prin

postincrementare.
Analiza calitativă a complexităţii programelor prezintă importanţă întrucât
sintetizează trăsăturile de bază ale acestora. În primul rând se identifică o serie de
trăsături ale programelor de analizat. În al doilea rând se construieşte un sistem de
coeficienţi de importanţă pentru aceste trăsături, sub formă de punctaj. În al treilea
rând, se stabilesc modalităţi de măsurare (apreciere) a trăsăturilor. În al patrulea
rând, se construieşte un tabel în care se consemnează rezultatele constatărilor
referitoare la fiecare produs software. În al cincilea rând, se trece la atribuirea de
punctaje acelor trăsături identificate.
Se adună punctele. Rezultă o diferenţiere a produselor software după setul

de trăsături definite. Complexitatea este o caracteristică dinamică bazată pe
diferenţele care apar între generaţiile de software şi de hardware. Elementele noi,
introduse de noile generaţii, prin efectele pozitive sunt incluse în structurile
produselor software şi toţi indicatorii de complexitate care se definesc sunt sau nu
adecvaţi măsurării complexităţii în măsura în care au capacitatea de a reflecta noile
trăsături ale generaţiilor de software şi hardware.
În evaluarea complexităţii produselor software este importantă definirea
riguroasă a factorilor şi a modalităţilor lor de cuantificare. De asemenea, pentru
trecerea la automatizare este importantă modalitatea de definire a algoritmilor, de
identificare a factorilor şi de contorizare a prezenţei lor aşa fel încât între
metodologia stabilită de calcul a complexităţii software şi programul care
evaluează automat complexitatea să nu existe diferenţe.
Complexitatea programelor se calculează folosind textul sursă sau pe baza
grafului asociat sau prin intermediul trăsăturilor identificate.
Programul este format din instrucţiuni. Un indicator al complexităţii
programelor este numărul de instrucţiuni.
Instrucţiunea este cea mai mică parte dintr-un program care defineşte
complet un context.
Astfel:
int a, b, c;
este o instrucţiune, iar contextul revine la precizarea faptului că a, b, c sunt

operanzi având tipul întreg.
Construcţia :
a = b + c;
este de asemenea o instrucţiune. În acest caz instrucţiunea corespunde unei

expresii aritmetice de atribuire.
Construcţia:
printf( ” %d %d”, a , b);
corespunzătoare apelului unei funcţii este o instrucţiune.

În ipoteza în care o expresie de atribuire de forma a = b + c este o

instrucţiune, construcţia:
a + = b + = c + = d *e;
este tratată tot ca o singură instrucţiune, are loc pierderea gradului de omogenitate
a instrucţiunilor.
Dacă se doreşte menţinerea gradului de omogenitate, expresia de atribuire
multiplă este pusă în corespondenţă cu atâtea instrucţiuni, câţi operatori de atribuire
conţine.
În exemplu considerat, expresia este asociată unui număr de trei
instrucţiuni.
Expresia virgulă:
a++, ++b, c = a + b;
permite evaluarea unei liste de expresii.

Secvenţa de program:
int a;
int b;
int c;
float d;
este pusă în corespondenţă cu numărul patru, al instrucţiunilor ce o alcătuiesc.

Construcţiile compuse conţin un număr de instrucţiuni, cu luarea în
considerare a elementelor de bază care definesc o instrucţiune.
Astfel, secvenţa:
if(a>b)
{
x = y * y;
z = w –2;
}
else
{
x++;
z = w *2;
y = x * y;
}
conţine o instrucţiune if şi două blocuri. Primul bloc conţine două instrucţiuni, iar
al doilea bloc conţine trei instrucţiuni. În total secvenţa conţine şase instrucţiuni.
Secvenţa:
if ( a>b ) if (a>c) vb = a;
else vb = c;
else
if(b>c) vb = b;
else
vb = c;
conţine, trei instrucţiuni if şi patru expresii de atribuire, în total şapte instrucţiuni.

Secvenţa:
for(i = 0; i <n; i++) S+=x[i];
conţine:
o instrucţiune for( );
patru expresii, din care două expresii de atribuire.
Această secvenţă este formată din 5 instrucţiuni.
Se observă modul de descompunere a instrucţiunilor compuse prin luarea
în considerare a ipotezei conform căreia la numărare se includ atât părţile cât şi
întregul.
Astfel, regulile stabilite aici sunt:
¾ o expresie simplă este o instrucţiune;
¾ apelul funcţiei neinclus într-o expresie este o instrucţiune;
¾ apariţia unui cuvânt cheie precum int, float, char, if, for, switch, while,
do, determină contorizarea unei instrucţiuni.
Important este ca regulile stabilite să fie utilizate uniform pentru toate

loturile de programe.
Este posibilă definirea altor reguli de numărare a instrucţiunilor. Este
importantă utilizarea acestor reguli în mod nediferenţiat pentru toate programele.
Astfel este asigurat caracterul comparabilităţii valorilor măsurate.
În programele scrise în limbaj de asamblare, instrucţiunile au acelaşi grad
de agregare, egal cu unu, ceea ce conduce la simplificarea modului de numărare a
instrucţiunilor.
Secvenţa:
MOV SI, offset x

MOV AX, 5
CMP BX, 0
JNZ alfa
ADD AX,CX
MOV CX,8
ciclu:
ADD AX, [SI]
ADD SI, 2
LOOP ciclu
alfa:
MOV e,AX
Conţine exact zece instrucţiuni, indiferent de convenţiile de numărare

utilizate.
Dacă se acceptă ipoteza conform căreia un program cu cât este mai

complex cu atât are în alcătuire mai multe instrucţiuni, unul dintre indicatorii de
măsurare a complexităţii este numărul liniilor de cod sursă care formează
programul.
Pentru a asigura comparabilitatea programelor prin acest indicator trebuie
clarificat conceptul de linie sursă.
Linia sursă corespunde unei singure instrucţiuni sau unui număr mai mare
de instrucţiuni. Sunt foarte rare cazurile în care pe o linie sursă sunt mai mult de
cinci instrucţiuni.
De regulă, pentru asigurarea lizibilităţii programelor se recomandă plasarea
instrucţiunilor aşa fel încât să se asigure lizibilitatea programelor.
În tabelul 4.6 sunt prezentate rezultatele analizei pe texte sursă, pentru a

evidenţia legătura dintre textele sursă privite ca număr de linii sursă, respectiv, ca
număr de instrucţiuni.
Numărul de instrucţiuni şi numărul de linii sursă

Tabel 4.6
Program Număr instrucţiuni Număr linii sursă
P1 33 38
P2 25 26
P3 41 51
P4 18 23
P5 30 39
P6 14 15
P7 34 47
P8 144 149
P9 51 63
P10 22 27
P11 16 25
P12 27 45
P13 139 150
În condiţiile unui stil de programare echilibrat nivelurile coeficienţilor de

corelaţie calculaţi pentru seriile de date construite în tabelul 4.6 au niveluri care
pun în evidenţă caracterul neintenţionat al plasării de instrucţiuni într-un număr dat
pe o linie sursă aşa cum rezultă din tabelul 4.7
Coeficient de corelaţie între linii sursă şi număr de instrucţiuni pe o linie sursă

Tabel 4.7
Număr linii sursă Număr instrucţiuni
Număr linii sursă 1 0,993948
Număr instrucţiuni 0,993948 1
Coeficientul de corelaţie dintre numărul liniilor sursă şi totalul de

instrucţiuni din program are un nivel apropriat de 1 ceea ce conduce la acceptarea
ipotezei că numărul de linii sursă este un indicator reprezentativ pentru
complexitatea programului privită prin intermediul instrucţiunilor.
Complexitatea programului depinde de diversitatea tipurilor de variabile şi

de constante, respectiv, de diversitatea instrucţiunilor şi operatorilor folosiţi în
modulele care alcătuiesc programul.
Se consideră un program Prog în care se utilizează variabilele de tip Tip1,
Tip2, …, Tipntip, se utilizează cuvintele cheie Key1, Key2, …, Keymkey care
desemnează funcţii apelate, instrucţiuni executabile şi nu părţi din instrucţiuni. De
asemenea, se folosesc operatorii Oper1, Oper2, …, Operpoper.
void main()
{
int a,b,i;
char x,y;
float r,s,x[5];
a=b=5;
x='c';
y='d';
r=s=3.14159;
if(a>r) b++
else
b--;
if(++a<b) y--;
else
--y;
for(i=0;i<5;i++)
x[i]=i*i+1;
s=x[0]+x[1]+x[2]+x[3]+x[4];
printf("\n %d %d %d",s,b,y);
}
Figura 4.7 Program C cu teste, iniţializări şi afişare
În programul din figura 4.7:

` variabilele sunt: Tip1 – int, Tip2 – char, Tip3 – float;
` cuvintele cheie: Key1 – if, Key2 – for, Key3 – printf;
` operatorii: Oper1 - =, Oper2 – [], Oper3 - +, Oper4 - ++, Oper5 - --,
Oper6 – ( ), Oper7 - <, Oper8 - *, Oper9 - %, Oper10 – { }.
Se consideră indicatorul:
N tipuri
Indct = ∑ frecv log

i =1
i 2 frecvi
unde:
Ntipuri – numărul tipurilor de categorii ale structurii;
frecvi – frecvenţa de apariţie a categoriilor.
Dacă se consideră N = 2 pentru că se operează cu 2 categorii şi anume:

categoria operanzilor şi, respectiv, categoria operatorilor şi dacă se notează n1 –
frecvenţa de apariţie a elementelor din categoria operanzilor, şi respectiv, n2 –
frecvenţa de apariţie a elementelor din categoria operatorilor se obţine indicatorul
de complexitate Halstead.
CHalstead = n1 log2 n1+ n2 log2 n2.
Pentru programul P considerat în figura 5.4.1, n1 = 3, n2 = 13.

Indicatorul de complexitate Halstead reuneşte în categoria operatorilor atât
instrucţiunile (3) cât şi operatori aritmetici şi relaţionali (10). Complexitatea
Halstead pentru programul P este:
CHalstead = 3 log2 3 + 13 log2 13 = 51,99
Dacă se diferenţiază operatorii în instrucţiunile şi operatorii cu care se

construiesc expresii se obţine un alt nivel al complexităţii, şi anume:
~
C = 3 log2 3 + 3 log2 3 + 10 log2 10 = 41,98
În [IVAN97] este prezentat indicatorul de complexitate cu luarea în

considerare a 6 categorii, şi anume:
fh1 – numărul de tipuri fundamentale de date care apar distinct în program;
fh2 – numărul de tipuri derivate de date care apar distinct în program;
fh3 – numărul de instrucţiuni distincte utilizate de programator;
fh4 – numărul de operanzi distincţi pentru calcule care apar în program;
fh5 – numărul de operatori distincţi pentru referire de operanzi care apar în

program;
fh6 – numărul de funcţii distincte apelate.
Deci, complexitatea este definită de relaţia:

6
Cˆ = ∑ fhi log 2 fhi
i =1
Dacă se definesc variabilele:
η (1) fh = fh1 + fh2

η ( 2) fh = fh3 + fh4 + fh5 + fh6
atunci valoarea complexităţii este determinată de relaţia:
(
C = η (1) fh log 2 η (1) fh + η ( 2) fh log 2 η ( 2 ) fh
Aceasta este identică cu forma relaţiei complexităţii Halstead. Datorită

relaţiei:
a log 2 a + b log 2 b ≤ ( a + b ) log 2 ( a + b ), unde a, b ∈ N
*
demonstrată în [IVAN97], rezultă că Cˆ < C Halstead . Deci metrica derivată a

complexităţii Halstead este mai fină decât metrica iniţială şi aproximează mai
riguros diversitatea de componente din program.
Indicatorul:
N
C = ∑ f i log 2 f i
i =1
creează o imagine bună asupra programelor. Pentru a realiza compararea

programului Prog în sensul stabilirii poziţiei sale într-o mulţime de programe, este
necesară normarea indicatorului folosind relaţia:
N
∑f i log 2 f i
IC = i =1
, cu IC ∈ [0,1]
⎛ N ⎞ ⎛ N ⎞
⎜ ∑ f i ⎟ log 2 ⎜ ∑ f i ⎟
⎝ i =1 ⎠ ⎝ i =1 ⎠
Dacă nivelul calculat al indicatorului IC pentru un program este 0,

complexitatea programului are nivelul minim, iar dacă nivelul calculat este 1,
complexitatea este maximă. Valoarea normată evidenţiază modul cât de bine sunt
utilizaţi operanzii şi operatorii în alcătuirea programelor.
Pentru programul P indicatorul normat al complexităţii este:
3 log 2 3 + 13 log 2 13
IC = = 12,9 cu IC ∈ [0,1].
16 log 2 16
Complexitatea programelor bazate pe structură obţinută prin graful asociat

foloseşte indicatorii McCabe şi indicatorul LIL, [IVAN99].
Fie un program Md principal, care apelează procedurile Proc2, Proc3.

procedura Proc1 apelează la rândul ei procedurile Proc11 şi Proc12. Procedura Proc2
apelează procedurile Proc21, Proc22 şi Proc23. Procedura Proc3 apelează procedurile
Proc31, Proc32, Proc33. Procedurile Proc11, Proc12, Proc21, Proc22, Proc23, Proc31,
Proc32, Proc33 nu conţin apeluri ale altor proceduri.
Structura de tip graf asociată acestui program este dată în figura 4.8.
Md
Proc1 Proc2 Proc3
Proc11 Proc12 Proc21 Proc22 Proc23 Proc31 Proc32 Proc33
Figura4.8 Structura arborescentă asociată programului
Structura arborescentă este caracterizată prin

` număr de niveluri;
` numărul de componente ale fiecărui nivel;
` modul de grupare a elementelor în cadrul fiecărui nivel.
Dacă se asociază fiecărui nivel o pondere, 1 pentru primul nivel, 2 pentru

nivelul unde se află procedurile Proc1, Proc2, Proc3, respectiv, 3 pentru nivelul unde
se află procedurile Proc11, Proc12, Proc21, Proc22, Proc23, Proc31, Proc32, Proc33,
dintre modalităţile de agregare se propune relaţia corespunzătoare nivelului j din
structura dată în figura 4.9.
nrmodule nivelj
I ( j)
Complex (Proc ) = α nivejl * ∑ I Complex (Proci )
i =1
în care:
αnivelj – ponderea asociată nivelului j din arbore pe care se află
modulul procedurii Proc;
nrmodulenivelj – numărul de module ale nivelului j;
Proc – modulul pentru care se determină valoarea agregată a
complexităţii subarborelui al cărui rădăcină este;
IComplex(Proc) – complexitatea agregată a subarborelui cu rădăcină în
modulul Proc.
Md
Nivel αnivelj
M1 M2 Mp
………….
Figura 4.9 Parte din structura arborescentă corespunzătoare nivelului αnivelj.
Dacă procedurilor de la bază li se asociază complexitatea egală cu 1, pentru

structura arborescentă dată în figura 4.8, organizată pe trei niveluri, în care nivelul
programul principal Md are ponderea 1, procedurile Proc1, Proc2, Proc3 au
ponderea 2, iar celelalte proceduri se află pe nivelul cu pondere 3, complexitatea
calculată este:
IComplex (Proc11) = IComplex (Proc12) = IComplex (Proc21) = IComplex (Proc22) = IComplex

(Proc23) = IComplex (Proc31) = IComplex (Proc32) = IComplex (Proc33) = 1;
IComplex (Proc1) = 3*( IComplex (Proc11) + IComplex (Proc12) ) = 6;

IComplex (Proc2) = 3*( IComplex (Proc21) + IComplex (Proc22) + IComplex (Proc23) ) = 9;
IComplex (Proc3) = 3*( IComplex (Proc31) = IComplex (Proc32) = IComplex (Proc33) ) = 9;
IComplex (Md) = 2*( IComplex (Proc1) + IComplex (Proc2) IComplex (Proc3)) = 48.
Generalizarea modelului de calcul pentru structura arborescentă organizată

pe pniveluri niveluri este:
⎛ nrmodulenivel 2 ⎛ ⎛ nrmodulenivelpniveluri ⎞⎞
( )⎞⎟⎟...⎟⎟ ⎟⎟
nrmodule nivel 1
I (Md ) = α nivel 1 ∑ ⎜
⎜ ∑ ∑ I MdiN
α nivel 2 ⎜
α niveli3 ....α nive lpniveluri ⎜⎜
⎜
i1 =1
⎝ i2 =1 ⎝ ⎝ i N =1 ⎠ ⎠⎠
Normarea acestui indicator de complexitate se realizează în raport cu graful

dat în figura 4.10.
Modul M1 Nivel 1
Modul M2 Nivel 2
Modul MPniveluri-1 Nivel pniveluri-1
…………. Nivel pniveluri

A1 A2 AQProc
Figura 4.10 Graf de normalizare asociat unui arbore cu pniveluri niveluri
Se defineşte indicatorul:
NProc = pniveluri –1 + QProc
unde:
NProc – numărul de proceduri, noduri, asociate programului considerat;
pniveluri – numărul de niveluri al grafului de normalizare;
QProc – numărul de module aflate pe ultimul nivel.
Pentru programul cu structură arborescentă din figura 4.8, caracterizat prin

NProc = 12, graful de normalizare asociat este reprezentat în figura 4.11.
M1 Nivel 1
M2 Nivel 2
…………. Nivel 3
A1 A2 A3 A10
Figura 4.11 Graful de normalizare asociat programului M
Valoarea complexităţii agregate este:

13
I (M 2 ) = 3 * ∑ I ( Ai ) = 30
i =1
în ipoteza:
I(Ai) = 1;
I(M1) = 2*I(M2) = 60.
Complexitatea relativă este:
I (M ) 48
IR = = = 0,8
I (M 1 ) 60
Problema complexităţii modulelor unui program este abordată şi incluzând

parametrii care se transmit de la un modul al altul sau de la nivelul i la nivelul i+1
din arborescenţă. În acest caz, complexitatea modulului Md este:
ComplexitateMd = nprm I log 2 nprm I + nprm E log 2 nprm E + nprm S log 2 nprm S
unde:
nprmI – numărul parametrilor de intrare;
nprmE – numărul parametrilor de ieşire;
nprmS – numărul parametrilor de stare, care arată cum s-a făcut
prelucrarea.
Mergând la nivel de instrucţiuni, programului i se asociază graful prin

punerea în corespondenţă a fiecărei instrucţiuni cu un nod. Instrucţiunile care
formează secvenţe lineare sunt puse în corespondenţă cu nodul dat în figura 4.12.
I1 Secvenţă de instrucţiuni Instrucţiune
I2 Instrucţiune simplă; I1
Instrucţiune simplă; I2
Figura4.12 Instrucţiuni în secvenţă lineară
Instrucţiunii de salt condiţionat i se asociază modelul dat în figura 4.13.
Secvenţă de instrucţiuni Instrucţiune

I1
if
I2 (condiţie) I1
I3
if
(condiţie) I3
I4 I5
else
I6
Figura 4.13 Nodul asociat instrucţiunii de salt condiţionat
Instrucţiunii repetitive WHILE i se asociază graful descris în figura 4.14.

I1 Secvenţă de instrucţiuni Instrucţiune
while
I2 {
(condiţie) I1
}
Figura 4.14 Nodul asociat instrucţiunii repetitive WHILE

Reprezentarea instrucţiunii repetitive FOR printr-un graf conduce la

obţinerea figurii 4.15.
I1
I2
for
I4 (iniţializare contor; I1
condiţie; I2
I3 modificare contor) I3
I5 for
(iniţializare contor; I5
I6 ; I6
modificare contor) I7
I8 If
(condiţie) I8
I9 I7 break; I9
I10
Figura 4.15 Nodul asociat instrucţiunii repetitive FOR
Instrucţiunii de salt condiţionat SWITCH i se asociază secvenţa de graf

dată în figura 4.16.

I1
switch
I2 I3 (condiţie) { I1
case 0:
case 1:
default:
}
Figura 4.16 Graf asociat instrucţiunilor de salt condiţionat SWITCH

Pentru programul dat în figura 4.17 care evaluează expresia:
a+b
expres =
c*d
Cu verificarea numitorilor c şi d pentru a nu se efectua împărţirea prin 0,

graful asociat este descris în figura 4.18
void main()
{
int vb;
float a,b,c,d,e;
vb=0;
do
{
scanf("%f,%f",&a,&b);
scanf("%f,%f",&c,&d);
if((c!=0)&&(d!=0))
{
e=(a+b)/(c*d);
printf("Rezultatul este: %f", e);
vb=1;
}
else
printf("\n Nu se poate calcula
expresia !");
} while(vb!=1);
}
Figura 4.17 Program pentru evaluarea expresiei e

I1 – iniţializare vb
I2 – scanf( );
I3 – scanf( );
I4 – verificare c = 0
I5 – verificare d = 0
I6 – calcul e I9 - printf( )
I7 – printf( )
I8 – vb = 1
I10 – verificare vb
Figura 4.18 Graful asociat programului de evaluare a expresiei e = (a + b) / (c*d)
Dacă se notează:
nnoduri – numărul de noduri din graf ;
marce – numărul de arce din graf;
Indicatorul de complexitate McCabe, numărul ciclomatic al grafului,

CMcCabe, este dat de relaţia:
CMcCabe = marce – nnoduri + 2
Pentru graful dat în figura 4.18, există nnoduri = 10 noduri, şi marce = 11 arce,
iar complexitatea în sens McCabe, CMcCabe are valoarea 3. Indicatorul de
complexitate prezentat în [IVAN99] ia în considerare precedenţele.
Clasificarea indicatorilor utilizaţi pentru a măsura complexitatea se face în
funcţie de mai multe criterii.
După valoarea determinată a complexităţii există:

¾ indicatori cu valori cuprinse în intervalul [0; 1/3], ce descriu un grad
scăzut al complexităţii;
¾ indicatori cu valori cuprinse în intervalul (1/3; 2/3), ce descriu nu grad
ridicat al complexităţii;
¾ indicatori cu valori cuprinse în intervalul [2/3; 1], ce descriu nu grad
foarte mare al complexităţii.
După tipul datelor de intrare, sunt definiţi indicatori ce folosesc:

` textul sursă al secvenţei de cod;
` graful asociat.
După modul în care sunt tratate elementele ce formează datele de intrare,

indicatorul asociat complexităţii software este:
omogen, considerând toate intrările de acelaşi fel;
diferenţiat, ţinând seama de cum au fost obţinuţi sau de ce reprezintă.
După structura indicatorilor, aceştia utilizează:

o variabilă; de exemplu numărul de instrucţiuni executabile;
două variabile; complexitatea în sens Halstead este determinată în
funcţie de numărul operatorilor şi numărul operanzilor;
mai mult de două variabile.
Este important să se găsească un indicator care să reflecte cât mai fidel

complexitatea, întrucât în faza de proiectare, estimarea complexităţii are un rol
esenţial în asigurarea necesarului de resurse, în estimarea costurilor şi mai ales în
definirea condiţiilor în care produsul software este profitabil.
4.5 Concluzii
Calitatea software este obiectivul central al procesului de dezvoltare

software. Pentru aceasta, numeroase cercetări au evidenţiat o serie de caracteristici
de calitate ce descriu în totalitate performanţele produsului program.
În condiţiile în care societatea depinde tot mai mult de aplicaţiile
informatice, consumatorul a căpătat abilitatea de a diferenţia produsele cu nivel
ridicat la calităţii de produsele predispuse la erori şi care nu îi satisfac nevoile

legate de:
obţinerea rezultatelor dorite;
caracter general de rezolvare a problemelor;
uşurinţă în utilizare şi înţelegere;
instrumentele puse la dispoziţie;
prelucrarea datelor între limite stabilite;
probabilitatea de blocare a execuţiei şi pierderea informaţiei;
resursele hardware şi software minime.
Calitatea produsului software a devenit o condiţie esenţială de a rămâne pe

piaţă. Pentru a învinge concurenţa produsele trebuie să coste puţin, să aibă calitate
cât mai mare şi să fie realizate în cel mai scurt timp. Acest obiectiv este atins doar
printr-o abordare organizată, planificată a procesului de determinare şi
implementare a caracteristicilor software de calitate.

Pa Gin A 1

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Pa Gin A 1

Încărcat de

Drepturi de autor:

Formate disponibile

4

4.1 Sistemul caracteristicilor de calitate

După cum se arată şi în definiţia dată de standardul ISO, [ISO86],calitatea

CC3 CC4 CC5 CC6

Figura 4.1 Structură ierarhizată a caracteristicilor de calitate

Construirea structurii arborescente implică parcurgerea etapelor:

Nivelurile măsurate ale setului de caracteristici

 se stabilesc dependenţele dintre caracteristicile de calitate r(xj, xl),

nprog nprog nprog

 se ordonează descrescător dependenţele măsurate, r(xccj, xccl);

Matricea simetrică a coeficienţilor de corelaţie ai caracteristicilor de calitate

Obţinerea structurii arborescente asociate celor şase caracteristici are loc

CC1 CC3 CC3

Figura 4.2 Structura arborescentă asociată tabelului 4.2

 se caută valoarea maximă de pe coloana corespunzătoare caracteristicii

Structura sistemului caracteristicilor de calitate se construieşte şi sub forma

¾ modificabilitate, descrie efortul consumat pentru a îmbunătăţi sau

Corectabilitate Modificabilitate Testabilitate

Figura 4.3. Dependenţe dintre caracteristicile de calitate

La elaborarea unui sistem de programe, utilizatorul, cel care este de fapt

Se consideră un număr de 25 de utilizatori Ut1, Ut2, …, Ut25 şi trei

Ponderile date de utilizatori caracteristicilor de calitate

Total 1439 674 387 2500

În ipoteza în care pentru caracteristicile de calitate CC1, CC2, CC3 sunt

IQ = 0,5756* nivelF + 0,2696* nivelP + 0,1548* nivelM

Dacă se consideră programul Prog pentru gestiunea contabilă a firmei, cu

4.2 Descrierea caracteristicilor de calitate

¾ etapa de implementare şi testare: cuprinde instalarea produsului într-un

Programele sunt elaborate pentru a îndeplini funcţii de prelucrare cerute de

Programele sunt produse a căror existenţă fizică este dată de ansamblul

` cu interfaţă user friendly; performanţele de lucru ale utilizatorul nu sunt

Nivelurile stabilite ca obiectiv pentru caracteristicile de calitate urmărite,

De cele mai multe ori, aplicaţiile la nivelul companiilor impun lucrul în

Calitatea software este un concept complex, iar perfecţionarea sa are la

Factorii de calitate avuţi în vedere sunt:

Pe de o parte există programul care permite rezolvarea unei probleme şi pe

Se consideră un program P livrat în formă executabilă. Portabilitatea este

Gradul de portabilitate este dat de relaţia:

De exemplu, produsul program SalSal destinat calculării salariului

s-au efectuat în Tmodif2 = 110 minute; se are în vedere că timpul de

Pe baza acestor date, se obţin gradele de portabilitate:

(240 − 83) + (168 − 110)

6450 − (175 + 23 + 32 + 143 + 12 + 10 )

Se observă că valoarea gradului de portabilitate este dependentă de

Portabilitatea produsului software în raport cu datele de intrare devină

Mentenanţa este un proces specific produselor software destinate să

tranzacţii şi pentru a prelucra noile date. Programul este mentenabil în măsura în

şi dacă această expresie este vulnerabilă a fi modificată fie prin efectuarea

 introducerea de elemente care asigură variabilitate în efectuarea de

g1(x), dacă x ε [a1, b1];

presupune utilizarea unui masiv unidimensional cu n+1 componente, a1,

Mentenabilitatea în raport cu evoluţiile hardware este posibilă în faza de

generaţiile precedente. Dezavantajele apar din imposibilitatea de a folosi facilităţile

Programarea orientată obiect este rezultatul direct al necesităţii elaborării

elementelor încât să se asigure o prelucrare completă. Operanzii şi operatorii

Reutilizarea software devine operaţională vând componentele disponibile

De exemplu, programul CompSoft implementează operaţii pe matrice

calcul cu matrice. Cum codul sursă al programului CompSoft conţine LT = 1150 de

Când se analizează un program este necesar să se identifice:

În acest context se calculează gradul risipei de muncă vie inclusă în

De regulă, atunci când este apreciat un program se evaluează indicatorul

La proiectarea software se identifică operaţii de prelucrare de prelucrare

Modulele sunt înzestrate cu un grad de generalitate suficient de mare aşa

se stabilesc dependenţele dintre caracteristicile de calitate r(xj, xl),

se ordonează descrescător dependenţele măsurate, r(xccj, xccl);

se caută valoarea maximă de pe coloana corespunzătoare caracteristicii

introducerea de elemente care asigură variabilitate în efectuarea de

raportul cerere/ofertă, întrucât pe piaţa de software producătorii oferă