CARACTERISTICI DE CALITATE ALE

APLICAŢIILOR DISTRIBUTE

1 Sistemul carcateristicilor de calitate

În [BARO82], [BARO82a], [BARO83], [BARO84], [IVAN06] este definit sistemul

caracteristicilor de calitate software.
Calitatea software este definitǎ ca totalitatea însuşirilor tehnice, economice şi sociale
ale aplicaţiilor informatice.
De la aplicaţie la aplicaţie caracteristicile de calitate au rol diferenţiat, dat de specificul
aplicaţiei. Pentru aplicaţiile din tehnologia nuclearǎ produsele software trebuie sǎ fie cu
fiabilitate maximǎ.
Pentru aplicaţiile în timp real produsele software trebuie sǎ aibǎ optimalitate în ceea ce
priveşte minimizarea duratei de prelucrare.
Pentru aplicaţiile în care se prelucreazǎ volume foarte mari de date, corectitudinea este
esenţialǎ.
Pentru aplicaţiile în care variaţiile la nivelul algoritmilor de prelucrare, la nivelul
structurilor de date sunt deosebit de frecvente, mentenanţa este caracteristica de calitate
asupra cǎreia dezvoltatorii de software trebuie sǎ insiste foarte mult.
În raport cu fiecare aplicaţie dezvoltatorii şi utilizatorii se fixeazǎ asupra unor
caracteristici de calitate pe care le şi ierarhizeazǎ, definind în acest fel un sistem al
caracteristicilor de calitate, pentru care se alocǎ resurse şi fonduri.
Sistemul caracteristicilor de calitate se defineşte în [BARO82] ca un ansamblul de
caracteristici între care existǎ multiple relaţii de interdependenţǎ, subordonare, ierarhizare sau
agregare.
Planificarea nivelului de calitate global al aplicaţiei se bazeazǎ pe nivelurile
caracteristicilor ierarhizate existente în sistem.
Controlul calitǎţii revine la a controla modul în care este realizat nivelul de calitate
pentru caracteristicile incluse în sistem.
Optimizarea calitǎţii se referǎ la caracteristicile de calitate incluse în sistemul de
caracteristici, în raport cu criteriul de cost, astfel încât sǎ se realizeze o maximizare a calitǎţii
în condiţiile menţinerii costului în limite de suportabilitate.
Fiabilitatea este cea mai importantǎ caracteristicǎ de calitate software şi constǎ în
capacitatea aplicaţiei informatice de a-şi menţine nivelul de performanţǎ în anumite condiţii
date pentru o perioadǎ specificatǎ de timp. Un produs software trebuie sǎ aibǎ cât mai puţine
eşuǎri şi sǎ fie cât mai uşor de reparat.
1
 Eficienţa este caracteristica de calitate software reprezentatǎ prin gradul cu care
aplicaţia informaticǎ îşi îndeplineşte scopurile fǎrǎ sǎ iroseascǎ resursele. Ea se referǎ la
relaţia dintre nivelul de performanţǎ şi volumul de resurse utilizate în anumite condiţii.
Corectitudinea este caracteristica de calitate cel mai greu de acoperit. Ea indicǎ gradul
în care o aplicaţie informaticǎ satisface cerinţele din specificaţii. Pentru produsele software
care au o complexitate mare este imposibilǎ o testare exhaustivǎ care sǎ ofere certitudinea cǎ
toate erorile au fost depistate şi corectate.
Mentenabilitatea este caracteristica de calitate care se evidenţiazǎ dupǎ lansarea în
execuţie a aplicaţiei informatice şi reprezintǎ uşurinţa cu care se fac modificǎri pentru a
satisface noi cerinţe sau pentru a corecta deficienţe.
Portabilitatea se referǎ la uşurinţa cu care programul software este folosit pe alte
configuraţii de sisteme de calcul.
Reutilizabilitatea se exprimǎ prin uşurinţa cu care se poate refolosi un produs software
în dezvoltarea altui produs. Prin refolosirea unui software existent dezvoltatorii pot crea
aplicaţii informatice mai complexe într-o perioadǎ mai scurtǎ de timp.
Structura sistemului de caracteristici este supusǎ optimizǎrii în ideea cǎ numǎrul de
caracteristici trebuie sǎ fie minim în raport cu efectele asupra eficienţei utilizǎrii aplicaţiei şi
sporului de cunoaştere pe care-l dǎ.
O datǎ cu utilizarea permanentǎ a conceptelor de management de calitate software se
obţin clase de calitate pentru aplicaţii informatice.
Aplicaţii informatice au urmǎtoarele caracteristici de calitate:
- funcţionalitatea corectă a componentelor aplicaţiei într-un mod securizat şi
interoperabil;
- fiabiliatatea care menţine nivelul performanţelor aplicaţiei în condiţii stabilite şi pe
o perioadă lungă de timp; atributele de bază ale acestei carecteristici sunt: toleranţa
la defecte şi recuperabilitatea datelor afectate de diverse erori ale aplicaţiei;
- uşurinţa în utilizare de către diverşi utilizatori;
- eficienţa aplicaţiei dată de comportamentul în timp şi de comportamentul
resurselor folosite;
- mentenabilitatea care se referă la efortul necesar pentru anumite modificări;
- portabilitatea prin care se permite aplicaţiei să fie rulată pe sisteme diferite;
- interoperabilitatea cu alte aplicaţii sau sisteme distribuite;
- complexitatea studiată în corelaţie cu alte caracteristici precum fiabilitatea,
stabilitatea sau mentenabilitatea;
- flexibilitatea în special în cazul aplicaţiilor web; această flexibilitate din punctul de
vedere al serverelor web pentru baze de date, este dată de capacitatea de a
încorpora datele din bazele de date accesate, în paginile web;
- securitatea oferă o cale sigură a informaţiei în reţea, folosind suport criptografic,
drepturi de citire/scriere, acces protejat prin parolă.
Pentru caracteristicile de calitate incluse în sistemul de caracteristici se definesc
indicatori care se bucurǎ de urmǎtoarele proprietǎţi:
- normare pe acelaşi interval;
- aceeaşi structurǎ de variabile;
- acelaşi nivel de complexitate;
2
 - acelaşi mod de culegere a datelor.
Realizarea calitǎţii se face prin testare.
În prezent, aplicaţiile informatice vizează din ce în ce mai mult caracteristicile de
mobilitate ale utilizatorilor datorate dezvoltării exponenţiale a tehnologiilor de comunicaţii.

2 Fiabilitate

Fiabilitatea mǎsoarǎ capacitatea aplicaţiei informatice de a funcţiona fǎrǎ erori pe un

interval de timp dat.
În conformitate cu [BARO82a], fiabilitatea este privită ca măsura încrederii pe care
existǎ în concepţia şi în capacitatea unui sistem de programe de a funcţiona corect în toate
condiţiile avute în vedere de la început. Definiţia este legată de probabilitatea ca o eroare din
cadrul programelor componente ale sistemului să fie activată de un set specific de date de
intrare.
Dacǎ o aplicaţie informaticǎ este activatǎ de un numǎr de n ori şi în k situaţii rezultatele
care se obţin sunt: incomplete sau incorecte sau are loc întreruperea execuţiei sau se acceptǎ
date de intrare incorecte, fiabilitatea efectivǎ F este datǎ de relaţia:
n−k
F=
n

Fiabilitatea estimatǎ se referǎ la un produs software în fazǎ de proiect sau într-un stadiu
de elaborare.
Abordarea teoreticǎ vizeazǎ o serie de modele folosite în estimarea fiabilitǎţii software.
Standardul ISO/IEC 9126 [****91], defineşte fiabilitatea ca un set de atribute bazat pe
capabilitatea produsului software de a-şi menţine nivelul de performanţă, în condiţii şi pe o
perioadă de timp stabilite. Analiza acestei caracteristici pune accentul pe toleranţa la defecte
şi corectitudine.
Tehnicile de obţinere a toleranţei la defecte se aplică în special la componentele
hardware şi la sistemele de operare. Principala problemă în programare este corectitudinea
sistemelor de programe, în sensul că acestea trebuie să îndeplinească specificaţiile funcţionale
stabilite.
Fiabilitatea aplicaţiilor informatice se apreciazǎ prin:
- disponibilitatea - implică conservarea unei capacităţi ridicate de prelucrare a unei
aplicaţii software, chiar dacă apare o anomalie în textul sursă al componentelor
acesteia;
- integritatea - impune ca rezultatele să fie exacte;
- reproductibilitatea prelucrării - urmăreşte obţinerea aceloraşi rezultate, cu ajutorul
unor seturi de date identice, la momente şi condiţii de execuţie diferite.
Factorii care influenţează în mod deosebit fiabilitatea aplicaţiilor software sunt:
- funcţionalitatea – definită în standardul ISO/IEC 9126, [****91], ca un set de
atribute bazate pe existenţa unui set de funcţii şi pe proprietăţile lor specificate;
3
 funcţiile satisfac necesităţile stabilite sau implicite; datorită acestui set de atribute
care definesc funcţionalitatea se demonstrează scopul căruia serveşte aplicaţia,
pentru a îndeplini cerinţele; în acest timp, alte seturi arată momentul şi modul în
care aplicaţia distribuitǎ corespunde nevoilor utilizatorilor; pentru a face referire la
nevoile stabilite sau implicite, se porneşte de la definiţia dată calităţii în standardul
ISO 8402 [****86], ca totalitatea trăsăturilor şi caracteristicilor unui produs sau
serviciu bazat pe abilitatea sa de a satisface nevoile stabilite sau implicite; atunci
când o aplicaţie informaticǎ distribuitǎ îşi îndeplineşte scopul nu mai este necesar să
se intervină asupra sa pentru îmbunătăţirea unor funcţiuni sau pentru introducerea de
noi funcţiuni; acest lucru reduce riscul apariţiei de erori, aspect care permite
menţinerea fiabilităţii aplicaţiei la un nivel ridicat;
- utilizabilitatea - este definită în [****91], ca un set de atribute bazate pe efortul
necesar pentru utilizarea produsului software şi pe evaluarea individuală a utilizării
acestuia, de către un grup stabilit sau implicit de utilizatori; în accepţiunea pe care o
oferă standardul, termenul utilizator are un înţeles larg şi include aici categorii
diverse de persoane ca: operatori, utilizatori finali şi indirecţi, precum şi toate
categoriile care îşi defăşoară activitatea dependent, sau sub influenţa utilizării
produsului software respectiv; aplicaţiile informatice sunt complexe şi oferă o gamă
largă de funcţiuni; unele dintre acestea sunt uşor de înţeles şi de folosit de personal
care nu necesită pregătire de specialitate; în cazul aplicaţiei informatice de
contabilitate realizarea funcţiunilor de salvare sau restaurare colecţii de date sau
obţinerea listei facturilor emise este la îndemâna unui operator; apar însă şi situaţii
în care utilizarea unei funcţiuni necesită cunoştiinţe aprofundate precum funcţia de
verificare corelaţii pentru întocmirea bilanţului contabil;
- eficienţa – este definită în [BARO83], ca o corelaţie optimă între consumul de
resurse implicat de utilizarea aplicaţiei informatice şi complexitatea problemei de
rezolvat; aici este introdusă şi noţiunea de ieşire a produsului software, definită ca o
relaţie între complexitatea datelor iniţiale şi a rezultatelor finale; în standardul
ISO/IEC 9126 [****91], definiţia se referă la un set de atribute bazat pe relaţia
dintre nivelul de performanţă al aplicaţiei informatice şi cantitatea de resurse
utilizate, în anumite condiţii stabilite; în comparaţie cu accepţiunea pe care o
întâlnim în [BARO82a], standardul ISO 8402 [****86], oferă un înţeles mai larg
termenului resurse consumate şi include aici memoria, timpul de execuţie, precizia,
serviciile de operare, mentenanţă sau suport de personal.;
- mentenabilitatea - este definită în [****91], ca un set de atribute bazate pe efortul
necesar de a face modificările specificate în produsul software respectiv; acestea
includ corecţii, îmbunătăţiri sau adaptări la modificări ale platformelor de dezvoltare
sau a celor cărora le sunt destinate, modificări în cerinţe şi specificaţii funcţionale;
în [BARO83], se afirmă că, un produs software este mentenabil în măsura în care
permite o rapidă şi uşoară actualizare astfel încât să se utilizeze în continuare, în
bune condiţii; sensul în care sunt privite aceste actualizări este mult mai restrâns,
deoarece ele se referă la operaţiile realizate la nivelul sistemului de programe, al
programelor şi modulelor componente, secvenţelor de instrucţiuni şi instrucţiunilor;
nivelul mentenabilităţii se stabileşte pe baza datelor obţinute în etapele de proiectare,
4
 testare şi utilizare curentă;
- robusteţea - este cunoscută şi sub numele de toleranţă la erori; fiabilitatea sistemelor
de programe este dependentă de toleranţa la defecte hardware; facilităţi cum sunt
detectarea erorilor de prelucrare şi faptul că atunci cînd apar solicitări eronate,
acestea nu sunt executate, iar sistemele continuă să rămână în execuţie, conduc la
creşterea robusteţei şi implicit a fiabilităţii acestora; pentru detectarea erorilor se
folosesc verificări dinamice ale informaţiei şi proceduri care să semnaleze
incompatibilităţi de date sau încercări de încălcare a restricţiilor de acces;
- portabilitatea - este definită în [BARO83], ca o caracteristică de ordin calitativ a
sistemelor de programe ce se executǎ pe mai multe tipuri de calculatoare; asigurarea
portabilităţii sistemelor de programe contribuie la menţinerea fiabilităţii la nivel
ridicat; varietatea mediilor de dezvoltare specifice fiecărui tip de calculatoare,
precum şi volumul modificărilor necesar adaptării face ca în cele mai multe cazuri
să se opteze pentru soluţia rescrierii acestor sisteme de programe; cazurile în care se
alege varianta modificării sistemelor existente sunt cele în care acestea trebuie
transferate într-un timp scurt; în această situaţie s-a constatat însă că nivelul
fiabilităţii este scăzut, iar costurile de exploatare sunt mari şi nu se justifică din
punct de vedere economic;
- siguranţa în utilizare - conform [BARO83], această caracteristică stabileşte măsura
în care un sistem de programe nu permite efectuarea de modificări neautorizate sau
nedorite în volumele de date, precum şi distrugerea parţială sau totală a volumelor
de date;
- stabilitatea – exprimă rezistenţa sistemului de programe faţă de efectele generate de
o modificare a datelor iniţiale, cât şi a secvenţelor de instrucţiuni care compun
programele şi modulele componente ale acestuia; în funcţie de nivelul la care se
efectuează modificarea se definesc stabilitatea la nivel de instrucţiune, la nivel de
secvenţă, la nivel de modul, la nivel de program şi respectiv, stabilitatea globală a
sistemului;
- adaptabilitatea - reprezintă, conform [****91], capacitatea sistemului de programe
de a permite integrarea de noi obiecte şi de a include acele secvenţe de instrucţiuni
care măresc performanţa sistemului şi îl aduc la nivelul eficienţei de utilizare de la
un moment dat, ulterior elaborării; adaptabilitatea influenţează fiabilitatea sistemului
de programe şi este influenţată de nivelul stabilităţii şi de complexitate;
- testabilitatea - oferă utilizatorilor posibilitatea de a evidenţia comportamentul
sistemului de programe în situaţii particulare; prin asigurarea testabilităţii se
urmăreşte descoperirea cât mai multor variante de probleme rezolvabile cu aceste
sisteme de programe; în practică s-a observat că un sistem de programe cu robusteţe
ridicată are un nivel de fiabilitate superior şi este în acelaşi timp un sistem de
programe testabil;
- complexitatea - este caracteristica de calitate pentru care s-au dezvoltat cele mai
multe sisteme de metrici şi se studiază în corelaţie cu alte caracteristici;
complexitatea determină şi creşterea cheltuielilor de exploatare a aplicaţiilor
informatice distribuite, precum şi eforturile de a dezvolta noi versiuni sau de a
rescrie aplicaţiile sau numai anumite componente;
5
 - flexibilitatea - determină volumul de restricţii impus utilizatorilor pentru a obţine
rezultate complete şi corecte prin folosirea aplicaţiilor informatice; flexibilitatea este
relaţionată cu numărul opţiunilor pe care aplicaţiile informatice le pun la dispoziţia
utilizatorilor.
Pentru aplicaţiile problema fiabilitǎţii se pune cu mai multǎ aquitate pentru cǎ:
- numǎrul de utilizatori creşte
- dezvoltatorii de aplicaţii nu interactioneazǎ direct cu utilizatorii pentru a depana in
timp real aplicaţia
- erorile au efecte directe prin plǎţi, prin livrǎri, prin opţiuni ce genereazǎ acţiuni,
tranzacţionǎri la bursǎ prin Internet sau prin mobile.
Proasta funcţionare sau nefuncţionarea a unuia din calculatoarele sistemului distribuit nu
trebuie să atragă după sine şi nefuncţionarea întregii aplicaţii informatice distribuite.
Elementele care definesc fiabilitatea unei aplicaţii sunt:
- serviciul aşteptat – serviciile aplicaţiei trebuie să corespundă aşteptărilor clienţilor
sau utilizatorilor;
- garantarea comportamentului – trebuie să existe o modalitate de garantare a
funcţionării operaţiilor critice ale aplicaţiei;
- gestiunea situaţiilor excepţionale – nu existǎ o garanţie absolută a funcţionării
tuturor serviciilor, existând potenţial de eşec în orice componentă sau nivel al
aplicaţiei, însă aplicaţia trebuie să fie capabilă să-şi reia funcţionarea fără coruperea
informaţiilor;
- securitate – o aplicaţie distribuită trebuie să fie securizată faţă de agenţii externi;
deoarece elementele care ţin de securitate afectează toate componentele aplicaţiei,
ele sunt incluse în infrastructura acesteia.
Pentru a mări fiabilitatea software prin prevenirea erorilor, trebuie analizate cerinţele şi
planurile de testare, pentru a se asigura testarea cerinţelor. De asemenea, trebuie acordată
atenţie şi activităţii de întreţinere a software pe timpul utilizării. Această activitate implică
asistenţă din partea programatorilor.
Procesul de prevenire a erorilor software necesită parcurgerea următoarelor etape:
- analiza cerinţelor, urmăreşte ca aplicaţia informaticǎ obţinutǎ să fie cea cerutǎ, iar
funcţionalitatea ei să fie compatibilă cu cerinţele;
- asigurarea unui mecanism facil de intervenţie asupra codului sursă, care să elimine
sau să minimizeze riscul introducerii de noi erori;
- aplicarea unui program de testare care să verifice funcţionalitatea şi să stabilească
compatibilitatea cu cerinţele.
Principalii factori care influenţează fiabilitatea aplicaţiilor informatice sunt: redundanţa,
timpul, spaţiul de intrare şi profilul operaţional.
Redundanţa – este folosită pentru a construi aplicaţii informatice fiabile; se disting două
tipuri: spaţială şi temporală;
- redundanţa spaţială - foloseşte mai multe componente decât strictul necesar pentru a
implementa un sistem de programe; cu cât redundanţa este mai mare, cu atât sunt
detectate sau tolerate mai multe erori;
- redundanţa temporală - constă în folosirea aceluiaşi set de instrucţiuni, pentru a
efectua acelaşi lucru în mod repetat, după care rezultatele sunt comparate între ele.
6
 Timpul - din punct de vedere al exprimării cantitative, fiabilitatea este descrisă adesea
prin intermediul unor intervale de timp. Există diferite tipuri ale unităţilor de timp;
- timpul calendar - reprezintă modul de exprimare uzuală a timpului. Este util ca
fiabilitatea să fie exprimată în concordanţă cu timpul calendar, deoarece oferă
managerilor şi celor ce dezvoltă software, şansa de a vedea data la care sistemul
atinge obiectivele referitoare la fiabilitate;
- timp de execuţie – utilizat de cele mai multe modele pentru evaluraea fiabilităţii;
motivul constă în faptul că aceste modele sunt superioare celor care utilizează
timpul calendar. Pentru a fi capabil să exprime fiabilitatea prin intermediul timpului
calendar, modelele convertesc timpul de execuţie în timp calendar într-o etapă
ulterioară.
Modelele utilizate pentru calculul fiabilităţii se bazează pe defectele care apar în mod
aleator. Deoarece un defect apare numai pe durata procesului de execuţie, este important ca
timpul calendar să fie utilizat în calculele referitoare la fiabilitate.
Spaţiul de intrare şi profilul operaţional - reprezintă mulţimea de seturi şi stări de
intrare, pe care aplicaţiile informatice trebuie să le trateze. Dacă ulterior se adaugă, pentru
fiecare stare particulară, probabilitatea de a fi aleasă, se obţine profilul operaţional. Urmează
să se decidă care este probabilitatea ce trebuie selectată pe durata testului, pentru fiecare stare
de intrare. Diferitele probabilităţi sunt determinate astfel încât profilul operaţional să reflecte
modul în care componentele sistemului de programe sunt executate în timpul unei operaţii
normale.
Modelele de fiabilitate software existente sunt grupate conform [FARR83], [NICO91],
[RAMA82], [****83], în funcţie de diferite sisteme de clasificare:
- bazate pe natura erorilor; multe modele consideră programul ca pe o cutie-neagră şi
realizează o predicţie asupra fiabilităţii sale, fără să ţină cont de structura
programului;
- bazate pe etapele din ciclul de viaţă al sistemelor de programe în care se aplică
modelele.
Modelele folosite în timpul etapei de testare/validare sau în etapa operaţională sunt
împărţite în modele pentru:
- timpi între erori;
- numărarea erorilor;
- însămânţarea erorilor;
- intrări pe domeniul de bază.
Modelele de predicţie sunt aplicate în fazele preliminare din ciclul de realizare a
sistemelor de programe. Ele folosesc date colectate în procesul de dezvoltare şi metrici de
produs în scopul obţinerii unui nivel preliminat pentru densitatea de defectare. Utilizarea
acestora permite determinarea nivelului fiabilitatăţii preliminate şi obţinerea de predicţii
referitoare la comportamentul sistemelor de programe în timpul etapelor de testare şi
exploatare.
Modelul bazat pe faze, prezentat în [FARR83], utilizează statisticile de eroare obţinute
în timpul etapelor de analiză a cerinţelor tehnice, proiectare şi implementare, pentru a estima
fiabilitatea pe durata testării şi utilizării efective [GAFF88]. Necesitǎ existenţa unui program
de înregistrare sistematicǎ a comportamentului stadiilor intermediare în cadrul etapelor
7
ciclului de dezvoltare software.
Acest model se exprimă prin:

2 2
∆Vt = E[e − B (t −1) − e − Bt ]

unde:
∆Vt - numărul de erori descoperite / KLOC (mii de linii de cod), de la momentul t-1
până la momentul t;
E - rata totală a intervalului de eroare, exprimată în erori / KLOC;
t - indexul asociat etapelor de detectare a erorilor;
B = ½τp2, iar τp este constanta aferentă etapei în care au fost descoperite erorile.
Volumul de resurse depinde de efortul de dezvoltare raportat direct la complexitatea
aplicaţiei, la experienţa echipei de dezvoltatori, toate influenţând numărul de erori produse şi
care sunt detectate în etapele procesului de dezvoltare. Cu cât identificarea erorilor este mai
depǎrtatǎ de momentul producerii, costurile de depanare sunt mai mari. Estimările sunt
realizate în dependenţǎ cu dimensiunea codului şi sunt utilizate diferenţiat în etapele
incipiente faţǎde etapele finale ale ciclului de dezvoltare.
Erorile descoperite în timpul analizei cerinţelor şi a proiectării software sunt
normalizate cu ajutorul estimărilor obţinute pentru dimensiunea codului.
Modelul RADC, dezvoltat în [ROLB92], conţine estimări care se bazeazǎ pe densitatea
erorilor, preluate în modele ale fiabilităţii. Rata erorilor, intervalul dintre douǎ întreruperi ale
execuţiei generate de aceeaşi tipologie de erori, probabilitatea ca produsul sǎ aibǎ o
întrerupere de execuţie într-un interval specificat şi multe alte nuanţǎri ale evenimentelor,
transferate din teoria înlocuirii optime a echipamentelor sunt adaptate în modelele de
fiabilitate software, care prin extensie de tip serial – fiabilitate date – fiabilitate software –
fiabilitate rezultate sunt transferate spre aplicaţiile distribuite. Factorii selectaţi în cadrul
modelului fac referire la densitatea erorilor în fazele primare ale ciclului de viaţă.
Pentru aplicaţiile informatice sunt selectaţi factori precum, tipul aplicaţiei, mediul de
dezvoltare şi sunt adaptate metrici ce vizeazǎ managementul proiectului, elementele de
structurǎ ale proiectului, limbajele de programare, dimensiunea aplicaţiei, structurabilitatea
acesteia, nivelul de reutilizare de componente obţinânduse un model iniţial pentru densitatea
erorilor δ0, de forma:
δ0 = AD x (AM x TM x QM) x (LT x SS x MD x ER x CX x SA x FU)
unde:
A – este tipul aplicaţiei reprezentat, în majoritatea cazurilor, prin aplicaţii de baze de
date;
D – este mediul de dezvoltare caracterizat prin dezvoltarea metodologiei respectiv a
instrumentelor disponibile;
AM – este metrica pentru anomalii în managementul proiectului;
TM – este metrica de trasabilitate;
QM – reprezintǎ metrica de calitate ce încorporeazǎ rezultatele analizei calităţii
software;
LT – reprezintǎ tipul de limbaj de comandă, de interogare, orientat pe obiecte, etc.;

8
 SS – reprezintǎ dimensiunea sistemului de programe;
MD – reprezintǎ modularitatea;
ER – reprezintǎ extinderea reutilizării;
CX – reprezintǎ complexitatea;
SA – reprezintǎ analiza standard pentru încorporarea în sistemele de programe a
rezultatelor analizei standardelor;
FU – este frecvenţa de utilizare a sistemului de programe.
Aceastǎ clasǎ de modele are la bazǎ estimǎri ce necesitǎ seturi de date privind
comportamentul de aplicaţii informatice numeroase şi omogene. Calitatea modelului este
strict dependentǎ de calitatea estimǎrilor.
Modelele de estimare sunt utilizate în etapele finale din ciclul de viaţă: testarea
integrării la nivel de componentă, testarea la nivel de sistem, testare funcţională şi exploatare.
Modelele de estimare incluse în categoria domeniul datelor utilizează datele de test
pentru sistemele de programe alese în concordanţă cu distribuţiile de probabilitate ale
utilizărilor operaţionale anticipate. Cele incluse în categoria domeniul timpului utilizează ca
element principal timpul, în următoarele variante: timpul de apariţie a erorilor, timpul de
execuţie între erori succesive, timpul de testare între erori succesive.
Modelele care utilizează timpul ca element principal sunt mai potrivite pentru
evaluarea fiabilităţii aplicaţiilor informatice distribuite, deoarece parametrul timp, în toate
formele lui de manifestare, este mai uşor de urmărit şi înregistrat de către utilizatori. În acest
sens, trebuie menţionat faptul că multe sisteme au funcţiuni speciale pentru contorizarea
timpului de execuţie şi înregistrarea codului erorii respectiv a momentului de timp şi a
modulului în care apare.
Modelul logaritmic Musa-Okumoto [MIOK90], foarte cunoscut în literatura
destinatǎ fiabilitǎţii software este aplicabil atunci când testarea se efectuează în concordanţă
cu un profil operaţional neuniform. Modelul ia în considerare:
t - timpul de execuţie consumat de la începutul testării;
λ0 - intensitatea iniţială de defectare;
λ(t) - intensitatea de defectare la momentul t;
θ - parametru de descreştere a intensităţii de defectare;
µ(t) - numărul aşteptat de defectări la momentul t.
pe baza cǎruia se obţin informaţii importante asupra intensitǎţii de apariţie a defectelor.
În cazul în care procesul de testare este eficient nivelul parametruluiλ(t) se reduce, iar
tendinţa de scǎdere se menţine dacǎ şi numai dacǎ prin eliminǎri de instrucţiuni, introduceri
de instrucţiuni sau modificǎri ale instrucţiunilor existente nu se introduc erori noi în program,
situaţie extrem de rar întâlnitǎ.
Modelul Littlewood-Verrall [LITT90], ia în calcul generarea de erori în procesul de
corectare şi admite că probabilitatea scade prin corectarea erorii.
Intenţia este de a face o aplicaţie informaticǎ distribuitǎ mai fiabilǎ atunci când o
eroare este detectată şi corectată, însă este puţin probabil că acest scop este realizat. Odată cu
fiecare eroare corectată o nouă componentă a sistemului este generată. Fiecare componentă
este obţinută din cea anterioară ca urmare a corectării erorii. Datorită incertitudinii implicate
în acest proces de corecţie, relaţia pe care un program o are cu predecesorul, este nesigură.
Aplicarea modelului Littlewood-Verrall pe aplicaţiile informatice nu ţine seama de
9
valoarea iniţială a intensităţii de defectare. Numărul defectelor descoperite la începutul
procesului de testare este mare şi descreşte pe măsură ce testarea avansează. Intensitatea de
defectare este influenţată de erorile care intervin în timpul procesului de testare. În cazul
aplicaţiilor informatice un factor de influenţă important este complexitatea. Numărul de
defecte este direct proporţional cu complexitatea sistemelor de programe. Aceasta determină o
creştere a dificultăţii sarcinilor de programare.
Aşa cum reiese din literatura de specialitate [FARR99], [KEIL89], [LUBL92],
[LYUM90], modelele de creştere a fiabilitǎţii consideră momentul apariţiei erorii ca intrare,
apoi calculează fiabilitatea curentă şi proiectează fiabilitatea viitoare. Prin utilizarea aceastei
metode, managerul de proiect determină care este volumul de teste ce trebuie efectuat înainte
atingerii obiectivelor fixate.
Pentru acest tip de modele, fiabilitatea noilor versiuni ale sistemelor de programe este
predictată în funcţie de cea a versiunilor anterioare.
Modelele de creştere realizează predicţii bazate pe numărul de erori observate pe
parcursul testului, iar parametri sunt estimaţi prin metoda verosimilităţii maxime sau a celor
mai mici pătrate. Ele produc rezultate diferite pentru aceleaşi date de intrare.
După alegerea modelului, factorii ce afectează fiabilitatea sunt modul de introducere
respectiv eliminare a defectelor şi mediul de lucru.
Introducerea de erori depinde de:
- experienţa persoanelor care activeazǎ în cadrul echipei de analişti, programatori;
- orientarea spre obţinerea de module de calitate la nivelul organizaţiei ;
- rigurozitatea cu care sunt utilizate procedurile de dezvoltare software;
- sistemul de metrici utilizat în planificarea, urmǎrirea şi creşterea calitǎţii aplicaţiei
distribuite;
- caracteristicile codului sursă dezvoltat;
- dimensiunea iniţială a codului;
- caracteristicile procesului de dezvoltare a sistemelor de programe;
- tehnicile ingineriei software utilizate;
- instrumentele folosite;
- pregătirea profesională şi nivelul de experienţă al personalului. SE DEZVOLTA
Eliminarea defectelor depinde de:
- performanţa echipei de testare;
- capacitatea de dezvoltare a seturilor de date de test;
- timpul alocat procesului de testare;
- nivelul planificat al erorilor maxim admise într-un interval dat şi pentru un numǎr
minim de activǎri specificate ale aplicaţiei
- profil operaţional;
- calitatea activităţii de depanare.
Mediul de lucru depinde de profilul operaţional.
Anumiţi factori sunt probabilistici şi prin urmare, multe modele sunt bazate pe procese
aleatoare. Diferitele modele existente utilizează probabilităţi de distribuţie a timpilor de
defectare sau a numărului de defecte experimentate şi iau în considerare variaţiile în timp ale
proceselor aleatoare. Toate modelele au un set de parametri care sunt stabiliţi pentru fiecare
proiect în parte.
10
 Se consideră că sistemul de programe are un nivel scăzut al fiabilităţii şi pentru fiecare
modificare succesivă se calculează creşterea fiabilităţii. Timpul necesar obţinerii nivelului
dorit de fiabilitate este mare.

3 Generalitate

Generalitatea este o caracteristicǎ de calitate pe care aplicaţiile monopost (desktop) le

percep numai atunci când produsul software nu include o anumitǎ situaţie.
Produsele software clasice se realizeazǎ de la simplu la complex, de la particular la
general.
Când se elaboreazǎ software pentru rezolvarea sistemelor liniare, se procedeazǎ astfel:
- se scrie program pentru aplicarea metodei exacte în cazul sistemelor liniare cu m
ecuaţii si m variabile, cu cel mult mult 50 de variabile, în condiţiile în care termenii
liberi este nenuli şi matricea asociatǎ este nesingularǎ;
- dupǎ testarea şi acceptarea acestui program se introduce componenta de verificare a
nesingularitǎţii matricii asociate, cu continuarea rezolvǎrii sistemului şi afişarea de
mesaje în cazul în care matricea este singularǎ, cu încheierea prelucrǎrii;
- se trece la rezolvarea de sisteme cu mai mult de 50 de ecuatii şi 50 de necunoscute
folosind o metodǎ de calcul aproximativ;
- dacǎ programul rezultat acoperǎ mai mult de 97% din situaţiile cu care se confruntǎ
organizaţia beneficiarǎ a produsului software, se trece la luarea în considerare a
situaţiei în care sistemul are un numǎr de ecuaţii mai mic decât numǎrul de
necunoscute; se testeazǎ şi se modificǎ pânǎ când este acceptat ca fiind corect
produsul obţinut;
- se îmbogǎţeşte produsul luând în considerare şi situaţia în care termenii liberi sunt
nuli, rezolvând în acest fel sisteme omogene; numai dupǎ testarea şi efectuarea
corecţiilor acestei noi posibilitǎţi se considerǎ produsul acceptat;
- se îmbogǎţeşte produsul cu proceduri de rezolvare a sistemelor în care numǎrul de
ecuaţii este mai mare decât numǎrul de necunoscute; numai dupǎ testarea şi
efectuarea corecţiilor acestei noi posibilitǎţi se considerǎ produsul acceptat;
- se trece la rezolvarea sistemelor liniare de mari dimensiuni folosind matrice rare,
incluzând toate variantele de structuri de sisteme liniare; numai dupǎ testarea şi
efectuarea corecţiilor acestei noi posibilitǎţi se considerǎ produsul acceptat;
- se dezvoltǎ un limbaj de iniţializare a matricilor şi a termenului liber;
- se dezvoltǎ un sistem de gestiune a fişierelor care memoreazǎ matricile şi termenii
liberi;
- se dezvoltǎ un sistem de autentificare a autilizatorilor.
Produsul software astfel obţinut are gradul de generalitate cel mai ridicat.
Se defineşte problema PROB în forma ei cea mai generalǎ, incluzând subproblemele
SPROB1, SPROB2, ... SPROBNPRB

11
 La implementare în diferite faze se scriu componente ce corespund anumitor
subprobleme.
Generalitatea se mǎsoarǎ cu indicatorul IGR dat de relaţia:

NPI
IGR =
NPRB

unde:
NPI – numǎrul de subprobleme implementat
NPRB – numǎrul de subprobleme maxim definit
Dacǎ pentru fiecare subproblemǎ SPRBi este estimat un coeficient de complexitate
C(SPROBi) asociat modulelor software care o implementeazǎ rezultǎ cǎ pentru problema
PROB în forma ei cea mai generalǎ complexitatea este datǎ de relaţia:

NPRB
C ( PROB) = ∑ C (SPROB )
i =1
i

Generalitatea unui program este datǎ de raportul dintre complexitǎţile subproblemelor

implementate şi complexitatea întregii probleme, indicator definit prin relaţia:

NPRB

∑α C (SPROB )
i =1
i i
IGR =
C ( PROB)

1, daca SPROBi este implementat

αi = 
 0, in rest

Se considerǎ aplicaţia din figura 1 în care existǎ definite patru subprobleme SPROB1,
SPROB2, SPROB3 şi SPROB4 cu gradele de complexitate 10, 20, 15 şi respectiv 30

SPROB1
C(SPROB1) = 10

SPROB2 SPROB3 SPROB4

C(SPROB2) = 20 C(SPROB3) = 15 C(SPROB4) = 30

Figura 1. Structurǎ arborescentǎ de subprobleme

Dacǎ se presupune cǎ existǎ implementate numai subproblemele SPROB1 şi SPROB3

atunci indicatorul de generalitate este:

12
 IGR = (10 + 15) / (10 + 20 + 15 + 30) = 25 / 75 = 0,33

Rezultatul indicǎ un nivel redus de generalitate ce corespunde soluţiei, trebuind sǎ se

treacǎ la ameliorarea sa.

4 Corectitudine

Pentru fiecare aplicaţie distribuitǎ se elaboreazǎ specificaţii ce includ:

- descrierea datelor de intrare (domeniul, tipul, mod de culegere, volum, ce tipuri de
greseli apar, cum sunt grupate în articol, ce lungime are câmpul, cum se stocheazǎ)
- descrierea rezultatelor
- descrierea formulelor de calcul
- prezentarea de comenzi
- prezentarea restricţiilor privind sortarea datelor
- definirea cheilor
- prezentarea seturilor de date de test
Corectitudinea unei aplicaţii se evidenţiazǎ prin testare.
Înseamnǎ cǎ pentru seturile de date de test SDT1, SDT2, ... SDTNT trebuie sǎ se obţinǎ
rezultatele RT1, RT2, ... RTNT. În realitate, în procesul de testare se identificǎ situaţii în care
rezultatele oferite de program pentru setul de date SDTi este RPi care diferǎ de rezultatul RTi
dat în specificaţii.
Corectitudinea unui program este un concept care are un fundament matematic riguros
[MANN69], [MANN74], [BUDD82], [CORR78], [DIJK68].
Latura practicǎ a aplicaţiilor deosebit de complexe legatǎ de corectitudine are la bazǎ
urmǎtoarele ipoteze:
- existenţa a NT seturi de date de test
- existenţa NT rezultate considerate corecte şi incluse în specificaţii
- asocierea unei structuri arborescente aplicaţiei informatice distribuite
- punerea în corespondenţǎ a celor NT rezultate RTi cu modulele terminale din
structura arborescentǎ; în cazul în care numǎrul modulelor terminale este egal cu NT,
NMT = NT procesul de testare este considerat complet; în cazul în care NMT > NT
rezultǎ cǎ testarea este incompletǎ, NMT – NT este numǎrul de module finale care nu
intrǎ în teste şi odatǎ cu ele nu intrǎ în teste fluxurile parţiale sau totale de la modulul
apelator pânǎ la ele; în cazul în care NMT < NT existǎ module finale supuse
testǎrilor repetate, caz explicabil atunci când aceste module prezintǎ o importanţǎ
specialǎ în economia aplicaţiei.
Corectitudinea aplicaţiei informatice este o caracteristicǎ de calitate a cǎrei prezenţǎ se
evidenţiazǎ în procesul de testare, definit riguros prin:
- numǎrul de testǎri
- durata de timp limitatǎ a procesului de testare

13
 - rapoarte detaliate privind rezultatul testǎrii pentru reluarea etapelor din ciclul de
dezvoltare în vederea efectuǎrii de corecţii.
Spre deosebire de demonstrarea corectitudinii folosind aparatul matematic prezentat în
[DIJK68], [HOAR69], [MANN69], pentru orice seturi de date de intrare în aplicaţia
informaticǎ, rezultatul fiind ori cǎ aplicaţia este corectǎ şi trebuie lansatǎ în execuţie curentǎ,
ori cǎ aplicaţia este incorectǎ şi trebuie reluate etape ale ciclului de dezvoltare, testarea
evidenţiazǎ modul în care funcţioneazǎ aplicaţia pentru un numǎr dat de seturi de date de test.
Nu se trag concluzii pentru extinderea spre orice seturi de date de test, ceea ce înseamnǎ cǎ nu
se pune semn de egalitate între testarea şi demonstrarea corectitudinii unei aplicaţii
informatice distribuite.
Pentru echipa care dezvoltǎ software, un rezultat categoric legat de corectitudinea sau
incorectitudinea aplicaţiei informatice este irelevant în raport cu cheltuielile post-testare. De
aceea, este necesar sǎ se defineascǎ un indicator al corectitudinii ICP definit pe intervalul [0,
1].
Dacǎ ICP = 0 rezultǎ cǎ toate seturile de date de test au condus la rezultate RPi diferite
de rezultatele din specificaţii RTi pe toatǎ gama de tipuri de erori.
Dacǎ ICP = 1 rezultǎ cǎ toate seturile de date de test au condus numai la rezultate
identice cu RTi, fǎrǎ a înregistra erori.
Înseamnǎ cǎ pentru ICP aparţine intervalului (0, 1) trebuie stabilit un mod de agregare
prin care sǎ se ia în considerare erorile.
Într-un modul, apar erori pe niveluri de agregare ERR11, ERR12, ... ERRij, ... ERRNE NT.
Pentru fiecare tip de eroare se stabileşte un coeficient de importanţǎ PC1, PC2, ... PCNE.
Se defineşte indicatorul de corectitudine ICP prin relaţia:

 NT NE

0, daca ∑∑ ERRhj = 0

 j =1 h =1


 NT NE
ICP =  ∑∑
 j =1 h =1
PC h ⋅ ERRhj
 NT NE , in caz contrar

 ∑∑
j =1 h =1
ERRhj


Dacǎ se considerǎ aplicaţia distribuitǎ APDi, coeficienţii de importanţǎ PC1 = 0,7; PC2 =
0,3 corespunzǎtori a douǎ tipuri de erori precum şi frecvenţele de apariţie a erorilor ERRij
pentru patru seturi de date de test, prezentate în tabelul 1 rezultǎ prin aplicarea formulei de
calcul a indicatorului ICP valoarea 0,55.
Tabelul 1. Date rezultate în procesul de testare pentru aplicaţia APDi
Set date de test Numǎr erori de tip 1 Numǎr erori de tip 2
SDT1 5 3
SDT2 2 4
SDT3 7 1
SDT4 9 5
TOTAL 23 13
14
 Indicatorul de corectitudine devine ICP=(23*0,7 + 13*0,3) / (23 + 13) = 20 / 36=0,55
Rezultatul indicǎ un nivel scǎzut de corectitudine ce corespunde soluţiei, trebuind sǎ se
treacǎ la ameliorarea sa.

5 Eficacitate

Eficacitatea mǎsoarǎ avantajele pe care le genereazǎ aplicaţia distribuitǎ. Existǎ

eficacitate la nivelul utilizatorilor aplicaţiei, existǎ eficacitate la nivelul administratorilor
aplicaţiei, precum şi eficacitate la nivelul dezvoltatorilor de aplicaţii informatice distribuite.
Dacǎ se considerǎ utilizatorii U1, U2, ... UNU şi costurile COST1, COST2, ... COSTNU
pentru soluţionarea problemelor de cǎtre utilizatori în condiţiile inexistenţei aplicaţiei
informatice precum şi costurile CAPI1, CAPI2, ... CAPINU, costurile soluţionǎrii problemelor
în condiţiile existenţei aplicaţie informatice se calculeazǎ indicatorul de efect la utilizator a
introducerii aplicaţiei informatice EUAI, dat de

NU

∑ CAPI
j =1
j

EUAI = NU

∑ COST
j =1
j

Dacǎ EUAI < 1 rezultǎ cǎ la nivelul utilizatorilor aplicaţia informaticǎ îşi dovedeşte
eficacitatea datoritǎ economiilor pe care le genereazǎ.
Dacǎ EUAI > 1 atunci cheltuielile utilizatorilor sunt mai mari dupǎ implementarea
aplicaţiei informatice şi cum tot timpul se acceptǎ şi forma veche de soluţionare a problemelor,
marea majoritate a utilizatorilor preferǎ aceastǎ formǎ, evitând accesarea resurselor aplicaţiei
informatice distribuite.
Dacǎ se considerǎ modulele ce alcǎtuiesc aplicaţia distribuitǎ ca fiind MOD1, MOD2, ...,
MODNM, costurile de realizare a modulelor în conformitate cu cerinţele din specificaţiile
aplicaţiei, folosind tehnologii noi, sunt CMOD1, CMOD2, ..., CMODNM.
Dacǎ dezvoltatorii construiesc modulele cu resursele pe care le au, adicǎ folosind
tehnologii cunoscute şi experimentate în proiectele anterioare, costurile sunt CRM1, CRM2, ...,
CRMNM.
Dacǎ se realizeazǎ modulele utilizând tehnologi cunoscute şi experimentate atunci costul
de dezvoltare a produsului este mai mic dar performanţa este mai scǎzutǎ. Utilizând
tehnologie nouǎ, neştiutǎ şi neexperimentatǎ, pentru dezvoltarea modulelor aplicaţiei, creşte
costul de realizare a aplicaţiei datoritǎ timpului pierdut cu învǎţarea şi însuşirea noilor
tehnologii dar creşte performanţa produsului.
Se calculeazǎ indicatorul de eficacitate la dezvoltator EDAI dupǎ formula:

15
 NM

∑ CMOD + cheltuieli de instruire - performanta

i =1
i
EDAI = NM

∑ CRM
i =1
i + efectul negativ al neperformantei

Pentru realizarea modulelor MOD1, MOD2, MOD3 şi MOD4 ce alcǎtuiesc o aplicaţie

informaticǎ distribuitǎ în tehnologie veche şi tehnologie nouǎ existǎ tabelul 2.
Tabel 2. Exemplul pentru calculul eficacitǎţii la dezvoltator

Tehnologie Tehnologie
veche nouǎ
MOD1 10 20
MOD2 15 20
Costuri
MOD3 30 50
MOD4 40 60
Cheltuieli cu învǎţarea 0 70
tehnologiei
Performanţǎ 70 90

rezultǎ eficacitatea la nivel de dezvoltator:

EDAI =
(20 + 20 + 50 + 60) + 70 − 90 = 130 = 0,78
(10 + 15 + 30 + 40) + 70 165

Dacǎ se considerǎ urmǎtoarele variante de module folosite de administrator:

V1 – variantǎ costisitoare pentru dezvoltator dar uşoarǎ pentru administrator
V2 – variantǎ uşoarǎ pentru dezvoltator dar foarte dificilǎ pentru administrator
şi costurile aferente acestor variante de module ca fiind:
CV1 = CDC1 + CAL1*NRL
unde:
CDC1 – reprezintǎ cheltuieli de dezvoltare a componentei de administrare foarte mari
CAL1 – reprezintǎ cheltuieli de administrare a componentei foarte mici pe lunǎ
NRL – numǎrul de luni de administrare;
CV2 = CDC2 + CAL2*NRL
unde:
CDC2 – reprezintǎ cheltuieli de dezvoltare a componentei de administrare foarte mici
CAL2 – reprezintǎ cheltuieli de administrare a componentei foarte mari pe lunǎ
atunci eficacitatea la administrator, EAAI se calculeazǎ ca fiind:

CV 1
EAAI =
CV 2

16
 Dacǎ se considerǎ pentru varianta V1 cheltuielile de dezvoltare a componentei
administrator ca fiind CDC1 = 100 şi cheltuielile de administrare a componentei dezvoltate ca
fiind CAL1 = 20; iar pentru varianta V2 cheltuielile de dezvoltare a componentei CDC2 = 50 şi
cheltuielile de administrare a componentei CAL2 = 70; pentru 36 de luni, rezultǎ eficacitatea
administrator

100 + 20 ⋅ 36 820
EAAI = = = 0,32
50 + 70 ⋅ 36 2570

Se considerǎ coeficienţii de importanţǎ PU, PD, PA pentru utilizator, dezvoltator,

respectiv administrator PU + PD + PA = 1 şi PU, PD, PA ∊ (0, 1).
Indicatorul agregat EUAD este dat de formula:

EUAD = PU * EUAI + PD * EDAI + PA * EAAI

unde:
EUAI – eficacitatea la utilizator
EDAI – eficacitatea la dezvoltator
EAAI – eficacitatea la administrator
Dacǎ coeficienţii de importanţǎ pentru utilizator, dezvoltator şi administrator sunt
PU=0,60; PD = 0,25 şi PA = 0,15 atunci rezultǎ un nivel slab al indicatorului agregat
EUAD=0,64 pentru aceastǎ soluţie.

17
 6 Continuitate

Existǎ în uz curent o serie de aplicaţii informatice caracterizate prin:

- structuri de interfeţe comune;
- cuvinte cheie comune;
- structuri de rezultate comune;
- moduri de autentificare identice;
- niveluri de validare asemǎnǎtoare;
- modalitǎţi de introducere a datelor fǎrǎ generare de erori;
- reducerea şirurilor de caractere cu introducere repetatǎ prin memorare, comparare,
crearea şi afişarea unei liste de şiruri posibile în vederea selecţiei.
La realizarea unei noi aplicaţii informatice interesul dezvoltatorilor este de a elimina
efortul de adaptare a utilizatorilor în procesul de interacţiune om – calculator.
De aceea, când se proiecteazǎ o nouǎ aplicaţie informaticǎ:
- se includ în noua aplicaţie, exact soluţiile la problemele existente deja în alte
aplicaţii
- se preiau fǎrǎ modificǎri de poziţie, de text, de prezentare, de design interfeţe cu
care utilizatorii sunt obişnuiţi
- se construiesc liste de valori pentru a facilita introducerea de date corecte prin
selecţie
- se cautǎ omogenitatea în a introduce date; toate datele se introduc prin selecţie de
valori din liste; toate datele se introduc prin selecţie de variabile radio
- ordinea de introducere, poziţia valorilor care trebuie introduse ţin seama de
specificul grupului ţintǎ care alcǎtuieşte mulţimea utilizatorilor.
Continuitatea este o caracteristicǎ de calitate deosebit de importantǎ în definirea
strategiilor de dezvoltare a aplicaţiilor informatice distribuite.
Dacǎ proprietarul aplicaţiei informatice doreşte maximizarea numǎrului de utilizatori
trebuie sǎ aibǎ în vedere:
- efectele pozitive, pe care le genereazǎ utilizarea aplicaţiei la nivelul persoanelor, sǎ
fie vizibile;
- efortul de adaptare a persoanelor la exigenţele aplicaţiilor sǎ fie minime.
Continuitatea este caracteristica cu care se gestioneazǎ efortul de adaptare.
Cu cât o aplicaţie informaticǎ conţine mai multe inovaţii, foloseşte un vocabular mai
nou, are interfeţe cu structuri diferite de cele existente, utilizatorii trebuie sǎ încerce în mod
repetat sǎ parcurgǎ etape ale procesului de selecţie de opţiuni, cu succes sau fǎrǎ succes în
vederea soluţionǎrii problemelor lor.
Dacǎ se considerǎ aplicaţiile informatice AI1, AI2, având vocabularele V1 şi V2, nivelul de
continuitate ICO, în raport cu vocabularele utilizate este dat de relaţia

LG (V1 ∩ V2 )
ICO =
LG (V1 ∪ V2 )

18
unde LG ( ) este lungimea ca numǎr de cuvinte
Dacǎ:
V1 = {FILE, EDIT, INSERT, FORMAT, TOOLS, TABLE, WINDOWS, HELP}
V2 = {FILE, EDIT, INSERT, MODIFY, INPUT, PRINT}
V1 ∩ V2 = {FILE, EDIT, INSERT}
V1 ∪ V2 = {FILE, EDIT, INSERT, FORMAT, TOOLS, TABLE, WINDOWS, HELP,
MODIFY, INPUT, PRINT}
LG (V1 ∩V2 ) = 3
LG (V1 ∪V2 ) = 11
3
ICO = = 0,27
11

În cazul în care interfeţele sunt analizate în raport cu câmpurile, poziţiile câmpurilor,

continuitatea se defineşte ţinând seama de concordanţa de poziţie a câmpurilor şi de modul în
care sunt pǎstrate câmpurile.
Dacǎ interfeţele au toate câmpurile comune dar se schimbǎ poziţia câmpurilor de la
interfaţa I1 la interfaţa I2 atunci indicatorul de concordanţǎ ICNC, ce priveşte poziţiile ocupate
de câmpuri în cele douǎ interfeţe se calculeazǎ dupǎ formula:

∑ poz
i =1
1i − poz 2i
ICNC =
N2
unde:
poz1i - reprezintă poziţia câmpului i în interfaţa 1
poz2i - reprezintă poziţia câmpului i în interfaţa 2
N - este numărul de câmpuri din interfeţe

Dacǎ se considerǎ capturile de ecran din figurile 1 si 2

1 câmpul 1 1 câmpul 6
2 câmpul 2 2 câmpul 5
3 câmpul 3 3 câmpul 2
4 câmpul 4 4 câmpul 3
5 câmpul 5 5 câmpul 7
6 câmpul 6 6 câmpul 1
7 câmpul 7 7 câmpul 4

Figura 1 Poziţia Figura 2 Poziţia câmpurilor

câmpurilor în interfaţa I1 în interfaţa I2

Câmpurile din interfaţa I1 îşi modificǎ poziţia în interfaţa I2 cu urmǎtoarele poziţii:

câmpul 1 = | 1 – 6 | = 5
câmpul 2 = | 2 – 3 | = 1
19
 câmpul 3 = | 3 – 4 | = 1
câmpul 4 = | 4 – 7 | = 3
câmpul 5 = | 5 – 2 | = 3
câmpul 6 = | 6 – 1 | = 5
câmpul 7 = | 7 – 5 | = 2

Indicatorul de concordanţǎ ICNC, ce priveşte poziţiile ocupate de câmpuri în cele douǎ

interfeţe, este:

ICNC = (5 + 1 + 1 + 3 + 3 + 5 + 2)/ (7 * 7 ) = 0,41

Dacǎ interfeţele au numai anumite câmpuri comune şi se schimbǎ poziţia câmpurilor

comune de la interfaţa I1 la interfaţa I2 atunci indicatorul de concordanţǎ ICNC, ce priveşte
poziţiile ocupate de câmpurile comune în cele douǎ interfeţe se calculeazǎ dupǎ formula:

∑ poz
h =1
1h − poz 2 h
ICNC =
max{NC1 , NC 2 }
unde:
poz1k - reprezintă poziţia câmpului k în interfaţa 1
poz2k - reprezintă poziţia câmpului k în interfaţa 2
k - este numărul comun de câmpuri din cele două interfeţe
NC1 - reprezintă numărul de câmpuri din interfaţa 1
NC2 - reprezintă numărul de câmpuri din interfaţa 2
Se considerǎ capturile de ecran din figurile 3 si 4

1 câmpul 1 1 câmpul 4
2 câmpul 2 2 câmpul 8
3 câmpul 3 3 câmpul 3
4 câmpul 4 4 câmpul 11
5 câmpul 5 5 câmpul 9
6 câmpul 6 6 câmpul 1
7 câmpul 7 7 câmpul 10
8 câmpul 2

Figura 3 Poziţia Figura 4 Poziţia câmpurilor

câmpurilor în interfaţa I1 în interfaţa I2

Câmpurile comune din cele douǎ interfeţe sunt: câmpul 1, câmpul 2, câmpul 3 şi câmpul
4. Aceste câmpuri îşi modificǎ poziţia din interfaţa I1 în I2 astfel:

câmpul 1 = | 1 – 6 | = 5
câmpul 2 = | 2 – 8 | = 6

20
 câmpul 3 = | 3 – 3 | = 0
câmpul 4 = | 4 – 1 | = 3

Indicatorul de concordanţǎ ICNC, ce priveşte poziţiile ocupate de câmpurile comune în

cele douǎ interfeţe devine în acest caz:

ICNC = (5 + 6 + 0 + 3)/ (4 * max{7; 8} ) = 16 / 32 = 0,5

Nivelul redus al indicatorului de concordanţǎ determinǎ alocarea de resurse pentru

efectuarea de modificǎri în structura modulelor pentru a-l creşte semnificativ.

7 Modelul global al calitǎţii aplicaţiei distribuite

Caracteristicile de calitate CR1, CR2, ...., CRT oferǎ o imagine completǎ în legǎturǎ cu
fiecare caracteristicǎ în parte.
Dacǎ pentru carcateristica CRi se construeşte un indicator de mǎsurare Hi aparţinǎnd
intervalului [0, 1] şi dacǎ se stabileşte cǎ pentru Hi = 0 produsul software nu este înzestrat cu
caracteristica CRi iar pentru Hi = 1 produsul software are nivelul cel mai înalt pentru
caracteristica CRi, atât realizatorul produsului software cât mai ales utilizatorii produsului
sunt interesaţi sǎ aibǎ o imagine globalǎ asupra comportamentului respectivului produs
software din toate punctele de vedere.
De aceea, se cautǎ o modalitate de agregare a tuturor informaţiilor privind cele T
caracteristici de calitate.
Existǎ numeroase modalitǎţi de a construi un model agregat.
Pentru fiecare modalitate se defineşte un sistem de ipoteze.
Singura idee ce trebuie luatǎ în considerare este strict legatǎ de:
- acceptarea sistemului de ipoteze
- acceptarea limitelor pe care sistemul de ipoteze le genereazǎ
- validarea punerii în corespondenţǎ a nivelurilor cantitative obţinute cu indicatorul
agregat cu niveluri calitative obţinute în practicǎ.
De remarcat este faptul cǎ oricare ar fi indicatorul agregat folosit, este demonstrat cǎ nu
este un indicator perfect [PǍUN83], [PELE07].
Nivelul mediu de calitate [IVAN06] corespunde situaţiei în care indicatorii asociaţi
caracteristicilor de calitate sunt normaţi şi de naturǎ adimensionalǎ. Dacǎ pentru
caracteristicile CR1, CR2, ...., CRT existǎ mǎsurate nivelurile cu indicatorii normaţi H1, H2, ...,
HT aparţinând intervalului [0; 1], nivelul mediu al calitǎţii, HM este dat de relaţia:

∑H
j =1
j

HM =
T

21
 Dacǎ se considerǎ caracteristicile de calitate şi nivelurile mǎsurate, ordonate
descrescǎtor, ale indicatorilor asociaţi unor date din tabelul 3 pentru un program PROG;
nivelul mediu al calitǎţii este

HM = (0,9 + 0,85 + 0,8 + 0,8 + 0,75 + 0,7)/6 = 0,8

Tabelul 3. Nivelul de calitate al programului PROG

Nr. CR H
crt. Caracteristica de calitate Nivelul indicatorului
1 Mentenabilitate 0,9
2 Funcţionalitate 0,85
3 Fiabilitate 0,8
4 Portabilitate 0,8
5 Utilizabilitate 0,75
6 Eficienţǎ 0,7

Modelul liniar ponderat pentru aprecierea globalǎ a calitǎţii HG este dat de relaţia
[IVAN06]:
T
HG = ∑p H
j =1
j j

unde pj - reprezintǎ coeficienţii de importanţǎ asociaţi caracteristicilor de calitate, de cǎtre

echipe de specialişti din domeniul dezvoltǎrii de software sau din domeniul utilizǎrii
software. Aceşti coeficienţi îndeplinesc condiţia:

∑p
j =1
j =1

Dacǎ un coeficient de importanţǎ pj este dat prin relaţia:

NS

∑a
i =1
ij
pj = T NS

∑∑ a
k =1 i =1
ik

unde:
NS – numǎrul de specialişti
aij – rata datǎ de specialistul Si pentru caracteristica de calitate CRj

rezultǎ, prin înlocuiri, cǎ modelul global al calitǎţii bazat pe ponderi este:

22
 T
 NS 
∑∑  aij  H j

j =1  i =1


HG = T NS

∑∑ a
j =1 i =1
ij

Experimental, dacǎ HG aparţine [0; 0,78) aplicaţia se respinge cǎ nu corespunde

calitativ, dacǎ HG aparţine lui [0,78; 0,92) aplicaţia este consideratǎ ca fiind bunǎ dfin punct
de vedere calitativ; dacǎ HG aparţine [0,92; 1] aplicaţia este foarte bunǎ din punct de vedere
calitativ.
Modelul global se utilizeazǎ direct, folosind coeficienţii de importanţǎ obţinuţi din
prelucrarea datelor oferite de specialişti şi nivelurile estimate sau mǎsurate ale caracteristicilor
de calitate.
Folosind niveluri planificate ale caracteristicilor de calitate Hpj se obţin niveluri
planificate ale calitǎţii agregate HG p.
Folosind niveluri estimate ale caracteristicilor de calitate Hej se obţin niveluri estimate
ale calitǎţii globale agregate HG e.
Folosind niveluri efective, mǎsurate pe durata execuţiei la utilizatori a nivelurilor
caracteristicilor de calitate Huj se obţin niveluri efective ale indicatorului global HG u.
Dacǎ x ∈ {e, p, u}
T
HG x = ∑p H
j =1
j
x
j

unde:
e – nivelul estimat
p – nivelul planificat
u – nivelul obţinut la utilizarea curentǎ
Indicatorul global de calitate îşi dovedeşte utilitatea dacǎ:
- se considerǎ aplicaţii aparţinând aceleiaşi clase
- nivelurile caracteristicilor de calitate sunt mǎsurate folosind aceiaşi indicatori
- este necesar sǎ se ierarhizeze un produs în raport cu alte produse pentru care este
calculat nivelul agregat
- rezultatul ierarhizǎrii este coroborat cu alte elemente ce completeazǎ raportul
produsului informatic nou faţǎ de produse informatice existente, în vederea obţinerii
unei imagini cât mai complete asupra întregului context astfel definit.
Dacǎ sistemul de ipoteze şi expresia analiticǎ sunt altele se obţine un alt model de
agregare şi un alt nivel pentru calitatea agregatǎ a produsului software.
Sunt situaţii în care indiferent de modelul de agregare construit poziţia unui produs
software într-o mulţime de produse aparţinând aceleiaşi clase este aceaşi, însǎ de cele mai
multe ori modelele globale conduc la rezultate diferite. Este important ca utilizatorul unui
astfel de model prin perseverenţa de care dǎ dovadǎ sǎ creeze un sistem de referinţǎ unitar şi
sǎ evalueze riscurile pe care le genereazǎ limitele procesului de agregare.

23