Modele ale Procesului de dezvoltare software

Ca orice produs fabricat complex, un program este realizat urmnd un anume

proces.
Un proces de dezvoltare a programelor se bazeaz pe o formalizare a activitilor
specifice, la care ne-am referit. Scopul formalizrii este obinerea unui ansamblu de
mecanisme care, n cazul n care sunt aplicate sistematic permit obinerea ntr-un
mod repetitiv i fiabil de produse software de calitate constant. Descrierea
procesului rmne general, pentru c nu este posibil s se defineasc un standard
unic adaptat la toate tipurile de aplicaii i la toate persoanele.

Dezvoltarea unui program poate fi vzut ca stabilirea unui ir de descrieri din ce n

ce mai precise i din ce n ce mai apropiate de un program executabil i de
documentaia sa. Trecerile de la o descriere la alta sunt deseori numite rafinri
succesive. Aceasta este o vedere simplificat, pentru ca nu ia n considerare natura
iterativ a procesului de dezvoltare.

O dat dezvoltat un program, este pus n exploatare. Se pun atunci probleme de

ntreinere, de corectare a defectelor, de ameliorare a anumitor caracteristici sau de
urmrire a evoluiei cerinelor. Intreinerea poate impune modificarea funciilor
sistemului i deci, un proces de redezvoltare. Din aceasta cauz se vorbete despre
ciclul de via al unui program, cnd considerm exploatarea i ntreinerea n plus
fa de dezvoltare.

Ce este ciclul de viata al unui program (Software life cycle)?

O secventa de etape in existenta produsului software. Sunt incluse toate

activitatile necesare pentru dezvoltarea produsului si relatiile
temporale dintre ele.
Fiecare etapa din ciclul de viata este caracterizata prin activitati specifice
si produsele rezultate din activitatile respective.

1
Modele ale ciclului de viata software (Software development life cycle models
or process models):
Waterfall model (Modelul cascada)
V model (modelul in V)
ESA ( European Space Agency) model
Incremental model (Modelul iterativ si incremental)
Dezvoltarea agila
Prototyping (Dezv pe baza de prototip)
Spiral model (Modelul in spirala)

Modelul cascada

Numit si modelul clasic al ciclului de viata sau modelul liniar

Descris de Royce n 1970, a fost larg utilizat de atunci, pentru descrierea

general a procesului de dezvoltarea programelor.

Ciclul de via n cascad prezint dezvoltarea unui program ca o succesiune de

faze ce se nlnuie ntr-o derulare liniar, de la analiza cerinelor i pn la
livrarea produsului ctre client.

Fiecare faz corespunde unei activiti i trebuie s se termine la o anumit dat

prin producerea anumitor documente sau programe.

Rezultatele fazei sunt supuse unei revizii aprofundate i nu se trece la faza

urmtoare dect atunci cnd sunt considerate satisfctoare.

2
 In prima sa versiune, modelul avea numai sgei descendente, care
materializeaz nlnuirea etapelor; el nu prevedea iteraii. Sgeile ascendente au
fost adugate mai trziu pentru a ilustra principiul c o etap repune n discuie
numai etapa precedent.

Limitele modelului n cascad

Modelul n cascad se bazeaz pe o secven de faze bine delimitate.

Documentele produse de fiecare faz sunt evaluate n cadrul reviziilor care
valideaz trecerea de la o faz la alta. Din pcate, proba efectiv a bunei sau a
proastei functionri a sistemului este realizat numai n cadrul fazei de integrare,
cnd este posibil evaluarea concret a programului. Inaintea acestei faze au fost
produse numai documente.

3
 Abordarea n cascad d rezultate satisfctoare numai n cazul n care este
efectiv posibil nlnuirea fazelor fr prea multe probleme. Aceasta presupune
ca ansamblul cerinelor s fie perfect cunoscut i problema complet nteleas de
analiti. Trebuie de asemenea ca soluia s fie uor de determinat de proiectani i
codificarea simpl - redus ideal la generarea automat a codului plecnd de la
documentele de proiectare.
In realitate se constat c partea de necunoscut poate fi nsemnat n anumite
dezvoltri, n special datorit:
- nenelegerii cerinelor de ctre client sau analist;
- instabilitii cerinelor;
-alegerilor tehnologice;
-schimbrilor de personal.
Din toate aceste motive sunt necesare reveniri n etape anterioare ale procesului
de dezvoltare. Aceste reveniri sunt de fapt o reflectare a realitii. Dac aceste
reveniri sunt ocazionale i limitate la faze adiacente, modelul n cascad este
pertinent. In caz contrar, modelul n cascad nu corespunde realitii.

Avantaje:

1. Sistemul este bine documentat

2. Permite un bun management al proiectului:

planificarea resurselor umane pe etape

estimari de cost mai exacte

Dezavantaje:

1. Un produs executabil, care sa demonstreze functionarea sistemului este

disponibil destul de tarziu, dupa integrare. Pana atunci s-au produs numai
documente.
2. Deoarece modelul este secvential, exista numai uhn feedback local, la
tranzitiile intre faze.

3. Multe erori sunt descoperite tarziu cost crescut

4
 4. Toate riscurile sunt incluse intr-un singur ciclu de dezvoltare

Adecvat pentru proiectele in care cerintele sunt bine intelese de la inceput si nu se

modifica pe parcursul procesului de dezvoltare.

Experienta ultimelor decenii a demonstrat ca modelul este valoros.

Este utilizat si in prezent de multe organizatii mari.

Modelul in V

Este o varianta a modelului cascada, care pune in evidenta corelarea dintre

activitatile de specificare si cele de testare, inlantuirea in timp a activitatilor fiind
aceeasi.

5
Partea din stanga reprezinta lantul de specificare a sistemului iar cea din dreapta
lantul de testare. Partea de jos a v-ului reprezinta implementarea

In acest model exist dou tipuri de dependene ntre etape:

-cele reprezentate prin liniile care formeaza V-ul, care corespund nlanuirii i
eventualei iteraii din modelul cascad; etapele se deruleaz deci secvenial, urmnd
V-ul de la stnga la dreapta;

-cele reprezentate prin linii orizontale, care indic faptul c o parte din
rezultatele etapei din care pleac sgeata sunt utilizate direct n etapa int. De
exemplu, la terminarea etapei de proiectare arhitectural, cazurile de teste de
integrare trebuie s fie complet descrise.

Prototiparea

Pentru sisteme noi, n mod special dac ele sunt mari i complexe este puin probabil
s se construiasc o specificaie complet, logic i valid nainte ca sistemul sa fie
construit i utilizat. Acest fapt a condus la ideea prototiprii. Ideea este de a permite

6
viitorilor utilizatori s exerseze cu o prim versiune a sistemului, care poate fi obinut
rapid prin tehnici de simulare i/sau de interpretare a specificaiilor. In acest ultim
caz, limbajele logico-funcionale sunt n mod sigur chemate s joace un rol important.

Prototipul este o schi a viitorului sistem: el nu are performanele i nu rspunde

exigenelor de calitate ale unui produs finit. Prototipul ofer clientului functionaliti
(nu n totalitate) ale viitorului sistem i interfaa sa utilizator. El este dezvoltat ntr-o
manier iterativ. Cerinele sunt extrase i validate iterativ prin utilizarea prototipului.
In fiecare iteraie specificaia sistemului este modificat i detaliat pn cnd
prototipul satisface necesitile utilizatorilor.

Un prototip care este utilizat pentru a desprinde cerinele viitorilor utilizatori, este o
"machet exploratoare".

Activitatea de prototipare poate interveni de asemenea n etapa de proiectare,

pentru a experimenta i compara diferite variante. Astfel de prototipuri se numesc
"machete experimentale".

Figura urmtoare red procesul de prototipare dedicat extragerii cerinelor:

7
 Pentru dezvoltarea prototipului se folosesc limbaje de nivel foarte nalt:
Smalltalk, PROLOG, LISP, SETL i altele. In prezent exist limbaje i medii de
dezvoltare specializate pentru construirea prototipurilor. Astfel de limbaje sunt
limbajele de generaia a 4-a (4GL).
Cu toate c se poate folosi acelai limbaj de programare, att pentru
realizarea prototipului ct i pentru dezvoltarea aplicaiei, se recomand ca prototipul
s fie considerat un sistem "nchis", adic s nu fie folosit ca baz pentru dezvoltarea
aplicaiei. Aceasta deoarece:
- prototipul a fost dezvoltat prin modificri succesive, de aceea arhitectura sa
iniial a fost alterat, ceea ce ngreuneaz ntreinerea;
- prototipul trebuie s corespund cerinelor utilizatorilor numai din punct de vedere
funcional. De aceea, n dezvoltarea sa sunt neglijate aspecte ca: eficiena,
adaptabilitatea, compatibilitatea i chiar fiabilitatea.

Modelul Incremental

Modelul ciclului de via "Incremental" este opus modelului in cascada .

El se bazeaz pe o idee foarte simpl: dac un sistem este prea complex pentru a
fi neles, conceput sau realizat intr-o singura faz este mai bine sa fie realizat n
mai multe faze, prin evoluie.

8
Cum se aplica

Intr-o faza initiala:

o Se studiaza scopul proiectului si fezabilitatea sa. In cazul deciziei de
continuare a proiectului:

o Se detaliaza cerintele utilizatorilor si se efectueaza o analiza de nivel

inalt, pentru a se determina cerintele software la un nivel general.

o Se determina o arhitectura generala a sistemului.

o Se impart cerintele in subseturi care pot fi implemenate in incremente

separate. Se stabileste planificarea in timp a incrementelor.

Fiecare increment implementeaza un subset de cazuri de utilizare de nivel inalt,

care exprima cerintele utilizatorilor. El este construit urmand abordarea
cascada: analiza detaliata a cerintelor din subset, proiectarea, implementarea si
testarea. Rezultatul este un produs care satisface un subset al cerintelor si este
livrat utilizatorilor.

Un produs tipic consta din 10-50 incremente.

9
 Se incepe cu o implementare simpla a unui subset al cerintelor software. Rezulta
o prima livrare.
Scopul primei implementari este de a crea un produs la care utilizatorul poate
reactiona. El trebuie sa puna in evidenta aspectele cheie ale problemei si sa
furnizeze o solutie sufient de simpla pentru a fi inteleasa si usor de implementat.

Fiecare noua iteratie include analiza ultimei versiuni si adaugarea de noi

functionalitati, ceea ce presupune reproiectarea, codificarea si testarea. Se
urmareste ca proiectarea sa fie directa, modulara, sa suporte reproiectarea.

Analiza unei iteratii se bazeaza pe feedback-ul utilizatorului si pe instrumentele

de analiza disponibile. Ea se refera la: modularitea produsului, cuplarea
modulelor, utilizabilitatea, fiabilitatea, eficienta si realizarea scopurilor.

Fiecare iteratie este o varianta imbunatatita a celei anterioare, de aceea metoda

se mai numeste imbunatatirea iterativa (iterative enhancement).

Se utilizeaza masuri pentru evaluarea evolutiei sistemului. Masurile prin care se

evalueaza un software sunt dificil de inteles ca valori absolute, dar schimbarile
valorilor lor in evolutia unui sistem sunt o baza de comparatie. Astfel de masuri
sunt: numarul de defecte, efortul de actualizare, dimensiune, complexitatea,
cuplarea modulelor. Schimbarile diferitelor aspecte se pot monitoriza si se pot
stabili limite pentru anumite masuri, pentru a semnala probleme sau anomalii.

Utilizarea analizei si a masuratorilor ca ghid in procesul iterativ este o diferenta

majora intre aceasta metoda si metodele de dezvoltare agila (agile software
development). Ele sunt suportul pentru determinarea eficientei procesului si a
calitatii produsului.

Fiecare iteraie a ciclului de via iterativ si incremental reproduce ciclul de via

n cascad la o scar mai mic. Obiectivele unei iteraii sunt stabilite pe baza
evalurii iteraiilor precedente. Documentaia este construit treptat, n timpul
fiecrei iteraii. La sfritul dezvoltrii, documentele obinute au aceeai form cu
cele obinute n maniera convenional.

10
Avantaje:
In fiecare etapa este livrat un produs executabil, care satisface o parte din
cerintele utilizator. Opus modelului cascada in care se elaboreaza documente.
Prototipurile sunt livrate clientului/utilizatorilor.
Feedback-ul utilizatorilor este distribuit pe intreg parcursul dezvoltarii.
In cazul aparitiei unor schimbari in cerinte acestea pot fi incoporate in
urmatorul prototip.

Ciclul de via iterativ se bazeaz pe evoluia prototipurilor executabile, msurabile i

deci pe evoluia elementelor concrete. El este opus din acest punct de vedere
ciclului de viata n cascad care se bazeaz pe elaborarea de documente. Livrrile
foreaz echipa s dea rezultate concrete n mod regulat.
Integrarea diferitelor componente ale programului este realizat ntr-o manier
progresiv n timpul construciei.
Progresele se msoar prin programe demonstrabile mai degrab dect prin
documente sau estimri, ca n ciclul de via n cascad;

In cursul dezvoltrii, clientul poate utiliza prototipurile. Demonstrarea prototipurilor

prezint numeroase avantaje:
- utilizatorul este pus n faa situaiilor de utilizare concrete care-i permit s-i
defineasc mai bine dorinele i s le comunice echipei de dezvoltare;
- utilizatorul devine partener al proiectului; el si ia partea de responsabilitate n noul
sistem i de fapt l accept mai uor;

Dezavantaje
Ciclul de via Incremental se bazeaz pe evoluia prototipurilor executabile. Din
nefericire, programele nu se preteaz n mod natural evoluiei, din contr, ele sunt
deseori foarte "fragile" la modificri. Efectul unei modificri locale se poate
propaga n ansamblul aplicaiei. Fiecare nou increment poate necesita
reorganizarea structurii interne, degradand arhitectura initiala a programului,
facndu-l greu de verificat i de ntreinut.

11
 Erorile de proiectare sunt mai greu de eliminat.
Abordarea obiect bazat pe modularitate i ncapsulare conduce la programe mai
robuste i mai rezistente fa de schimbri. Din acest punct de vedere, abordarea
obiect furnizeaza un cadru confortabil pentru dezvoltarea prin evoluie, ntr-o
manier iterativ.
Clientul poate vedea ce se poate face si poate cere mai mult!
Abordarea incrementala se poate transforma usor intr-una codifica si
repara ( build and fix ).

Planificarea

Principalul risc in utilizarea unui model incremental este de a lucra intr-o manierea
ad-hoc. Determinarea unui plan de actiuni este de prima importanta pt succesul
abordarii incrementale. In faza de analiza preliminara se determina scopul
proiectului si se incearca determinarea riscurilor majore ale proiectului, se determina
o lista o cerintelor si constrangerilor mai importante, pt a construi un plan de
dezvoltare. Se stabileste natura fiecarui icrement si ordinea de construire a
incrementelor.

O varianta a modelului este Numai implementarea incrementala:

Urmeaza modelul cascada pana in faza de implementare

In timpul analizei cerintelor si proiectarii de sistem:
o Se definesc subseturi / subsisteme care pot fi livrate
o Se definesc interfete care permit adaugari iterative simple, cu un minim
de modificari a arhitecturii existente
Diferitele parti sunt implementate, testate si livrate in functie de diferite
prioritati si la diferite momente de timp

12
Construirea in paralel a incrementelor: risc

Diferite incremente pot fi construite in paralel de diferite echipe.Dupa inceperea fazei

de proiectare a primului increment, echipa de specificare incepe specificarea celui
de-al 2-le increment. Riscul este ca cele 2 incremente sa nu se potriveasca. In mod
norma, al 2-lea trebuie sa-l includa pe primul. Fiecare increment are parti comune cu
altele. Este necesara o buna comunicare si coordonare intre echipele care
construiesc in paralel incrementele care au parti comune (privind implementarea
partilor comune). Aceste probleme cresc exponential cu numarul de incremente.

Rational Unified Process (RUP: www.rational.com)

Este un proces de dezvoltare iterativ. Cei care l-au definit, Ivar Jacobson, Grady
Booch, and James Rumbaugh, il caracterizeaza astfel:

Dirijat de cazurile de utilizare

Modelul cazurilor de utilizare descrie complet functionalitatea sistemului. Cazurile de

utilizare dirijeaza procesul de dezvoltare: dezvoltatorii creaza modele de proiectare
si implementare pentru a realiza cazurile de utilizare iar testorii testeaza sistemul
pentru a verifica daca sistemul implementeaza corect cazurile de utilizare.

Centrat pe arhitectura

Arhitectura sistemului este aspectul cel mai important al sistemului. Arhitectul

selecteaza cazurile de utilizare care reprezinta functile cheie ale sistemului (5%-10%
din cazurile de utilizare), le specifica in detaliu si le realizeaza in termeni de
subsisteme, clase, componente.

Inerativ si incremental

Proiectul de dezvoltare software este divizat in mini-proiecte, fiecare fiind o iteratie

din care rezulta un increment. Fiecare iteratie are de-a face cu cele mai importante
riscuri si realizeaza un grup de cazuri de utilizare care impreuna extind utilizabilitatea

13
produsului. In fazele initiale, un proiect initial poate fi extins cu unul mai detaliat. In
fazele urmatoare, incrementele sunt in mod tipic aditive.

Agile software development

Este un cadru conceptual pentru proiectele software. Exista mai multe metode de
dezvoltare agila, cum sunt cele expuse de Agile Alliance, o organizatie non-
profit.

Pentru orice proiect software exista o serie de factori de risc care pot periclita
finalizarea cu succes a proiectului, cum ar fi: factori de experienta ( conducatorului
de proiect, a echipei), factori de planificare, factori tehnologici, factori externi
(modificarea cerintelor, modificarea interfetelor externe).
Cele mai multe metode de dezvoltare agila incearca sa minimizeze riscul
dezvoltand software-ul in intervale scurte de timp, numite timeboxes, constand
din 1-4 saptamani. Data de sfarsit a unui timebox nu poate fi modificata. Daca
echipa depaseste data, iteratia este anulata si replanificata.
Fiecare iteratie este un proiect software in miniatura si include toate activitatile
necesare livrarii mini-incrementului unei noi functionalitati: planificare, analiza
cerintelor, proiectare, codificare, testare, documentare.
Fiecare noua iteratie trebuie sa livreze un nou produs. La sfarsitul fiecarei iteratii
echipa re-evalueaza prioritatile proiectului.

Timebox-urile sunt utilizate in ,metodele de dezvoltare agila ca o forma de

management al riscului in dezvoltarea unui software.

Metodele agile pun in evidenta comunicarea directa intre participantii la elaborarea

unei iteratii, in locul documentelor scrise. Acestia lucreaza in aceeasi locatie, intre ei
fiind cel putin programatorii si clientii lor (cei care definesc produsul). Echipa poate
include testori, proiectanti de interactiune, echipe de documentare tehnica si
manageri.

Principala masura a progresului este considerata software-ul functional. Se produce

foarte putina documentatie, motiv pentru care metodele sunt criticate.

14
Pentru mai multe informatii despre metodele de dezvoltare agila:
http://www.agilealliance.org/.

Comparatie cu alte metode

Considerand ca metodele de dezvoltare pot fi plasate pe o scara continua de la cele

adaptive la cele predictice, metodele agile se situeaza la extremitatea celor adaptive.

<--Agile--> <--Iterative/Incrementale--> <--Cascada-->

<-------------|------------------------------------|----------------|->
Adaptive Predictive

Metodele adaptive sunt focalizate pe adaptarea rapida la schimbari. Nu se au in

vedere cu exactitate ce se va intampla in viitor. O echipa adaptiva poate raporta
exact ce sarcini vor fi realizate saptamana urmatoare si ce este planificat pentru luna
urmatoare.

Metodele predictive sunt focalizate pe planificarea in detaliu a activitatilor, in

timp. O echipa predictiva poate raporta exact ce este planificat pentru intreagul
proces de dezvoltare. Echipa predictiva are dificultati in schimbarea directiei. Planul
este optimizat pentru desinatia originala iar schimbarea directiei poate necesita
renuntarea la rezultatele curente si replanificarea activitatilor. Numai schimbarile
considerate importante sunt luate in considerare.

In comparatie cu metodele incrementale:

- asemanare- creaza produse livrabil in perioade de timp scurte

- deosebiri:

perioadele de timp sunt masurate in saptamani si nu luni

perioadele de timp sunt stricte (time-box-uri)

in metodele incrementale procesul este ghidat de analiza

si masurare a caracteristicilor produsului. Ele sunt
suportul pentru determinarea eficientei procesului si a
calitatii produsului

15
In comparatie cu modelul cascada

Dezvoltarea agila are foarte putine in comun cu dezvoltarea cascada. Modelul

cascada are si in prezent o utilizare larga.. Modelul cascada este cel mai predictiv,
activitatile sunt pre-planificate intr-o secventa. Progresul este masurat prin produse
intermediare (specificatii, doc de proiectare, planuri de testare, revizii ale codului,
etc). Efortul de integrare si testare poate fi foarte mare (cateva luni cativa anui!),
fiind una dintre cauzele de esec ale unei dezvoltari cascada. Prin dezv agila se
produc produse executabile intervale de cateva saptamani sau luni. Se pune
accentul pe obtinerea de executabile cat mai repede apoi imbunatatirea lor continua!

Extreme Programming, este o metoda de dezvoltare agila care a crescut

popularitatea metodelor agile.
Extreme Programming (XP) este un model incremental bazat pe iteratii scurte,
testare intensiva si simplitate. Este adecvata pentru echipe mici si proiecte
caracterizate prin schimbari rapide ale cerintelor.
Informatii suplimantare despre XP pot fi gasite la: www.extremeprogramming.org,
www.xprogramming.com.

Modelul spirala

Barry Boehm a definit acest model plecand de la slabiciunile modelului cascada, in

special lipsa sa de flexibilitate la schimbari ale cerintelor.

Este focalizat pe analiza riscurilor in mod incremental, repetand modelul cascada

intr-o serie de cicluri, ca in figura urmatoare.

Fiecare ciclu consta din 4 faze.

1. Determinarea obiectivelor: definirea produsului, determinarea scopurilor si a

constrangerilor, generarea alternativelor.

16
 2. Evaluarea alternativelor: analiza riscurilor, prototiparea
3. Dezvoltarea produsului: proiectarea de detaliu, testarea unitara, integrarea,
.
4. Planificarea urmatorului ciclu: evaluarea de catre client, planificarea
dezvoltarii si a livrarii catre client.

Este o imbunatatire a modelului cascada deoarece prevede mai multe livrari

si mai multe posibilitati de implicare a clientului.

Raza spiralei reprezinta costul acumulat.

Informatii suplimentare: http://www.stsc.hill.af.mil/crossTalk/2001/05/boehm.html.

17
Ulterior Boem a sugerat o versune modificata a modelului modelul spirala WinWin,
care adauga la inceputul fiecarui ciclu activitati de identificare a partilor interesate in
proiect (stakeholders) si conditiile lor de castig (win conditions).

18