Curs 1.

Etapele dezvoltrii software

1. Noiuni preliminare

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 admitea 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 noastre1:
- Un sistem de control al navetelor spaiale include aproximativ 25 milioane linii de
cod i un efort pentru dezvoltare de 22.000 man-years (unitate de msur pentru
costul dezvoltrii software ex., dac un program presupune efortul a 100 de
persoane iar finalizarea dezvoltrii necesit 2 ani atunci costul total de dezvoltare va
fi de 200 man-years);
- Un sistem de control al traficului aerian include aproximativ 1 milion de linii de cod
i 1600 man-years pentru scriere i 500 man-years pentru dezvoltare;
- Majoritatea produselor software dezvoltare astzi, din cauza complexitii, nu pot fi
pe deplin nelese de ctre o singur persoan;
- Testarea programelor reprezint o problem de imposibilitate (un program tipic, de
nivel mediu, avnd 100 de posibile intrri, 2100 posibile stri va presupune 1020 ani
presupunnd efectuarea a 100 de teste pe secund) nu e de mirare c apar bug-uri
tot timpul.
Creterea programelor n dimensiune i complexitate a depsit 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

1
http://www.cs.jcu.edu.au/ftp/web/teaching/Subjects/cp1500/1995/foils/may26/may26.html

1
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 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. Desigur, n toate aceste cazuri, alegerea unor instrumente
adecvate este critic. Aa cum nu putem construi o cas folosind un singur cui i
dezvoltarea programelor necesit alegerea unor instrumente adecvate pentru lucru. De
alegerea acestor instrumente depinde n primul productivitatea: e una s contruim
folosind o simpl lopat de exemplu i alta s folosim un excavator la fel i n cazul
instrumentelor de dezvoltare dac ne gndim la diferena ntre a implementa noi tot codul
i a folosi componente anterior dezvoltate ce deja implementeaz unele dintre
funcionalitile necesare. Aceste aspecte se traduc n timp i costuri de dezvoltare n
ambele cazuri.
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 2 . Era necesar un efort de standardizare a unor
metodologii, tehnici, metode de dezvoltare a produselor software n spiritul contracarrii
unor probleme legate de proprietate intelectual, de etape i moduri de abordare. Astfel,
n anul 1968, apare termenul de ingineria programrii. Prin acest termen 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.
Astzi ingineria programrii este vzut ca abordarea sistematic a dezvoltrii,
funcionrii, ntreinerii i retragerii din funciune a programelor (cf. IEEE Standard
Glossary of Software Engineering Technology, 1983). Aceast viziune nu face referiri la
cost sau la eficien, ns adaug referiri la perioade importante din viaa unui program,
ce urmeaz crerii i funcionrii, i anume ntreinerea i retragerea din funcionare.
Ingineria software urmrete toate aspectele privind producia software de la primele
stagii ale specificaiilor de sistem i pn la mentenana sistemului dup ce a fost dat n
funciune. innd cont de toate cerinele organizaionale i de restriciile financiare ale unei
organizaii, ingineria software definete teorii, metode i instrumente de lucru al cror numr

2
http://en.wikipedia.org/wiki/History_of_software_engineering

2
sporete continuu i care devin tot mai complexe datorit ncercrilor de a descoperi noi
soluii la problemele specifice unor organizaii
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, instrumente adecvante pentru dezvoltarea programelor.
Alegerea instrumentelor de dezvoltare adecvate n funcie de scopul i natura proiectului
software devine cel puin la fel de important precum alegerea unor stiluri de lucru sau
metode de dezvoltare adecvate pentru c ele sunt interdependente. Introducerea unora
dintre cele mai frecvent utilizate instrumente pentru dezvoltarea programelor reprezint
de altfel scopul acestui curs.
Spunem c un produs software reprezint programe i documentaia aferent.
Produsele software pot fi generice (off-the-shelf) dezvoltate pentru a fi vndute mai
multor clieni - sau specifice (custom) dezvoltate pentru a fi vndute unui singur client,
conform cu specificaia acestuia. Un program bun este acela care:
- Ofer utilizatorilor funcionalitile cerute;
- Este uor de meninut programul trebuie s evolueze odat cu schimbarea nevoilor
utilizatorilor;
- Este sigur (nu conine defecte de funcionare sau defectele sunt remediate imediat ce
sunt descoperite de ctre productor);
- Este eficient (nu irosete resurse ale sistemului);
- Este uor de folosit.
Spunem c 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 motor trebuie s fie fiabil pentru c trebuie s funcioneze o perioad
suficient de lung de timp fr ntreruperi, chiar dac nu totdeauna la performane optime.
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 sa poate fi ntrerupt din cnd n cnd. Atunci cnd funcioneaz ns,
trebuie s funcioneze foarte bine.

3
 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 celebre34:
- 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.
Procesul software presupune folosirea unor tehnici i instrumente adecvate avnd n
vedere:
- Problema care trebuie rezolvat;
- Restriciile impuse;
- Resursele disponibile.

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.

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.

3
http://www.maths.manchester.ac.uk/~higham/talks/count05.pdf
4
http://www.whagen.de/publications/2005/DigitalMediaRoutledge/RT2241_C0091.pdf

4
 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;

5
- 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 handler-ele de excepii, 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. 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 blocurile de construcie 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.

6
 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 frecven 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 pot fi considerate i ca aparinnd fazelor de
implementare i respectiv testare. ns unul din scopurile fazei de proiectare este
stabilirea unui plan pentru terminarea sistemului. 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 reprezint 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%. Codul 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

7
mod logic la testarea sistemului i semnaleaz erori care vor fi ndeprtate n versiunile
ulterioare.
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.

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. 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

8
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.
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.

9
 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.

2. Metodologii de dezvoltare a programelor

Cnd pornim la dezvoltarea unui program avem nevoie de:

- nelegere clar a ceea ce se cere;
- un set de metode i instrumente de lucru;
- un plan de aciune.
Planul de aciune se numete metodologie de dezvoltare. Dezvoltarea unui anumit
program const ntr-un set de pai ce se fac pentru a-l realiza. Lund n considerare tipul
pailor ce se efectueaz se creeaz un model de lucru, ce poate fi aplicat unei serii mai
largi de proiecte. Acesta este motivul pentru care planul de aciune este numit model: el
poate fi privit ca un ablon al dezvoltrii de programe. n timpul dezvoltrii programelor
s-a constatat c exist anumite tipuri de activiti care trebuie fcute la un moment dat:
- Analiza cerinelor: Se stabilete ce anume vrea clientul ca programul s fac. Scopul
este nregistrarea cerinelor ntr-o manier ct mai clar i mai fidel. Claritatea se
refer la lipsa ambiguitii iar fidelitatea la nregistrarea ct mai exact (posibil cuvnt
cu cuvnt);
- Proiectarea arhitectural: Din motive de complexitate, programele mari nu pot fi
concepute i implementate ca o singur bucat. Programul va trebui construit aadar
din module sau componente. Proiectarea arhitectural mparte sistemul ntr-un numr
de module mai mici i mai simple, care pot fi abordate individual;
- Proiectarea detaliat: Se realizeaz proiectarea fiecrui modul al aplicaiei, n cele
mai mici detalii;
- Scrierea codului: Proiectul detaliat este transpus ntr-un limbaj de programare. n
mod tipic, aceasta se realizeaz modular, pe structura rezultat la proiectarea
arhitectural;
- Integrarea componentelor: Modulele programului sunt combinate n produsul final.
Rezultatul este sistemul complet. n modelul numit big-bang componentele sunt
dezvoltate i testate individual. Apoi ele sunt integrate n sistemul final. Avnd n
vedere c funcionarea corect a componentelor individuale a fost testat, integrarea

10
 ar trebui s fie o formalitate. Din pcate, componentele nu pot fi testate exhaustiv, iar
cnd acestea lucreaz mpreun pot s apar situaii pe care o anumit component nu
le-a ntlnit n procesul de testare sau conflicte ntre anumite componente (de
exemplu, conflicte de partajare a resurselor). S-a constatat c atunci cnd se aplic
acest model, timpul de testare explodeaz, proiectul devenind greu de controlat.
Aceasta justific denumirea de big-bang. Modelul incremental propune crearea
unui nucleu al aplicaiei i integrarea a cte o component la un moment dat, urmat
imediat de testarea sistemului obinut. Astfel, se poate determina mai uor unde
anume apare o problema n sistem. Acest tip de integrare ofer de obicei rezultate mai
bune dect modelul big-bang;
- Validarea: n procesul de validare ne asigurm c programul ndeplinete cerinele
utilizatorului. ntrebarea la care rspundem este: construim produsul corect? Un
exemplu de validare este testul de acceptare, n care produsul este prezentat clientului.
Clientul spune dac este mulumit cu produsul sau dac mai trebuie efectuate
modificri;
- Verificarea: n procesul de verificare ne asigurm c programul este stabil i c
funcioneaz corect din punctul de vedere al dezvoltatorilor. ntrebarea la care
rspundem este: construim corect produsul?
- ntreinerea: Dup ce programul este livrat clientului, mai devreme sau mai trziu
sunt descoperite defecte sau erori ce trebuie reparate. De asemenea, pot apare
schimbri n specificaiile utilizatorilor, care vor diverse mbuntiri. ntreinerea
const n gestionarea acestor probleme.
Se poate constata uor c aceste activiti sunt n strns legtur cu cele patru faze
ale ingineriei programrii: analiza, proiectarea, implementarea i testarea.

3. Modele generale de procese de dezvoltare

Dup cum a fost explicat anterior, un model al unui proces software reprezint o
reprezentare abstract a unui proces software. Un model de proces reprezint procesul
privit dintr-o anumit perspectiv. n continuare introducem cteva modele generale de
proces (numite i paradigme de proces). Modelele descrise sunt:
- Modelul cascad. Activitile fundamentale de proces specificaia, dezvoltarea,
validarea i evoluia sunt reprezentate ca faze separate precum specificarea cerinelor,
proiectarea software, implementare, testare, etc.
- Dezvoltarea evoluionar. Abordarea prespune ntreptrunderea activitilor de
specificaie, dezvoltare i validare. Se pornete de la dezvoltarea unui sistem iniial
pornind de la un set de specificaii abstracte. Sistemul este ulterior rafinat pe baza
intrrii furnizate de utilizator pentru a produce n final un sistem ce satisface n
totalitate cerinele utilizatorului.

11
- Dezvoltarea bazat pe componente. Abordarea se bazeaz pe existena unui numr
considerabil de componente reutilizabile. Procesul de dezvoltare a sistemului se
axeaz n acest caz pe integrarea acestor componente n cadrul sistemului.
Aceste trei modele generice de procese larg rspndite astzi n practica ingineriei
programelor. Ele nu sunt mutual exclusive i sunt adesea folosite mpreun, ndeosebi n
cazul dezvoltrii unor sisteme de mari dimensiuni.
De asemenea, de-a lungul timpului au fost derivate modele noi pornind de la aceste
modele generale. De exemplu, cel mai important model derivat poate fi considerat
modelulul de dezvoltare formal. Modelul de dezvoltare formal se bazeaz pe
construirea unui model matematic al sistemului ce se dorete a se implementa. Acest
model este apoi transformat, folosind un aparat matematic corespunztor i transformri
ce pstreaz consistena, n cod executabil.

Modelul cascad

n modelul cascad, cunoscut i sub numele de modelul secvenial, are loc mai
nti faza de analiz, apoi cea de proiectare, urmat de cea de implementare i testare, iar
n final operarea i mentenana. Echipele care se ocup de fiecare faz pot fi diferite, iar
la fiecare tranziie de faz poate fi necesar o decizie managerial.
Principalele etape ale modelului cascad sunt urmtoarele:
- Analiza i definirea cerinelor. Serviciile, constrngerile i obiectivele sistemului sunt
iniial stabilite prin consultare cu utilizatorii sistemului. Aceste cerine sunt definite n
detaliu i servesc ca specificaie a sistemului.
- Proiectarea sistemului i a software-ului. Procesul de proiectare a sistemului
partiioneaz cerinele ca fiind de natur hardware sau software. Etapa aceasta are de
asemenea rolul de a stabili arhitectura general a sistemului. Proiectarea software-ului
prespune identificarea i descrierea abstractizrilor software ale sistemului
fundamentale i a interaciilor ntre acestea.
- Implementarea i testarea sistemului. n aceast etap sunt integrate i testate
diversele uniti individuale de program n cadrul unui sistem complet pentru a se
asigura faptul c cerinele software cerute au fost ndeplinite. Dup testare sistemului
software este livrat clientului.
- Operarea i mentenana. n mod normal (dei nu i necesar) aceasta reprezint cea
mai lung dintre fazele modelului. Sistemul este instalat i dat spre folosire.
Mentenana presupune corectarea erorilor ce nu au fost descoperite n etapele
anterioare a ciclului de dezvoltare, mbuntirea implementrii unitilor sistemului
i mbuntirea serviciilor oferite de sistem pe msur ce sunt descoperite i adoptate
noi cerine de exploatare.
Rezultatul fiecrei etape reprezint unul sau mai multe documente ce sunt aprobate
(eng. signed off). Urmtoarea faz nu poate ncepe pn cnd faza anterioar nu s-a
terminat. n practic ns fazele pot fi ntresute astfel nct informaii din fiecare etap

12
pot influena rezultatele altei etape. n timpul proiectrii, de exemplu, pot fi identificate
diverse probleme legate de cerine incorecte formulate n etapa de analiz. Procesul
software, n practic, nu este un simplu model secvenial ci presupune o secven de
iteraii ale activitilor de dezvoltare.

Fig. 1. Modelul cascad.

Metodologia secvenial este potrivit cnd complexitatea sistemului este mic iar
cerinele sunt statice. Ea spune c mai nti trebuie s ne gndim ce trebuie construit, apoi
s stabilim un plan de lucru i apoi s realizm proiectul, innd cont de standardele de
calitate. De asemenea, se aliniaz metodelor de inginerie hardware. Foreaz meninerea
unei discipline de lucru care evit presiunea scrierii codului nainte de a cunoate precis
ce produs va trebui de fapt construit.
De multe ori, echipa de implementare se afl n situaia de a programa nainte de
finalizarea analizei, ceea ce conduce inevitabil la descoperirea unor pri de cod inutile
sau care contribuie foarte puin (poate chiar i ineficient) la funcionalitatea produsului
final. Totui, acest cod devine un balast foarte costisitor: dificil de abandonat i greu de
schimbat. Aceast metodologie foreaz analiza i planificarea naintea implementrii, o
practic foarte nimerit n multe situaii.
Un mare numr de sisteme software din trecut au fost construite cu o metodologie
secvenial. Multe companii i datoreaz succesul acestui mod de realizare a
programelor. Trebuie spus totui i c presiunea de schimbare din partea surselor externe
era destul de limitat la momentul respectiv.
Unul din principalele dezavantaje ale metodologiei secveniale este faptul c acord o
foarte mare importan fazei de analiz. Membrii echipei de analiz ar trebui s fie
probabil clarvztori ca s poat defini toate detaliile aplicaiei nc de la nceput.
Greelile nu sunt permise, deoarece nu exist un proces de corectare a erorilor dup
lansarea cerinelor finale. Nu exist nici feedback de la echipa de implementare n ceea ce
privete complexitatea codului corespunztor unei anumite cerine. O cerin simplu de
formulat poate crete considerabil complexitatea implementrii. n unele cazuri, este

13
posibil s fie chiar imposibil de implementat cu tehnologia actual. Dac echipa de
analiz ar ti c o cerin nu poate fi implementat, ei ar putea-o schimba cu o cerin
diferit care s satisfac cele mai multe dintre necesiti i care s fie mai uor de efectuat.
Comunicarea dintre echipe este o problem. n mod tradiional, cele patru echipe pot
fi diferite iar comunicarea dintre ele este limitat. Modul principal de comunicare sunt
documentele realizate de o echip i trimise urmtoarei echipe cu foarte puin feedback.
Echipa de analiz nu poate avea toate informaiile privitoare la calitate, performan i
motivare.
ntr-o industrie n continu micare, metodologia secvenial poate produce sisteme
care, la vremea lansrii, s fie deja nvechite. Accentul att de mare pus pe planificare nu
poate determina rspunsuri suficient de rapide la schimbare. Ce se ntmpl dac clientul
i schimb cerinele dup terminarea fazei de analiz? Acest lucru se ntmpl ns
frecvent; dup ce clientul vede prototipul produsului, el i poate schimba unele cerine.

Dezvoltarea evoluionar (Prototipizare)

O problem general care apare la dezvoltarea unui program este s ne asigurm c

utilizatorul obine exact ceea ce vrea. Prototipizarea vine n sprijinul rezolvrii acestei
probleme. nc din primele faze ale dezvoltrii, clientului i se prezint o versiune
funcionala a sistemului. Aceast versiune nu este ntregul sistem, ns este o parte a
sistemului care cel puin funcioneaz.
Dezvoltarea evoluionar se bazeaz pe dezvoltarea unei implementri iniiale, expus
comentariilor utilizatorului i rafinarea ei i producerea de noi versiuni pn cnd este
dezvoltat sistemului final (Fig. 2). Activitile de specificare, dezvoltare i validare sunt
ntresute.

Fig. 2. Dezvoltarea evoluionar.

Prototipul ajut clientul n a-i defini mai bine cerinele i prioritile. Prin
intermediul unui prototip, el poate nelege ce este posibil i ce nu din punct de vedere
tehnologic. Prototipul, este de obicei produs ct mai repede; pe cale de consecin, stilul
de programare este de obicei (cel puin) neglijent. ns scopul principal al prototipului
este de a ajuta n fazele de analiz i proiectare i nu folosirea unui stil elegant.

14
 Se disting dou feluri de prototipuri:
- de aruncat (throw-away);
- evoluionar.
n cazul realizrii unui prototip de aruncat, scopul este exclusiv obinerea unei
specificaii. De aceea nu se acord nici o importan stilului de programare i de lucru,
punndu-se accent pe viteza de dezvoltare. Odat stabilite cerinele, codul prototipului
este aruncat, sistemul final fiind rescris de la nceput, chiar n alt limbaj de programare.
n cazul realizrii unui prototip evoluionar, scopul este de a crea un schelet al
aplicaiei care s poat implementa n prim faz o parte a cerinelor sistemului. Pe
msur ce aplicaia este dezvoltat, noi caracteristici sunt adugate scheletului existent. n
contrast cu prototipul de aruncat, aici se investete un efort considerabil ntr-un design
modular i extensibil, precum i n adoptarea unui stil elegant de programare.
Aceast metod are urmtoarele avantaje:
- permite dezvoltatorilor s elimine lipsa de claritate a specificaiilor;
- ofer utilizatorilor ansa de a schimba specificaiile ntr-un mod ce nu afecteaz
drastic durata de dezvoltare;
- ntreinerea este redus, deoarece validarea se face pe parcursul dezvoltrii;
- se poate facilita instruirea utilizatorilor finali nainte de terminarea produsului.
Dezavantajele principale ale prototipizrii sunt prezentate n continuare:
- deoarece prototipul ruleaz ntr-un mediu artificial, anumite dezavantaje ale
produsului final pot fi scpate din vedere de clieni;
- clientul nu nelege de ce produsul necesit timp suplimentar pentru dezvoltare, avnd
n vedere c prototipul a fost realizat att de repede;
- deoarece au n fiecare moment ansa de a face acest lucru, clienii schimb foarte des
specificaiile;
- poate fi nepopular printre dezvoltatori, deoarece implic renunarea la propria munc.

Dezvoltarea bazat pe componente

n majoritatea proceselor software exist un grad de reutilizare software. Acest aspect

apare cu precdere atunci cnd dezvoltatorii ce lucreaz n cadrul unui proiect cunosc
proiecte sau module de cod ce realizeaz funcionaliti similare celor cerute de proiectul
curent. Dezvoltatorii adesea ajung s caute astfel de componente reutilizabile i, prin
eventuala lor modificare, le integreaz n proiect.
Dezvoltarea bazat pe componente se bazeaz aadar pe refolosirea sistematic a unor
componente anterior implementate sau pe modificarea unor sisteme COTS (Commercial-
off-the-shelf).
n acest model etapele principale ale procesului de dezvoltare sunt (Fig. 3):

15
- Analiza componentelor. Plecnd de la specificarea cerinelor se realizeaz o cutare a
componentelor cu ajutorul crora se pot implementa acestea. Adesea e greu de gsit o
component care s se potriveasc exact unei anumite cerine sau componenta care ar
putea fi folosit adesea implementeaz funcionalitatea numai parial.
- Modificarea cerinelor. n aceast etap cerinele sunt analizate folosind diversele
informaii disponibile despre componente. Cerinele pot fi ulterior modificate n
funcie de componentele disponibile. Atunci cnd modificrile sunt imposibil de fcut
poate fi reluat activitatea de analiz a componentelor pentru gsirea unor soluii
alternative.
- Proiectarea sistemului prin refolosire. n aceast etap este proiectat framework-ul
sistemului (sau se poate opta pentru refolosirea unui framework deja existent).
Proiectanii sistemului iau n considerare, n aceast etap, componentele refolosite i
organizeaz sistemul final n scopul acomodrii acestora. n aceast etap poate
aprea de asemenea necesitatea proiectrii software, ndeosebi atunci cnd nu pot fi
gsite componente reutilizabile.
- Dezvoltare i integrare. n aceast etap este dezvoltat software-ul ce nu a putut fi
procurat i n final sunt integrate componentele i sistemele COTS pentru creerea
sistemului final. Integrarea sistemului, n acest model, poate fi parte a procesului de
dezvoltare (nu exist o delimitare clar ntre cele dou activiti dezvoltare i
integrare).
Astzi abordarea de dezvoltare bazat pe componente este din ce n ce mai popular
datorit apariiei unui numr mare de standarde bazate pe componente (ex. CORBA
Component Model CCM, Distributed Component Object Model DCOM, Microsoft
DotNET Framework, SUN Microsystems JavaBeans and Enterprise JavaBeans EJB).

Fig. 3. Etapele dezvoltrii bazate pe componente.

Dezvoltarea bazat pe componente are avantajul reducerii cantitii de software
necesar a fi dezvoltat, cu implicaii precum reducerea costurilor i riscurilor de
producie. De asemenea abordarea poate conduce la un timp mai mic de livrare a
produsului software final. Totui, compromisurile cerinelor sunt inevitabile i acest
aspect poate conduce la crearea unui sistem ce nu ntrunete cerinele reale ale
utilizatorilor. n plus se pierde i o parte din controlul asupra evoluiei sistemului
deoarece noile versiuni ale componentelor reutilizate nu sunt sub controlul organizaiei ce
le folosete.

16
4. Iteraiile procesului de dezvoltare

Schimbrile sunt inevitabile n oricare proiect software de dimensiuni mari. Cerinele

sistemului se pot modifica pe msur ce afacerea clientului ce necesit produsul software
se adapteaz la presiuni i schimbri externe. Prioritile de management sunt i ele n
continu modificare. Pe msur ce noi tehnologii devin disponibile apar modificri n
etapele de proiectare i implementare. Toate aceste schimbri trebuie luate n considerare
n dezvoltarea unor produse software activitile presupune de dezvoltarea unui produs
software trebuie repetate pe msur ce sistemul este refcut ca rspuns la diverse cerine
de modificare. Modele proceselor software ce suport schimbrile survenite pe parcursul
ciclului de dezvoltare a unui produs software poart denumirea de modele iterative.
n aceast seciune sunt introduse dou modele de proces ce sunt proiectate n mod
explicit pentru a suporta iteraiile proceselor:
1. Livrarea incremental. Specificaia software, proiectarea i implementarea sunt
separate n serii de incrementri ce sunt dezvoltate pe rnd.
2. Dezvoltarea n spiral. Dezvoltarea spiralelor sistemului conduce de la un proiect
iniial pn la dezvoltarea sistemului final.

Dezvoltarea incremental

Modelul n cascad prezentat anterior presupune c utilizatorii sistemului furnizeaz

un set de cerine nainte de nceperea etapei de proiectare i c proiectanii furnizeaz
strategii de proiectare particulare naintea fazei de implementare. Modificrile cerinelor
necesit ns refacerea tuturor etapelor de analiz a cerinelor, proiectare i implementare.
Totui, separarea fazelor de proiectare i implementare ar trebui s conduc la crearea
unui sisteme bine-documentate ce sunt uor de modificat. Prin contrast, o abordare
evoluionar permite ca deciziile de analiz a cerinelor i proiectare s fie ntrziate dar
poate conduce de asemenea la dezvoltarea de software slab structurat i dificil de neles
i meninut.
Dezvoltarea incremental (Fig. 4) reprezint o abordare intermediar ce combin
avantajele ambelor modele. ntr-un proces de dezvoltare incremental clienii identific, n
linii mari, serviciile ce vor fi furnizate de ctre sistem. Ei identific apoi care dintre
servicii sunt mai importante i care sunt mai puin importante pentru sistemul final. Sunt
definite apoi un numr de livrri incrementale, fiecare incrementare furniznd un sub-set
al funcionalitilor sistemului final. Alocarea serviciilor ce sunt implementate cu fiecare
nou increment depinde de prioritile alocate, serviciile avnd cea mai mare prioritate
pentru sistemului final (respectiv pentru utilizator) fiind implementate cel mai devreme.
Dup ce au fost identificate incrementrile sistemului cerintele serviciilor ce trebuie
implementate odat cu primul incrementat sunt analizate n detaliu i se trece la
implementarea respectivului increment. n timpul fazei de dezvoltare alte analize ale
cerintelor pentru incrementri viitoare pot aprea, dar nu se accept modificri ale
cerinelor pentru incrementarea curent.

17
 Odat ce a fost finalizat i livrat un increment clienii pot trece la punerea n producie
a funcionalitii respective. Aceasta nseamn c utilizatorii pot trece la experimentarea
n producie a unora dintre funcionalitile cele mai prioritare, de baz, nainte ca ntreg
sistemul s fie dezvoltat.

Fig. 4. Dezvoltarea incremental.

Dezvoltarea incremental are i ea o serie de avantaje. Clienii nu sunt obligai s
atepte pn cnd ntregul sistem este livrat i pot trece la folosirea unor funcionaliti
prioritare nainte chiar ca ntreg sistemul s fie finalizat. Clienii pot, de asemenea, folosi
incrementrile iniiale ca prototip i pot experimenta cerinele ulterioare ce sunt propuse
apoi pentru dezvoltrile viitoare ale sistemului final. Riscul de eec al ntregului proces
este redus. Chiar dac n unele incrementri pot aprea probleme, totui unele
incrementri, cu o mare probabilitate, ajung s fie livrate clientului. n fine, deoarece
serviciile avnd cea mai mare prioritate sunt livrate iniial, inevitabil aceste servicii vor fi
i testate cel mai ndelung nainte de punerea n producie a sistemului final. Utilizatorii
vor ntlni mai puine erori de funcionare n cadrul unor dintre componentele critice ale
sistemului final.

Modelul spiral

Modelul spiral (Fig. 5) este un exemplu bine cunoscut de metodologie a ingineriei

programrii. Acest model ncearc s rezolve problemele modelului n cascad, pstrnd
avantajele acestuia: planificare, faze bine definite, produse intermediare. n locul
reprezentrii procesului software ca o secven de activiti, procesul este reprezentat n
acest caz sub forma unei spirale. Fiecare bucl a spiralei reprezint o faz a procesului
software. Astfel, bucla cea mai din centru corespunde activitii de stabilire a fezabilitii
sistemului, urmtoarea bucl corespunde definirii cerinelor, urmtoarea proiectrii
sistemului i aa mai departe.
Fiecare bucl a spiralei este mprit n patru sectoare:
1. Stabilirea obiectivelor. Sunt definite obiective specifice pentru faza curent a
proiectului. Sunt identificate, de asemenea, constrngeri asupra proceselor i

18
 produsului i este trasat un plan detaliat de management. Tot aici sunt stabilite
riscurile asociate procesului. Pot fi planificate strategii alternative, n funcie de
riscurile identificate.
2. Evaluarea i reducerea riscurilor. n cazul fiecrui risc anterior identificat este
realizat o analiz detaliat. Sunt trasai pai pentru reducerea riscului. De exemplu,
dac apare un risc legat de faptul c cerinele sunt necorespunztoare atunci se poate
trece la dezvoltarea unui sistem prototip.
3. Dezvoltarea i validarea. Dup etapa de evaluare a riscurilor se alege un model de
dezvoltare. De exemplu, dac riscurile interfeelor utilizator sunt dominante, atunci
un model corespunztor de dezvoltare ar putea fi prototiparea evoluionar. Dac
riscurile legate de siguran sunt dominante atunci se poate alege un model de
dezvoltare formal a modelului. Modelul cascad poate fi ales atunci cnd riscul
principal identificat l reprezint integrarea sub-sistemelor.
4. Planificarea. Proiectul este revizuit i se ia o decizie legat de posibila continuare cu
o nou bucl a spiralei. Dac se ia decizia de continuare atunci sunt trasate planuri
pentru continuarea cu urmtoarea faz a proiectului.

Fig. 5. Modelul spiral.

Principala diferen ntre aceast abordare i ale modele de procese software este dat
de recunoaterea explicit a riscurilor. Riscul reprezint orice ar putea merge ru. De
exemplu, dac intenia este de a utiliza un nou limbaj de programare, un posibil risc ar
putea fi reprezentat de posibilitatea ca compilatoarele existente s nu fie de ncredere sau
s nu produc cod eficient. Riscurile duc la probleme legate de planificare i depirea
costurilor.
Un ciclu al spiralei ncepe prin elaborarea obiectivelor precum performan i
funcionalitate. Modaliti alternative de atingere a acestor obiective i constrngerile
impuse de fiecare obiectiv sunt apoi enumerate. Fiecare alternativ este evaluat n
termeni de riscuri posibile i sunt identificate posibilele surse de riscuri. Urmtpatoarea
etapa presupune rezolvarea acestor riscuri prin activiti de informare precum analiza
detaliat, prototiparea i simularea. Odat ce riscurile au fost evaluate se trece la etapa

19
propriu-zis de dezvoltare, urmat de o activitate de planificare a urmtoarei faze a
procesului.
Deci, procesul ncepe n centrul spiralei. Fiecare ciclu terminat reprezint o etap. Pe
msur ce spirala este parcurs, produsul se maturizeaz. Cu fiecare ciclu, sistemul se
apropie de soluia final. Dei este considerat ca un exemplu generic pentru metodologia
ciclic, metoda are i elemente secveniale, puse n eviden de evoluia constant de la o
etap la alta.

20