Managementul Proiectelor Software

Universitatea Politehnica BucurestiFacultatea de Automatica si CalculatoareCatedra CalculatoareConf. Dr. Ing. Costin-Anton BoiangiuCostin.Boiangiu@cs.pub.roManagementul Proiectelor SoftwareCapitolul 3. Faza de planificare

Managementul Proiectelor SoftwarePlanul de proiectPlanul de proiect : este documentul cu care culmineaza toate activitatile de planificare executate de catre managerii de proiect

are un important rol comunicational: ofera managementului superior o vedere de ansamblu asupra obiectivelor proiectului si asupra modului prin care acestea vor fi indepliniteplanurile de proiect sunt de obicei supuse unui review foarte atent deoarece greseli flagrante lasate nerezolvate in aceasta etapa pot conduce la probleme foarte grave in faza de executie

The Project Management Plan Pankaj Jalote, Software Project Management in Practice (Chapter 1), Addison Wesley, 2002

The project management plan (PMP) document is the culmination of all planning activities undertaken by project managers. The outputs of the various planning activities appear in this document, which becomes the baseline document guiding the overall execution of the project. It should not be confused with the detailed project schedule, which represents only the schedule and assignment of activities.Documenting the planning outputs enables the project plan to be reviewed for deficiencies. In many instances, a project plan review has revealed glaring shortcomings that, if not corrected, could have spelled trouble for the project. A thorough review of the management plan is one of the best ways to nip potential problems in the buda huge value to project managers, particularly those who are less experienced.The document also serves an important communication purpose. It gives senior management an overall view of the project goals and commitments and describes how the project will be managed to meet them. It gives the project team a comprehensive view of the project and the roles of the individual team members.

3Structura planului de proiectSumarul proiectuluiun overview de nivel inalt al proiectuluiSectiunea de planificaremodul de executie al diferitelor proceduri de planificaremodul de dezvoltare ce va fi folosit, estimarea timpilor de executie etc.Sectiunea de urmarire (tracking)masuratorile ce vor fi facute in timpul proiectuluisistemele folosite pentru inregistrarea datelor, etc.Sectiunea destinata echipeistructura si membrii echipeirolurile si responsabilitatile diferitilor membri ai echipeiThe Project Management Plan Pankaj Jalote, Software Project Management in Practice (Chapter 1), Addison Wesley, 2002

4Planul de proiect - detaliiUn proiect software este o munca de echipa; in managementul unei echipe de dezvoltate trebuiesc luate in considerare atat obiectivele proiectului, cat si obiectivele individuale ale fiecarui membru al echipeiComunicarea, atat cu membrii echipei cat si cu clientii, este esentiala; planificarea trebuie sa ia in considerare eventuale conflicte ce pot aparea in relatia cu ambele parti mai sus mentionateDocumentarea detaliata a diferitelor task-uri de planificare este esentiala; de asemenea, un review atent din partea managementului superior este necesara pentru a detecta din timp eventualele probleme de planificareThe Project Management Plan Pankaj Jalote, Software Project Management in Practice (Chapter 1), Addison Wesley, 2002

5Planul de proiect - detaliiInformatii esentiale in planul de proiect:Obiectivele proiectuluiProcesul de dezvoltare folositModul de managementEstimarea efortuluiPunctele de control intermediar (Milestones)Planul de management al risculuiControlul calitatiiPlanul de urmarire si verificare al proiectuluiOrganizarea echipeiModul de rezolvare el eventualelor conflicte in cadrul echipe si/sau cu clientulThe Project Management Plan Pankaj Jalote, Software Project Management in Practice (Chapter 1), Addison Wesley, 2002

6Planificarea pas cu pasPasul 0 Alegerea proiectului

Selectarea proiectului este numita si Pasul 0 deoarece este o etapa ce se afla de fapt in afara procesului principal de planificare al proiectuluiIn aceasta etapa au loc activitati ce duc la luarea unei decizii in legatura cu proiecte cate vor fi incepute aceasta decizie poate fi luata individual sau poate sa faca parte dintr-o strategie pe termen lung a companiei

Step Wise: an overview on project planning Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

7Planificarea pas cu pasPasul 1 Identificarea domeniului si a obiectivelor proiectului

Identificarea obiectivelor si masurarea eficientei cu care acestea pot fi atinseInstituirea unei autoritati in cadrul proiectuluiIdentificarea tuturor persoanelor interesate in proiect, precum si a intereselor individuale ale fiecareia Modificarea obiectivelor in lumina analizei asupra persoanelor interesate in proiectStabilirea metodelor de comunicare cu toate partile interesate

Step Wise: an overview on project planning Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

8Planificarea pas cu pasPasul 2 Identificarea infrastructurii

Stabilirea modului in care proiectul se incadreaza in strategia companieiIdentificarea standardelor si a procedurilor de instalareIdentificarea modului in care va fi organizata echipa de dezvoltare

Deciziile strategice sunt de obicei documentate fie intr-un plan de strategie business, fie intr-un plan tehnologic dezvoltat pe baza planului business

Step Wise: an overview on project planning Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

9Planificarea pas cu pasPasul 3 Analiza caracteristicilor

Stabilirea tipului de proiect (proiectul are ca finalitate atingerea anumitor obiective/un anumit produs)Identificarea celor mai importante riscuriAnaliza modului de implementare, avand in vedere cerintele utilizatorilorSelectarea ciclului de viata folosit pentru dezvoltareRevizuirea estimarilor asupra resurselor

Step Wise: an overview on project planning Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

10Planificarea pas cu pasPasul 4 Identificarea produselor si a activittilor

Identificarea si descrierea produselor finale ce vor rezulta ca urmare a proiectuluiDocumentarea eventualelor probleme ale produsuluiDezvoltarea unei retele de activitati idealaModificarea retelei de activitati, luand in considerare nevoia pentru etape intermediare si puncte de verificare

In aceasta etapa activitatile sunt descrise foarte in detaliu; planurile de termen lung sunt descrise succint, accentul fiind pus pe task-urile imediateStep Wise: an overview on project planning Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

11Planificarea pas cu pasPasul 5 Estimri ale efortului pentru fiecare activitate

Efectuarea de estimari folosind o abordare de jos in susEstimari de personalEstimari de timpEstimari de resurseRevizuirea planului pentru a crea activitati ce pot fi controlateActivitatile ce dureaza mult timp sunt foarte greu de controlat; este de preferat ca acestea sa fie impartite in sub-activitati cat mai scurte, pentru a se putea masura cat mai eficient stadiul in care se afla proiectul.

Step Wise: an overview on project planning Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

12Planificarea pas cu pasPasul 6 Analiza riscurilor

Identificarea si cuantificarea riscurilor datorate activitatilorImportanta (seriozitatea) risculuiProbabilitatea de aparitiePlanificarea reducerii riscurilor si a unei modalitati de masurare a evenimentelor neprevazuteAjustarea planurilor si a estimarilor astfel incat sa ia in considerare riscurile identificare anteriorStep Wise: an overview on project planning Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

13Planificarea pas cu pasPasul 7 Alocarea resurselor

Identificarea si alocarea resurselorSe inregistreaza tipul de personal necesar pentru fiecare activitatePersonalul disponibil pentru proiect este identificat si alocat provizoriu la diferitele task-uriRevizuirea planurilor si a estimarilor, astfel incat sa ia in considerare constrangerile datorate resurselorIn cazul in care anumiti mebrii ai echipei trebuie sa lucreze la mai mult de un task in acelasi timp, se hotaraste o ierarhie de prioritati Step Wise: an overview on project planning Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

14Planificarea pas cu pasPasul 8 Revizuirea/Publicarea planului

Revizuirea aspectelor legate de calitate in planul de proiectDocumentarea planurilor si ajungerea la un acord din partea tuturor partilor implicate

Pasul 9 Executia planului

Pasul 10 Nivele inferioare de planificare

Step Wise: an overview on project planning Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

15Planificarea pas cu pas Concluzii(1)Oricare ar fi abordarea fazei de planificare a unui proiect, aceasta trebuie sa contina:

Stabilirea obiectivelor proiectului

Analiza caracteristicilor proiectului

Stabilirea unei infrastructuri care sa contina o organizare potrivita si un set de standarde, metode si unelte ce vor fi folosite in cadrul proiectului

Step Wise: an overview on project planning Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

16Planificarea pas cu pas Concluzii(2)Identificarea produselor generate de catre proiect, precum si a activitatilor necesare pentru a crea aceste produse

Alocarea resurselor la fiecare activitate in parte

Stabilirea unor puncte de control a calitatii

Managementul unui proiect este un proces iterativ; cand se apropie timpul efectuarii unei anumite activitati, aceasta trebuie re-planificata mai in detaliuStep Wise: an overview on project planning Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

17Planificarea pas cu pas Concluzii(3)

Sursa: Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999Step Wise: an overview on project planning Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

18Metode de dezvoltare ale ciclului de viataProiecte in-houseEchipa de dezvoltare si utilizatorii apartin aceleiasi organizatiiProiectul se incadreaza intr-un portofoliu de sisteme informationale deja existenteMetodele si tehnologiile folosite sunt dictate de standardele localeProiecte de tip software houseUtilizatorii si echipa de dezvoltare fac parte din organizatii diferiteMetodele si tehnologiile folosite sunt stabilite de catre managerul de proiect pentru fiecare proiect in parteSelection of an appropriate project approach Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

19Metode de dezvoltare ale ciclului de viataAlegerea tehnologiilor si a metodologiilor

Tehnologia aleasa este foarte importanta deoarece determina:necesarul de intruire al personaluluitipul de personal care este recrutatmediul de dezvoltare (atat hardware, cat si software)aranjamentele de intretinere ale sistemului

Tipuri de metodologiiOO Object OrientedJSP (Jackson Structured Programming)SSADM (Structured System Analysis and Design Method)Etc.

Selection of an appropriate project approach Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

20Metode de dezvoltare ale ciclului de viataAlegerea tehnologiilor si a metodologiilor

Criterii:

Produsul dezvoltat va un pachet general (ex. procesator de text) sau un pachet specific unei anumite aplicatii (ex. sistem de rezervare a biletelor la o companie aeriana)?Este sistemul unul care necesita anumite unelte pentru dezvoltare:contine procesari concurente ale datelor?este un sistem bazat pe informatii (knowledge-based)?necesita procesari grafice foarte avansate?Selection of an appropriate project approach Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

21Metode de dezvoltare ale ciclului de viataAlegerea tehnologiilor si a metodologiilor

Criterii (continuare):

Sistemul este unul critic din punct de vedere al securitatii? (o eroare aparuta poate pune in pericol de exemplu viata unor oameni?)Care este natura mediului hardware/software in care produsul va fi operational?Produsul este unul orientat pe date sau unul orientat pe control?

Selection of an appropriate project approach Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

22Metode de dezvoltare ale ciclului de viataPlanul tehnic

Introducere si sumar al contrangerilorCaracteristicile sistemuluiRiscurile si incertitudinile proiectuluiCerintele clientului referitoare la implementareAbordarea recomandataSelectarea metodologiei Metode de dezvoltareUnelte softwareMediul software/hardware tintaSelection of an appropriate project approach Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

23Metode de dezvoltare ale ciclului de viataPlanul tehnic (continuare)

ImplementareaMediul de dezvoltare Mediul de intretinere Pregatirea (training-ul) ImplicatiiProduse si activitati ale proiectuluiRaport financiarSelection of an appropriate project approach Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

24Metode de dezvoltare ale ciclului de viataMetode de dezvoltare softwareMetode structurate (inclusiv metodele Orientate pe obiecte)

Sunt alcatuite dintr-o multime de pasi si reguli care, cand sunt aplicate, genereaza prodiagramele de flux, de date, etc. (fiecare asemenea produs este documentat atent)De cele mai multe ori sunt mult mai consumatoare de timp decat metodele intuitive, acest lucru ducand si la o crestere a costurilor proiectuluiAvantaje: sistemul este mult mai putin sensibil la erori si mult mai usor de intretinut la sfarsitRecomandate in cazul proiectelor mari, care implica multi dezvoltatori si multi utilizatoriSelection of an appropriate project approach Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

25Metode de dezvoltare ale ciclului de viataMetode de dezvoltare softwareMetode de dezvoltare rapida

Se bazeaza pe workshop-uri de trei-cinci zile in care dezvoltatorii lucreaza intensiv impreuna cu clientii pentru a identifica si pentru a cadea de acord asupra cerintelor business ale proiectuluiUn principiu esential folosit este acela de time-box intinderea fiecarei etape a proiectului este constransa de un deadline predeterminat, foarte scurt si inflexibil Cerintele ce nu pot fi satisfacute intr-un anumit time-box, sunt mutate in etapele urmatoare

Selection of an appropriate project approach Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

26Metode de dezvoltare ale ciclului de viataMetode de dezvoltare softwareModelul in cascada

considerat metoda clasica de dezvoltare a sistemelorpermite controlul eficient alproiectelor si estimarea foarte exacta a timpilor de executie

Sursa: Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999Selection of an appropriate project approach Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

27Metode de dezvoltare ale ciclului de viataMetode de dezvoltare softwareModelul procesului in V

Sursa: Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999Selection of an appropriate project approach Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

28Metode de dezvoltare ale ciclului de viataMetode de dezvoltare softwareModelul procesului in V (continuare)

Extinde activitatile de testare din modelul in cascadaFiecare pas are un proces de validare corespunzator; in cazul in care apar defecte, procesul de validare intoarce dezvoltarea la pasul de dezvoltare corespunzator; toti pasii urmatori trebuiesc apoi refacutiIdeal, acest tip de feed-back ar trebui sa apara numai in cazul unei discrepante mari intre specificatiile unei anumite activitati si ceea ce a fost de fapt implementat

Selection of an appropriate project approach Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

29Metode de dezvoltare ale ciclului de viataMetode de dezvoltare softwareModelul in spirala

Poate fi considerat ca o alta vedere a modelului in cascadaUn mai mare grad de detaliu este necesat la fiecare etapa a proiectului, acest fapt justificand si un mai mare grad de incredere in probabilitate de succes a proiectuluiAcest model poate fi vazut ca o spirala in care sistemul dezvoltat este vazut din ce in ce mai in detaliu la fiecare rotatieUn proces de evaluare a etapei precedente are loc inaintea inceperii unei noi iteratii

Selection of an appropriate project approach Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

30Metode de dezvoltare ale ciclului de viata

Selection of an appropriate project approach Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

31Metode de dezvoltare ale ciclului de viataModelul in spirala (continuare)

Dezvoltare iterativbazat pe ideea de ciclu de producieprocesul de dezvoltare cuprinde mai multe cicluri de producieDezvoltare incremental fiecare ciclu are o complexitate (un nivel de detaliere) mai mare dect precedentulModelul spiral (Boehm, 1986)B. W. Boehm, A spiral model of software development and enhancement, ACM Sigsoft, Software Engineering Notes, 11(1986), No. 4, 14-23. combin trsturile ciclului clasic de viaprototipizriielement nou: ANALIZA RISCURILOR

Selection of an appropriate project approach Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

32Metode de dezvoltare ale ciclului de viataModelul in spirala (continuare)

Activitile unui ciclu de producie(1) planificarestabilirea obiectivelor, alternativelor de rezolvare i a restriciilor pentru ciclul curent(2) analiza riscuriloranalizeaz alternativele de rezolvare i restriciile din (1)identific factorii de riscdecizia GO/NO GO (continu/renun)dac toate cerinele clientului sunt ndeplinite, dezvoltarea este ncheiat dac riscurile sunt prea mari se oprete dezvoltareadac riscurile se pot ine sub control, se ncepe un nou ciclu de producie(3) inginerie - nceputul unui ciclu noudezvoltarea produsului pe urmtorul nivel de detalierese pot folosimodelul clasicprototipizarea - pentru clarificarea unor cerine(4) evaluarea clientului

Selection of an appropriate project approach Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

33Metode de dezvoltare ale ciclului de viataModelul in spirala (continuare)Avantajeabordare evoluionistajut la nelegerea riscurilor i la identificarea modalitilor de inere sub control a acestoraprototipizarea este folosit ca mecanism de reducere a riscurilorciclul clasic de via este ncorporat ntr-un cadru iterativ, care reflect mai bine lumea realDezavantajeanaliza riscurilor este o activitatea criticatenie acordat riscurilor tehnice n toate etapele proiectuluidac un risc major nu este descoperit

Selection of an appropriate project approach Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

34Metode de dezvoltare ale ciclului de viataMetode de dezvoltare softwarePrototipuri software

Tipuri de prototipuri:Throw-awayFolosit doar pentru a testa unele idei; se renunta la el in momentul in care incepe dezvoltarea sistemului operationalEvolutionarEste dezvoltat si modificat in continuu pana in momentul in care poate deveni un sistem operationalIncrementalSistemul operational este dezvoltat si implementat in etape mici; feed-back-ul de la etapele anterioare este folosit si influenteaza dezvoltarea etapelor urmatoare

Selection of an appropriate project approach Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

35Metode de dezvoltare ale ciclului de viataPrototipuri software (continuare)Dezvoltatorul creaz un model al programului care trebuie realizat; modelul poate fi:un prototip pe hrtie sau un model bazat pe calculator care prezint interaciunea om-calculator ntr-o manier ce permite utilizatorului s o neleagun prototip funcional, care implementeaz un subset al funciilor pe care trebuie s le realizeze programulun program existent care ndeplinete o parte din/toate funciile dorite pentru noul programo parte din funciile acestuia trebuie mbuntite n timpul procesului de dezvoltare

Selection of an appropriate project approach Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

36Metode de dezvoltare ale ciclului de viata

Selection of an appropriate project approach Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

37Metode de dezvoltare ale ciclului de viataPrototipuri software (continuare)

Activiti: (1) colectarea cerinelordezvoltatorul i utilizatorul stabilescobiectivele generalecerinele cunoscutedomeniile n care cerinele vor fi definite ulterior(2) producerea rapid a unui proiectse reprezint acele elemente care sunt percepute de utilizatorformatul datelor de intrareformatul rezultatelor(3) construirea prototipului(4) evaluarea prototipului de ctre utilizator(5) rafinarea prototipului(6) realizarea produsului final

Activitile (3) - (5) se repet pn cnd sunt satisfcute toate cerinele clientului

Selection of an appropriate project approach Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

38Metode de dezvoltare ale ciclului de viataPrototipuri software (continuare)

Avantajele utilizarii prototipurilor:Comunicarea este imbunatatita: de obicei clientii prefera sa nu citeasca documentele foarte mari produse de catre metodele de dezvoltare strcuturate. Chiar si daca le citesc, le este mult mai greu sa isi faca o idee in legatura cu sistemul dezvoltat, spre deosebire de utilizarea unui prototipCand nu exista un sistem deja existent care poate fi imitat, clientii pot testa diferite prototipuri pentru a isi da seama care dintre ele le este cel mai util

Selection of an appropriate project approach Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

39Metode de dezvoltare ale ciclului de viataAvantajele utilizarii prototipurilor (continuare):

Necesarul de documentatie este redus datorita faptului ca prototipul poate fi examinat in practicaCosturile de intretinere sunt reduse; daca clientul nu cere multe schimbari ale prototipului, este foarte probabil ca acesta sa nu ceara nici multe schimbari ale produsului finalClientii pot fi mult mai implicati in deciziile legate de design-ul final al sistemului

Selection of an appropriate project approach Bob Hughes, Mike Cotterell, Software Project Management - Second Edition (Chapter 2), McGraw-Hill, 1999

40Metode de dezvoltare ale ciclului de viata

Metode de dezvoltare softwareTehnicile generatiei a 4-a

Metode de dezvoltare ale ciclului de viataTehnicile generatiei a 4-a(continuare)

4GL - Fourth Generation LanguagesInstrumente CASE Computer-Aided Software Engineeringspecificarea cerinelor se face folosind limbaje de specificareapropiate de limbajul natural SAUfolosind notaii matematice (algebrice)sprijin pentru modelare, inclusiv teste de consisten i validitatetraducerea automat a specificaiilor n cod surs (forward engineering), trecndu-se prin nivele deanaliz - modele de analizproiectare - modele de proiectaregenerarea specificaiilor din cod surs (reverse engineering)faciliti grafice de nivel naltsprijin pentru diverse metodologii de analiz i proiectaregenerare automat de documentaieMetode de dezvoltare ale ciclului de viataTehnicile generatiei a 4-a(continuare)

Activiti: (1) colectarea cerinelorideal: clientul descrie cerinele folosind limbajul de specificare al instrumentului CASEn realitate: dialog ntre client i specialistul n specificarea cerineloreste necesar cunoaterea limbajului de specificare (mai ales cnd acesta nu este apropiat de limbajul natural)(2) proiectareinclude elaborarea de modele pentru analiz i proiectareeste nevoie de o reprezentare a modelelor care s permit generarea automat de cod(3) implementare folosind generarea automat de cod surseste completat (eventual) de codificarea manual a zonelor neacoperite de generarea automat(4) testarease respect toate etapele testriielaborarea documentaiei

Metode de dezvoltare ale ciclului de viataTehnicile generatiei a 4-a(continuare)

Avantajeproductivitate ridicatntreinere uoar a programelor DACcerinele sunt formulate corectactivitatea de proiectare este bine structuratDezavantajecurba de nvare a folosirii instrumentelor este lungcodul generat nu este ntotdeauna i eficientcosturi de achiziie/ntreinere foarte mariprobleme de migrare, comunicare cu alte instrumente similareproblem deschis: ntreinerea sistemelor mariRegul: instrumentul nu nlocuiete gndirea umanVezi: http://www-106.ibm.com/developerworks/components/library/co-ipuse.html?dwzone=componentsMetode avansate de planificare si analiza a proiectelorListe de task-uri detaliate (wbs work breakdown structures)

WBS reprezinta de fapt o decompozitie a muncii necesare dezvoltarii unui proiect in bucati din ce in ce mai miciDecompozitia este efectuata pana al nivelul la care exista suportul pentru o urmarire detaliata a progresului la care se afla proiectulFiecare pas elementar din decompozitie va avea un cost si o estimare muncii individuala; eforturile aferente si costurile activitatilor de la nivelele superioare sunt calculate pur si simplu prin insumarea eforturilor si costurilor activitatilor din care sunt compuseIn momentul in care lista de task-uri, impreuna cu estimarile aferente, este aprobata, estimarile de cost devin bugetul proiectului

Developing Intermediate Plans Richard Bechtold, Essentials Of Software Project Management (Section 17), Management Concepts Inc., 1999

As you are deciding how to organize your project, and the types of tools that you will need, you can also begin documenting the overall work to be performed. This can be achieved relatively quickly and easily by developing a work breakdown structure (WBS). However, one of the difficulties involved in building a WBS is that you need at least a very high-level idea about how you are going to build the system. In other words, you need a preliminary design. But the design effort is still in the planning stages, and a design doesnt yet exist.

45Metode avansate de planificare si analiza a proiectelorListe de task-uri detaliate (wbs work breakdown structures)

Sursa Exemplu: Richard Bechtold, Essentials Of Software Project Management (Section 17), Management Concepts Inc., 1999Developing Intermediate Plans Richard Bechtold, Essentials Of Software Project Management (Section 17), Management Concepts Inc., 1999

46Metode avansate de planificare si analiza a proiectelorListe de task-uri detaliate (wbs work breakdown structures)

O intrebare esentiala in dezvoltarea listei de task-uri detaliate este urmatoare: Pana la ce nivel trebuiesc descompuse activitatile?Ideea care se urmareste este urmatoarea: la nivelul cel mai de jos, o activitate nu poate fi spre exemplu terminata in procent de 50%. Aceasta trebuie sa fie atat de simpla astfel incat sa nu se poata spuna despre ea decat ca este fie 0% sau 100% realizata.Exemple: pentru proiectele ce dureaza intre 4 si 12 luni, activitatile trebuiesc descompuse in general pana cand nivelul cel mai de jos reprezinta aproximativ 1 sau 2 saptamani de munca; pentru proiectele mai lungi se paote ajunge si pana la 4 si chiar 8 saptamani

Developing Intermediate Plans Richard Bechtold, Essentials Of Software Project Management (Section 17), Management Concepts Inc., 199947Metode avansate de planificare si analiza a proiectelorListe de resurse detaliate (Rbs Resource breakdown structures)

Sunt similare listelor de task-uri detaliate, dar se refera la organizatie, echipa de dezvoltatori si personalul implicat in realizarea produsului

Relatia cea mai importanta ce este documentata prin intermediul RBS estea aceea a autoritatii: cine raspunde in fata cui si cine spune cui ce sa faca

Nu este importanta pozitia in cadrul organizatiei a fiecarui individ in parte (se urmareste documentarea faptului ca angajatul X raspunde in fata managerului Y, indiferent daca X este secretara, unul dintre programatori sau un alt manager)

Developing Intermediate Plans Richard Bechtold, Essentials Of Software Project Management (Section 17), Management Concepts Inc., 1999

A resource breakdown structure is similar to a work breakdown structure. However, resource breakdown structures focus on the organizations, divisions, programs, projects, teams, and individuals who will be performing the work.

A common problem with resource breakdown structures is the issue of a given person reporting to someone but not having the same level of authority that other people who report to that person have. For example, a resource breakdown structure may show a secretary reporting to an executive manager. Several project managers also report to the executive manager. With regard to diagrams of resource breakdown structures, most companies employ a rather confusing convention of solid lines meaning one thing, dotted lines meaning something else, double lines indicating yet another relationship, etc. In short, the organizational relationships of who manages whom, who reports to whom, and who supports whom become highly confusing.

When you develop a resource breakdown structure for your project, keep it simple and clear. The most important relationship to document is who has authority to tell someone else what to do. It is far less important to show that person x has a secretary, or that person y provides a quarterly report to person x. Ideally, a resource breakdown structure will effectively duplicate the abstraction levels of a work breakdown structure. For example, if the work breakdown structure shows four levels of product abstraction (that is, the smallest instances of a work package are only four levels removed from the overall system), then it is helpful if the resource breakdown structure shows a similar decomposition. That is, for this example, the individual software engineers, or the smallest teams, are only four levels removed from the top of the overall development organization.48

Planificare

Analiza riscurilor

Inginerie

Evaluarea clientului

Colectarea cerinelor

iniiale i planificarea

proiectului

Planificare bazat

pe comentariile

clientului

Evaluarea clientului

Analiz de risc

bazat pe cerinele

iniiale

Analiz de risc

bazat pe reacia

clientului

Decizie go, no-go

Spre un sistem

complet

Prototipul iniial

Urmtorul prototip

Produsul final

Colectarea cerinelor

i rafinarea lor

Proiectare

rapid

Construirea

prototipului

Evaluarea prototipului

de ctre client

Rafinarea

prototipului

Realizarea

produsului

Start

Stop

Colectarea

cerinelor

Strategie de

proiectare

Implementare

folosind 4GL

Testare