Ciclul dezvoltare pp

2. Ciclul de dezvoltare al produsului software
Software Development Life Cycle - SDLC
 Modelul cascadă (waterfall)
 Modelul V
 Modelul incremental
 Modelul RAD (Rapid Application Development)
 Modelul agil
 Modelul iterativ
 Modelul spirală
 Agil vs. Tradițional

3. SDLC – definiții
 Procese sau metodologii diverse, selectate pentru
dezvoltarea unui proiect în funcție de obiectivele
acestuia;
 Mediu care descrie activitățile realizate în cadrul
fiecărei etape a procesului de dezvoltare software
 Plan detaliat, care descrie modul în care se va realiza
dezvoltarea, întreţinerea şi înlocuirea software-ului
specific (proces de dezvoltare software)
 Standardul internațional SDLC – ISO/IEC 12207

4. SDLC - etape

5. SDLC
Analiză și
planificare
Definirea
cerințelor
Proiectarea
arhitecturii
Implementare,
dezvoltare
Testare produs
Operare și
întreținere

6. Analiza și planificarea cerințelor
 este etapa fundamentală, cea mai importantă din
SDLC
 este efectuată de către membrii seniori ai echipei pe
baza intrărilor de la client, de la departamentul de
vânzări, pe baza studiilor de piața şi experţilor din
domeniul proiectului
 Implică planificarea cerinţelor de asigurare a calităţii şi
identificare a riscurilor asociate proiectului
 rezultatul studiului de fezabilitate tehnică constă în
definirea diverselor abordări tehnice care pot fi urmate
pentru a implementa proiectul cu riscuri minime

7. Definirea cerinţelor
 presupune definirea clară şi documentarea cerinţelor
produsului
 obţinerea aprobării clientului sau a analiştilor de piaţă
prin intermediul SRS (Software Requirement
Specification)
 SRS cuprinde toate cerinţele produsului care vor fi
proiectate şi dezvoltate

8. Proiectarea arhitecturii produsului
 SRS este referinţa de bază
 este propusă o abordare de proiectare a arhitecturii
produsului, documentată într-un DDS (Design
Document Specification)
 defineşte în mod clar toate modulele arhitecturale ale
produsului
 proiectarea internă a tuturor modulelor din arhitectura
propusă trebuie să fie clar definită şi detaliată în DDS

9. Implementarea și dezvoltarea
 începe efectiv dezvoltarea şi se realizează produsul
 se generează codul sursă de programare
 se folosesc instrumente de programare: compilatoare,
interpretoare, depanatoare etc.
 limbaje de programare de nivel înalt, cum ar fi C, C++,
Pascal, Java, PHP

10. Testarea produsului
 este, de obicei, un subset al tuturor etapelor din
modelele SDLC moderne
 se referă doar la etapa de testare în situaţia în care sunt
raportate, urmărite, fixate şi reanalizate defecte ale
produsului până când produsul ajunge la standardele
de calitate definite în SRS

11. Operare și întreținere
 poate fi lansat într-un segment limitat şi testat în
mediul de afaceri real
 pe baza feedback-ului, produsul poate fi lansat
nemodificat sau cu îmbunătăţirile sugerate
 întreţinerea acestuia se face pentru baza de clienţi
existentă

12. Modele SDLC
 Descriere
 Etape
 Avantaje
 Dezavantaje
 Recomandări de utilizare

13. Modelul cascadă (waterfall)
 Definit de W. W. Royce în 1970
 Modelul ciclului de viață liniar-secvențial
 Etapele nu se suprapun
 La sfârșitul fiecărei etape are loc o revizuire

14. Modelul cascadă (waterfall)

15. Modelul cascadă (waterfall)
Culegerea și analiza cerințelor
Proiectarea sistemului
Implementarea
Testarea
Operarea sistemului și întreținerea

16. Modelul cascadă - avantaje
 documentaţia şi proiectarea structurii reprezintă un
avantaj atunci când apar noi membri în echipă;
 este un model uşor de utilizat şi simplu;
 este uşor de coordonat, datorită rigidităţii modelului -
fiecare etapă are un rezultat așteptat şi un proces de
evaluare;
 etapele sunt implementate individual, pe rând;
 este recomandat pentru proiectele mici, în care
cerinţele sunt foarte bine înţelese.

17. Modelul cascadă – dezavantaje (1)
 cerinţele pot fi adăugate şi după finalul etapei de “culegere
a cerinţelor”, fapt ce influențează în mod negativ
dezvoltarea produsului;
 problemele din cadrul unei etape nu sunt niciodată
rezolvate complet în cadrul aceleiaşi etape;
 partiționarea în etape a proiectului nu este flexibilă;
 adăugarea de cerinţe noi de către client, conduce la costuri
suplimentare, deoarece acestea nu pot fi implementate în
aceeași ediţie a produsului;
 estimarea corectă a timpului și costului alocat pentru
fiecare etapă sunt dificil de realizat;
 nu sunt realizate prototipuri până la finalizarea ciclului de
viaţă;

18. Modelul cascadă – dezavantaje (2)
 odată ce aplicaţia este în etapa de testare, este foarte
dificil să se revină la etapa de concepţie în cazul în care
există probleme;
 există un risc şi o incertitudine mari;
 nu este recomandat pentru proiectele complexe şi
orientate obiect;
 este considerat un model slab pentru proiectele lungi
şi în curs de desfăşurare;
 nu este potrivit pentru proiectele în care cerinţele
prezintă un grad de schimbare de la moderat spre
ridicat.

19. Modelul cascadă – se recomandă când:
 cerinţele sunt foarte bine cunoscute, clare şi fixe;
 definirea produsului este stabilă;
 tehnologia este înţeleasă;
 nu există cerinţe ambigue;
 resursele care necesită expertiză sunt disponibile
gratis;
 proiectul este scurt.

20. Modelul V (Verificare și Validare)
 Este o extensie a modelului cascadă;
 Este criticat de adepții Agile (“este prea simplu pentru
a reflecta cu exactitate procesul de dezvoltare software
și poate duce managerii într-un fals sentiment de
securitate”);
 Ciclul de viaţă este o cale secvenţială de executare a
proceselor;
 Testarea produsului este planificată în paralel cu faza
de dezvoltare corespunzătoare.

21. Modelul V - diagrama

22. Modelul V - diagrama

23. Modelul V - diagrama

24. Modelul V - diagrama

25. Modelul V - avantaje
 simplu şi uşor de utilizat;
 testarea activităţii (cum ar fi planificarea) - proiectarea
testării se realizează înainte de codificare, salvând timp şi
crescând rata de succes faţă de modelul cascadă;
 are loc o urmărire proactivă a defectelor - defectele sunt
găsite în stadiu incipient;
 evită fluxul descendent de defecte;
 funcţionează bine pentru proiecte mici, în cazul în care
cerinţele sunt uşor de înţeles;
 este uşor de coordonat, datorită rigidităţii modelului -
fiecare etapă are un rezultat așteptat şi un proces de
evaluare.

26. Modelul V - dezavantaje
 este rigid şi puţin flexibil;
 software-ul este dezvoltat în etapa de implementare, prin urmare
nu sunt realizate prototipuri ale software-ului;
 dacă apar modificări pe parcurs, atunci documentele de testare,
împreună cu documentele de cerinţe trebuie să fie actualizate;
 există risc ridicat şi incertitudine;
 nu este un model bun pentru proiecte complexe şi orientate-
obiect;
 este un model slab pentru proiecte lungi şi în curs de
desfăşurare;
 nu este potrivit pentru proiecte în care cerinţele prezintă risc de
schimbare moderat până la ridicat;
 odată ce aplicaţia este în faza de testare, întoarcerea şi
schimbarea funcţionalităţii sunt dificile.

27. Modelul V – se recomandă în următoarele cazuri:
 pentru proiecte de dimensiuni mici până la medii şi în
care cerinţele sunt clar definite şi fixe;
 atunci când resursele tehnice ample sunt disponibile
împreună cu expertiza tehnică necesară.

28. Modelul incremental
 Cerinţele sunt împărţite în subseturi de cerinţe
 Presupune cicluri multiple de dezvoltare => ciclul de
viață multi-cascadă
 Fiecare modul trece prin etapele de: cerinţe,
proiectare, implementare şi testare
 Primul modul se finalizează cu prima versiune
 Urmatoarele versiuni adaugă funcționalități

29. Modelul incremental

30. Modelul incremental
Proiectare
&
Dezvoltare
Testare Implementare
Proiectare
&
Dezvoltare
Testare Implementare
Proiectare
&
Dezvoltare
Testare Implementare
Versiunea 1
Versiunea 2
Versiunea N

31. Modelul incremental - avantaje
 în fiecare etapă este livrat un produs executabil, care satisface o
parte din cerinţele utilizatorului;
 prototipurile sunt livrate utilizatorului;
 feedback-ul utilizatorilor este distribuit pe întreg parcursul
dezvoltării;
 este mai flexibil – implică costuri mai mici la schimbarea
scopului şi cerinţelor;
 este uşor de testat şi depanat în timpul unei iteraţii mai mici;
 reduce costurile iniţiale de livrare;
 riscul este mai uşor de gestionat, deoarece piesele riscante sunt
identificate şi tratate în timpul iteraţiei;
 în cazul apariţiei unor schimbări în cerinţe, acestea pot fi
încorporate în următorul prototip.

32. Modelul incremental - dezavantaje
 necesită o bună planificare şi proiectare;
 necesită o definire clară şi completă a întregului sistem
înainte ca acesta să fie divizat şi construit incremental;
 costul total este mai mare decât la modelul cascadă;
 erorile de proiectare sunt mai greu de eliminat;
 abordarea incrementală se poate transforma uşor într-una
„codifică şi repară”;
 clientul vede ce se poate face şi poate cere mai mult;
 abordarea obiect furnizează un cadru confortabil pentru
dezvoltarea prin evoluţie, într-o manieră iterativă.

33. Modelul incremental – se recomandă când:
 cerinţele întregului sistem sunt clar definite şi înţelese;
 cerinţele majore sunt definite; cu toate acestea, unele
detalii pot evolua în timp;
 este necesară o lansare mai devreme a produsului pe
piaţă;
 se utilizează o noua tehnologie;
 există unele caracteristici şi obiective cu risc ridicat.

34. Modelul RAD
 RAD – Rapid Application Development
 Este un tip de model incremental
 Componentele sau funcţiile sunt dezvoltate în paralel
 Dezvoltările sunt depozitate, livrate şi apoi asamblate
într-un prototip de lucru
 Clientul vede şi utilizează prototipul şi oferă feedback

35. Modelul RAD - diagrama

36. Modelul RAD - avantaje
 timp de dezvoltare redus;
 creşte reutilizarea componentelor;
 apar evaluări iniţiale rapide;
 încurajează feedback-ul clientului;
 integrarea timpurie rezolvă multe probleme de integrare;
 progresul poate fi măsurat;
 timpul de iterare poate fi scurtat, cu utilizarea de
instrumente RAD puternice;
 se poate obţine productivitate cu mai puţini oameni şi în
timp scurt.

37. Modelul RAD - dezavantaje
 depinde de o echipă puternică şi de performanţele
individuale necesare pentru identificarea cerinţelor de
afacere;
 numai sistemele care pot fi modularizate pot fi construite
folosind RAD;
 necesită dezvoltatori/proiectanţi de înaltă calificare;
 există o dependenţă mare de abilităţile de modelare;
 este inaplicabil proiectelor mai ieftine, deoarece costul de
modelare şi generare automată de cod sunt foarte mari;
 necesită implicarea utilizatorului în cadrul ciclului de viaţă.

38. Modelul RAD – se recomandă
când:
 este necesară crearea unui sistem modularizat în 2-3
luni;
 există o disponibilitate mare de proiectanţi pentru
modelare şi bugetul este suficient de mare pentru a
permite costul lor, împreună cu costul instrumentelor
de generare automată a codului;
 resursele cu un nivel ridicat de cunoştinţe de afaceri
sunt disponibile şi sistemul trebuie realizat într-un
interval scurt de timp (2-3 luni).

39. Modelul agil
 este un tip de model incremental
 software-ul este dezvoltat în cicluri rapide,
incrementale
 fiecare versiune este testată pentru a asigura calitatea
software-ului
 este utilizat pentru aplicaţiile care trebuie dezvoltate
într-un timp critic
 Extreme Programming (XP) este în prezent una dintre
cele mai bine cunoscute metode de dezvoltare agilă

40. Modelul agil - diagrama

41. Modelul agil - diagrama

42. Modelul agil – avantaje (1)
 obţinerea satisfacţiei clienţilor prin livrarea rapidă şi continuă a
software-ului;
 oamenii şi interacţiunile sunt mai accentuate în cadrul
modelului decât procesele şi instrumentele - clienţii,
dezvoltatorii şi testării interacționează constant;
 versiuni de lucru sunt livrate frecvent (mai degrabă săptămâni
decât luni);
 conversaţia faţă-în-faţă este cea mai bună formă de comunicare;
 cooperare strânsă, de zi cu zi între oamenii de afaceri şi
dezvoltatorii produsului;
 atenţie continuă către excelenţă tehnică şi proiectare bună;
 adaptare regulată la circumstanţele de schimbare;
 chiar şi schimbările târzii în cerinţe sunt binevenite;

43. Modelul agil – avantaje (2)
 este o abordare realistă pentru dezvoltarea de software;
 promovează munca în echipă;
 poate fi dezvoltat rapid;
 necesarul de resurse este minim;
 oferă versiuni de lucru parţiale anticipate;
 este un model bun pentru mediile care se schimbă în mod
constant;
 există reguli minime;
 permite o dezvoltare simultană şi livrare într-un context
general planificat;
 este uşor de gestionat;
 oferă flexibilitate pentru dezvoltatori.

44. Modelul agil - dezavantaje
 în cazul unor livrabile software, în special mari, evaluarea efortului
necesar pe întreg parcursul ciclului de dezvoltare software este dificilă
de realizat;
 nu se pune accent prea mare pe proiectare şi pe documentaţia necesară;
 necesită dezvoltatori cu experienţă;
 nu este potrivit pentru manipularea dependenţelor complexe;
 există risc mai mare la durabilitate, mentenabilitate şi extensibilitate;
 depinde foarte mult de interacţiunea cu clienţii, astfel încât, în cazul în
care clientul nu este clar, echipa poate fi condusă într-o direcţia greşită;
 există dependenţă individuală foarte mare, deoarece există
documentaţie minimă generată;
 transferul de tehnologie către noi membri ai echipei poate fi destul de
dificil din cauza lipsei de documentaţie.

45. Modelul iterativ
 nu începe cu o specificare completă a cerinţelor
 dezvoltarea începe prin specificarea şi implementarea
doar a unei parţi a software-ului
 procesul se repetă, producând o nouă versiune a
software-ului pentru fiecare ciclu al modelului

46. Modelul iterativ - diagrama

47. Modelul iterativ - diagrama

48. Modelul iterativ - avantaje
 dezvoltarea şi îmbunătăţirea produsului pas cu pas
permite urmărirea defectelor în stadii incipiente şi
evită fluxul descendent al acestora;
 permite obţinerea feedback-ului utilizatorilor;
 este necesar un timp mai mic pentru documentare şi
este acordat un timp mai mare proiectării.

49. Modelul iterativ - dezavantaje
 fiecare fază a iteraţiei este rigidă, fără suprapuneri;
 poate genera o arhitectură a sistemului sau de
proiectare costisitoare, deoarece nu toate cerinţele
sunt culese pentru întregul ciclu de viaţă.

50. Modelul iterativ – se recomandă
când:
 cerinţele întregului sistem sunt clar definite şi înţelese;
 proiectul este mare;
 cerinţele majore sunt definite; oricum unele detalii pot
evolua în timp.

51. Modelul spirală
 este asemănător cu modelul incremental, dar cu mai mult
accent pus pe analiza riscului
 are patru faze: planificare, analiza riscului, inginerie şi
evaluare
 spirala de bază, începe în faza de planificare, cerinţele sunt
colectate şi riscul este evaluat
 la sfârşitul fazei de analiza de risc este realizat un prototip
 software-ul este produs în faza de inginerie
 etapa de evaluare permite clientului să evalueze rezultatul
proiectului înaintea spiralei următoare

52. Modelul spirală - diagrama

53. Modelul spirală - avantaje
 propune o atitudine pro-activă asupra riscurilor, cu o
presupunere explicită a riscurilor şi a rezolvării lor;
 este foarte flexibil;
 se realizează multe analize de risc, prin urmare este
îmbunătăţită evitarea riscului;
 este bun pentru proiecte mari şi cu misiuni critice;
 se realizează un control asupra documentaţiei;
 pot fi adăugate ulterior funcţionalităţi suplimentare;
 software-ul este produs devreme în ciclul de viaţă
software.

54. Modelul spirală - dezavantaje
 sunt aproape imposibil de estimat de la început timpul
şi costurile necesare;
 poate fi un model costisitor;
 analiza de risc necesită expertiză ştiinţifică superioară;
 succesul proiectului depinde foarte mult de faza de
analiză de risc;
 nu funcţionează bine pentru proiecte mai mici.

55. Modelul spirală – se recomandă
când:
 evaluarea riscurilor şi costurilor este importantă;
 proiectele sunt cu risc mediu spre ridicat;
 utilizatorii nu sunt siguri de necesităţile lor;
 cerinţele sunt complexe;
 sunt realizate linii de produse noi;
 se aşteaptă schimbări semnificative (cercetare şi
explorare).

56. Agil vs. Tradițional (1)
 Modele agile –> metode de dezvoltare software
adaptive
 Modele tradiționale -> abordare predictivă
 Metodelor predictive depind în totalitate de analiza
cerinţelor şi de planificarea realizată la începutul
ciclului
 Modelul agil utilizează abordarea adaptivă - nu există
o planificare detaliată, dar există claritate cu privire la
sarcinile viitoare în ceea ce priveşte caracteristicile care
trebuie să fie dezvoltate

57. Agil vs. Tradițional (2)
 Echipa se adaptează la schimbările dinamice ale
cerinţelor produsului
 Produsul este testat foarte frecvent, minimizând riscul
unor defecţiuni majore în viitor
 Interacţiunea cu clienţii este punctul forte al
metodologiei agile
 Comunicarea deschisă şi documentaţia minimă sunt
caracteristicile tipice ale mediului de dezvoltare agilă
 Echipele lucrează în strânsă colaborare şi sunt de cele
mai multe ori localizate în acelaşi spaţiu geografic

58. Agil vs. Tradițional (3)
 SDLC agil este mult mai potrivit pentru dezvoltarea de
proiecte mici-mijlocii
 la proiecte la scară largă este încă mai bine să se adopte
SDLC tradiţional
 criterii pe care echipa de dezvoltare le-ar putea folosi
pentru a identifica SDLC-ul dorit:
 mărimea echipei;
 poziţia geografică;
 dimensiunea şi complexitatea software-ului;
 tipul de proiect;
 strategia de afacere;
 capacitatea de proiectare etc.

59. Agil vs. Tradițional (4)

60. Temă seminar:
1. Daţi un exemplu de proiect specific societății
informaționale (în echipă de maxim 5 persoane),
identificaţi modelul SDLC care se pretează cel mai
bine la proiectul dat şi justificaţi alegerea făcută – 0,5
puncte