UNIVERSITATEA „ALEXANDRU IOAN CUZA” IAŞI

FACULTATEA DE ECONOMIE ŞI ADMINISTRAREA AFACERILOR

SPECIALIZAREA: INFORMATICĂ ECONOMICĂ

FACTORI DE SUCCES ÎN DEZVOLTAREA

SISTEMELOR INFORMAŢIONALE

Coordonator, Absolvent,
Prof. univ. dr. Florin DUMITRIU Cristina CULER
 2008
CUPRINS

INTRODUCERE.......................................................................................................................3
CAPITOLUL 1: ASPECTE GENERALE PRIVIND DEZVOLTAREA SISTEMELOR
INFORMAŢIONALE................................................................................................................4
1.1 Arhitectura sistemelor informaţionale.............................................................................4
1.2 Strategii ale definirii arhitecturii sistemului informaţional..............................................5
1.3 Strategii ale dezvoltării unui sistem informaţional........................................................8
1.3.1 Strategia descompunerii funcţionale (orientate-funcţii).........................................10
1.3.2 Strategia fluxurilor de date (orientate-proces).......................................................11
1.3.3 Strategii orientate spre informaţii (orientate-date)..................................................12
1.3.4 Strategii orientate-obiect........................................................................................13
1.4 Etapele realizării unui sistem (produs) informaţional....................................................15
1.5. Participanţi la dezvoltarea sistemelor informaţionale...................................................16
CAPITOLUL 2: FACTORI CARE INFLUENŢEAZĂ DEZVOLTAREA SISTEMELOR
INFORMAŢIONALE..............................................................................................................22
2.1 Influenţe şi beneficii ale utilizării CMMI (Capability Maturity Model Integration) în
îmbunătăţirea proceselor de lucru........................................................................................22
2.2 Gradul de schimbare .....................................................................................................25
2.2.1 Îmbunătăţire continuă vs. restructurare...................................................................25
2.2.2 Managementul schimbării.......................................................................................26
2.3 Factori referitori la utilizatori ce au influenţă asupra succesului dezvoltării sistemelor
informaţionale......................................................................................................................27
2.3.1 Factori referitori la utilizatori..................................................................................27
2.3.2 Analiza interacţiunii factorilor referitori la utilizatori .......................................29
2.4 Standarde şi calitate.......................................................................................................30
2.5 Utilizarea instrumentelor de tip CASE (Computer-Aided Sofware Engineering).........31
2.6 Dezvoltarea orientată-obiect a sistemelor .....................................................................32
2.7 Dezvoltarea “agilă” a sistemelor....................................................................................34
2.7.1 Principiile din spatele metodelor agile ...................................................................34
2.7.2 Compararea metodelor agile cu alte metode...........................................................35
2.7.3 Critici aduse metodelor agile .................................................................................37
2.8 Eşecul proiectelor de dezvoltarea a sistemelor informaţionale......................................37
2.8.1 Definirea noţiunii de eşec a proiectelor..................................................................38
2.8.2 Factori care cauzează eşecul dezvoltării sitemelor informaţionale.........................40
CAPITOLUL 3: INFLUENŢA TESTĂRII ASUPRA SUCCESULUI DEZVOLTĂRII
SISTEMELOR INFORMAŢIONALE....................................................................................41
3.1 Aspecte generale cu privire la organizarea testării........................................................42
3.2 Tehnici de testare...........................................................................................................44
3.2.1 Testare pre-implementare.......................................................................................45

2
 3.2.2 Clasificarea tehnicilor de testare.............................................................................46
3.2.3 Testarea structurilor de control repetitive...............................................................48
3.2.4 Examinările şi execuţiile de probă..........................................................................49
3.3 Strategia testării sistemelor informaţionale...................................................................49
3.3.1 Testarea modulelor..................................................................................................50
3.3.2 Testarea integrării...................................................................................................51
3.3.3 Testarea la nivelul sistemului..................................................................................52
3.4 Alte tipuri de testare.......................................................................................................53
3.5 Testare manuală vs. testare automată.............................................................................53
3.5.1 Compararea testării manuale cu testarea automată.................................................54
3.5.2 Avantajele utilizării testării automate.....................................................................55
3.5.3 Procesul testării automate.......................................................................................56
3.5.4 Limitele testării automate.......................................................................................57
3.6 Documentarea testării....................................................................................................58
CAPITOLUL 4: TESTAREA UNITARĂ A CLASELOR JAVA FOLOSIND
UTILITARUL JUNIT..............................................................................................................61
4.1 JUnit – cadru de testare unitară regresivă......................................................................61
4.2 Crearea testelor utilizând JUnit......................................................................................62
4.3 Exemplu de testare folosind Junit .................................................................................65
4.4 Recomandări pentru realizarea testelor cu JUnit...........................................................77
CONCLUZII........................................................................................................................79
Bibliografie..........................................................................................................................81

INTRODUCERE

În noua economie, producătorii de soluţii IT sunt confruntaţi cu o nouă cerinţă care îi

obligă să schimbe total modul de construcţie a unui produs, fără a face compromisuri de
calitate. A fi primul pe piaţă cu ultimele tehnologii este mai important ca oricând. Lucrând cu
o infrastructură software şi hardware din ce în ce mai complexă, confruntaţi cu creşterea
continuă a cerinţelor de calitate şi cu necesitatea reducerii costurilor, firmele dezvoltatoare de
sisteme informaţionale încep să preţuiască tot mai mult soluţiile solide de dezvoltare.
Această lucrare urmăreşte să identifice o parte din factorii care contribuie la
menţinerea echilibrului în cadrul triunghiului cost-durată-performanţă.
Primul capitol al lucrării se doreşte o trecere în revistă a câtorva noţiunii generale cu
privire la ceea ce semnifică dezvoltarea unui sistem informaţional: caracterizarea noţiunii de
arhitectură a unui sistem informaţional şi orientările abordate în definirea acesteia, strategiile
de dezvoltare a unui sistem informaţional, etapele ciclului de viaţă, precum şi principalii
actori implicaţi în dezvoltarea unui produs informaţional.

3
 Următoarea secţiune prezintă câţiva dintre factorii cheie, care pot avea o importanţă
majoră în ceea ce priveşte succesul dezvoltării sistemelor informaţionale. Printre aceştia se
pot enumera: utilizarea CMMI (Capability Maturity Model Integration) în îmbunătăţirea
proceselor de lucru, gradul de schimbare ce este asociat cu implementarea unui nou proiect,
abilităţi ridicate cu referire la managementul schimbării, implicarea utilizatorilor în procesul
de dezvoltare, supravegherea respectării anumitor standarde de calitate, folosirea
instrumentelor de tip CASE (Computer-Aided Sofware Engineering) şi a metodelor “agile”,
dezvoltarea aplicaţiilor pe baza abordării orientate-obiect. Tot aici se va dezbate şi problema
eşecului proiectelor de dezvoltare a sistemelor informaţionale.
Al treilea capitol descrie unul din factorii esenţiali ai dezvoltării sistemelor, dar care
de multe ori este ţinut în umbră sau chiar trecut cu vederea: testarea. Pentru a caracteriza
acest concept s-au evidenţiat principalele tehnici de testare, strategiile ce pot fi adoptate, o
comparaţie între testarea manuală şi cea automată, precum şi documentele ce sunt necesare a
fi elaborate în decursul procesului de testare.
Ultima secţiune este constituită dintr-un studiu de caz pe tema testării unitare a
claselor Java folosind utilitarul Junit.

CAPITOLUL 1: ASPECTE GENERALE PRIVIND

DEZVOLTAREA SISTEMELOR INFORMAŢIONALE

Dat fiind faptul că lumea se află intr-o continuă schimbare, firmele sunt stimulate să
caute mereu noi soluţii care să aibă menirea de a obţine informaţii cât mai eficient. Din
această cauză, sistemul informaţional trebuie să fie supus unor schimbări continue, fie că ele
sunt sub forma unor unor mici adaptări, unor modificări esenţiale sau chiar presupun
substituirea sistemului.
Necesitatea efectuării schimbărilor apare din unul din motivele: întregul sistem de
care aparţine face parte dintr-un plan major de modernizare, transformarea unor
funcţionalităţi de bază, decizia modificării obiectivelor strategice ale firmei, îmbunătăţirea
performanţelor sistemului, valorificarea beneficiilor aduse de tehnologiile de ultimă
generaţie.

1.1 Arhitectura sistemelor informaţionale

4
 Arhitectura sistemului informaţional reprezintă soluţia generică privitoare la
procesele de prelucrare a datelor ce trebuie să se realizeze şi modul de integrare a datelor şi
prelucrărilor. Această soluţie cadru este urmarea sintetizării răspunsurilor la următoarele
întrebări:
− Care sunt componentele sistemului informaţional?
− Cum sunt legate aceste componente şi cum interacţionează ele?
− Ce date se culeg?
− Unde se culeg datele, unde se stochează şi prelucrează?
− Ce date se transmit către diferitele componente ale sistemului informaţional?
Altfel spus, arhitectura reprezintă "soluţia constructivă" a sistemului informaţional şi
reflectă viziunea strategică managerială asupra modului în care organizaţia (firma) lucrează.
Sistemul informaţional global al firmei se descompune în subsisteme, fiecare dintre
acestea acoperind un domeniu de activitate distinct.
La rândul său, fiecare subsistem se descompune în aplicaţii fiecare dintre acestea
acoperind o activitate distinctă în cadrul domeniului. De exemplu, subsistemul informaţional
pentru domeniul comercial se va descompune în aplicaţii distincte pentru fiecare din
următoarele activităţi: aprovizionare, desfacere, marketing.
Procesul de descompunere continuă şi în pasul următor pentru fiecare aplicaţie se vor
defini proceduri realizând funcţii distincte în cadrul aplicaţiei (exemplu: proceduri pentru
dirijarea prelucrărilor, proceduri pentru actualizarea bazei de date, proceduri pentru
consultarea bazei de date). La rândul lor, procedurile se descompun în module. Acestea
cuprind secvenţe de cod realizând câte o funcţie distinctă în cadrul procedurii. De exemplu,
o procedură de actualizare a bazei de date va cuprinde: un modul pentru adăugare de
înregistrări, un modul de modificare a tuplurilor, un modul de ştergere a tuplurilor.

1.2 Strategii ale definirii arhitecturii sistemului informaţional

În funcţie de modalitatea de abordare a realizării sistemului informaţional, s-au

cristalizat în timp trei strategii1:
 strategia descendentă (top-down);

1
Stanciu V., Sisteme informaţionale de gestiune, Tribuna Economică Bucureşti, 1999, consultat pe
www.tribunaeconomica.ro în data de 22 martie 2008, la ora 15:33.

5
 strategia ascendentă;
 strategia mixtă.
Strategia top-down este cea mai răspândită modalitate de descriere a situaţiei
curente a organizaţiei prin care se urmăreşte determinarea cerinţelor informaţionale ale
unităţii. Se începe cu o analiză mai profundă a misiunii organizaţiei, a obiectivelor ei şi a
strategiei, pentru a stabili cu exactitate informaţiile necesare atingerii obiectivelor. Strategia
presupune o puternică implicare a top-managerilor.
Strategia descendentă (top-down) are la bază principiul modularităţii şi
constă în descompunerea succesivă a unui sistem complex de sus în jos pâna la un nivel de
module elementare. Descompunerea urmăreşte structura funcţională a sistemului şi se
finalizează în identificarea arborelui structurii sistemului cu definirea modulelor
funcţionale pe fiecare nivel ierarhic si a legăturilor dintre acestea oferind o descriere a
fiecărei componente a sistemului.
Prin această abordare, sistemul informaţional dobândeşte o structură ierarhic
modulară în care fiecare componentă îndeplineşte o anumită funcţionalitate şi va fi
coordonată în funcţionarea sa de componentele plasate la nivelul ierarhic imediat superior.
Rezultă că această strategie se aplică în cazul sistemelor informaţionale
complexe, vizând o arie largă de cuprindere (de exemplu: sistemul informaţional al
CCR, sistemul informaţional al unei bănci, sistemul informaţional al Ministerului Finanţelor,
etc).
Se asigură astfel realizarea unei soluţii globale, unitare la nivel conceptual pentru
întregul sistem, componentele acestuia urmând să fie proiectate si realizate independent
(pe baza unei planificări), priorităţile fiind fixate în funcţie de opţiunea beneficiarului sau
importanţei respectivelor componente şi conexiunilor necesare în cadrul sistemului global.
Pe măsura realizarii componentelor din arhitectura generală a sistemului
informaţional acestea se vor testa şi apoi integra în produsul final a cărui funcţionalitate va
fi de asemenea verificată. Se poate realiza trecerea în exploatare a componentelor finalizate
urmând ca integrarea acestora în sistemul informaţional global să se realizeze în timp.
Aplicarea unei astfel de strategii impune un efort deosebit atât în perioada de analiză
(fiind necesară o analiză complexă şi foarte amanunţită având în vedere complexitatea

6
proceselor informaţionale supuse informatizării) cât şi de proiectare şi realizare, ceea ce
impune eforturi financiare deosebite.
În procesul integrării componentelor în cadrul sistemului informaţional global nu vor
apărea probleme deosebite ca urmare a strategiei unitare de proiectare si realizare definită la
demararea proiectului. Integrarea se va realiza din treaptă în treaptă pornindu-se de la
componentele elementare (cu gradul cel mai mare de detaliere).

Sistem informaţional

Subsistem 1 Subsistem 2 Subsistem n

Aplicaţie 1 Aplicaţie n Aplicaţie 1 Aplicaţie n

Procedură 1 Procedură n Procedură 1 Procedură n

Sursa: Prelucrare după Stanciu V., Sisteme informaţionale de gestiune, Tribuna Economică Bucureşti,
1999, consultat pe www.tribunaeconomica.ro în data de 22 martie 2008
Fig. 1.1 Ilustrarea strategiei descendente

Avantajele acestei metode faţă de altele sunt prezentate în Tabelul 1.1.

Tabelul 1.1 Avantajele strategiei top-down

Tip avantaj Descriere

Perspectivă mai largă
Integrare mai bună
Sprijin managerial mai bun
Dacă n-ar fi văzută în primul rând de sus, organizaţia ar fi
considerată ca un sistem informaţional lipsit de imagine de
ansamblu.
Dacă nu ar fi văzut pe ansamblu (de sus), sistemul informaţional
ar fi unul nou, ăi nu unul integrat în cel existent.
Dacă n-ar fi implicaţi factorii de decizie de pe nivelul superior,
planificarea sistemului informaţional ar avea mai puţine şanse de

7
 reuşită.
Înţelegere mai bună Daca nu s-ar vedea unitatea de sus, ar creşte tendinţele de
abordare a unor componente izolate ale acesteia.

Strategia ascendentă (botton-up)2 este opusă metodei top-down,

având la bază principiul agregării şi constă în identificarea de jos în sus a componentelor
unui sistem şi asamblarea succesivă a modulelor definite pe diferite nivele ierarhice şi a
relaţiilor dintre acestea astfel încât se ajunge la un singur modul corespunzător sistemului.
Combinată cu metoda ascendentă a condus la „strategia mixtă” care îmbină
elemente de la ambele promovează iniţiativa la nivelul fiecărui domeniu de gestiune.
Această strategie presupune identificarea problemelor organizaţiei şi a posibilităţilor oferite
pentru definirea proiectelor. Se dezvoltă soluţii informaţionale la nivelul fiecărui domeniu
de gestiune (contabilitate, comercial, producţie etc.) fără a exista o soluţie cadru şi o
arhitectură definită pentru sistemul informaţional global la nivel de organizaţie.
Sistemele de gestiune se realizează şi exploatează independent pe măsura finalizării
lor, răspunzând cerinţelor de gestiune ale domeniilor pentru care au fost realizate, urmând ca
ulterior să se treacă la integrarea acestora în cadrul sistemului informaţional global al
organizaţiei. Metoda cere un timp mai scurt si este mai ieftină, având avantajul de a se şti cu
exactitate problemele cu care se confruntă unitatea. Datorită lipsei unei strategii unitare în
plan hardware si software, a unei soluţii unitare de proiectare şi realizare există riscul unui
grad redus de integrare a subsistemelor de gestiune cuprinse în cadrul sistemului
informaţional al organizaţiei. Ca dezavantaj se consideră lipsa unui punct de vedere de
ansamblu, la nivel de unitate.
Strategia mixtă reprezintă o combinare a strategiei descendente cu strategia
ascendentă reţinându-se punctele lor forte. În această abordare se optează pentru o definire
a componentelor sistemului informaţional în conformitate cu cerinţele strategiei descendente,
urmând ca proiectarea, realizarea şi integrarea acestor componente să se realizeze urmând
cerinţele strategiei ascendente.

1.3 Strategii ale dezvoltării unui sistem informaţional

2
Lungu, I., Sabău, Gh., Bodea, C., Surcel, Tr., - Sisteme informaţionale pentru conducere, Ed. SIAJ,
1994.

8
 Considerăm că dacă s-ar porni de la conceptul filosofic de
“Existenţă Fundamentală”, ceea ce DeMarco numea „forma solidului" - cu
trimitere la obiectele palpabile - ajungem la Substanţă, Energie,
Informaţie3. Informaţia este văzută de DeMarco, în 1982, ca fiind posibil de abordat prin
trei perspective specifice sistemelor informaţionale sau prin trei dimensiuni: date, funcţii,
comportament.
Datele sunt surprinse prin prisma structurii lor sub forma de atribute şi înseamnă,
de fapt, ceea ce sistemul are stocat şi-şi poate „reaminti" oricând despre fenomenele sau
procesele studiate. Ele reflectă structura statică a sistemului informaţional.
Funcţiile scot în evidenţă, în mod limitat, ceea ce face sistemul. Ele pot fi văzute
şi ca procese, întrucât elementele sistemului despre care se păstreaza datele de rigoare sunt
supuse unor transformări funcţionale, prin intermediul proceselor.
Comportamentul este invocat pentru a reda o altă modalitate de percepţie a
sistemului, tot limitată, pentru surprinderea stărilor comportamentale prin care acesta ar
trece, reliefându-se influenţa evenimentelor, ceea ce ar sugera dinamica lui.
Pornind de la aspectul tridimensional al sistemelor informationale, se poate afirma că
acestea pot fi axate pe una, două sau toate cele trei dimensiuni, ceea ce îndreptăţeşte pe
Whitmire4 să spună că, atunci când aplicaţiile sunt net dominate de una dintre cele trei
dimensiuni, ele sunt data-strong, function-strong sau control-strong. Tot el adaugă că, atunci
când dimensiunea dominantă, nu este clară, ele pot fi considerate aplicaţii hibride.
Preluând comportamentul hologramelor, la care însă nu face nici o referire, reţine că
obiectele luate individual păstrează caracteristicile întregii aplicaţii. Conceptul este
remarcabil deoarece, cât timp este posibilă tratarea unui singur obiect asa cum se poate trata
întreaga aplicaţie, rezultatele sunt deosebite.
În funcţie de elementul care stă la baza structurii sistemului informaţional şi implicit,
a abordării structurale, pot fi identificate mai multe strategii de dezvoltare a sistemelor
informaţionale – de la cele orientate pe funcţii sau procese şi până la cele orientate obiect.

3
Oprea, D., Meşniţă, G., Dumitriu, F., - Analiza sistemelor informaţionale, Editura Universităţii „Al. Ioan
Cuza", 2005, Iaşi, p. 181.
4
Whitmire, S.A, - Object-Oriented Design Measurement, John Wiley & Sons, Inc., New York, 1997, citat în
Oprea, D., Meşniţă, G., Dumitriu, F., - Analiza sistemelor informaţionale, Editura Universităţii „Al. Ioan Cuza",
2005, Iaşi, p.182.

9
 1.3.1 Strategia descompunerii funcţionale (orientate-funcţii)

Strategia descompunerii funcţionale a sistemelor informaţionale, care este

orientată pe funcţii, nu poate să conducă la conceperea unor sisteme suficient de stabile.
Totuşi, pe lângă problema complexităţii, stabilitatea arhitecturii programelor este una din
principalele mize ale acestei abordări. În acest sens, trebuie amintit conceptul de
independenţă funcţională care stă la baza proiectării arhitecturale a programelor.
Conceptul de independenţă funcţională derivă din principiul „divide et impera” şi
principiul abstractizării. El presupune ca fiecare modul de program să fie proiectat astfel
încât el să realizeze o singură funcţie sau subfuncţie a programului, iar interfaţa cu celelalte
module sa fie cât mai simplă. Independenţa funcţională este masurată prin intermediul a
două criterii calitative: coeziunea şi cuplarea. Coeziunea este o măsură a afinităţii mutuale
dintre componentele unui modul, respectiv a modului în care instrucţiunile dintr-un modul
sunt folosite pentru realizarea unei singure funcţii. Cuplarea este o măsură a
interdependenţei relative dintre module, ea depinzând de complexitatea interfeţei dintre
module.
Cu toate acestea, eforturile de obţinere a unui anumit nivel de stabilitate în
proiectarea sistemului informaţional are puţine şanse de reuşită atât timp cât se porneşte de
la premisa că arhitectura programului este determinată de cerinţele funcţionale ale
sistemului. Aceasta presupune construirea diagramei de structură pe baza diagramelor
fluxurilor de date ale sistemului ce sunt întocmite conform descompunerii funcţionale a
sistemului. Ori, se ştie ca cerinţele funcţionale ale unui sistem informaţional sunt cele mai
susceptibile de a se modifica.
Descompunerea funcţională este cea care anunţă apariţia proiectării structurate şi
analizei structurate. Fiecare funcţie este descompusă în subfuncţii etc., pâna când se obţin
forme uşor de transpus în instrucţiunile limbajelor de programare. Şi în cazul descompunerii
funcţionale conceptele specifice au fost introduse mai întâi în programarea structurată
(Dahl) sşi apoi în proiectare, urmată de analiză.
Descompunerea funcţională (DF) este văzută ca o sumă de funcţii, subfuncţii şi
interfeţe funcţionale, sub forma unei ecuaţii5:
5
Coad, P., Yourdon, E. - Object-Oriented Anulysis, Second Edition, Yourdon Press, Prentice HallBuilding,
Englewood Cliffs, New Jersey, USA, 1991, pp. 19-21, citat în Oprea, D., Meşniţă, G., Dumitriu, F., - Analiza

10
 DF = Funcţii+ Subfuncţii + Interfeţe funcţionale
Metoda are ca puncte tari simplitatea, obţinerea destul de uşoară a cerinţelor
utilizatorului şi generarea de soluţii pe diferite niveluri de abstractizare (sistem, subsistem,
funcţie, subfuncţie).
Ca puncte slabe putem considera concentrarea eforturilor spre funcţii (ceea ce
conduce la culegerea multor date redundante), inexistenţa unor reguli precise de
descompunere şi evidenţierea anevoioasă a interacţiunilor non-ierarhice din sistemele
complexe.
Disfuncţionalităţile metodei au fost ameliorate prin soluţii ingenioase de tipul
coeziunii şi cuplării, introduse spre sfârşitul anilor 1980 de Page&Jones şi
Yourdon/Constantine.

1.3.2 Strategia fluxurilor de date (orientate-proces)

O altă metodă şi în acelaşi timp o altă modalitate de reprezentare a domeniului

problemei şi responsabilităţilor sistemului printr-o specificaţie tehnică este metoda
orientată spre procese, deseori descrisă ca „analiză structurată".
Ecuaţia metodei este6:
Metoda fluxului de date = Fluxul (si controlul) datelor +
Transformările (şi controlul) datelor + Stocarea (şi controlul)
datelor + Terminatori + Specificaţii de proces + Dicţionarul
datelor
Prin această metodă, analiştii efectuează reprezentarea lumii reale prin linii ale
fluxurilor de date şi cerculete pentru procese. În timp, s-au conturat două strategii în analiza
structurată. Se vorbeşte despre o metodă „veche" şi despre o metodă „modernă" de analiză
structurată. În ultima variantă sunt definite cu claritate evenimentele din lumea reală la care
sistemul trebuie să răspundă, o formă embrionară a actualelor interacţiuni dintre utilizator
şi sistem, bazate pe mesaje. Sunt incluse de asemenea, fluxurile datelor şi transformările la
nivel inferior prin intermediul dicţionarului de date, respectiv al specificaţiilor proceselor.

sistemelor informaţionale, Editura Universităţii „Al. Ioan Cuza", 2005, Iaşi, p.183.
6
Coad, P., Yourdon, E. - Op cit, p. 22.

11
 Cum metoda orientată pe procese are încă un mare grad de asemănare cu
descompunerea funcţională, criticile metodei descrise anterior se reportează şi în cazul de
faţă.

1.3.3 Strategii orientate spre informaţii (orientate-date)

Majoritatea specialiştilor consideră că se poate obţine un plus de stabilitate dacă

structura propriu-zisă a sistemului informaţional se limitează la descrierea datelor şi a bazei
de date, presupunându-se că tipurile de date utilizate în cadrul organizaţiei sunt supuse mai
puţin schimbării decât prelucrările din sistem.
Această orientare a dus la apariţia strategiei orientate pe date. Chiar dacă
valoarea datelor se schimbă în mod constant, structura datelor nu presupune modificări
esenţiale, dacă ea a fost bine proiectată de la început. De regulă, clasele de entităţi în
legătură cu care se vor memora datele în sistem nu se schimbă, rareori fiind necesară
introducerea unei noi clase de entităţi, caz în care structura nu suferă transformări esenţiale,
ci presupune doar adăugarea noii clase la structura existentă.
Pe de altă parte, atributele specifice claselor de entităţi identificate în sistem suferă
modificări în mod cu totul excepţional. Descrierea datelor pe cele trei niveluri de
abstractizare – conceptual, logic şi fizic - permite o mai bună evidenţiere a aspectelor
invariante specifice datelor. În acest sens, modelarea conceptuală a datelor, folosind modelul
entitate-relaţie, descrie datele aşa cum sunt ele în realitate, independent de cerinţele
organizării şi de cerinţele tehnice ale suporturilor de stocare şi ale programelor de aplicaţii
care le accesează.
Dacă datele sunt relativ stabile, procesele de prelucrare care utilizează datele sunt
considerate a fi supuse schimbărilor în mod frecvent, ca urmare a necesităţii adaptării lor la
cerinţele functţionale ale utilizatorilor şi la progresele tehnologice.
Este de dorit ca analiştii de sisteme şi utilizatorii finali să fie capabili să schimbe
frecvent procedurile administrative din cadrul sistemului, a căror modelare trebuie realizată
cu maximum de flexibilitate. Modificarea procedurilor de prelucrare determină reproiectarea
prelucrărilor şi fluxurilor din sistem, modificarea programelor de aplicaţii, schimbarea
echipamentelor şi a programelor de sistem. În schimb, structura datelor rămâne relativ
stabilă.

12
 Două realizări remarcabile în domeniu au dat tonul acestei noi orientări în abordarea
sistemelor: modelarea datelor cu ajutorul diagramelor entitate-relaţie, de către Peter P. Chen
şi ingineria informaţiei, în viziunea lui James Martin.
Termenul „obiect", folosit în modelarea informaţiilor sau modelarea semantică a
datelor, este un simbol prin care se reprezintă una sau mai multe „ocurenţe” (cazuri) ale
„entităţilor” lumii reale.
Metoda este identificată prin următoarea ecuaţie7:
Modelarea informaţiilor = Obiecte + Atribute + Relaţii +
Supertipuri/Subtipuri + Obiecte asociative
Coad si Yourdon spun că şi în acest caz se poate vorbi despre existenţa a două
strategii. Strategia veche se bazează pe conceperea listei atributelor, gruparea lor în obiecte,
stabilirea de relaţii între „ocurenţe" (cazuri), folosirea supertipurilor/subtipurilor pentru
extragerea atributelor comune şi definirea obiectelor asociative pentru reliefarea relaţiilor
sigure. Noua strategie este destul de apropiată de precedenta, cu excepţia primului pas, care
îşi propune mai întâi să identifice obiectele lumii reale şi apoi urmează descrierea lor cu
ajutorul atributelor. Specialiştii apreciază salturile înregistrate însă, în acelaşi timp, fac
inventarul conceptelor inexistente, cum ar fi: servicii, mesaje, moştenire, structură.

1.3.4 Strategii orientate-obiect

Strategia orientată-obiect pune în centrul atenţiei noţiunea de obiect,

considerată drept o entitate care se poate distinge dintre alte entităţi şi care are o
semnificaţie în contextul aplicaţiei modelate. Obiectul asociază datele şi prelucrările în
cadrul aceleeaşi entităţi, ramânând vizibilă doar interfaţa obiectului.
Un obiect comportă un aspect static, reprezentat prin intermediul unor variabile de
stare numite atribute şi un aspect dinamic, reprezentat de comportamentul obiectului.
Aspectul static este ascuns de aspectul dinamic. În acest fel, abordarea obiectuală se distinge
de abordarea structurată. În locul unei structurări separate a variabilelor de stare,
reprezentate de date şi a funcţiilor, reprezentate de prelucrări, se modelează entităţi active
formate din structuri de date ascunse de funcţii. Un program este privit într-o manieră
globală, ca un ansamblu de obiecte care interacţioneaza prin intermediul mesajelor, care

7
Coad, P., Yourdon, E. - Op cit, p. 27.

13
declanşeaza operaţiuni ce determină evoluţia stărilor interne ale obiectelor. În acest fel se
obţine un plus de stabilitate în conceperea sistemelor informaţionale.
Ecuaţia ce caracterizează metoda, este redată în cele ce urmează8:
Orientat-Obiect = Clase şi Obiecte + Moştenire +
Comunicaţii prin mesaje
Conceptele de obiect şi clasă sunt interdependente: un obiect aparţine unei clase
(este o instanţă a clasei), iar o clasă este o grupare logică a obiectelor care au aceeaşi
structură şi un comportament similar. Un obiect este o abstractizare a datelor
elementare şi poate fi descris astfel9:
Obiect = Identitate + Comportament + Stare
Identitatea obiectului se realizează printr-un identificator al obiectului, care este
un atribut invariabil ce permite ca obiectul să fie referit independent de celelalte obiecte.
Identificatorul este generat de sistem la crearea obiectului.
Starea obiectului este o valoare care poate fi simplă (de exemplu, un literal) sau
structurată (de exemplu, o listă). In ultimul caz, ea poate fi compusă din valori simple,
referinţe la alte obiecte sau valori care ele însăşi sunt structurate.
Comportamentul unui obiect este definit printr-un set de operaţiuni ce-i pot fi
aplicate şi este descris în clasa căreia îi aparţine obiectul.
Concluzionând, se poate afirma că obiectul este o abstractizare a datelor elementare,
caracterizat printr-un identificator unic, invariabil, o clasă căreia îi aparţine şi o stare
reprezentată printr-o valoare simplă sau structurată.
Abordarea structurală specifică metodelor orientate-obiect capătă un caracter
conceptual mai accentuat, diminuând distanţa semantică ce există între modelul sistemului
şi realitate. Se realizează astfel o mai bună aplicare a abstractizării. De asemenea, cuplarea
redusă dintre obiecte şi coeziunea mare obţinută prin încapsulare şi polimorfism permit o
mai bună localizare a modificărilor, ceea ce determină un nivel redus al riscului efectelor
neaşteptate.

8
Coad, P., Yourdon, E. - Op cit, p. 30.
9
Bouzghoub, M., Gardarin, G., Velduriez, P. - Object Technology : Concepts and Methods, International
Thomson Computer Press, Boston, 1997, p. 15, citat în Oprea, D., Meşniţă, G., Dumitriu, F., - Analiza
sistemelor informaţionale, Editura Universităţii „Al. Ioan Cuza", 2005, Iaşi, p.187.

14
 Indiferent de strategia utilizată în definirea arhitecturii trebuie ca această soluţie să
permită dezvoltarea ulterioară a sistemului informaţional prin crearea şi integrarea de noi
componente. O astfel de abordare conduce la definirea de arhitecturi deschise pentru
sistemele informaţionale. Numai astfel sistemul informaţional va putea evolua odată cu
activitatea organizaţiei asigurând suportul informaţional necesar procesului de conducere şi se va
putea totodată moderniza prin integrarea de noi soluţii IT.

1.4 Etapele realizării unui sistem (produs) informaţional

Punctul de început al unui ciclu de viaţă a unui sistem informaţional este reprezentat
de decizia de realizare a unui nou SI mai performant, iar punctul final al ciclului de viaţă este
reprezentat de momentul deciziei de înlocuire a SI existent cu unul nou, mai bine adaptat
cerinţelor asigurând performanţe informaţionale, tehnice şi economice superioare.
Un sistem sau produs informaţional se realizează printr-un proces de proiectare ce
conţine mai multe etape a căror parcurgere conduce la atingerea scopului propus.
1. Analiza sistemului (produsului) informaţional
Analiza are ca obiect stabilirea cerinţelor ce trebuie avute în vedere în realizarea
proiectului. Acestea sunt determinate de:
 Cerinţele utilizatorilor - obiectivele pe care urmează să le îndeplinească viitorul
sistem informaţional, criteriile de eficienţă, securitate, performanţă pe care acesta urmează să le
asigure;
 Cerinţele sistemului - se stabilesc pornind de la cerinţele utilizatorilor şi vor
reprezenta prezentarea detaliată a rezultatelor pe care sistemul informaţional urmează să le
asigure. Se va evidenţia ce anume urmează să facă sistemul fără a se sugera în nici un fel
cum se va face acest lucru;
 Cerinţele hardware şi software - evidenţiază ce urmează să facă produsul software şi
restricţiile sub care funcţionalitatea sa va fi asigurată.
2. Proiectarea sistemului (produsului) informaţional
Cuprinde două etape:

15
  Proiectarea de ansamblu (generală) - în cadrul căreia se definesc soluţii cadru,
conceptuale privind viitorul sistem informaţional. În această etapă se stabileşte structura
sistemului informaţional, componentele şi interacţiunile dintre ele;
 Proiectarea amănunţită (de detaliu) - în cadrul căreia se rafinează soluţia cadru,
având ca finalitate definirea soluţiei finale a sistemului informaţional;
În etapa de proiectare se realizează modelele conceptuale şi logice ale datelor şi
prelucrărilor.
3. Realizarea sistemului (produsului) informaţional
Se efectuează în trei etape, şi anume:
 Realizarea propriu-zisă a aplicaţiei prin elaborarea, din modelul logic, a modelului
tehnic al datelor şi al prelucrărilor;
 Testarea - se verifică dacă sistemul răspunde sau nu cerinţelor pentru care a fost
proiectat;
 Integrarea componentelor şi testarea finală a sistemului - reunirea componentelor
în cadrul produsului final şi verificarea funcţionării lui în ansamblu.
4. Instalarea sistemului (produsului) informaţional
Instalarea presupune în primul rând achiziţionarea şi punerea în funcţiune a
calculatoarelor (reţelei de calculatoare) şi a software-ului de bază, urmărindu-se realizarea
arhitecturii alease pentru configurarea sistemului (centralizată sau descentralizată) după care,
sistemul (produsul) informaţional se va implementa şi retesta în condiţii reale de funcţionare.
Etapa se încheie cu acceptarea sistemului (produsului) informaţional de către beneficiar.
5. Exploatarea şi întreţinerea
Reprezintă utilizarea curentă a sistemului informaţional şi întreţinerea lui. După
exploatare se pot evalua rezultatele şi interveni acolo unde sunt necesare modificări.
6. Dezvoltarea sistemului (produsului) informaţional
Evaluarea finală a sistemului informaţional presupune şi analiza feed-back, ceea ce
duce la apariţia unor versiuni noi. Dezvoltarea produselor are în vedere realizarea şi
integrarea de module noi, care să îmbunătăţească şi / sau dezvolte funcţionalitatea şi
performanţele sistemului. Aceste servicii noi sunt de cele mai multe ori destul de costisitoare.

1.5. Participanţi la dezvoltarea sistemelor informaţionale

16
 Dezvoltarea unui sistem informaţional implică participarea unei echipe, cu un număr
mai mic sau mai mare de membri, în funcţie de dimensiunea proiectului. Echipa este alcătuită
din: managerul de proiect, proiectanţii, programatorii, analiştii, specialiştii în domeniul luat
în considerare (între aceştia se includ reprezentanţii conducerii, beneficiarii proiectului,
utilizatorii etc. ).
Managerul de proiect este persoana responsabilă cu îndeplinirea obiectivelor
proiectului. Acesta este, de obicei, în contact cu beneficiarii sau finanţatorii proiectului şi
lucrează îndeaproape cu analiştii in stadiile incipiente ale proiectului. Analiştii sunt
concentraţi pe obţinerea detaliilor cu privire la ceea ce trebuie să facă sistemul, în timp ce
managerul de proiect este concentrat pe determinarea factorilor de succes şi pe susţinerea
procesului de instruire a persoanelor afectate cu privire la modul de funcţionare a proiectului
de dezvoltare a sistemului.
Managerul de proiect este o parte impulsionare şi o parte gestionare a problemelor din
cadrul proiectului. Rolul său este de a se asigura că proiectul merge înainte şi pentru asta
foloseşte o mare varietate de procese, întâlniri şi documentaţie menite să asigure progresul
continuu şi identificarea problemelor cât mai curând posibil.
Rolul managerului de proiect este de a fi capabil să observa amănuntele cât mai
consecvent posibil. De asemenea trebuie să aibă o imagine de ansamblu pentru a putea
evalua riscul şi acurateţea estimărilor temporale. Toate acestea necesită o oarecare reţinere şi
competenţe de bun ascultător. Reţinerea previne intervenţia prematură a managerului, iar
ascultarea asigură că problema reală este inţeleasă şi poate fi transmisă tuturor.
Analiştii au rolul de a capta, consolida şi comunica informaţiile de la specialiştii în
domeniu la restul echipei. Analiştii iau datele de intrare şi le transformă în ceva ce echipa de
implementare poate pricepe. Unul din factorii-cheie este clarificarea intenţiilor specialiştilor.
Analistul va petrece o perioadă îndelungată de timp punând întrebări de genul: „Ce vreţi să
spuneţi prin asta?” sau „Cum se potriveşte asta cu ceea ce discutam mai devreme?”.
Întrebările de genul acesta expun potenţiale diferenţe de semnificaţie între specialişti şi restul
echipei de implimentare. Şi mai important este faptul că aceste întrebări expun presupunerile
cu privire la logica afacerii care s-ar putea să nu fie exprimate clar sau să nu fie exprimate
deloc de către specialişti.

17
 Analiştii sunt responsabili pentru identificarea şi documentarea cerinţelor precum şi
pentru rezolvarea cerinţelor conflictuale.
Specialiştii în domeniul luat în considerare sunt reprezentaţi de reprezentanţii
conducerii, beneficiarii proiectului, utilizatorii. Rolul de specialist în domeniu nu este un rol
pe care persoana aflată în centrul tehnologiei informaţionle să îl joace în mod normal, totuşi
acest rol este o parte importantă a procesului de dezvoltare. Specialiştii sunt cei care
furnizează informaţiile cu privire la ceea ce trebuie dezvoltat, ei oferă materialul brut pentru
procesul de dezvoltare, incluzând cerinţele sistemului şi cum vor fi acestea utilizate. Datele
lor de intrare descriu problema sau oportunitatea pe care proiectul o va rezolva în cele din
urmă.
Proiectanţii au rolul de a transforma cerinţele într-o structură care va deveni
prototipul pentru soluţia creată. Această conversie este bazată în principal pe modele
anterioare, în care proiectantul a fost implicat în trecut, fie prin documentare pentru a fi în
pas cu ultimile tehnici fie din experienţă proprie.
O importantă componentă a rolului proiectantului constă în motivarea şi ghidarea
liderilor proiectului. Aceştia trebuie să accepte structura, trebuie să ştie cum se potrivesc
piesele.
Programatorii sunt cei care transpun cerinţele sistemului sub forma procedurilor de
prelucrare, prin apelarea la tehnici şi principii specifice proiectării interfeţelor, bazelor de
date, programelor. Tot ei sunt cei care se ocupă de testarea si întreţinerea sistemului.
În Tabelul 1.2 sunt prezentate câteva puncte forte şi câteva neajunsuri presupuse de
îndeplinirea unui rol în cadrul dezvoltării unui sistem informaţional10.
Tabelul 1.2 Puncte tari şi puncte slabe în rolurile îndeplinite de participanţii la
dezvoltarea sistemelor informaţionale
Participant Bun Rău Urât
Vizibilitate ridicată – Limite stricte de timp – Oamenii şi interesele –
rolul implică raportarea rolul este crucial în conflictele de interese
în faţa conducerii momentul în care sunt dificil de
executive a unei proiectul se confruntă cu administrat
Manager de organizaţii astfel că are un grad ridicat de stress concomitent cu

10
Bogue R., „Anatomy of a Software Development Role: The Good, the Bad, the Ugly”,
http://www.projectmanagerplanet.com/tools/article.php/, accesat în 25 martie 2008, ora 19:30.

18
proiect posibilitatea de a
demonstra o bună
calitate a muncii în faţa
unor oameni importanţi;
Rol cheie – poate avea
un mare impact asupra
succesului/eşecului
proiectului în ansamblu;
Sentiment de împlinire
– cu ocazia fiecărui pas
înainte făcut în realizarea
proiectului prin
interacţiunea cu un mare
număr de persoane.
Rol cheie în definirea
soluţiei – este cel care,
încă de la demararea
proiectului, poate să aibă
oportunitatea de a
îndruma soluţia pe
drumul cel bun;
Interacţiune cu toată
Analist echipa – are posibilitatea
de a interacţiona cu toţi
cei implicaţi în proiect,
inclusiv cei din afara
echipei de dezvoltare a
proiectului, adică oameni
cu poziţii înalte care pot
ajuta la construcţia unei
bune reputaţii şi a unei
cauzat de restricţiile de instruirea şi
timp greu de îndeplinit; supravegherea
Suprasolicitare – de cele activităţii echipei;
mai multe ori managerul Decizii neplăcute –
se vede împărţit între mai câteodată este necesară
multe sarcini care se selectarea informaţiilor
suprapun si care necesită care vor fi incluse
implicarea sa pentru a pentru menţinerea
putea fi duse la bun traiectoriei corecte a
sfârşit; proiectului sau optarea
pentru lucrul peste
program în vederea
respectării limitelor de
timp ;
Competenţele Conflicte – sunt o
cunoscătorilor în consecinţă normală a
domeniu – nu toţi unei zile de lucru a unui
cunoscătorii dispun de anlist;
calităţile pe care le “Ţap ispăşitor” – dacă
etalează, îngreunând un anlist îşi face bine
simţitor sarcinile treaba, totul merge
analistului. bine, în cazul în care
ceva lipseşte, cel mai
adesea, analistul este
învinovăţit.
19
 cariere puternice

Rol de scurtă durată – Disconfort - dat fiind Timp investit –

rolul în proiect este în faptul că dezvoltarea de participarea la
general scurt; sisteme nu reprezintă dezvoltarea unui
Respect – cunoscătorii îndeletnicirea lui proiect poate necesita
sunt o parte importantă a principală, specialistul se investirea unui timp
proiectului şi se bucură poate simţi depăşit de îndelungat.
Specialist de un respect general; situaţie;
Grad înalt de expunere Confuzii – deşi în
– ocazia de a general sunt persoane
interacţiona cu inteligente, dezvoltatorii
numeroase persoane pot avea dificultăţi în
situate pe niveluri înţelegerea punctelor de
diferite în organizaţie. vedere ale specialiştilor.
Poziţie de valoare Efort suplimentar în a Cerinţe neclare –
ridicată – acest rol poate ţine pasul cu noutăţile – proiectantul trebuie să
conferi o valoare a fi proiectant înseamaă a ia mereu în considerare
importantă proiectului fi la zi cu o mare faptul că pentru a
(dacă este realizat cum varietate de noi tehnici, înţelege exact ceea ce
trebuie) materializată modele şi instrumente; doreşte clientul trebuie
printr-o recompensă Dificultăţi în a găsi să aprofumdeze
Proiectant materială; soluţiile optime – este cercetările;
Interacţiuni multiple – uşor de luat o decizie Dispoziţie către
presupune contactul cu eronată dacă se ţine cont suportarea
membri-cheie ai echipei de multitudinea de factori consecinţelor unui
de dezvoltare, precum şi care trebuiesc luaţi în proiect eşuat – dacă un
cu utilizatorii. considerare proiect are probleme la
dezvoltare, în capul
listei vinovatţilor se
situează proiectantul.
Mobilitate pe verticală “Cubul” – există Disfuncţionalităţi

20
 – din poziţia de percepţia conform căreia abundente – adeseori
programator se poate programatorii nu au parte apar conflicte de
foarte uşor urca pe scara de prea mult contact interese între
ierarhică; interpersonal, ei fiind respectarea termenelor
Stabilitate – retrogradaţi pe “tărâmul de finalizare a
programatorii pot deveni cubului”. produselor şi
Programator indispensabili pentru respectarea
organizaţiile în care standardelor de calitate.
activează, ei fiind printre
puţinii care ştiu ce fac şi
ştiu şi de ce o fac;
Rezolvarea de
probleme – acest rol
este antrenant deoarece
poate dezvolta abilităţi
de rezolvitor de
probleme atât pe durata
programării propriu-zise
cât şi pe durata testării.

21
 CAPITOLUL 2: FACTORI CARE INFLUENŢEAZĂ
DEZVOLTAREA SISTEMELOR INFORMAŢIONALE

Succesul unui proiect poate fi măsurat prin cât s-a apropiat acesta de atingerea
obiectivelor, cu respectarea parametrilor referitori la buget şi termene. Aceste trei elemente:
performanţe, cost şi durată sunt cunoscute sub denumirea de tripla constrângere şi reprezintă
echilibrul pe care trebuie să-l urmărească orice proiect pentru a fi considerat de succes.

2.1 Influenţe şi beneficii ale utilizării CMMI (Capability Maturity

Model Integration) în îmbunătăţirea proceselor de lucru

Capability Maturity Model Integration (CMMI) reprezintă o abordare de îmbunătăţire

a proceselor care oferă organizaţiilor elementele necesare pentru procese eficiente11. Poate fi
utilizat pentru ghidarea optimizării proceselor pe parcursul unui proiect, în cadrul unui
department sau a unei întregi organizaţii. CMMI ajută la integrarea funcţiilor unei organizaţii
care sunt în mod tradiţional separate, stabileşte sopuri şi priorităţi de ameliorare a proceselor,
asigură o direcţie pentru procesele de calitate şi oferă un punct de referinţă pentru evaluarea
procesele curente.
De asemenea, CMMI, creat la Institutul de Inginerie Software de la universitatea
Carnegie Mellon, reduce durata ciclului de dezvoltare a sistemelor, ameliorând abilitatea de a
îndeplini scopurile în ceea ce priveşte costurile, planificarea, construirea produselor şi
calitatea ridicată.

11
http://www.sei.cmu.edu/cmmi/general/index.html, accesat la data de 30 aprilie 2008, la ora 20:23.

22
 Experienţa organizaţională în procesul de dezvoltare a sistemelor informaţionale
este de asemenea un factor de succes12. Modelul CMMI reprezintă o metodă de a măsura
această experienţă şi sortează nivelul de maturitate în dezvoltarea sistemelor a unei
organizaţii utilizând cinci nivele de la Iniţial la Optimizat.

Proces de Optimizat
îmbunătăţire continuă (5)

Proces Administrat
previzibil (4)

Proces
consistent, Definit
standard (3)

Proces Repetitiv
disciplinat (2)

Iniţial
(1)

Sursa: Prelucrare după Stair, R., Reynolds, G., Principles of Information Systems, Seventh Edition,
Thomson Course Technology, 2006, Boston p. 581

Fig. nr. 2.1 Maturitatea sistemelor în dezvoltare bazate pe CMMI

1. Iniţial. Acest nivel este tipic pentru o organizaţie fără experienţă în dezvoltarea
sistemelor şi a aplicaţiilor. Acest nivel are adesea un proces de dezvoltare ad-hoc sau chiar
haotic.
2. Repetitiv. Al doilea nivel urmăreşte costurile, programul şi funcţionalitatea
dezvoltării. Disciplina de a repeta dezvoltări anterioare de succes este la ea acasă.
3. Definit. Pe nivelul trei, organizaţiile folosesc proceduri definite şi documentate.
Toate proiectele realizate de organizaţie folosesc abordări standardizate de dezvoltare a
aplicaţiilor şi sistemelor. Standardele de programare sunt adesea folosite la acest nivel.
4. Administrat. La acest nivel, organizaţiile folosesc măsurători detaliate ale
procesului de dezvoltare a sistemului pentru a ajuta administrarea procesului şi ameliorarea

12
Stair, R., Reynolds, G., - Principles of Information Systems, Seventh Edition, Thomson Course Technology,
2006, Boston p. 581.

23
calităţii.
5. Optimizat. Este cel mai înalt nivel de experienţă şi maturitate. Îmbunătăţirea
permanentă este utilizată pentru a întări toate aspectele procesului de dezvoltare.
Organizaţiile situate la acest nivel iniţiază adesea proiecte inovatoare. Scopul este de a
optimiza toate ipostazele efortului depus în dezvoltarea sistemelor.
Multe organizaţii au investit în îmbunătăţirea proceselor de lucru prin utilizarea
CMMI. Multe dintre acestea au reuşit chiar să-şi depăşescă obiectivele de îmbunătăţire.
Există suficiente dovezi care să demonstreze ameliorarea proceselor prin influenţa asupra
performanţelor planificărilor şi a costurilor, asupra calităţii produselor, precum şi asupra
randamentului investiţiilor.
Rezultatele cantitative prezentate în următorul tabel provin de la un total de 35 de
organizaţii, dintre care mai multe sunt intreprinderi care au mai mult de o organizaţie
constituentă13.

Tabelul nr 2.1 Îmbunătăţirea performanţelor în decursul timpului prin CMMI, pe categorii

Categoria de Îmbunătăţire Număr de centre de Îmbunătăţire Îmbunătăţire

performanţă medie colectare a datelor minimă maximă

Cost 34% 29 3% 87%

Planificare 50% 22 2% 95%

Productivitate 61% 20 11% 329%

Calitate 48% 34 2% 132%

Satisfacţia 14% 7 -4% 55%

clienţilor

Randamentul 4.0 : 1 22 1.7 : 1 27.7 : 1

investiţiilor

Sursă: Preluare după Gibson, Diane L., Goldenson, Dennis R., Kost, Keith, Perfomance Results of
CMMI. Based Process Improvement, raport tehnic Software Engineering Institute, Carnegie Mellon, august
200614.

13
Gibson, Diane L., Goldenson, Dennis R., Kost, Keith, - Perfomance Results of CMMI. Based Process
Improvement, raport tehnic Software Engineering Institute, Carnegie Mellon, august 2006.
14
Notă: Aceste rezultate din tabel exprimă modificări survenite în decursul unor perioade variate de timp.

24
 Categoria costurilor acoperă instanţele unde organizaţia a raportat schimbări în costul
final sau intermediar al produselor, schimbări în costul proceselor angajate să producă
produsele şi economii generale care pot fi atribuite îmbunătăţirii proceselor prin intermediul
modelelor. De asemenea include şi anticiparea ridicată a costurilor implicate şi alte măsuri
ale variaţiei. Categoria planificării cuprinde anticiparea şi reducerea timpului afectat
programului de lucru. Productivitatea include numeroşi indici bazaţi pe cantitatea de muncă
îndeplinită într-o anumită perioadă de timp. Îmbunătăţirea calităţii produselor se măsoară cel
mai adesea prin reducerea numărului de defecte. Satisfacţia clienţilor este o categorie ce
poate fi monitorizată prin intermediul sondajelor practicate în rândul clienţilor. Randamentul
investiţiilor poate fi exprimat prin mai multe metode15. Pe lângă diferenţele costuri-beneficii,
mai ţine cont şi de: valoarea prezentă netă, randamentul intern, perioadele de rambursare.

2.2 Gradul de schimbare

Gradul de schimbare asociat cu implementarea unui proiect este un factor major care
influenţează calitatea dezvoltării unui sistem. Raza de acţiune poate varia de la
implementarea unor mici îmbunătăţiri realizate sistemului existent până la o restructurare
majoră. Echipa de proiect trebuie să identifice unde anume se situează pe acest spectru al
schimbării.

2.2.1 Îmbunătăţire continuă vs. restructurare

Proiectele de îmbunătăţirea continuă nu necesită schimbări semnificative în procesele

afacerii sau reinstruirea indivizilor, deci au un grad ridicat de succes. Tipic, deoarece
ameliorările continue implică îmbunătăţiri minore, ele au şi beneficii modeste. Pe de altă
parte, restructurarea semnifică schimbări fundamentale în modalitatea în care organizaţia îşi
conduce afacerea şi îşi îndeplineşte sarcinile. Factorii asociaţi cu o restructurare de succes
sunt similari cu cei ceruţi în orice proces de dezvoltare, inclusiv susţinerea conducerii,
scopuri corporative şi obiective de dezvoltare a sistemelor bine definite şi un management al
schimbării prudent16.

15
El Emam, K., - The ROI from Software Quality. Auerbach Publications, Boca Raton, Florida 2005.
16
Stair, R., Reynolds, G., - Op. cit., p. 577.

25
 Gradul
de risc
Gradul de schimbare

Îmbunătăţire continuă Proces de restructurare a

afacerii

Fig. nr. 2.2 Influenţa gradului de schimbare asupra succesului proiectelor

Proiectele de restructurare majoră tind să aibă un grad ridicat de risc, dar au şi un

potenţial ridicat spre beneficii majore aduse afacerii.

2.2.2 Managementul schimbării

Abilitatea de a manevra schimbarea este critică în succesul dezvoltării sistemelor.

Noile sisteme produc inevitabil schimbări. Din nefericire, nu toată lumea se poate adapta
uşor, iar complexitatea crescândă a sistemului poate multiplica problemele. Managementul
schimbării are nevoie de abilitatea de a recunoaşte existenţa unor potenţiale probleme (în
special în ceea ce priveşte utilizatorii) şi rezolvarea lor înainte să devină o serioasă
ameninţare la succesul sistemelor noi sau modificate.
Printre cele mai întâlnite probleme putem enumera:
- frica angajaţilor de a-şi pierde slujba, puterea, influenţa în organizaţie;

26
 - impresia că noul sistem va genera mai multă muncă decât să o elimine;
- reticenţa de a lucra cu informaticieni;
- neliniştea că sistemul propus va afecta negativ structura organizaţiei;
- credinţa că sunt alte probleme mai importante decât cele rezolvate prin sistemul
propus sau că sistemul este dezvoltat de persoane care nu sunt familiare cu “modul în
care facem noi lucrurile”;
- indisponibilitatea de a învăţa noi abordări şi proceduri.
Prevenirea sau rezolvarea acestui tip de probleme necesită un efort coordonat din
partea acţionarilor, utilizatorilor, managerilor şi personalului dezvoltator. Un remediu ar
consta în discuţii simple cu toţi cei implicaţi cu privire la principalele lor griji. Conducerea
poate apoi să se ocupe cu eliminarea respectivele îngrijorări.

2.3 Factori referitori la utilizatori ce au influenţă asupra succesului

dezvoltării sistemelor informaţionale

Depăşirile de buget, termene-limită nerespectate, caracteristici inexacte şi eşecurile

depline încă mai chinuie industria dezvoltatoare de sisteme informaţionale în ciuda
progreselor care s-au realizat în procesele de dezvoltare17.
S-au realizat multe cercetări cu privire la influenţa participării şi implicării
utilizatorilor în succesul proiectelor de dezvoltare a sistemelor informaţionale. Totuşi, multe
din detaliile mecanismelor şi antecedentelor participării cu succes a utilizatorilor sunt încă
necunoscute.

2.3.1 Factori referitori la utilizatori

Factorii identificaţi ca fiind releţionaţi cu personalul utilizator sunt: dispoziţia spre

schimbare, angajamentul, abilităţile de comunicare, cunoştinţele de utilizare a calculatorului,
apartenenţa, participarea, procedurile, înţelegerea sistemului curent şi înţelegerea nevoilor18.
Fiecare din aceste caracteristici sau atribute ale utilizatorilor sistemului în dezvoltare pot
influenţa succesul proiectul în diverse feluri.

17
Ravichandran, T., Rai, A. - Total quality management in information systems development: Key constructs
and relationships, apărut în Journal of Management Information Systems, 2000, pp. 119-155.
18
Havelka, D., Conrad, K., Glassberg, B. - A project success model for information systems development, apărut
în Proceedings of Western Decision Sciences Institute Annual Meeting, Las Vegas, 2002.

27
 Dispoziţia spre schimbare include dorinţa utilizatorilor de a încerca noi abordări
tehnologice ca şi suport pentru sistemul de lucru. Este general acceptat faptul că majoritatea
indivizilor au o tendinţă naturală de a se opune schimbării. Asta ar putea avea impact asupra
succesului proiectului prin insistenţa utilizatorilor ca noul sistem să funcţioneze în aceeaşi
manieră ca cel vechi.
Angajamentul reprezintă nivelul de importanţă pe care îl acordă utilizatorii afectaţi
îndeplinirii proiectului. Acesta reflectă nivelul de implicare emoţională şi psihologică în
proiect şi este de aşteptat să aibă influenţă directă asupra reuşitei prin determinarea duratei de
timp pe care sunt dispuşi utilizatorii s-o dedice proiectului. Cei care vor dori succesul
dezvoltării vor oferi documentaţie, cor răspunde la întrebări şi vor îndeplini orice alte
activităţi necesare.
Abilităţile de comunicare sunt definite ca abilităţile de scriere, vorbire şi ascultare a
participanţilor la proiectul de dezvoltare. Principalul motiv pentru participarea utilizatorilor
în dezvoltarea sistemelor este de a-şi transfera cunoştinţele. Fără un nivel adecvat al
abilităţilor de comunicare, interacţiunea dintre utilizatori poate fi dificilă, iar aceştia, deşi ar
fi dispuşi să furnizeze informaţiile necesare, nu sunt capabili să exprime cerinţele echipei
dezvoltatoare, altor utilizatori sau conducerii.
Cunoştinţele de utilizare a calculatorului definesc gradul de înţelegere pe care îl
posedă utilizatorii cu privire la calculatoare, software şi tehnologie în general. Dacă
utilizatorii sunt cunoscători în ceea ce priveşte calculatorul, comunicarea cu personalul
dezvoltator se poate îmbunătăţi dat fiind faptul ca ar putea înţelege o parte din jargonul
tehnic. De asemenea, pe măsură ce aceste cunoştinţe cresc, utilizatorii sunt mai dispuşi să
accepte noua tehnologie şi pot să arate mai puţină reticenţă şi sunt capabili să aibă nişte
perspective mai realiste cu privire la ceea ce se poate realiza folosind tehnologia
informaţională şi cu privire la cantitatea de timp şi bani necesară pentru proiectare,
construirea şi implementarea noilor aplicaţii.
Apartenenţa este definită ca fiind un ataşament psihologic la sistem sau la procesul
afacerii pentru care este dezvoltat sau implementat un nou sistem sau o nouă aplicaţie. Dacă
un utilizator cu un dezvoltat simţ al apartenenţei consideră că un sistem nou va determina ca

28
activităţile să fie mai eficiente şi mai rapide, atunci s-ar putea să crească angajamentul faţă
de proiect şi ar putea să aibă un impact pozitiv asupra acestuia. În schimb, dacă un utilizator
cu un dezvoltat simţ al apartenenţei la procesul de afaceri consideră proiectul ca o ameninţare
care generează o creştere a nivelului de muncă sau chiar pierderea postului de lucru, atunci
asta va determina o scădere a angajamentului faţă de proiect având o influenţă negativă
asupra succesului acestuia.
Participarea semnifică implicarea activă şi semnificativă a utilizatorilor actuali ai
aplicaţiei în procesul de dezvoltare. Aceasta include identificarea justă a utilizatorilor finali şi
a performanţelor acestora în îndeplinirea anumitor sarcini şi activităţi. Încă mai există
dezbateri cu privire la nivelul optim de participare a utilizatorilor. Noile tehnici, cum ar fi
programarea extremă, care minimalizează participarea, sunt sugerate ca fiind cele mai
productive metode de dezvoltare a sistemelor, în timp ce abordările socio-tehnice încă sunt
populare şi au mulţi apărători dedicaţi19.
Capacitatea de înţelegere a noului sistem reprezintă nivelul de cunoştinţe pe care
utilizatorii participanţi la procesul de dezvoltare îl au cu privire la procesele şi procedurile
curente, manuale sau bazate pe calculator, utilizate pentru a-şi efectua îndatoririle.
Utilizatorii cu un grad ridicat de înţeleger a sistemului actual sunt capabili să semnaleze
anumite probleme specifice sau zone ce ar necesita îmbunătăţiri în noul sistem. Pe de altă
parte, utilizatorii care nu au un grad ridicat de înţelegere a sistemului actual sau cum este
acesta relaţionat de alte operaţii ale afacerii nu vor putea să ofere detalii necesare pentru
automatizarea proceselor sau pentru eliminarea ieşirilor redundante din sistem.
Capacitatea de a înţelege nevoile înseamnă gradul de cunoştinţe pe care îl au
utilizatorii participanţi la procesul de dezvoltare în legătură cu informaţiile necesare pentru a-
şi îndeplini sarcinile. Asta include cunoştinţe cu privire la ieşiri şi la procesarea şi datele
necesare pentru a produce aceste ieşiri. Motivul principal pentru implicarea utilizatorilor în
procesul de dezvoltare este determinarea cerinţelor informaţionale necesare pentru executarea
activităţilor acestora. Pentru ca acest transfer de cunoştinţe să se petreacă, utilizatorii trebuie
să aibă o idee referitor la ceea ce înseamnă cerinţe informaţionale.

2.3.2 Analiza interacţiunii factorilor referitori la utilizatori

19
Shayo, C.; Olfman, L.; Teitelroit, R. - An exploratory study of the value of pretraining enduser participation,
publicat în Information Systems Journal., 9, 1, 1999, pp. 55-79.

29
 Următorul tabel prezintă factorii referitori la personalul utilizator si care pot să
influenţeze reuşita dezvoltării sistemelor informaţionale.

Tabelul nr. 2.2 Interacţiunea dintre factorii ce se referă la utilizatori

Dispoziţia spre schimbare

Abilităţile de comunicare

Apartenenţa

Participarea

Capacitatea de a înţelege nevoile

Angajamentul

Cunoştinţele de utilizare a calculatorului

Capacitatea de înţelegere a noului sistem

Succesul dezvoltării sistemului informaţional

Influenţa factorilor referitori la
utilizatori unul asupra celorlalţi

Dispoziţia spre schimbare 0 - 0 0 0 - 0 0 -

Angajamentul - 0 0 0 + + 0 0 +
Abilităţile de comunicare 0 0 0 0 0 + 0 0 0
Cunoştinţele de utilizare a calculatorului 0 0 0 + 0 + + 0 +
Apartenenţa 0 0 0 0 0 0 + + 0
Participarea - 0 0 + + + + + 0
Capacitatea de înţelegere a noului 0 0 0 + + 0 + + +
sistem
Capacitatea de a înţelege nevoile 0 0 0 0 + 0 0 + +

Fiecare factor este redat atât pe orozontală cât şi pe verticală, fiind adăugat ca şi
“scop” succesul dezvoltării sitemului. Influenţa fiecărui factor asupra celorlalţi poate fi
cuantificată cu “+” (pentru o influenţă pozitivă), cu “-“ (pentru o influenţă negativă) sau cu
“0” (dacă nu există influenţă sau o distincţie evidentă).

2.4 Standarde şi calitate

Un alt factor de succes îl reprezintă calitatea planificării proiectului. Cu cât este

proiectul mai mare cu atât este mai probabil ca o planificare defectuoasă să provoace
probleme semnificative.

30
 O parte din problemele care contribuie la eşecul proiectelor de dezvoltare a
sistemelor, precum şi soluţiile acestora sunt prezentate în următorul tabel.

Tabelul nr. 2.3 Factori de eşec şi contramăsurile acestora

Factor
Rezolvarea problemei nepotrivite
Analiză şi definire deficitară a
problemelor
Comunicare insuficientă
Proiectul este prea ambiţios
Lipsa susţinerii conducerii
Lipsa implicării utilizatorilor şi a
conducerii
Proiectare nepotrivită sau greşită a
sistemului
Lipsa standardelor
Implementare şi testare insuficientă
Utilizatorii nu sunt capabili să
folosească sistemul eficient
Lipsa grijii pentru întreţinere
Contramăsură
Stabilirea unei legături clare între proiect şi ţelurile
organizaţiei
Ghidarea după abordări standardizate a dezvoltării
sistemelor
Comunicaţi, comunicaţi, comunicaţi
Reducerea ariei de acoperire a proiectului numai
asupra celor mai importante oportunităţi
Identificarea managerului de top care are cel mai
multe de câştigat de pe urma succesului proiectului
şi recrutarea acestuia pentru a susţine proiectul
Identificarea şi recrutarea acţionarilor-cheie ca şi
participanţi activi la proiect
Urmărirea unei abordări standardizate a dezvoltării
sistemelor
Implementarea unui sistem de standarde
Dedicarea unui timp suficient acestei activităţi
Dezvoltarea unui program riguros de instruire şi
alocarea de timp destul în program pentru executare
Includerea în justificarea originală a proiectului a
unor costuri pentru întreţinere

Deşi o planificare adecvată nu garantează apariţia problemelor, ea poate minimiza

probabilitatea ca acestea să se întâmple. O bună dezvoltare a sistemului nu este automatizată.

2.5 Utilizarea instrumentelor de tip CASE (Computer-Aided Sofware

Engineering)

Instrumentele de tip CASE automatizează multe din sarcinile implicate în dezvoltarea

sistemelor şi impune ataşamentul la ciclul de viaţă al dezvoltării sistemelor, astfel dictând un

31
grad de rigoare şi standardizare în întregul proces de dezvoltare.
Avantajele şi dezavantajele instrumentelor de tip CASE sunt evidenţiate în următorul
tabel.
Tabelul nr. 2.4 Avantajele şi dezavantajele instrumentelor de tip CASE
Avantaje Dezavantaje
Producerea unor sisteme cu o mai lungă şi Producerea unor sisteme iniţiale care sunt mai
eficientă existenţă operaţională scumpe de construit şi de întreţinut
Producerea unor sisteme care îndeplinesc Necesitatea unor definiri extensive şi precise a
îndeaproape cerinţele şi nevoile utilizatorilor cerinţelor şi a nevoilor utilizatorilor
Producerea unor sisteme excelent Apariţia dificultăţilor în adaptare
documentate
Producerea unor sisteme care să aibă nevoie Necesitatea unei instruiri mai intense a
de mai puţină susţinere personalului de întreţinere
Producerea unor sisteme mai flexibile Posibilitatea unei integrări dificile cu sistemele
existente

Aceste instrumente caută toate scenariile de proiectare posibile pentru a se asigura că

programul este lipsit de erori.

2.6 Dezvoltarea orientată-obiect a sistemelor

Dezvoltarea orientată-obiect a sistemelor este o abordare a dezvoltării sistemelor care

combină logica ciclului de viaţă a sistemului cu puterea programării şi modelării orientate-
obiect.
Succesul dezvoltării poate depinde de instrumentele de programare utilizate şi de
orientările urmărite. Limbajele de programare orientată-obiect permit interacţiunea între
obiectele de programare – un obiect este alcătuit atât din date cât şi din operaţiile care se pot
realiza asupra lor. Conceperea aplicaţiilor şi programelor utilizând limbaje de programare
orientate-obiect implică construirea a unor părţi şi module care pot fi reutilizate în alte
proiecte de programare20.
Folosind abordările orientate-obiect, dezvoltarea programelor devine mai rapidă şi
mai eficientă, obţinându-se astfel costuri mai scăzute. Modulele pot fi create intern sau
obţinute dintr-o sursă externă. Odată ce o firmă are modulele de programare, programatorii şi
20
Verton, D., Senate votes to kill funds for antiterror data mining, publicat în Computerworld, 21 iulie 2003,
accesat la www.computerworld.com, în data de 13 mai 2008, 11:22.

32
analiştii de sistem pot să le modifice şi să le integreze cu alte module pentru a obţine noi
programe.
Dezvoltarea orientată-obiect urmăreşte un ciclu de viaţă foarte bine definit. Fazele
acestui ciclu pot fi, şi de cele mai multe ori sunt, completate prin multe repetiţii.
Dezvoltarea orientată-obiect a sistemelor implică, de obicei, următoarele:
♦ Identificarea potenţialelor probleme şi oportunităţi din cadrul organizaţiei
care ar putea fi potrivite pentru abordarea orientată-obiect. Acest proces este similar cu
analiza tradiţională a sistemului. În mod ideal, aceste probleme şi oportunităţi ar trebui să se
preteze la dezvoltarea programelor care pot fi construite prin modificarea modulelor de
program existente deja;
♦ Definirea tipului de sistem folositor utilizatorilor. Această investigare
semnifică definirea tuturor obiectelor care fac parte din mediul de lucru al utilizatorilor
(analiză orientată-obiect). Echipa care se ocupă de proiectarea orientată-obiect studiază
afacerea şi construieşte un model al obiectelor care aparţin afacerii (ex.: un client, o
comandă, o plată);
♦ Proiectarea sistemului. Acest proces defineşte toate obiectele din sistem şi
modul în care acestea interacţionează ( proiectare orientată-obiect). Proiectarea implică
dezvoltarea de modele logice şi fizice ale noului sistem prin adăugarea de detalii la modelul
obiectului aflat în analiză;
♦ Programarea sau modificarea modulelor. Această etapă a implementării ia
modelul obiectului început în analiză şi finalizat în proiectare şi îl transformă într-un set de
obiecte relaţionate în sistem. Limbajele de programare orientată-obiect sunt astfel proiectate
ca să permită programatorilor să creeze clase de obiecte pe calculator care să corespundă
obiectelor din procesul veritabil de afaceri. Obiectele cum ar fi: un client, o comandă, o plată
sunt redefinite ca obiecte de sistem – un ecran pentru client, un meniu de introducere a
comenzii, o iconiţă cu semnul dolarului. Apoi programatorii scriu noi module sau le modifică
pe cele existente pentru a produce programele dorite;
♦ Evaluarea realizată de utilizatori. Implementarea iniţială este evaluată de către
utilizatori şi îmbunătăţită. Sunt introduse scenarii şi obiecte suplimentare şi ciclul se repetă,
ca în final să fie disponibil spre folosire un sistem complet, testat şi aprobat;

33
 ♦ Revizuire şi modificare periodică. Sistemul complet şi operaţional este revizuit
la intervale regulate de timp şi modificat dacă este necesar.

2.7 Dezvoltarea “agilă” a sistemelor

Dezvoltarea “agilă” este un cadru conceptual pentru proiectarea aplicaţiilor care

promovează repetivitatea pe parcursul ciclului de viaţă al unui proiect.
Există multe metode agile de dezvoltare, majoritatea minimizând riscul prin
dezvoltarea aplicaţiilor în periaode scurte de timp. Aplicaţiile dezvoltate pe durata unei
unităţi de timp este definită ca o iteraţie, care poate dura de la una până la patru săptamâni.
Fiecare iteraţie este un întreg proiect: include planificare, analiza cerinţelor, proiectare,
programare, testare şi documentare. Poate că o itieraţie nu adaugă suficientă funcţionalitate
pentru a garanta distribuţia proiectului pe piaţă, dar scopul este de a avea o variantă
disponibilă (fără erori) la sfârşitul fiecărei iteraţii. La finalul fiecărei repetiţii, echipa
reevaluează priorităţile proiectului.
Metodele agile favorizează comunicarea faţă-în-faţă înaintea documentelor scrise,
generând mult mai puţină documentaţie scrisă comparativ cu alte metode.

2.7.1 Principiile din spatele metodelor agile

Metodele agile sunt o familie de procese de dezvoltare, nu o abordare singulară a

dezvoltării aplicaţiilor. În 2001, 17 figuri proeminente21 din câmpul dezvoltării agile (aşa
numite “metode uşoare”) s-au întâlnit să discute despre creare unor aplicaţii uşoare, rapide şi
centrate pe oameni. Ei au creat Manifestul Agile.
Dintre principiile din spatele Manifestului Agile putem enumera22:
♦ satisfacţia clienţilor printr-o livrare continuă şi rapidă de aplicaţii folositoare;
♦ aplicaţii funcţionale livrate frecvent (săptămânal mai degrabă decât lunar);
♦ aplicaţiile funcţionle sunt principala măsură a progresului;
♦ chiar şi schimbările târzii în cerinţe sunt bine-venite;
♦ cooperare zilnică şi apropiată între dezvoltatori şi cei implicaţi în afacere;

21
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James
Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor,
Ken Schwaber, Jeff Sutherland şi Dave Thomas.
22
www.agilemanifesto.org, accesat în 29 aprilie 2008, la ora 12:32.

34
♦ discuţia faţă-în-faţă este cea mai bună metodă de a comunica;
♦ proiectele sunt construite în jurul unor indivizi motivaţi, care sunt de încredere;
♦ atenţie continuă spre excelenţă tehnică şi bună proiectare;
♦ simplitate;
♦ echipe auto-organizate;
♦ adaptare regulată la împrejurări în schimbare.
O parte din autorii ce au elaborat Manifestul pentru dezvolare agilă au lucrat în
continuare pentru a vedea ce principii manageriale vor putea fi necesare pentru a putea căpăta
o gândire agilă în managementul produselor şi a proiectelor. Astfel că, în 2005, au publicat
“Declaraţia de interdependenţă”23.
Cele şase principii au fost esenţiale pentru managementul modern al proiectelor (şi
managementul în general)24:
“Noi...
♦ îmbunătăţim randamentul investiţiilor, prin concentrarea pe un flux de
valoare continuu;
♦ oferim rezultate de încredere, prin implicarea clienţilor în interacţiuni
frecvente şi apartenenţă impărtăşită;
♦ ne aşteptăm la incertitudine, şi o administrăm prin iteraţii, anticipare şi
adaptare;
♦ dezlănţuim creativitatea şi inovaţia, prin recunoaşterea că indivizii sunt
sursa de valoare de bază şi crearea unui mediu unde ei pot face diferenţa;
♦ susţinem performanţa, prin evidenţa rezultatelor grupului şi
responsabilitate împărţită pentru eficacitatea echipei;
♦ îmbunătăţim eficacitatea şi siguranţa, prin strategii, procese şi practici
specifice situaţiei.
”

2.7.2 Compararea metodelor agile cu alte metode

23
Larman, C.; Basili V. R., - Iterative and Incremental Development: A Brief History, IEEE Computer Society,
iunie 2003, p. 47-56.
24
http://www.agilealliance.com, accesat în data de 30 aprilie, la ora 14:33.

35
 Metodele agile sunt adesea caracterizate ca fiind opusul metodelor situate în spectrul
“orientate pe plan” sau “disciplinate”. Această definire este înşelătoare deoarece ar însemna
că metodele agile sunt “neplanificate” şi ”indisciplinate”. O caracterizare mai precisă ar fi că
metodele se pot situa pe o scală de la “adaptativ” către ”predictiv”25. Metodele agile sunt
situate pe partea adaptativă a scalei.
Metodele adaptative se concentrează pe adaptarea rapidă la realitatea schimbătoare.
Când nevoile unui proiect se schimbă, o echipă adaptativă se schimbă şi ea. O echipă
adaptativă vaavea dificultăţi în descrierea exactă a ceea ce se va întâmpla în viitor. Cu cât
este data mai îndepărtată cu atât va fi mai vagă o metodă adaptativă cu privire la ce se va
întâmpla la respective dată. O echipă adaptativă poate raporta exact ce sarcini vor fi
îndeplinite săptămâna viitoare, dar numai ce cerinţe sunt planificate pentru luna următoare.
Metodele predictive, în schimb, se concentrează pe planificarea viitorului în detaliu.
O echpă predictivă poate raporta exact ce sarcini şi cerinţe sunt planificate pe durata
întregului proces de dezvoltare. Echipele predictive întâmpină dificultăţi în schimbarea
direcţiei. Planul este optimizat pentru direcţia originală şi schimbarea direcţiei poate duce la
inutilizarea unor sarcini îndeplinite şi refacerea lor diferit. Echipele predictive vor institui
adesea un comitet de control al schimbării pentru a se asigura că numai cele mai valoroase
schimbări sunt luate în considerare.
Majoritatea metodelor agile împărtăşesc cu alte metode iterative şi incrementale de
dezvoltare accentul pus pe construirea de aplicaţii difuzabile în perioade scurte de timp.
Dezvoltarea agilă diferă, totuşi, de alte metode de dezvoltare: în acest model perioadele de
timp sunt măsurate mai degrabă în săptămâni decât în luni şi munca este efectuată cu un grad
colaborativ ridicat.
Dezvoltarea agilă are foarte puţine în comun cu modelul “cascadă “ care este cel mai
predictiv model dintre toate. Principala problemă cu modelul “cascadă” o reprezintă
fragmentarea inflexibilă a unui proiect în stadii separate, astfel că angajamentele sunt luate de
devreme, dar reacţia la schimbarea cerinţelor este dificilă. Iteraţiile sunt scumpe.

25
Boehm, B.; Turner R., - Balancing Agility and Discipline: A Guide for the Perplexed, Addison-Wesley,
Boston, 2004, p. 165-194

36
Asta înseamnă că modelul “cascadă” este foarte posibil să fie nepotrivit dacă cerinţele nu
sunt bine înţelese sau este o probabiliotate ridicată ca aceste să se modifice pe parcursul
proiectului26.
Unele echipe agile folosesc modelul “cascadă” la scară mică, repetând întregul ciclu
”cascadă” la fiecare iteraţie27.

2.7.3 Critici aduse metodelor agile

Dezvoltarea agilă de aplicaţii a fost criticată că nu ar aduce beneficiile preconizate

atunci când programatorii care folosesc această metodă au abilităţi medii, ştiut fiind faptul că
majoritatea echipelor de dezvoltare sunt alcătuite din oameni cu abilităţi medii (sau chiar
medii)28.
Criticile aduse acestor metode se referă la:
- lipsa structurării şi a documentaţiei necesare;
- incorporarea unei proiectări insuficiente a aplicaţiei;
- necesitatea adoptării unei prea mari schimbări culturale;
- posibilitatea apariţiei unor negocieri contractuale dificile;
- posibilitatea să fie ineficientă;
- imposibiltatea estimării realiste a necesarului de effort investit, dat fiind faptul că
la începutul proiectului nimeni nu cunoaşte cerinţele complete;
- creşterea drastică a riscului de a realiza schimbări necontrolate în raza de acţiune a
proiectului dată fiind lipsa documentaţiei cu cerinţele detaliate.

2.8 Eşecul proiectelor de dezvoltarea a sistemelor informaţionale

Pentru a putea defini noţiunea de eşec în contextul proiectelor de dezvoltare a

sistemelor informaţionale, este nevoie să devenim eşecul într-un context general. Asta va

26
Sommerville, I., - Software engineering, 8th edition, Addison Wesley, Boston, 2007, p. 66f.
27
Ambler, S., - Scaling Scrum - Meeting Real World Development Needs, publicat în aprilie 2008, pe
http://www.drdobbsonline.net/architect/207100381.
28
Papadimoulis, A., - The Great Pyramid of Agile, publicat în 24 mai 2007 pe
http://thedailywtf.com/Articles/The-Great-Pyramid-of-Agile.aspx, accesat în data de 13 aprilie, la ora 23:14.

37
preveni orice ambiguitate cu privire la eşecul proiectelor de dezvoltare a sistemelor
informaţionale.

2.8.1 Definirea noţiunii de eşec a proiectelor

Eşecul, de obicei în raport cu proiectele care sunt întârziate sau depăşesc bugetul, se
defineşte ca fiind incapacitatea de a obţine pe deplin beneficiile aşteptate sau de a câştiga
acceptul şi susţinerea entuziastă a utilizatorilor şi a conducerii29.
Eşecul se descrie ca fiind un număr de evenimente care se petrec în cadrul proiectului
şi îl determină să nu respecte specificaţiile şi să-şi îndeplinească misiunea.
Nu este foarte corectă creare unei definiţii absolute a eşecului. Este mai plauzibil să
existe mai multe grade de eşec. Se pot identifica mai multe categorii de eşec30 prezentate în
tabelul următor.
Tabelul nr. 2.5 Categorii de eşecuri ale sistemelor informaţionale
Categorii de eşec Descrierea eşecului
Eşec în corespondenţă Sistemul informaţional nu îndeplineşte
obiectivele proiectate
Eşecul procesului Sistemul informaţional depăşeşte bugetul şi
restricţiile de timp
Eşecul interacţiunii Utilizatorii menţin o interacţiune scăzută sau
inexistentă cu sistemul informaţional
Eşecul aşteptărilor Sistemul informaţional nu se ridică la nivelul
aşteptărilor acţionarilor

Tipurile de eşec şi nivelul eşecului trebuie de asemenea definite clar deoarece eşecul
poate însemna diferite situaţii pentru diverse persoane şi organizaţii. În cadrul sistemelor
informaţionale pot exista eşecuri organizaţionale, tehnice sau umane. Nivelul la care poate să
apară eşecul variază în funcţie de grupul care decide cât valorează eşecul petru ei în termen
de valoare financiară şi competitivitate31.

29
Cannon, J.A., - Why IT Applications Succeed or Fail, Industry and Commercial Training, Vol. 26, No. 1,
1994, p. 10-15.
30
Yeo, K. T., - Critical failure factors in information system projects, International Journal for Project
Management, Vol. 20, No. 3, 2002, p. 241-246.
31
Goulielmos, M., - Outlining organisational failure in information systems development, Disaster Development
and Management Journal, Vol. 12, No. 4, 2003, pp. 319-327.

38
 Eşecul dezvoltării sistemelor informaţionale se poate situa pe trei nivele: minor,
major sau critic32.
Eşecul de nivel unu este considerat minor pentru că proiectul final de dezvoltare încă
îşi îndeplineşte obiectivele şi este terminat.
Eşecul de nivel doi este major deoarece proiectul nu-şi îndeplineşte toate cerinţele şi
nu va fi încheiat în buget şi la timp. În acest caz apar două situaţii posibile: proiectul poate
continua şi să fie finalizat dar a depăşit timpul şi bugetul sau proiectul nu îşi va îndeplini
toate obiectivele, dar soluţia este utilizabilă.
Eşecul de nivel trei este critic şi proiectul nu-şi realizează nici o cerinţă şi nici un
obiectiv. Este foarte probabil să fie aruncat după ce a depăşit timpul şi bugetul şi să nu se
întrezărească nici o finalitate pentru respectivul proiect.

Tabelul nr. 2.6 Nivelurile eşecului proiectelor

Nivelul eşecului
Nivelul unu Nivelul doi Nivelul trei
(minor) (major) (critic)
Profitabilitate Nu toate scopurile sunt Aruncat înainte de finalizare
Evaluări slabe realizate Incapacitatea dezvoltatorului
Tehnologie Soluţii complexe de a îndeplini cerinţele
neconvingătoare Lipsa planificării Consultarea cu clientul pe
Lipsa resurselor Lipsa implicării parcursul etapei de dezvoltare
Lipsa utilităţii utilizatorilor
Lipsa organizării Lipsa resurselor
proiectului Lipsa angajamentului
Transparenţa proiectului Aşteptări nerealiste
Lipsa susţinerii conducerii
Modificarea cerinţelor şi a
specificaţiilor
Depăşirea programului
Depăşirea bugetului

32
Lally G., - Understanding Information Technology System Project Failure, School of Computing, Dublin
Institute of Technology, 2004.

39
 Lipsa apartenenţei şi a
responsabilităţii
Prea multe interese investite

Nivelele de eşec sunt cumulative şi nivelul trei nu poate fi atins fără să fi trecut prin
nivele unu şi doi de eşec. La nivelul unu echipa de proiect ar trebui să fie conştientă de ruta
descendentă pe care o ia proiectul şi ar trebui să fie dispuşi să răspundă eficient schimbării
din mediu care a produs eşecul de nivel unu. Dacă proiectul se deplasează către nivelul doi,
devine evident că se află în mare dificultate şi ajunge în pericolul de a fi anulat, căzând astfel
la nivelul trei.

2.8.2 Factori care cauzează eşecul dezvoltării sitemelor informaţionale

O paradigmă frecventă în managementul proiectelor de dezvoltare a sistemelor

informaţionale este privirea porcesului de dezvoltare şi predare ca un schimb în natură între
trei părţi: timp, cost şi calitate33. Schimburile sunt diminuate sau eliminate de tot prin
negociere. În ciuda încercărilor de a face din dezvoltarea de aplicaţii şi predarea proiectelor
activităţi cât mai riguroase, o proporţie considerabilă din efortul depus se concretizează în
sisteme care nu se ridică la nivelul aşteptărilor.
Se pot identifica o serie de factori critici care cauzează eşecul proiectelor.
Factorii cauzali care implică conducerea sunt responsabili de circa 65% din rata
eşecului proiectelor:
- administrare necorespunzătoare în predarea proiectelor;
- comunicare deficitară între beneficiarii proiectului;
- competenţe scăzute (şi lipsa abilităţilor);
- metode de estimare nepotrivite;
- management deficitar al riscului;
- susţinere insuficientă din partea conducerii;
Factori cauzali de ordin tehnic sunt responsabili de circa 35% din rata eşecului
proiectelor:

33
McManus, J., Wood-Harper, T., - Understanding the Sources of Information Systems Project Failure,
Management Services, publicat în http://findarticles.com/p/articles/mi_qa5428/is_200710/ai_n21295900, 2007

40
 - cerinţe definite inadecvat sau deficitar;
- proiectare tehnică necorespunzătoare;
- instrumente de dezvoltare improprii;
- documentaţie pentru utilizatori inadecvată;
- planificare deficitară a testării;
- suport tehnic redus.
Există o accepţiune generală cu privire la faptul ca greşelile sunt acceptabile, pe când
eşecul nu e. Eşecul este considerat o eroare absolută de pe urma căruia nu se mai poate
recupera. S-a ajuns la concluzia că succesul a fost în mare parte datorat creării planurilor
pentru situaţii neprevăzute şi alternarea abordărilor în cazul proiectelor cu un grad ridicat de
risc.

CAPITOLUL 3: INFLUENŢA TESTĂRII ASUPRA SUCCESULUI

DEZVOLTĂRII SISTEMELOR INFORMAŢIONALE

41
 Testarea este ultima ocazie pentru revizuirea cerinţelor sistemului, a specificaţiilor de
proiectare şi a programelor sursă.
Testarea este adesea văzută ca o modalitate de identificare, pe cât posibil şi cu un
efort minim, dacă un sistem software are erori şi dacă realizează ceea ce s-a cerut.

3.1 Aspecte generale cu privire la organizarea testării

Testarea este un termen mai general care face referire la două noţiuni: verificarea şi
validarea34. Verificarea reprezintă procesul de evaluare a sistemului sau a unei componente
a lui, pentru a se determina dacă o anumită funcţie a fost implementată corect, oferind
răspunsul la întrebarea: „A fost construit bine sistemul?”. Validarea poate fi definită ca
procesul de evaluare a sistemului sau a unei componente a lui, pentru a se determina dacă
sunt respectate cerinţele funcţionale identificate în faza de anliză, răspunzând la întrebarea:
„A fost construit sistemul care trebuie?”
Este aproape imposibil să testezi un sistem atât de meticulos încât să se poată pretinde
că nu mai are nici o eroare. Adeseori, încercarea de a corecta o eroare poate genera o mulţime
de alte erori, care la rândul lor trebuie corectate şi testate exhaustiv. Este mult mai realist să
ne gândim la testare ca la un proces de găsire a erorilor. Când s-a ajuns la un stadiu în care se
pare ca sistemul merge perfect, asta nu ne duce neapărat cu gândul că nu mai există erori, ci,
pur şi simplu, înseamnă că acestea nu au fost încă descoperite.
De asemenea este greu de stabilit dacă un sistem face ceea ce trebuie. Testarea unui
sistem informaţional nu poate decât să confrunte un anume set de programe cu nişte
specificaţii de cerinţe exprimate prin diagrame de tip informal. Deşi nu este cel mai adecvat
instrument, procesul de testare rămâne principala unealtă pe care o folosesc dezvoltatorii
pentru a verifica dacă sistemul a fost bine construit.
În general, testarea implică elaborarea planurilor testelor, stabilirea standardelor
testării, precum şi încadrarea întregii activităţi de testare în ciclul de viaţă al sistemelor, în
vederea asigurării completitudinii planurilor de testare a programelor.
O prezentare schematică a procesului de testare este evidenţiată în următoare figură.

34
Oprea, D., Meşniţă, G., Dumitriu, F., Proiectarea sistemelor informaţionAle, Editura Universităţii „Al. Ioan
Cuza", 2006, Iaşi, p. 305.

42
 Stabilirea
subset al
rezultatelor
rezultate
datelor de
aşteptate
intrare
rezultatele
testării Documentele
Strategia Compararea
P testării rezultatelor
testării

subset al
rezultate
datelor de
obişnuite
intrare
P

Sursă: Prelucrare după van Vliet, H., - Software Engineering. Principles and Practices, John Wiley &
Sons, LTD, Chichester, 2000, p. 401.
Fig. nr. 3.1 Schema generală a procesului de testare
Prima activitate se referă la definirea strategiei testării, care are drept scop stabilirea
setului minim al datelor de test care să satisfacă cerinţele testării, cuantificate prin
intermediul criteriilor de acceptabilitate.
După stabilirea criteriilor de acceptabilitate, se va trece la generarea setului de teste
care să răspundă acestor criterii, adică a unui subset al datelor de intrare în P, unde P
reprezintă obiectul supus testării.
Odată definit setul de teste, se va trece la determinarea rezultatelor aşteptate, pentru
fiecare test în parte şi apoi la execuţia componentei P. În final, se realizează compararea
rezultatelor obţinute în urma execuţiei cu cele aşteptate, eventualele diferenţe semnalând
existenţa unor erori, ce vor fi transmise spre rezolvare proiectanţilor sau programatorilor
responsabili.
Datele de test au menirea de a fi utilizate pentru a verifica dacă programul executat se
comportă aşa cum se doreşte şi dacă produce rezultatele aşteptate. Ele pot fi incluse în mai
multe categorii:
♦ date valide, care ar trebui să fie normale pentru sistem. Testele din această
categorie includ, de asemenea, condiţiile de limită, cum ar fi date atipice, dar care se
încadrează în limitele sistemului;
♦ date invalide, care nu ar trebui introduse în mod normal în sistem;

43
 ♦ date care în sine sunt valabile, dar nu sunt acceptabile în starea lor curentă;
♦ date de testare a performanţelor sistemului, cum ar fi viteza de răspuns sau
manipularea unui volum mare de date.
Activitatea de testare este ghidată după anumite principii35:
1. testele trebuie concepute de o asemenea manieră astfel încât să urmărească
respecterea cerinţelor utilizatorilor;
2. testele trebuie planificate cu mult timp inainte de începerea activităţii de testare;
3. testarea trebuie să înceapă cu detaliile, desfăşurată la nivelul modulelor
componente;
4. testarea exhaustivă nu este posibilă;
5. testarea trebuie să fie realizată de persoane care nu au fost implicate în fazele
anterioare de dezvoltare a sistemului, dacă se doreşte ca această activitate să fie cât mai
eficientă;
6. testarea nu vizează numai produsul final, ci şi rezultatele fazelor intermediareale
dezvoltării sistemului.
Acest ultim principiu trebuie consolidat deoarece, în mod tradiţional, în procesul de
dezvoltare a sistemului a sistemelor informaţionale, testarea a fost lăsată până la ultimele
stadii ale proiectului. Totuşi, activităţile de testare sau de verificare a calităţii, pot, şi ar trebui
realizate pe parcursul întregului proces de dezvoltare. De asemenea, înainte de proiectarea şi
implementarea sistemului este necesară verificarea cerinţelor sistemului. Prin această
activitate se urmăreşte dacă36: cerinţele sunt detaliate suficient, astfel încât să permită
proiectarea şi implementarea lor; cerinţele nu intră în contradicţie unele cu altele.

3.2 Tehnici de testare

Tehnicile de testare au un caracter preponderent euristic şi empiric, mai puţin

fundamentat teoretic, ceea ce explică multitudinea tehnicilor prezentate în literatura de
specialitate.
35
Oprea, D., Meşniţă, G., Dumitriu, F. - Op cit., p. 306.
36
Richard, L.K., - Testing Requirements, www.gantthead.com, accesat în data de 19 mai 2008, la ora 19:23.

44
 În fazele incipiente ale dezvoltării37 (ex.: analiză şi proiectare) activităţile de testare
sunt menite să stabilească, pe cât posibil, dacă cerinţele utilizatorilor au fost complet înţelese.
Tipul de testare ce poate fi utilizat în această etapă este de natură diferită faţă de cel care este
efectuat în timpul şi după implementare. Înaintea implementării, sunt testate idei; în timpul şi
după implementare este testat cod.

3.2.1 Testare pre-implementare

Testarea pre-implementare nu este realizată de programatori sau măcar, în mod

normal, de membrii unei echipe de testare, ci de către o echipă de referenţi care pot fi:
manageri de proiect, clienţi sau dezvoltatori – de fapt oricine din cei implicaţi activ în
procesul de dezvoltare. Testarea timpurie este mai degrabă ca o recenzie a ceea ce s-a făcut
până la momentul respectiv, o trecere în revistă a unor idei şi concepte.
La finalul fiecărei etape, echipa de dezvoltare a sistemului trebuie să verifice cerinţele
specificate în etapa precedentă şi să refacă dacă este necesar.
În figura următoare este prezentată o variantă simplificată a ciclului de viaţă a
sistemului în care este evidenţiată şi etapa de testare.

Cerinţele
clientului
Elaborare
Validare cerinţe

Sistem
Verificare
operaţional
Specificaţii

Instalare şi
Validare
întreţinere

Proiectare

Sistem
Testare
funcţional
Specificaţii
Implementare
tehnice

Sursă: Prelucrare după Britton, C., Doake, J. - Software System Development: A Gentle Introduction,
Fourth Edition, MacGraw-Hill Education, Glasgow, 2006, p. 176.

37
Britton, C., Doake, J. - Software System Development: A Gentle Introduction, Fourth Edition, MacGraw-Hill
Education, Glasgow, 2006, p. 175.

45
 Fig. nr. 3.2 Ciclul de viaţă al sistemului – variantă simplificată

Referenţii verifică dacă documentul cu specificaţiile cerinţelor produs la finalul etapei

de elaborare a cerinţelor captează exact cerinţele clientului şi dacă cerinţele specificate sunt
consistente şi reale. Setul de soluţii alternative produse în etape de proiectare vor fi revizuite
pentru a vedea dacă îndeplinesc condiţiile specificate, dacă sunt posibile din punct de vedere
tehnic, operaţional şi financiar, şi dacă sunt compatibile cu resursele şi politicile clientului. În
specificaţiile tehnice produse la finalul etapei de proiectare încă se mai sunt verificate idei şi
nu cod, deşi acum aceste idei sunt exprimate într-un mod formal în cadrul documentelor de
proiectare. Una din soluţiile propuse va fi selectată şi proiectată în detaliu. Referenţii vor
verifica dacă schiţa îndeplineşte condiţiile subliniate în etapele anterioare, dacă este completă
şi dacă este compatibilă cu cerinţele de performanţă de ordin logic şi fizic.
Următorul set de teste va fi efectuat asupra codului, şi astfel, testarea trece în faza de
post-implementare. Iniţial aceasta va fi realizată de către un programator sau de echipă de
testare.

3.2.2 Clasificarea tehnicilor de testare

Mosley face o diferenţiere între teste ghidându-se după două criterii38:

1. în funcţie de modul în care testarea angajează tehnici statice sau dinamice, poate
fi:
a. testare statică care verifică programele sursă fără ca acestea să fie lansate în
execuţie;
b. testare dinamică care implică execuţia programelor.
2. în funcţie de modul în care testarea poate fi efectuată, poate fi:
a. testare automată care este efectuată sub controlul calculatorului;
b. testarea manuală care se desfăşoară sub controlul omului.

38
Mosley, D.J., - The Handbookof MIS Application Software Testing, Yourdon Press, Englewood Cliffs, New
Jersey, 1993, citat în Oprea, D., Meşniţă, G., Dumitriu, F., Proiectarea sistemelor informaţionAle, Editura
Universităţii „Al. Ioan Cuza", 2006, Iaşi, p.308.

46
 Cele două tehnici de clasificare sunt relativ redundante, în sensul că majoritatea
tehnicilor de testare manuală se regăsesc şi în categoria tehnicilor de testare statică, atât timp
cât, în general, tehnicile manuale nu implică execuţia programelor39, iar tehnicile de testare
automată presupun, de cele mai multe ori, execuţia programelor, deci ele sunt considerate
tehnici de testare dinamică.
În funcţie de sursele de de informaţii utilizate pentru generararea cazurilor de test se
remarcă două abordări cărora le corespund două categorii de tehnici de testare: tehnici tip
“cutia neagră” şi tehnici tip ”cutia albă”40.
Testarea tip “cutia neagră”, numită şi funcţională, nu ia în considerare detaliile
procedurale ale componentei testate, ci vizează funcţiile acesteia. Se vor alege date de test
pentru fiecare funcţie în parte şi de interes vor fi doar datele de intrare şi rezultatele aşteptate
pentru fiecare funcţie.
Testarea tip “cutia albă”, numită şi structurală, presupune concentrarea atenţiei asupra
detaliilor procedurale ale componentei testate, pentru a putea determina cazurile de test şi
datele de intrare necesare. Ea implică identificarea cazurilor de test care permit execuţia
tuturor ramurilor programului, derivate din structurile de control alternative şi/sau repetitive.
Prin urmare, se va defini câte un caz de test pentru fiecare ramură logică a programului.
Testarea tip “cutie albă” urmăreşte generarea cazurilor de test, astfel încât să fie
asigurată:
♦ execuţia fiecărei structuri de control alternative pe ambele ramuri;
♦ execuţia fiecărei structuri de control repetitive, atât la numărul minim, cât şi la
numărul maxim al iteraţiilor, dar şi a unui intermediar;
♦ verificarea valididităţii structurilor de date interne ale programelor.
Testarea de tip “cutie neagră” urmăreşte să răspundă la următoarele întrebări:
♦ cum poate fi testată funcţionalitatea aplicaţiei?
♦ cum pot fi testate performanţele aplicaţiei?
♦ ce volum de date şi ce rată a intrărilor poate accepta sistemul?

39
van Vliet, H., - Software Engineering. Principles and Practices, Second Edition, John Wiley & Sons, LTD,
Chichester, 2000, p. 399, Oprea, D., Meşniţă, G., Dumitriu, F., Proiectarea sistemelor informaţionAle, Editura
Universităţii „Al. Ioan Cuza", 2006, Iaşi, p.308.
40
Oprea, D., Meşniţă, G., Dumitriu, F. - Op cit., p. 309.

47
 ♦ ce efect va avea asupra modului de funcţionare a sistemului a anumită combinaţie a
datelor de intrare?
De ce ar fi totuşi necesare ambele tipuri de testare?
Pentru că, pe de o parte, testarea exhaustivă a programelor nu este posibilă, deci nu
este suficientă testarea tip “cutie albă”, iar pe de altă parte, multe erori apar atunci când se
proiectează şi se implementează condiţii sau structuri de control care privesc cazurile
speciale ale funcţiei tratate şi care nu fac parte din fluxul logic principal al programului, deci
nici testarea de tip “cutie neagră” nu este suficientă.
De reţinut este faptul că testarea tip “cutie alb㔺i testarea de tip “cutie neagră” sunt
complementare şi pentru ca o testare să fie de bună calitate ambele trebuie să fie utilizate.

3.2.3 Testarea structurilor de control repetitive

Structurile repetitive stau la baza majorităţii algoritmilor implementati în programe.

Dacă le-am clasifica din punctual de vedere al testării, acestea pot fi împărţite în trei
categorii: simple, imbricate şi concatenate. Regulile de testare a structurilor repetitive se
încadrează în tehnicile tip “cutie albă”.
În Figura 3.3.2 sunt prezentate categoriile de structuri de control repetitive.

Structuri Structuri Structuri

repetitive repetitive repetitive
simple imbricate concatenate

48
 Fig. nr. 3.3 Tipuri de structuri de control repetitive

În cazul structurilor repetitive simple, dacă ar fi să considerăm n ca numărul maxim

de iteraţii, atunci ar trebui realizate următoarele teste: nici o iteraţie (adică nici o trecere prin
respectiva buclă), o singură trecere, două treceri, m treceri (unde m<n), n-1, n, n+1 treceri.
Pentru structurile repetitive imbricate, numărul testelor posibile creşte în progresie
geometrică cu nivelul de imbricare.
Structurile repetitive concatenate pot fi testate în manieră descrisă în cazul celor
simple, dacă fiecare structură este independentă de celelalte, sau asemănător celor imbricate,
dacă nu sunt independente.

3.2.4 Examinările şi execuţiile de probă

Ambele tehnici de testare sunt manuale.

Examinările presupun evaluarea programelor linie cu linie în vederea depistării
manuale a unor erori frecvent întâlnite, fără a se urmări efectul fiecărei instrucţiuni.
O echipă de examinare este formată din patru membri, fiecare cu roluri bine definite.
Moderatorul este responsabil pentru organizarea şedinţelor de lucru, le conduce, asigură ca
fiecare participant să urmeze procedurile stabilite, astfel încât aceştia să lucreze ca o echipă.
Echipa mai conţine doi inspectori (examinatori) care vor interpreta programul sursă. Din
echpă trebuie să mai facă parte şi programatorul, respectiv cel care a scris codul (programul
sursă), deoarece cunoaşte cel mai bine programul şi poate fi solicitat de inspectori să explice
ce a intenţionat să facă dacă se consideră că ceva este greşit, neclar sau nu funcţioneză corect.
Execuţia de probă, spre deosebire de examinări, presupune analiza programelor prin
urmărirea efectului fiecărei instrucţiuni pe baza unor date de test.
Pe lângă descoperirea unui număr mare de erori (dupa unele estimări între 60% si
90%)41, aceste două tehnici mai prezintă unele avantaje: promovarea spiritului de echipă,
membrii unei echipe pot învăţa unii de la ceilalţi şi pot acumula cunoştinţe noi privind
tehnicile şi stilurile de programare, erorile tipice care pot apărea la scrierea programelor.

3.3 Strategia testării sistemelor informaţionale

41
Oprea, D. – Analiza şi proiectarea sistemelor informţionale economice, Editura Polirom, Iaşi, 1999, p. 481.

49
 În cadrul demersului de dezvoltare a sistemelor informaţionale, este necesară
definirea unui cadru de desfăşurare a fazei de testare concretizat prin intermediul strategiei
testării sistemelor informaţionale ce cuprinde diverse metode de elaborare a cazurilor de test
şi urmăreşte o succesiune de paşi foarte clar stabiliţi.
Indiferent de cine o elaborează, strategia testării trebuie să prezinte următoarele
caracteristici:
♦ procesul de testare trebuie să aibă o traiectorie ascendentă, adică să înceapă de jos,
de la nivelul modulelor, şi să se termine printr-o validare a sistemului informaţional ca un
întreg;
♦ tehnicile de testare utilizate trebuie să fie adaptate astfel încât să fie cele mai
adecvate în momentul respectiv al testării;
♦ realizarea testării trebuie să fie făcută fie de o echipă independentă, în cazul
proiectelor de mare amploare, fie de membrii echipei de dezvoltare a sistemului, în cazul
proiectelor de o mai mică amploare.

3.3.1 Testarea modulelor

Scopul principal urmărit prin testarea la nivelul modulelor constă în identificarea şi

corectarea unui număr cât mai mare de erori, înainte de integrarea lor în unităţi de program
mai complexe, în care erorile sunt mult mai greu de localizat şi eliminat.
Testarea modulelor presupune utilizarea mai multor tehnici de testare odată cu
parcurgerea a mai multe faze. Se începe cu testarea la nivelul interfeţelor modului, pentru
a se asigura că intrările şi ieşirile în/din modul sunt corecte. Urmează testarea structurilor
de date locale, prin care se verifică integritatea datelor memorate temporar de-a lungul
ramurilor de execuţie din modulul respectiv. Cele mai importante teste, dintre cele efectuate
la nivelul modulelor, sunt cele care vizează căile de execuţie a programului, prin care se
urmăreşte depistarea erorilor legate de calcule greşite, comparaţii eronate în expresiile logice,

50
controlul logic necorespunzător al execuţiei. Testarea modulelor se încheie cu analiza
valorilor limită.
Un modul nu este de sine-stătător, el fie este apelat de module situate pe un nivel
ierarhic superior, fie apelează module de pe nivele ierarhice inferioare, făcând astfel
imposibilă testarea dinamică. Pentru a preîntâmpina acest incovenient, pentru fiecare modul
testat, se vor concepe două tipuri speciale de module42: subordonate (stub modules) şi
director (drive module).
Un modul director este văzut ca un program principal al cărui rol constă în a simula
condiţiile normale de exploatare a programului în care va fi executat modulul testat. Un
modul subordonat are rolul de a înlocui un modul invocat de modulul testat, fiind un
subprogram care va avea aceeaşi interfaţă ca cel pe care îl inlocuieşt, va realiza un minim de
prelucrări, va semnala faptul că a fost apelat, după care va reda controlul modulului testat.

3.3.2 Testarea integrării

Atâta timp cât au fost testate modulele individual şi se presupune că funcţionează

impecabil, ar putea apărea întrebarea: De ce mai este necesară testarea integrării modulelor?
Răspunsul la această întrebare este mai mult decât simplu: pentru că pot apărea alte erori care
nu pot fi depistate prin testarea la nivelul modulelor.
Pentru integrarea modulelor se poate apela la una din următoarele strategii:
♦ strategia integrării treptate a modulelor, presupune construirea şi testarea
programului în paşi mici, astfel încât erorile să fie uşor de localizat şi corectat, iar activitatea
de testare a integrării să fie realizată sistematic;
♦ strategia integrării deodată a modulelor, deşi nerecomandată, presupune
construirea programului direct prin integrarea modulelor şi abia apoi testarea programului ca
un tot.
Există două modalităţi prin care se poate realiza testarea integrării: fie de sus în jos
(top-down), fie de jos în sus (bottom-up).
Testarea de sus în jos începe cu modulul principal, după care se parcurge structura
ierarhică a programului, fie orientat pe verticală integrând toate modulele de pe câte o
ramură a structurii ierarhice, fie orientat pe orizontală reunind iniţial modulele situate pe

42
Oprea, D., Meşniţă, G., Dumitriu, F. - Op cit., p. 318.

51
nivelul ierarhic imediat inferior modulului principal ca apoi să se continue cu fiecare nivel
ierarhic.
Testarea de jos în sus presupune construirea şi testarea treptată a programului,
începând cu modulele depe ultimele niveluri ierarhice.
În practică, cel mai adesea, acestea abordări sunt utilizate împreună, prezentând
principalul avantaj de a reduce numărul de module director şi subordonate care trebuiesc
create.

3.3.3 Testarea la nivelul sistemului

Deşi la o primă vedere această testare ar fi similară cu testarea integrării, se

deosebeşte prin direcţionarea testelor spre acele particularităţi care se găsesc la nivelul
sistemului: securitatea, refacerea în cazul unor căderi ale sistemului, performanţele.
Dacă ar fi să categorisim testele care sunt elaborate în această fază în funcţie de
scopul pe care îl urmăresc, se evidenţiază43:
♦ testarea refacerii vizează să producă o cădere a sistemului şi să verifice în ce
măsură refacerea este realizată corespunzător;
♦ testarea securităţii vizează verificarea funcţionării corespunzătoare a
mecanismelor de de protecţie în cazul unor încercări de atac asupra sistemului sau a unor
accesări neautorizate;
♦ testarea solicitării sistemului urmărşte confruntarea acestuia cu situaţii ieşite din
comun, în timp ce testele din precedentele etape vizau modul de funcţionare în condiţii
normale de lucru;
♦ testarea performanţelor sistemului implică de cele mai multe ori şi testarea
solicitării şi apreciaază performanţele tehnice hard şi soft.

3.3.4 Testarea de acceptare

Acest tip de testare constituie ultima oportunitate de verificare a sistemului înainte de

a fi valorificat. Ca o particularitate faţă de testele precedente, se impune ca testarea de
acceptare să se realizeze într-un mediu asemănător cu cel în care va funcţiona şi de către cei

43
Pressman, R. S., - Software Engineering. A Practitioner’s Approach, Fifth Edition, McGraw-Hill Publishing
Company, London, 2000, p. 483-485.

52
care îl vor folosi. De asemenea, este necesar ca testele concepute să fie astfel elaborate încât
să exerseze funcţiile aplicaţiei care sunt dirijate către utilizator.
În decursul testării de acceptare se parcurg, de obicei, două etape: testarea alfa şi
testarea beta.
Testarea alfa presupune utilizarea unor date nereale, dar reprezentative şi se
efectuează de către client la sediul producătorului, sub monitorizarea echipei de dezvoltare a
sistemului.
Testarea beta presupune utilizarea unor date reale şi se efectuează la sediul clientului,
fără a benficia de monitorizarea echipei de dezvoltare.

3.4 Alte tipuri de testare

Testarea regresivă (regression testing) - se verifică dacă s-a modificat neaşteptat

comportamentul aplicaţiei în urma implementării unor noi cerinţe/schimbări (change
requests).
Testarea negativă (negative testing) - se solicită aplicaţia, producând deliberat
cazuri complicate, neobişnuite sau particulare pentru a forţa apariţia erorilor.
Testarea de încărcare (load testing) - se determină punctele slabe ale aplicaţiei şi
dacă sunt necesare îmbunătăţiri ale infrastructurii hardware sau software prin măsurarea
caracteristicilor de performanţă şi scalabilitate a principalelor componente ale aplicaţiei web;
de regulă aceasta se realizează prin creşterea numărului de sesiuni utilizator sau a
conexiunilor TCP/IP.
Testarea de desfacere (release testing)44 – testele de desfacere verifică dacă produsul
ce urmează a fi livrat este complet: dacă CD-urile conţin fişierele care trebuie, dacă sunt
utilizate versiunile corecte ale fişierelor, dacă CD-urile nu au viruşi şi dacă este inclusă
documentaţia potrivită. Se va efectua şi o verificare amănunţită ca aplicaţia să realizeze ceea
ce se aşteaptă să realizeze, prin compararea cu documentaţia cerinţelor, materialul de
promovare şi documentaţia utilizatorilor.

3.5 Testare manuală vs. testare automată

44
Britton, C., Doake, J. – Op. cit. , p. 179.

53
 Testarea manuală, mult timp văzută ca singura soluţie de a descoperi eventualele
defecte, întârzie foarte mult lansarea pe piaţă a produsului şi induce cheltuieli semnificative
mai ales în cazul descoperirii efectelor laterale – atât în procesul dezvoltării unei aplicaţii cât
şi în cazul de schimbări ulterioare.
Totodată procedurile de testare manuală, prin natura lor limitată, nu reuşesc să
descopere toate defectele şi nu au nici o şansă să simuleze condiţii de utilizare simultană,
intensivă, a unei aplicaţii.
Există numeroase căi de a îmbunătăţi procesul de testare, una dintre cele mai eficiente
fiind testarea automată. Testele automate execută o secvenţă de acţiuni fără intervenţie
umană şi pot simula utilizarea unei aplicaţii în condiţii de simultaneitate ridicată. În general,
majoritatea produselor necesită să fie testate de mai multe ori, pe mai multe platforme
software şi hardware, ca şi după schimbările ulterioare sau la lansarea unei noi versiuni de
produs. Prin folosirea testării automate, costurile testărilor repetate se reduce aproape la zero.

3.5.1 Compararea testării manuale cu testarea automată

Testarea manuală şi testarea automată sunt mai degrabă două procese diferite, decât
două căi diferite de a executa acelaşi proces: dinamica lor este diferită precum şi modul de a
releva erorile45.
Testarea manuală este mai folositoare în situaţiile în care este nevoie urgent de
rezultatele unor tipuri de teste specifice şi limitate, când se doreşte ca timpul de feedback să
fie foarte scurt, iar costurile să fie relativ mici. Cum îmbunătăţirea calităţii produsului
implică costuri adiţionale pentru găsirea erorilor şi gestionarea acestora până la repararea lor
definitivă, testarea manuală s-a dovedit a fi în timp extrem de costisitoare. Testarea manuală
pe scară largă presupune alocarea de resurse hardware şi umanedestul de mari, iar riscul să
apară erori este amplificat de factorul uman.
Testarea automată necesită un efort iniţial mai mare pentru planificarea, organizarea
şi producerea testului, criteriul principal în obţinerea de rezultate bune fiind planificarea
atentă, amănunţită şi precisă a acestuia.

45
Eftimescu, D., Ilioiu, A., Introducere în testarea automată, 25 martie 2002,
http://www.securenet.ro/ro/publications/doc/testarea_automata.pdf, accesat în data de 13 martie 2008, la ora
23:12.

54
 O alternativă interesantă este aşa-numita testare parţială. Această soluţie este
combinaţie de jumătate testare manuală şi jumătate testare automată, aceasta din urmă fiind
folosită numai acolo unde se pot obţine beneficii maxime.
Testarea automată se doreşte a fi soluţia ideală pentru reducerea timpului de
dezvoltare şi a costurilor. O echipă de testeri poate să pornească uneltele de testare automată,
să le lase să ruleze şi în final să colecteze şi analizeze rezultatele. Timpul este astfel mai bine
organizat şi poate fi petrecut pentru izolarea şi raportarea erorilor.

3.5.2 Avantajele utilizării testării automate

Printre avantajele utilizării testării automate putem enumera:

a) avantaje privind eficienţa şi costurile
♦ prevenirea erorilor prin abordarea structurată a procesului de dezvoltare a
proiectului;
♦ detecţia erorilor care au ajuns până în faza de producţie (prin teste de regresie
automată);
♦ reutilizarea informaţiei acumulate (condiţii de test, scripturi);
♦ reducerea creării de noi scripturi (refolosindu-le şi adaptându-le pe cele vechi);
♦ execuţia automată a testelor de performanţă în fazele de început ale proiectului
poate evita eforturile de reproiectare în fazele ulterioare;
♦ odată ce scripturile de testare automată sunt implementate, o parte din personal
poate fi redirecţionat către alte necesităţi.
b) avantaje privind economia de timp
♦ analiză rapidă şi exactă în cazul schimbării parametrilor sistemului;
♦ durată scurtă a ciclurilor de testare;
♦ estimări mai exacte pentru procesul de planificare a testului;
♦ posibilitatea efectuării mai multor teste (scripturile de testare pot fi rulate şi după
orele de program economisind astfel timp);
♦ generarea rapidă a condiţiilor de testare.
c) avantaje privind calitatea
♦ o mai bună înţelegere a scopului testării;
♦ o acoperire mai mare a elementelor de testat;

55
 ♦ rezultate mai consistente datorită repetabilităţii testelor;
♦ compararea automată a rezultatelor.

3.5.3 Procesul testării automate

Într-o abordare mai detaliată testarea automată înseamnă46:

1. planificare
1. identificarea cerinţelor şi a funcţionalităţilor;
2. gruparea acestora în condiţii de test;
3. crearea cazurilor de test pentru aceste condiţii;
2. proiectare
1. construcţia scripturilor de test;
2. generarea testelor de rulare;
3. execuţie
1. crearea scenariului de rulare a scripturilor;
2. rularea uneltelor monitor pentru înregistrarea datelor;
3. înregistrarea rezultatelor pentru fiecare rulare;
4. raportarea şi gestionarea erorilor;
4. management
1. generarea rapoartelor şi graficelor;
2. controlul dintr-un singur punct de comandă;
3. documentarea permanentă a stadiului curent al proiectului.
Procesul de testare automată presupune un efort de management deosebit 47. Acest
proces începe încă din faza de analiză a aplicaţiei şi continuă în toate etapele de dezvoltare.

46
Eftimescu, D., Ilioiu, A., - Introducere în testarea automată, publicat în 25 martie 2002,
http://www.securenet.ro/ro/publications/doc/testarea_automata.pdf, accesat în data de 13 martie 2008, la ora
23:12.
47
Pettichord, B.,- Success with test automation, versiune din 28 iunie 2001,
http://www.io.com/~wazmo/succpap.htm, accesat în data de 15 martie 2008, la ora 13:22.

56
 Analiza
Planificare Testare funcţională rezultatelor
test regresivă

Monitorizare
Servicii performanţe
Managementul Managentul
cerinţelor defectelor

Diagnosticarea Generare
Identificarea
cauzelor advertismente
problemei
principale în timp real

Sursă: Preluare după Eftimescu, D., Ilioiu, A., - Introducere în testarea automată, publicat în 25
martie 2002, http://www.securenet.ro/ro/publications/doc/testarea_automata.pdf, accesat în data de 13 martie
2008, la ora 23:12.

Fig. nr. 3.4 Diagrama succesiunii etapelor procesului de testare automată

În figura precedentă se pot observa etapele procesului, ordinea şi frecvenţa acestora,

precum şi locul central pe care îl ocupă managementul defectelor şi serviciile. Un factor
important este menţinerea centrală a comunicării între etape pentru managementul erorilor.

3.5.4 Limitele testării automate

Sunt multe lucruri pe care uneltele de testare automată nu le pot face şi este important
să se cunoască aceste limitări pentru a alege pe cea mai potrivită. Un sistem de testare
automată nu poate spune când ceva "arată bine" pe ecran sau când o poză sau fereastră nu
este bine încadrată. De asemenea un test automat nu poate decide dacă logica programului
are lipsuri funcţionale decât în măsura în care au fost definite complet cerinţele aplicaţiei
respective. Unele teste, mai ales pentru aplicaţii mici şi pentru aplicaţii care se concentrează

57
mai ales pe grafică şi nu pe business logic, sunt mult mai uşor realizabile de către operatorul
uman decât de către un computer. De aceea trebuie alcătuit un plan bine definit al procedurii
de testare, când, unde şi în ce condiţii este fiabilă introducerea automatizării.
Testarea automată nu va putea înlocui în întregime testarea manuală şi nici nu trebuie.
Tester-ii pot să observe cum un utilizator poate interacţiona cu produsul, în timp ce un sistem
de testare automată nu poate întotdeauna să prevadă aceste acţiuni sau să găsească cea mai
bună cale de a le testa. Dacă sunt bine folosite, programele de testare automată măresc
considerabil productivitatea asigurării calităţii (Quality Assurance), economisesc costuri,
măresc semnificativ consistenţa şi calitatea produsului şi ajută la optimizarea şi accelerarea
procesului de dezvoltare al unei aplicaţii. Deja în ţările cu tradiţie în dezvoltarea de software
există cerinţa ca toate produsele software din sectorul militar, medical, guvernamental şi
financiar să fie testate cu unul din sistemele recunoscute de testare automată, iar rapoartele
automate asupra felului cum a decurs testarea constituie baza acceptării unei aplicaţii de către
client48.

3.6 Documentarea testării

Se pot identifica mai multe tipuri de documente49:

Specificaţii de testare. Pregătirea testelor este, de departe, cea mai importantă etapă
din cadrul unui proiect de testare a aplicaţiilor. În acest stadiu trebuie create testele şi definite
cerinţele pentru mediul de testare:
♦ planul de testare (strategia de testare) stabileşte cum va fi manevrată,
programtă şi executată testarea;
♦ specificaţiile pentru proiectarea testelor definesc logic ce anume trebuie testat
prin examinarea cerinţelor şi caracteristicilor care vor putea fi apoi transformate în condiţii de
test. Aceste specificaţii nu înregistrează valorile ce vor fi introduse în teste, dar descriu
cerinţele pentru definirea acestor valori şi oferă o legătură între condiţiile de testare şi
cazurile de testare;

48
Isenberg, H.M., - The practical organization of automated software testing, http://www.automated-
testing.com/PATfinal.htm, accesat în data de 30 aprilie, la ora 14:20.
49
Standardul IEEE 829 privind documentarea testării aplicaţiilor, http://www.acutest.co.uk/acutest/ieee829,
accesat în data de 17 mai 2008, la ora 21:20.

58
 ♦ specificaţiile cazurilor de test convertesc condiţiile de test în cazuri de test prin
adăugarea de date reale, condiţii predefinite şi rezultate aşteptate. Cazurile de test pot fi
elaborate când proiectul de testare este complet. Un caz de test poate acoperi una sau mai
multe condiţii de test prezente în plan şi ar trebui să includă:
- date precise necesare pentru execuţia testului formate dintr-o combinaţie de date
de intrare şi date rezultate din aplicaţie şi sistem;
- date de ieşire şi rezultate aşteptate;
- condiţii predefinite care vor fi punctul de start pentru fiecare test. O
caracteristică (cerinţă) din plan poate fi testată în una sau mai multe cazuri de test, şi un caz
de test poate verifica una sau mai multe cerinţe. Scopul este ca un set de cazuri de test să
verifice fiecare caracteristicădin plan cel puţin o dată;
♦ proceduri de testare care descriu în termeni practici cum sunt executate testele.
Sunt dezvoltate atât din specificaţiile de proiectare a testelor cât şi din specificaţiile cazurilor
de test. Documentul cu proceduri descrie fizic cum anume va efectua tester-ul testele,
structura fizică necesară şi paşii pe care trebuie să-i urmeze procedura;
♦ raportul de transmitere a obiectelor de test specifică care obiecte sunt
disponibile pentru testare. Acest document oferă detalii cu privire la etapele anterioare ale
testării. Include numele persoanei responsabile pentru fiecare obiect, locaţia sa fizică şi
statutul.
Execuţia testării. Programul care prevede ce cazuri de test sunt rulate şi când este
definit în palnul de testare, în timp ce rezultatele sunt înregistrate în jurmalul testării şi în
raportul incidentelor.
♦ jurnalul testării este o revizie de ansamblu care înregistraeză detaliile testării în
ordine cronologică. Acest jurnal consemnează ce cazuri de test au fost efectuate, ordinea
executării lor şi rezultatele testelor. Rezultatele sunt fie teste promovate, adică rezultatele
actuale şi cele aşteptate sunt identice, fie eşuate atunci când există discrepanţe. Dacă există o
discrepanţă sau mai multe sunt elaborate sau actualizate rapoartele incidentelor şi le sunt
menţionate identităţile în jurnal. Această evidenţă este importantă pentru că permite
verificarea progresului testării precum şi pentru că oferă informaţii valoroase cu privire la
identificarea cauzelor incidentelor;

59
 ♦ raportul incidentelor inventariază detaliile cu privire la orice comportamente şi
evenimente neaşteptate care necesită investigare. Raportul constă în amănuntele incidentului,
cum ar fi: rezultatele aşteptate, când a eşuat şi orice dovadă care să ajute la rezolvarea lor.
Această evidenţă trebuie să includă, dacă e posibil, o evaluare a impactului incidentului
asupra testării.
Raportarea testării constă într-un raport sumar al testării care să rezumeze şi să
evalueze testele. Eventual, testarea va fi finalizată conform criteriilor specificate în planul de
testare. Asta se întâmplă atunci când succesul sau eşecul sistemului se decide pe baza
rezultatelor. Raportul sumar înregistrează această informaţie.

60
 CAPITOLUL 4: TESTAREA UNITARĂ A CLASELOR JAVA
FOLOSIND UTILITARUL JUNIT

Testarea unitară s-a impus în ultima perioadă în dezvoltarea proiectelor scrise în

limbajul Java şi numai, pe măsura apariţiei unor utilitare gratuite de testare a claselor, care au
contribuit la creşterea vitezei de programare şi la micşorarea drastică a numărului de bug-uri.

4.1 JUnit – cadru de testare unitară regresivă

O unitate reprezintă cea mai mică parte testabilă a unei aplicaţii. În programarea
procedurală o unitate poate fi: un program individual, o funcţie, o procedură, o pagină web,
un meniu etc., în timp ce în programarea orientată-obiect cel mai mic unit este întotdeauna
reprezentat de o clasă, care poate fi o clasă de bază sau o superclasă, o clasă abstractă,
derivată sau o clasă- copil.
În industria de dezvoltare software pentru platforma Java, cel mai răspândit şi
acceptat cadru de lucru pentru testare rămâne în continuare JUnit. Popularitatea acestuia se
datorează următoarelor caracteristici:
♦ simplu de integrat în mediile de dezvoltare consacrate (prin dependenţe directe de
proiect sau, cel mai adesea, prin plug-in-uri dedicate – care furnizează şi console
specializate);
♦ se dovedeşte uşor de înţeles, învăţat şi aplicat;
♦ se bazează pe şabloane de proiectare consacrate şi familiarea programatorilor
pentru platforma Java.
Testarea regresivă reprezintă aceea testare făcută cu scopul de a determina dacă
modificările făcute cu scopul de a corecta defectele nu presupun defecte suplimentare50.
Elementele de testare unitară din JUnit furnizează instrumente de înregistrare şi
repetare a testelor, pentru ca testele unitare să poată fi repetate uşor mai târziu (de regulă
când se schimbă o parte din sistem), astfel încât dezvoltatorul să fie convins ca noile
modificări nu au stricat vechea funcţionalitate.

50
*** - Testarea Unitară în BlueJ, http://www.bluej.org/tutorial/testing-tutorial-romanian.pdf, accesat în data de
15 martie 2008, la ora 17:39.

61
 Scopuri ale framework-ului JUnit:
♦ Framework-ul trebuie să ne ajute să scriem teste utile;
♦ Framework-ul trebuie să ne ajute să creăm teste care să-şi menţină valoarea în
timp;
♦ Framework-ul trebuie să ne ajute să minimizăm costurile prin reutilizarea codului.
Printre avantajele folosirii utilitarului JUnit se numără51:
- se îmbunătăţeşte viteza de scriere a codului, concomitent cu creşterea calităţii
acestuia, deoarece prin scrierea testelor unitare se micşorează timpul de depanare, permiţând
refactorizarea mai uşoară, cu depistarea imediată a eventualelor erori inserate în codul
modificat;
- clasele de test sunt uşor de scris şi modificat pe măsură ce codul sursă se măreşte,
putând fi compilate împreună cu codul sursă al proiectului. Compilatorul testează sintaxa
codului sursă, în timp ce clasele de test validează integritatea codului;
- clasele de test JUnit pot fi rulate automat (în suită), rezultatele fiind vizibile imediat.
Se pot crea ierarhii de suite de test, care pot fi testate împreună sau separat, în funcţie de
cerinţete proiectului;
- clasele de test măresc încrederea programatorului în codul sursă scris şi îi permit să
urmărească mai uşor cerinţele de implementare ale proiectului, putând constitui şi o parte a
documentaţiei finale transmise clientului;
- JUnit este un utilitar gratuit, iar testele JUnit sunt scrise în Java şi beneficiază de
portabilitatea acestuia.

4.2 Crearea testelor utilizând JUnit

JUnit a fost proiectat pe baza a două modele (patterns): modelul Command şi modelul
Composite.
O clasă TestCase este un obiect command şi orice clasă ce conţine metode de test
trebuie să subclaseze clasa TestCase. O clasă TestCase se compune dintr-un număr de
metode publice testXXX(). Pentru a verifica rezultatele aşteptate şi cele curente se va invoca
una dintre metodele assert().

51
*** - Testarea unitară a claselor Java folosind utilitarul JUnit, http://inf.ucv.ro/~pm/junit/, accesat la data de
25 martie 2008, la ora 14:20.

62
 În tabelul următor se regăsesc explicaţii asupra metodelor assertXXX utilizate de
către JUnit.

Tabelul nr. 4.1 Metodele assertXXX utilizate de către JUnit

Metodele setUp() si tearDown() servesc la iniţializarea şi distrugerea oricărui obiect

utilizat în cadrul testelor. Fiecare test rulează într-un context propriu şi apelează metoda
setUp() înainte şi metoda tearDown() după fiecare metodă de test pentru a evita efectele
secundare dintre teste.
Instanţele TestCase se pot compune sub forma unor ierarhii TestSuite ce vor invoca
automat toate metodele testXXX() definite în fiecare instanţă TestCase. O clasă TestSuite
poate fi compusă din alte teste, instanţe TestCase sau alte instanţe TestSuite.
În următoarea figură este prezentată diagrama de clase a pachetului junit.framework.

63
 Fig. nr. 4.1 Diagrama de clase a pachetului junit.framework

Etapele creării manuale a unei clase de test sunt:

- se defineşte o subclasă a clasei TestCase;
- se suprascrie metoda setUp() pentru iniţializarea obiectelor testate;
- se suprascrie metoda tearDown() pentru eliberarea obiectelor testate;
- se defineşte una sau mai multe metode publice testXXX() ce testează obiectele şi
anticipează rezultatele aşteptate;
- se defineşte o metodă statică suite() de tip factory ce creează o suită TestSuite care
conţine toate metodele testXXX() din subclasa clasei TestCase;
- opţional se defineşte o metodă main() ce returnează subclasa TestCase în mod batch.
Se pot crea suite de test ce include o ierarhie de clase de test sau alte suite. Etapele
creării unei suite de test sunt:
- se defineşte o subclasă a clasei TestCase;
- se defineşte o metodă factory statică suite() ce creează o instanţă TestSuite ce
conţine toate testele;
- opţional se defineşte o metodă ce lansează instanţa TestSuite în mod batch.

64
 4.3 Exemplu de testare folosind Junit

Pentru exemplificare se utilizează o aplicaţie tip librărie virtuală în care se defineşte o

clasă Carte ce păstrează informaţii despre cărţile din librărie şi o clasă de tip coş de
cumpărături Coş ce păstrează lista cărţilor pe care un client doreşte să le cumpere.
Codul sursă al celor două clase este prezentat mai jos:
package cărţi;

public class Carte {

/*
* Titlul cărţii.
*/
private String titlu;
/*
* Autorul cărţii.
*/
private String autor;
/*
* Preţul cărţii.
*/
private double preţ;

public Carte(String titlu, String autor, double preţ) {

this.titlu = titlu;
this.autor = autor;
this.preţ = preţ;
}
/*
* Get titlul cărţii.
*@return Titlul cărţii.
*/
public String getTitlu() {
return titlu;
}

/*
* Get autorul cărţii.
*@return Autorul cărţii.
*/
public String getAutor() {
return autor;
}

/*

65
* Get preţul cărţii.
*@return Preţul cărţii.
*/
public double getPreţ() {
return preţ;
}

/*
* Testează dacă 2 obiecte carte sunt egale.
*@param obj The object
*@return true if object are equals.
*/
public boolean equals(Object obj) {
if (obj instanceof Carte) {
Carte b = (Carte) obj;
return b.getTitlu().equals(titlu);
}
return false;
}
}

66
package cărţi;

import java.util.*;

public class Coş {

/*
* Lista cu itemi.
*/
private List items;

/*
* Constructorul coşului.
*/
public Coş() {
items = new ArrayList();
}

/*
* Get preţtotal al itemilor din coş.
*@return Preţ total.
*/
public double getTotal() {
Iterator i = items.iterator();
double total = 0.00;
while (i.hasNext()) {
Carte carte = (Carte) i.next();
total = total + carte.getPreţ();
}
return total;
}

/*
* Adaugarea unui item la coş.
*@param carte Cartea de adaugat.
*/
public void addItem(Carte carte) {
items.add(carte);
}

/*
* Inlăturarea unui item din coş.
*@param carte Cartea de şters.
*@throws Exception If cartea not found to coş.
*/
public void removeItem(Carte carte) throws Exception
{
if (!items.remove(carte)) {
throw new Exception("Cartea nu a fost găsită.");
}
}

/*
* Numărarea itemilor din coş.
*@return Numărul itemilor.
*/ 67
public int getItemCount() {
return items.size();
 Un exemplu de clasă de test pentru coşul de cumpărături este prezentat în cele ce
urmează.
package cărţi;

import junit.framework.Test;
import junit.framework.TestCase;
import junit.framework.TestSuite;

/*
* Clasa coşTest este un exemplu de clasa TestCase.
*@created 20 mai 2008
*/
public class coşTest extends TestCase {
/*
* Obiect de tipul Coş ce va fi testat.
*/
private Coş coş;
/*
* Obiect de tipul Carte ce va fi testat.
*/
private Carte carte;

/*
* Constructor pentru o instanţă coşTest cu numele specificat.
*@param name Nume test.
*/
public cosTest(String name) {
super(name);
}

/*
* Iniţializează obiecte de test. Se apelează înaintea fiecărei metode de test.
*/
protected void setUp() {
coş = new Coş();
carte = new Carte("Unit testing", "John Smith", 35.95);
coş.addItem(carte);
}

/*
* Distruge obiectele testate. Se apelează după fiecare metodă de test.
*/
protected void tearDown() {
coş = null;
}

68
/*
* Testare inserare cărti in coş.
*/
public void testCarteAdd() {
Carte carte = new Carte("Extreme machines", "Thomas
Manner", 46.95);
coş.addItem(carte);
double PreţTotal = this.carte.getPreţ() + carte.getPreţ();
assertEquals(PreţTotal, coş.getTotal(), 0.0);
assertEquals(2, coş.getItemCount());
}

/**
* Test golire coş.
*/
public void testEmpty() {
coş.empty();
assertTrue(coş.isEmpty());
}
/*
* Testare scoatere cărţi din coş.
*@throws Exception Dacă nu există acea carte în coş.
*/
public void testCarteRemove() throws Exception
{
coş.removeItem(carte);
assertEquals(0, coş.getItemCount());
assertEquals(0.0, coş.getTotal(), 0.0);
}

/*
* Testare scoatere carte inexistentă din coş.
*/
public void testCarteNotFound()
{
try {
Carte carte = new Carte("Unit test", "John Scott", 35.95);
coş.removeItem(carte);
fail("Trebuie să semnaleze o excepţie");
}
catch (Exception w) {
}
}

/*

69
 * Asamblează şi returnează o suită de teste pentru toate metodele de test din clasa
* de test
*@return O clasă Test nenulă.
*/

/*
* Metoda Main.
*@param args Argumentele din linia de comandă.
*/
public static void main(String args[]) {
junit.textui.TestRunner.run(suite());
junit.swingui.TestRunner.run(coşTest.class);
}
}

Se observă că clasa cosTest este extinsă din clasa TestCase. S-a iniţializat în metoda
setUp() un obiect coş de clasă Coş şi un obiect carte de clasă Carte, care a fost adăugat
obiectului coş.
În metoda testCarteAdd() s-a testat adăugarea unei cărţi în coş folosind metoda
assertEquals(double expected, double actual, double delta), delta fiind diferenţa acceptată
pentru comparaţii între două valori de tip double, precum şi incrementarea numărătorului de
itemuri din coş cu metoda assertEquals(int expected, int actual).
Metoda testEmpty() testează golirea coşului după apelul metodei empty(). S-a utilizat
metoda assertTrue(boolean condition) care afişează un mesaj de eroare în cazul în care
condiţia este falsă.
Metoda testCarteRemove() testează operaţia de eliminare a unui obiect Carte din
coşul coş. Coşul are iniţial un obiect Carte (inserat prin metoda setUp()) care este eliminat
din coş cu metoda removeItem(). Se testează ca numărul de obiecte Book rămase să fie zero.
Metoda testCarteNotFound() testează inexistenţa în coş a unui obiect Carte care nu a
fost adăugat anterior, în caz de eroare se aruncă o excepţie prin apelul metodei fail().
JUnit furnizează atât o interfaţă text pentru utilizator, cât şi o interfaţă grafică, fiecare
indicând numărul de teste, erorile şi starea finală a testului.
Interfata text (junit.textui.TestRunner) afişează câte un punct pentru fiecare test
efectuat şi un OK dacă toate testele au fost trecute cu succes sau mesaje de eroare dacă unul
dintre teste a eşuat.

70
 Fig. nr. 4.2 Mesajul afişat în consolă în cazul în care toate testele au fost trecute cu succes

Fig. nr. 4.3 Mesajul afişat în consolă în cazul în care unul din teste a eşuat

Interfaţa grafică (junit.swingui.TestRunner) afişează o fereastră de tip Swing cu un

bară verde dacă toate testele au trecut cu succes sau o bară roşie dacă unul sau mai multe
teste eşuează.
Interfaţa grafică este specificată în metoda main().
Pentru a afişa rezultatele testelor folosind interfaţa grafică, în metoda main() se scrie
junit.swingui.TestRunner.run(ShoppingCartTest.class) în loc de
junit.textui.TestRunner.run(suite()).
Se recompilează clasa de test şi se lansează în execuţie. În cazul în care toate testele
au fost trecute cu succes rezultatul afişat este prezentat în imaginea următoare.

71
 Fig. nr. 4.4 Fereastră afişată în cazul în care toate testele au fost trecute cu succes

În cazul în care unul din teste a eşuat, va apărea una din ferestrele următoare.

Fig. nr. 4.5 Fereastră afişată în cazul în care coşul cu cărţi este vid, deşi el trebuia să mai
conţină o carte

72
Fig. nr. 4.6 Fereastra afişată în cazul în care coşul conţine mai puţine cărţi decât se aşteaptă

Fig. nr. 4.7 Fereastra afişată în cazul în care coşul verificat nu este gol, deşi trebuia să fie

73
Fig. nr. 4.8 Fereastra afişată în cazul în care se încearcă înlăturarea unei cărţi inexistente în coş

Se pot crea suite de test ce includ o ierarhie de clase de test sau alte suite.
Etapele creării manuale a unei suite de test sunt:
♦ se creează o clasă cu numele AllTests;
♦ în aceasta clasă se construieste o metodă statică care va returna un obiect
TestSuite. Această metodă se implementează astfel:
- se creează un obiect TestSuite apelând constructorul de forma TestSuite (String);
TestSuite suităTeste = new TestSuite („Suită de teste”);
- se adaugă testele unei clase TestXXX, utilizând metoda addTestSuite(Class).
Această metodă va utliza reflexivitatea pentru a studia metodele clasei furnizate ca şi
parametru.
suităTeste.addTestSuite (Coş.class) ;
- se adaugă testele unei alte clase de teste, şi asa mai departe;
- metoda va returna obiectul astfel creat.
package cărţi;

import junit.framework.Test;
import junit.framework.TestSuite;

74
public class AllTests {
/**
* Asamblează şi returnează o suită de teste
* Se pot adăuga teste noi.
* @return O suită de teste.
*/

public static Test suite() {

TestSuite suite = new TestSuite();
suite.addTest(coşTest.suite());
// O altă clasă de test.
suite.addTest(CreditCardTest.suite());
return suite;
}

/*
* Lansează in execuţie suita de teste.
*/
public static void main(String args[]) {
junit.swingui.TestRunner.run(AllTests.class);
}
}
Ca şi variantă, se poate adăuga treptat câte o metodă de test.
package cărţi;

import junit.framework.Test;
import junit.framework.TestSuite;

public class AllTests {

/**
* Asamblează şi returnează o suită de teste
* Se pot adăuga teste noi.
* @return O suită de teste.
*/

public static Test suite() {

TestSuite suite = new TestSuite();
suite.addTest(new cosTest("testCarteAdd"));
suite.addTest(new cosTest("testEmpty"));
suite.addTest(new cosTest("testCarteRemove"));
suite.addTest(new cosTest("testCarteNotFound"));
return suite;
}

/*

75
* Lansează in execuţie suita de teste.
*/
public static void main(String args[]) {
junit.swingui.TestRunner.run(AllTests.class);
}
}

Alternativ, se poate opta pentru o alta tehnică de elaborare a testelor, şi anume

generarea automată a claselor de tip test.
Aceasta se poate realiza urmând paşii;
♦ se face click dreapta pe pachetul “cărţi”;
♦ se alege opţiunea JUnit Test Case;

Fig. nr. 4.9 Fereastra afişată pentru alegerea tipului de test dorit

♦ se selectează metodele pentru care se intenţionează să se

creeze teste;

76
 Este preferabil să se creeze teste pentru toate metodele de care dispune clasa. Se
bifează metodele pentru care se vor crea teste.
În acest meniu apar şi metodele clasei Object. Dacă testarea vizează o clasă derivată,
atunci în acest meniu va apare şi clasa părinte a clasei care urmează să fie testată.

Fig. nr. 4.10 Meniul de selecţie a metodelor pentru care se vor crea teste

♦ se generează codul sursă al clasei de teste.

4.4 Recomandări pentru realizarea testelor cu JUnit

Câteva recomandări cu privire la organizarea şi execuţia testelor folosind utilitarul

JUnit:
- se vor crea clase de test în acelaşi pachet ca şi codul testat;
- pentru a evita combinarea codului de test şi de aplicaţie în directoarele sursă, se va
crea o structură de directoare identică (mirrored) cu structura pachetului ce conţine codul de
test;
- pentru fiecare pachet Java al aplicaţiei se va defini o clasă TestSuite ce conţine toate
testele pentru validarea codului din pachet;

77
 - se va verifica faptul că procesul de construire (build) al proiectului include
compilarea tuturor testelor, pentru a se asigura că testele apelează ultima variantă a codului
sursă;
- se va alterna scrierea codului sursă cu operaţii de testare pentru a se depista rapid
eventuale bug-uri;
- se vor scrie teste pentru zonele cu risc maxim de erori;
- dacă un bug este raportat în aplicaţia productivă, se va scrie un test care expune
acest bug;
- se vor scrie teste unitare înaintea scrierii codului si se va scrie cod nou numai când
un test eşuează.

78
 CONCLUZII

Cel mai important lucru în proiectarea şi dezvoltarea unui sistem informaţional îl

reprezintă dorinţa reală a beneficiarului de a realiza acest sistem.
De cele mai multe ori, necesitatea efectuării schimbărilor apare din unul din motivele:
fie întregul sistem de care aparţine face parte dintr-un plan mult mai mare de modernizare, fie
este nevoie de transformarea unor funcţionalităţi de bază, fie s-a luat decizia de a se
modificării obiectivelor strategice ale firmei, fie se urmăreşte îmbunătăţirea performanţelor
sistemului, sau se caută valorificarea într-o măsură cât mai mare a beneficiilor aduse de
tehnologiile de ultimă generaţie.
Dezvoltarea sistemelor informaţionale cuprinde întreaga gamă de activităţi implicate
în procesul de construire, implementare şi întreţinere a unui sistem informaţional.
Scopul sistemelor informaţionale este de a promova şi de a uşura activităţile
întreprinse, sistemul informaţional fiind, de fapt, un sistem bazat pe activitatea umană.
În raza de acţiune a sistemelor informaţionale, dezvoltarea poate fi caracterizată ca
fiind centrată în jurul metodelor structurate, cu multe abordări complementare şi alternative,
unele bazate pe practică, altele mai mult de ordin academic.
Pentru mulţi cercetători, în special cei care au cunoştinţe de informatică, dezvoltarea
sistemelor informaţionale, în principal, este împărţită în două mari activităţi: analiza
sistemelor afacerii şi proiectarea de asemenea sisteme informaţionale computerizate care să
le poată susţine. Aceasta începe cu analiza sistemului şi se încheie cu programarea, pentru ca
uneori să se rezume doar la aceste activităţi.
Dat fiind faptul că dezvoltarea sistemelor informaţionale reprezintă o activitate
temporară între proiectanţii sistemului şi utilizatori, trebuie accentuate metodele participative
de proiectare şi interactivitatea.

79
 Dezvoltarea sistemelor informaţionale trebuie percepută ca o schimbare
multidimensională de ordin social, deoarece ea include multiple aspecte culturale, morale,
politice şi sociale.
Un ţel de urmărit în cadrul procesului de dezvoltare a sistemelor informaţionale îl
reprezintă creare unor sisteme care să fie în permanentă evoluţie, care să poată fi adaptate,
sau chiar reinventate, astfel încât să întâmpine schimbările inevitabile care vor apărea,
mergând pe principiul că cerinţele nu trebuie pur şi simplu să fie rezolvate, ci trebuie să se
prevadă evoluţia lor.
Un parametru prin care poate fi cuantificat succesul unui proiect îl reprezintă măsura
în care s-a apropiat acesta de atingerea obiectivelor sale, dara cu respectarea parametrilor
referitori la buget şi durată. Aceste trei elemente: performanţe, cost şi durată sunt cunoscute
sub denumirea de tripla constrângere şi reprezintă echilibrul pe care trebuie să-l urmărească
orice proiect pentru a fi considerat de succes.

80
 Bibliografie

Cărţi
1. Andone I., Mockler R. J., Dologite D. G., Ţugui Al., - Dezvoltarea sistemelor inteligente în
economie. Metodologie şi studii de caz, Editura Economică, Bucureşti, 2001.
2. Boehm, B.; Turner R., - Balancing Agility and Discipline: A Guide for the Perplexed,
Addison-Wesley, Boston, 2004.
3. Britton, C., Doake, J. - Software System Development: A Gentle Introduction, Fourth Edition,
MacGraw-Hill Education, Glasgow, 2006.
4. El Emam, K. The ROI from Software Quality. Auerbach Publications, Boca Raton, Florida
2005.
5. Fotache D., Hurbean L., - Soluţii informatice integrate pentru gestiunea afacerilor – ERP,
Editura Economică, Bucureşti, 1999.
6. Goulielmos, M., - Outlining organisational failure in information systems development,
Disaster Development and Management Journal, Vol. 12, No. 4, 2003.
7. Lally G., - Understanding Information Technology System Project Failure, School of
Computing, Dublin Institute of Technology, 2004.
8. Larman, C.; Basili V. R., - Iterative and Incremental Development: A Brief History, IEEE
Computer Society, iunie 2003.
9. Lungu I., Gh. Sabău, C. Bodea, Tr. Surcel, - Sisteme informaţionale pentru conducere, Ed.
SIAJ, 1994.
10. Munteanu A. - Auditul sistemelor informaţionale, Editura Polirom, Iaşi, 2001.
11. Oprea, D. – Analiza şi proiectarea sistemelor informţionale economice, Editura Polirom, Iaşi,
1999.
12. Oprea D., Airinei D., Fotache M., - Sisteme informţionale pentru afaceri, Editura Polirom,
Iaşi, 2002.

81
13. Oprea, D., Meşniţă, G., Dumitriu, F., - Analiza sistemelor informaţionle, Editura Universităţii
„Al. Ioan Cuza", 2005, Iaşi.
14. Oprea, D., Meşniţă, G., Dumitriu, F., Proiectarea sistemelor informaţionle, Editura
Universităţii „Al. Ioan Cuza", 2006, Iaşi.
15. Pressman, R. S., - Software Engineering. A Practitioner’s Approach, Fifth Edition, McGraw-
Hill Publishing Company, London, 2000.
16. Ravichandran, T., Rai, A. - Total quality management in information systems development:
Key constructs and relationships, apărut în Journal of Management Information Systems,
2000.
17. Sommerville, I., - Software engineering, 8th edition, Addison Wesley, Boston, 2007.
18. Stair, R., Reynolds, G., - Principles of Information Systems, Seventh Edition, Thomson
Course Technology, 2006, Boston.
19. Whitmire, S.A, - Object-OrientedDesign Measurement, John Wiley & Sons, Inc., New York,
1997.
20. Yeo, K. T., - Critical failure factors in information system projects, International Journal for
Project Management, Vol. 20, No. 3, 2002.

Reviste sau articole din volume

1. Havelka, D., Conrad, K., Glassberg, B. – “A project success model for information
systems development”, Proceedings of Western Decision Sciences Institute Annual Meeting,
Las Vegas, 2002.
2. Shayo, C.; Olfman, L.; Teitelroit, R. – “An exploratory study of the value of pretraining
enduser participation”, Information Systems Journal., 9, 1, 1999.
3. Cannon, J.A., - “Why IT Applications Succeed or Fail”, Industry and Commercial
Training, Vol. 26, No. 1, 1994.

Referinţe Internet
1. Ambler, S., - Scaling Scrum - Meeting Real World Development Needs,
http://www.drdobbsonline.net/architect/207100381, accesat în aprilie 2008.
2. Bogue R., - Anatomy of a Software Development Role: The Good, the Bad, the Ugly,
http://www.projectmanagerplanet.com/tools/article.php/, accesat în 25 martie 2008.
3. Eftimescu, D., Ilioiu, A., Introducere în testarea automată, http://www.securenet.ro/ro/
publications/doc/testarea_automata.pdf, accesat în data de 13 martie 2008.

82
4. Gibson, Diane L., Goldenson, Dennis R., Kost, Keith, Perfomance Results of CMMI. Based
Process Improvement, raport tehnic Software Engineering Institute, Carnegie Mellon, august
2006, http://www.sei.cmu.edu/, accesat la data de 27 aprilie 2008.
5. Isenberg, H.M., - The practical organization of automated software testing,
http://www.automated-testing.com/PATfinal.htm, accesat în data de 30 aprilie 2008.
6. McManus, J., Wood-Harper, T., - Understanding the Sources of Information Systems Project
Failure, http://findarticles.com/p/articles/mi_qa5428/is_200710/ai_ n21295900, accesat în
data de 22 martie 2008.
7. Papadimoulis, A., The Great Pyramid of Agile, http://thedailywtf.com/Articles/The-Great-
Pyramid-of-Agile.aspx, accesat în data de 13 aprilie 2008.
8. Pettichord, B.,- Success with test automation, http://www.io.com/~wazmo/succpap.htm,
accesat în data de 15 martie 2008.
9. Richard, L.K., - Testing Requirements, www.gantthead.com, accesat în data de 19 mai 2008.
10. Stanciu V., Sisteme informaţionale de gestiune, Tribuna Economică Bucureşti, 1999,
www.tribunaeconomica.ro, accesat în data de 22 martie 2008.
11. Verton, D., - Senate votes to kill funds for antiterror data mining, Computerworld, 21 iulie
2003, accesat la www.computerworld.com, în data de 13 mai 2008.
12. *** - Testarea Unitară în BlueJ, http://www.bluej.org/tutorial/testing-tutorial-romanian.pdf,
accesat în data de 15 martie 2008.
13. *** - Testarea unitară a claselor Java folosind utilitarul JUnit, http://inf.ucv.ro/~pm/junit/,
accesat la data de 25 martie 2008.
14. ***http://www.acutest.co.uk/acutest/ieee829, accesat în data de 17 mai 2008.
15. ***http://www.agilealliance.com, accesat în data de 30 aprilie 2008.
16. ***www.agilemanifesto.org, accesat în 29 aprilie 2008.
17. ***http://facultate.regielive.ro/cursuri/contabilitate/proiectare_a_sistemelor_contabile-
11687.html, accesat în 15 februarie 2008.
18. ***http://www.sei.cmu.edu/cmmi/general/index.html, accesat la data de 30 aprilie 2008.

83