1

1. Abordri moderne ale problemei calitii

Actuala perioad pe care o parcurge societatea romneasc este caracterizat, n principal, prin
adoptarea i statuarea unor noi modele organizaionale n domeniile social, politic i economic.
Un loc important n cadrul acestor mutaii l ocup ncercrile prin care diveri factori cu pondere
economic i social - o parte a corpului managerial, nvmntul i chiar o parte a clasei politice n formare
-ncearc s-i nsueasc, s adapteze i s se adapteze, s cunoasc i s impun o nou cultur a calitii.
Acest lucru se nscrie n tendina general a societii romneti de a se alinia, cel puin n form, valorilor ce
caracterizeaz societatea occidental, societate ce, n urm cu peste patru decenii, sesiza importana
economic a calitii i dezvolta primele tehnici, teorii i modele ce aveau s pun bazele unui nou tip de
cultur - cultura calitii.
n domeniul economic, creterea importanei calitii a fost determinat de diversificarea i
nnoirea/rennoirea rapid a ofertei de bunuri i servicii, mondializarea pieelor - facilitat de progresele din
telecomunicaii i din domeniul reelelor de calculatoare - creterea exigenelor clienilor i ale societii,
creterea complexitii produselor i serviciilor. Acest lucru a fcut ca, pe lng anumii parametrii "clasici"
ai caracteristicilor de calitate ale diferitelor produse, s apar i alii noi, cum ar fi caracterul nepoluant sau
nepericulozitatea, astfel c, n prezent, calitatea a devenit un factor determinant al complexitii unei entiti.
nc de la sfritul anilor '80, organizaia internaional pentru standarde, I.S.O., cu sediul la Geneva Elveia, ncepe s publice primele standarde referitoare la calitate. Standardul ISO-8402 - "Managementul i
asigurarea calitii - Vocabular" [ISO3], definete calitatea ca
ansamblul caracteristicilor unei entiti, care i confer aptitudinea de
a satisface nevoile exprimate sau implicite. Calitatea n sine se
Calitatea
Calitatea
exprim printr-un sistem de caracteristici, nu este de sine-stttoare,
ci se definete n relaia cu anumite persoane (figura 1.2) - clieni,
productori, furnizori, comerciani, etc. - este o variabil continu i
nu una discret - dei metricile prin care se exprim unele
Client
caracteristici de calitate, au un caracter discret - i presupune
satisfacerea nu numai a nevoilor exprimate, dar i a celor implicite.
Mergnd un pas mai departe fa de standardul ISO-8402,
Productor
specialitii japonezi n calitate, au elaborat metoda "Quality Function
Deployment" [ZUL1], conform creia, printre altele, nevoile
exprimate n cerine ale beneficiarilor, pot fi:
Furnizor
- normale sau explicite, ce apar n specificaii i reies din
discuiile cu clientul, fiind satisfcute n raport direct cu prezena lor
Comerciani
n entitatea respectiv;
- implicite, considerate elementare, i de aceea de cele mai
multe
ori nici nu se mai menioneaz, prezena lor n entitatea livrat
Alii
nu d un spor de satisfacie, n schimb absena lor poate fi total
Figura 1.2. Categoriile de persoane,
nesatisfctoare;
care influeneaz definirea
- deosebite, cele mai dificil de ndeplinit, fiind peste ateptrile
caracteristicilor calitii
clienilor. Absena lor nu produce insatisfacii, deoarece sunt
neateptate, dar prezena produce o satisfacie deosebit, aducnd totodat productorului importante
avantaje pe pia.
Universalitatea calitii este reliefat i prin definirea noiunii de entitate, ce apare n definiia calitii
din standardul ISO 8402. Astfel, o entitate poate fi o activitate, un produs sau un proces, o persoan sau un
grup de persoane, o organizaie, un sistem sau o combinaie ntre toate acestea.
Noua cultur a calitii a determinat i apariia unor modele de management corespunztoare.
Managementul calitii este parte component att a tiinei managementului ct i a managementului practic
al firmelor i organizaiilor.
Introducerea n practic a tehnicilor managementului calitii produce modificri n cadrul
organizaiilor, att n ceea ce privete organizarea procesual i structural (compartimentele de asigurare a
calitii - "Quality Assurance" - ce au aprut pe lng controlul tehnic de calitate - C.T.C., cercurile calitii,
servicii de audit i controlling, echipe transfuncionale) ct i n ceea ce privete mentalitile managerilor i
executanilor, poziia clienilor, poziia proceselor unul fa de altul, etc. Calitatea nu mai trebuie doar
verificat, ci produs.
Concepia modern despre calitate privete acest concept dinamic i leag calitatea produsului sau
serviciului de alte dou elemente: calitatea concepiei (proiectului) i calitatea fabricaiei.

Conform standardelor ISO, calitatea fabricaiei reprezint gradul de conformitate a produsului cu

documentaia tehnic, iar calitatea proiectului exprim msura n care proiectul produsului asigur
satisfacerea cerinelor beneficiarilor i posibilitatea de folosire, la fabricaia produsului respectiv, a unor
procedee tehnologice raionale i optime din punct de vedere economic (figura 1.3), unde:
A = cerinele beneficiarului;
B = caracteristicile calitii prevzute n documentaia
tehnic;
C = caracteristicile produsului;
1 = calitatea concepiei;
2 = calitatea fabricaiei;
3 = calitatea produsului (sau serviciului).
La aceste noiuni se adaug i conceptul de calitate livrat. Calitatea livrat se refer la nivelul real al
calitii produsului sau serviciului, n momentul achiziionrii de ctre beneficiar.

2. Calitatea produselor software - particulariti

Dac societatea contemporan este o societate a calitii, atunci ea este n aceeai msur o societate a
informaiei i a tehnologiei informaiei.
n industria de software, ntlnim aceeai concentrare pe produs a concepiei, execuiei, asigurrii i
verificrii calitii, ca n faza preindustrial, dar, pe de alt parte, datorit complexitii produsului rezultat,
exist grupul de executani, mprit n colective sau indivizi specializai, care acioneaz pe parcursul unor
nlnuiri de faze (ciclu de via). Modelul de producie n industria software este un model de "producie a
proiectelor". Particularitatea produciei de software rezid n faptul c activitile desfurate pot fi specifice
unei anumite faze a ciclului de via, sau pot fi independente de fazele ciclului de via.
Importana calitii produselor software rezid n cel puin trei aspecte:
erorile din programele de aplicaie pot fi fatale n anumite domenii unde vieile oamenilor depind de
acestea; aceste erori pot provoca pierderi financiare, materiale i tot felul de alte tipuri de insatisfacii sau
pierderi;
dac n domeniul produselor hardware costurile au o tendin general de scdere, n domeniul
dezvoltrii de software, dei productivitatea a crescut substanial, nu se nregistreaz i o scdere a costurilor
care s duc la aceeai tendin.
Acest ultim aspect se datoreaz particularitilor prin care calitatea se manifest n domeniul produselor
software, aa cum sunt ele relevate n [BAR01]:
- comportamentul instruciunilor nu se deterioreaz n timp;
- erorile sunt provocate de folosirea sau combinarea incorect a componentelor elementare, i nu de
aceste componente n sine;
- interaciunile dintre componentele unui program sunt, mai complexe, mai ales dac acestea
ruleaz n cadrul unor aplicaii complexe;
- erorile exist deja n program, ele sunt eliminate cu timpul, prin depanare, deci programul se
mbuntete prin trecerea timpului;
- eliminarea unei erori nu d sigurana c a diminuat numrul total de erori cu o unitate;
- non-calitatea programelor poate fi atribuit n ntregime greelilor umane, de proiectare, concepie,

calitatea concepiei

3 = calitatea produsului
(sau serviciului).
Calitatea fabricaiei

B = caracteristicile calitii
prevzute n documentaia
tehnic

C = caracteristicile
produsului

Figura 1.3. Elementele conceptului calitii

programare, documentare.
Un manager preocupat de calitatea produselor software trebuie s posede, conform [WEI2], anumite
abiliti speciale i chiar caliti native, cum ar fi: s observe ce se ntmpl i s neleag semnificaia
propriilor observaii; s se poat comporta i s poat aciona congruent n situaii interpersonale dificile,
chiar i cnd este derutat, suprat sau speriat; s poat nelege situaiile complexe. Aceast ultim abilitate
permite s se poat planifica un proiect i apoi s se observe i s se acioneze astfel nct proiectul s
decurg conform planului sau s poat fi modificat conform cerinelor i schimbrilor aprute pe parcurs.
Calitatea produselor software este definit n [BAR03] ca msura n care acestea satisfac cerinele
utilizatorilor prin caracteristici tehnice, economice i psiho-sociale. Aceast definiie se bazeaz pe dou
concepte care, puse n legtur, dau msura calitii unui produs software, i anume cerinele utilizatorilor i
caracteristicile produsului.
O importan deosebit n procesul de dezvoltare software o are dependena dintre specificul i
calitatea procesului generator, calitatea proiectului i calitatea produsului. Ca urmare, putem deosebi de la
nceput doi factori eseniali pentru calitatea produsului software, i anume modelul specificat (proiectul) i
conformana fa de proiect (fidelitatea reproducerii). Definirea problemei la beneficiar i clarificarea i
detalierea acesteia de ctre beneficiar i productor prin elaborarea unor specificaii, are un impact deosebit
att asupra calitii proiectului i, ulterior, a produsului, dar i asupra ntregului ciclu de via al produsului
software.

3. Managementul calitii - component a managementului firmei

Calitatea a devenit o problem major pentru managementul actual al firmei. In unele lucrri de
specialitate privitoare la teoria i practica managementului se pune chiar problema existenei, pe lng
funciunile tradiionale ale firmei, i a "funciunii de calitate". Ca urmare, managementul de vrf al firmelor,
trebuie s se preocupe de elaborarea strategiilor i politicilor firmei n domeniul calitii.
Integrate n strategia i politica general a firmei, strategiile i politicile de calitate asigur exprimarea
orientrilor privind mrimea performanelor viitoare ale firmei, posibilitile de asigurare a unui management
concurenial i determinarea procedurilor de comportament pe diferite piee i fa de diferite produse.
Conform [NICI], abordarea calitii prezint, n cadrul firmei, dou aspecte: asigurarea calitii i
gestiunea calitii.
Asigurarea calitii reprezint un ansamblu de mijloace, prestabilite i sistematizate, ntreprinse de
firm, n toate compartimentele implicate n activiti ce pot influena calitatea produselor i serviciilor
executate, astfel nct s exprime certitudinea realizrii cerinelor de calitate specificate.
Obiectivele gestiunii calitii constau n identificarea, analiza i interpretarea tuturor anomaliilor
aprute n timpul desfurrii produciei, precum i n definirea aciunilor corective sau de orientare a calitii
n toate etapele de realizare a produsului i/sau de prestare a serviciului, inclusiv prin prisma costurilor
calitii.
Unul din obiectivele fundamentale ale managementului calitii l constituie construirea, manevrarea i
mbuntirea unui sistem al calitii n cadrul organizaiei. Reciproc, managementul calitii nu poate avea
coeren n organizaii unde nu exist definit un sistem manevrabil al calitii, proceduri pentru meninerea,
actualizarea i mbuntirea acestuia. Astfel, avnd n vedere modelul Maturitate/Capabilitate - CMM/SEI,
[PFL1], elaborat n S.U.A. la Software Engineering Institute, se apreciaz c, dei gestiunea calitii poate
apare la o organizaie productoare de software situat la nivelul doi de maturitate - procesele sunt repetabile
- totui aceasta nu poate fi efectiv dect la organizaii aflate cel puin la nivelul trei de maturitate, unde
procesele sunt definite i instituionalizate. Acest nivel de maturitate presupune c produsele intermediare ale
etapelor dezvoltrii, precum i etapele n sine, sunt bine definite i "vizibile", permind msurarea
caracteristicilor produselor i proceselor intermediare.
Pentru exercitarea unui management al calitii eficient, sistemul calitii existent n organizaie trebuie
s asigure realizarea premiselor pentru un suport corect al activitii decizionale (Tabelul 1.1.).
Tabelul 1.1.

Premise pentru definirea aciunilor corective, de orientare a calitii n toate

etapele de realizare, a produsului software

existena unei baze de date referitoare la proiecte anterioare, actualizat cu datele proiectului
curent, inclusiv n ceea ce privete costurile;
actualizarea continu, pe baza unor contacte permanente cu managementul de nivel
nalt i cu compartimentele de marketing, a direciilor de aciune viabile de urmat n ceea ce
privete calitatea produsului, precum i a tendinelor aprute pe pia;

analiza i sistematizarea neconformitilor aprute, a momentelor, proceselor i cauzelor

apariiei acestora, precum i a costurilor aferente;
stabilirea de scenarii corective i elaborarea de diagrame de tip cauz-efect pentru fiecare tip
sistematic de neconformitate sau defeciune, aprute la nivelul produsului i la nivelul
sistemului (proceselor) prin care acesta este dezvoltat, cu luarea n considerare i a cauzelor
externe proceselor, precum i elaborarea de diagrame cauz-efect n studierea unor scenarii ale
schimbrii de tip "what if ?";
punerea de acord, din punct de vedere practic, a tendinelor generale ale pieei produsului, a
tendinelor generale n ceea ce privete calitatea, cu posibilitile concrete de care dispune
organizaia (firma) productoare, de a produce o anumit calitate;
propuneri de actualizare, pe baza rezultatelor concrete obinute, a strategiei i politicii firmei cu
privire la calitate.
Lucrarea de fa apare n cadrul programului de perfecionare a nvmntului superior de informatic
economic, ce include "coala doctoral de managementul calitii software", sub egida Consiliului Naional
al Cercetrii tiinifice Universitare, pe baza contractului 39687-146/1998.

4. Abordarea managerial orientat pe produs. Sistemul caracteristicilor de

calitate ale produselor software
Dup cum se arat i n definiia dat calitii (standardul ISO 8402, [ISO3]), aceasta este prezent n
fapt printr-un set de caracteristici. Aceste caracteristici pot fi mprite n:
a) caracteristici economice, exprimate prin costuri (de proiectare, elaborare, implementare, utilizare),
economii (de resurse materiale, umane, financiare), creteri de randament i productivitate, privite n legtur
cu costurile i economiile i analizate mpreun n vederea stabilirii oportunitii realizrii
produsului;
b) caracteristici sociale i psiho-senzoriale, care constau n potenarea elementelor creatoare,
eliminarea rutinei i stereotipiei, instruirea asistat a operatorilor. Asupra acestor caracteristici s-au fcut
studii comparative. S-a constatat, de pild, c rutina i nemulumirea utilizatorilor datorate lucrului, timp
ndelungat, cu anumite produse, este mult mai mic n cazul utilizrii interfeelor utilizator grafice (Microsoft
Windows, X-Windows, Macintosh), dect n cazul utilizrii unor interfee n mod text;
c) caracteristici tehnice i de utilizare (de utilitate general). Aceste caracteristici sunt tratate "in
extenso" n literatura de specialitate, iar organizaia internaional pentru standardizare a elaborat un
model concretizat n standardul ISO 9126 din 1991 [ISO1].
ntre caracteristicile de calitate, indiferent din ce perspectiv ar fi privite sau grupate, exist multiple
relaii de interdependen, subordonare, ierarhizare, decompoziie sau agregare. Complexitatea acestor relaii
determin ca ansamblul caracteristicilor de calitate s alctuiasc un sistem.
Pentru ca acest sistem de caracteristici de calitate s poat fi operaional, n sensul ca s se poat
selecta un set de caracteristici pe baza cruia s se construiasc un sistem de metrici cu care calitatea unuia
sau mai multor produse software s fie evaluat, setul selectat trebuie s aib urmtoarele proprieti:
- s fie apreciat complet de ctre evaluatori, n sensul de a putea surprinde toate aspectele calitii n
care evaluatorii sunt interesai (prin evaluatori se neleg persoanele autorizate i n cunotin de cauz,
interesate n evaluarea calitativ a produsului, a organizaiei productoare sau a sistemului calitii, respectiv
productori, beneficiari, auditori);
- s fie ierarhizabii, n sensul ca principalele caracteristici s poat fi descompuse n factori ce pot
cuantificai cu ajutorul metricilor;
- s fie necontradictoriu - caracterul contradictoriu al unor caracteristici nu poate fi eliminat
n totalitate, fiind practic imposibil s se dezvolte un set de caracteristici perfect consistent. Astfel,
complexitatea vine n contradicie cu fiabilitatea, portabilitatea cu eficiena, etc. Ca urmare, pentru elaborarea
unor specificaii pe baza unui set de caracteristici de calitate ce presupun aspecte contradictorii, fie se pot
stabili anumite nivele pentru anumite caracteristici, celelalte pstrndu-se n limite acceptabile sau lsndu-se
la dispoziia priceperii proiectanilor i programatorilor, fie se stabilete un sistem de prioriti specificate
explicit. De exemplu, n cadrul unui produs software, anumite programe/module trebuie s se execute mai
rapid, iar altele s fie prevzute cu proceduri suplimentare de verificare i testare a corectitudinii datelor,
chiar dac aceasta duce la ncetinirea duratei de execuie.
La nivel general, sistemul trebuie s se bazeze, conform [BR1], pe urmtoarele considerente
elementare:

1. conexiunea elementelor interne ale sistemului s fie mai puternic dect legturile sistemului cu
mediul. Aceasta se realizeaz prin selectarea pe anumite criterii (specificaiile beneficiarilor, urmrirea de
ctre productor a unor anumite caracteristici specifice clasei din care face parte produsul software respectiv,
etc), a caracteristicilor de calitate incluse;
2. orice sistem, indiferent de complexitatea sa este un subsistem al unui sistem mai cuprinztor. n
toate situaiile, sistemul caracteristicilor de calitate ce urmeaz a fi construit este doar un subsistem al calitii
software;
3. unitatea i complexitatea unui sistem presupune o anumit ordine n aezarea i funcionarea
elementelor sale;
4. orice sistem este caracterizat printr-o anumit structur, care poate fi privit ca atare, adic sub
forma exact de reunire a tuturor subsistemelor sau prin urmrirea diferitelor structuri componente;
5. orice subsistem poate avea o multitudine de bucle de reacie care se nchid pe anumite poriuni de
proces, pe anumite poriuni de sistem sau chiar la nivelul ntregului sistem. Acest lucru se traduce la nivelul
sistemului caracteristicilor de calitate prin interdependenele i contradiciile existente ntre caracteristici. Cea
mai dificil problem a sistemului calitii software este cercetarea mecanismului specific al interaciunii
dintre diferitele caracteristici de calitate ale sistemului, problem posibil de soluionat doar prin
managamentul calitii.
Obinerea unui sistem operaional de caracteristici - modelul calitii - pe baza cruia s se poat
realiza managementul i gestiunea calitii, presupune parcurgerea unor etape anterioare obligatorii, astfel:
a) definirea problemei - n care se stabilesc caracteristicile i factorii de calitate ce vor fi luai n
considerare;
b) construirea modelului calitii - analiza i modelarea relaiilor dintre componente, a modului de
interaciune, a interdependenelor, precum i alegerea unui criteriu de performan. Aceast alegere este
parial determinat de felul n care este precizat problema;
c) stabilirea soluiei - o soluie este obinut cnd se apreciaz c rspunsul obinut la un moment dat
este cel mai bun n comparaie cu criteriile stabilite;
d) omologarea soluiei - omologarea soluiei obinute pe baza modelului - rezultat al procesului de
optimizare. Se poate face prin:
A. compararea cu performanele precendete sau ale altor produse concurente pe pia - superioritatea
noii soluii poate fi considerat ca o verificare a valabilitii ei. Inconvenientul acestei metode const n aceea
c n evaluarea calitii oricrui produs pe o perioad trecut toate intrrile sunt cunoscute i elemente
importante ale lurii deciziei (variaiile probabilistice ale pieei, obinuinele utilizatorilor, etc.) sunt astfel
eliminate.
B. compararea cu performanele viitoare - const n compararea soluiilor supuse la seturi de date de
intrare externe identice, fa de una din ele. Inconvenientele sunt n principal legate de timp i cost ridicat
pentru alctuirea seturilor respective de date, elaborarea sau luarea n calcul a unor variante diferite ale
produsului, obinerea i analiza rezultatelor sumare comparative. n plus, orict de exhaustiv ar fi elaborate
seturile de date de test, n cazul produselor complexe, acestea nu pot fi atotcuprinztoare, neputndu-se trage
concluzii privind alte seturi de date de intrare.
C. comparaia prin simulare - experimentrile repetate satisfac caracteristicile unor ncercri n
condiiile unor date de intrare externe diferite i alese la ntmplare. Dar, aa cum se arat n [BR1], i
aceast metod genereaz probleme specifice care pot reduce contribuia sa la rezolvarea problemei.

5. Definirea caracteristicilor de calitate. Modele ale sistemelor caracteristicilor de

calitate software
n literatura de specialitate, att din ar ct i strin, se gsesc numeroase definiri i ierarhizri ale
caracteristicilor de calitate [ISO1], [STU1], [B0E1], [TAT1], [THA1], [BARO1], [BARO2], [BARO3],
[MCC1]. Unii autori folosesc doar termenul de caracteristici de calitate, alii le grupeaz n caracteristici i
atribute, caracteristici i factori sau caracteristici i subcaracteristici.
Se vor trata n continuare cteva caracteristici de calitate, pe baza definirilor fcute n [ISO1], [BAR01]
i [BAR03].
Funcionalitatea este definit n standardul ISO/IEC 9126, [ISO1], ca un set de atribute bazate pe
existena unui set de funcii i pe proprietile lor specificate. Funciile satisfac necesitile stabilite sau
implicate. Acest set de atribute ce definete funcionalitatea, arat "ce face" produsul software pentru a
ndeplini cerinele, pe cnd alte seturi rspund la ntrebrile "cnd" i "cum" corespunde nevoilor produsul
respectiv. Referirea la nevoile stabilite sau implicate se face pe baza definiiei calitii din standardul ISO
8402 [ISO3]: "totalitatea trsturilor i caracteristicilor unui produs sau serviciu care se bazeaz pe abilitatea

sa de a satisface nevoile stabilite sau implicate". ntr-un context contractual nevoile sunt stabilite, specificate,
pe cnd n alt context nevoile implicate trebuie identificate i definite.,
Fiabilitatea este privit n [BARO1] ca msura ncrederii pe care o avem n concepia i n capacitatea
unui program de a funciona corect n toate condiiile avute n vedere de la nceput. Aceast definiie se
refer mai mult la fiabilitatea procesului dect la cea a programului, fiind legat de probabilitatea ca o eroare
din program s fie activat de un set specific de intrri. Fiabilitatea produselor software este caracteristica ce
exprim poate cel mai bine particularitile acestei industrii, dac abordm problema n comparaie cu
fiabilitatea produselor hardware. Exist abordri cantitative ale fiabilitii, exprimate prin probabilitatea ca un
produs software s-i ndeplineasc funciunile cu anumite performane i fr erori ntr-un interval de timp
i n condiii de exploatare date, precum i abordri calitative ce privesc fiabilitatea ca o capacitate a
produsului software. Standardul ISO/IEC 9126 [ISO1], definete fiabilitatea ca un set de atribute care se
bazeaz pe capabilitatea produsului software de a-i menine nivelul de performan n condiii i pe o
perioad de timp stabilite. Limitele fiabilitii unui produs software se datoreaz erorilor din etapele de
formulare a cerinelor, proiectare i implementare. Cderile datorate acestor erori depind de modul i
condiiile n care este utilizat produsul. Corespunztor ciclului de via al produsului software, putem
distinge o fiabilitate previzional sau proiectat, o fiabilitate experimental i o fiabilitate operaional (la
beneficiar).
Utilizabilitatea este definit n [ISO1] ca un set de atribute bazate pe efortul necesar pentru a utiliza
produsul software i pe evaluarea individual a utilizrii produsului, de ctre un grup stabilit sau implicat de
utilizatori. Standardul d termenului de utilizatori un neles foarte larg, incluznd operatori, utilizatori finali
i indireci, precum i toate categoriile de persoane care i desfoar activitatea dependent sau sub influena
utilizrii produsului software respectiv.
Eficiena produselor software este definit n [BAR03] ca o corelaie optim ntre consumul de resurse
al produsului i complexitatea problemei de rezolvat. Tot n acest material se arat c eficiena poate fi
exprimat prin introducerea noiunii de output al produsului software, definit ca o relaie ntre complexitatea
datelor iniiale i a rezultatelor finale. Standardul ISO/IEC 9126 [ISO1], definete eficiena tot ca pe o
corelaie, dar nu ntre consumul de resurse i complexitatea problemei, ci ca un set de atribute bazate pe
relaia dintre nivelul de performan al produsului software i cantitatea de resurse utilizate, n anumite
condiii stabilite. Spre deosebire de [BAR01], standardul [ISO1] lrgete mult categoria resurse consumate,
incluznd att memoria, timpul de execuie, precizia ct i cantitatea de hrtie utilizat, serviciile de operare,
mentenan sau suport de personal.
Mentenabilitatea este definit n [ISO1] ca un set de atribute bazate pe efortul necesar pentru a face
modificrile specificate n produsul software respectiv. Modificrile includ corecii, mbuntiri sau
adaptri la modificri ale platformelor (de dezvoltare, int, etc), modificri n cerine i specificaii
funcionale. Conform [BAR03], un produs software este mentenabil n msura n care permite o rapid i
uoar actualizare astfel nct s poat fi utilizat n continuare n bune condiii. Actualizrile din aceast
definiie sunt privite n sens mult mai restrns. Ele referindu-se numai la operaii la nivelul produsului
software, al modulelor, secvenelor de instruciuni i instruciunilor. Nivelul mentenabilitii se poate stabili
pe baza datelor obinute n etapele de proiectare, testare i utilizare curent. Evaluarea acestei caracteristici se
bazeaz pe datele obinute indirect prin examinarea influenei modificrilor asupra celorlalte caracteristici
de calitate, cum ar fi complexitatea, testabilitatea, modularitatea, etc. Un factor care determin obinerea unei
mentenabiliti corespunztoare este corelarea strict a nivelului de complexitate cu funcia de procesare
ndeplinit de fiecare modul.
Portabilitatea este definit n [ISO1] ca un set de atribute bazate pe facilitatea pe care trebuie s o ofere
produsele software n direcia transferrii dintr-un mediu n altul. nelegnd prin mediu nu numai contextul
hardware i/sau software, ci i cadrul organizaional, standardul ISO/IEC 9126 - [ISO1] - extinde
considerabil limitele cerinelor impuse portabilitatii. Restrngnd mult limitele, n [BARO3] portabilitatea
se definete ca o caracteristic de ordin calitativ a programelor ce pot fi rulate pe mai multe tipuri de
calculatoare. Programele sunt considerate portabile nu numai dac pot fi implementate pe mai multe tipuri de
calculatoare direct, fr alte modificri ci i dac execuia pe alte tipuri de sisteme de calcul necesit
modificri de mic anvergur i un efort de programare mult mai mic dect cel cerut de rescrierea acestor
programe. Un aspect deosebit al acestei caracteristici este legat de portabilitatea compilatoarelor, de diferitele
faciliti video i audio oferite de sistemele de calcul i folosite n programele de aplicaie. Abordarea diferit
a acestei caracteristici de calitate, la sfritul anilor '90, este relevat i de preocuprile pentru crearea de
sisteme ieftine, care pot deveni staii de lucru n mai multe tipuri de reele, rulnd programe dezvoltate pe
platforme int diferite - UNIX, Windows, DOS, VMS - avnd n spate puterea reelei globale - Internet.

Interoperabilitatea considerat de mai muli autori un atribut al calitii, reprezint, conform

[BARO3], capacitatea produsului software de cuplare cu alte produse. Acest atribut permite reutilizarea unor
programe pentru construirea unor aplicaii complexe. Cuplarea se poate asigura direct sau folosind interfee.
Problema interfeelor i a bibliotecilor de funcii prin care pot fi cuplate aplicaii, a stat la baza dezvoltrii
unor concepte, programe i specificaii deosebit de complexe. Exemple elocvente sunt specificaiile Open
Database Connectivity, utilizate n aplicaiile de baze de date, API-urile dezvoltate de Microsoft odat cu
sistemul Windows sau Object Linking and Embedding - ncapsularea i nlniurea obiectelor - set construit
folosind tehnica obiectelor, prin care obiecte construite de unele aplicaii sunt accesibile i altor aplicaii.
Complexitatea este probabil atributul sau caracteristica de calitate pentru care s-au dezvoltat cele mai
multe sisteme de metrici i care a fost studiat n corelaie cu mai multe caracteristici, n special cu
fiabilitatea, mentenabilitatea, stabilitatea, etc. Acest atribut a fost abordat fie studiind codul surs al
programelor, fie prin intermediul grafurilor asociate programelor, grafuri n care nodurile corespund
structurilor de control iar arcele arat fluxul execuiei. Din prima categorie de abordri fac parte sistemele de
metrici Halstead i combinaii ale acestora - [BAR02], [TEO1] - iar din a doua categorie, metrica cea mai
reprezentativ este complexitatea ciclomatic, dezvoltat de T.McCabbe [MCC1]. n [MUN1] i [RADI] se
propun noi metrici pentru msurarea complexitii, obinute prin combinarea celor dou categorii amintite,
utiliznd metoda statistic a analizei factorilor. Elaborarea unor modele pertinente pentru studierea i
predicia complexitii produselor software este important pentru programarea resurselor umane, materiale,
financiare i de timp, necesare proiectrii i implementrii programelor de complexiti diferite. De
asemenea, complexitatea influeneaz i cheltuielile ulterioare punerii n funciune a produsului (postvnzare, service, asisten tehnic), precum i eforturile de a dezvolta noi versiuni sau de a rescrie produsul i
pe/pentru alte platforme.

Modele ale sistemelor caracteristicilor de calitate software

Modelele cunoscute, ce apar n literatura de specialitate, valorific experiena ctigat n elaborarea
unor proiecte, i, plecndu-se de la anumite necesiti practice ale aplicaiilor i de la un set iniial de
caracteristici, prin rafinare, ordonare i diminuarea redundanelor, se ajunge la construirea unei arborescente
a caracteristicilor. Arborele respectiv are cel puin dou nivele, deosebindu-se o structur de nivel nalt care
nglobeaz caracteristici generale agregate i o structur de nivel sczut (elementar), care cuprinde
caracteristicile "primitive" (subcaracteristici, factori). Se pornete de la ideea simplificatoare c toate
caracteristicile de nivel nalt se obin prin agregarea caracteristicilor primitive. Descompunerea
caracteristicilor generale n caracteristici de nivel inferior (pentru care se mai folosesc i ali termeni: factori,
primitive, etc), este necesar deoarece astfel se pot urmri/cuantifica n procesul de elaborare, respectivele
caracteristici de calitate.
Caracteristicile de pe nivelele superioare se constituie n modelul calitii, prin care se reflect
scopurile urmrite n construirea calitii produsului software i la evaluarea general a acestuia, iar cele de
pe nivelurile inferioare asigur fundamentarea controlului msurii n care produsul posed caracteristicile de
calitate respective i punctul de plecare n elaborarea, adoptarea sau adecvarea sistemelor de metrici.
Pentru identificarea legturilor se construiesc diagrame n care, prin arcele incidente, este reprezentat
relaia "dependent de", iar prin arcele descendente relaia "determin pe". De exemplu, pentru fiabilitate, se
pot reprezenta relaiile din figura 2.1. de mai jos.

8
Independen hardware
Portabilitate
Completitudine

Utilitate

Fiabilitate

Acuratee
Consisten

Eficien

Utilitate
general
Factori umani

Eficien hardware
Accesibilitate
Comunicativ

Mentenabilitate

Testabilitate

Structuralitate
Autodescriere

Uor de neles
Conciziune
Modificabilitate

Claritate
Extensibilitate

Figura 2.1. Model al sistemului de caracteristici ale

calitii

Maturitate

Maturitate

Acuratee
Fiabilitate

Tolerana la erori
Consisten

Utilitate
Complexitate

Corectitudine
Stabilitate
Integritate

n exemplul de mai sus, s-au luat n considerare un numr destul de mare de caracteristici de calitate
care vin n relaie cu fiabilitatea i, cu toate acestea, mai puteau fi gsite i altele, cum ar fi recuperabilitatea
sau structuralitatea. Acest gen de abordare conduce ns la un model inaplicabil.

De fapt, graful se construiete din setul iniial, limitat, de caracteristici - alese n funcie de specificul
problemei, al prelucrrii i al specificaiilor beneficiarilor - i pe baza relaiilor de preceden i de
descenden, apoi se rafineaz succesiv pn se ajunge la un model coerent, exhaustiv i necontradictoriu i,
ceea ce este mai important, un model aplicabil n continuare.
n Anexa 1 se prezint patru modele de sisteme de caracteristici, dezvoltate n strintate i n ar, i
anume modelul Boehm (Anexa IA), modelul McCall (Anexa 1B), un model romnesc elaborat la I.C.I.
Bucureti (Anexa IC) i modelul ISO/IEC statuat de standardul ISO 9126 (Anexa 1D), avnd unii parametrii
prezentai n tabelul de mai jos (tabelul 2.1).
Tabelul 2.1.
Modelul
Modelul
Modelul
Modelul
Boehm
McCall
I.C.I.
ISO 9126
Numr de caracteristici de
10
11
6
6
nivel nalt
Numr de caracteristici de
12
22
19
21
nivel sczut
22
33
25
27
Numr total de caracterisitici
4
2
2
2
Numr de nivele n arbore
Caracteristicile de nivel sczut
determin mai mult de o
Da
Da
Nu
Nu
caracteristic de nivel nalt ?
La primele dou modele (Boehm i McCall), exist mai multe caracteristici primitive, care determin
mai multe caracteristici de nivel nalt. De exemplu, n cazul modelului Boehm, completitudinea determin
att portabilitatea ct i fiabilitatea iar n cazul modelului McCall consistena determin corectitudinea,
fiabilitatea i mentenabilitatea. In aceste cazuri, decompoziia caracteristicilor de nivel superior n
caracteristici primitive, determin deplasarea interdependenelor i redundanelor dintre caracteristicile
structurii de nivel nalt ctre structura de nivel inferior. Modelul McCall expliciteaz relaiile dintre cele 11
caracteristici principale luate n considerare, ntr-un tabel anex.
Celelalte dou modele (I.C.I. i ISO) sunt mai coerente din acest punct de vedere, pentru c, dei nu se
poate spune c nu exist interdependene "ncruciate" ntre caracteristici, acestea nu sunt integrate n model.
De fapt, pentru modelul ISO/IEC 9126 - [ISO1] - structura de nivel inferior a modelului nu face parte din
standard ci este doar o propunere a ISO i International Electrotechnical Commission.

6. Metrici i sisteme de metrici ale caracteristicilor de calitate software. Scalare,

clasificare i evaluare conform standardului ISO/IEC 9126
Dei modelul calitii ncorporeaz recunoaterea obiectivelor relevante i, implicit, a caracteristicilor
de calitate aferente, din toate perspectivele relevante (utilizator, inginer software, manager, vnztor, etc),
construirea unui sistem particularizat al caracteristicilor de calitate, nu reprezint dect puntea ctre reala
msurare i evaluare, procese de egal importan n obinerea calitii dorite.
Conform [TRI3], pe baza unei corecte definiri a obiectivelor operaionale ale prilor implicate, trebuie
determinate metricile necesare pentru fiecare caracteristic sau factor (metrici "obiective", "consacrate", sau
cu caracter subiectiv). n [BAK1] se arat c pentru ca rezultatele s fie semnificative, msurarea calitii
produselor software cu ajutorul metricilor, trebuie s fie fundamentat din punct de vedere teoretic, iar
rezultatele empirice trebuie s fie obinute printr-o bun proiectare a experimentrii.
Teoria msurtorilor prevede un cadru pentru caracterizarea numeric a proprietilor sau atributelor
intuitive ale obiectelor sau evenimentelor. Aplicarea criteriilor teoriei msurtorilor la msurarea calitii
produselor software necesit identificarea i/sau definirea:
caracteisticilor, atributelor, produselor sau proceselor software;
modelele formale sau abstraciunile ce capteaz sau structureaz aceste caracteristici sau
atribute;
relaiile importante, ordonrile, ierarhizrile existente ntre obiectele modelate, determinate de
atributele modelelor;
maparea pe sisteme numerice, prezervnd relaiile de ordine. Aceast ultim idee constituie
baza teoriei reprezentaionale a msurtorilor. Dac toate criteriile de mai sus sunt satisfcute,
autorii [BAK1] definesc rezultatul final al acestei mapri ca o msur software. O mapare
arbitrara care nu satisface n mod necesar primele trei criterii, este definit ca o metric.

10

Pentru a putea folosi msurile software n predicii i planificri ale calitii software, este necesar s
existe sau s fie definite:
dou sau mai multe msuri ale caracteristicilor sau atributelor;
o idee, o supoziie sau chiar o teorie care pune n relaie msurile respective, necesar pentru
confirmarea sau infirmarea cauzalitii;
o demonstraie empiric a teoriei respective.
n ncercarea de structurare a msurilor i metricilor software din [BAK1], acestea sunt referite ca dou
concepte separate: msurile definite asupra unor caracteristici sau obiecte pe care le caracterizeaz numeric i
sistemele de predicie ce implic un model matematic i anumite proceduri.
Pentru a putea fi operaionalizate, metricile i msurile trebuiesc validate. Validarea msurilor se
definete ca fiind procesul prin care se asigur c msura reprezint o caracterizare numeric adecvat i
fidel a unui anumit atribut. Prin validare se dovedete c msura sau metrica respectiv este bine definit i
consistent. Validarea msurilor (numit i validare intern), vizeaz, luarea n considerare a modelelor
formale utilizate n captarea atributelor i caracteristicilor.
Validarea sistemelor de predicie reprezint procesul empiric prin care se stabilete acurateea
sistemului respectiv ntr-un mediu dat, prin mijloace empirice (de exemplu comparnd performanele unui
model cu date punctuale brute, cunoscute dintr-un anumit mediu). Att timp ct nu exist o anumit ipotez
despre capabilitile predictive ale unor asemenea msuri, ele nu pot fi validate n totalitate prin corelarea cu
anumite date disponibile la un moment dat. Pentru o validare complet este necesar i validarea extern,
prin corelarea consistent a msurii cu seturi de date, prin formule determinate iniial, pe baza unei analize de
regresie. Validarea extern se distinge astfel de validarea intern efectuat iniial pentru a arta c msura
respectiv msoar efectiv un anumit atribut. Validarea extern a msurii m este deci procesul prin care se
stabilete o relaie consistent ntre m i seturi de date empirice presupuse a msura un anumit atribut.
Autorii articolului [BAK1] arat c, dat fiind slaba nelegere (nc) a relaiilor dintre produsele
software i procese, validarea extern pare a fi extrem de ne-fiabil. Cu toate acestea, specialitii n domeniu
sunt gata s accepte aceast abordare a validrii, att timp ct msurile propuse reuesc s capteze nelegerea
i concepiile intuitive asupra atributelor respective. Msurile corecte pot fi dezvoltate cnd caracteristicile
sau atributele respective sunt definite ne-ambiguu, modelate corect i inteligibile.
n [PFL1] se pune n legtur modelul maturitate/capabilitate elaborat la Software Engineering Institute
(S.E.I.), n S.U.A., cu utilizarea unor anumite tipuri de msuri i metrici. Astfel, modelul amintit, care descrie
un set de nivele de maturitate n care se ncadreaz procesele de dezvoltare software dintr-o organizaie, este
folosit drept cadru de plasare a metricilor i msurilor software, pornindu-se de la ideea c numai cnd
procesul de dezvoltare este suficient de bine structurat i procedural are sens culegerea anumitor tipuri de
date (a se vedea tabelul 2.8).
Tabelul 2.8.
Nivel
Caracteristici
Metrici
5. Optimizat
mbuntirea procesului
Referitoare la proces + feed-back pentru
prin feed-back
modificarea procesului
4. Condus i
Proces msurat (cantitativ) Referitoare la proces + feed-back pentru
controlat
controlul procesului
3. Definit
Proces definit,
Referitoare la produs
instituionalizat
2. Repetabil
Proces dependent de
Referitoare la proiect
individualiti
1. Iniial
Abordare ad-hoc a
Msuri elementare
procesului de dezvoltare
Pentru nivelul 1 se pot face msurtori elementare referitoare la dimensiunea produsului, efortul de
dezvoltare, pentru a determina un nivel estimativ al productivitii. n nivelul 2 de maturitate nu sunt
disponibile msurrii activitile care realizeaz transformarea intrrilor n ieiri, astfel c, pe acest nivel pot
fi aplicate numai metrici referitoare la proiect. La un proces repetabil se poate msura efortul necesar pentru
dezvoltarea unui sistem, durata unui proiect, dimensiunea cerinelor, costul total al proiectului, etc. De
exemplu, se pot utiliza metricile:
numrul de linii de cod;
numrul de obiecte i metode (n cazul POO);
luni-persoan de efort;
volumul schimbrilor n definirea cerinelor;

11

anii de experien n domeniu, ntr-un anumit tip de aplicaii, arhitecturi sau metode.
Al treilea nivel de maturitate a proceselor dintr-o organizaie productoare de software se numete
definit, deoarece activitile sunt clar definite, cu puncte i condiii de intrare i ieire. Aceasta nseamn c
se pot examina intrrile i ieirile fiecrei activiti funcionale definite i executate n timpul dezvoltrii
produsului software. Aceast caracteristic permite msurarea produselor intermediare.
Metricile recomandate n [PFL1] pentru aceast etap sunt:
complexitatea cerinelor, msurat prin numrul de aciuni i obiecte distincte referite n
cerine;
complexitatea proiectrii, msurat prin numrul de module proiectate, complexitatea
proiectrii McCabe;
complexitatea testrii msurat prin numrul de ci de test, numrul de obiecte de
interfa testate;
numrul de defecte descoperite, numrul de defecte descoperite per unitate, modul, etap,
activitate (densitatea defectelor), densitatea defectelor pentru fiecare produs intermediar;
numrul de pagini de documentaie intermediar, numrul de pagini de documentaie
pentru produsul final.
Procesul condus i controlat ("managed process") de pe nivelul patru de maturitate ofer posibilitatea
utilizrii unor informaii din activiti ale dezvoltrii anterioare procesului curent (de exemplu problemele
descoperite n etapa de proiectare, testare, etc) ca feed-back pentru mbuntirea activitilor din aval. De
fapt, ntr-un asemenea tip de proces feed-back-ul determin modificarea desfurrii resurselor, activitile de
baz rmnnd neschimbate. Pe acest nivel de maturitate al procesului pot fi colectate i analizate date
referitoare la ntregul proces. n [PFL1] se recomand la acest nivel culegerea urmtoarelor tipuri de date:
date referitoare la modelul de proces (de tip cascad, prototipizare);
volumul obiectelor proiectate i realizate pentru a fi reutilizate, n ce msur produsul este
proiectat pentru reutilizare (cerine, proiecte de module, planuri de test, cod);
volumul reutilizrii la producere, n ce msur proiectul reutilizeaz componente
de la alte proiecte;
identificarea defectelor, cum i unde sunt descoperite defectele (n timpul revizuirii
cerinelor, proiectelor, inspeciilor pe cod, n fazele de testare);
utilizarea managementului configuraiei: este impus procesului de dezvoltare o
schem de management al configuraiei? Managementul configuraiei i controlul
muncii de modificare permit managementului de proiect exercitarea unui control mai
eficace al procesului de dezvoltare? Managementul configuraiei determin i o evaluare a
impactului alterrilor i modificrilor n activiti i/sau produse?;
rata de realizare a modulelor: timpul mediu n care modulele sunt identificate, proiectate,
codificate, testate i integrate, reflect gradul n care procesul i mediul de dezvoltare
faciliteaz implementarea i testarea?
Determinarea unor relaii clare dintre caracteristicile produsului i variabilele ce caracterizeaz
procesul de dezvoltare ajut la evaluarea msurii n care procesul sau activitile acestuia corespund
obiectivelor de calitate i productivitate ale organizaiei.
Un proces optimizat este ultimul nivel de maturitate din cadrul modelului. n acest stadiu, msurile i
metricile sunt utilizate pentru modificarea i mbuntirea procesului. Modificrile procesului pot afecta att
organizaia ct i procesul n desfurare. De exemplu, n cadrul acestui tip de proces, dac metricile indic,
n timpul activitilor de definire i proiectare a cerinelor, un grad ridicat de incertitudine, tipul de proces
poate fi modificat din cascad n prototipizare, pe baza acestor informaii. Astfel, un proces optimizat ar oferi
maximum de flexibilitate dezvoltrii software. Metricile s-ar comporta ca senzori iar procesul nu ar fi numai
sub control ci i dinamic. Conform studiilor S.E.I., acest nivel de maturitate nu a fost nc atins de nici o
organizaie productoare de software.
Metricile sunt folositoare n condiiile n care sunt implementate ntr-o secven bine fundamentat de
activiti. Paii de urmat n utilizatea metricilor, conform [PFL1], sunt:
1 - evaluarea procesului;
2 - determinarea metricilor i a datelor ce trebuie colectate;
3 - determinarea celor mai potrivite tehnici i instrumente pentru a fi utilizate n cadrul proiectului;
4 - estimarea costului i programului proiectului;
5 - determinarea nivelului metricilor;
6 - construirea unei baze de date a proiectului;

12

7 - evaluarea costului i a programului proiectului;

8 - evaluarea productivitii i a calitii;
9 - formarea unei baze pentru estimri viitoare.

Scalare, clasificare i evaluare conform standardului ISO/IEC 9126

Dup cum se autodefinete, standardul ISO 9126 [ISO1], este aplicabil n definirea cerinelor de
calitate ale produselor software i n evaluarea calitii produselor software, ceea ce include:
definirea cerinelor de calitate ale produsului software;
evaluarea specificaiilor pentru a asigura ndeplinirea cerinelor de calitate n timpul procesului
dezvoltrii produsului software;
descrierea facilitilor i atributelor produselor software (de exemplu n manuale ale
utilizatorilor);
evaluarea, nainte de livrare, a produselor software dezvoltate;
evaluarea produselor software nainte de acceptare.
n anexa B a standardului, n mod edificator, se prezint i cerinele care au dus la alegerea
caracteristicilor descrise n acest standard, i anume:
s acopere mpreun toate aspectele calitii software, aa cum rezult din definirea calitii n
standardul [ISO3];
s descrie calitatea produsului cu un minim de suprapunere;
s fie ct mai aproape de terminologia stabilit - consacrat;
s formeze un set de ase pn la opt caracteristici din raiuni de claritate i uurin n lucrul cu
modelul;
s poat fi identificate zone de atribute ale calitii produselor software pentru rafinri viitoare.
Rafinarea i dezvoltarea n continuare a celor ase caracteristici de baz oferite de standard se face n
funcie de tipul produsului software. Dei nu exist o clasificare unanim acceptat a acestora, standardul
mparte produsele software n. trei clase: sisteme software cu misiuni critice (pentru care fiabilitatea este
esenial); sisteme software cu criticitate n timp real (pentru care eficiena este cea mai important
caracteristic) i sisteme software interactive orientate ctre utilizatori (pentru care utilizabilitatea este cea
mai important).
n Anexa 2 se prezint modelul procesului de evaluare propus de standardul ISO 9126 [ISO1], proces
ce presupune trei etape: definirea cerinelor de calitate, pregtirea evalurii i procedura de evaluare. Etapa
de pregtire a evalurii cuprinde activitile de selecie a metricilor, definirea nivelelor de clasificare i
definirea criteriilor de evaluare, iar etapa de evaluare cuprinde activitile de msurare, de clasificare i de
evaluare.
Conform standardului, acest proces poate fi aplicat n fiecare faz a ciclului de via, pentru fiecare
component a produsului software.
Standardul ISO/IEC 9126 consacr n cadrul modelului general al procesului de evaluare, o etap
distinct metricilor i msurtorilor. Att acest standard ct i standardul ISO 9000-3 statueaz c,
deocamdat, nu exist metrici universal acceptate. Astfel, modelul de proces de evaluare ofer un cadru
extrem de larg i general pentru scalare i clasificare.
Maniera n care se definesc caracteristicile de calitate - att n general ct i n standardul analizat - nu
permite msurarea lor direct. De aici apare necesitatea decompoziiei acestora n caracteristici de nivel mai
sczut (subcaracteristici, atribute, factori), crora li se pot asocia metrici care s le reflecte ct mai fidel
nivelul.
Metrica este definit n cadrul standardului ISO/IEC 9126 [ISO1] ca fiind orice proprietate
cuantificabil a produselor software sau orice interaciune cuantificabil a produsului software cu mediul,
care poate fi corelat cu o caracteristic de calitate - direct sau printr-o subcaracteristic/factor/atribut.
Metricile difer n funcie de mediu i de faza procesului de dezvoltare software n care sunt utilizate.
Standardul recomand ca metricile utilizate s fie corelate cu punctul de vedere al utilizatorului, acesta fiind
crucial.

13

Excelent
valori
msurate

Satisfctor

Bun
Suficient

nivel de
clasificare

Insuficient

Nesatisfctor

Figura 2.2. Scala de valori ale metricilor, divizat n regiuni corespunztoare diferitelor grade de
satisfacie
Rezultatul msurtorilor, respectiv valorile msurate ale metricilor, sunt mapate pe o scal. Valoarea n
sine nu arat un anumit nivel de satisfacie, aspectul cantitativ trebuind s fie proiectat n continuare ntr-o
clasificare de ordin calitativ. Ca atare, scala de valori este divizat n regiuni corespunztoare diferitelor
grade de satisfacie (a se vedea figura 2.2).
Att timp ct calitatea vizeaz nevoi date, concrete i particulare, nu este posibil s fie stabilite nivele
generale de clasificare, acestea trebuind s fie definite pentru fiecare evaluare specific.
Pentru o evaluare coerent a calitii unui produs software, rezultatele evalurii diferitelor caracteristici
trebuie s fie agregate, pe baza unor criterii de evaluare. Evaluatorul trebuie s pregteasc o procedur,
utiliznd de exemplu, tabele de decizie sau medii ponderate (metoda punctajului) [NICI]. Metoda punctajului
acord un numr de puncte caracteristicilor de calitate. Calitatea produsului este superioar cnd numrul de
puncte acordat este mare. Coeficientul de apreciere prin punctaj (Kp) se determin astfel:
q p
Kp
100
unde q este ponderea fiecrei caracteristici de calitate iar p numrul de puncte acordat caracteristicii
respective.
Procedura mai include, de obicei, pe lng valorile msurate ale metricilor, i alte aspecte cum ar fi
durata sau costul, care contribuie la evaluarea calitii unui produs software ntr-un mediu particular.
Nivelul calitii exprimat agregat st la baza unor decizii manageriale, fundamentate pe criterii de ordin
managerial.
Un exemplu de evaluare a calitatii a doua variante de TI vezi tabelele urmatoare
Nivelul calitatii pentru varianta 1 a TI (indicii particulari)

Nivelul calitatii pentru varianta 1 a TI (indicii particulari)

14

Nivelul calitatii pentru varianta 2 a TI (indicii particulari)

15

Ponderea fiecrei caracteristici de calitate

Coeficientul de apreciere a calitatii generale a TI

pentru variantele 1 i 2 ale TI

16

7. Abordarea orientat pe produs i controlul dezvoltrii software

Considerarea calitii ca o mrime ce poate fi msurat exact, este principala caracteristic a abordrii
bazate pe produs. Rezult de aici o definire a calitii ca un ansamblu de caracteristici, diferenele dintre
caracteristicile de calitate ale produselor constituindu-se n diferene de ordin calitativ ntre acestea. Conform
[OLA1], o asemenea abordare se regsete, n special, n lucrrile de teorie economic i de calimetrie:
stabilirea unei corelaii stricte ntre variaia caracteristicilor i nivelul calitii produselor, a favorizat
introducerea modelrii matematice pentru estimarea acestui nivel. Sistemele calitii construite pe baza
abordrii calitii orientate pe produs, denumite i sisteme de calitate tradiionale, determin concentrarea
eforturilor organizaiilor productoare de software asupra minimizrii insatisfaciei utilizatorului. Aceste
sisteme se focalizeaz asupra detectrii i corectrii defectelor, utiliznd intensiv testrile, auditurile i
inspeciile. Datele rezultate din msurri statistice, metrici, testri, audituri i inspecii sunt nregistrate i
analizate n vederea mbuntirilor ulterioare. Cu toate acestea, dezvoltarea de software n sistem tradiional
rmne lipsit de coeren, datorit, n principal, specificului acestei industrii.
"Un sistem stabil este un sistem a crui performan este previzibil. Un sistem stabil se atinge prin
eliminarea, una cte una, a cauzelor ce produc disfunciile, detectate cel mai bine prin semnalele indicatorilor
statistici" - W. Edwards Deming. Adesea, abordarea problemei calitii prin prisma produsului se confund
prea mult cu abordarea pur statistic a problemei calitii. Att concepiile lui P. Crosby ct i cele ale lui E.
Deming sunt derivate din experiena acestora n studiul calitii n industria manufacturier. Dezvoltarea de
software nu este o industrie de tip manufacturier i de aceea "semnalele indicatorilor statistici" ale lui
Deming, dei necesare, nu sunt suficiente pentru control, deoarece nu exist suficient repetiie (deci
stabilitate) n procesul de dezvoltare de software, pentru ca indicatorii statistici comuni s poat fi
semnificativi. Cu alte cuvinte, n industria de software, fenomenele de mas sunt aproape inexistente. De
aceea, pentru caracterizarea real a calitii produsului software, este necesar mbinarea ideilor i practicilor
din statistic cu cele din ingineria i managementul proiectelor.
Prin natura sa produsul software nu este vizibil n sensul obinuit al cuvntului (nu poate fi perceput
vizual, auditiv, kinestetic, olfactiv, gustativ, etc), de aceea exist un mare numr de instrumente proiectate
pentru a face software-ul vizibil. Aceste instrumente i proceduri sunt utilizate pentru a face vizibile:
logica software - listinguri ale codului surs, scheme logice i o mare varietate de diagrame;
calitatea software - se reprezint sau se calculeaz valorile unor metrici ce exprim nivele ale unor
caracteristici de calitate, sau ale calitii globale (de exemplu graficul erorilor pe module, complexitatea
ciclomatic a modulelor, etc);
utilizarea unor modaliti de facilitare a comunicaiei -reprezentarea informaiilor despre logica
software sau calitatea software se face n mod particular pentru fiecare tip de actor participant la realizarea
produsului. Astfel, informaiile despre software vor fi mai bine nelese de programatori dac se vor
exprima sub forma schemelor logice, iar aceleai informaii vor fi mai bine asimilate de manageri dac vor
fi prezentate sub form de diagrame;
controlul distorsiunilor i redundanei.
n ingineria software, indicatori statistici precum numrul mediu de erori per modul reprezint numai
primul pas al procesului de eliminare a cauzelor disfunciilor. n acest caz, managerii nu pot nelege exact
semnificaia indicatorilor statistici fr consultarea personalului care cunoate structura codului programelor,
aa cum simpli programatori, care lucreaz la anumite pri ale produsului, nu pot percepe n totalitate
implicaia erorilor din cod, fr informaii despre consecinele acestor erori asupra ntregului produs
software. De exemplu, alte reprezentri (mai apropiate de viziunea managerial) ale graficului numrului
mediu de erori per modul, pot fi: costul remedierii erorilor per modul sau timpul consumat pentru remedierea
erorilor per modul. Deci, managementul calitii nu poate fi eficient dect dac informaiile despre software
sunt comunicate i urmrite att n dinamica lor ct i sub diferitele aspecte (caracteristici) sub care se
abordeaz calitatea software. Aa cum la construcia unei case sunt necesare mai multe planuri - planul de
structur, planul instalaiei electrice, planul instalaiei de ap i canalizare, planul de ncadrare n zon, etc. la construirea produsului software, i, n mod particular a calitii acestuia, sunt necesare informaii despre
fiecare element implicat: logica programelor, schema fluxului de date, schema bazei de date, rezultatele
testrii, etc. nu att la un moment dat, ci aa cum au evoluat ele, n dinamica procesului de dezvoltare. Orice
element care duce la distorsionarea, indisponibilitatea, neconsemnarea sau la nereprezentarea adecvat a
acestor informaii mpiedic organizaia productoare de software s ating un nivel superior de maturitate i,
implicit, un nivel superior de productivitate i calitate a produselor sale. E. Deming observ c oamenii care
nu-i pot reprezenta i vizualiza produsul, proiectul sau activitatea la care lucreaz, nu pot avea contribuii
reale la mbuntirea calitii.

17

8. Abordarea managerial orientat pe proces. Ciclu de via - modele i

structuri
Dup cum s-a prezentat i n capitolul anterior, la Software Engineering Institute - S.U.A., a fost
dezvoltat un model ce descrie tipuri eseniale de procese de dezvoltare software, clasificnd organizaiile
productoare n funcie de caracteristicile particulare ale procesului lor de producie/dezvoltare. In [WEI2],
G. Weinberg arat c, pentru industria de software, nivelele de maturitate prezentate n modelul CMM/SEI,
reprezint modele socio-culturale ale acestei ramuri de activitate.
G. Weinberg adaug la modelele cuprinse n CMM/SEI i nivelul, sau modelul, "0". Acest model nu
este un model profesional (industrial). Este caracterizat n [WEI2] prin lipsa separaiei dintre productorul i
utilizatorul de software ("economia natural"). Nu exist client, manager sau procese specificate, iar cei ce
dezvolt software n acest model nu sunt contieni c execut i particip la un proces. Motivaia lor este
aceea c nimeni nu poate s le ofere ceea ce doresc sau s le neleag cerinele. Actorii acestui model'sunt
programatorii aflai n postura magic a unui creator divin, omniscient i omnipotent. Cu toate c acest model
are meritul de a garanta satisfacia utilizatorului (deoarece este identic cu productorul), nu poate fi luat n
considerare, deoarece nu nseamn "industrie" software.
Industria de software nseamn proiectarea unor aplicaii de complexitate i dimensiuni mari,
dezvoltate n cadrul unor echipe i, de cele mai multe ori, n organizaii specializate, urmnd etape bine
stabilite [SPI1]. Conform [SPI1], aceste etape se refer la specificarea cerinelor utilizatorului, analizarea
acestora, proiectarea de detaliu, implementarea, testarea i ntreinerea/mbuntirea produsului creat, pn
la scoaterea sa din utilizare (figura 3.1)- Aceast succesiune de procese definete ciclul de via al software i
constituie obiectul ingineriei programrii" [SPI1].
Software se creaz ca rspuns dat unui set de nevoi la un moment dat, i odat cu evoluia acestui set
de nevoi i produsul software se maturizeaz, att n perioada de dezvoltare ct i n perioadele de
operare/mentenan [BRY1]. Figura 3.2. ilustreaz un alt model al ciclului de via al software, propus n
[BRY1].
n stadiul de concept, viitorul produs software poate fi vag perceput. Dup realizarea proiectului
preliminar produsul ncepe s capete contur, iar dup realizarea proiectului de detaliu produsul software este
complet conturat. n etapele urmtoare produsul software exist sub form de cod i sub form de
documentaie. n aceste ultime stadii produsul este n form executabil trebuind s ndeplineasc funciile
specificate n cerine.
Specificare
cerine
Analiz
cerine
Implementare
Testare
Instalarea
ntreinerea

Figura 3.1. Ciclul de via al software (modelul 1)

18

Ciclul de via al software

Software se creaz ca rspuns
dat unui set de nevoi la un
moment dat, i odat cu evoluia
acestui set de nevoi i produsul
software se maturizeaz, att n
perioada de dezvoltare ct i n
perioadele de operare/
mentenan

Specificare
cerine
Analiz
cerine
Concept

Proiectare
Preliminar
de detaliu
Implementare

Testare
Instalare
ntreinere
n stadiul de concept, viitorul produs software poate fi vag perceput. Dup realizarea
proiectului preliminar produsul ncepe s capete contur, iar dup realizarea proiectului
de detaliu produsul software este complet conturat. n etapele urmtoare produsul
software exist sub form de cod i sub form de documentaie.

Figura 3.2. Etapele ciclului de via al software

CERINE
PENTRU
SOFTWARE

CONCEPT
PROIECTARE
PRELIMINAR

PROIECTARE
DETALIAT

PROTOTIP
(PRIMA
FORM)

PRODUS
SOFTWARE
OPERAIONAL

Figura 3.3. Ciclul de via (modelul 2)

Desigur; modelele prezentate sunt modele ideale. n realitate, produsul software nu trece fr opriri i
revizuiri de la o etap la alta (datorit unor evenimente de natur variat - modificarea cerinelor,
descoperirea unor erori de proiectare, etc.). Ca urmare, activitatea de mentenan se aplic n toate stadiile
modelului.
Problema cea mai important de rezolvat n aceste situaii o reprezint controlabilitatea proceselor
implicate de ciclul de via, avnd n vedere restriciile impuse acestuia (timp, resurse). Chiar i n cazul celor
mai clare modele ce posed un nalt nivel de acuratee, controlarea proceselor nu poate fi fcut cu succes,
datorit perturbaiilor aleatoare produse de intrrile proiectului (resurse, date, situaii, poziii ale actorilor
implicai i chiar stri de spirit, etc.). n plus, fa de modelul de dezvoltare, controlabilitatea proceselor
presupune existena unor modele predictive asupra modului n care diferitele intervenii manageriale pot
afecta sistemul sub control. Dup prerea lui G.Weinberg [WEI2], cel mai mare ctig adus n industria de
software de modelul 2 (nivelul de maturitate caracterizat n CMM/SEI prin "repetabilitate, rutin") sunt
planurile de dezvoltare a produsului software ale organizaiilor productoare. Aceste organizaii au fcut
eforturi majore pentru a-i construi standarde interne, a prescrie i documenta secvene de
Aciuni menite s controleze dezvoltarea de software. Metodele tipice prescriu o serie de pai ideali de
urmat, ncepnd, de obicei, cu un studiu de fezabilitate, specificarea cerinelor i proiectarea de nivel nalt,
urmate apoi de proiectarea de detaliu, codificare, testarea pe uniti, testarea ntregului sistem, testarea "beta"
i versiunea final ("product release"). n Figura 3.4. se red modelul de procese n cascad din [WEI2], din

19

clasa crora fac parte i modelele prezentate mai sus. Modelul original se traduce printr-un plan strict
secvenial, avnd reprezentate sgei unidirecionale ntre noduri.

Cerine
de sistem

Specificaii
cerine

Analiz

Proiectarea
programelor

Codificare
Testare

Operaionalizare

Figura 3.4. Modelul de procese n cascad

n spiritul acestui tip de modele, s-au elaborat metodologii, cum este cea dezvoltat n ara noastr, la
I.C.I. Bucureti, n 1982, i preluat n [D0D1]. Etapele acestei metodologii sunt prezentate, pe scurt, n
Anexa 4.
n scurt timp, au nceput s apar modificri ale modelului proceselor n cascad, constnd n bucle de
feedback, modificri ce reprezint recunoaterea faptului c un model pur liniar este o descriere inadecvat a
ceea ce se ntmpl n realitate n dezvoltarea de software. Modificrile iniiale aprute sunt prezentate n
Figura 3.5.

Cerine
de sistem
Specificaii
cerine
Analiz

Modelul proceselor n cascad, const n bucle

de feedback, modificri ce reprezint
recunoaterea faptului c un model pur liniar
este o descriere inadecvat a ceea ce se
ntmpl n realitate.
Bucle de feedback n dou zone: de la
proiectarea programelor la specificarea
cerinelor i de la testare la proiectarea
programelor.

Proiectarea
programelor
Codificare
Testare
Operaionalizare

Figura 3.5. Bucle de feedback n modelul proceselor n cascad.

Asumpiile implicite sau explicite luate n calcul la realizarea metodologiilor liniare sunt:
nu vor fi fcute greeli;
dac se vor face greeli, acestea nu vor fi de amploare;
prile responsabile vor ti, cu certitudine, cum s corecteze micile greeli.
Pe aceast baz, n [WEI2], metodologiile secveniale se definesc ca modelnd procese lineare,
suplimentate prin feedback-uri implicite. Odat cu creterea dimensiunii i complexitii proiectelor
efectuarea micilor corecii instinctive nu mai poate fi suficient.
Modificrile modelului, surprinse n Figura 3.5, vizeaz introducerea unor bucle de feedback n dou
zone: de la proiectarea programelor la specificarea cerinelor i de la testare la proiectarea programelor. Dar
reexaminarea, modificarea sau chiar refacerea specificaiilor sau a proiectelor programelor, pe lng faptul c
este costisitoare, presupune perturbarea i mai puternic a ntregului eafodaj al realitii proceselor de

20

producie, ceea ce face ca i acest model s fie inaplicabil. n plus, metodologia nu prevede n nici un sens ce
informaii vor trebui s circule pe buclele de feedback de la o etap la alta. n esen, din modelul modificat
reiese concluzia: "Fie faci totul bine de prima dat, fie refaci totul de Ia nceput".
Pornind de la ideea c, dnd atenia cuvenit micilor deviaii care apar n procesul de dezvoltare, de la
o etap la alta, se acioneaz mai devreme i deci mai puin, Humphrey Watts introduce ideea celulelor
unitare de baz (basic unit cells) din care se compune un proces mai mare. Fiecare din aceste celule este
prevzut cu bucl de flux de feedback ce provine de la celulele ulterioare i merge la celulele anterioare.
Minimiznd aceste celule, nonlinearitatea este ideal minimizat (Figura 3.6).

Input

Entry

N
Task

Exit

Out

Output

In

Figura 3.6. Celulele unitare de baz n procesul de dezvoltare

n conjuncie cu celulele de baz ale lui W. Humphrey, se utilizeaz "Ciclul evolutiv de livrare" al lui
Gilb. Conform acestui model, munca se desfoar n micro-proiecte, buclele de feedback neputnd crete
prea mult. Maximul admis al buclei este de la un micro-proiect la altul (Figura 3.7)

Stabilirea obiectivelor de perspectiv

Arhitectura global deschis

Feedback

Schi de plan de evoluie

Feedback
Ingineria etapei curente
(atribute, soluii, sub-etape)
Construirea etapei planificate
Livrarea ctre un utilizator real
Evaluarea rezultatelor

Micro-proiect
Figura 3.7. Maximul admis al buclei de feedback
Att celulele de baz ct i micro-proiectele, ncearc s rezolve problema legturilor inverse, dar se
focalizeaz numai asupra produsului care este n curs de dezvoltare. Pe legtura invers circul numai
informaii despre produs (rezultate ale unor metrici, ale inspeciilor asupra produsului sau ale auditurilor pe
produs), i nici un fel de informaii despre proces, n general. Pentru o conducere efectiv i eficient, un
manager trebuie s aib mult mai multe informaii i mult mai devreme n timp, informaii pe care, singur
produsul, nu le poate furniza. O viziune mai complet asupra mbuntirii calitii software i a
productivitii, o ofer abordarea procesual (Deming). Un program de mbuntire ideal combin orientarea
bazat pe proces cu ideea mbuntirilor mici dar continue, pentru a produce cu succes modificri,
meninnd instabilitatea la un nivel minim.
n vederea eliminrii bulversrilor ciclului de dezvoltare, generate ndeosebi de modificri, clarificri
sau revizuiri ale cerinelor beneficiarilor de software, s-a dezvoltat un nou model al proceselor, bazat pe
proprietile noilor instrumente i platforme de dezvoltare, care permit dezvoltarea relativ rapid a "faadei"

21

unei aplicaii incomplete (interfaa), asupra creia beneficiarul proiectului este chemat s-i exprime punctele
de vedere. Prototipizarea, bazat pe un schelet de aplicaie (prototip), dei este eficient pentru aplicaii de
gestiune de date (sisteme de gestiune de baze de date, subsisteme "front office" pentru culegere de date, etc),
poate fi mai puin eficient n cazul aplicaiilor de dimensiuni i complexitate mare. Aceasta fie datorit
costurilor considerabile ale dezvoltrii unor asemenea prototipuri, care vor influena costurile totale ale
proiectului, fie datorit complexitii construirii i testrii prototipului nsui. Prototipizarea rmne totui o
metod eficient de aplicat n cazul etapelor procesului de dezvoltare. Astfel, pentru fiecare produs software
rezultat n urma fiecrei etape din cadrul procesului de dezvoltare (specificaii, documentaii, cod), n funcie
de instrumentele automate de care se dispune i de eficiena economic, se poate elabora mai nti o variant
prototip, urmnd ca, n cadrul etapei, aceasta s fie rafinat i completat iterativ.
Att timp ct aceste modele ale ciclului de via sunt aproximri, nici unul nu poate fi perfect, dar
trebuie s aibe cel puin calitatea de a fi credibile. Aa cum se arat i n [WEI2], problema principal a
modelelor, ciclului de via rmne neliniaritatea, i, uneori, chiar iterativitatea (conexiunile inverse, repetate
sau nu). O alt soluie oferit acestei probleme este aceea de a corecta i completa modelul ciclului de via
cu un alt tip de modele - modelele interveniilor. Aceste modele pot ajuta att la nelegerea a ceea ce nu se
poate controla, ct i la formarea unei imagini corecte asupra efectelor unor intervenii efective n fluxul
proceselor. De fapt, procedeul const n a "altera" modelul ciclului de via (indiferent ce form ar avea
acesta) cu diagrame de tip cauz-efect.
Exemplul simplu prin care n [WEI2] se ilustreaz aceast tehnic de lucru este edificator. Astfel, dac
lum n considerare modelul ciclului de via tip cascad (Figura 3.1.3), se poate face urmtoarea afirmaie:
Dac s-a terminat etapa proiectrii programelor, i am executat etapa de codificare, urmtoarea
etap va fi testarea, etap ce va duce produsul software mai aproape de stadiul operaional.
Avnd n vedere modelul (concretizat ntr-o metodologie intern de lucru), se poate spune c, dac
"apar probleme" n etapa de codificare, produsul software ar putea fi mai departe de stadiul operaional, i
anume:
1. fie s fie trimis n stadiul "Verificare cerine" (de fapt reverificare cerine), aa cum sugereaz
modelul (i, probabil, metodologia de lucru);
2. fie s fie ntr-un stadiu nemenionat n model (i n nici o metodologie), ntr-un stadiu mai
mult sau mai puin formal, n care:
a) numrul i complexitatea dificultilor aprute n etapa de codificare este foarte mare (de
nedepit);
b) participanii la proiect manifest o ncredere nejustificat n capacitatea echipelor lor de
dezvoltare de a soluiona problemele aprute;
c) conducerea organizaiei crede, n mod eronat, c proiectul este foarte aproape de
terminare;
d) unul sau mai muli programatori de baz sunt epuizai din cauza muncii suplimentare,
Erorile incluse n program n etapa de codificare vor
Cerine sau pur i simplu au prsit organizaia,
sau manifest un puternic sentiment de frustrare,
fi descoperite n etapa de testare. Cauzele efectului
de sistem
din cauze diferite (familie, nemulumiri erori
de ordin
salariale,
fapt
grave profesional,
n etapa de testare
pot sauec),
nu pot
fi ce ce
asociate cu etape din cadrul modelului/metodologiei.
Specificaii
afecteaz
serios
munca;
n schem un model de diagram cauz -efect n
cerine
e) un programator i un ef au devenit inamici de
nempcat.
cazul
n care cauza erorilor aprute poate fi
intensitatea frustrrilor
n general, personalul implicat nAnaliz
dezvoltarea de software, (oameni cu pregtire
de tip exact), i n
special conducerea, sunt poate prea obinuii cu metodologiile, nefiind capabili s prezic, s neleag i s
depeasc cu succes, pentru toi actorii participani, efecte negative care nu sunt bazate n mod direct pe
Proiectarea
metodologiile elaborate de ei.
programelor
Continund exemplul de mai sus, erorile incluse n program n etapa de codificare vor fi descoperite n
etapa de testare. Cauzele efectului erori grave n etapa de testare
pot sau (de cele mai multe ori), nu pot fi
Codificare
asociate cu etape din cadrul modelului/metodologiei. n [WEI2] se prezint un model de diagram cauzTestare 3.8).
efect n cazul n care cauza erorilor aprute poate fi intensitatea frustrrilor (Figura
Intensitatea
frustrrilor

Operaionalizare

Erori n cod
Erori n etapa
de testare

Figura 3.8. Model de diagram cauz-efect

22

Efecte precum erori n cod pot avea originea n oricare din etapele modelului/metodologiei, precum i
alte cauze nemenionate (un programator care lucreaz la alt proiect corupe, din greeal, codul surs). De
asemenea, variabile precum intensitatea frustrrilor pot fi influenate de nenumrai factori i, cu toate c
acest tip de variabile nu apar n metodologii, acestea afecteaz procesele de dezvoltare de software. Cu alte
cuvinte, variabilele ce trebuie s fie utilizate de controlorii/managerii procesului de dezvoltare pot fi direct
derivate din produs, din proces, sau pot face parte din categoria "produselor secundare" rezultate n urma
procesului (de exemplu primele acordate programatorilor pentru ncadrarea n timp sau pentru calitatea
muncii, experiena cptat de membrii echipei de dezvoltare, relaiile umane i profesionale dintre membri
echipei, precum i cele dintre acestea i conductorii proiectului, experiena personal cptat de fiecare i
de echip n ansamblu, ncrederea n manageri, etc). Cele mai multe metodologii sunt focalizate asupra
produsului, astfel nct nu menioneaz nici un alt produs al procesului care nu este direct legat de calitatea
produsului software final rezultat, de costul sau programul proiectului.

9. Gestiunea construirii calitii software

Pentru gestiunea construirii calitii software, sunt utilizate ca instrumente de lucru diagramele de
proiect, diagrame ce puncteaz fiecare proces parcurs, n curs, n ntrziere, n impas, furniznd imagini de
stadiu sau de ansamblu pertinente asupra sistemului de dezvoltare de software. Aceste diagrame se realizeaz
cu ajutorul schemelor PERT, Gantt sau PPPP (Public Project Progress Poster). n [WEI1], G.Weinberg
puncteaz dezavantajele primelor dou metode (PERT i Gantt) cnd sunt aplicate n gestiunea proiectelor de
dezvoltare de software. Astfel, aceste tipuri de diagrame arat numai procesele, omind dou lucruri:
1. condiiile eseniale care trebuie s fie ndeplinite pentru ca un proces s fie parcurs cu succes, cum ar
fi:
cerinele documentate, care reprezint un standard de msurare pentru revizii i inspecii;
resursele umane implicate n proces, pregtirea i experiena lor;
activitile obligatorii care trebuie ndeplinite n procesele anterioare, fr de care procesul
prezent nu poate fi dus la ndeplinire;
resursele software i hardware de care depinde procesul;
adecvarea spaiului de lucru;
fondurile prevzute n buget pentru procesul prezent.
2. reviziile i inspeciile, care servesc la msurarea calitii produsului software rezultat n
urma procesului.
n diagramele PPPP, fiecare proces este reprezentat printr-un dreptunghi mprit n trei pri: condiiile
necesare, procesul n sine i revizia (Figura 3.1) n rubricile din cadrul dreptungiului poate fi cuprins
descrierea succint sau amnunit a fiecreia.
Condiii necesare
procesului N

Procesul N

Revizia (inspecia)
procesului N

Figura 3.11. Diagramele PPPP (Public Project Progress Poster)

Fr reprezentarea reviziilor i inspeciilor aferente procesului, actorii implicai uit adesea c produsul
software (intermediar sau final) rezultat n urma procesului nu este de fapt un produs, ci un produs candidat,
care devine produs doar dup completarea reviziei prin care msurtorile fcute sunt comparate favorabil cu
cerinele documentate, parte a condiiilor necesare desfurrii procesului. Acest mod de reprezentare
determin simplificarea diagramei, prin faptul c nu mai este necesar s fie reprezentate absolut toate
legturile inverse (legturile inverse dintre proces i revizia sau inspectarea sa fiind implicite). Dac produsul
software rezultat n urma procesului a trecut cu succes de revizie, rubrica reviziei este colorat cu verde
(Figura 3.12.a), dac n urma reviziei sunt de efectuat modificri minore, rubrica reviziei este colorat cu
galben i se adaug o nou rubric pentru proiect (Figura 3.12,b). n situaia n care se constat, n urma
reviziei, c produsului trebuie s-i fie fcute modificri majore, rubrica reviziei se coloreaz n rou i se
adaug o nou rubric pentru produs i pentru revizie (Figura 3.12,c). Dac, n urma reviziei se constat c
produsul trebuie refcut n ntregime, rubrica reviziei se coloreaz n negru, iar dreptunghiul se completeaz
cu o rubric pentru condiiile necesare, una pentru proces i una pentru revizie (Figura 3.12, d)

Cerin
Cerine
documentate

23
Proiectarea
Modulului 21
actualizat
cel

Proiectarea
Modulului
21
puin
sptmnal.

Documentele
Proiectului
Fiecare dreptunghi
corespunztor unui proces va
Modulului 21

Diagrama PPPP va fi
fi aranjat pe o scal a timpului, corespunztor programului proiectului, pentru a se putea urmri i ncadrarea
19.01
n timpul programat. n figura 3.13 se prezint un exemplu pentru
dou procese: elaborarea planurilor de
testare i elaborarea testelor pentru un produs software.

Pe scala
timpului
suntDiagrame
reprezentatece
datele
limitincadrarea
de terminare anproceselor
Dup cum se
Figura
3.14.
indic
timpul respective.
programat
poate observa
din exemplul
de mai sus,
Cerine
procesul de
Elaborare
Planuri de
Elaborare
Documentate,
elaborare
a
planuri de
Proiecte,
testare
teste
Teste complete
planurilor
de
testare
Standarde
complete
testare
s-a
de testare
realizat
la
timp, pe cnd
procesul de
Figura 3.13. Elaborarea planurilor de testare i elaborarea testelor pentru un produs
elaborare
a
software.
testelor este n
ntrziere.
Procesele care nu au nceput s fie executate la data stabilit n grafic sunt reprezentate n diagrama
PPPP lsnd o urm neagr n urm ("dr"), n figura 3.14. se prezint un exemplu, conform cruia scrierea
codului programelor pentru modului 21 nu a nceput la data fixat, anterioar datei de 19.01, datorit unor
revizii majore pe care au trebuit s le suporte proiectele modulului. Punerea n oper a diagramelor PPPP
(sau P4), produce modificri nsemnate n organizaia productoare de software, din mai multe motive. n
primul rnd, prin crearea i actualizarea unei asemenea diagrame, nici o neregul n sistemul de dezvoltare al
produsului software nu mai poate fi ascuns. Uurina cu care poate fi interpretat o diagram PPPP face
vizibil evoluia procesului, astfel nct pot fi identificate repede procesele ce cauzeaz ntrzierea. De
asemenea, seriozitatea cu care managementul de proiect urmrete realizarea i actualizarea diagramei PPPP
transmite un mesaj clar echipei asupra seriozitii i rigurozitii conducerii.
Condiii necesare
procesului N

Procesul N

Revizia (inspecia)
procesului N

Condiiile
procesului N+1

Procesul
N+1

Revizia
procesului
N+1

Figura 3.12,a. Diagrama, cnd produsul software a trecut cu succes de revizie

Condiii necesare
procesului N

Procesul N

Revizia (inspecia)
procesului N

Procesul N

Figura 3.12,b. Diagrama, cnd n urma reviziei sunt de efectuat modificri minore

Condiii necesare
procesului N

Procesul
N

Revizia 1
proces N

Procesul
N

Revizia 2
proces N

Figura 3.12.c. Diagrama, cnd n urma reviziei sunt de efectuat modificri majore

Condiii
necesare
proces N

Proces
N

Revizia 1
proces N

Condiii
necesare
proces N

Proces
N

Revizia 2
proces N

Figura 3.12.d. Diagrama, cnd n urma reviziei este necesar refacerea produsului

24

n unele variante ale diagramelor PPPP, dreptunghiurile aferente proceselor mai includ o rubric,
actualizat, de asemenea, sptmnal, i anume ct s-a cheltuit din bugetul alocat procesului respectiv.
Managementul calitii software se realizeaz i n mod asistat, cu ajutorul unor sisteme automate. n
[WAL1] se prezint arhitectura unui asemenea sistem, dezvoltat n cadrul programului universitar ESPRIT
REQUEST, n Marea Britanie, la Centrul pentru fiabilitate software din cadrul City University - Londra.
Scopul acestui sistem automat este de a asista un manager de proiect de-a lungul ciclului de via al unui
produs software, printr-o interfa, ce nsumeaz informaii din subsisteme ca: iniierea proiectului,
monitorizarea proiectului sau evaluarea proiectului. Acest produs software reprezint o variant constructiv
a modelului COQUAMO (Constructive QUAlity MOdelling System) dezvoltat tot n cadrul programului
ESPRIT. Conform acestui model, activitile privind calitatea software se cuprind n trei grupe, i anume:
asigurarea calitii (QA) - activitile planificate sau sistematice necesare pentru ca un
produs/serviciu s satisfac nevoile date;
controlul calitii (QC) - prevede modalitile concrete prin care este construit calitatea
produsului;
managementul calitii (QM) - ansamblu de activiti n cadrul funciilor generale ale
managementului, prin care se determin i implementeaz calitatea produsului.
Instrumentele automate pentru susinerea acestor activiti trebuie s asigure i pregtirea personalului
n utilizarea standardelor, precum i modaliti de susinere a activitilor de auditare a conformanei cu
standardele. Sistemul automat de management al calitii prezentat n [WAL1] are la baz trei standarde
NATO i un standard britanic: AQAP-1-"NATO requirements for an industrial quality control system",
AQAP-13-"NATO software quality control system requirements", AQAP-14-"Guide for the evaluation of a
contractor's software quality control system for compliance with AQAP-13" i BS5750 - "British Standard
on Quality
Systems". Structura sistemului cuprinde trei instrumente software, care acoper activitile mai multor
subsisteme- tabelul 3.2.
Aa cum se arat n [WAL1], n timpul testrii ntregului produs software i al primei perioade de
utilizare efectiv a acestuia, comportamentul produsului poate fi observat direct. Atunci este posibil
verificarea exact a conformanei calitii operaionale cu calitatea ce reiese din specificaiile pe baza crora
a fost construit produsul. Pentru aceast perioad, s-a construit un instrument separat de evaluare a
produsului software, deoarece metricile i modelele pe baza crora se efectueaz verificarea nivelelor finale
ale caracteristicilor de calitate software sunt de obicei diferite de cele utilizate n timpul monitorizrii
proiectului.
Printre avantajele pe care autorii sistemului - denumit n final IPSE (Integrated Project Support
Environments) - le evideniaz, sunt: asigurarea conformanei cu standardele prin nglobarea standardelor
direct n produsul CASE IPSE, (ntr-un instrument care asist producerea documentaiilor) i simplificarea
auditrii conformanei cu standardele, care poate fi demonstrat prin simpla verificare a utilizrii
instrumentelor CASE conformante cu standardele. n acest mod se reunesc constructiv activitile de nvare
a standardelor, de nvare a producerii unui produs software i de nvare a executrii unei activiti n
conformitate cu un standard ce descrie un sistem al calitii.
Tabelul 3.2

Structura QMS - Quality Management System

Activiti software

Instrumente

Subsisteme

1.
Planificarea i
iniierea

Asistarea
Creare planuri calitate, verificare, validare planuri, proiectului strategii
planificrii
de testare, identificare metrici utilizate la monitorizarea proiectului,
Crearea
Stabilire nivele msurabile ale factorilor de calitate (subcaracteristici),
specificaiilor
analiza viabilitii acestor nivele i a modalitilor utilizate pentru
cerinelor calitii atingerea lor
Analiza
Utilizare elemente critice pentru succesul proiectului pentru a
fezabilitii i
previziona calitatea produsului final n termenii specificaiilor
prognozarea
cerinelor calitii.
calitii
Utilizare date metrici selecionate pt. elaborare de rapoarte i analize de
stadiu privind proiectul, n termenii de calitate stabilii.

2.
Monitorizarea
proiectului

25

3.
Evaluarea
proiectului

Utilizare date obinute pentru realizare rapoarte privind nivelul calitii

produsului software obinut i prognoze cu privire la activitatea de
mentenan i suport tehnic.

10. Inspectarea calitii software. Auditul calitii software

Metoda cea mai natural i cea mai ieftin de a verifica corectitudinea produselor realizate sau a
proceselor ce au avut loc, este examinarea acestora. Conform [KNI1], Babbage i von Neumann solicitau cu
regularitate colegilor lor s-i examineze programele. Dei metodele de inspectare difer prin modul de
organizare i de acoperire a codului, structura, componena i dimensiunile echipei de revizie, n esen
acestea realizeaz n fapt acelai lucru: inspectarea produsului software i organizarea unor discuii avizate i
constructive n legtur cu acesta.
n timp, odat cu creterea dimensiunii i complexitii proiectelor, a exigenelor beneficiarilor,
industria de software a dezvoltat multe metode de testare a produselor software, unele dintre acestea fiind
automatizate cu ajutorul altor instrumente software. Cu toate acestea, testarea este un proces scump, mare
consumator de resurse, neoferind, n acelai timp i garania suficienei. Deci, alturi de testare, inspecia i
examinarea codului, indiferent de metoda utilizat, rmne un proces i o metod viabil att din punct de
vedere al rezultatelor ct i din punct de vedere al costurilor. Studii empirice, bazate pe rezultate practice
obinute de mai muli manageri de proiecte software (D.P. Freedman, G.M. Weiberg, M.E. Fagan, G.W.
Russel), referite n [KNI1], arat c reviziile i inspeciile pot reduce numrul de erori coninute n
programele ajunse n faza de testare cu aproximativ 10%, ceea ce determin reducerea costurilor de testare cu
50% pn la 80%.
Din rezultatele sistematizate de Russell (IEEE Software, Vol.8 No.l, Jan 1991, p.25-31) i interpretate
de Fagan i Knight (Achieving Ouality Software - Proceedings of a National Debate, Society for Software
Quality, San Diego, California, Jan. 1991), rezult c 65% pn la 85% din defectele operaionale sunt
detectate prin inspecii, la un cost cu 1/4 pn la 2/3 mai redus fa de testare, i sunt remediate cu un cost ce
ajunge la 1/7 pn la 1/2 fa de costul remedierii lor n faza de testare. Defectele operaionale sunt definite n
acest context ca mici greeli de logic, utilizri incorecte ale unor operatori, utilizarea unor construcii de o
ineficient inacceptabil i alte defecte ce determin programele s nu execute sau s execute incorect
anumite operaiuni, avnd uneori, prin propagare, efecte dezastruoase asupra funcionrii de ansamblu a
produsului.
n [TEO5] se prezint cteva tipuri de metode de revizie i inspecie a codului, aa cum sunt ele
enumerate n literatura de specialitate [KNI1], [WEI1]. Aceste metode s-au sistematizat n funcie de scopul
urmrit, astfel:

inspecii i revizii care urmresc depistarea erorilor sau obiective limitate:

revizia formal - autorul produsului, sau unul din revizorii familiarizai cu munca la produs
prezint produsul celorlali revizori. Fluxul inspeciei este condus de prezentarea fcut i de
problemele ridicate pe parcurs de revizori;
revizia activ a proiectrii (sau metoda Parnas i Weiss) - const n efectuarea unor scurte
revizii, fiecare fiind focalizat pe o anumit parte a produsului (de obicei segmente ale
documentaiei de proiectare). Participanii la aceste revizii sunt ghidai de ntrebrile puse de
autorii proiectrii, asftel nct s ncurajeze o examinare ct mai amnunit;
metoda camerei curate - este mai mult dect o simpl metod, dei revizuirea produsului de
ctre productor este .componenta sa major. Aceast metod cere autorilor s execute variate
revizii asupra produsului i nu le permite acestora ca o anumit parte a produsului (un modul
sau o parte din documentaie) s fie executat, pus n aplicare sau examinat de cel care 1-a scris.
n unele cazuri, nici compilarea modulelor nu este fcut de autorii lor. Acesta metod vizeaz
ncurajarea executrii unor verificrii riguroase din partea factorului uman, dar i structurarea
produselor software astfel nct acestea s se preteze testrii pe uniti sau module.

inspecii i revizii care urmresc testarea conformanei:

parcurgeri ale codului (walkthroughs) - sunt utilizate pentru examinarea codului surs n
relaie cu documentele de proiectare i cu specificaiile. Participanii execut o simulare pas cu
pas, linie cu linie a codului i a documentaiei. Autorii programelor sunt prezeni pentru a
rspunde eventualelor ntrebri ale participanilor;
- inspecii - ntr-o inspecie, se stabilete o list de criterii cu care produsul trebuie s fie conformant,
iar aceast list determin fluxul reviziei. Inspeciile sunt utilizate i pentru evaluarea unor caracteristici de

26

calitate, cum ar fi portabilitatea sau conformana cu standardele. Inspectorul trebuie s stpneasc bine lista
de criterii, sau s fie bine informat asupra nivelului dorit al caracteristicilor de calitate ce urmeaz a fi
inspectate;
- metoda celor N inspecii - este o tehnic adaptat analizei conformanei cu cerinele i specificaiile
utilizatorului, materializate n documentaii. n cadrul acestei metode sunt efectuate cteva inspecii, n
paralel, conduse de un singur moderator. Aceasta deoarece s-a constatat c rezultatele inspeciilor paralele nu
sunt, de obicei, convergente.
inspecii i revizii etapizate, care urmresc scopuri complexe:
- inspeciile Fagan - sunt o combinaie ntre reviziile formale, parcurgerile de cod i inspecii. Aceste
inspecii presupun parcurgerea a cinci pai: (1) evaluarea general, n care autorii explic coninutul
programelor inspectorilor. De exemplu, pentru o inspecie pe codul surs, n aceast etap se vor examina i
explica documentaia de proiectare a programelor, precum i logica general a acestora; (2) pregtirea, n
timpul creia inspectorii studiaz produsul i documentaia asociat; (3) inspecia -ntlnire controlat de un
moderator care, la rndul su, desemneaz o persoan ce va ghida inspectorii ntr-o examinare detaliat, linie
cu linie a produsului, pentru cutarea erorilor; (4) corectarea erorilor sesizate la inspecie. n urma parcurgerii
pasului anterior inspectorii vor elabora un raport cu erorile depistate, ce va fi nmnat autorului n vederea
efecturii coreciilor; (5) revizia final, n care se verific modul de corectare a erorilor semnalate n raport.
- inspecia fazat, sau pe faze - este proiectat astfel nct s asigure rigurozitatea, elasticitatea i
eficiena metodei n utilizarea resurselor precum i posibilitatea de a fi automatizat. Metoda presupune
efectuarea unei serii de inspecii pariale coordonate, numite faze. Fiecare faz trebuie s asigure c produsul
inspectat posed fie o anumit caracteristic specific sau particularizat, fie un mic set (subsistem) de
caracteristici nrudite. Caracteristicile examinate sunt ordonate astfel nct fiecare faz s poat prezuma
existena caracteristicilor verificate n fazele anterioare. La rndul lor fazele pot fi efectuate de un singur
inspector sau de mai muli inspectori. Fazele efectuate de un singur inspector reprezint procese riguroase i
rigide, ce constau n verificarea unor liste de cerine definite fr ambiguitate (check lists).
Produsul nu poate trece de aceast faz a inspectrii pn nu ndeplinete toate cerinele menionate n
listele respective. n fazele care sunt efectuate de mai muli inspectori se inspecteaz i se verific acele
caracteristici i proprieti ale unui produs software care nu pot fi surprinse de seturi de ntrebri precise, cu
rspunsuri de tip da/nu, independente de aplicaie.
ntr-o astfel de situaie inspectorii din echip examineaz produsul n mod independent, conform unor
proceduri structurate clar i apoi are loc ntlnirea acestora, n care se compar rezultatele individuale. Acest
tip de faz este n esen un proces Delphi. Inspectorilor nu li se furnizeaz alte informaii legate de produs i
de realizarea acestuia, n afara celor disponibile n documentaii.
Listele de cerine (check lists) utilizate pot fi specifice aplicaiei (n cazul fazelor executate de un
inspector), specifice domeniului aplicaiei i liste cu cerine de ambele tipuri (n cazul fazelor efectuate de
mai muli inspectori). Listele de cerine specifice domeniului ndreapt eforturile inspectorului ctre zonele
mai dificile ale domeniului respectiv, pe c|nd listele specifice aplicaiei sunt proiectate s foreze o examinare
exhaustiv a produsului de ctre inspector. De exemplu, ntr-o inspecie a codului surs, n lista de cerine se
pot genera periodic ntrebri de tipul: "La ce folosete aceast instruciune?" sau "Pentru ce este utilizat
aceast structur de date?", cu o rat fix, stabilit la mia de linii de cod surs. Modul cum se rspunde la
aceste ntrebri ne arat dac inspectorul a verificat poriunea de cod respectiv i a neles suficient de bine
produsul. Rspunsuri incorecte repetate la aceste tipuri de ntrebri pot conduce i la concluzia c produsul
software nu este suficient de bine documentat, programele nu sunt eficient comentate sau sunt scrise neclar.
Acest tip de informaie este esenial pentru a asigura mentenabilitatea produsului.
Inspecia pe faze, prezentat n [KNI1], elimin un important neajuns al celorlalte metode. Astfel, dei
metodele de inspecie i revizie amintite sunt benefice n sens statistic, aplicarea nici uneia dintre acestea nu
poate evalua mulumitor msura sau nivelul unei caracteristici sau unui subsistem de caracteristici de calitate
ale unui produs software. Dei managerii de proiect sunt n unanimitate de acord c aplicarea inspeciilor i
reviziilor mbuntete nivelul general de calitate al produselor organizaiilor productoare, acetia ar dori
ca, pe baza rezultatelor inspeciilor, s poat fi n msur s fac predicii asupra nivelului de calitate al
produsului software inspectat.
Potrivit [KNI1], pentru ca o metod de inspectare a unui produs software s aib o productivitate mare,
este necesar ca aceasta s ndeplineasc urmtoarele condiii:
1. s existe garania c metoda de inspectare se poate aplica riguros, astfel nct rezultatele s fie
specifice fiecrui produs particular i, n acelai timp, repetabile la nivelul aceluiai produs;
2. s fie flexibil, s poat servi unor scopuri complexe (nu numai unei simple detectri a erorilor
nainte de faza de testare);

27

3. s fie conceput astfel nct o mare parte a muncii s poat fi fcut automat, resursele umane s fie
utilizate numai atunci cnd este imperios necesar;
4. s fie eficient, astfel nct, cu un anumit volum de resurse, s se poat obine rezultate maximale.
Cu toate acestea, orict de fiabil sau riguroas ar fi inspecia calitii, dac nu este eficient din punct
de vedere al costurilor, metoda nu va fi aplicat. Aa cum se recunoate n [KNI1], disponibilitatea metodei
din punctul de vedere al costurilor este imposibil de modelat analitic ntr-un mod convingtor. Acest lucru
poate fi obinut numai prin experimentri la scara produselor software industriale, opernd n mediul
industrial, efectund experimente multiple de aceeai natur, pentru a permite estimarea variaiei statistice i
comparaii la scara de 1/1 cu alte medode. Aceste experimente sunt imposibile fr investirea unor resurse
substaniale, de-a lungul mai multor ani. n acest context, este puin probabil ca o organizaie productoare de
software de nivel industrial s susin o asemenea investiie, att timp ct nu exist suficiente dovezi c
metoda este fezabil nu numai ntr-un mediu academic. Dar, dei experimentele academice izolate nu pot
produce rezultate semnificative i concluzive, pot oferi indicaii empirice bune asupra utilitii relative a
inspeciilor calitii.
n [WEI1] G. Weinberg d cteva sfaturi demne de luat n seam, pentru cei care conduc
inspecii ale calitii produselor software. Acetia sunt sftuii:
- s ia cele mai radicale (pesimiste) decizii - fapt care va determina managementul organizaiei s ia n
calcul cu seriozitate argumentele pesimiste ale inspectorilor;
- s asculte cu atenie diferenele de opinii - dac un singur inspector nu reuete s neleag n
ntregime produsul, atunci trebuie reconsiderat problema dac productorul
a creat un produs
inspectabil (vizibil, inteligibil, stabil) cu implicaiile de rigoare asupra mentenabilitii sale;
- s observe cu atenie reacia inspectorilor la semnarea listelor de control sau a celorlalte documente
ale inspeciei - fiecare inspector poart responsabilitatea a ceea ce a fcut, eventualele ezitri pot ridica
ntrebri asupra calitii muncii inspectorului, sau asupra rezervelor pe care acesta le poate avea fa de
produsul inspectat;
- s remarce problemele care se redeschid mereu (subiectul discuiilor care nu se mai termin) - dac
inspectorii fac ncercri s redeschid discuia asupra unor probleme clasate, sau asupra crora s-a luat deja o
decizie, acest lucru indic faptul c exist rezerve.
Dei inspeciile sunt metode de gestiune i management al calitii orientate ctre produs, faptul c toi
participanii la inspecii i mbuntesc, n timp, ntr-un mod sau altul, abilitile personale (profesionale, de
comunicare, de conducere) efectul major al acestora se va reflecta, pe termen mai lung, asupra calitii
proceselor.

Auditul calitii software

Cererea din ce n ce mai mare de produse software performante i cu preuri accesibile, a determinat ca
acest tip de industrie s nfloreasc nu numai n rile dezvoltate, dar i n rile slab dezvoltate (India,
Pakistan, China etc). n dezvoltarea proiectelor mari se includ adesea produse preluate de la subcontractori,
sunt implicate echipe de dezvoltare aflate n locaii geografice diferite, astfel c, n toate cazurile,
complexitatea produselor se reflect i n complexitatea proceselor de dezvoltare. Acest lucru a generat
nevoia ca productorii i beneficiarii de software s doreasc o confirmare, de la o entitate independent, c
produsul dezvoltat este congruent cu cerinele, posed nivelul dorit de calitate i este improbabil s aib un
comportament aberant. Ca urmare, s-a dezvoltat auditul calitii, ca tehnic prin care o entitate independent
examineaz fie produsul software (auditul produsului), fie procesul generator (auditul proceselor).
Aa cum se arat n [BRY1] auditul software are cte ceva de oferit fiecrui participant: utilizatorul
este asigurat c produsul ndeplinete nevoile sale operaionale i de performan, cumprtorul este asigurat
c produsul va fi livrat la timp i n limitele bugetului alocat, iar productorul este asigurat c produsul s-a
dezvoltat ntr-o manier trasabil, fiind deci mentenabil, i va fi acceptat de utilizator i cumprtor. Costul
auditului este preul pe care utilizatorul, cumprtorul i productorul trebuie s-1 plteasc pentru a-i
reduce riscurile.
Indiferent de modelul de ciclu de via al procesului de dezvoltare software, la sfritul fiecrui proces,
stadiu sau etap, exist un interval de timp (o platform) n care "se trage linia", procedndu-se la o scurt
evaluare de stadiu. Aceste "platforme" sunt vizate de auditul software.
n esen, auditul implic dou procese fundamentale - verificarea i validarea. Verificarea este
procesul ce const n stabilirea dac, la sfritul fiecrui proces, stadiu sau etap de dezvoltare software,
obiectivele propuse la nceput s-au atins, i n ce msur. Verificrile succesive desfurate de-a lungul
procesului de dezvoltare traseaz maturizarea produsului software de la o etap la alta. Validarea este
procesul ce const n stabilirea dac produsul software rezultat dup un stadiu (etap, proces) de dezvoltare

28

ndeplinete obiectivele specificate n cerine. Pentru a fi efectiv i a putea preveni disfunciile generate de
modificarea cerinelor de la o etap la alta, validarea trebuie efectuat la sfritul fiecrei etape. Astfel,
validrile succesive traseaz conformana ntre produsul software rezultat dup fiecare stadiu de dezvoltare i
elementele coninute n cerine care trebuie ndeplinite n stadiile respective.
Verificarea i validarea, combinate i repetate, alctuiesc modele de proceduri pentru auditarea
software. Oricare ar fi modelul de procedur adoptat, scopurile auditrii sunt creterea vizibilitii produselor
sau proceselor software i stabilirea trasabilitii de-a lungul ciclului de via. De asemenea, auditul face
vizibil pentru manageri, stadiul curent i nivelul de calitate al produsului software, permind evaluarea
integritii acestuia.
Pentru ca auditul s-i ating scopurile (vizibilitate i trasabilitate), este necesar ca, n fiecare stadiu al
procesului de dezvoltare, produsul software s poat fi identificat. Prin identificare, n [BRY1] se nelege:
determinarea clar a prilor constitutive ale produsului software;
determinarea clar a relaiilor dintre aceste pri;
atribuirea unei etichete sau unui nume unic i sugestiv fiecrei pri constitutive;
descrierea grafic sau tabelar a prilor i relaiilor dintre ele.
Prile constitutive al unui produs software, n orice stadiu de dezvoltare s-ar afla, sunt elementele de
configuraie software.
Identificarea constituie i o premiz important a comunicaiei informaiei privind trasabilitatea. Astfel,
ca rezultat al verificrii i validrii, se poate construi un tabel sau o matrice a trasabilitii care s indice
corespondena dintre un element de configuraie dintr-un anumit stadiu i elementele de configuraie
corespondente din celelalte stadii de dezvoltare, sau dintre acesta i "reflectarea" sa n specificaii.
n tabelul 3.3 se prezint o succesiune de pai, constituii ntr-un model de auditare de software, ntr-un
anumit stadiu din ciclul de via, n viziunea autorilor [BRY1 ].
Tabelul 3.3.
Motivaia parcurgerii acestui pas: deseori, cumprtorul/utilizatorul nu i
1. Examinarea
specificaiilor cerinelor cunoate dect vag nevoile vis-a-vis de un produs software i nu este capabil,
de prima dat, s articuleze complet, necontradictoriu i fr ambiguiti
fa de produs
aceste nevoi n scris. Examinarea specificaiilor scoate n eviden omisiunile
i ambiguitile. Chiar dac aceste probleme nu sunt rezolvate pe loc,
examinarea preliminar face vizibile lucrurile care se pot transforma n
probleme cheie.
2. Verificarea
asigurrii calitii.

n sens restrns, asigurarea calitii poate fi privit ca asigurarea

conformanei produsului, n format, coninut i metodologie cu standardele
prescrise. Acest pas const n verificarea conformitii
produsului cu
standarde specificate (guvernamentale, industriale, interne, comerciale,
profesionale, etc), prescrise de managerii proiectului sau de utilizator.

3. Identificarea
produsului

Determinarea elementelor de configuraie, a relaiilor dintre ele, asignarea

de denumiri i etichete elementelor de configuraie ce constituie produsul,
descrierea sugestiv a acestora, aa cum s-a artat mai sus.

4. Examinarea
claritii,
completitudinii,
consistenei interne si
testabilittii.

Se execut comparnd coninutul textual i grafic al unor seciuni, cu

coninutul altor seciuni ale documentaiei. Sunt nregistrate inconsistene,
ambiguiti, omisiuni, adugri sau modificri nepotrivite ale scopurilor sau
nivelelor de detaliere.

29

5. Produsul este
verificat prin
comparaie cu etapa
anterioar din ciclul
su deviat.

Dac nu exist o etap anterioar, acest pas nu este executat. Corelarea

elementelor de configuraie identificate n stadiul prezent cu elementele din
care au evoluat. Compararea elementelor de configuraie corelate se face n
vederea verificrii dac scopurile i sarcinile etapei anterioare au fost atinse
n produs. Discrepanele sunt comparate cu cele identificate n audituri
anterioare, cu alte comentarii conexe (ale utilizatorilor, cumprtorilor sau
cu cele aprute n diferinte edine de analiz ale productorului), cu cele
reieite din rapoartele de stadiu ale configuraiei. Sunt identificate
discrepanele nou aprute, fa de cele cunoscute. Se mai examineaz n acest
pas i rezoluiile puse pentru soluionarea discrepanelor identificate deja.

Se execut cnd software-ul auditat este o actualizare a unui produs software

6. Elaborarea
rapoartelor de stadiu al auditat anterior. Procesul const n compararea elementelor de configuraie
identificate n stadiul prezent cu cele identificate n acelai stadiu al produsului
configuraiei
anterior, pentru a determina ce elemente de configuraie au fost modificate,
terse sau adugate. Aceste modificri, tergeri i adugri sunt comparate cu
lista modificrilor aprobate n acelai stadiu al produsului anterior, i
sunt nregistrate diferenele. Alctuirea
listei
modificrilor
este
obligaia managementului configuraiei. Lista de modificri este aprobat n
procesul controlului configuraiei.
Elementele de configuraie ale produsului auditat sunt corelate cu elementele
de configuraie identificate n specificaii. Acesta este un pas din procesul de
creare a matricei trasabilitii. Elementele de configuraie corelate sunt
comparate pentru a verifica modul n care au fost satisfcute cerinele prevzute
n specificaii.
8. Evaluarea identificate Evaluarea se bazeaz pe cele observate i nregistrate i neconcordanelor
i elaborarea raportului trebuie s fie obiectiv. n baza experienei lor, auditorii formuleaz concluzii
bazate pe tipul, numrul, natura i complexitatea discrepanelor identificate.
final
7. Validarea
conformanei cu
specificaiile de cerine
identificate

n Anexa 3 A se prezint un model de structur al raportului de audit, aa cum a fost propus n [BRY1].
Aceti pai sunt aplicabili n toate etapele pe care le parcurge un produs de-a lungul ciclului su de via.
Auditul este executat n dou situaii: n procesul de dezvoltare care conduce la crearea unui nou produs
software, i cnd produsul software este modificat. Auditarea software este parte a unui proces complex, i
anume procesul de control al configuraiei (al crui model propus n [BRY1] este prezentat n Anexa 3B).
Controlul procesului este un element al managementului configuraiei. Relaiile dintre auditul software,
procesul de control al configuraiei i managementul configuraiei, sunt cele din figura 3.15.
Auditul este o activitate profesionist i independent, deci, din echipa de audit fac parte persoane cu
pregtire i experien de nalt nivel, membri ai unor organizaii independente i profesioniste (firme de
audit, institute de cercetare, agenii guvernamentale sau neguvernamentale specializate, etc). Echipa de
auditori, prin poziia sa independent, ofer o garanie suplimentar asupra obiectivittii auditului. Din
componena echipei de audit pot face parte i manageri ai firmei, manageri ai proiectului i persoane din
comisia de control al configuraiei. Aceste persoane i pot aduce contribuia la proces, fr a realiza
auditarea.
Figura 3.15.

Managementul configuraiei
Control configuraie vers.
1
Audit

Control configuraie vers.

2
Audit versiunea

Control configuraie vers.

n
Audit versiunea

Resursele alocate auditrii trebuie s fie proporionale cu dimensiunea i complexitatea efortului de

dezvoltare. n evaluarea complexitii software, se au n vedere numrul de componente ce interacioneaz,
complexitatea logic a acestora, numrul i experiena persoanelor implicate n proiectare i dezvoltare, dar i

30

alte elemente mai "delicate", precum numrul estimat de iteraii la un stadiu de dezvoltare sau numrul
anticipat de modificri ale proiectelor.

12. Costul calitii software - definire, coninut i propunere de clasificaie

Conform [BAR04], costul calitii, ca parte a costului de elaborare a produsului software, reprezint
expresia bneasc a consumurilor de resurse, determinate de realizarea unui anumit nivel al caracteristicilor
de calitate, sau de mbuntire a acestora.
Cteva condiii necesare, dar nu i suficiente, pentru a garanta atingerea unui nivel de calitate dorit
(cerut, previzionat), sunt:
- existena i funcionarea unui sistem al calitii cu proceduri standardizate, cunoscute i verificate n
timp;
- o cunoatere i evaluare realist a cerinelor beneficiarilor, a posibilitilor i resurselor
productorului astfel nct s se proiecteze pentru produsul software un nivel de calitate care s ndeplineasc
cumulativ dou cerine: s asigure acceptarea fr rezerve a produsului de ctre beneficiar i s poat fi atins
respectivul nivel de calitate, cu ncadrarea n resursele planificate ale proiectului, n condiii de eficien
economic i cu posibilitatea asigurrii managementului calitii.
Prin resursele productorului se nelege ndeobte:
- resursele financiare alocate, proprii sau atrase, avnd, o anumit calitate (de exemplu disponibilitatea
sumelor de bani, operativitatea i sigurana deschiderii unor acreditive, a unor linii de credit, etc);
- cantitatea, calitatea i modul de structurare a resurselor umane (proiectani i programatori cu o
anumit experien i deci cu un anumit nivel de salarizare, dimensiunea echipelor de testare i experiena n
domeniu, calitatea i numrul personalului echipelor de QA, modul de distribuire ntre procese sau produse module de produs, documentaie - a personalului mai mult sau mai puin experimentat);
- bugetul (portofoliul) de timp i structurarea acestuia ntre procese i produse (ct i modul de alocare
a timpului pentru proiectare, codificare, inspecii ale codului, testare).
La acest tip de resurse, care sunt caracterizate prin vizibilitate i msurabilitate imediat, se mai pot
aduga i alte categorii de resurse, care, dei mai puin vizibile i msurabile, pot afecta n aceeai msur
managementul calitii: disponibilitatea beneficiarului de a se implica n realizarea proiectului, precum i
experiena acestuia n utilizarea unor sisteme informatice, nivelul general al frustrrilor de diferite naturi ce
se pot manifesta la nivelul actorilor implicai, atitudinea managementului, poziia activitii de informatic n
obiectivele organizaiei, etc.
Productorii de software cu un anumit nivel de maturitate, care au definite procesele i procedurile de
dezvoltare, estimeaz costurile de dezvoltare, inclusiv costurile unui anumit nivel sau a unor variante
alternative de calitate, pe baza unor audituri sau a unor modele de evaluare.
Dei modelele ce se vor prezenta n subcapitolul 4.3. au la baz elemente ale activitii cu ajutorul
crora se poate comensura costul efectiv al calitii pe procese sau faze de dezvoltare, datele ce se culeg din
contabilitate inspir cea mai mare ncredere pentru managementul organizaiei productoare de software.
Dificultatea evidenierii costului calitii const n faptul c munca de cuantificare a acestor costuri este
dificil. Din aceast cauz, separarea acestor costuri i inerea unei evidee analitice separate (sub aspectul
evidenei contabile, pe conturi analitice) este o problem de apreciere colectiv, a compartimentelor de
contabilitate, asigurarea calitii, a compartimentelor de dezvoltare, testare, precum i a managementului. Cu
toate acestea, datele privind costurile calitii nu se pot
extrage n totalitate direct din contabilitate, ele putnd fi determinate pe trei ci: colectarea din
documente primare, nscrierea sumelor n conturi analitice, calcule simple, utilizndu-se chei de repartizare.
Aa cum se arat n [0LA1], pentru a sugera c, n general, o mare parte a cheltuielilor cu calitatea sunt
evitabile, n literatura de specialitate se propune utilizarea termenului de "costuri referitoare la calitate", n
locul termenului de "costurile calitii".
Dei, aa cum s-a artat, exist diferene ntre industriile manufacturiere i proiectele de dezvoltare de
software, n ceea ce privete costurile, este relevant recomandarea de clasificai? coninut n standardul ISO
9004-3, [ISO4], pentru cazul produselor rezultate din procese continue (figura 4.1).

31

Costurile referitoare la calitate

Costurile realizrii calitii

Costuri de investi

Costuri de prevenire

Costuri de evaluare

Costurile de asigurare externa a

cntai

Costuri de defectare (pierderi)

Costurile defectrilor interne

Costurile defectrilor
externe

Figura 4.1. Costurile referitoare la calitate

n standardul menionat, costurile de realizare a calitii reprezentint costurile implicate de realizarea
i meninerea nivelului specificat al calitii, iar costurile de asigurare extern a calitii cuprind costurile
demonstraiilor i probelor cerute de clieni ca dovezi obiective ale calitii, ale clauzelor speciale i
suplimentare de asigurare a calitii, procedurilor, datelor, ncercrilor pentru demonstrare i evaluare..
Costurile privind calitatea produselor software refer un ansamblu de activiti care genereaz
cheltuieli ce pot fi grupate n urmtoarele categorii: (a) de prevenire, (b) de evaluare, (c) de identificare i
remediere pe parcursul dezvoltrii, (d) de remediere a defectelor (ale non-calitii). n tabelul 4.1 se prezint
o propunere de grupare a acestor costuri.
Tabelul 4.1
- costuri determinate de implementarea, funcionarea i mbuntirea
A. Costuri de
sistemului calitii (stabilirea i actualizarea standardelor interne i a
prevenire a
procedurilor de calitate);
defectelor
- costuri determinate de audituri ale calitii, de verificarea calitii
proiectelor de ansamblu i de detaliu, a documentaiilor intermediare;
- costuri legate de constituirea fluxului de control i dirijare a proceselor
i produselor n vederea asigurrii calitii;
- costuri de evaluare a subcontractanilor, costuri de remediere a unor
programe, documentaii, primite de la eventuali subcontractani;
- costuri determinate de ridicarea calificrii personalului, de motivarea
acestuia, de angajarea unor experi din exterior sau de personal cu
calificare superioar;
- costul unor procese suplimentare de verificare, de exemplu costul
B. Costuri de
inspeciilor pe codul surs, ale auditrii produselor software intermediare
evaluare
i finale;
- timpul suplimentar consumat pentru procesele de analiz a erorilor
sistematice, n vederea stabilirii cauzelor.
- costuri legate de achiziionarea, testarea, nvarea, exploatarea
C. Costuri de
produselor
utilizate n procesul dezvoltrii;
identificare i
- costuri suplimentare aprute n procesul dezvoltrii datorate
remediere, a
identificrii i remedierii unor erori la produsele intermediare (erori n
defectelor, pe
proiectare, n codificare, n elaborarea documentaiilor), evideniate, la
parcursul
intrarea i ieirea fiecrui proces, att de compartimentele de QA, ct i de
dezvoltrii
personalul de la dezvoltare software.
a. Costuri la productor
D. Costurile
- costuri suplimentare la finalul procesului de dezvoltare, determinate de
remedierii
remedierea unor erori aprute dup testarea i inspecia de calitate final
defectelor
(consumuri suplimentare de

32

Cauzele defectelor:
1 cauze datorate
produselor suport i a
produselor primite de
la subcontractani;
2 cauze hardware;
3 cauze umane;
4 cauze
metodologice
(proceduri, tehnologii
inadecvate);
5 cauze datorate unui
control defectuos;
6 cauze datorate
mediului de
desfurare a
procesului de
dezvoltare;
7 cauze manageriale;
8 mentenabilitate
redus;
9 marketing
defectuos.

timp, curent electric, hrtie, consumabile, trafic suplimentar pe liniile de

comunicaie nchiriate, etc.);
- costuri suplimentare determinate de repetarea unor teste i verificri;
- costuri determinate de nerespectarea eventualelor obligaii contractuale;
- costuri privind stingerea reclamaiilor fcute de beneficiari;
- costuri suplimentare privind service-ul comercial;
- costuri suplimentare determinate de re-pregtirea produsului pentru
livrare,
b. Costuri la beneficiar
- costuri privind remedierea erorilor la produsele reclamate de beneficiari
ca necorespunztoare s"au refuzate, n cazul m care recepia se face la
acetia (module de program, capitole de documentaie, supori magnetici,
etc);
- costuri determinate de nlocuirea produselor menionate la aliniatul
anterior;
- costuri privind testrile, controalele, expertize la produsul ajuns la
destinaie i reclamat de beneficiar;
- costuri privind activitatea de mentenan n perioada de garanie;
- costuri privind stingerea reclamaiilor pentru calitate necorespunztoare
fcute de beneficiari, n cazul n care recepia are loc la beneficiar;
- costuri determinate de daunele provocate activitii beneficiarului i
reclamate de acesta, datorit calitii necorespunztoare a produsului
software livrat.

13. Raportul cost calitate - cost total

Pe baza modalitatii de clasificaie a costurilor calitii software se poate evalua att raportul dintre
costul calitii i costul total (parte - ntreg), ct i efectul costurilor referitoare la calitate asupra
performanelor organizaiei productoare de software. Conform analizei prezentate n [0LA1] i innd cont
de specificul industriei software i de clasificaia din subcapitolul 4.1., costurile de prevenire i de evaluare
sunt considerate costuri de investiii, iar celelalte intr n categoria costurilor de producie sau a cheltuielilor
de exploatare.
Dac efectul costurilor de investiii este dificil de evaluat imediat, n cazul costurilor de identificare i
remediere a erorilor n timpul procesului de dezvoltare sau al unor costuri de remediere la productor sau
beneficiar, scderea lor va determina direct scderea costurilor de producie sau exploatare, reflectndu-se
direct n creterea profitului. n ceea ce privete relaia imediat dintre costul total i costurile de prevenire,
creterea acestora va determina cu certitudine creterea costurilor totale, chiar dac este posibil ca, pe termen
mai lung, investiiile respective (n sistemul calitii), s conduc la creterea vnzrilor i deci, la
maximizarea profitului. Deci, evaluarea efectului lor asupra performanelor financiare ale organizaiei este
ngreunat de faptul c acest efect poate fi pus n eviden doar n perioade ulterioare celei corespunztoare
exerciiului financiar curent [0LA1].
Cuantumul costurilor de evaluare poate avea un impact dublu. Astfel, pe de o parte, creterea
cheltuielilor cu inspeciile i auditurile intermediare se reflect n scderea cheltuielilor de testare i, n
general, a costurilor de identificare i remediere a erorilor n timpul procesului de dezvoltare, astfel c efectul
lor asupra costurilor referitoare la calitate poate fi nul sau chiar de reducere a acestora. Pe de alt parte,
impactul creterii acestor costuri asupra costului total nu poate determina o cretere direct proporional, ci
dimpotriv, poate avea ca efect scderea costului total.
n plus, unele costuri referitoare la calitate sunt necuantificabile (acestea, de fapt, nici nu au fost prinse
n propunerea de clasificaie prezentat). De exemplu, costul aferent pierderii unui contract, a unui client sau
a pieei, ca urmare a vnzrii unui produs necorespunztor calitativ, sau reducerea vnzrilor datorit faptului
c, prin calitatea necorespunztoare a produselor, ali productori realizeaz produse similare sau
substitueni. De asemenea, n propunerea de clasificaie prezentat, nu au fost incluse costurile de asigurare
extern a calitii, aa cum sunt ele prevzute n standardul [ISO4]. Sub aspect conceptual, aceste costuri pot
include i cheltuielile generate de participarea la trguri i expoziii, precum i cheltuielile de reclam i
publicitate. Din punct de vedere contabil, aceste cheltuieli pot fi repartizate asupra produsului, fie prin
includerea lor la stabilirea unui pre de cost, fie prin repartizarea pe baz de chei de repartiie. Fie
urmtoarele notaii:

33

Cp = costuri de prevenire
Ce = costuri de evaluare
Cd = costurile de identificare i remediere a erorilor n timpul procesului de dezvoltare +
costurile de remediere la productor i beneficiar (costurile totale de identificare i
remediere a erorilor).
Aa cum se arat n [COZI] i [0LA1], potrivit abordrii tradiionale a analizei costurilor, referitor la
corelaia cost-calitate, pe msura creterii costurilor de prevenire Cp i a costurilor de evaluare Ce, se
produce scderea costurilor Cd (figura 4.1).
Curba costurilor totale referitoare la calitate admite un minim, iar nivelul calitii corespunztoare
zonei haurate (AB) este considerat optim. Se remarc faptul c n zona respectiv Cd Cp+Ce. Zonele de
pe grafic din afara zonei optime, reprezint "zona mbuntirilor", respectiv "zona supracalitii" (figura
4.2).

Cd

Cp+Ce
A

Cd Cp + Ce

Costuri

Cp+Ce+Cd

Cost total minim

Nivelul calitii

Figura 4.1. Corelaia cost - calitate

Conform estimrilor din [COZI] i [OLA1], precum i a lucrrilor lui Juran i Gryna, n zona

Cd
Curba costurilor totale

Zona optim
Zona mbuntirilor
Cd>70%
Cp+Ce<30%

Cp+Ce
A

Cd Cp + Ce

Costuri

Cp+Ce+Cd

Zona supracalitii
Cd < 40%
Cp+ Ce > 60%

Cost total minim

Nivelul calitii

Figura 4.2. Corelaia cost - calitate

34

mbuntirilor, Cd au o pondere mai mare de 70% n totalul costurilor referitoare la calitate, iar cele de
prevenire i evaluare sub 30%. n aceast zon, printr-o cretere relativ mic a costurilor de prevenire i
evaluare (a investiiilor), se poate obine o reducere semnificativ a Cd. n zona supracalitii Cd < 40%, iar
costurile de prevenire i evaluare au o pondere mai mare de 60%. n aceast zon, conform abordrilor
clasice amintite, reducerea Cd presupune costuri din ce n ce mai mari de prevenire i evaluare.
n contradicie cu abordarea clasic prezentat mai sus, strategia mbuntirii continue (Kaizen), pe
lng faptul c nu implic investiii mari, determin obinerea a dou avantaje: 1. se poate obine creterea
nivelului calitii fr eforturi prea mari; 2. aplicnd principiul pailor mici, se asigur o mai mare stabilitate
i controlabilitate a proceselor.
n figura 4.3. se prezint evoluia costurilor totale minime, conform concepiei mbuntirii continue,
iar n figura 4. 4. se prezint efectele mbuntirii prin simplificare (sursa [0LA1]).
Costuri
Costuri
totale

Cd

Costul
total
minim
Cp+Ce

Nivelul calitii

100

Figura 4.3.

Costuri
Costuri
totale

Cd

Costul
total
minim
Cp+Ce

Figura 4.4.

Nivelul calitii

100

35

14. MANAGEMENTUL CALITII PUNTE DE TRECERE DE LA

MANAGEMENTUL INFORMAIONAL LA CEL AL CUNOTINELOR
Accesul managerilor i specialitilor la informaii multidimensionale i cunotine despre toate
activitile ntreprinderii i a mediului de afaceri este una dintre cele mai importante condiii pentru
asigurarea competitivitii n economia global modern. Generalizarea experienei acumulate n domeniul
informatizrii arat c tehnologiile informaionale, sistemele informatice sunt necesare, dar nu i suficiente
pentru asigurarea garantat a succesului activitii de baz a organizaiilor.
n ultimii ani soluiile problemei n cauz sunt examinate n cadrul unor astfel de domenii tiinifice i
practice cum ar fi: managementul informaional (MI), managementul cunotinelor (MC) i managementul
calitii (MQ). Dei aceste tipuri de management s-au dezvoltat ca direcii tiinifice i practice aparte, i nu
se mai pune la ndoial importana fiecrui din ele n parte, ca condiii necesare pentru asigurarea
competitivitii unei ntreprinderi, n ultima perioad de timp au aprut unele publicaii, n care se
menioneaz anumite interdependene ntre ele. Aceasta reiese chiar i din faptul c aceste tipuri de
management sunt examinate n acelai context ca condiii de asigurare a competitivitii ntreprinderilor. Dar,
apar i publicaii care confirm existena unor legturi mai strnse dect cele menionate. Chiar i
interdependenele unilaterale dintre oricare dou tipuri de management dintre cele enumerate anterior,
studiate n literatura de specialitate, arat c realizarea lor n cadrul aceluiai sistem de management al
afacerilor (MA) asigur condiii de sporire a eficienei fiecrui tip de management n parte.
Scopul de baz al acestui articol este analiza interdependenelor reciproce active dintre
managementul informaional, managementul cunotinelor i managementul calitii n cadrul
managementului general al aceleiai ntreprinderi, formnd un model structural integrat al sistemului de
management al afacerilor, in care sunt prezente toate aceste tipuri de management. O atenie deosebit va fi
acordat verificrii ipotezei conform creia MQ joac un rol important n realizarea interdependenelor dintre
MI i MC, care ar avea un efect sinergetic din integrarea lor reciproc.

Definiiile noiunilor de baz

Fr a pretinde la o definire a noiunilor informaie, cunotine, MI, MC i MQ mai profund, dect
mulimea de definiii diverse cunoscute n mediul de specialitate, vom accentua doar acele aspecte n
definiiile existente, care le evideniaz specificul n compararea reciproc i care ar putea influena formele
respective de management. n acest context, cele mai caracteristice aspecte ale noiunilor de baz sunt
urmtoarele: informaia este rezultatul procesri datelor; cnd informaia se mbin cu contextul i
experiena, ea se transform n cunotine. Noiunea de cunotine este mai superioar dect informaia i
documentele care o conin. Cunotinele presupun un nivel de implicare uman [1], ele sunt informaia
absorbit i neleas de persoan concret. Sunt situaii n care ceea ce pentru o persoan reprezint o
informaie pentru alta, cu o alt capacitate sau un alt rol, constituie o cunotin.
Diferena dintre informaie i cunotine, ne permite s difereniem diferite niveluri de generalizare a
informaiei cuprinse n diapazonul ntre informaie pur i simplu ca date procesate i informaie, care
corespunde tuturor cerinelor utilizatorului, fiind absorbit i neleas de persoane concrete n conformitate
cu necesitile informaionale reale, n contextul experienei personale [2].
n articolul de fa vom folosi una din cele mai cuprinztoare definiii ale MI, care include practic
toate tipurile de activitate informaional ce corespund ntregului diapazon de interpretri cunoscute ale MI
[3]: managementul informaional este planificarea, finanarea, organizarea, ncadrarea cu personal,
managementul, instruirea n domeniu i controlul informaiei. MI include managementul resurselor
informaionale variate, cum ar fi:
suporturile informaionale (documente sau medii electronice);
departamente care ofer servicii informaionale;
sisteme informaionale, att computerizate, ct i tradiionale.
Managementul informaional poate fi uor interpretat ca un termen umbrel, ce include aa
domenii ca tiina computaional (ce dezvolt instrumentarul de realizare a funciilor), managementul
dosarelor, arhivelor i bibliotecilor, precum i managementul resurselor informaionale. MI poate de
asemenea s includ telecomunicaiile, managementul datelor, managementul documentelor i
informatica n general.
Managementul cunotinelor este orice activitate structurat ce duce la sporirea capacitii
organizaiei de a dobndi, distribui i utiliza cunotine pentru supravieuirea i succesul su. MC este definit
ca administrarea profesionist a sumei sau a domeniului a tot ce a fost perceput, descoperit sau studiat n
ntreprindere prin colectarea, integrarea, organizarea, analiza i distribuirea cunotinelor de afaceri n aa

36

mod ca s fie utilizate efectiv de ctre ntreprindere pentru a efectua aciuni efective i a realiza scopurile
sale [4] .
n [3] este subliniat scopul i terenul comun al tuturor tipurilor de management: al datelor,
informaiei, cunotinelor, nregistrrilor i documentelor - ele toate au acelai obiectiv. n particular, ele tind
s gestioneze informaia ntr-un mod, care ar asigura integritatea ei i utilizarea n conformitate cu varietatea
scopurilor.
Ca proces managementul cunotinelor este ndreptat la managementul nu al documentelor propriu
zise, ci al coninutului lor. n acest context autorii [3] menioneaz c managementul cunotinelor nseamn
cptarea (colectarea, procurarea, generarea), organizarea (clasificarea, indexarea, trasarea), recuperarea
(cutarea, accesarea), distribuirea (mprirea, micarea) i meninerea (curirea, creterea, sporirea,
ngrijirea) a coninutului depozitului de date
Obiectivele managementului calitii tehnologiilor informaionale i a serviciilor informaionale
(MQ) constau n identificarea, analiza i interpretarea tuturor anomaliilor i n definirea aciunilor corective
sau de orientare a calitii n toate etapele de realizare a TI i/sau de prestare a serviciilor informaionale.

Interdependene dintre MI, MC i QM

Pentru a nelege rolul fiecrui din tipurile de management n cauz fa de celelalte este necesar de
studiat interdependenele dintre ele. Generaliznd rezultatele relevante (dei reprezentnd interdependene
unilaterale) din literatura de specialitate, se poate admite ipoteza existenei unor interdependene reciproce
dintre toate tipurile de management menionate n cadrul aceluiai sistem de management al afacerilor, care
ar avea un efect sinergetic din integrarea lor reciproc.
Printre cele mai reprezentative interdependene pot fi evideniate urmtoarele:
1) Interdependena reciproc dinte MI i MC (MI MC)
Tot mai frecvent sunt cercetate unele aspecte care confirm dependena managementului cunoaterii
de managementul informaional (MI) [2, 5, 6] i de managementul resurselor informaionale [4], precum i
de unele subsisteme aparte ale MI [1]. n [6] MI integrat, realizat n baza principiilor sistemice de integrare a
diferitor tipuri de management specializat (managementul datelor, managementul documentelor,
managementul nregistrrilor, managementul resurselor informaionale, etc.) este prezentat ca o temelie
pentru dezvoltarea MC. Succint putem prezenta aceast dependen a MC de MI n felul urmtor: MCMI.
Pe de alt parte, avnd n vedere c cunotinele sunt nite informaii cu proprieti deosebit de
importante pentru organizaie, contientizarea tipurilor de cunotine i a rolului lor n organizaie poate fi
utilizat pentru concretizarea mai profund a scopurilor i formelor de realizare a MI. O astfel de abordare
este o condiie necesar pentru eficientizarea activitilor ce in de MI. Adic, n acest sens exist i o
dependen invers dintre MC i MI (MI MC).
2) Interdependena reciproc dinte MI i MQ (MI MQ)
Exist relaii reciproce foarte puternice ntre TI i servicii informaionale i managementul total al
calitii (MTQ), care au fost cercetate nu numai teoretic, dar i practic [9]. IM este un factor foarte esenial
de suport al implementrii unui astfel de sistem ca MTQ, care necesit volume mari de informaii. Deci,
eficiena MQ depinde n mare msur de nivelul de organizare a MI n organizaia dat (MQ MI).
Pe de alt parte, implementarea MTQ n activitile de baz a unei organizaii presupune rspndirea
principiilor de MTQ asupra tuturor activitilor, care suport activitile de baz, inclusiv i asupra MI.
Totodat, o activitate multidimensional ca MI poate fi eficient organizat doar n condiii de utilizare a
elementelor de MQ, care poate fi un mecanism de mbuntire permanent a calitii datelor, soft-ului i
informaiilor (MI MQ).
3) Interdependena reciproc dintre MQ i MC (MQ MC)
De exemplu, n [7, 9] se menioneaz c, odat ce strategia orientat la calitate depinde de capacitatea
capitalului intelectual al organizaiilor de a menine competitivitatea produselor i a serviciilor, iar angajaii
n astfel de organizaii trebuie s efectueze activiti bazate pe utilizarea cunotinelor, managementul
cunoaterii devine un factor critic pentru succesul activitii companiilor, care utilizeaz sistemul MQ. Deci,
n acest context, MQ depinde n mare msur de MC (MQ MC).
Pe de alt parte, sunt menionate i dependene inverse dintre MQ i MC. De exemplu, n [8, 5, 6]
este analizat influena pozitiv a utilizrii mecanismelor de control al calitii asupra proceselor de baz ale
managementului cunotinelor.
Reieind din definiia noiunii de cunotine (ca informaie, care corespunde tuturor cerinelor
utilizatorului, fiind absorbit i neleas de persoane concrete n conformitate cu necesitile informaionale
reale, n contextul experienei personale, adic acele informaii, care corespund anumitor cerine fa de
calitate), informaiile rezultative n sistemul informatic pot fi mbuntite permanent n baza unui feedback
activ (conexiune invers) susinut de sistemul de management al calitii produselor i serviciilor

37

informaionale. Cu alte cuvinte, utilizarea principiilor de management al calitii fa de MI este o condiie

necesar pentru extragerea cunotinelor din fluxurile de informaii asigurate de MI.
Deci, MC poate fi n mare msur asigurat de utilizarea MQ fa de procesele de MI n firma dat,
ceea ce nseamn c MC depinde de MQ (MCMQ).
Astfel, pe deoparte, n firma dat managementul calitii produselor i serviciilor de baz poate fi
eficient doar pe baza cunotinelor necesare din domeniu (obinute ca rezultat al unui management al
cunoaterii). Pe de alt parte, managementul cunotinelor poate fi mai efectiv, dac este organizat pe baza
utilizrii principiilor de management al calitii, folosite fa de MI. Aceasta mrturisete despre
interdependena reciproc strns dintre aceste dou tipuri de management.
n baza generalizrii celor menionate, putem conclude c exist interdependene reciproce ntre toate
cele trei tipuri de management (MI, MQ i MC). Relaiile dintre fiecare din aceste tipuri de management i
managementul general, al afacerilor (MA) reies din nsei definiiile lor. Schema general, care reprezint
interdependenele reciproce n cauz, este prezentat n figura 7.1.
Un rol deosebit n aceast interdependen l joac MQ, care servete n calitate de punte de trecere
dintre MI i MC. Folosirea managementului calitii n procesele managementului informaional poate
transforma MI n temelie sigur pentru managementul cunotinelor.
Odat ce fiecare din tipurile enumerate de management contribuie la eficientizarea celorlalte tipuri,
putem conclude c un efect maximal al influenei lor la eficiena managementului afacerilor poate fi obinut
doar prin realizarea lor n paralel ca subsisteme, care interacioneaz n cadrul aceluiai sistem de
management al afacerilor.

Managementul afacerilor
(MA)

Managementul
cunotinelor
(MC)

Managementul
informaional (MI)
Sistemul informaional
managerial (SIM)

Managementul calitii
(MQ)
TI i serviciilor
informaionale

Figura 7.1. Schema interdependenelor dintre diferite

forme de management: MA, MC, MI (SIM) i MQ

Concluzii
Dei mai multe forme de management (informaional, al cunoaterii, al calitii tehnologiilor i
serviciilor informaionale etc.) se dezvolt n literatura de specialitate ca direcii aparte, la ora actual sunt
observate unele elemente de convergen dintre ele. Prin urmare, este necesar studierea mai profund a
interdependenelor dintre aceste direcii, cu att mai mult c ele se intersecteaz din punct de vedere a
scopului i terenului comun al tipurilor respective de management.
Interdependenele reciproce dintre formele de management n cauz, discutate n articolul de fa,
sunt generalizate i prezentate ca subsisteme ale sistemului de management al afacerilor.
Generaliznd cele menionate n lucrare, putem conclude c un sistem de management al afacerilor,
bazat pe o strategie integrat, orientat la MTQ, poate fi eficient cu adevrat doar n condiiile dac
realizeaz toate dimensiunile de management (cel informaional, al cunoaterii i al calitii) conjugate ca
subsisteme ale unui singur sistem de management al afacerilor cu un scop final comun (figura 7.2). O astfel

38

de abordare a problemei contribuie la sporirea nu numai a eficienei fiecrui tip de management aparte, dar i
a efectului sinergetic cauzat de interaciunea lor reciproc n cadrul sistemului de management al firmei .

Organizaia (ntreprinderea)
Managementul afacerilor
(MA)

Managementul
total al calitii
produselor i
serviciilor
(MTQ)

Managementul
cunoaterii (MC)
Managementul
informaional
(MI)
Managementul
calitii TI i SIM

Sisteme informatice
manageriale (SIM),
Tehnologii
informaionale (TI)
n managementul
afacerilor

Utilizatori
externi
ai SIM, TI

Parteneri
n schimb
de date

Sistemul informatic
al managementului
total al calitii

Procesul de producere
i prestare servicii

Consumatorii
de produse
i servicii

Figura 7.2. Model structural - funcional al sistemului de management al afacerilor,

n care n calitate de subsisteme sunt realizate MI, MC i MQ

15. Abordarea sistemic a problemei pregtirii cadrelor n domeniul managementului informaional

Informatica este unul din cele mai dinamice domenii ale tiinei i practicii moderne. Dezvoltarea
continu a informaticii condiioneaz modificri respective i n activitile profesionitilor informaticieni.
Dei, n linii mari specialitii, care practic diferite activiti cu datele, informaia, cunotinele, nregistrrile
i documentele au aceleai obiective (n particular, ei caut s gestioneze informaia ntr-un mod, care ar
asigura integritatea si folosirea la o varietate de scopuri), dezvoltarea accelerat a tehnologiilor
informaionale (TI) schimb permanent hotarele dintre multe profesii specifice i chiar natura (sensul) lor.
Un rol aparte n acest context l au unele probleme de convergen a tehnologiilor informaionale,
care dup cum a fost observat n [1], contribuie la apariia noilor profesii, n special ale celor de manageri
informaionali. Convergena n mediul cnd totul devine digital, tergnd distinciile dintre documentele
tiprite, vizuale, audio- i multimedia, duce la confluena disciplinelor i a activitilor profesionale
respective. Din toate acestea rezult c problemele de pregtire a specialitilor n domeniul informaticii, care
ar corespunde cerinelor moderne ale societii, trebuie s fie permanent n atenia instituiilor abilitate n
domeniu.
Scopul comunicrii de fa const n formularea unor probleme ce in de abordarea sistemic a
dezvoltrii programelor de studii i de pregtire a specialitilor n domeniul managementului informaional
(MI) n conformitate cu necesitile societii informaionale.
Crearea unui spaiu informaional unic al societii prezint o problem foarte complex, care nu
poate fi soluionat eficient fr un management informaional bine organizat la toate nivelurile de ierarhie
supuse informatizrii (ntreprindere, asociaii, subramuri, ramuri ale economiei naionale, societate). Nu
ntmpltor managementul informaional a devenit una din cele mai frecvente noiuni utilizate n mediul
informaticii. n acelai timp, se observ o mare varietate de abordri ale acestei probleme la nivel naional
(inclusiv nivelul micro i macro al societii), internaional i global [1,2]. Aceast situaie este reflectat de

39

diversitatea interpretrilor termenului conceptual managementul informaional: de la nelegerea lui n cel

mai ngust sens al cuvntului (ca sinonim al tehnologiei informaionale, uneori nsemnnd doar organizarea
datelor n memoria computerului -managementul datelor), pn la cel mai larg sens al MI, care cuprinde
practic toate tipurile de activitate informaional.
O astfel de varietate de interpretri ale noiunii MI influeneaz n mod direct i formele de realizare a
MI, reflectndu-se inclusiv i asupra pregtirii specialitilor n domeniul managementului informaional,
unde se observ cam aceeai diversitate de abordri. Simind necesitatea societii, mai multe instituii de
nvmnt superior, au nceput s pregteasc cadre n domeniul managementului informaional, dar
netiind prea clar, cum ar trebui s fie aceti specialiti i ce ar trebui s cunoasc. n unele universiti sunt
predate discipline noi sub denumirea de Management informaional, iar n altele a aprut chiar
specializarea n acest domeniu. Dar n majoritatea cazurilor accentul n programele de nvmnt e pus pe
unele aspecte foarte nguste ale MI, neglijnd n majoritatea cazurilor competene importante care trebuie s
fie formate la respectivii specialiti.
n acest context, sunt necesare noi cercetri n teoria i practica mondial n acest domeniu: n
pregtirea specialitilor informaticieni, n general, i n pregtirea managerilor informaionali, n particular.

Tendinele de baz n dezvoltarea MI ca factori de influen n formarea

specialitii Managementul informaional
Managementul informaional a devenit o problem odat cu apariia societii i a fluxurilor eseniale
de informaii. Dar ca domeniu important al tiinei i practicii a nceput s se dezvolte accelerat doar n
ultimele 2 decenii n rezultatul dezvoltrii rapide a tehnologiilor informaionale i a modificrii continue i
semnificative a profesiilor informaionale respective. Analiza experienei acumulate n domeniu [3,4] ne
permite s facem concluzi c pentru asigurarea unui MI eficient este necesar n primul rnd o structurare
mai strict a mediului de aplicare, o formulare exact a conceptelor de baz i a corelrii lor reciproce n
cadrul sistemului. Cu att mai mult acestea sunt necesare n cazul pregtirii cadrelor n acest domeniu de MI,
avnd ca scop asigurarea plenitudinii funcionale a sistemului de management informaional, pe deoparte, i
reducerea redundanei nejustificate, pe de alt parte.
n [5-7] n baza generalizrii experienei acumulate n domeniul informatizrii societii au fost
evideniate urmtoarele direcii de baz ale dezvoltrii MI, care reprezint ambele extreme reprezentative ale
diapazonului de interpretri ale acestei noiuni:
MI n sensul tehnologic, condiionat de coala informatic, cnd centrul de greutate n sensul
MI l au tehnologiile informaionale i sistemele informatice ca instrumentar de soluionare a
multor probleme ce in de organizarea fluxurilor informaionale;
MI n sensul tradiional al noiunii de management, cnd resursele informaionale sunt tratate
ca toate celelalte resurse materiale, energetice, umane etc., iar MI este interpretat din punct de
vedere al funciilor de dirijare: planificare, eviden, organizare, etc.
n direcia tehnologic a managementului informaional sunt evideniate numeroase subdirecii,
principalele dintre ele fiind urmtoarele:
Managementul datelor, care include proiectarea, crearea, implementarea i administrarea
bazelor de date;
Proiectarea, crearea, implementarea i administrarea sistemelor informatice n procesul
exploatrii lor;
Managementul documentelor, care cuprinde etapele de proiectare, elaborare, exploatare i
administrare a sistemelor informatice documentare;
Managementul nregistrrilor, orientat la proiectarea, elaborarea i exploatarea sistemelor
informatice de organizare i procesare a documentelor care reflect tranzacii economice;
Managementul cunotinelor, care include identificarea, acumularea, organizarea i utilizarea
cunotinelor n procesele de dirijare.
Aria de influen a acestui tip de management informaional n sens tehnologic este prezentat
ntr-un ir de lucrri de un model structural funcional integrat (figura 8.1)
Tratarea tradiional a MI este mai mult sau mai puin fr contradicii n literatura de specialitate.
Anume n acest context este mai clar interpretarea MI ca parte component a managementului general al
proceselor, ce au loc n unitile social-economice (USE) de diferite niveluri de ierarhie, ca subsistem care
trebuie s creeze condiii optime pentru a contribui la realizarea scopului i produsului final al USE.
n [6,7] este argumentat necesitatea crerii unui spaiu informaional integrat, care reflect adecvat
toate procesele ce au loc n sistemul real, i poate asigura condiii pentru extragerea cunotinelor necesare
pentru managementul efectiv al USE-

40

Managementul Cunotinelor

Managementul Informaional

Fig. 8.1. Modelul structural al managementului informaional

Pot fi evideniate dou grupe de probleme, care devin actuale n contextul temei abordate:
1) probleme de integrare n cadrul fiecrui tip de management. Aici orientarea trebuie s fie la
abordarea sistemic, n primul rnd la cuprinderea ciclului ntreg de via a resurselor informaionale
(care include toate etapele de la apariia lor pn la trecerea n stare pasiv dup utilizare, de exemplu,
n arhive), att n forma electronic, ct i pe supori tradiionali;
2) probleme de integrare ntre nivelurile i tipurile de management referitor la date, informaii,
cunotine, documente, arhive (figura 8.1). n ultima perioad de dezvoltare a managementului
informaional au nceput s ia amploare unele direcii noi de MI, bazate pe integrarea tipurilor de MI
deja existente, cum ar fi: managementul datelor cu managementul documentelor, managementul
documentelor cu managementul nregistrrilor.
n ultimii 10 ani a nceput s se dezvolte un nou tip de management (managementul calitii
tehnologiilor i serviciilor informaionale), care se intersecteaz esenial cu soluionarea problemelor MI n
sensul larg al cuvntului. Managementul calitii n acest domeniu reprezint un exemplu de convergen a

41

diferitor tipuri de MI, care este bazat pe mbinarea aspectelor caracteristice pentru ambele extreme de
interpretare a MI: manageriale i tehnologice.
n aceleai lucrri [6,7] este argumentat concluzia c integrarea tuturor formelor de MI bazat pe
utilizarea managementului calitii tehnologiilor i serviciilor informaionale este condiia fundamental a
dezvoltrii celei mai moderne forme de management informaional: managementul cunotinelor . n mod
generalizat cele menionate despre tipurile i direciile de dezvoltare a MI pot fi prezentate n figura 8.2, care
reprezint o structurare a domeniului integrat de MI i totodat un cadru de orientare pentru cercetaredezvoltare a MI, dar mai ales, pentru pregtirea cadrelor n domeniul MI.

Necesitatea unui cadru de formare profesional n domeniul MI

Din cele menionate mai sus referitor la multidimensionalitatea MI, convergena continu a diferitor
tipuri de MI (n sensul tehnologic i tradiional al noiunii) putem conclude c pregtirea cadrelor n acest
domeniu este o problem complex i cere o atenie permanent din partea instituiilor de nvmnt
superior. n primul rnd, este necesar un cadru general de orientare pentru programele de nvmnt n
domeniu. Totodat programele de formare profesional n MI trebuie s fie bine coordonate cu programele
de specializare n toate celelalte subdomenii ale informaticii n vederea excluderii redundanei nejustificate.
Managerii informaionali trebuie s aib o viziune larg, bazndu-se pe o abordare sistemic a
problemelor complexe[3]. Ei trebuie s aib un spectru mai larg de cunotine care s le permit s cuprind
mai multe aspecte ale tehnologiilor informaionale, pe de o parte, ale managementului informaional (inclusiv
managementul cunotinelor), managementul calitii n sisteme informatice i managementului general (al
afacerilor), pe de alt parte.
A devenit o problem major pregtirea specialitilor de sistem de nalt calificare, capabili s
ndeplineasc individual lucrri complexe viznd elaborarea noilor tehnologii informaionale, a sistemelor
informatice ce in de infrastructura informaional de baza a societii. Cel mai acut aspect al acestei

Managementul general al USE

Managementul cunotinelor

Managementul informa ional

Managementul informaional n sensul

ngust, condi ionat de coala informatic

Tehnologiile informaionale ca instrumentar

de soluionare a problemelor ce in de
organizarea fluxurilor informaionale

Managementul datelor,
Managementul documentelor,
Managementul informaional,
Managementul cunotinelor

Managementul informaional n sensul

condiionat de coala de management

Planificarea, finanarea, organizarea,

ncadrarea cu personal, managementul,
instruirea n domeniu i controlul informaiei

Managementul resurselor informaionale:

supor ii informaionali (docum ente, medii

electronice);
departamente, care ofer servicii informa ionale;
sisteme informaionale computerizate i
tradi ionale, etc.

Managementul calitii n sisteme informatice

Fig. 8.2. Structura conceptual a managementului informaional i al cunotinelor

42

probleme este pregtirea managerilor de proiect, de sistem si, n general, a specialitilor n domeniul MI.
Activitatea specialitilor informaticieni se desfoar ntr-un mediu foarte dinamic sub influena
multiplilor factori care se schimb n permanen. Toate acestea condiioneaz un ir de cerine fa de
informaticieni (n special pentru specialitii de sistem) i, respectiv, fa de sistemul de formare a lor.
n Academia de Studii Economice a fost acumulat anumit experien n pregtirea cadrelor n
domeniul Managementul informaional n cadrul ciclului 1 (licen) i a ciclului 2 (masterat). Avnd n
vedere necesitatea acoperirii integrale a dimensiunilor menionate anterior ale domeniul de MI, programul de
specializare n MI (ciclul 2-masterat) prevede o orientare a studiilor nu att la acumularea de cunotine
concrete (care n mod accelerat se nvechesc), ct la dezvoltarea capacitilor de gndire sistemic i
actualizarea permanent a acestora n procesul activitii practice, conform evoluiei progresului tehnicotiinific n domeniu.
Din acest motiv, programul de studii include pe lng disciplinele privind aspectele concrete ale
tehnologiilor informaionale (care presupun nsuirea mijloacelor i instrumentarului: afaceri electronice,
proiectarea sistemelor informatice, baze de date, reele informatice, tehnologii de procesare, etc., studiate n
mare parte la ciclul 1), i discipline orientate la o pregtire teoretic fundamental, la formarea unei culturi
profesionale adecvate si a gndirii sistemice, discipline necesare pentru rezolvarea optim a problemelor de
informatizare complexe (managementul cunotinelor, managementul calitii produselor i serviciilor
informaionale, gestiunea proiectelor informatice etc.), care apar permanent intr-un mediu dinamic (figura
8.3). n acest context, n programul de studii sunt prezente i aa discipline opionale ca: analiza sistemic,
cibernetica proceselor economice, inteligena artificial, sisteme suport pentru decizii, etc.
Analiznd primele rezultate a celor 2 ani de pregtire a specialitilor n MI, considerm c programul
de studii al ASEM ar putea fi pus la baza crerii unui cadru general de orientare pentru programele de
nvmnt n domeniu pentru alte universiti din Moldova

43

MI de nivel superior
Managementul cunotinelor
Managementul calitii
produselor i serviciilor informatice
(supuse managementului informaional)

Managementul informaional
MI aspecte traditionale i mixte:
Gestiunea proiectelor informatice
Economia serviciilor informatice
Gestiunea securitii informatice

Instrumentare de realizare a MI i MC:

Tehnologii avansate de reea
Tehnologii de programare
Procesarea limbajului natural,
etc.

MI aspecte tehnologice:
Sisteme informatice financiar-contabile
Afaceri electronice
ndeplinirea i susinerea tezei de masterat, etc.

MI aspecte tehnologice concrete,

insusite la ciclul1:
Proiectarea sistemelor informatice,
Baze de date, Retele informatice,
Tehnologii de procesare a informatiei
Programarea calculatoarelor,
Sisteme de operare, etc.

Grupa de discipline opionale:

Teoria sistemelor, Programarea ERP, Cibernetica proceselor economice,
Limbaje de modelare, Inteligen artificial,
Sisteme suport pentru decizii, Integrarea aplicaiilor Windows,
Fiabilitatea sistemelor informatice, etc.

Figura 8.3. Structura programului de formare profesional n domeniul MI

Concluzii
Din cercetrile efectuate [3-7] i din experiena acumulat n Academia de Studii Economice din
Moldova pot fi extrase unele concluzii, principalele dintre care sunt urmtoarele:
1) Programele de nvmnt orientate la formarea specialitilor n domeniul managementului
informaional trebuie s aib la temelie o abordare sistemic a problemei. La baza trebuie s fie
sistematizarea activitilor informaionale la toate nivelurile de ierarhie n societate i generalizarea celor mai
moderne teorii i experiene acumulate n informatic;
2) Este necesar elaborarea unui cadru naional de formare profesional a specialitilor n
managementul informaional, n care ar fi determinat conceptul de management informaional, dat
descrierea specialitii i reglementate disciplinele (unitile de cursuri) obligatorii n programele respective
de studii;
3) Avnd n vedere dinamismul accelerat al informaticii, pentru perfecionarea sistemului de pregtire
a specialitilor n domeniu sunt necesare:
efectuarea permanent a cercetrilor impactului schimbrilor n domeniul tehnologiilor
informaionale asupra specialitilor informatice;
perfecionarea curriculum-urilor specialitilor informaionale (i nu numai) n contextul
dezvoltrii Societii Informaionale.