Managementul si dezvoltarea proiectelor software

1. Managementul si dezvoltarea proiectelor software UNIT 1. Managementul proiectelor

2. Obiective • Ingineria software ?! • Ciclul de viata al unui produs software • Modele de dezvoltare software • Caietul de sarcini

3. 1.Ingineria software ?! • De ce inginerie software? • Definitia ingineriei software

4. 1.1 De ce inginerie software ? Pentru a se trece de la dezvoltarea ad-hoc si imprevizibila la o dezvoltare strucurata, constructiva si sistematica

5. Istorie • Programarea modulara Pascal • Programarea orientata obiect C++/Java • Programarea cu ajutorul componentelor Entreprise Java Beans

6. Criza dezvoltarii software Erori grave • Sonde spatiale pierdute (Venus ’60, Marte 99) • Criza rachetelor – Cuba 1979 • Rachetele Patriot 1991 • Primul zbor Ariane 5 1996 artificii de 5 miliarde $ • Aeroportul Denver 1994-1996 • Anul 2000 • Incidente în fiecare luna - bursa din Tokyo … - accidente de circulatie • Proiectarea software • Livrarea în întârziere a tuturor proiectelor • Cost mult ridicat fata de cel prevazut • Livrarea unui produs de proasta calitate • Esuarea în majoritatea cazurilor • Studiu american din 1995 : 81 miliarde $ / an datorat esecului software

7. Constructia podurilor si dezvoltarea software Ingineria software • Sistemele informatice devin foarte repede extrem de complexe • Esecuri foarte numeroase • « Craparea » este un fenomen des întâlnit si obisnuit • Pierderi minore în general • Cu exceptia sistemelor critice putem spune ca un produs software nu poate anticipa orice situatie • Adaugarea sau schimbarea functionalitatilor, de platforme • Ingineria civila • Esecuri mai putine • Surparea unui pod este foarte perculoasa pentru oameni • O experienta de mai multe milenii • Un pod stricat în general nu se repara ci se reconstruieste • Podul rezista la 99% din conditii • Daca un pod este inutilizabil atunci schimbam traseele drumurilor

8. 1.2 Definitia Ingineriei Software • Disciplina ( = metode,tehnici, utilitare ) • bazata pe cunostinte (teorie) • pe cunostinta de a face,produce ceva (pragmatica) • si de a face sa se stie (comunicare) • pentru a produce (dezvoltare) • în mod industrial (marime) • aplicatii software (produse) • de cea mai buna calitate

9. 2.Ciclul de viata al unui produs software

10. Cum se va desfasura proiectul de la Inginerie Software ? • Întâlniri la 3F, C15, Zambara … • Craciunul , deci nu facem nimic • Sesiunea …. Oau , mi se învârte totul în cap Iadul studentesc ….

11. 2.1Cum se desfasoara în general un proiect ? • Entuziasm general la început • Un punct de criza în care se constientizeaza ca proiectul nu poate fi predat la timp • Spre sfârsit : un volum de munca impresionabil (24h/24h), resurse umane suplimentare (colegul de camera de anul 4), tensiune si relatii încordate • Acest ciclu se repeta si în marile companii de soft la primele proiecte realizate de catre o companie. • Principala cauza este incapacitatea de planificare si gestionare a resurselor (timp, oameni, documentatie, utilitare, cunostinte, etc) .

12. 2.2 Asa da, asa nu Termen de predare Punct de criza Efort 10 Pas 1 Pas 2 Pas 3

13. 2.3 Ciclul de viata optim pentru derularea unui proiect • Ciclu de viata = ansamblul etapelor parcurse în dezvoltarea unui produs software. • Etapele ciclului de viata : • Culegerea de specificatii • Analiza • Proiectarea • Implementarea si Testarea • Validare si Integrare • Calificare • Punerea în functiune • Mentinerea • Retragerea sau înlocuirea

14. 2.3.1 Culegerea de informatii • Definirea problemei, adica a ceea ce se da în problema, a resurselor de care dispunem (alte sisteme informatice sau BD pe care le putem utiliza, tehnici utilizabile, persoane care ar putea lucra,etc) • Specificarea detaliata a functionalitatilor ce trebuiesc suportate de catre sistemul informatic (adica realizarea diagramei de cazuri de utilizare) • Este de fapt realizata prin caietul de sarcini • Analiza functionala (vezi Curs 2 UML)

15. 2.3.1.1.Stabilirea obiectivelor • Se face de catre managerul de proiect; • Fiecarea idee buna trebuie promovata indiferent de cel care a contribuit la ea; D1 Clientul este cel care doreste acel produs. D2 Utilizatorul este cel care doreste sa utilizeze acel produs software. D3 Dezvoltatorii sunt aceia care intentioneaza sa « fabrice » acel produs.

16. 2.3.1.2 Definirea necesitatilor • Un caiet de sarcini este stabilit de catre client în colaborare cu utilizatorul si dezvoltatorul : - descrierea functionalitatilor asteptate de la aplicatie; - constrângeri non-functionale (timp de raspuns, utlizarea memoriei, etc ); - posibilitatea utilizarii Diagramei de Cazuri de utilizare; Rezultatul acestei etape : Caietul de sarcini

17. 2.3.2 Analiza • Cautarea solutiilor corecte posibile A gasi solutiile corecte posibile înseamna • a alege tehnica de programare ( orientat obiect, procedural, componente); • a gasi algoritmii potriviti si adaptarile lor la necesitatile problemei; • determinarea modelului obiectual necesar dezvoltarii proiectului; • a alege solutia software necesara dezvoltarii;(MySQL sau Oracle,Java sau C#, JavaBuilder sau Eclipse,etc ). • a gasi criteriile de dezvoltare (ergonomie, accesibilitate, rapiditate, etc ) • Identificarea caracteristicilor acestor solutii Pentru solutiile gasite se va încerca o acomodare pe cazuri simple si studierea caracteristicilor (comportamente,raspunsuri, timp de executie,etc ) în aceste situatii de cercetare.

18. 2.3.2.1 Analiza necesitatilor • Este de fapt definitia produsului de realizat • specificatiile precise ale produsului de realizat; • constrângeri ce trebuiesc satisfacute; Rezultatul acestei etape • dosarul de analiza (specificatii functionale si non-functionale) • schita manualului utilizatorului ;

19. 2.3.2.2 Planificare • Defalcarea proiectului în sarcini care se înlantuiesc în mod continu si logic. • Afectarea fiecarui membru al echipei pentru o anumita durata si scop. • Definitia normelor de calitate ce trebuiesc satisfacute . • Alegerea metodelor de concepere si testare. • Stabilirea dependentelor externe (umane, materiale, preturi, calitate a serviciilor) Rezultatul acestei etape • Plan de calitate al produsului, Planul proiectului • Estimarea costurilor reale • Deviz destinat clientului (pret, întârzieri, livrabile)

20. 2.3.3 Proiectarea • La modelele rezultate în urma etapei de analiza se adauga noi elemente pentru a defini o solutie particulara ce « transpune » problema în cauza. • Proiectarea trebuie sa aibe în vedere optimizarea unor criterii de dezvoltare. • Proiectarea este de fapt o rafinare a modelului obiectual ( o diagrama de clasa aproape perfecta, constrângeri pentru atribute si metode, coerenta modelului )

21. Faza de concepere • Definirea arhitecturii software. • Interfete dintre diferite module. • Rolul acestei etape este de a concepe arhitectura de asa natura astfel încât componentele produsului sa fie independente pentru a facilita dezvoltarea. Rezultatul acestei etape • Dosarul de conceptie; • Planul de integrare; • Planul de testare; • Actualizarea planning-ului ;

22. 2.3.4 Implementarea si testarea • Alegerea limbajului potrivit de dezvoltare • Alegerea tehnologiei potrivite de dezvoltare (alegerea serverului de baze de date, alegerea tehnologiei de stocare a datelor, alegerea metodei de transmitere a datelor – protocoale de comunicatii, sincronizare etc ) • Scrierea codului sursa / scripturi ,etc. Rezultatele acestei etape • Module codate • Documentarea fiecarui modul • Actualizarea planning-ului

23. Testarea • Se verifica echivalenta dintre implementare si modelul proiectat. • Validarea implementarii în raport cu criteriile de corectitudine identificate în etapa de analiza. • Implementarea si testarea se face pentru fiecare modul în parte.De fapt testarea se împarte în doua : este vorba de testarea pentru fiecare modul al aplicatiei dar si testarea întregii aplicatii.Testarea întregii aplicatii este de fapt o alta etapa din ciclul de viata si trebuie facuta aceasta distinctie. Rezultate Module testate Rezultatele testarilor unitare

24. 2.3.5 Integrarea si validarea aplicatiei • Fiecare modul este integrat cu celelalte conform planului de integrare. • Ansamblul este testat conform cu planurile de testare. Rezultate • Produs software testat • Manual de instalare • Versiunea finala a manualului de utilizare.

25. 2.3.6 Calificarea produsului soft • Teste de amploare realizate în conditii normale de utilizare. • Teste non-functionale • Teste de încarcare • Teste de toleranta la pana Rezultate Raportul de anomalii

26. 2.3.7 Punerea în functiune • Livrarea produsului final • Instalarea produsului la client • Sfârsit sau nu ?! ….

27. 2.3.8 Mentinerea aplicatiei • Raporturi de incidente sau anomalii • Cerere de modificari corective • Cereri de evolutie a aplicatiei • Cod si documentatie modificata • O noua serie de teste • Unitare • De integrare • Non – regresive

28. 3. Modele ale ciclului de viata • Modelul în cascada • Modelul în V • RAD • RUP • 2TUP • XP

29. 3.1 Modelul în cascada Analiza necesitatilor Modificarea necesitatilor Specificatii functionale Planificare Concepere Implementare Integrare Calificare Exploatare Retragere

30. Problemele modelului în cascada • Proiectele adevarate rar urmeaza o dezvoltare secventiala • Este dificil a stabili toate necesitatile proiectului la începutul sau • Produsele soft dezvoltate urmând un model în cascada apar de cele mai multe ori cu întârziere • Acest model este aplicabil pentru proiectele care sunt bine întelese

31. 3.2 Modelul în V Specificatii functionale si planificare Calificare Conceptie globala Integrare Teste unitare Conceptie detaliata Programare

32. Comparatie • Modelul în V permite • O buna anticipare în dezvoltare • Evita întoarcerea • Dar • Cadrul de dezvoltare este foarte rigid • Durata este adesea foarte lunga • Produsul soft apare adesea foarte târziu

33. Mini-concluzie Clientul încearca prototipul « Ascultarea » clientului Construirea sau ameliorarea prototipului

34. 3.3 RAD Rapid Aplication Develoment • Discutii si interactiuni cu utilizatorul • Verificarea eficacitatii reale a unui algoritm • Verficarea specificatiei interfetei cu utilizatorul (GUI) • Metoda utilizata adesea pentru stabilirea si identificarea necesitatilor • Utilizata adesea de catre generatoarele de coduri

35. 3.4 RUP Rational Unified Process Workflow= disciplina

36. Definitii • Initiere : este faza în care se : • Stabileste domeniul proiectului; • Stabilesc criteriile pentru stabilirea reusitei; • Evalueaza riscurilor; • Estimeaza resurselor necesare; • Un grafic de executie preliminar,raportat la cele patru faze principale. • Elaborare :stabilirea unei arhitecturi robuste,adica se realizeaza planul proiectului si se elimina factorii de risc majori. • Constructie : în mod iterativ si incremental se va implementa un produs complet. • Tranzitie : sosftul este livrat utilizatorilor pentru testarea ( versiune beta a sistemului )

37. Faze de dezvoltare Initiere Elaborare Constructie Tranzitie Produs fabricat Capacitate operationala initiala Obiective (Viziune) Arhitectura timp

38. Workers Artefactos Activities Elemente RUP Workflow: Requirements Workflow Detail:Analyse the Problem

39. 3.5 2TUP : Two Track Unified Process • Se concentreaza în jurul arhitecturii sistemului de proiectat • Propune un ciclu de dezvoltare în Y • Se poate adapta pentru proiecte de orice marime

40. 3.6. XP EXtreming Programming • Este recomndabila pentru echipele de maxim 10 persoane • 4 valori : • Comunicare • Simplitate • Feedback • Curaj

41. 4.Caietul de sarcini • Ce este un caiet de sarcini ? • Structura 1. Introducere 2.Organizarea proiectului 3.Gestiune 4.Tehnici 5.Calendar si Buget 6.Functiile produsului 7.Constângeri non-functionale

42. 4.1 Ce este un caiet de sarcini ? • Caietul de sarcini constituie fundamentul pentru orice proiect. • El ne furnizeaza de fapt un ghid despre ce avem de facut în cadrul proiectul la care vom avea de lucru. • Pâna aum în majoritatea cazurilor studentii s-au confruntat cu probleme simple a caror rezolvare se rezuma la maxim câteva • În cazul problemelor de matematica un mic „caiet de sarcini” era reprezentat de ceea ce se scrie înainte de a rezolva problema,adica ipoteza si concluzia. • Daca însa problema pe care o avem de efectuat este una mai complicata atunci trebuie efectuat un adevarat caiet de sarcini. • De exemplu daca trebuie organizata o excursie atunci este necesara realizarea unui caiet de sarcini. • În viata de zi cu zi,conceptul de caiet de sarcini este utilizat frecvent . Daca guvernul doreste sa construiasca autostrada Timisoara-Budapesta, atunci va face un concurs la care firmele care vor dori sa construiasca aceasta autostrada vor participa prin caietul de sarcini.Practic vom avea de-a face cu un concurs al caietelor de sarcini.

43. 4.2.1 Introducere • Rezumatulcontine o descriere detaliata a aplicatiei, asupra scopului aplicatiei respective, a directiilor de cercetare pentru atingerea obiectivelor aplicatiei si alte amanunte considerate esentiale în întelegerea aplicatiei . • Materiale ce trebuiesc livrate clientului, adica produsul soft, bibliotecile asociate, documentatie tehnica, manualul utilizatorului,etc. • Definitii si acronime . Gânditi-va ca un client poate nu va pricepe tot ceea ve-ti scrie în acest caiet,mai ales termenii specifici.În aceasta rubrica aveti sansa sa faceti cunoscut limbajul utilizat.

44. 4.2.2 Organizarea proiectului • Stabilirea etapelor de dezvoltare • Stabilirea relatiilor dintre diferitele etape de dezvoltare • Distribuirea sarcinilor (adica ce sarcina are fiecare)

45. Microsoft Office Project • Editor si utilitar pentru organizarea task-urilor

46. 4.2.3 Gestiune • Obiective si prioritati • Ipoteze,dependente si constrângeri • Gestiunea riscului • Mijloace de control

47. 4.2.4 Tehnici • Metode si utilitare utilizate • Metode si utilitare utilizate în proiectare • Metode si utilitare utilizate în dezvoltare • Metode si utilitarea utilizate în crearea documentatiei • Metode si utilitare utilizate în testare • Metode si utilitare utilizate în integrarea modulelor • Utilitar pentru asigurarea gestiunii proiectului • Documentatie • Documentatia utilizata pentru folosirea metodelor si utilitarele de mai sus • Documentatia proiectului (JavaDoc sau Doxygen) http://www.stack.nl/%7Edimitri/doxygen/index.html Doxygen http://java.sun.com/j2se/javadoc/ JavaDoc

48. 4.2.5 Calendar si buget • Calendarul desfasurarii proiectului, adica perioada în care trebuie efectuata o anumita sarcina,cine trebuie sa o efectueze si care va fi rezultatul muncii din acea etapa, cum vom evalua rezultatul acelei etape. • Bugetul alocat • Resurse, adica de ce avem nevoie pentru a realiza acest proiect : resurse umane, calculatoare, soft-uri, resurse de documentare,etc.

49. 4.2.6 Functiile produsului • Este de fapt o transpunere a diagramei cazurilor de utilizare. • Pentru fiecare actor vom determina functiile pe care acesta ar intentiona sa le utilizeze.

50. 4.2.7 Constrângeri non-functionale