Transcript 18Ficea Cristian

CMMI
Maturitatea si Capabilitatea
proceselor si organizatiilor
Ficea Cristian 341 C5
Cupins
 Organizatii software imature vs. organizatii software mature
 Aria de proces
 Proces software
 Nivele de maturitate ale proceselor software
Organizatii software imature (I)
 Intr-o organizatie de software imatura, procesele software sunt in
general improvizate de practicieni si de gestionarea acestora pe
parcursul proiectului.
 Organizatia de software imatura este reactionara, iar managerii sunt de
obicei concentrati sa rezolve crizele de moment.
 Termenele si bugetele sunt in mod obisnuit depasite deoarece nu sunt
bazate pe o estimare realistica.
Organizatii software imature (II)
 Atunci cand sunt impuse termene de terminare, calitatea produsului si
functionalitatea sunt deseori compromise pentru a respecta termenul
limita.
 Intr-o organizatie imatura, nu exista nici un obiectiv de baza pentru
evaluarea calitatii sau pentru rezolvarea produsului sau problemelor
procesului.
 Prin urmare, este dificil de a prezice calitatea produsului.
Organizatii software mature (I)
 O organizatie de software matura poseda o abilitate la nivel de
organizatie pentru gestionarea proceselor de dezvoltare si intretinere a
soft-ului.
 Procesele software sunt comunicate in detaliu atat personalului existent
si cat noilor angajati, si activitatile de munca se desfasoara comform cu
procesele planificate.
 Rolurile si responsabilitatile in cadrul procesului definit sunt clare
dealungul proiectului si in toata organizatia.
Organizatii software mature (II)
 Intr-o organizatie matura, managerii monitorizeaza calitatea produselor
software si procesele ce le produc.
 Exista un obiectiv de baza bine stabilit pentru a califica calitatea produsului
si de a analiza probleme produsului si proceselor.
 Termenele limita si bugetele sunt bazate pe o performanta stabilita si este
realistica; rezultatele asteptate pentru cost, termenul limita, functionalitate,
si calitatea produsului sunt deobicei atinse.

In general, un proces disciplinat este urmarit indeaproape deoarece toti
participantii inteleg valoarea de a face acest lucru, si infrastructura necesara
exista pentru a sprijini procesul.
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.
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.
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).
Proces software
 Un proces software poate fi definit ca fiind un set de activitati, metode,
practice si transformari pe care oamenii le folosesc pentru a dezvolta si
mentine software-ul si produsele associate ( ex: planuri de proiecte,
documente de proiectare, codul si manuale de folosire ).

Ca o organizatie matura, procesele de software devin mai bine definite si
sunt implementat mai consistent in cadrul organizatiei.
 Capabilitatea proceselor software descrie valoarea rezultatelor
asteptate care pot fi atinse urmand procesele software.
Nivele de maturitate a proceselor software
Organizarea CMM in cinci niveluri
prezentate in figura prioritizeaza
actiuni de ameliorare pentru
cresterea procesului de
maturitate software.
Sagetile din figura indica tipul de
capacitate a procesului de a fi
institutionalizat de catre
organizatie pentru fiecare pas din
cadrul framework-ului de
maturitate.
Nivele de maturitate (I)
 Un nivel de maturitate este un platou evolutiv bine definit spre
realizarea unui proces software matur.
 Fiecare nivel cuprinde un set de obiective, care atunci cand sunt
indeplinite stabilesc o componenta importanta a procesului software.

Atingand fiecare nivel de maturitate din framework se stabilesc diferite
componente in procesul software, rezultand cresterea procesului de
capabilitate a organizatiei.
Nivele de maturitate (II)
 Nivele de maturitate de la 2 la 5 pot fi caracterizate prin activitatile
executate de catre organizatie pentru a stabili sau imbunatatii procesul
software, de catre activitatile executate in fiecare proiect, si de catre
rezultatele procesului de capabilitate din cursul proiectelor.

O caracterizare comportamentala a nivelului 1 este inclusa pentru a
stabili o baza de comparative pentru imbunatatirea proceselor de la
nivelele mai mari de maturitate.
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.
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.
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.
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.
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.
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.
Intrebari ?
Multumesc !