Modele de procese software

“Ce se întâmplă cu ‘viaţa’ software-ului”

Universitatea Piteşti 1
 Modele de procese software
 Constă într-o reprezentare simplificată a proceselor
software. Reprezintă o descriere a acestora pentru o
formă particulară dintr-o anumită perspectivă.
 Modele generice de procese
 Modelul în cascadă
 Modelul în V
 Modelul în siprală, etc...

Universitatea Piteşti 2
Modelul Waterfall
System
Engineering

Analysis

Design

Code

Testing

Maintenance

Universitatea Piteşti 3
Descrire Model
 Descris de Royce în 1970, a fost larg utilizat de atunci,
pentru descrierea generală a procesului de dezvoltarea
programelor.
 Ciclul de viață al modelului în cascadă prezintă dezvoltarea
unui program ca o succesiune de faze ce se înlănțui într-o
derulare liniară, de la analiza cerințelor și până la livrarea
produsului către client.
 Fiecare fază corespunde unei activități ț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 următoare decăt atunci când sunt
considerate satisfăcătoare.

Universitatea Piteşti 4
Avantaje ale modelului Waterfall
 Uşor de înţeles și de utilizat
 Activităţile decurg dintr-o fază în alta
 Dacă apare o corecţie, se întoarce la faza anterioară după
care intră în ciclul normal
 Problemele principale sunt uşor de înţeles
 Bun pentru controlul managementului (organizare,
personal, urmărire)
 Este preferat atunci când pe primul loc este calitatea în
raport cu costul şi timpul de realizare

Universitatea Piteşti 5
Probleme ale modelului Waterfall
Model
• Toate cerinţele trebuie să fie cunoscute înainte
• Rezultatele create pentru fiecare etapă sunt
considerate definitive - inhibă flexibilitatea
• Poate da o falsă impresie de progres
• Integrarea este doar o problemă importantă la
sfârşit
• Slabe şanse pentru beneficiar de a previzualiza
sistemul (până când nu va fi prea târziu)

Universitatea Piteşti 6
Aplicarea modelului Waterfall
• Cerinţele sunt cunoscute foarte bine
• Definirea produsului este clară
• Tehnologia este bine înţeleasă
• Este o nouă versiune a unui produs existent
• Portarea unui produs existent pe o platformă
nouă.

Universitatea Piteşti 7
Modelul V

Universitatea Piteşti 8
 Descrierea modelului 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

• Partea din stanga reprezinta lantul de specificare a

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

Universitatea Piteşti 9
 Etapele modelului V
• Definirea cerintelor
utilizator/sistem – alocare resurse
• Definirea cerintelor software –
reprezintă specificarea completă a
sistemului
• Proiectarea arhitecturală –
defineşte cum completează întregul
proiect funcţiile software
• Proiectarea detaliata – dezvoltarea
de algoritmi pentru fiecare
componentă a sistemului
Universitatea Piteşti
• Testarea de acceptare– prevederea
pentru îmbunătăţiri şi corecţii
• Testare sistem – specifică testele la
nivel de sistem
• Integrare şi testare– se verifică dacă
toate modulele se interconectează
corect
• Testare module – se verifică
funcţiile fiecărui modul în parte
• Codarea – transformarea
algoritmilor în software
10
Avantaje ale modelului V
• Se fac verificări şi validări ale produsului încă din
faze incipiente ale dezvoltare
• Fiecare unitate realizată trebuie testată
• Managerul de proiect poate urmări progresul
proiectului în punctele principale

Universitatea Piteşti 11
Probleme ale modelului V
• Nu este uşor de lucrat cu procese paralele
• Nu se poate lucra la nivel de iteraţii sau
faze!!!!
• Nu este uşor de adus modificări ale
proiectului dacă cerinţele se schimbă
• Nu conţine activităţi de analiză a riscurilor

Universitatea Piteşti 12
Aplicarea modelului V
• Proiecte care trebuie să aibă o fiabilitate
ridicată – aplicații software în domeniul
medical
• Toate cerințele trebuie cunoscute de la început
• Soluţiile de dezvoltare pe tehnologii cunoscute
sau deja utilizate

Universitatea Piteşti 13
Model de proiectare evolutiv
Start

Culege
Proiectare Construire
cerinţe şi
selectare rapidă prototip

Rafinare Evaluare
Produs prototip clienţi

Stop

Universitatea Piteşti 14
Etapele de proiectare ale
modelului evolutiv
• Este realizat un plan preliminar al proiectului
• Este trasat în linii mari un model
• Modelul este sursa pentru realizarea parţială a
specificaţiilor proiectului
• Este construit un prototip pe baza atributelor de
bază
• Proiectantul prezintă prototipul, beneficiarul il
evaluează pentru prevenirea problemelor şi
propunerea de îmbunătăţiri.
• Acest ciclu continuă până când beneficiarul este
mulţumit

Universitatea Piteşti 15
 Avantaje ale modelului evolutiv
 Beneficiarul poate vedea cerinţele sistemului în
modul în care acestea sunt colectate
 Proiectanţii învaţă de la clienţi
 Un produs mult mai uşor de realizat
 Nu apar cerinţe neaşteptate
 Dă o flexibilitate proiectării şi dezvoltării
 Se văd semne vizibile de progres
 Interacţiunea cu prototipul stimulează gradul de
conştientizare a funcţiilor suplimentare ce
trebuie aduse acestuia
Universitatea Piteşti 16
Probleme ale modelului evolutiv
 Tendinţa de abandonare a programării
structurate de către programatori
 Reputaţii slabe pentru folosirea metodelor rapide
de programare şi neconvenţionale
 Intreţinerea sistemului poate fi trecută cu vederea
 Beneficiarul doreşte ca să fie scos ca produs final
prototipul
 Procesul poate continua la infinit

Universitatea Piteşti 17
Aplicarea modelului evolutiv
• Cerinţele sunt încă necunoscute şi urmează să se
clarifice
• Cum ar fi etapa de clarificare a cerinţelor în
modelul de cascadare
• Dezvoltarea interfeţelor cu utilizatorul
• Demonstraţii scurte
• O dezvoltare nouă, originală
• Porţiuni de analiză şi proiectare prin proiectarea
orientată pe obiecte
Universitatea Piteşti 18
Modelul Incremental

Universitatea Piteşti 19
Descrierea modelului Incremental
 Realizarea parţială a întregului sistem
 Completarea pe parcurs a funcţionalităţii
 Modelul incremental pune accent pe
cerinţele de sistem şi apoi implementarea
acestora pe grupuri
 La fiecare versiune ulterioară a sistemului se
adaugă funcţii noi până când acesta este
terminat.

Universitatea Piteşti 20
Caracteristici ale modelului
incremental
 Dezvoltarea prioritară a funcţiilor importante şi de risc înalt
 Fiecare versiune de produs trebuie să fie operaţională
 Utilizatorul poate răspunde pentru fiecare versiune
 Utilizează metoda “divide and conquer” de împărţire a
sarcinilor
 Costul iniţial al primului produs este mic
 Timpul de finalizare a primei versiuni este mic
 Utilizatorii pot să utilizeze repede funcţiile importante ale
sistemului
 Riscul apariţiei de cerinţe noi este mic

Universitatea Piteşti 21
Probleme ale modelului
incremental
 Necesită o bună planificare şi proiectare
 Necesită definirea rapidă a sistemului
complet şi pe deplin funcţional pentru
definirea cerinţelor
 Este necesară definirea cât mai bună a
interfeţelor ( unele vor fi dezvoltate cu
mult mai înainte)
 Costul total al întregului sistem nu este mic

Universitatea Piteşti 22
Aplicarea modelului incremental
 Risc de finanţare, planificare în timp,
complexitate mare sau este necesară realizarea
unei prime versiuni cât mai repede.
 Mare majoritate a cerinţelor este deja cunoscută
dar se aşteptă la apariţia altor noi cerinţe.
 Este necesară obţinerea unui funcţionalităţi de
bază pentru a fi plasat pe piaţă
 Proiecte care prezintă timpi mari de realizare
 Proiectele care au la bază tehnologii noi

Universitatea Piteşti 23
Spiral Model

Universitatea Piteşti 24
Descrierea modelului
 Adaugă analiza de risc
 Fiecare ciclu implică aceeaşi secvenţă
de etape ca la modelul în cascadă

Universitatea Piteşti 25
Cadranul obiective, alternative şi constrângeri
 Obiective: funcţionalitate, performanţă, interfaţă
hardware/software, factori de succes critici
 Alternative: realizare, reutilizare, cumpărare,
sub-contractarebuild,etc.
 Constrângeri: cost, timp realizare, interfeţe, etc.

Universitatea Piteşti 26
 Cadranul evaluare a alternativelor,
identificare şi rezolvare a riscurilor

 Studiul alternativelor relative la obiective şi

constrângeri
 Identificare risc (experienţă, tehnologie nouă,
timp scurt, procese slabe, etc.
 Rezolvare risc (evaluarea cazulului în care ar
putea fi fierduţi bani prin dezvoltarea în
continuare a proiectului

Universitatea Piteşti 27
Cadranul dezvoltarea la nivelul următor al
produsului

 Tipuri de activităţi:
 Creare proiect
 Revizuire proiect
 Dezvoltare cod
 Verificare cod
 Testare produs

Universitatea Piteşti 28
Cadranul Planificarea fazei următoare

 Tipuri de activităţi:
 Dezvolarea unui plan de proiect
 Devoltarea configuraţiei unui plan managerial
 Dezvoltarea unui plan de test
 Dezvoltarea unui plan de instalare

Universitatea Piteşti 29
 Caracteristici ale modelului spirală
 Oferă indicaţii din timp asupra riscurilor foarte mari
fără costuri prea mari
 Utilizatorii au acces la system repede datorită
uneltelor de prototipizare rapidă
 Sunt dezvoltate prima dată funcţiile de risk major
 Nu se urmăreşte ca sistemul să fie perfect
 Utilizatorii pot urmării toate etapele ciclului de
dezvoltare
 Răspunsuri şi reacţii rapide de la utilizatori
 Se pot evalua mereu costurile cumulative
Universitatea Piteşti 30
Probleme ale modelului spirala
 Timp pierdut pentru evaluarea riscurilor prea mari la
proiecte mici cu risc scăzut
 Timp mai mult pierdut pentru planificare, pentru reluarea
obiectivelor, realizând analiza de risc şi prototipizarea
 Modelul este complex
 Este necesară o expertiză pentru riscul de evaluare
 Spirala poate continua la infinit
 Proiectanţii trebuie să realoce timpul în fazele în care nu
se dezvoltă proiectul
 Este greu de definire a obiectivelor pentru a verifica dacă
procesul necesită o iteraţie următoare

Universitatea Piteşti 31
Aplicarea modelului spirala
 Când se creează un prototip
 Când este importantă evaluarea costului şi a
riscului
 Pentru proiecte cu risc mediu
 Când se schimbă priorităţile economice în
proiecte pe termen lung
 Utilizatorii nu sunt siguri pe ceea ce doresc sa
realizeze
 Cerinţele sunt complexe
 O linie noua de producţie
 Se aşteptă la schimbări semnificative (cercetare şi
exploatare)
Universitatea Piteşti 32
Modelul Asamblare pe
componente
Extrage
componentă
yes
Identifică Caută
componente componente sunt? Construieşte
candidate în librării sistem
no

Construieşte
componentă

Universitatea Piteşti 33
Component Assembly
Characteristics
 Utilizează tehnologii orientate pe obiect
 Componente – clase care încapsulează date şi
algoritmi în acelaşi timp
 Componente dezvoltate pentru a fi reutilizate
 Paradigmă similară modelului spiral, dar implică
componente în activitatea inginerească
 Sistemul creat este rezultatul asamblării de
componente

Universitatea Piteşti 34
Modele de proiectare rapide
 Creşterea vitezei sau suspendarea unor faze
de proiect
 În general pentru proiecte cu un scop încă
neclar şi mai puţin formale
 Utilizată pentru aplicaţii cu timp de
realizare foarte critic
 Utilizate în organizaţii unde sunt folosite
metode cu o disciplină foarte riguroasă

Universitatea Piteşti 35
Modele rapide de proiectare
 Dezvoltare de Software adaptiva
Adaptive Software Development (ASD)
 Proiectare ghidată după specificaţii
Feature Driven Development (FDD)
 Crystal Clear
 Dezvoltarea Software dinamica
Dynamic Software Development Method (DSDM)
 Dezvoltarea prin aplicare rapidă
Rapid Application Development (RAD)
 Scrum
 Programare Extremă
Extreme Programming (XP)
 Rational Unify Process (RUP)
Universitatea Piteşti 36
Rapid Application Development
(RAD) Team #2
Team #1 Business
Modeling
Business Data
Modeling
Modeling Process
Data Modeling
Application
Modeling Generation
Process Testing &
Modeling Turnover
Application
Generation
Testing &
Time period Turnover

Universitatea Piteşti 37
 Caracteristici ale modelului
RAD
 Versiune rapidă a modelului Waterfall
 Funcţiile sunt realizate de echipe separate după care sunt
integrate ca un întreg.
 Necesită resurse umane şi concomitent
 Clientul este implicat pe tot parcursul ciclului de proiectare,
minimizează riscul de a nu mulţumii clienţi
 Orientarea se face pe realizarea codului şi nu a
documentaţiei(WYSIWYG).
 Utilizează concepte de preluare a informaţiilor privitoare la
date, procese şi costuri

Universitatea Piteşti 38
Probleme ale
modelului RAD
 Accelerarea procesului de dezvoltare trebuie să
dea răspunsuri rapide utilizatorului
 Riscul de a nu realiza nici odată închiderea
proiectului
 Greu de utilizat în sisteme moştenite (preluate)
 Necesită un sistem care poate fi modularizat
 Dezvoltatorii şi clienţii trebuie să se rezume la un
interval de timp

Universitatea Piteşti 39
Aplicarea modelului RAD
 Când se cunosc cerinţele destul de bine
 Utilizatorul este implicat pe tot parcursul
proiectării
 Proiectul poate fi încadrat într-o fereastră de timp
 Preluarea de utilizator a proiectului la fiecare pas
nou de dezvoltare
 Nu este necesară o performanţă ridicată
 Risc tehnic scăzut
 Sistemul poate fi modularizat

Universitatea Piteşti 40
 Programare extrema- XP
• Pentru echipe dezvoltare software de
mărime mică şi medie iar cerinţele se pot
schimba repede şi sunt neclare
• Programarea este elementul principal în
proiectul software
 Comunicarea între echipe constă în
codurile de program
 Ciclul de viaţă şi comportamentul
obiectelor complexe consta în procese de
testare şi iarăşi programare.
Universitatea Piteşti 41
 Etape ale modelului XP
1. Planificarea – prin analiza estimărilor tehnice şi priorităţile de
afaceri se determină scopul următoarei lansări
2. Mici lansari de programe– sunt plasate sisteme simple în
producţie, apoi sunt lansate versiuni noi în intervale scurte de
timp
3. Arhitectura – intreaga dezvoltarea este ghidată după simple
descrieri referitoare la modul de funcţionare al sistemului
4. Proiectare simplă – sistemul este proiectat cât mai simplu cu
putinţă (sunt eliminate elementele de complexitate marită)
5. Testare – programatorii realizează continuu unitaţi de testare
în timp ce clienţii realizează scenarii de testare pentru
funcţionalitatea sitemului
6. Redezvoltare – programatorii restructurează continuu sitemul
făra schimbarea comportamenului acestuia. Elimină doar
suprapunerile şi îl simplifica.
Universitatea Piteşti 42
Etape ale modelului XP
7. Programare pereche -- întreaga realizare a programului
este scris cu doi programatori la o maşină
8. Proprietate colectivă – oricine poate schimba orice cod
oriunde din sistem în orice moment.
9. Integrare continuă – integrează şi construieşte sistemul
de mai multe ori pe zi – de fiecare dată când o sarcină
este terminată.
10. 40 ore pe săptamână – de regulă, timpul de lucru nu
este mai mare de 40 de ore pe sâptămână
11. La dispoziţia clientului – un membru al echipei este
disponibil tot timpul pentru a răspunde la intrebările
clientului
12. Standarde de codare – programatorii scriu întregul cod
în conformitate cu regulile impuse in domeniul
Universitatea Piteşti 43
 Caracteristici ale modelului XP
Practicile normale de lucru sunt preluate la nivele
extreme
 În cazul în care codul este considerat bun, acesta se revizuieşte tot timpul
(programarea pereche)
 Dacă testarea este bună, toata lumea va testa tot timpul
 În cazul în care simplificarea este posibilă, menţine sistemul la modul cel mai
simplu posibil fără a-i afecta funcţionarea. (cel mai simplu mod la care
funcţionează)
 În cazul în care proiectul este bun, toată lumea va proiecta pe acesta
(redezvoltare)
 Dacă arhitectura este importantă, toata lumea va lucra la definirea şi
redefinirea arhitecturii (arhitectura)
 Dacă integrarea şi testarea este importantă, construieşte şi testează de mai
multe ori pe zi(integrare continua)
 Dacă iteraţiile scurte sunt bune, realizează iteraţii cât mai scurte (ore mai
degrabă decât săptămâni)
Universitatea Piteşti 44
Tehnici de generaţia a 4-a (4GT)
Requirements
gathering

"Design"
Strategy

Implementation
using 4GL

Testing

Universitatea Piteşti 45
4GT Characteristics
 Utilizează unelte software care permit inginerilor
software sa specifice caracteristicile s/h la cel mai înalt
nivel
 Sunt generate coduri bazate pe specificaţii
 Mai mult timp câştigat în proiectare şi testare – creşte
productivitatea
 Unelte software utilizate nu uşor de utilizat şi s-ar
putea sa nu genereze coduri eficiente

Universitatea Piteşti 46
Modelul (FDD) Feature Driven
Design
Cinci procese de activităţi de tipul FDD
1. Dezvoltarea unui model global – Elaborarea de clase şi secvenţe de
diagrame pentru întâlnirile între arhitectul principal şi experiţii în
domeniul, repectiv dezvoltatori.
2. Realizează o listă de funcţii – Identificarea tuturor specificaţiior şi
cerinţelor necesare. Cerinţele sunt descompuse în activităţi de
afaceri.
Cerinţele sunt funcţii care pot fi dezvoltate în aproximativ 2
saptamani şi sunt exprimate în termenii clinetului după un
sablonŞ <actiune><rezultat><obiect>
i.e. Se calculează totalul vânzărilor
3. Plan după specificaţii -- echipa de dezvoltare planifică dezvoltarea
secvenţelor de specificaţii
4. Proiectarea după specificaţii -- echipa realizează sevenţe de
organigrame pentru specificaţiile selectate
5. Punerea în practică specificaţiilor – echipa scrie şi testează

Universitatea Piteşti 47
Metoda de dezvoltare dinamică a sistemelor
(DSDM)

Se aplică pentru arhitecturi RAD sau

arhitecturi de durată mică
Etape de proiectare
Studiul de fezabilitate
Studiul de afaceri – cerinţele au prioritate
Model funcţional iterativ
Analiza riscurilor
Plan de timp
Proiectarea şi realizarea iteraţiilor
Implementarea
Universitatea Piteşti 48
 Caracteristicile modelului DSDM
1. Este necesară implicarea utilizatorului(Ambassador users)
2. Echipa DSDM este autorizată să ia decizii
3. Concentrare pe timpul de predare
4. Acceptarea produsului este strâns legată de planul de
afaceri
5. Dezvoltare iterativă sau incrementală – pentru a converge
către o soluţie
6. Iniţial, necesită acceptare la nivel înalt
7. Toate schimbările realizate în timpul procesului de
dezvoltare sunt reversibile
8. Testarea este integrată pe tot parcursul ciclului de viaţă
9. Este necesară o abordare de cooperare şi colaborare între
toţi participaţii la dezvoltarea proiectului

Universitatea Piteşti 49
 Other Process Models
 Component assembly model—the process to
apply when reuse is a development objective
 Concurrent process model—recognizes that
different part of the project will be at different
places in the process
 Formal methods—the process to apply when a
mathematical specification is to be developed
 Cleanroom software engineering—emphasizes
error detection before testing

Universitatea Piteşti 50
Conclusion
 Paradigmele utilizate pentru dezvoltarea software-lui
depind de mai mulţi factori
 Resursa umană - personal & utilizatori
 Produsul software
 Unelte software disponibile
 Mediul de lucru
 Existenţa modelelor face procesul de dezvoltare mai
clar, dar pot evolua şi devenii noi paradigme.

Universitatea Piteşti 51
References
 “Software Engineering: A Practitioner’s Approach” 5th
Ed. by Roger S. Pressman, Mc-Graw-Hill, 2001
 “Software Engineering” by Ian Sommerville, Addison-
Wesley, 2001

Universitatea Piteşti 52