Capability Maturity Model Integration

Nume:
Ureche Mihai
Cotoc Ginel-Dragos
Grupa:
443A

Cuprins
1) Introducere
2) Cele cinci nivele ale procesului de maturitate
3) Definitia operational a capabilitatii modelului de maturitate
4) Directii viitoare ale CMM
5) Concluzii

1. Introducere

Dupa doua decenii de promisiuni neonorate cu privire la cresterile de productivitate si de

calitate de la aplicarea unor noi metodologii de software si tehnologii, organizatiile isi dau seama ca
problema lor fundamental este incapacitatea de a gestiona procesul de software. In multe
organizatii, proiectele sunt adesea intarziate si depasesc bugetul si de asemenea beneficiile unor
metode mai bune si instrumente nu pot fi realizate in cadrul unui proiect nedisciplinat, haotic.
In Noiembrie 1986, Institutul de Inginerie Software (SEI), cu asistenta din partea Corporatiei
Mitre, au inceput dezvoltarea unui framework care au ajutat organizatiile sa isi imbunatateasca
procesul software. In septembrie 1987, SEI a lansat o scurta descriere a framework-ului de
maturitate a procesului, care a fost extins ulterior in cartea lui Humphrey, Gestionarea Procesului
de Software.Doua metode, procesul de evaluarea a programelor de software si capacitatea de
evaluare si un chestionar de maturitate au fost dezvoltate pentru a evalua procesul de maturitate
software.
Dupa patru ani de experimentare cu framework-ul de maturitate al proceselor de software si
versiunile preliminarii ale chestionarului de maturitate, SEI a evoluat framework-ul de maturitate in
Capability Maturity Model for Software (CMM). CMM prezinta seturi de practice recomandate intro serie de domenii cheie care si-au dovedit capacitatea de a consolida procesul de software. CMM
se bazeaza pe cunostintele dobandite de la evaluarile procesului de software si feedback extinse atat
din industrie cat si din guvern.
Capability Maturity Model pentru Software ofera organizatiilor de software indrumari privind
modul de a obtine controlul proceselor lor pentru dezvoltarea si intretinerea software si cum sa
evolueze spre o cultura de inginerie software si excelenta in management. CMM a fost dezvoltat
astfel incat sa ofere indrumare organizatiilor de software in procesul de selectarea a strategiilor de
ameliorare prin determinarea maturitatii procesului curent si identificarea a catorva aspecte mai
critice privind calitatea software-ului si imbunatatirea procesului. Concentrandu-se asupra unui set
limitat de activitati si lucru agresiv pentru a le atinge, o organizatie poate imbunatati in mod
constant procesul de software la nivel de organizatie, pentru a permite castiguri continue si de
durata in procesul de dezvoltare software.
Versiunea 1.0 a CMM a fost revizuita si utilizata de catre comunitatea software in timpul
anului 1991 si 1992. Un atelier de lucru a fost tinut in aprilie 1992 pentru versiune 1.0 a CMM, si a
fost asteptat de aproape 200 de specialist software. Versiunea curenta a CMM 1.1, este rezultatul
feedback-urilor din cadrul atelierului de lucru si a feedback-urilor venite din cadrul comunitatii
software.
1.1 Organizatii de software imature versus mature
Stabilirea obiectivelor pentru procesul de imbunatatire necesita o intelegere a diferentei dintre
organizatiile de software imature si mature. Intr-o organizatie de software imatura, procesele
software sunt in general improvizate de practicieni si de gestionarea acestora pe parcursul
proiectului. Chiar daca procesul software a fost specificat, nu este riguros urmat si aplicat.
Organizatia de software imatura este reactionara, iar managerii sunt de obicei concentrati sa resolve
crizele de moment. Termenele si bugetele sunt in mod obisnuit depasite deoarece nu sunt bazate pe

o estimare realistica. 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.
Pe de alta parte, o organizatie de software matura poseda o abilitate la nicel 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.
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.
1.2 Conceptele fundamentale ce stau la baza proceselor de maturitate
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.
Performanta proceselor software reprezinta rezultatele actuale obtinute urmand procesul
software. Astfel, performanta proceselor software sunt concentrate pe rezultatele obtinute, in timp
ce capabilitatea proceselor software sunt concentrate pe rezultatele asteptate.
Maturitatea proceselor software este masura in care un process specific este explicit definit,
gestionat, masurat, controlat si eficient. Maturitatea implica un potential de crestere in capabilitate
si indica atat imbogatirea proceselor software organizationale cat si consistenta cu care sunt aplicate
in proiectele din intreaga organizatie.
2.

Cele cinci nivele ale procesului software de maturitate

Imbunatatirea continua a procesului se bazeaza pe pasi mici mai degraba decat inovatii
revolutionare. Structura CMM-ului se bazeaza pe principii de calitate expuse de catre Walter
Shewart, W. Edwards Deming, Joseph Juran si Philip Crosby. CMM ofera un framework folosit
pentru organizarea acestor etape evolutive in cinci niveluri de maturitate care pun bazele succesive

pentru imbunatatirea continua a proceselor. Aceste cinci nivele definesc o scara ordinala pentru
masurarea maturitatii proceselor unei organizatii de soft si pentru evaluarea capacitatii procesului
software.
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 stabiliste diferite componente in procesul software, rezultand cresterea procesului de
capabilitate a organizatiei.
Organizarea CMM in cinci niveluri prezentate in figura urmatoarea 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.

2.1 Caracterizarea comportamentelor nivelelor de maturitate

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.
2.1.1 Nivelul 1 Nivelul de initializare
La nivelul initial, organizatia de obicei nu ofera un mediu stabil pentru dezvoltarea si
mentinerea software. In timpul unei crize, proiectele de obicei abandoneaza procedurile planificate
si revin la codificare si testare. Succesul depinde in totalitate de a avea un manager exceptional si o
echipa de soft eficienta. Ocazional, manageri capabili care pot rezista presiunilor de a lua decizii
rapide pentru procesul software; dar atunci cand acestia vor parasi proiectul, influenta lor
stabilizatoare va pleca cu ei. Chiar si un process de inginerie pruternic nu poate depasi instabilitatea
creata de absenta practicilor manageriale.
In ciuda acestui ad hoc, chiar haotic, organizatiile de nivel 1 dezvolta frecvent produse ce
functioneaza , chiar daca acestea depasesc bugetul si termenul limita. Succesul in organizatiile
nivelului 1 depinde de competenta si eroismul oamenilor din organizatie si nu pot fi repetate decat
daca aceleasi persoane competente sunt atribuite la urmatorul proiect. Astfel capabilitatea nivelului
1 este caracateristica fiecarui individ nu organizatiei.
2.1.2 Nivelul 2 Nivelul de repetabilitate
La nivelul repetabil, politicile de gestionare a proiectului software si procedurile pentru a
implementa aceste politici sunt stabilite. Planificarea si gestionarea de noi proiecte se bazeaza pe
experienta cu proiectele similare. Capacitatea proceselor este consolidate prin stabilirea proceselor
de gestionare de baza dintr-un proiect. Un process eficace poate fi caracterizat ca unul care este
practicat, documentat, instruit, masurat si capabil sa fie imbunatatit.
Proiectele organizatiilor de nivel 2 au instalat software-ul de control de baza de management.
Angajamentele realiste ale proiectului se bazeaza pe rezultatele observate la proiectele anterioare si
cu privire la cerintele proiectului curent. Managerii de soft urmaresc costurile softului, termenele
limita si functionalitatea; problemele in indeplinirea sarcinilor sunt identificate atunci cand acestea
apar. Cerintele software si produsele dezvoltate pentru a le satisface sunt de baza, si integritatea lor
este controlata. Standardele proiectului software sunt definite, iar organizatia se asigura ca sunt
indeplinite in totalitate. Standardele proiectului software sunt definite, iar organizatia garanteaza ca
ecestea sunt urmate in totalitate.
Procesele pot diferi intre proiecte intr-o organizatie de nivel 2. Cerintele organizationale
pentru a atinge nivelul 2 sunt acelea ca exista politic ice ghideaza proiectele stabilind cele mai
adecvate procese de management.
Capabilitatea procesului software a organizatiilor de nivelul 2 pot fi insumate ca fiind
disciplinate deoarece planificarea si urmarirea proiectului software este stabil si astfel succesele
anterioare pot fi repetate. Procesul de proiect se afla sub controlul efectiv al unui sistem de
management, urmand planuri realiste bazate pe performanta proiectelor anterioare.

2.1.3 Nivelul 3 Nivelul de definitie

La nivelul definit, procesul standard pentru dezvoltarea si mentinerea soft-ului din intreaga
organizatie este documentat, incluzand atat procesele de inginerie software cat si cele de
management, iar aceste procese sunt integrate intr-un intreg coerent. Acest proces standard este
mentionat in intreaga CMM ca procesul de organizare a software-ului standard. Procesele stabilite
la nivelul 3 sunt folosite pentru a ajuta managerii de soft si personalul tehnic pentru a efectua
procese mai eficiente. Organizatia exploateaza practici eficiente de inginerie software cand
standardizeaza procesele software. Exista un grup care este responsabil cu organizarea activitatilor
proceselor software, de exemplu un grup de ingineri de soft, sau SEPG. Un program de formare la
nivel de organizatie este pus in aplicare pentru a se asigura ca personalul si managerii au
cunostintele necesare pentru a indeplini rolurile asignate.
Proiectele adapteaza procesele organizatorice de software standard astfel incat sa se fie
dezvoltate propile procese de software definite, care sunt asignate pentru caracteristicile unice ale
proiectului. Aceste procese adaptate sunt mentionate in CMM ca procese de software de proiect
definite. Un process software definit contine un set coerent, integrat de procese de inginerie
software si manageriale. Un process bine definit poate fi caracterizat incluzand criteriile de
pregatire, intrari, standardele si procedurile pentru efectuarea lucrarilor, mecanismele de verificare a
iesirilor si criteriul de finalizare. Deoarece procesul software este bine definit, conducerea are o
incredere buna in in progresul tehnic pe toate proiectele.
Capacitatea proceselor software ale organizatiilor de nivel 3 pot fi insumate ca standard si
consistente deoarece atat activitatile ingineriei software cat si cele manageriale sunt stabile si
repetabile. Aceasta capabilitate a proceselor se bazeaza pe o intelegere comuna, la nivelul intregii
organizatii a activitatilor, rolurilor si responsabilitatile intr-un process de software definit.
2.1.4 Nivelul 4 Nivelul de gestiune
La nivelul gestionat, organizatia stabileste obiectivele calitative atat pentru produsele software
cat si pentru procese. Productivitatea si calitatea sunt masurate pentru activitatile importante ale
procesului de software pentru toate proiectele, ca parte a unui program organizational de masurare.
Procesele software sunt integrate cu o masurare bine definita si consistent la nivelul 4. Aceste
masuratori stabileste cantitatea fundamentala pentru evaluarea proceselor software a proiectelor si
produselor.
Proiectele obtin controlul asupra produselor lor si proceselor prin ingustarea variatiei in
procesul de performanta pentru a se incadra in limitele acceptabile cantitative. Variatii semnificative
in procesele de performanta pot fi distinse de variatia random (zgomot), in special in liniile de
produse stabilite.
Procesele de capabilitate software a organizatiilor de nivel 4 pot fi insumate ca fiind
cuatificabile si previzibile deoarece procesele sunt masurate si functioneaza in limite masurabile.
Acest nivel de capabilitate permite unei organizatii sa anticipeze tendintele in procese si calitatea
produsului. Deoarece procesele sunt atat stabile cat si masurabile, atunci cand unele circumstante

exceptionale se produc, cauza speciala de variatie poate fi identificata si abordata. Cand limitele
cunoscute ale proceselor sunt depasite, se iau masuri pentru a corecta aceasta situatie.
2.1.5 Nivelul 5 Nivelul de optimizare
La nivelul de optimizare, toata organizatia este concentrata pe procesul continuu de
imbunatatire. Organizatia are ca scop identificarea punctelor slabe si sa consolideze procesul de
productivitate, cu scopul de a preveni aparitia de defecte. Datele privind eficacitate procesului de
software este utilizat pentru a efectua analize cost-beneficiu a noilor tehnologii sis a propuna
modificari la procesul de software al organizatiei. Inovatii care exploateaza cele mai bune practice
de inginerie software sunt identificate si transferate in intreaga organizatie.
Echipele de proiect software in organizatiile de nivel 5 analizeaza defectele si determina
cauzele sale. Procesele software sunt evaluate pentru a preveni tipurile cunoscute de defecte din
recurenta, si lectiile invatate sunt disseminate si la alte proiecte.
Aici exista pierderi cronice, in forma de reprelucrare in orice sistem datorita variatilor
random. Pierderile sunt inacceptabile; sunt organizate eforturi pentru a elimina rezultatele pierdute
in schimnbarea sistemului, exemplu : imbunatatirea procesului de schimbare a cauzelor comune
de ineficienta pentru a preveni pierderile care apar. In timp ce acest lucru este valabil la toate
nivelele de maturitate, acesta este punctual central al nivelului 5.
Capabilitatea software a proceselor a organizatiilor de nivel 5 poate fi caracterizata ca o
continua imbunatatire, deoarece organizatiile de nivel 5 fac in permanenta eforturi pentru a
imbunatatii gama de compatibilitate a proceselor, imbunatatind astfel procesele de performanta si
proiectele lor. Imbunatatirea are loc atat prin integrarea proceselor avansate in procesele existente
cat si prin inovatii folosind noi tehnologii si metode. Tehnologia si imbunatatirile proceselor sunt
planificate si gestionate ca activitati de afaceri obisnuite.
2.2 Procesul de capabilitate si predictia de performanta
Maturitatea proceselor software ale organizatiilor ajuta la anticiparea abilitatii proiectului ca
sa isi atinga obiectivele sale. Proiectele din nivelul 1 organizeaza experiente in variatii mari in
realizarea costului, termenului limita, functionalitatii, si obiectivelor de calitate. Asa cum este
ilustrat in Figura 2.4, trei imbunatatiri sunt intalnite in atingerea obiectivelor ca procese mature de
software ale organizatiei. Aceste asteptari sunt bazate pe rezultatele proceselor de imbunatatire care
au fost atinse in alte industrii, si acestea sunt in concordant cu rezultatele initiale raportate in studiul
de caz din organizatiile de software.
In primul rand, odata cu cresterea maturitatii, diferenta dintre rezultatele asteptate si
rezultatele actuale scade in cadrul proiectelor.
In al doilea rand, odata cu cresterea maturitatii, variabilitatea rezultatelor actuale din jurul
rezultatelor asteptate scade. De exemplu, in organizatiile de nivel 1 livrarea de date pentru proiecte
de dimensiuni similare este imprevizibila si variaza foarte mult. Similar pentru proiecte dintr-o
organizatie cu un nivel de maturitate ridicat, cu toate acestea, vor fi livrate cu un interval mai mic.

In al treilea rand rezultatele vizate imbunatatesc astfel incat maturitatea organizatiei creste.
Astfel atunci cand o organizatie de software se maturizeaza, costurile se diminueaza, timpul de
dezvoltare devine mai scurt, si productivitatea si calitatea cresc. Intr-o organizatie de nivel 1, timpul
de dezvoltare poate fi destul de lung deoarece cantitatea de reprelucrare trebuie efectuata pentru a
corecta erorile. In schimb, organizatiile cu un nivel de maturitate ridicat au crescut eficienta
procesului si pentru ca au redus reprelucrarea costisitoare, timpul de dezvoltare a devenit mai mic. (
Acest lucru este ilustrat in Figura 2.4 prin deplasarea orizontala a liniei tinta fata de origine )
Imbunatatirile estimate in rezultatele proiectului reprezentat in Figura 2.4 presupune ca
rezultatele proiectului software devin mai previzibile, precum zgomotul, adesea sub forma de
reprelucrare este eliminat din procesul de software. Chiar si in cazul sistemelor fara precedent,
practicile caracteristice de management si inginerie a mai multor organizatii mature contribuie la
identificarea si solutionarea problemelor mai devreme in ciclu de dezvoltare decat ar fi fost
detectate in organizatiile mai putin mature. In unele cazuri, un process matur inseamna ca erorile
proiectelor sunt identificate mai devreme in ciclul de viata al soft-ului si investitia intr-o cauza
pierduta este minimizata.
Studiile ce caz documentate ale procesului de imbunatatire a softului indica faptul ca exista
imbunatatiri semnificative atat in calitate cat si productivitate ca urmare a efortului de imbunatatire.
Randamentul investitiilor pare a fi de obicei in intervalul 5:1 la 8:1 pentru eforturile de imbunatatire
a proceselor.

2.3 Sarind peste nivelele de maturitate

Incercarea de a sari peste nivele este contraproductiva deoarece fiecare nivel de maturitate din
CMM formuleaza o fundatie necesara folosita pentru a atinge urmatorul nivel. CMM identifica
nivelurile prin care o organizatie ar trebuie sa evolueze pentru a stabili o cultura de excelenta a
ingineriei software. Organizatiile pot institui imbunatatiri specifice peocesului, in orice moment
doresc chiar inainte ca ele sa fie pregatite pentru a avansa la nivelul la care practica specifica este
recomandata. Cu toate acestea, organizatiile trebuie sa inteleaga ca stabilitatea acestor imbunatatiri
este un risc mai mare deoarece fundatia pentru institutionalizarea lor cu success nu a fost finalizata.
Procesele fara o fundatie adecvata esueaza in punctual in care este cea mai multa nevoie de ea in
conditii de stress si ele nu ofera nici o baza pentru imbunatatirile din viitor.
De exemplu, un proces de software bine definit care este characteristic unei organizatii de
nivel 3, poate fi pusa la mare risc in cazul in care conducerea face un program de lucru prost sau
esueaza in controlarea schimbarilor cerintelor de baza. Similar, multe organizatii au colectat datele
detaliate caracteristice nivelului 4, doar pentru a afla ca datele au fost neinterpretabile din cauza
inconsecventei proceselor de dezvoltare software. In acelasi timp, trebuie recunoscut faptul ca
eforturile de imbunatatire a procesului trebuie sa se concentreze pe nevoile organizatiei, in
contextual mediului de afaceri ale sale si practicile de nivel superior se pot adresa nevoilor curente
ale unei organizatii sau proiect.

3. Definitia operational a capabilitatii modelului de maturitate

CMM este un framework ce reprezinta o cale de imbunatatire recomandata pentru
organizatiile software care vor sa isi creasca capabilitatea procesului software. Aceasta elaborare
operational a CMM este conceputa pentru a sprijini mai multe moduri ce vor fi utilizate. Sunt cel
putin patru utilizari ale CMM care sunt acceptate:

Echipele de evaluare vor folosi CMM pentru a identifica punctele forte si punctele
slabe in cadrul organizatiei

Echipele de evaluarea vor folosi CMM pentru a identifica riscurile de a alege intre
diferiti contractori pentru acordarea de afaceri si pentru a monitoriza contractele.

Managementul superior va folosi CMM pentru a intelege activitatile necesare pentru

lansarea unui process de imbunatatire a programului software in cadrul organizatiei
lor.

Personalul tehnic si grupurile de imbunatatire a proceselor, cum ar fi SEPG, vor folosi

CMM ca un ghid pentru a le ajuta sa defineasca si sa imbunatateasca procesul
software in organizatia lor.

Din cauza utilizarilor diverse ale CMM, aceasta trebuie sa fie descompusa in suficiente detalii
astfel ca recomandarile proceselor actuale pot fi derivate din structura nivelelor de maturitate.
Aceasta descompunere indica, de asemenea procesele cheie si structura lor, care caracterizeaza
procesul de maturitate software si capabilitatea de proces.

3.1 Structura interna a nivelelor de maturitate

Fiecare nivel de maturitate a fost descompus in parti constituente. Exceptie facand nivelul 1,
descompunerea fiecarui nivel de maturitate variaza de rezumatele abstracte ale nivelelor de jos pana
la definirea lor operationale in practicile cheie, asa cum este ilustrat in Figura 3.1. Fiecare nivel de
maturitate este compus din mai multe domenii cheie. Fiecare domeniu cheie este organizate in cinci
sectiuni numite trasaturi comune. Caracteristicile comune specifica practicile cheie pe care atunci
cand sunt adresate colectiv indeplinesc obiectivele din zonele proceselor cheie.

3.3 Zonele cheie ale procesului

Cu exceptia nivelului 1, fiecare nivel de maturitate este descompus n mai multe zone cheie
de procesare care indica unde o organizatie ar trebui sa se concentreze pentru a imbunatati procesul
de software. Zonele cheie ale procesului identifica problemele care trebuie sa fie adresate pentru a
atinge un nivel de maturitate.
Fiecare zona cheie a procesului identifica un grup de activitati legate de faptul ca, atunci cand
sunt efectuate in mod colectiv, ating un set de obiective considerate importante pentru marirea
capacitati procesului. Zonele cheie ale procesului au fost definite astfel incat sa sa apartina unui
nivel de maturitate unic, cum se arata in figura 3.2.
Calea spre atingerea obiectivele unei zone cheie de proces poate diferi de la proiecte bazate pe
diferentele in domeniile sau mediile de aplicabilitate. Cu toate acestea, toate obiectivele unei zone
cheie de proces trebuie realizate pentru organizatie pentru a satisface a cea zona cheie de proces.
Adjectivul "cheie" implica faptul c exista zone de proces (si procese) care nu sunt esentiale
pentru a atinge un nivel de maturitate. CMM nu descrie in detaliu toate zonele de procesare care
sunt implicate cu dezvoltarea si mentinerea software-ului. Anumite zone de proces au fost
identificate ca cheie determinante a capacitati de proces; acestea sunt cele descrise in CMM.
Zonele cheie ale procesului poat fi considerate ca fiind cerintele pentru atingerea unui nivel de
maturitate. Pentru a atinge un nivel de maturitate, zonele cheie ale procesului pentru acel nivel
trebuie sa fie indeplinite.

Practicile specifice care urmeaza sa fie executate in fiecare zona cheie de proces va evolua ca
organizatia sa atinga nivele mai ridicate ale procesului de maturitate. De exemplu, multe dintre
capacitatile estimate ale proiectului descrise in cadrul Planificari Proiectului Software: zonele cheie
de proces de la nivelul 2 trebuie sa evolueze pentru a face fata datelor suplimentare ale proiectului
disponibile la nivelul 3, astfel cum este descris in Managementul Software Integratat.
Zonele cheie ale procesului la nivelul 2 se concentreze asupra proiectului software referitoar
la stabilirea unor controale de management de baza de proiect.
Scopul Cerintelor de Management este de a stabili un cadru comun de intelegere intre
client si proiectul de software legat de cerintele clientului, care vor fi abordate de catre
proiectul de software.Acest acord cu clientul este baza pentru planificarea si
gestionarea proiectului software.
Scopul Planificari Proiectului Software este de a stabili planuri rezonabile pentru
efectuarea de inginerie software si pentru gestionarea proiectului software. Aceste
planuri sunt fundamentul necesare pentru gestionarea proiectului software.
Scopul Urmariri si Supravegheri Proiectului Software este de a stabili vizibilitate
corespunzatoare in progresul actual, astfel ca managementul sa poata lua actiuni
eficiente atunci cand performanta proiectului software se abate in mod semnificativ de
planurile de software.
Scopul Managementului de Subcontract Software este de a selecta subcontractori
software calificati si sa ii gestioneze in mod eficient .
Scopul Asigurarii Calitatii Software este de a oferi management cu o vizibilitate
adecvata in proces care este utilizat de proiectul software si a produselor care sunt
construite.
Scopul Managementului de Configurare Software este de a stabili si mentine
integritatea produselor proiectului software pe parcursul cilului de viata al proiectului
software.
Zonele cheie ale procesului la nivelul 3 se adreseaza problemelor de proiectare si
organizatorice,pe masura ce organizatia stabileste o infrastructura care institutionalizeaza ingineria
software eficient si procesele de management in toate proiectele.
Scopul Concentrari Procesului Organizatiei este de a stabili responsabilitatea de
organizare pentru activitatile procesului de software care sa imbunatateasca
capacitatea procesului de software la nivel de organizatie globala.
Scopul Definiri Procesului Organizatiei este de a dezvolta si mentine un set utilizabil
de active ale procesului de software care sa imbunatateasca performanta procesului pe
proiecte si ofera o baza pentru definirea datelor semnificative pentru managementul
cantitativ al procesului. Aceste active ofera un fundament stabil care poate fi
institutionalizat prin intermediul unor mecanisme cum ar fi formarea.
Scopul Programului de Instruire este de a dezvolta abilitatile si cunostintele de
persoane astfel incat sa poata indeplini rolurile lor efectiv si eficient. Instruirea este o
responsabilitate de organizare, dar proiectele software ar trebui sa identifice
competentele necesare si sa furnizeze instruirea necesara
atunci cand nevoile proiectului sunt unice.
Scopul Managementului Software Integrat este de a integra
ingineria software si activitatile de management intr-un proces software coerent,
definit care este adaptat de la organizatia standard a procesului de software si a

activelor aferente procesului. Acesta adaptare se bazeaza pe mediului de afaceri si pe

nevoile tehnice ale proiectului.
Scopul Ingineriei Produsului Software este de a efectua in mod constant un proces de
inginerie bine definit care integreaza toate activitatile de inginerie software pentru a
produce produse software corecte, coerente in mod efectiv si eficient. Ingineria
Produsului Software descrie activitatile tehnice ale proiectului, de exemplu, cerintele
de analiza, proiectare,cod, si de testare.
Scopul Coordonari Intergrup este de a stabili un mijloc pentru ca grup de inginerie
software sa participe in mod activ cu alte grupuri de inginerie astfel ca proiectul sa fie
in masura sa satisfaca in mod efectiv si eficient nevoile clientului.
Scopul Examinari Egale este de a elimina defectele devreme si eficient de la locul de
de functionare al produselor software. Un efect corolar important este de a dezvolta o
mai buna intelegere a produselor software de lucru si a defectelor care pot fi prevenite.
Peer review este o metoda de inginerie importanta si eficienta care poate fi
implementata prin intermediul inspectiilor, parcurgerilor structurate, sau un numar de
alte metode de examinare colegial.
Zonele cheie ale procesului la nivelul 4 se concentreza pe stabilirea unei intelegeri cantitative
atat a procesului de software cat si a produse software de lucru care sunt construite.
Scopul Managementului Procesului de Cantitate este de a controla cantitativ
performanta procesului de proiect software. Performanta procesului software
reprezinta rezultatele reale obtinute in urma urmariri unui proces de software.
Accentul se pune pe identificarea cauzelor speciale de variatie in cadrul unui proces
care poate fi stabil masurat si corectat, corespunzator, circumstantele care au condus la
aparitia variatiilor tranzitorii.
Scopul Managementului Calitati Software este de a dezvolta o ntelegerea cantitativa a
calitatii produsului software de proiect si de a atinge obiectivele specifice de calitate.
Zonele cheie ale procesului la nivelul 5 acopera problemele legate de faptul ca ambele atat
organizatia cat si proiectele trebuie sa adreseze pentru a implementa in mod continu si masurabil
imbunatatiri ale procesului software.
Scopul Preveniri Defectari este de a identifica cauzele defectelor si sa le impiedice sa
reapara. Proiectul software analizeaza defectele,identifica cauzele lor, precum si
modificarile care definesc procesul software.
Scopul de Managementului Schimbari Tehnologiei este de a identifica bebficiile
tehnologiilor noi (de exemplu, instrumente, metode, si procese) si de a le transfera in
organizatie intr-un mod ordonat. Accentul anagementului Schimbari Tehnologiei este
pe efectuarea inovatiei in mod eficient intr-o lume mereu schimbatoare.
Scopul Managementului de Schimbare al Procesului este de a imbunatati continuu
procesele de software utilizate in organizatie cu intentia de a imbunatati calitatea
software-ului, cresterea productivitatii, si scaderea timpul ciclului de dezvoltare a
produsului.
3.4 Obiective
Obiectivele rezuma cheile practice ale unei zone cheie de proces si pot fi folosite pentru a
determina daca o organizatie sau un proiect a implementat in mod eficient zona cheie de proces.
Obiectivele semnifica scopul,limitele si intentia pentru fiecare zona cheie a procesului. Satisfactia
de la un KPA este determinata de realizarea obiectivelor.

3.5 Caracteristici comune

Pentru comoditate, practicile care descriu zonele cheie de proces sunt organizate de
caracteristici comune. Caracteristici comune sunt atribute care indica implementarea si
institutionalizarea unei zone cheie de proces este eficace, repetabila, si de durata. Cele cinci
caracteristici comune sunt:
Angajamentul de a Executa
Angajamentul de a executa descrie actiunile organizatie pe care trebuie sa le ia pentru
a se asigura ca procesul este stabilit si va tine. Angajamentul de a excuta de obicei,
implica stabilirea politicilor organizationale si sponsorizarea de management senior.

Capacitatea de a Executa
Capacitatea de a Executa descrie conditiile prealabile care trebuie sa existe in proiect
sau organizatie ca sa implementeze procesul software competent. Abilitatea de a
Executa de obicei implica resurse, structuri organizatorice, si de formare.
Activitati Executate
Activitatile Executate descriu rolurile si procedurile necesare pentru a implementa o
zona cheie de proces. Activitatile Executate de obicei implica stabilirea planurilor si
procedurilor, executarea lucrarilor, si luand actiuni corective, daca este necesar.
Masurare si Analiza
Masurarea si Analiza descriu necesitatea de a masura procesul si de a analiza
masuratorile. Masurare si Analiza includ de obicei si exemple de masuratori care ar
putea fi luate pentru a determina starea si eficacitatea activitatilor efectuate.
Verificarea Implementari
Verificarea implementari descrie pasii pentru a se asigura ca activitatile sunt efectuate
in conformitate cu procesul care a fost stabilit. Verificarea de obicei cuprinde
comentari si audituri de catre managementul si software-ul de asigurare a calitatii.

Practicile din caracteristica comuna Activitati Executate descrie ceea ce trebuie sa fie
implementat pentru a stabili o capacitate de proces. Celelalte practici, luate ca un ntreg, formeaza
baza prin care o organizatie poate institutionaliza practicile descrise in caracteristica comuna
Activitati Executate.
3.6 Practici cheie
Fiecare zona cheie de proces este descrisa in termeni de cheie practica pe care contribuie la
satisfacerea obiectivelor sale. Practicile cheie descriu infrastructura si activitatile care contribuie cel
mai mult la implementarea si institutionalizarea zonei cheie de proces.
Fiecare practica cheie consta dintr-o singura propozitie, adesea urmat de o mai detaliata
descriere, care pot include exemple. Aceste practici cheie, de asemenea, mentionate in continuare ca
practicile cheie de nivel superior,stabilesc politicile fundamentale, procedurile, si activitatile pentru
zona cheie de proces. Componente descrierii detaliate sunt frecvent mentionate in continuare subpractici. Practicile cheie descriu "ce" este de facut, dar ele nu ar trebui safie interpretate ca
mandatarea "cum" ar trebui sa fie atinse obiectivele. Practicile alternative pot realiza obiectivele din
zona cheie de proces. Practicile cheie ar trebui interpretate rational sa judece daca obiectivele din
zona cheie de proces sunt eficiente, desi poate in mod diferit, atinse. Practicile cheie sunt cuprinse

in " "Key Practices of the Capability Maturity Model,Version 1.1 ", impreuna cu orientari cu privire
la interpretarea lor.

4. Directi viitoare ale CMM

Atingerea unor niveluri mai ridicate de maturitate a procesului software sunt elementare si
necesita un angajament pe termen lung pentru imbunatatirea continua a proceselor. Organizatiilor
Software le pot lua zece ani sau mai mult pentru a construi fundatia pentru, si o cultura orientat
spre, imbunatatirea continua a proceselor. Desi un deceniu-lung programul de imbunatatire a
procesului este strain celor mai multe companii din SUA, acest nivel de efort este necesar pentru a
produce organizatii software mature.
CMM nu este un glont de argint si nu abordeaza toate aspectele care sunt important pentru
proiectele de succes. De exemplu, CMM in prezent nu apeleaza la expertiza in domenii de
aplicabilitate speciale, specifice tehnologiilor software, sau sa sugereze cum sa selecteze, angajeze,
motiveze, si sa pastreze persoane competente. Desi aceste aspecte sunt cruciale pentru succesul unui
proiect, ele nu au fost integrati in CMM.
In urmatorii cativa ani, CMM va continua sa efectueze teste extinse prin utilizarea in procesul
de software evaluari, evaluarile capacitati de software,si imbunatatirea procesului de programe.
Produse pe baz de CMM si materiale de formare vor fi dezvoltate si revizuite, dupa caz. CMM este
un document viu care va fi mbunatatit, dar se anticipeaza ca CMM v1.1 va ramane de referinta pana
in 1996. Aceasta ofera un exhilibru adecvata si realist intre nevoile de stabilitate si de imbunatatire
continua. O carte despre CMM este n curs de scriere pentru seria SEI publicate de Addison-Wesley.
SEI , de asemenea, lucreaza cu Organizatia Internaionala de Standardizare (ISO) in eforturile
sale de a construi standardele internationale de evaluare a procesului de software, imbunatatire, si
capacitatea de evaluare. Acest efort va integra concepte de la mai multe metode diferite folosite in
procesul de imbunatatire. Dezvoltarea Standardelor ISO (si contributiile de la alte metode) vor
influenta CMM v2.0, chiar ca activitatea SEI va influenta procesul de activitate ISO.

5. Concluzii
CMM reprezinta un "simt comun de inginerie" care abordeaza imbunatatirea procesului
software. Nivelurile de maturitate, zonele cheie de proces, caracterisitcile comune,si practicile cheie
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
probabilitatea cu eforturilor de imbunatatire a procesului software.
CMM ofera o structura conceptuala pentru imbunatatirea managementului si dezvoltarea de
produse software intr-un mod disciplinat si consecvent. Aceasta nu garanteaza ca produsele
software vor fi construite cu succes sau ca toate probleme in ingineria software vor fi rezolvate in
mod corespunzator. Cu toate acestea, rapoarte curente de programe imbunatatite pe baza de CMM
indica faptul ca se poate imbunatati care o organizatie de software poate atinge obiectivele privind
costul sau,calitatea, si productivitatea. [Dion92, Humphrey91b, Lipke92, Wohlwend93].
CMM identifica practici pentru un proces de software matur si ofera exemple de state-of-thepractice (si, in unele cazuri, state-of-the-art), dar aceasta nu este menit sa fie exhaustiv sau
dictatorial. CMM identifica caracteristicile unui proces eficace de software, dar organizatia matura

abordeaza toate aspectele esentiale pentru un proiect de succes, inclusiv oameni si tehnologie,
precum si procesul.