CMMI Maturitatea si Capabilitatea proceselor si organizatiilor

1. CMMIMaturitateasiCapabilitateaproceselorsiorganizatiilor FiceaCristian 341 C5

2. Cupins • Organizatiisoftware imaturevs. organizatii software mature • Aria de proces • Proces software • Nivele de maturitate ale proceselor software

3. Organizatii software imature (I) • Intr-o organizatie de software imatura, procesele software sunt in general improvizate de practicienisi de gestionareaacestorapeparcursulproiectului. • Organizatiade software imaturaestereactionara, iarmanageriisunt de obiceiconcentratisarezolvecrizele de moment. • Termenelesibugetelesunt in mod obisnuitdepasitedeoarece nu suntbazatepe o estimarerealistica.

4. Organizatii software imature (II) • Atuncicandsuntimpusetermene de terminare, calitateaprodusuluisifunctionalitateasuntdeseori compromise pentru a respectatermenullimita. • Intr-o organizatieimatura, nu existanici un obiectiv de bazapentruevaluareacalitatiisaupentrurezolvareaprodusuluisauproblemelorprocesului. • Prinurmare, estedificil de a prezicecalitateaprodusului.

5. Organizatii software mature (I) • O organizatie de software maturaposeda o abilitate la nivelde organizatiepentrugestionareaproceselor de dezvoltaresiintretinere a soft-ului. • Proceselesoftware suntcomunicate in detaliuatatpersonalului existent si cat noilorangajati, siactivitatile de munca se desfasoaracomform cu proceseleplanificate. • Rolurilesiresponsabilitatile in cadrulprocesuluidefinitsuntclaredealungulproiectuluisi in toataorganizatia.

6. Organizatii software mature (II) • Intr-o organizatiematura, manageriimonitorizeazacalitateaproduselor software siproceselece le produc. • Existaun obiectiv de baza bine stabilitpentru a calificacalitateaprodusuluisi de a analizaproblemeprodusuluisiproceselor. • Termenelelimitasibugetelesuntbazatepe o performantastabilitasiesterealistica; rezultateleasteptatepentru cost, termenullimita, functionalitate, sicalitateaprodusuluisuntdeobiceiatinse. • In general, un procesdisciplinatesteurmaritindeaproapedeoarecetotiparticipantiiintelegvaloarea de a face acestlucru, siinfrastructuranecesaraexistapentru a sprijiniprocesul.

7. Aria de proces (I) • Aria de proces reprezintă un pachet de practici înrudite care duc la atingerea unui set de obiective de natură managerială, tehnică sau de suport și indică acțiunile care trebuie urmate pentru atingerea acestor obiective: managementul proceselor, inginerie, managementul proiectelor și suport. • Ariile de proces fundamentale ale managementului proceselor sunt performanța procesului organizațional (OPP) și inovarea organizațională și utilizarea (OID) • Ariile de proces fundamentale ale managementului proiectelor, categorie care implică toate activitățile legate de project management, planificare și monitorizare, se referă la totalitatea activitățilorlegate de stabilirea și întreținerea angajamentelor, monitorizarea progresului și gestionarea acordurilor cu furnizorii.

8. Aria de proces (II) • Ariile de proces progresive ale categoriei managementului proiectelor sunt managementul integrat al proiectelor, dezvoltarea integrată a produselor și proceselor (IPMIPPD), managementul riscului (RSKM) și managementul cantitativ al proiectelor (QPM). Ele se referă la activitățile de stabilire a proceselor de definire din setul de procese standard ale organizației. • Ariile de proces din categoria ingineriei acoperă activitățile de dezvoltare și întreținere care se desfășoară în toate disciplinele inginerești. • Pentru a realiza dezvoltarea integrată a produselor și proceselor este necesară o abordare inginerească robustă care se bazează pe dezvoltarea în faze ale ciclului de viață al produsului.

9. Aria de proces (III) • Toate ariile de proces din categoria ingineriei au fost astfel concepute încât să permită recursivitatea pe parcursul realizării arhitecturii produsului. • Ariile de proces din categoria suport acoperă activitățile care sprijină dezvoltarea și întreținerea produsului. Ariile fundamentale ale categoriei suport sunt: managementul configurației (CM), asigurarea calității proceselor și produselor (PPQA), analiză și măsurare (MA). • Ariile de proces progresive ale categoriei suport asigură o mentenanță îmbunătățită a proiectelor și organizației. Aceste arii sunt: analiza cauzală și decizia (CAR) și analiza și stabilirea deciziei (DAR).

10. Proces software • Un proces softwarepoate fi definitcafiind un set de activitati, metode, practice sitransformaripe care oamenii le folosescpentru a dezvoltasimentine software-ulsiprodusele associate ( ex: planuri de proiecte, documente de proiectare, codulsimanuale de folosire). • Ca o organizatiematura, procesele de software devinmai bine definite sisuntimplementatmai consistent in cadrulorganizatiei. • Capabilitateaproceselor softwaredescrievaloarearezultatelorasteptate care pot fi atinseurmandprocesele software.

11. Nivele de maturitate a proceselor software OrganizareaCMM in cinciniveluriprezentate in figuraprioritizeazaactiuni de ameliorarepentrucrestereaprocesului de maturitate software. Sagetiledin figuraindicatipul de capacitate a procesului de a fi institutionalizat de catreorganizatiepentrufiecare pas din cadrul framework-ului de maturitate.

12. Nivelede maturitate (I) • Un nivel de maturitateeste un platouevolutiv bine definitsprerealizareaunuiproces software matur. • Fiecarenivelcuprinde un set de obiective, care atuncicandsuntindeplinitestabilesc o componentaimportanta a procesului software. • Atingandfiecarenivel de maturitate din framework se stabilescdiferitecomponente in procesul software, rezultandcrestereaprocesului de capabilitate a organizatiei.

14. Nivele de maturitate (II) • Nivele de maturitate de la 2 la 5 pot fi caracterizateprinactivitatileexecutate de catreorganizatiepentru a stabilisauimbunatatiiprocesul software, de catreactivitatileexecutate in fiecareproiect, si de catrerezultateleprocesului de capabilitate din cursulproiectelor. • O caracterizarecomportamentala a nivelului1 esteinclusapentru a stabili o baza de comparative pentruimbunatatireaproceselor de la nivelelemaimari de maturitate.

15. 1. Nivelul inițial (ad-hoc, imatur) • La nivelul inițial, organizația nu asigură un mediu stabil pentru dezvoltarea noilor produse: procesele de dezvoltare sunt instabile și impredictibile, deoarece ele sunt modificate în mod constant, pe măsură ce lucrările (de dezvoltare) progresează sau variază de la un proiect la altul. • Procesele nu sunt documentate, tinzând să fie conduse în manieră ad-hoc, de utilizatori și evenimente.

16. 2. Nivelul repetabil (repeatable- engl.) • La nivelul repetabil, politicile pentru managementul proiectelor de dezvoltare și procedurile de implementare a acestor politici sunt stabilite. • Unele procese, dezvoltate în proiecte anterioare sunt repetabile, posibil cu rezultate consistente.

17. 3. Nivelul definit (defined -engl.) • La nivelul definit, procesele standardizate pentru dezvoltarea noilor produse sunt documentate și definite, aceste procese sunt integrate într-un întreg coerent. • Un proces bine-definit poate fi caracterizat ca incluzând criterii de pregătire/disponibilitate, input-uri, norme și proceduri pentru efectuarea lucrărilor procesului, mecanisme de verificare (de exemplu, echipe de analiză), output-uri și criterii de terminare a procesului de dezvoltare.

18. 4. Nivelul manageriat (managed -engl.) • La nivelul manageriat, organizația stabilește metrici pentru produse și procese și măsoară rezultatele. • Proiectele realizează controlul asupra produselor și proceselor lor, prin îngustarea variației performanței acestora, pentru a se încadra în limite acceptabile. • Capabilitatea proceselor este stabilită din acest nivel.

19. 5. Nivelul optimizat (optimized -engl.) • La nivelul optimizat, întreaga organizație este focalizată pe îmbunătățirea continuă a proceselor, prin schimbări/îmbunătățiri tehnologice incrementale și inovative. • Organizația are mijloace pentru a identifica "punctele slabe" și a întări proactiv procesele, cu scopul de a preveni apariția defectelor. • Datele asupra eficienței procesului de dezvoltare sunt folosite pentru a efectua analize cost/beneficiu ale noilor tehnologii de dezvoltare și ale modificărilor propuse în procesele de dezvoltare ale organizației.

20. Concluzii • Atingerea unor niveluri mai ridicate de maturitate a procesului software sunt elementare si necesita un angajament pe termen lung pentru imbunatatirea continua a proceselor. • CMM reprezinta un "simt comun de inginerie" care abordeaza imbunatatirea procesului software. Nivelurile de maturitate au fost discutate pe larg si revizuite in cadrul comunitatii software. • In timp ce CMM nu este perfect, el nu reprezinta un larg consens al comunitatii software si este un instrument util pentru ghidarea eforturilor de imbunatatire a procesului software.

21. Intrebari ?

22. Multumesc !