Ingineria programrii

Cursul 1

Fazele dezvoltrii unui produs software

1. Ce este ingineria programrii?
2. Fazele ingineriei programrii
2.1. Faza de analiz
2.2. Faza de proiectare
2.3. Faza de implementare
2.4. Faza de testare
3. Concluzii

1. Ce este ingineria programrii?

tiina calculatoarelor este un domeniu relativ nou. Primele calculatoare au fost construite la
mijlocul anilor 1940 i de atunci au avut loc dezvoltri spectaculoase. n anul 1946 Goldstine i
von Neumann apreciau c 1000 de instruciuni reprezint o limit superioar rezonabil pentru
complexitatea problemelor ce pot fi concepute ca rezolvabile cu ajutorul calculatorului. Dup ce a
prevzut n 1981 c nici un program pentru calculatoare personale nu va necesita vreodat mai
mult de 640 KB de memorie RAM, Bill Gates admite n 1995 c lucrurile s-au schimbat n
ultimele dou decenii.
Urmtoarele exemple ofer o imagine asupra gradului de complexitate la care au ajuns
programele n zilele noastre:
sistemul de rezervare a biletelor pentru compania aerian KLM coninea, n anul 1992,
dou milioane de linii de cod n limbaj de asamblare;
sistemul de operare System V versiunea 4.0 (UNIX) a fost obinut prin compilarea a
3.700.000 linii de cod;
programele scrise pentru naveta spaial NASA au circa 40 de milioane de linii de cod;
pentru realizarea sistemului de operare IBM OS360 au fost necesari 5000 de ani-om.
Creterea programelor n dimensiune i complexitate a depit cu mult progresele fcute n
domeniul tehnicilor de programare. De aceea, programarea a devenit i a rmas mai mult o art
dect o meserie.
O paralel cu ingineria construciilor este atractiv. Dac dorim s construim o cuc
pentru cine, putem s mergem prin grdin, s cutam lemne i cuie, s lum un ciocan i s
ncepem s lucrm. Avem anse destul de bune s reuim, mai ales dac suntem ndemnatici.
Dac totui nu reuim, putem ncerca a doua zi din nou cu alte lemne i alte cuie. Iar dac cinele
nu ncape n cuc, putem s ne cumprm alt cine.
Lucrurile stau radical diferit atunci cnd dorim s construim o cas pentru familia noastr.
Atunci va trebui sau s angajm un arhitect care s ne fac un proiect, sau s cumprm un
proiect standard de cas. Va trebui s negociem cu o firm de construcii preul, durata de
realizare, calitatea finisajelor. Nu ne permitem s riscm economiile familiei pe o construcie care
se va drma la a doua rafal de vnt. n plus, dac membrilor familiei nu le place orientarea
ferestrelor sau peisajul, nu i putem schimba cu alii (n cel mai ru caz, ne schimb ei pe noi).
Cu att mai mult, dac o firm pltete cteva milioane de dolari pentru a ridica un zgrie
nori, reprezentanii acesteia vor fi foarte ateni cu cine i n ce condiii vor lucra. Ei vor dori
garanii c proiectul este viabil, vor angaja mai multe firme de arhitectur pentru a-l verifica. De
1

asemenea, studii geologice, de fizic a pmntului sau meteorologie vor fi obligatorii. Vor fi
folosite cele mai performante materiale i se vor angaja cei mai competeni i cu experien
constructori. Eecul nu mai este o opiune pentru contractantul proiectului.
tim c inginerii constructori ntocmesc planuri, construiesc machete, studiaz
proprietile materialelor folosite i fac rapoarte privind progresul operaiunilor. Construcii de o
complexitate foarte mare au fost realizate n acest fel ntr-un mod raional i economic. Inginerii de
programe ar trebui s procedeze similar pentru ca dezvoltarea programelor s nu mai fie un proces
impredictibil.
Pe msur ce complexitatea programelor cretea, la sfritul anilor 60 ncepea s se
prefigureze deja o criz a programrii. Un raport prezentat de ctre o companie, n care erau
analizate cteva proiecte i stadiile lor de finalizare, a constatat c:
2% din sistemele software contractate au funcionat de la predare;
3% din sistemele software au putut funciona dup cteva modificri;
29% au fost predate dar n-au funcionat niciodat;
19% au fost folosite dar au fost abandonate;
47% au fost pltite dar niciodat predate.
Pentru a contracara aceste tendine, la conferina organizat de comitetul tiinific al
NATO n anul 1968, a fost propus termenul de ingineria programrii (engl. software
engineering), ntr-un mod oarecum provocator. Se dorea ca arta programrii s mprumute din
rigoarea tiinelor inginereti pentru a putea livra programe la timp i n mod economic. Prima
definiie dat ingineriei programrii a fost enunat astfel (F. L. Bauer):
Ingineria programrii este stabilirea i utilizarea de principii inginereti solide pentru a
obine n mod economic programe sigure i care funcioneaz eficient pe maini de calcul reale.
n IEEE Standard Glossary of Software Engineering Technology (1983) ingineria
programrii este definit dup cum urmeaz:
Ingineria programrii reprezint abordarea sistematic a dezvoltrii, funcionrii,
ntreinerii, i retragerii din funciune a programelor.
Remarcm c a doua definiie este mai vag dect prima, ntruct nu face referire la cost i
la eficien. Mai mult, se pare c experiena n general negativ acumulat a fcut s se renune
la formularea principii inginereti solide, ntruct se pare c acestea nu pot fi identificate fr a
fi supuse contestaiilor. A doua definiie adaug ns referiri la perioade importante din viaa unui
program, ce urmeaz crerii i funcionrii, i anume ntreinerea i retragerea din funcionare.
Considerm c ingineria programrii are urmtoarele caracteristici importante:
este aplicabil n producerea de programe mari;
este o tiin inginereasc;
scopul final este ndeplinirea cerinelor clientului.
Programele mici se pot scrie relativ uor, de ctre un singur programator, ntr-o perioad
destul de scurt de timp. Un program de 100 de instruciuni este cu siguran un program mic. Nu
putem identifica precis grania dintre un program mic i unul mare, ns pe msur ce
dimensiunea programului crete, apar provocri noi, calitativ diferite.

ntruct un singur sau civa programatori nu pot avea timpul fizic pentru terminarea
programului, este necesar crearea uneia sau mai multor echipe de lucru. Este necesar
coordonarea i comunicarea ntre echipe. Complexitatea sistemului software i a organizaiei care
realizeaz sistemul software devine important, putnd depi capacitatea de nelegere a unui
singur individ. Apare ca dezirabil o abordare riguroas a acestor probleme, ce include stilul de
lucru, modul de scriere a codului etc.
Nerespectarea cerinelor poate avea efecte serioase. Un sistem de livrare a insulinei pentru
diabetici poate provoca moartea pacientului dac nu funcioneaz corect. Funcionarea incorect a
unui sistem de control al unui satelit poate provoca pagube de milioane de dolari.
Un program este fiabil dac funcioneaz i continu s funcioneze fr ntreruperi un
interval de timp. Aceast noiune exprim de fapt rezistena la condiiile de funcionare. Un
sistem de operare trebuie s fie fiabil pentru c trebuie s funcioneze o perioad suficient de
lung de timp fr s cad, indiferent de programele care ruleaz pe el, chiar dac nu totdeauna
la performane optime.
Programul este sigur dac funcioneaz corect, fr operaii nedorite. Un program pentru
un
automat bancar trebuie s fie sigur, pentru a efectua tranzaciile n mod absolut corect, chiar dac
funcionarea sa poate fi ntrerupt din cnd n cnd. Atunci cnd funcioneaz ns, trebuie s
funcioneze foarte bine.
Programul este sigur dac funcioneaz corect, fr operaii nedorite. Un automat bancar
trebuie s fie sigur, pentru a efectua tranzaciile n mod absolut corect, chiar dac funcionarea
poate fi ntrerupt din cnd n cnd. Atunci cnd funcioneaz ns, trebuie s funcioneze foarte
bine.
Un program are o eroare (engl. bug) dac nu se comport corect. Se presupune c
dezvoltatorul tia ce ar fi trebuit programul s fac, iar comportamentul greit nu este intenionat.
Iat cteva erori celebre:
n primii ani n care calculatoarele au fost introduse la staiile de benzin din SUA,
consumatorii primeau cecuri pe sume enorme. Faptul era privit n general cu umor i
reclamaiile erau rezolvate repede;
Sistemul de operare IBM OS360 coninea aproximativ 1.000 de greeli la fiecare nou
versiune care ncerca s rezolve greelile din versiunea precedent;
Un vehicul de explorare a planetei Venus a fost pierdut deoarece programul primit de pe
Pmnt pentru rectificarea orbitei coninea linia 'DO 3 I = 1.3'; instruciunea corect n
limbajul FORTRAN ar fi trebuit s conin virgul n loc de punct;
n 1979 s-a descoperit o eroare n programele pentru sistemele de rcire n centralele
nucleare din SUA; din fericire, nu fusese niciodat nevoie de execuia rutinelor ce
conineau erorile;
Din cauza unei erori n sistemul de avertizare mpotriva atacului cu rachete balistice,
procedurile de contraatac au fost declanate nainte de a se descoperi c a fost o eroare;
Racheta Arianne 5 a explodat n iunie 1996 din cauza unei greeli de programare; costurile
s-au ridicat la 500 milioane dolari.
Ingineria programrii are ca scop obinerea de sisteme funcionale chiar i atunci cnd
teoriile i instrumentele disponibile nu ofer rspuns la toate provocrile ce apar. Inginerii fac
lucrurile s mearg, innd seama de restriciile organizaiei n care lucreaz i de constrngerile
financiare.

Problema fundamental a ingineriei programrii este ndeplinirea cerinelor clientului.

Aceasta trebuie realizat nu punctual, nu n acest moment, ci ntr-un mod flexibil i pe termen
lung. Ingineria programrii se ocup cu toate etapele dezvoltrii programelor, de la extragerea
cerinelor de la client pn la ntreinerea i retragerea din folosin a produsului livrat. Pe lng
cerinele funcionale, clientul dorete (de obicei) ca produsul final s fie realizat cu costuri de
producie ct mai mici. De asemenea, este de dorit ca aceasta s aib performane ct mai bune
(uneori direct evaluabile), un cost de ntreinere ct mai mic, s fie livrat la timp, i s fie sigur.
Rezumnd, atributele cheie ale unui produs software se refer la:
posibilitatea de a putea fi ntreinut: un produs cu un lung ciclu de via este supus deseori
modificrilor, de aceea el trebuie foarte bine documentat;
fiabilitate: produsul trebuie s se comporte dup cerinele utilizatorului i s nu cad
mai mult dect e prevzut n specificaiile sale;
eficien: produsul nu trebuie s foloseasc n pierdere resursele sistemului ca memoria sau
ciclii procesor;
interfaa potrivit pentru utilizator: interfaa trebuie s in seama de capacitatea i
cunotinele utilizatorului.
Optimizarea tuturor acestor atribute e dificil deoarece unele se exclud pe altele (o mai
bun interfa pentru utilizator poate micora eficiena produsului). n cazurile n care eficiena
este critic, acest lucru trebuie specificat explicit nc din faza de preluare a cerinelor
utilizatorului, precum i compromisurile pe care ea le implic privind ceilali factori.
Trebuie spus c ingineria programrii nu rezolv toate problemele care apar atunci cnd se
scriu programe. Ingineria programrii nu ofer nici teorii. Inginerii fac lucrurile s mearg.
Totui, n momentul de fa, ingineria programrii ne poate spune sigur ce s nu facem.

2. Fazele ingineriei programrii

Exist patru faze fundamentale ale metodologiilor ingineriei programrii:
analiza (ce dorim s construim);
proiectarea (cum vom construi);
implementarea (construirea propriu-zis);
testarea (asigurarea calitii).
Dei aceste faze se refer n mod special la ciclul de via al produsului software, ele pot fi
aplicate i altor stadii de existen prin care trece un program de la natere pn la moarte:
lansare, ntreinere, ieire din uz.

2.1. Faza de analiz

Aceast faz definete cerinele sistemului, independent de modul n care acestea vor fi
ndeplinite. Aici se definete problema pe care clientul dorete s o rezolve. Rezultatul acestei faze
este documentul cerinelor, care trebuie s precizeze clar ce trebuie construit.
Documentul ncearc s redea cerinele din perspectiva clientului, definind scopurile i
interaciunile la un nivel descriptiv nalt, independent de detaliile de implementare, cum ar fi, de
exemplu: formularea problemei, ateptrile clientului sau criteriile pe care trebuie s le
ndeplineasc produsul.

Grania dintre descrierile de nivel nalt i cele de nivel sczut nu este foarte bine trasat.
Uneori, dac un detaliu tehnic important trebuie specificat, el va aprea n document. Totui,
aceasta trebuie s fie excepia i nu regula. Aceste excepii pot fi determinate de necesitatea
meninerii compatibilitii cu alte sisteme deja existente, sau a unor anumite opiuni dorite de
client, de exemplu utilizarea unui anumit standard sau o constrngere asupra dimensiunilor imaginii
aplicaiei, care poate fi destinat unei categorii speciale de utilizatori sau care va rula pe nite
sisteme cu o serie de particulariti (monitoare care nu suport rezoluii mari).
Faza de analiz poate fi vzut ca o rafinare a detaliilor. Distincia dintre detaliile de nivel
nalt i cele de nivel sczut sunt puse mai bine n eviden de abordrile top-down (unde se merge
ctre detaliile de nivel sczut) i bottom-up (care tind ctre detaliile de nivel nalt).
Documentul cerinelor poate fi realizat ntr-o manier formal, bazat pe logic
matematic, sau poate fi exprimat n limbaj natural. n mod tradiional, el descrie obiectele din
sistem i aciunile care pot fi realizate cu ajutorul obiectelor. Aici noiunea de obiect nu trebuie
confundat cu obiectul din programarea orientat obiect. Descrierea obiectelor i aciunilor trebuie
s fie general i s nu depind de o anumit tehnologie. Desigur, ntr-o abordare POO,
descrierile vor lua forma obiectelor i metodelor, ns n alte abordri, obiectele pot fi de exemplu
servicii care acceseaz baze de date.
n general, documentul cerinelor descrie ontologia proiectului, adic vocabularul de
cuvinte cheie (n special construcii substantivale i verbale) care va fi utilizat pentru definirea
protocolului specific aplicaiei. Descrierile acestea nu implic proiectarea arhitecturii aplicaiei, ci
enumerarea prilor componente i a modului n care acestea se comport. Mai trziu, n faza de
proiectare, acestea vor fi transformate n primitive informatice, precum liste, stive, arbori, grafuri,
algoritmi i structuri de date.
Mai concret, documentul trebuie s conin descrieri pentru urmtoarele categorii:
Obiecte: Documentul trebuie s defineasc mai nti ontologia sistemului, care este bazat
n mare parte pe construcii substantivale pentru identificarea pieselor, prilor componente,
constantelor, numelor i a relaiilor dintre acestea;
Aciuni: Documentul trebuie s defineasc de asemenea aciunile pe care trebuie s le
ndeplineasc sistemul i care sunt sugerate n general de construcii verbale. Exemple de
aciuni sunt: metodele, funciile sau procedurile;
Stri: Sunt definite ca mulimi de setri i valori care disting sistemul ntre dou ipostaze
spaio-temporale. Fiecare sistem trece printr-o serie de schimbri de stare. Exemple de stri
sunt: starea iniial, cea final sau strile de eroare. Cele mai multe stri depind de
domeniul problemei. Strile sunt asociate cu obiectele sistemului. Un eveniment
declaneaz o tranziie de stare care poate conduce la ndeplinirea unei aciuni de ctre
sistem;
Scenarii tipice: Un scenariu este o secven de pai urmai pentru ndeplinirea unui scop.
Cnd sistemul este terminat i aplicaia este disponibil, clientul trebuie s poat utiliza,
ntr-o manier ct mai facil i clar specificat, toate scenariile tipice ale aplicaiei.
Scenariile tipice trebuie s reprezinte majoritatea scenariilor de utilizare ale aplicaiei.
Ponderea acestora variaz de la un sistem la altul, dar 90% se consider o proporie
acceptabil. Bineneles c un sistem cu un singur scenariu de utilizare este relativ simplu
de obinut, pe cnd unul cu mii de scenarii posibile va fi mult mai dificil de analizat.
Deseori este invocat regula 80/20: 80% din funcionalitatea sistemului se realizeaz cu

20% din efortul de munc. Executarea restului minoritar de funcionalitate necesit marea
majoritate a timpului de lucru;
Scenarii atipice: Un scenariu atipic trebuie s fie ndeplinit de sistem numai n cazuri
speciale. Clientul poate s spere, de exemplu, c o eroare neprevzut este un eveniment
atipic. Totui, sistemul trebuie s gestioneze un numr ct mai mare de categorii de erori,
prin tehnici stabilite, precum tratarea excepiilor, monitorizarea proceselor etc.;
Cerine incomplete sau nemonotone: O enumerare complet a cerinelor pentru toate
situaiile care pot aprea n condiii de lucru reale nu este posibil. n logica tradiional, o
teorie este definit de o mulime finit de axiome. Teoremele din teoria respectiv sunt
propoziii adevrate. Dac se adaug ulterior noi axiome, teoremele existente rmn
valide iar noile teoreme dezvoltate sunt adugate teoremelor stabilite. n logica
nemonoton, adugarea de noi axiome poate invalida unele teoreme care au fost
demonstrate anterior. O nou teorie nu mai este o simpl extensie a teoriei vechi, ci o
mulime de teoreme noi, mpreun cu o parte din teoremele vechi. Procesul de stabilire a
cerinelor are o natur iterativ i nemonoton. Mulimea iniial de cerine (axiomele)
definete posibilitile (teoremele) sistemului. Noile cerine pot infirma soluiile vechi. Pe
msur ce un sistem crete n dimensiuni i complexitate, stabilirea cerinelor devine din
ce n ce mai dificil, mai ales cnd procesul de colectare a cerinelor este distribuit, fiind
realizat de indivizi cu specializri diferite.
2.2. Faza de proiectare

Pe baza cerinelor din faza de analiz, acum se stabilete arhitectura sistemului:

componentele sistemului, interfeele i modul lor de comportare:
Componentele sunt elementele constructive ale produsului. Acestea pot fi create de la zero
sau reutilizate dintr-o bibliotec de componente. Componentele rafineaz i captureaz
semnificaia detaliilor din documentul cerinelor;
Interfeele ajut la mbinarea componentelor. O interfa reprezint grania dintre dou
componente, utilizat pentru comunicarea dintre acestea. Prin intermediul interfeei,
componentele pot interaciona;
Comportamentul, determinat de interfa, reprezint rspunsul unei componente la stimulii
aciunilor altor componente.
Documentul de proiectare descrie planul de implementare a cerinelor. Se identific
detaliile privind limbajele de programare, mediile de dezvoltare, dimensiunea memoriei, platforma,
algoritmii, structurile de date, definiiile de tip globale, interfeele etc.
n aceast faz trebuie indicate i prioritile critice pentru implementare. Acestea
sugereaz sarcinile care, dac nu sunt executate corect, conduc la eecul sistemului. Totui, chiar
dac prioritile critice sunt ndeplinite, acest fapt nu duce automat la succesul sistemului, ns
crete nivelul de ncredere c produsul va fi o reuit.
Folosind scenariile tipice i atipice, trebuie realizate compromisurile inerente ntre
performan i complexitatea implementrii. Analiza performanelor presupune studierea modului
n care diferitele arhitecturi conduc la diferite caracteristici de performan pentru fiecare scenariu
tipic. n funcie de frecvena de utilizare a scenariilor, fiecare arhitectur va avea avantaje i
dezavantaje. Un rspuns rapid la o aciunea a utilizatorului se realizeaz deseori pe baza unor
costuri de resurse suplimentare: indeci, managementul cache-ului, calcule predictive etc. Dac o

aciune este foarte frecvent, ea trebuie realizat corect i eficient. O aciune mai rar trebuie de
asemenea implementat corect, dar nu este evident care e nivelul de performan necesar n acest
caz. O situaie n care o astfel de aciune trebuie implementat cu performane maxime este
nchiderea de urgen a unui reactor nuclear.
Planul de implementare i planul de test, descrise mai jos, pot fi incluse de asemea n fazele
de implementare i respectiv testare. ns unul din scopurile fazei de proiectare este stabilirea unui
plan pentru terminarea sistemului, de aceea cele dou planuri au fost incluse n paragraful curent.
Planul de implementare stabilete programul dup care se va realiza implementarea i
resursele necesare (mediul de dezvoltare, editoarele, compilatoarele etc.).
Planul de test definete testele necesare pentru stabilirea calitii sistemului. Dac produsul
trece toate testele din planul de test, este declarat terminat. Cu ct testele sunt mai amnunite, cu
att este mai mare ncrederea n sistem i deci crete calitatea sa. Un anume test va verifica doar o
poriune a sistemului. Acoperirea testului este procentajul din produs verificat prin testare. n mod
ideal, o acoperire de 100% ar fi excelent, ns este rareori ndeplinit. De obicei, un test cu o
acoperire de 90% este simpl, ns ultimele 10% necesit o perioad de timp semnificativ.
De exemplu, s considerm BIOS-ul (Basic Input/Output System) construit de IBM la
nceputul anilor 80 n strns legtur cu sistemul de operare DOS (Disk Operating System) al
firmei Microsoft. Din raiuni de performan, BIOS-ul a fost plasat ntr-un chip ROM, i deci
patch-urile pentru eventualele erori erau imposibile. Astfel, au fost necesare teste cu acoperire de
100%. odul propriu-zis al BIOS-ului era destul de mic, cteva mii de linii. ns deoarece BIOS-ul
are o natur asincron, testul a presupus mai nti crearea unui mediu asincron care s aduc
sistemul n starea dorit i apoi trebuia generat un eveniment care s declaneze un test. Foarte
repede, setul de test a devenit mult mai mare dect BIOS-ul. A aprut astfel problema testrii
nsui a mediului de test! n final, o acoperire de 100% a fost atins, dar cu un cost foarte ridicat. O
soluie mai ieftin a fost nscrierea BIOS-ului ntr-o combinaie dintre EPROM (Electronic
Programmable Read Only Memory) i ROM. Cea mai mare parte a produsului era plasat n ROM,
iar patch-urile erau plasate n EPROM. Aceasta a fost abordarea adoptat de Apple pentru
Macintosh.
n general, este suficient ca testele s cuprind scenariile tipice i atipice, fr s verifice
ntregul sistem, cu absolut toate firele de execuie. Acesta poate conine ramificaii interne, erori
sau ntreruperi care conduc la fire de execuie netestate. Majoritatea sistemelor sunt pline de bug-uri
nedescoperite. De obicei, clientul particip n mod logic la testarea sistemului i semnaleaz erori
care vor fi ndeprtate n versiunile ulterioare.
2.3. Faza de implementare
n aceast faz, sistemul este construit, ori plecnd de la zero, ori prin asamblarea unor
componente pre-existente. Pe baza documentelor din fazele anterioare, echipa de dezvoltare ar
trebui s tie exact ce trebuie s construiasc, chiar dac rmne loc pentru inovaii i
flexibilitate. De exemplu, o component poate fi proiectat mai restrns, special pentru un anumit
sistem, sau mai general, pentru a satisface o direcie de reutilizare.
Echipa trebuie s gestioneze problemele legate de calitate, performan, biblioteci i
debug. Scopul este producerea sistemului propriu-zis. O problem important este ndeprtarea
erorilor critice. ntr-un sistem exist trei tipuri de erori:

Erori critice: mpiedic sistemul s satisfac n mod complet scenariile de utilizare. Aceste
erori trebuie corectate nainte ca sistemul s fie predat clientului i chiar nainte ca procesul
de dezvoltare ulterioar a produsului s poat continua;
Erori necritice: Sunt cunoscute, dar prezena lor nu afecteaz n mod semnificativ calitatea
observat a sistemului. De obicei aceste erori sunt listate n notele de lansare i au
modaliti de ocolire bine cunoscute;
Erori necunoscute: Exist ntotdeauna o probabilitate mare ca sistemul s conin un
numr de erori nedescoperite nc. Efectele acestor erori sunt necunoscute. Unele se pot
dovedi
critice, altele pot fi rezolvate cu patch-uri sau eliminate n versiuni ulterioare.
2.4. Faza de testare
Calitatea produsului software este foarte important. Multe companii nu au nvat ns

acest
lucru i produc sisteme cu funcionalitate extins, dar cu o calitate sczut. Totui, e mai simplu
s-i
explici clientului de ce lipsete o anumit funcie dect s-i explici de ce produsul nu este
performant. Un client satisfcut de calitatea produsului va rmne loial firmei i va atepta noile
funcii n versiunile urmtoare.
n multe metodologii ale ingineriei programrii, faza de testare este o faz separat,
realizat de o echip diferit dup ce implementarea s-a terminat. Motivul este faptul c un
programator nu-i poate descoperi foarte uor propriile greeli. O persoan nou care privete
codul poate descoperi greeli evidente care scap celui care citete i recitete materialul de multe
ori. Din pcate, aceast practic poate determina o atitudine indiferent fa de calitate n echipa
de implementare.
Tehnicile de testare sunt abordate preponderent din perspectiva productorului sistemului.
n mod ideal, i clientul trebuie s joace un rol important n aceast faz.
Testele de regresiune (engl. regression test) sunt colecii de programe care testeaz una
sau mai multe trsturi ale sistemului. Rezultatele testelor sunt adunate i dac exist erori, bug-ul
este corectat. Un test de regresiune valid genereaz rezultate verificate, numite standardul de aur.
Validitatea rezultatului unui test ar trebui s fie determinat de documentul cerinelor. n practic,
echipa de implementare este responsabil de interpretarea validitii.
Testele sunt colectate, mpreun cu rezultatele standardelor de aur, ntr-un pachet de test de
regresiune. Pe msur ce dezvoltarea continu, sunt adugate mai multe teste noi, iar testele vechi
pot rmne valide sau nu. Dac un test vechi nu mai este valid, rezultatele sale sunt modificate n
standardul de aur, pentru a se potrivi ateptrilor curente. Pachetul de test este rulat din nou i
genereaz noi rezultate. Acestea sunt comparate cu rezultatele standardelor de aur. Dac sunt
diferite, n sistem a aprut o greeal. Greeala este corectat i dezvoltarea continu. Acest
mecanism detecteaz situaiile cnd starea curent de dezvoltare a produsului invalideaz o stare
existent. Astfel, se previne regresiunea sistemului ntr-o stare de eroare anterioar.
Exist patru puncte de interes n testele de regresiune pentru asigurarea calitii.
Testarea intern trateaz implementarea de nivel sczut. Fiecare funcie sau component
este testat de ctre echipa de implementare. Aceste teste se mai numesc teste clear-box sau
white-box, deoarece toate detaliile sunt vizibile pentru test.

Testarea unitilor testeaz o unitate ca un ntreg. Aici se testeaz interaciunea mai multor
funcii, dar numai n cadrul unei singure uniti. Testarea este determinat de arhitectur. De
multe ori sunt necesare aa-numitele schele, adic programe special construite pentru stabilirea
mediului de test. Numai cnd mediul este realizat se poate executa o evaluare corect. Programul
schel stabilete stri i valori pentru structurile de date i asigur funcii externe fictive. De
obicei, programul schel nu are aceeai calitate ca produsul software testat i adesea este destul de
fragil. O schimbare mic n test poate determina schimbri importante n programul schel. Aceste
teste se mai numesc teste black-box deoarece numai detaliile interfeei sunt vizibile pentru test.
Testarea intern i a unitilor poate fi automatizat cu ajutorul instrumentelor de
acoperire (engl. coverage tools), care analizeaz codul surs i genereaz un test pentru fiecare
alternativ a firelor execuie. Depinde de programator combinarea acestor teste n cazuri
semnificative care s valideze rezultatelor fiecrui fir de execuie. De obicei, instrumentul de
acoperire este utilizat ntr-un mod oarecum diferit: el urmrete liniile de cod executate ntr-un test
i apoi raporteaz procentul din cod executat n cadrul testului. Dac acoperirea este mare i liniile
surs netestate nu prezint mare importan pentru calitatea general a sistemului, atunci nu mai
sunt necesare teste suplimentare.
Testarea aplicaiei testeaz aplicaia ca ntreg i este determinat de scenariile echipei de
analiz. Aplicaia trebuie s execute cu succes toate scenariile pentru a putea fi pus la dispoziia
clientului. Spre deosebire de testarea intern i a unitilor, care se face prin program, testarea
aplicaiei se face de obicei cu scripturi care ruleaz sistemul cu o serie de parametri i colecteaz
rezultatele. n trecut, aceste scripturi erau create manual. n prezent, exist instrumente care
automatizeaz i acest proces. Majoritatea aplicaiilor din zilele noastre au interfee grafice (GUI).
Testarea interfeei grafice pentru asigurarea calitii poate pune anumite probleme. Cele
mai multe interfee, dac nu chiar toate, au bucle de evenimente, care conin cozi de mesaje de la
mouse, tastatur, ferestre etc. Asociate cu fiecare eveniment sunt coordonatele ecran. Testarea
interfeei presupune deci memorarea tuturor acestor informaii i elaborarea unei modaliti prin
care mesajele s fie trimise din nou aplicaiei, la un moment ulterior.
Testarea la stres determin calitatea aplicaiei n mediul su de execuie. Ideea este crearea
unui mediu mai solicitant dect cel n care aplicaia va rula n mod obinuit. Aceasta este cea mai
dificil i complex categorie de teste. Sistemul este supus unor cerine din ce n ce mai
numeroase, pn cnd acesta cade. Apoi produsul este reparat i testul de stres se repet pn cnd
se atinge un nivel de stres mai ridicat dect nivelul ateptat de pe staia clientului. Deseori apar aici
conflicte ntre teste. Fiecare test funcioneaz corect atunci cnd este fcut separat. Cnd dou
teste sunt rulate n paralel, unul sau ambele teste pot eua. Cauza este de obicei managementul
incorect al accesului la resurse critice. Mai apar i probleme de memorie, cnd un test i aloc
memorie i apoi nu o mai dezaloc. Testul pare s funcioneze corect, ns dup ce este rulat de
mai multe ori, memoria disponibil se reduce iar sistemul cade.

3. Concluzii
n acest curs s-a fcut mai nti o introducere n problematica domeniului ingineriei
programrii, insistndu-se pe cauzele care au determinat dezvoltarea sa: creterea continu a
complexitii sistemelor software. Apoi s-au descris cele patru faze fundamentale ale
metodologiilor ingineriei programrii: analiza, proiectarea, implementarea i testarea, necesare
pentru realizarea unor sisteme de calitate.

10