Managementul P roiectelor Software

1. Managementul Proiectelor Software Universitatea “Politehnica” București Facultatea de AutomatiășiCalculatoare CatedraCalculatoare Conf. Dr. Ing. Costin-Anton Boiangiu costin.boiangiu@cs.pub.ro

2. Managementul Proiectelor Software Capitolul 1. Introducere

3. CuprinsCapitolul 1 - Introducere • Dimensiunea unui proiect software • Planificarea proiectului • Execuția proiectului • Închiderea proiectului • Procesul de dezvoltare • Particularitățile proiectelor software • Noțiuni de bază despre management • Etapele unui proiect

4. Noțiuni introductive • Un proiect software are douădimensiuniprincipale: • Ingineriaproiectului • Se ocupă cu dezvoltareaefectivă a proiectului • Se concentreazăpeaspecteprecum design, cod, testare • Managementulproiectului • Planificareașicontrolulactivităților de inginerieîn scopulatingeriiobiectivelorproiectului • costuri • timpi de execuție • Calitate

5. If you don't stand for something, you'll fall for anything.

6. Dimensiunea unui proiect software Proiecte mici : Proiecte mari: • Echipeformatedintr-un număr redus de persoane • Durată de câteva săptămâni • Metodeinformale demanagement șidezvoltare • email-uri • câtevatermene limită • comunicare verbală • Echipe mari; durată câteva luni • Taskuri este efectuate cu atenție; metode bine cunoscute • Fiecare produs intermediar este documentat riguros și verificat • Task-urile sunt planificate și urmărite pas cu pas • Rigurozitate și formalitate crescută

7. Proces • O secvență de pașicetrebuiescurmațipentru a executa cu succes o activitate (un task) • Într-o organizație • Reuneșteexperiența inginerilorși a managerilor de proiect(experiența dobândită din execuția cu succes a unorproiecteanterioare). • Esențialepentru • Planificarea cu succes a unuiproiect • Pentruevitareaunorcapcanece pot duce la eșeculproiectului.

8. Avantajele utilizării proceselor • Un cumul de cunoștințe colective • Rolesențialîn estimareasuccesului/eșeculuiunuiproiect • Nici o organizație nu poateînvăța din experințeletrecute fără a definișifolosiprocese • Definirea a ceeacetrebuie făcut și cum = 80% din totalul de muncăîntr-un proiect obișnuit • Procese definite riguros => doar 20%

9. Procesul de management al proiectului Trei etape principale:

10. 1. Planificareaproiectului • Activități administrative și de pornire • Planificareașiorarulproiectului • Definireaobiectivelorproiectului • Estimareacosturilorși a efortului • Definireaunui plan de masurare a proiectului • Identificareariscurilorși a modului de evitare/recuperare • Obținereaacordului de la managementul superior • Definireașirevizuireaplanului de management al configurațiilor • Realizareauneiechipeșistabilirearesponsabilitățilorfiecăruia

11. 2. Execuțiaproiectului • Execuția proiectului după planul propus • Monitorizarea conformității cu procesele definite • Analiza defectelor și efectuarea de activități de prevenire a acestora • Monitorizarea performațelor la nivel de program • Efectuarea de review-uri la anumite etape critice și replanificarea unor etape dacă este necesar • Monitorizarea progresului proiectului

12. 3. Închidereaproiectului • Analizadatelor post-proiect • Etapa are loc dupaceclientulși-a datacceptulpentruprodusul final • Se urmăreștestabilireaunorconcluzii ca urmare a experiențeiacumulate, pentru a îmbunătățiproceselefolositeîn viitor • Rezultăîntr-un raport de închidere a proiectului

13. Principiile fundamentale în MPS • Procesul de dezvoltarebazatpearhitectură • Modul de dezvoltareiterativ • Principaleleriscuriconfruntate cat maidevreme. • Dezvoltareabazatăpecomponente • Plan de management al schimbărilor • Model de evaluare bazat pe demonstrații • Coobiectiv al calității și evaluarea corectă a progresului • Notații bazate pe modele • Procesul de dezvoltare configurabil și scalabil economic • Versiunile intermediare având nivele de detaliu din ce în ce mai mari

14. 1. Procesul de dezvoltare bazat pearhitectură • Componentelearhitecturale - înțelese foartebineînainte de a luaîn considerare amănuntele de detaliu • Gradul de refacere/abandon a unorcomponente– ar trebui săscadăsau să rămână constant în timpuldesfășurăriiunuiproiect • Atenție sporităacordatăarhitecturii la început • =>realizareauneifundații solidepentru 20% din elementeleresponsabile de succesulproiectului (cazuri de utilizare, erori, riscuri, etc.)

15. 2. Modul de dezvoltare iterativ • Framework de planificare cât mai dinamic • Proces de dezvoltare iterativ • =>Management al riscului mult mai bun • Rezolvarea problemelor critice foarte devreme • => Dezvoltare mai predictibilă& mai puține surprize • => Expunerea la surse de cost și/sau întârzieri neprevăzute reduse la maxim

16. 3. Principalele riscuri confruntate cat mai devreme. • Framework de planificare cât maidinamic + • Proces de dezvoltareiterativ • =>Management al risculuimultmai bun • Rezolvareaproblemelorcriticefoartedevreme • => Dezvoltaremaipredictibilă& maipuținesurprize • => Expunerea la surse de cost și/sauîntârzierineprevăzutereduse la maxim

17. The sooner you begin coding the later you finish.

18. 4. Dezvoltarea bazată pe componente • Complexitateadezvoltării de software • ~ numărul de elemente generate de cătremembriiechipei • Diminuarea număruluiacestora • Diminuareacomplexității procesuluide management

19. 5. Plan de management al schimbărilor • Dinamicadezvoltării iterative • fluxurile de lucruconcurente ale diferitelorechipe de dezvoltare care folosescaceleașicomponente • necesitălinii de referințăcontrolatefoarteriguros

20. 6. Model de evaluare bazat pe demonstrații • Integrarea apare foarte devreme în viața unui proiect și se continuă pe parcursul întregului proces de dezvoltare. • Rezultatele intermediare sunt elemente esențiale, deoarece sunt tangibile și obiective

21. 7. Evaluare obiectivă a calității și corectă a progresului • Indicatorii de progres șicalitate derivă direct din componentele dezvoltate și conferă informații importate în legatura cu trendul proiectului și gradul de corelare al produsului cu cerințele inițiale

22. 8. Notații bazate pe modele • Utilizarea unor notații inginerești în faza de design va conduce la un control mai bun al complexității, evaluări intermediare mai obiective și mai corecte, precum și analize ce pot fi automatizate

23. 9. Procesul de dezvoltare configurabil și scalabil economic • trebuie folosite împreună pentru a lărgi segmentul de piațățintă • => o întoarcere a investiției mult mai mare

24. 10. Versiunile intermediare având nivele de detaliu din ce în ce mai mari • Versiuni intermediare ce pot fi utile sunt de obicei disponibile foarte devreme în timpul procesului de dezvoltare

25. Good project management is not so much knowing what to do and when, as knowing what excuses to give and when.

26. Particularitățile proiectelor software • Ce este un proiect? • Un proiect este in fapt o activitate planuita, nerepetitiva, ale carei principale caracteristici sunt urmatoarele: • Planificarea • Activitățile nu urmăresc o anumită rutină • Anumite obiective trebuieatinse și anumite produse trebuie realizate • Există o durată de timp predeterminată (absolută sau relativă) • Munca este realizatăîn mai multe etape • Resursele disponibile au anumite constrangeri • Un proces - o serie de activități numeroase și complexe

27. Proiecte Software (Particularități) • Invizibilitate - spre deosebire de un pod sau un drum care sunt construite și progresul este vizibil imediat, în cazul unui produs software progresul nu este evident foarte repede • Complexitate - Produsele software sunt unele dintre produsele cu cea mai mare complexitate per euro/dolar/lei investiți • Flexibilitate - Ușurința cu care un produs software poate fi modificat este unul dintre cele mai importante atu-uri ale acestui tip de proiecte

28. Categorii de produse software • Sistemeinformaționale vs. sisteme embedded • În cazulsistemelorinformaționale, produsul software are interfete cu organizatia; sistemele embedded au interfete cu altemasini. • Exemple: • Sisteminformatic: sistem de gestiune a stocului • Sistem embedded: sistem de control automat al aeruluiconditionatîntr-un depozit

29. Categorii de produse software • Obiective vs produse • Produsele software – scopul: a crea un anumit produs, sau de a atinge un anumit obiectiv. • Dezvoltarea produselor software - 2 etape: • Prima: proiect bazat pe obiective care urmarește recomandarea unei soluții software pentru a satisface anumite cerințe • A doua: dezvoltarea efectivă a produsului software

30. Proiectul ca un sistem • Sisteme, subsistemeșimedii • Sistem= o mulțime de părțiinterconectate • Oricesistemînsăeste de obicei parte a unui alt sistem, moment în care reprezintă de fapt un subsistem. • Mediul= tot ceeace se aflăîn afarasistemului • toateelementele care • pot influența sistemul • darasupra cărorasistemulîn cauză nu are nici un control.

31. Sisteme deschise vs. sisteme închise • Sistemedeschisesuntacelea care interacționează cu mediul exterior. • Majoritateasistemeloraparțin acesteicategorii; • Celemaimulteproblemeîn procesul de dezvoltare a unuiprodus software fiindchiar o urmare a incapacității dezvoltatorilor de a realiza cât de deschiseste un sistemîn realitate • Sub-optimizări - subsisteme care lucrează la parametriioptimi, dar care au un efectnegativasuprasistemuluiîn ansamblu. • Exemplu: un produs software foarteeficient, dar care estefoartegreu de modificat

32. Sisteme sociotehnice • Orice proiect software necesita organizare: • din punct de vedere tehnologic • din punct de vedere al resurselor umane. • Ca urmare • managerii de proiect trebuie să aibă • cunoștințe tehnice • capacitatea de a comunica eficient cu oamenii.

33. The first myth of management is that it exists.

34. Noțiuni de bază • Ceestemanagementul? • Managementulimplicăurmătoareleactivități:

35. Noțiuni de bază

36. Principalele probleme • EstimareașiPlanificareaeronată a etapelor unuiproiect • Definireaeronată a Rolurilorîn cadrulechipei • SelectareaunorCriterii de succesgreșite • Presiuneatermenelor limită • Lipsade cunoștințe referitoare la domeniul de aplicație al produsului • Lipsa de standardeși măsurătoriprivindcalitatea

37. Principalele probleme (2) • Lipsa tehnicilor necesare • Lipsa controlului calității • Lipsa comunicației eficiente care poate duce la efectuarea aceleiași operațiuni de mai multe ori • Schimbări apărute în mediul software sau în cerințele inițiale • Lipsa de pregătire a personalului

38. Stakeholders • Persoane care au un anumit interes în respectivul proiect • Trei categorii principale:

39. Participanții la proiect • Determină gradul de succes al proiectului • Deseori se pot afla în stare tensionatăși chiar conflictuală • Cunoașterea de către managerul de proiect a tuturor participanților cât și a rolului și așteptărilor acestora va duce la găsirea soluțiilor de compromis care să nu blocheze derularea proiectului și finalizarea sa pentru a se realiza așteptările participanților

40. Participanții la proiect • Este bine să se deosebească din categoriile participanților participanții cheie, cei care vor determina gradul în care proiectul finalizat a întâmpinat așteptările participanților sau nu • Participanții implicați în proiect, pot fi persoane fizice sau juridice

41. The 7 Phases of a Project

42. Recapitulare • Proiect software • Ingineria proiectului • Managementul proiectului • Proces • Planificarea proiectului ->Execuția proiectului->Închiderea proiectul • Riscuri • Modele • Sisteme • Participanții la proiect

43. Mulțumesc