Procesele software

1. Procesele software

2. Obiective • Modele pentru proceselesoftware • Trei modele generice de procese şi când pot fi utilizate • Schiţarea modelelor proceselor pentru ingineria cerinţelor, dezvoltarea software-lui, testare şi evoluţie • Explicarea modelului RUP (Rational Unified Process) • Tehnologia CASE în sprijinirea activităţilor procesului software

3. Subiecte acoperite • Modele pentru procesul software • Iterarea procesului • Activităţile procesului • RUP (Rational Unified Process) • CASE (Computer-aided software engineering)

4. Procesul software Def. Proces software = set structurat de activităţi necesare pentru dezvoltarea unui sistem software • specificare; • proiectare; • validare; • evoluţie. Def. Model pentru proces software = reprezentare abstractă a unui proces. Prezintă o descriere a unui proces dintr-o perspectivă particulară.

5. Modele generice pentru procesul software • Modelul cascadă (waterfall) • Etape separate şi disticte de specificare şi de dezvoltare. • Dezvoltare evolutivă • Specificarea, dezvoltarea şi validareasunt intercalate. • CBSE (Component-based software engineering) • Sistemul este asamblat din componente existente. Există variante multiple ale acestor modele. De exemplu, dezvoltarea formală unde se utilizează un proces de tip cascadă dar specificarea este o specificare formală care este rafinată de-a lungul mai multor stadii pentru a deveni un proiect implementabil.

6. Modelul cascadă

7. Etapele modelului cascadă • Analiza şi definirea cerinţelor • Proiectarea sistemului şi a software-lui • Implementarea şi testarea unităţilor • Integrarea şi testarea sistemului • Operarea şi întreţinerea Principalul dezavantaj al modelului cascadă constă în dificultatea adaptării modificărilor după ce procesul demarat. Înainte de a se trece la o nouă etapă este necesară încheierea celei precedente.

8. Problematica modelului cascadă • Partiţionarea inflexibilăa proiectuluiîn stadii distincte face dificil răspunsul la modificarea cerinţelor clientului. • Modelul este potrivit doar în cazurile în care cerinţele sunt bine înţelese şi modificările vor fi în limite acceptabile în timpul procesului de dezvoltare. • Puţine sisteme business au cerinţe stabile. • Modelul cascadă este folosit în special pentru proiecte de ingineria sistemelor mari, unde un sistem este dezvoltat pe mai multe sit-uri.

9. Dezvoltare evolutivă • Dezvoltare exploratorie • Obiectivul este acela de a lucra cu clienţii şi de a dezvolta un sistem final dintr-o specificare schiţată iniţial. Trebuie să se înceapă cu cerinţe bine înţelese şi să se adauge caracteristici noi pe baza propunerilor clientului. • Prototipare (Throw-away prototyping) • Obiectivuleste acela de a înţelege cerinţele sistemului. Trebuie să se înceapă cu cerinţele puţin înţelese şi să se clarifice ceea ce este necesar cu adevărat.

10. Dezvoltare evolutivă

11. Dezvoltare evolutivă • Probleme • Lipsa vizibilităţii procesului; • Sistemele sunt deseori slab structurate; • Pot fi necesare calificări speciale (e.g. în limbaje pentru prototipare rapidă). • Aplicabilitate • Pentru sisteme interactive de dimesiuni mici sau mijlocii; • Pentru părţi din sisteme mari (e.g. interfaţa utilizator); • Pentru sisteme cu durate mici de viaţă.

12. CBSE (Component-based software engineering) • Bazată pe reutilizare sistematică, unde sistemele sunt integrate din componente existente sau sisteme COTS (Commercial-off-the-shelf). • Etapele procesului • Analiză componente; • Modificare cerinţe; • Proiectare sistem cu reutilizare; • Deyvoltare şi integrare. • Această abordare este din ce în ce mai mult utilizată odată cu apariţia standardelor de componente.

13. Dezvoltare orientată pe reutilzare

14. Iterare proces • Cerinţele sistemului se dezvoltă ÎNTOTDEAUNA în cursul unui proiect astfel încât reiterarea, în care primele etape sunt reluate, este întotdeauna parte a procesului pentru sisteme mari. • Iterarea se poate aplica oricărui model generic de proces software. • Două abordări (corelate) • Furnizare incrementală; • Dezvoltare în spirală.

15. Furnizare incrementală • În loc de a livra sistemul deodată, dezvoltarea şi livrarea sunt divizate în incremente cu fiecare increment livrând o parte a funcţionalităţii cerute. • Cerinţele utilizatorului sunt prioritizate şi cerinţele cu cele mai mari priorităţi sunt incluse în primele incremente. • Odată ce a fost pornită dezvoltarea unui increment, cerinţele sunt îngheţate deşi cerinţele pentru următoarele incremente pot continua să evolueze.

16. Dezvoltare incrementală

17. Avantajele dezvoltării incrementale • Se poate furniza valoare la client cu fiecare increment, astfel încât funcţionalitatea sistemului este disponibilă mai devreme. • Primele incremente acţionează ca un prototip care ajută la obţinerea cerinţelor pentru incrementele următoare. • Risc mai scăzut de eşuare a întregului proiect. • Serviciile sistemului cu priorităţi mari tind să fie testate mai mult.

18. Programare extremă • Abordare a dezvoltării bazată pe dezvoltarea şi furnizarea de incremente de funcţionalitate foarte mici. • Se bazează pe: • îmbunătăţirea constantă a codului, • implicarea utilizatorului în echipa de dezvoltare, • programare în mod pereche (pairwise).

19. Dezvoltare în spirală • Procesul este reprezentat sub formă de spirală (în loc de secvenţă de activităţi cu reluare). • Fiecare buclă din spirală reprezintă o etapă în proces. • Nu există faze fixe ca specificaresauproiectare – buclele din spirală sunt alese funcţie de ceea ce este necesar. • Risurile sunt evaluate explicit şi rezolvate de-a lungul procesului.

20. Modelul spirală al procesului software

21. Sectoarele modelului spirală • Stabilire obiective • Sunt identificate obiectivele specifice etapei. • Evaluare şi reducere risc • Riscurilesunt evaluate şi se realizează activităţi pentru reducerea riscurilor cheie. • Dezvoltareşi validare • Se alege un model de dezvoltare pentru sistem, care poate fi oricare din modelele generice. • Planificare • Proiectul este revăzut şi se planifică următoarea etapă a spiralei.

22. Activităţile procesului • Specificarea software-lui • Proiectarea şi implementarea software-lui • Validarea software-lui • Evoluţia software-lui

23. Specificarea software-lui Def. Procesul de stabilire a serviciilor cerute şi a constrângerilor asupra operării şi dezvoltării sistemului. • Procesul pentru ingineria cerinţelor • Studiu de fezabilitate; • Obţinere şi analiză cerinţe; • Specificare cerinţe; • Validare cerinţe.

24. Procesul pentru ingineria cerinţelor

25. Proiectarea şi implementarea software-lui Def. Procesul de convertire a specificaţiilor sistemului într-un sistem executabil. • Proiectare software • Proiectarea unei structuri software care realizează specificaţiile; • Implementatare • Translatareaacestei structuriîntr-un program executabil; • Activităţile de proiectare şi implementare sunt strâns corelate şi pot fi intercalate.

26. Activităţile procesului de proiectare a software-lui • Proiectare arhitecturală • Specificare abstractă • Proiectare interfaţă • Proiectare componente • Proiectare structură de date • Proiectare algoritm

27. Procesul de proiectare a software-lui

28. Metode structurate Def. Abordări sistematiceale proiectării software-lui. • Proiectul este documentat (în mod uzual) sub formă de set de modele grafice. • Modele posibile • Model obiecte; • Model secvenţe; • Model tranziţii de stare; • Model structural; • Model al fluxului de date.

29. Programare şi depanare Def. Traducerea proiectului într-un program şi eliminarea erorilor din acel program. • Programarea este o activitate personală – nu există un proces generic pentru această activitate. • Programatoriirealizează o testare iniţială a programului în cursul operaţiei de depanare (debugging) pentru a descoperi şi corecta erori ale programului.

30. Procesul de depanare

31. Validarea software-lui • Verificarea şi validarea (V & V) are scopul de a arăta că sistemul se conformează specificaţiilor sale şi îndeplineşte cerinţele clientului sistemului. • Implică procese de verificare/control şi revizuire şi testarea sistemului. • Testarea sistemului implică executarea sistemului cu cazuri de testare care sunt derivate din specificarea de date reale ce trebuie procesate de sistem.

32. Procesul de testare

33. Stadiile testării • Testare componente sau unităţi • Componentele individuale sunt testate independent; • Componentelepot fi funcţii sau obiectesau grupuri coerente de astfel de entităţi. • Testare sistem • Testarea sistemului în ansamblu. Testarea proprietăţilor emergente are o importanţă specială. • Teste de acceptare • Testare cu datele clientului pentru a verifica dacă sistemul îndeplineşte cerinţele acestuia.

34. Etapele testării

35. Evoluţia software-lui • Software-ul este în mod inerent flexibil şi se poate modifica. • Pe măsură ce cerinţele se modifică odată cu modificarea circumstanţelor business, software-ul suport pentru business trebuie, de asemenea, să evolueze şi să se schimbe. • Deşi s-a făcut demarcarea între dezvoltare şi evoluţie (întreţinere), aceasta devine din ce în ce mai nerelevantă pe măsură ce din ce în ce mai puţine sisteme sunt complet noi.

36. Evoluţia sistemului

37. RUP(Rational Unified Process) • Model modern pentru procesul software derivat din UML şi procesele asociate elaborării acestuia. • Descris din 3 perspective • Perspectivă dinamică– arată repartizarea etapelor în timp; • Perspectivă statică– arată activităţile procesului; • Perspectivă practică - sugerează practici bune.

38. Modelul etapelor RUP

39. Etapele RUP • Concepţie • Stabilirea cazului business pentru sistem. • Elaborare • Dezvoltarea unei înţelegeri a domeniului problemei şi a athitecturii sistemului. • Construire • Proiectarea sistemului, programareaşi testarea. • Tranziţie • Repartizarea (deploy) sistemului în contextul său de operare.

40. Practici bune RUP • Dezvoltare iterativă a software-lui • Managementul cerinţelor • Utilizare de arhitecturi bazate pe componente • Modelare vizuală a software-lui • Verificarea calităţii software-lui • Controlul modificărilor în software

41. Fluxuri statice de activităţi

42. CASE (Computer-aided software engineering) • CASE (Computer-aided software engineering) este software folosit ca suport pentru procesele de dezvoltare de software şi de evoluţie a software-lui. • Automatizare activităţi • Editoare grafice pentru dezvoltarea modelului sistemului; • Dicţionare de date pentru gestionarea entităţilor proiectării; • Constructor GUI pentru construirea interfeţei utilizator; • Debugger-epentru a sprijini găsirea erorilor în program; • Traducătoare (translator) automate pentru generare de noi versiuni de program.

43. Tehnologia CASE • Tehnologia CASEa condus la îmbunătăţiri semnificative ale procesului software. Totuşi nu atât de mult cât s-a prezis. • Ingineria software cere gândire creativă – aceasta nu este uşor de automatizat; • Ingineria software este o activitate de echipă şi, pentru proiectele mari, se cheltuieşte mult timp cu interacţiunile în cadrul echipei. Tehnologia CASE nu oferă suport pentru acestea.

44. Clasificare pentru CASE • Clasificarea ajută la înţelegerea diferitelor tipuri de instrumente CASE şi suportul oferit de ele pentru activităţile procesului (care proces?). • Perspectiva funcţională • Instrumentele sunt clasificate conform funcţiei lor specifice. • Perspectiva proces • Instrumentele sunt clasificate conform activităţilor procesului pentru care oferă suport. • Perspectiva integrării • Instrumentele sunt clasificate conform organizării lor în unităţi integrate.

45. Clasificarea funcţională a instrumentelor

46. Clasificare instrumente bazată pe activităţi

47. Integrare CASE • Instrumente • Suport pentru activităţi individuale ale procesului, cum ar fi verificarea consistenţei proiectării, editare text, etc. • Workbench-uri • Suport pentru o etapă a procesuluicum ar fi specificare sau proiectare; în mod normal includ mai multe instrumente integrate. • Medii • Suport pentru toate sau pentru o parte substanţialăa întregului proces software. În mod normal includ mai multe workbench-uri integrate.

48. Instrumente, workbench-uri, medii

49. Puncte cheie • Procesele software sunt activităţileimplicate în producerea şi evoluţia unui sistem software. • Modelele proceselor software sunt reprezentări abstracte ale acestor procese. • Activităţile generalesunt specificarea, proiectarea şi implementarea, validarea şi evoluţia. • Modelele generice ale proceselor descriu organizarea proceselor software. Exemplele includ modelul cascadă, modelul dezvoltării evolutive şi ingineria software bazată pe componente. • Modelele iterative ale procesului descriu procesul software process sub formă de ciclu de activităţi.

50. Puncte cheie • Ingineria cerinţelor este procesul de dezvoltare a specificaţiilor software-lui. • Procesele de proiectare şi implementare transformăspecificaţiile în program executabil. • Validarea implică controlarea faptului că sistemele îşi îndeplinesc specificaţiile şi necesităţile utilizatorului. • Evoluţiase referă la modificarea sistemului după ce a fost dat în exploatare. • RUP(Rational Unified Process) este un model generic de proces care separă activităţile de etape. • Tehnologia CASE oferă suport pentru activităţile procesului software.