Ingineria programrii

Cursul 2

Metodologii de dezvoltare a programelor

1. Etapele dezvoltrii programelor
2. Metodologii generice
2.1. Metodologia secvenial
2.2. Metodologia ciclic
2.3. Metodologia hibrid ecluz
3. Metodologii concrete
3.1. Metodologia cascad
3.2. Metodologia spiral
3.3. Metodologia spiral WinWin
3.4. Prototipizarea
3.5. Metodologia Booch
3.6. Metode formale
3.7. Extreme Programming
4. Concluzii

1. Etapele dezvoltrii 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. De obicei, 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, dup care sunt integrate n sistemul final. Avnd n vedere c funcionarea corect a
componentelor individuale a fost testat, integrarea ar trebui s fie o formalitate. Din pcate,
componentele nu pot fi testate exhaustiv, iar cnd acestea lucreaz mpreun pot s apar situaii pe
1

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 aprea 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.
2. Metodologii generice
n acest paragraf, vor fi prezentate trei categorii importante de metodologii: secvenial,
ciclic i hibrid. n metodologia secvenial (cascad), cele patru faze urmeaz una alteia ntr-o
modalitate serial. n metodologia ciclic (spiral), fazele sunt dispuse n cicluri care i genereaz
incremental contribuiile la sistemul final. Metodologia hibrid (ecluz) combin progresul constant
al metodologiei secveniale cu incrementele iterative ale metodologiei ciclice.
2.1. Metodologia secvenial
n metodologia secvenial, cunoscut i sub numele de metodologia "cascad", are loc mai
nti faza de analiz, apoi cea de proiectare, urmat de cea de implementare, iar n final se
realizeaz testarea. Echipele care se ocup de fiecare faz pot fi diferite, iar la fiecare tranziie de
faz poate fi necesar o decizie managerial.

Figura 1. Metodologia secvenial

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

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.
Dezavantaje
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 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: 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.
2.2. Metodologia ciclic
Metodologia ciclic, cunoscut i sub numele de metodologia "spiral", ncearc s rezolve
unele din problemele metodologiei secveniale. i aceast metodologie are patru faze, ns n
fiecare faz se consum un timp mai scurt, dup care urmeaz mai multe iteraii prin toate fazele.
Ideea este de fapt urmtoarea: gndete un pic, planific un pic, implementeaz un pic, testeaz un
pic i apoi ia-o de la capt. n mod ideal, fiecrei faze trebuie s i se acorde atenie i importan
egale.
Documentele de la fiecare faz i schimb treptat structura i coninutul, la fiecare ciclu sau
iteraie. Pe msur ce procesul nainteaz, sunt generate din ce n ce mai multe detalii. n final, dup
cteva cicluri, sistemul este complet i gata de lansare. Procesul poate ns continua pentru lansarea
mai multor versiuni ale produsului.

Figura 2. Metodologia ciclic

3

Avantaje
Metodologia ciclic se bazeaz pe ideea perfecionrii incrementale ale metodologiei
secveniale. Permite feedback-ul de la fiecare echip n ceea ce privete complexitatea cerinelor.
Exist etape n care pot fi corectate eventualele greeli privind cerinele. Clientul poate arunca o
privire asupra rezultatului i poate oferi informaii importante mai ales n faza dinaintea lansrii
produsului. Echipa de implementare poate trimite echipei de analiz informaii privind
performanele i viabilitatea sistemului. Acesta se poate adapta mai bine progresului tehnologic: pe
msur ce apar noi soluii, ele pot fi ncorporate n arhitectura produsului.
Dezavantaje
Metodologia ciclic nu are nici o modalitate de supraveghere care s controleze oscilaiile
de la un ciclu la altul. n aceast situaie, fiecare ciclu produce un efort mai mare de munc pentru
ciclul urmtor, ceea ce ncarc orarul planificat i poate duce la eliminarea unor funcii sau la o
calitate sczut. Lungimea sau numrul de cicluri poate crete foarte mult. De vreme ce nu exist
constrngeri asupra echipei de analiz s fac lucrurile cum trebuie de prima dat, acest fapt duce la
scderea responsabilitii. Echipa de implementare poate primi sarcini la care ulterior se va renuna.
Echipa de proiectare nu are o viziune global asupra produsului i deci nu poate realiza o arhitectur
complet. Nu exist termene limit precise. Ciclurile continu fr o condiie clar de terminare.
Echipa de implementare poate fi pus n situaia nedorit n care arhitectura i cerinele sistemului
sunt n permanen schimbare.
2.3. Metodologia hibrid ecluz
Metodologia ecluz (engl. "watersluice"), propus de Ronald LeRoi Burback (1998), separ
aspectele cele mai importante ale procesului de dezvoltare a unui produs software de detaliile mai
puin semnificative i se concentreaz pe rezolvarea primelor. Pe msur ce procesul continu,
detaliile din ce n ce mai fine sunt rafinate, pn cnd produsul poate fi lansat. Aceast metodologie
hibrid preia natura iterativ a metodologiei spiral, la care adaug progresul sigur al metodologiei
cascad.

Figura 3. Metodologia hibrid ecluz

4

La nceput, ntr-un proces iterativ, fazele de analiz, proiectare, implementare i testare sunt
mprite n mai multe sarcini poteniale, fiecruia atribuindu-i-se o prioritate care reflect
beneficiul ndeplinirii sarcinii respective pentru scopul final. La fiecare moment se execut sarcina
cu prioritate maxim. n funcie de dimensiunea echipelor, mai multe sarcini pot fi realizate n
paralel. Sarcinile rmase, de prioritate minim, sunt pstrate pentru examinare ulterioar.
Descompunerea problemei este foarte important. Cu ct descompunerea i stabilirea prioritilor
sunt mai bune, cu att mai eficient este metodologia.
Pe msur ce sarcinile stabilite sunt ndeplinite, noi sarcini pot fi descoperite. Acestea sunt
adugate sarcinilor rmase nesoluionate i se reatribuie prioritile. Procesul continu pn cnd
produsul este gata de lansare.
Prioritile se stabilesc pe baza unei funcii de prioritate, care depinde att de domeniul
problemei i de normele firmei. Ea trebuie s realizeze un compromis ntre cantitate i calitate, ntre
funcionalitate i constrngerile privind resursele, ntre ateptri i realitate. Toate funciile de
prioritate ar trebuie s aib ca prim scop lansarea produsului.
Pe lng rolul evident de a stabili prioritile i deci ordinea de execuie a sarcinilor de lucru,
funcia mai trebuie s gestioneze sarcinile conflictuale i nemonotone. Ea trebuie s mpart aceste
sarcini n grupuri consistente, s reglementeze selecia grupurilor consistente i apoi s dirijeze
selecia sarcinilor din cadrul grupurilor. Pe msur ce sistemul crete, funcia de prioritate trebuie s
aleag sarcini consistente cu partea deja constituit din sistem. O sarcin nemonoton vine n
contradicie cu sistemul realizat deja i trebuie eliminat dac nu este absolut necesar pentru
succesul sistemului.
Odat ce o component este terminat i acceptat de echip, schimbrile asupra sa sunt
ngheate. Componenta va fi schimbat numai dac modificrile sunt absolut necesare iar echipa
este dispus s ntrzie lucrul la restul sistemului pentru a le efectua. Schimbrile trebuie s fie
puine la numr, bine justificate i documentate.
Etapele principale ale metodei sunt: schia de principiu, prototipul, versiunile alfa/beta i
produsul final.
n prima etap, schia de principiu, echipele lucreaz simultan la toate fazele problemei.
Echipa de analiz sugereaz cerinele. Echipa de proiectare le discut i trimite sarcinile critice de
implementare echipei de implementare. Echipa de testare pregtete i dezvolt mediul de test n
funcie de cerine. Echipa de implementare se concentreaz asupra sarcinilor critice, care n general
sunt cele mai dificile. Aceast abordare contrasteaz cu practica curent de realizare mai nti a
sarcinilor simple. Totui, majoritatea produselor care urmeaz acest model eueaz. Odat ce
componentele critice au fost realizate, sistemul este gata de a face tranziia ctre stadiul de prototip.
Unul din scopurile acestei etape este de a se convinge echipele c o soluie poate fi gsit i pus n
practic.
n cea de a doua etap, de prototip, cerinele i documentul cerinelor sunt ngheate.
Schimbrile n cerine sunt nc permise, ns ar trebuie s fie foarte rare i numai dac sunt absolut
necesare, deoarece modificrile cerinelor n acest stadiu al proiectului sunt foarte costisitoare. Este
posibil totui ajustarea arhitecturii, pe baza noilor opiuni datorate tehnologiei. Dup ce sarcinile
critice au fost terminate, echipa de implementare se poate concentra pe extinderea acestora, pentru
definirea ct mai multor aspecte ale aplicaiei. Unul din scopurile acestei etape este de a convinge
persoanele din afara echipelor c o soluie este posibil.
Acum produsul este gata pentru lansarea versiunilor alfa i beta. Arhitectura este ngheat,
iar accentul cade pe implementare i asigurarea calitii. Prima versiune lansat se numete n
general alfa. Produsul este nc imatur; numai sarcinile critice au fost implementate la calitate
5

ridicat. Numai un numr mic de clieni sunt n general dispui s accepte o versiune alfa i s-i
asume riscurile asociate. O a doua lansare reprezint versiunea beta. Rolul su este de a convinge
clienii c aplicaia va fi un produs adevrat i de aceea se adreseaz unui numr mai mare de
clieni.
Cnd o parte suficient de mare din sistem a fost construit, poate fi lansat n sfrit produsul.
n aceast etap, implementarea este ngheat i accentul cade pe asigurarea calitii. Scopul este
realizarea unui produs competitiv. n produsul final nu se accept erori critice.
Avantaje
Metodologia ecluz recunoate faptul c oamenii fac greeli i c nici o decizie nu trebuie s
fie absolut. Echipele nu sunt blocate ntr-o serie de cerine sau ntr-o arhitectur imobil care se pot
dovedi mai trziu inadecvate sau chiar greite. Totui, pentru respectarea termenelor limit,
metodologia impune date de ngheare a unor faze. Exist timp suficient pentru corectarea greelilor
decizionale pentru atingerea unui nivel suficient de ridicat de ncredere. Se pune mare accent pe
comunicarea ntre echipe, ceea ce reduce cantitatea de cod inutil la care ar trebui s se renune n
mod normal. Metodologia ncearc s mute toate erorile la nceputul procesului, unde corectarea,
sau chiar renceperea de la zero a lucrului, nu sunt foarte costisitoare.
Dezavantaje
Metodologia presupune asumarea unor responsabiliti privind delimitarea etapelor i
nghearea succesiv a fazelor de dezvoltare. Ea presupune crearea unui mediu de lucru n care
acceptarea responsabilitii pentru o decizie care se dovedete mai trziu greit s nu se
repercuteze n mod negativ asupra individului. Se dorete de asemenea schimbarea atitudinii
echipelor fa de testare, care are loc nc de la nceput, i fa de comunicarea continu, care poate
fi dificil, ntruct cele patru faze reprezint perspective diferite asupra realizrii produsului.
3. Metodologii concrete
3.1. Metodologia cascad
Metodologia cascad, propus de Barry Boehm, este una din cele mai cunoscute exemple de
metodologie de ingineria programrii. Exist numeroase variante ale acestui proces. ntr-o variant
detaliat, metodologia cascad cuprinde urmtoarele etape:

Figura 4. Metodologia cascad

Dup fiecare etap exist un pas de validare. Procesul .curge. de la etap la etap, ca apa
ntr-o cascad. n descrierea originar a lui Boehm, exist o ntoarcere, un pas napoi interactiv ntre
fiecare dou etape. Astfel, metoda cascad este de fapt o combinaie de metodologie secvenial cu
elemente ciclice. Totui, n practica inginereasc, termenul .cascad. este utilizat ca un nume
generic pentru orice metodologie secvenial.
Acesta este modelul dup care de obicei sistemele sunt dezvoltate n practic. De asemenea,
reordonarea fazelor s-a dovedit a fi sub-optimal. Exist o mare atracie pentru acest model datorit
experienei, tradiiei n aplicarea sa i succesului pe care l-a implicat. O sarcin complex este
mprit n mai muli pai mici, ce sunt mai uor de administrat. Fiecare pas are ca rezultat un
produs bine definit (documente de specificaie, model, etc.)
Modelul cascad cu feedback propune remedierea problemelor descoperite n pasul
precedent. Problemele la pasul i care sunt descoperite la pasul i + 3 rmn neremediabile. Un model
realist ar trebui s ofere posibilitatea ca de la un anumit nivel s se poat reveni la oricare dintre
nivelele anterioare.
Dezavantajul principal al modelului n cascad apare deoarece clientul obine o viziune
practic asupra produsului doar n momentul terminrii procesului de dezvoltare. De asemenea,
modelul nu are suficient putere descriptiv, n sensul c nu integreaz activiti ca managementul
resurselor sau managementul configuraiei. Aceasta face dificil coordonarea proiectului.
Dup cum am menionat la prezentarea metodologiei generice secveniale, i modelul
cascad impune nghearea specificaiilor foarte devreme n procesul de dezvoltare pentru a evita
7

iteraiile frecvente (rentoarcerile n fazele anterioare atunci cnd n faza curent s-au detectat erori:
n timpul analizei se descoper erori de specificaii, n timpul implementrii se descoper erori de
specificaii/proiectare etc., astfel nct procesul poate implica multiple secvene de iteraii ale
activitilor de dezvoltare). nghearea prematur a cerinelor conduce la obinerea unui produs prost
structurat i care nu execut ceea ce dorete utilizatorul. Conduce de asemenea la obinerea unei
documentaii neadecvate deoarece schimbrile intervenite n iteraiile frecvente nu sunt actualizate
n toate documentele produse.
3.2. Metodologia spiral
Metodologia spiral, propus tot de Boehm, este un alt 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. El
definete urmtorii pai n dezvoltarea unui produs:
studiul de fezabilitate;
analiza cerinelor;
proiectarea arhitecturii software;
implementarea.
Modelul n spiral recunoate c problema principal a dezvoltrii programelor este riscul.
Riscul nu mai este eliminat prin aseriuni de genul: .n urma proiectrii am obinut un model corect
al sistemului., ca n modelul cascad. Aici riscul este acceptat, evaluat i se iau msuri pentru
contracararea efectelor sale negative. Exemple de riscuri:
n timpul unui proces ndelungat de dezvoltare, cerinele noi ale clientului sunt ignorate;
clientul schimb cerinele;
o firm concurent lanseaz un program rival pe pia;
un dezvoltator/arhitect prsete echipa de dezvoltare;
o echip nu respect un termen de livrare pentru o anumit component.
n modelul spiral se consider c fiecare pas din dezvoltare conine o serie de activiti comune:
pregtirea: se identific obiectivele, alternativele, constrngerile;
gestionarea riscului: analiza i rezolvarea situaiilor de risc;
activiti de dezvoltare specifice pasului curent (de exemplu analiza specificaiilor sau
scrierea de cod);
planificarea urmtorului stadiu: termenele limit, resurse umane, revizuirea strii
proiectului.
Metodologia spiral cuprinde urmtoarele etape, grupate pe patru cicluri:

Figura 5. Metodologia spiral

Ciclul 1 . Analiza preliminar:
1. Obiective, alternative, constrngeri
2. Analiza riscului i prototipul
3. Conceperea operaiilor
4. Cerinele i planul ciclului de via
5. Obiective, alternative, constrngeri
6. Analiza riscului i prototipul
Ciclul 2 . Analiza final:
7. Simulare, modele, benchmark-uri
8. Cerine software i validare
9. Plan de dezvoltare
10. Obiective, alternative, constrngeri
11. Analiza riscului i prototipul
Ciclul 3 . Proiectarea:
12. Simulare, modele, benchmark-uri
13. Proiectarea produsului software, validare i verificare
14. Integrare i plan de test
15. Obiective, alternative, constrngeri
16. Analiza riscului i prototipul operaional
Ciclul 4 . Implementarea i testarea:
17. Simulare, modele, benchmark-uri
18. Proiectare detaliat
19. Cod
20. Integrarea unitilor i testarea acceptrii
21. Lansarea produsului
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.
9

3.3. Metodologia spiral WinWin

Aceast metodologie extinde spirala Boehm prin adugarea unui pas de stabilire a prioritii
la nceputul fiecrui ciclu din spiral i prin introducerea unor scopuri intermediare, numite puncte
ancor. Procesul WinWin identific un punct de decizie. Pentru fiecare punct de decizie, se
stabilesc obiectivele, constrngerile i alternativele.
Punctele ancor stabilesc trei scopuri intermediare. Primul punct ancor, numit obiectivul
ciclului de via, precizeaz cazurile sigure de funcionare pentru ntregul sistem, artnd c exist
cel puin o arhitectur fezabil (adic posibil din punct de vedere practic) care satisface scopurile
sistemului. Primul scop intermediar este stabilit cnd sunt terminate obiectivele de nivel nalt ale
sistemului, arhitectura, modelul ciclului de via i prototipul sistemului. Aceast prim ancor
spune de ce, ce, cnd, cine, unde, cum i estimeaz costul produsului. Dup executarea acestor
operaii, este disponibil analiza de nivel nalt a sistemului.
Al doilea punct ancor definete arhitectura ciclului de via, iar al treilea . capacitatea
operaional iniial, incluznd mediul software necesar, hardware-ul, documentaia pentru client i
instruirea acestuia.
Aceste puncte ancor corespund etapelor majore din ciclul de via al unui produs:
dezvoltarea iniial, lansarea, funcionarea, ntreinerea i ieirea din funciune.
3.4. Prototipizarea
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 funcional a sistemului.
Aceast versiune nu reprezint ntregul sistem, ns este o parte a sistemului care cel puin
funcioneaz.
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.
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;
10

 se poate facilita instruirea utilizatorilor finali nainte de terminarea produsului.

Dintre dezavantajele principale ale prototipizrii amintim:
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.
3.5. Metodologia Booch
Aceast metodologie asigur o dezvoltare orientat obiect n fazele de analiz i proiectare.
Faza de analiz este mprit n mai muli pai. Primul pas este stabilirea cerinelor din perspectiva
clientului, genernd o descriere de nivel nalt a funcionrii i structurii sistemului. Al doilea pas
este analiza domeniului, realizat prin definirea claselor: atributele, metodele, motenirea. Faza de
analiz este terminat cu un pas de validare. Aceast faz itereaz cei trei pai pn cnd soluia este
consistent.
i faza de proiectare este iterativ. Design-ul logic este transformat n design fizic, cu detalii
privind firele de execuie, procesele, performanele, tipurile de date, structurile de date etc. Se
creeaz un prototip i apoi se testeaz. Faza itereaz design-ul logic, cel fizic, prototipurile i
testarea.
Metodologia Booch este secvenial n sensul c mai nti este terminat analiza i apoi
proiectarea. Ea este ciclic datorit iteraiilor din fiecare faz. Metoda se concentreaz n special
asupra acestor dou faze, de analiz i proiectare, fr s insiste foarte mult asupra implementrii i
testrii.
3.6. Metode formale
n acest model de dezvoltare, sunt folosite formalismul i rigoarea matematicii. n prima
faz este construit o specificaie n limbaj matematic. Apoi, aceast specificaie este transformat
n programe, de obicei printr-un proces incremental.
Avantaje:
precizia obinut prin specificarea formal;
pstrarea corectitudinii n timpul transformrii specificaiei n cod executabil;
ofer posibilitatea generrii automate de cod;
verificarea consistenei i testarea prin metode similare demonstrrii automate de teoreme.
Dezavantaje:
specificarea formal este de obicei o barier de comunicare ntre client i analist;
necesit personal foarte calificat (deci mai scump);
folosirea impecabil a tehnicilor specificrii formale nu implic neaprat obinerea de
programe sigure, deoarece anumite aspecte critice pot fi omise din specificaiile iniiale.
Datorit acestor caracteristici, metodele formale sunt potrivite n special pentru sisteme cu
cerine critice.

11

Exist mai multe limbaje pentru specificarea formal a funcionalitii programelor: Z, CSP
(Communicating Sequential Processes), VDM (Vienna Development Method), Larch, FDM
(Formal Development Methodology) etc.
n continuare, vom exemplifica cteva funcii simple de lucru cu o baz de date cu datele de
natere ale unor persoane, descris n limbajul Z (Spivey, 1989):

3.7. Extreme Programming

Extreme Programming (Kent Beck, 1996) este o metodologie care propune rezolvri
originale pentru problemele care apar n dezvoltarea de programe. Fiind o tehnologie nou (i
extrem) are att adepi ct i critici. XP consider c dezvoltarea programelor nu nseamn ierarhii,
responsabiliti i termene limit, aa cum se afl acestea pe masa administratorului, ci nseamn
colaborarea oamenilor din care este format echipa. Acetia sunt ncurajai s i afirme
personalitatea, s ofere i s primeasc cunotine i s devin programatori strlucii.
De asemenea, XP consider c dezvoltarea de programe nseamn n primul rnd scrierea de
programe. Aceast sintagm banal se pare c este uitat de multe companii care se ascund n
spatele proceselor de dezvoltare stufoase, a edinelor i a rapoartelor de activitate. XP ne amintete
cu respect ca fiierele PowerPoint nu se pot compila.
De altfel, inspirarea proceselor de dezvoltare a programelor din ingineria construciilor se
pare c nu este cea mai fericit alegere. Este adevrat c un inginer care vrea s construiasc un pod
peste un ru face mai nti msurtori, realizeaz un proiect i abia apoi trece la execuie, toate
acestea ntr-un mod secvenial i previzibil. Dar dezvoltarea de programe nu seamn cu aa ceva,
orict am vrea s credem asta. Dac inginerului constructor respectiv i s-ar schimba cerinele de
rezisten i i s-ar muta malurile chiar cnd a terminat de construit jumtate de pod, putem fi siguri
c acel inginer i-ar schimba modul de lucru. Din pcate ns, nu tim (nc) cum.
12

Iniiatorii XP definesc urmtoarele dou carte, ca baz filosofic pentru aceast

metodologie.
Carta drepturilor dezvoltatorului:
Ai dreptul s tii ceea ce se cere, prin cerine clare, cu declaraii clare de prioritate;
Ai dreptul s spui ct i va lua s implementezi fiecare cerin, i s i revizuieti estimrile
n funcie de experien;
Ai dreptul s i accepi responsabilitile, n loc ca acestea s-i fie asignate;
Ai dreptul s faci treab de calitate n orice moment;
Ai dreptul la linite, distracie i la munc productiv i plcut.
Carta drepturilor clientului:
Ai dreptul la un plan general, s tii ce poate fi fcut, cnd, i la ce pre;
Ai dreptul s vezi progresul ntr-un sistem care ruleaz i care se dovedete c funcioneaz
trecnd teste repetabile pe care le specifici tu;
Ai dreptul s te rzgndeti, s nlocuieti funcionaliti i s schimbi prioritile;
Ai dreptul s fii informat de schimbrile n estimri, suficient de devreme pentru a putea
reduce cerinele astfel ca munca s se termine la data prestabilit. Poi chiar s te opreti la
un moment dat i s rmi cu un sistem folositor care s reflecte investiia pn la acea dat.
Aceste afirmaii, dei par de la sine nelese, conin semnificaii profunde. Multe din
problemele aprute n dezvoltarea programelor pornesc de la nclcarea acestor principii.
Enumerm pe scurt cteva dintre caracteristicile XP:
Echipa de dezvoltare nu are o structur ierarhic. Fiecare contribuie la proiect folosind
maximul din cunotinele sale;
Scrierea de cod este activitatea cea mai important;
Proiectul este n mintea tuturor programatorilor din echip, nu n documentaii, modele sau
rapoarte;
La orice moment, un reprezentant al clientului este disponibil pentru clarificarea cerinelor;
Codul se scrie ct mai simplu;
Se scrie mai nti cod de test;
Dac apare necesitatea rescrierii sau eliminrii codului, aceasta se face fr mil;
Modificrile aduse codului sunt integrate continuu (de cteva ori pe zi);
Se programeaz n echip (programare n perechi). Echipele se schimb la sfritul unei
iteraii (1-2 sptmni);
Se lucreaz 40 de ore pe sptmn, fr lucru suplimentar.
4. Concluzii
Au fost prezentate aici cele mai importante metodologii de dezvoltare a programelor. Mai
nti au fost descrise metodologiile generice: secvenial, ciclic i hibrid, cu avantajele i
dezavantajele fiecreia. Apoi s-au amintit cteva metode concrete de dezvoltate: modelul cascad,
modelul spiral, WinWin, prototipizarea, metodologia Booch, metodele formale i aa-numita
"programare extrem".

13