1

L1. Modele de dezvoltare a programelor

Obiective
n aceast lucrare de laborator sunt prezentate modelele de dezvoltare ale sistemelor
software.
Dup parcurgerea acestui referat, studenii vor avea cunotinele necesare:
- identificrii avantajelor i dezavantajelor utilizrii unui anumit model de dezvoltare;
- adoptrii unui model de dezvoltare corespunztor tipului de aplicaie software ce
trebuie realizat.
Introducere
Dezvoltarea unui sistem software presupune parcurgerea unei secvene de pai care
conin activiti, constrngeri i resurse ce produc programul executabil. Aceste activiti sunt
cuprinse n ceea ce se numete procesul software.
Procesul de dezvoltare a sistemelor software se mai numete ciclu de via software
deoarece descrie viaa unui produs de la concepie pn la implementare, livrare, utilizare i
ntreinere.
n mod obinuit, dezvoltarea sistemelor software implic parcurgerea urmtoarelor etape:
Analiza cerinelor - stabilete cerinele clientului ntr-o manier ct mai clar i mai
fidel.
Proiectarea arhitectural furnizeaz o structur a sistemului ce trebuie implementat;
n general, se mparte sistemul ntr-un numr de module mai mici i mai simple, care pot fi
abordate individual.
Proiectarea detaliat - realizeaz proiectarea fiecrui modul al aplicaiei, n cele mai
mici detalii.
Scrierea codului - proiectul detaliat este implementat ntr-un limbaj de programare
inndu-se cont de structura rezultat la proiectarea arhitectural.
Integrarea componentelor - combin modulele programului n produsul final.
n ceea ce privete aceast etap, exist mai multe abordri:
- modelul de integrare big-bang - componentele sunt dezvoltate i testate individual
i apoi sunt integrate n sistemul final; la integrare pot aprea situaii ce nu au fost
luate n considerare n procesul de testare a componentelor 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.
- modelul de integrare incremental - se creeaz un nucleu al aplicaiei i se
integreaz 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 - se verific dac programul ndeplinete cerinele utilizatorului. Un
exemplu de validare este testarea de acceptare, n care produsul este prezentat clientului.
Verificarea - se verific stabilitatea i funcionarea corect a sistemului din punctul de
vedere al dezvoltatorilor.
ntreinerea - presupune corectarea eventualelor defecte sau erori dup ce programul
este livrat clientului i mbuntirea acestuia conform schimbrilor aprute n specificaiile
clientului.


2
Modelul de dezvoltarea n cascad
Modelul de dezvoltare n cascad (engl. waterfall) definete urmtorii pai n dezvoltarea
unui program:





















Figura 1. Modelul de dezvoltare n cascad
Avantaje:
- o sarcin complex este mprit n pri mai uor de administrat;
- la sfritul fiecrei faze este furnizat un set fixat de documente (specificaii, model etc.).
Dezavantaje:
- o etap de dezvoltare trebuie complet terminat nainte de nceperea etapei urmtoare;
- nu se precizeaz cum trebuie executai paii n dezvoltarea sistemului software;
- un client trebuie s atepte instalarea sistemului, deci terminarea procesului de
dezvoltare, pentru a vedea cum funcioneaz acesta;
- ntr-o anumit etap a dezvoltrii nu se poate influena rezultatul obinut ntr-o etap
precedent pentru a se remedia o problema gsit.

Observaii.
1. Adoptarea modelului n cascad cu reacie (figura 2) permite remedierea problemelor
descoperite n pasul precedent. Nici aceast soluie nu elimin complet inconvenientul precizat
anterior deoarece un model realist ar trebui s ofere posibilitatea ca de la un anumit nivel s se
poat reveni la oricare dintre nivelele anterioare.
2. n modelul de dezvoltare n cascad lipsete conceptul de prototipizare.
Prototipul este un produs dezvoltat parial care permite clientului i dezvoltatorilor s
analizeze aspectele funcionale majore ale sistemului propus i s decid dac este suficient de
apropriat de cel cerut.
Spre exemplu, dezvoltatorii pot construi un sistem care s conin cteva cerine cheie
pentru a se asigura c cerinele sunt consistente i fezabile; n acest fel se pot face modificri n
stadiul de analiz a cerinelor i nu n faza de testare, care ar presupune, evident, costuri mult mai
ridicate.
Similar se pot prototipiza pri arhitecturale, dup cum se poate observa n figura 3.
Analiza
cerinelor
Proiectarea
sistemului
Proiectarea
detaliat
Testarea unitilor i
testarea la integrare
Testarea
sistemului
Testarea de
acceptare
Operarea i
ntreinerea
Scrierea
codului
3
Punctele cheie ale cerinelor sunt fixate nainte de validarea oficial n faza de testare a
sistemului.























Figura 2. Modelul n cascad cu reacie






















Figura 3. Modelul n cascad cu prototipizare
Analiza
cerinelor
Proiectarea
sistemului
Proiectarea
detaliat
Testarea unitilor
i testarea la
integrare
Testarea
sistemului

Testarea de
acceptare
Operarea i
ntreinerea

Scrierea
codului
Analiza
cerinelor
Proiectarea
sistemului
Proiectarea
detaliat
Testarea unitilor i
testarea la integrare
Testarea
sistemului

Testarea de
acceptare
Operarea i
ntreinerea
Scrierea
codului
Prototipizare
Validare
Verificare
4
Modelul n V
Modelul n V este o variaie a modelului n cascad care pune n eviden legtura dintre
activitile de testare i cele de analiz i proiectare (figura 4).















Figura 4. Modelul n V
Observaii.
1. Testarea componentelor i testarea la integrare pot fi utilizate pentru verificarea
proiectrii detaliate.
2. Testarea sistemului verific dac toate elementele proiectrii sistemului sunt corect
implementate.
3. Testarea de acceptare verific dac toate cerinele clientului au fost implementate.
4. Dac se gsete o problem n timpul verificrii i validrii, atunci se execut din nou
etapa corespunztoare din ramura din stnga a modelului pentru a elimina problema aprut.
Modelul incremental
Modelul de dezvoltare incremental este similar modelului n cascad (figura 5).
Se identific cerinele sistemului i apoi se repet activitile de dezvoltare la fiecare
livrare nou.
Dezavantaj: Modelul incremental pleac de la o presupunere nerealist i anume aceea c att
sistemul ct i cerinele software rmn stabile.












Figura 5. Modelul incremental

Analiza
cerinelor
Proiectarea
sistemului
Proiectarea
detaliat
Testarea unitilor i
testarea la integrare
Testarea de
acceptare
Operarea i
ntreinerea

Scrierea
codului
Testarea
sistemului

Verificare proiectare
Validare cerine
Analiza
cerinelor
Proiectare Implementare ntreinere Instalare
Livrare 1
Proiectare Implementare ntreinere Instalare
Proiectare Implementare ntreinere Instalare
Livrare 2
Livrare i
5
Prototipizarea
Prototipizarea poate fi baza pentru un model al procesului de dezvoltare, dup cum se
poate observa n figura 6.











Figura 6. Prototipizarea
Avantaje:
- permite construirea unei versiuni funcionale a sistemului sau a unei pri a sistemului
cu scopul de a nelege sau de a clarifica anumite probleme;
- permite reducerea riscurilor i a incertitudinii n procesul de dezvoltare a sistemului
software;
- permite dezvoltatorilor s obin specificaii lipsite de ambiguitate i utilizatorilor s
schimbe specificaiile astfel nct s nu se modifice substanial durata de dezvoltare;
- se faciliteaz instruirea utilizatorilor finali nainte de terminarea produsului;

Dezavantaje:
- deoarece prototipul ruleaz ntr-un mediu artificial, anumite dezavantaje ale produsului
final pot fi scpate din vedere de clieni;
- clienii au posibilitatea s schimbe foarte des specificaiile.

Observaie. Exist dou feluri de prototipuri:
- de aruncat (engl., throw-away) - scopul este exclusiv obinerea unei specificaii.
punndu-se accentul doar pe viteza de dezvoltare i nu pe stilul de programare; dup stabilirea
cerinelor, codul prototipului este aruncat, sistemul final fiind rescris de la nceput, chiar n alt
limbaj de programare; acest tip de prototipizare poate fi nepopular printre dezvoltatori, deoarece
implic renunarea la propria munc.
- evoluionar - scopul este de a crea o schem cadru a aplicaiei care asigur funciile
majore ale sistemului; pe msur ce aplicaia este dezvoltat, se adaug caracteristici noi schemei
iniiale; n contrast cu prototipul de aruncat, aici se investete un efort considerabil ntr-o
proiectare modular i extensibil, precum i n adoptarea unui stil elegant de programare.
Modelul n spiral
Modelul n spiral combin avantajele modelului n cascad (planificare riguroas,
documente bine definite la sfritul fiecrei faze) cu avantajele dezvoltrii incrementale i ale
prototipizrii.
Riscul este o problem potenial ce poate aprea n dezvoltarea unui sistem software.
Modelul n spiral combin activitile de dezvoltare cu managementul riscurilor pentru a
minimiza i controla riscurile. n cazul proiectelor software riscurile frecvente ce pot aprea sunt:
Cerine incomplet, vag formulate sau greit nelese;
Personal neexperimentat, greit dimensionat, fluctuant;
Estimri greite ale bugetului i orarului de livrare;
Prototip
cerine
Prototip
proiect
Prototip
sistem
Testare
List
revizuiri
Sistem livrat
Cerine sistem (pot fi
informale sau incomplete)
List
revizuiri
List
revizuiri
prototip
revizuit
verificare
client/utilizator
6
Dependena de alte proiecte;
Interfaare necorespunztoare
Subestimarea nivelului de dificultate etc.
Modelul de dezvoltare n spiral are patru activiti principale (figura 7):
elaborarea obiectivelor sistemului software, a constrngerilor i a alternativelor
existente;
evaluarea alternativelor referitoare la obiective i constrngeri i identificarea surselor
majore de risc i rezolvarea sau diminuarea acestor riscuri;
definirea entitilor software care compun proiectul; activiti de dezvoltarea specifice
pasului curent
planificarea ciclului urmtor: buget, termene, revizuire proiect; terminarea proiectului
dac este prea riscant.

























Figura 7. Modelul n spiral
Modelul RUP
Modelul RUP (Rational Unified Process) este un model de dezvoltare iterativ care
presupune realizarea unui sistem software pe baza evalurii periodice a obiectivelor i
replanificarea pe baza acestor evaluri.
Procesul iterativ poate fi descompus n dou etape:
Etapa inginereasc (tehnic) n care:
- se dezvolt planuri;
- se stabilesc cerinele i arhitectura sistemului;
- se rezolv problema riscurilor ce pot aprea la dezvoltarea proiectului.
Aceast etap are ca rezultat o arhitectur executabil de baz. Proiectarea este realizat
Evaluare alternative
(prin prototipuri)
Identificare i rezolvare riscuri
Analiza risc (AR)
Determinare
obiective,
alternative,
constrngeri
AR
AR
AR
Simulare, modele
Prototip (PR)
PR
PR
Prototip
operaional
Proiectare
detaliat
Testare
uniti
Integrare i
testare
Implement.
Testare de
acceptare
Integrare,
plan testare
Plan dezvoltare
Concept
Validare
cerine
Proiectare
software
Validare/verificare
software
Plan
cerine
Dezvoltare
Planificare faza urmtoare
Cost cumulativ
START
7
de echipe de dimensiuni mai mici.
Etapa de producie n care se construiete o versiune utilizabil n contextul furnizat
de etapa anterioar. Construcia, testarea i implementarea activitilor sunt realizate de echipe de
dimensiuni mai mari.
ntr-un ciclu de dezvoltare iterativ fiecare faz descrie starea proiectului, avnd
importana sa i incluznd activiti n proporii diferite;
Faza reprezint timpul dintre dou milestone-uri majore ale proiectului, de-a lungul
cruia sunt atinse obiective bine definite i sunt luate decizii de trecere sau nu la faza urmtoare
(vezi figura 8). Este de precizat faptul c produsul este implementat n principal n fazele de
Elaborare i Construcie.









Figura 8. Fazele modelului RUP
n faza de iniiere echipa de dezvoltare stabilete obiectivele eseniale ale proiectului.
Rezultatele acestei faze sunt:
o enumerare a cerinelor principale ale sistemului;
o imagine de ansamblu asupra arhitecturii programului;
o descriere a obiectivelor proiectului;
un plan preliminar de dezvoltare.
Riscurile determinate de extragerea cerinelor trebuie identificate nainte de pornirea
proiectului.
Faza de elaborare are ca scopuri determinarea arhitecturii programului, stabilirea echipei
de lucru, eliminarea situaiilor cu risc mare. La ieirea din aceast faz se obin:
un prototip evoluionar al arhitecturii programului;
teste care verific funcionarea programului;
o descriere a majoritii funcionalitilor sistemului;
un plan de proiect detaliat pentru iteraiile urmtoare.
n faza de construcie se adaug cerinele neimplementate nc i se dezvolt complet
sistemul. Rezultatele acestei faze sunt:
programul propriu-zis;
teste;
manuale de utilizare.
n faza de tranziie programul este mbogit mai departe cu caracteristici, ns accentul
se pune pe mbuntirea i rafinarea celor existente pe baza reaciilor de la client. Sfritul
acestei activiti i a ntregului proces de dezvoltare are loc atunci cnd obiectivele propuse n
cadrul fazei de pornire sunt ndeplinite iar clientul este satisfcut.
Un proiect bazat pe RUP evolueaz n pai numii iteraii. Iteraia este o secven
distinct de activiti bazate pe un plan stabilit i pe criterii de evaluare din care rezulta un
livrabil executabil (versiune stabil, complet i executabil a sistemului). Este necesar
precizarea c faza de iniiere poate s nu necesite un livrabil executabil. Iteraia reprezint
punctul la care proiectul este evaluat i sunt realizate ajustrile necesare.
Scopul unei iteraii este s dezvolte un program funcional care s poat fi prezentat
timp
Tranziie Construcie Elaborare Iniiere
Etapa de producie Etapa inginereasc
Milestone
Arhitectur
Milestone
Capabilitate
operaional iniial
Milestone
Livrare
produs
Milestone
Obiective
8
clientului, iar clientul s l poat evalua.
Durata unei iteraii depinde de tipul de proiect la care se lucreaz, de fazele proiectului,
de experiena echipei etc. Este de preferat ca iteraiile s fie ct mai scurte. n general, iteraiile
din faza de Elaborare sunt mai mari dect iteraiile din faza de Construcie.
n ceea ce privete numrul de iteraii, tabelul 1 prezint valorile medii n funcie de
fazele procesului de dezvoltare.
Tabel 1. Numrul de iteraii n fazele de dezvoltare RUP
Numr total de iteraii Faza de dezvoltare
[I,E,C,T]
Mic 3 [0,1,1,1]
Tipic 6 [1,2,2,1]
Mare 9 [1,3,3,2]
Foarte mare 10 [2,3,3,2]
n interiorul unei faze, iteraiile au n general aceeai lungime. Pentru majoritatea
proiectelor durata unei iteraii este ntre 1 lun i 2 luni. Iteraiile mai mari de 6 sptmni au
nevoie n general de milestone-uri intermediare. Reducerea obiectivelor unei iteraii duce la
reducerea duratei i la o nelegere mai clar a scopurilor. Iteraiile mai mici de o lun trebuie
planificate cu atenie. n general, iteraiile scurte sunt mai convenabile n faza de Construcie
unde gradul de includere de noi funcionaliti i gradul de noutate sunt mici. Iteraiile scurte pot
s nu necesite analiz formal i proiectare.
Conform modelului de dezvoltare RUP, n interiorul fiecrei iteraii au loc urmtoarele
activiti (figura 9) .
Modelarea funcional. Sunt sintetizate necesitile funcionale.
Cerine. Se translateaz necesitile funcionale n comportament de sisteme automate.

Figura 9. Activiti n interiorul fazelor
Analiza i Proiectare. Se translateaz cerinele n arhitectura programului.
Implementare. Se creeaz programul conform cu arhitectura astfel nct s se asigure
comportarea dorit.
Testare. Se asigur corectitudinea comportrii cerute sistemului i prezena tuturor
comportrilor dorite n program.
Managementul configuraiei i a schimbrilor. Se gestioneaz toate versiunile tuturor
entitilor din care este compus programul.
Managementul proiectului. Sunt administrate planificrile i resursele.
Administrarea mediului. Se instaleaz i se menine mediul de lucru necesar
dezvoltrii proiectului.
9
Plasare. Se efectueaz activitile necesare punerii n funciune a proiectului.
Aceste activiti nu sunt separat n timp ci , din contr, se execut n paralel de-a lungul
ciclului de via al proiectului. Spre exemplu, dup cum se observ n figura 9, n faza timpurie a
proiectului se scrie o cantitate mic de cod. De asemenea, pe msur ce proiectul evolueaz se
cunosc majoritatea cerinelor, dar pot aprea i cerine noi, deci activitatea cerine dureaz tot
ciclul de via al proiectului. Astfel, odat cu dezvoltarea proiectului, ponderea activitilor crete
sau scade, dar nici una dintre activiti nu este anulat pe parcursul dezvoltrii proiectului.
O problem important care apare n cazul modelului RUP este realizarea primei iteraii,
care, n general, este ce mai dificil. Prima iteraie necesit participarea i consensul liderilor de
proiect. Trebuie rezolvate problemele de integrare i de organizare a echipei. Pentru a fi siguri de
succes trebuie ca n prima iteraie s se ncerce asigurarea unei minime funcionaliti. n caz
contrar terminarea primei iteraii va fi ntrziat i va exista presiunea reducerii numrului de
iteraii, pierzndu-se avantajele abordrii iterative.
O alt problem care trebuie abordat este alegerea strategiei de iterare. Aceasta poate fi
de tipul:
Wide and Shallow. n acest tip de strategie se analizeaz ntregul domeniu al
problemei dar se iau n considerare doar detaliile de suprafa. Se definesc toate cazurile de
utilizare i majoritatea se completeaz la un nivel de detaliu ridicat pentru o nelegere exact a
problemei. Se definete n linii mari arhitectura sistemului i serviciile i mecanismele cheie
oferite de componentele arhitecturale. Se definesc de asemenea interfeele, dar detaliile interne se
detaliaz doar dac trebuie luat n considerare un risc. Majoritatea iteraiilor are loc n faza de
Construcie.
Narrow and Deep. Se analizeaz o poriune a domeniului problemei. Cazurile de
utilizare se definesc i se completeaz n detaliu. Se definete arhitectura necesar asigurrii
comportrii dorite a sistemului. Se proiecteaz i se implementeaz sistemul. Iteraiile care
urmeaz se focalizeaz pe analizarea, proiectarea i implementarea domeniilor verticale
suplimentare.
Hibrid. Aceast strategie este o mixtur a strategiilor anterioare.
Avantaje RUP
Se iau n considerare la nceputul dezvoltrii proiectului riscurile majore ale
proiectului.
Dezvoltarea iterativ produce n primul rnd arhitectura sistemului, deci integrarea
apare ca activitate de verificare a fazei de proiectare
Defectele de proiectare sunt detectate i rezolvate la nceputul ciclului de via.
Are loc o integrare continu, evitndu-se integrarea de tip big bang la sfritul
proiectului.
Permite o abordare mai bun a conceptului de calitate deoarece o mare parte a
caracteristicilor sistemului (performan, tolerana la defecte) sunt tangibile la nceputul
procesului.
Problemele sunt corectate fr a periclita intele de cost i orarul proiectului.

Probleme propuse
1. Pentru fiecare dintre modelele de dezvoltare prezentate mai sus, precizai avantajele i
dezavantajele majore.
2. Modificai modelul de dezvoltare incremental innd cont de faptul c cerinele unui
sistem software se modific n timp.
3. Marcai diferenele ntre prototipul de aruncat i prototipul evoluionar.
4. Precizai sursele frecvente ale riscurilor n dezvoltarea unui sistem software.
5. Comparai strategiile de iterare utilizate n modelul de dezvoltare RUP.