---
tags: wiki
---

# CMM - Fejlettségi-érettségi modell

[CMM-tanúsítvány](https://www.emi.hu/emi/web.nsf/Pub/emi_tanusitvanyok.html)
[CMMI a Wikipediában](https://hu.wikipedia.org/wiki/CMMI)

A **CMMI** (**C**apability **M**aturity **M**odel **I**ntegration) egy szoftverfolyamat-fejlesztési modell, mely két megközelítésben (lépcsős és folytonos) mutatja meg az IT folyamatokat.

## A CMMI modell a következő megközelítéseket integrálja

- Capability Maturity Model for Software (SW-CMM) v2.0 draft C,
- Electronic Industries Alliance Interim Standard (EIA/IS) 731, Systems Engineering Capability Model (SECM),
- Integrated Product Development Capability Maturity Model (IPD-CMM) v0.98,
- A modell az ISO/IEC 15504 Technical Report for Software Process Assessment-ben leírt modellel, vagyis a SPICE modellel is kompatibilis.

A CMMI modell a szoftverfejlesztésben (SW), rendszerszervezés- és fejlesztésben (SE), integrált termék- és folyamatfejlesztésben (IPPD) alkalmazható.

**A modell (1-5) érettségi szintet és (0-5) képességi tartományt definiál.**

### Érettségi szintek lépcsős megközelítése
1. Initial – Kezdeti
2. Managed – Menedzselt
3. Defined – [Definiált](https://wikiszotar.hu/ertelmezo-szotar/Defini%C3%A1l), dokumentált, meghatározott
4. Quantitatively Managed – Mennyiségileg menedzselt
5. Optimizing – Optimalizált

### Képességi szintek folytonos megközelítése
1. Incomplete – Befejezetlen
2. Performed – Végrehajtott
3. Managed – Menedzselt
4. Defined – Definiált
5. Quantitatively Managed – Mennyiségileg menedzselt
6. Optimizing – Optimalizáló

A CMMI modell auditálását a [SCAMPI](https://hu.wikipedia.org/wiki/SCAMPI "SCAMPI") (**S**tandard **C**MMI **A**ppraisal **M**ethod for **P**rocess **I**mprovement) módszer biztosítja.

---

A **Capability Maturity Model** ( **CMM** ) egy fejlesztési modell, amelyet 1986-ban hoztak létre a kutatást finanszírozó [amerikai védelmi minisztériummal](https://en.wikipedia.org/wiki/U.S._Department_of_Defense "Amerikai Védelmi Minisztérium") szerződött szervezetektől származó adatok tanulmányozása után . Az „érettség” kifejezés a folyamatok formalitásának és [optimalizálásának](https://en.wikipedia.org/wiki/Optimization "Optimalizálás") fokára vonatkozik , _[az ad hoc](https://en.wikipedia.org/wiki/Ad_hoc "Ehhez")_ gyakorlatoktól a formálisan meghatározott lépéseken át, a kezelt eredménymutatókon át a folyamatok aktív optimalizálásáig.

[A modell célja a meglévő szoftverfejlesztési](https://en.wikipedia.org/wiki/Software_development "Szoftverfejlesztés") folyamatok javítása , de más folyamatokra is alkalmazható.

[2006-ban a Carnegie Mellon Egyetem](https://en.wikipedia.org/wiki/Carnegie_Mellon_University "Carnegie Mellon Egyetem") Szoftvermérnöki Intézete kifejlesztette a [Capability Maturity Model Integration-t](https://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration "Képesség-érettségi modell integrációja") , amely nagymértékben felváltotta a CMM-et, és kiküszöböli annak néhány hátrányát.

## Áttekintés

_A képesség-érettségi modellt eredetileg úgy fejlesztették ki, hogy objektíven felmérjék a kormányzati vállalkozók folyamatainak_ képességét egy szerződéses szoftverprojekt megvalósítására. A modell a folyamatérettségi keretrendszeren alapul, amelyet először _[az IEEE Software](https://en.wikipedia.org/wiki/IEEE_Software "IEEE szoftver")_, majd később a Managing the Software Process_ by [Watts Humphrey](https://en.wikipedia.org/wiki/Watts_Humphrey "Watts Humphrey") , 1989-es könyv ír le . Később 1993-ban egy jelentésben [[3]](https://en.wikipedia.org/wiki/Capability_Maturity_Model#cite_note-sei93cmm-3) , 1995-ben pedig ugyanezen szerzők könyveként adták ki.

[Bár a modell a szoftverfejlesztés](https://en.wikipedia.org/wiki/Software_development "Szoftverfejlesztés") területéről származik , általában az üzleti folyamatokat segítő modellként is használják, és világszerte széles körben alkalmazzák a kormányhivatalokban, a kereskedelemben és az iparban. [[4]](https://en.wikipedia.org/wiki/Capability_Maturity_Model#cite_note-McKay-4) [[5]](https://en.wikipedia.org/wiki/Capability_Maturity_Model#cite_note-5)

## Története

### Előzetes igény a szoftverfolyamatokra

Az 1980-as években a számítógépek használata egyre elterjedtebbé, rugalmasabbá és olcsóbbá vált. A szervezetek megkezdték a számítógépes információs rendszerek bevezetését, és jelentősen megnőtt a [szoftverfejlesztés iránti igény.](https://en.wikipedia.org/wiki/Software_development "Szoftverfejlesztés") A szoftverfejlesztés sok folyamata gyerekcipőben járt, kevés szabványos vagy „ [legjobb gyakorlat](https://en.wikipedia.org/wiki/Best_practice "Legjobb gyakorlat") ” megközelítést határoztak meg.

[Ennek eredményeként a növekedést növekvő fájdalmak kísérték: gyakori volt a projektek kudarca, a számítástechnika](https://en.wikipedia.org/wiki/Computer_science "Számítástechnika") területe még a kezdeti években járt, a projektek léptékére és összetettségére vonatkozó ambíciók pedig meghaladták a piac azon képességét, hogy a tervezett költségvetésen belül megfelelő termékeket szállítsanak. Olyan személyek, mint [Edward Yourdon](https://en.wikipedia.org/wiki/Edward_Yourdon "Edward Yourdon") , [Larry Constantine](https://en.wikipedia.org/wiki/Larry_Constantine "Larry Constantine") , [Gerald Weinberg](https://en.wikipedia.org/wiki/Gerald_Weinberg "Gerald Weinberg") , [Tom DeMarco](https://en.wikipedia.org/wiki/Tom_DeMarco "Tom DeMarco") , és [David Parnas](https://en.wikipedia.org/wiki/David_Parnas "David Parnas") kutatási eredményeket tartalmazó cikkeket és könyveket kezdtek publikálni, hogy megpróbálják professzionalizálni a szoftverfejlesztési folyamatokat.

Az 1980-as években számos amerikai katonai projekt, amelyben szoftveralvállalkozók vettek részt, túllépték a költségvetést, és a tervezettnél jóval később fejeződtek be, ha egyáltalán. Annak érdekében, hogy meghatározzák ennek okát, az [Egyesült Államok légiereje](https://en.wikipedia.org/wiki/United_States_Air_Force "Egyesült Államok légiereje") finanszírozott egy tanulmányt a Software Engineering Institute-ban (SEI).

### Előélete

A szakaszos érettségi modellt először nem a CMU/SEI alkalmazta az IT-re, hanem [Richard L. Nolan](https://en.wikipedia.org/wiki/Richard_L._Nolan "Richard L. Nolan") , aki 1973-ban publikálta az IT-szervezetek [növekedési modelljének szakaszait .](https://en.wikipedia.org/wiki/Stages_of_growth_model "A növekedési modell szakaszai")

[Watts Humphrey](https://en.wikipedia.org/wiki/Watts_Humphrey "Watts Humphrey") az IBM-nél 27 éves pályafutása későbbi szakaszában kezdte el kidolgozni folyamatérettségi koncepcióit.

### Fejlesztés a Szoftvermérnöki Intézetben

A modell aktív fejlesztése az Egyesült Államok Védelmi Szoftvermérnöki Intézete (SEI) által 1986-ban kezdődött, amikor Humphrey csatlakozott a [Pennsylvania állambeli Pittsburgh-](https://en.wikipedia.org/wiki/Pittsburgh,_Pennsylvania "Pittsburgh, Pennsylvania") i Carnegie Mellon Egyetem [Szoftvermérnöki Intézetéhez](https://en.wikipedia.org/wiki/Software_Engineering_Institute "Szoftvermérnöki Intézet") , miután visszavonult az IBM-től. Az Egyesült Államok légierejének kérésére megkezdte a folyamatérettségi keretrendszer formalizálását, hogy segítse az Egyesült Államok Védelmi Minisztériumát a szoftvervállalkozók képességeinek értékelésében a szerződések odaítélésének részeként.[](https://en.wikipedia.org/wiki/Pittsburgh,_Pennsylvania "Pittsburgh, Pennsylvania")

A légierő tanulmányának eredménye egy modell volt a hadsereg számára, amelyet a szoftveralvállalkozók folyamatképességének objektív értékelésére használhat. Humphrey ezt a keretrendszert a korábbi [minőségirányítási érettségi rácsra alapozta, amelyet](https://en.wikipedia.org/wiki/Quality_Management_Maturity_Grid "Minőségirányítási érettségi rács") [Philip B. Crosby](https://en.wikipedia.org/wiki/Philip_B._Crosby "Philip B. Crosby") dolgozott ki „A minőség ingyenes” című könyvében. Humphrey megközelítése abban tért el egymástól, hogy egyedülálló belátása szerint a szervezetek a folyamatok meghatározott sorrendben történő megoldásán alapuló folyamataikat szakaszosan érlelik. Humphrey megközelítését a szervezeten belüli szoftverfejlesztési gyakorlatok rendszerének fokozatos fejlődésére alapozta, ahelyett, hogy az egyes fejlesztési folyamatok érettségét önállóan mérné. A CMM-et ezért a különböző szervezetek általános és hatékony eszközként használták az általános üzleti folyamatok teljesítményének megértéséhez, majd javításához.

[Watts Humphrey Capability Maturity Model (CMM) 1988-ban](https://en.wikipedia.org/wiki/Capability_Maturity_Model#cite_note-13) , könyvként pedig 1989-ben jelent meg _Managing the Software Process_ címmel.

A szervezeteket eredetileg a folyamatérettségi kérdőív és a Humphrey és a Szoftvermérnöki Intézet munkatársai által kidolgozott Software Capability Evaluation módszer segítségével értékelték.

A Capability Maturity Model teljes körű megjelenítése meghatározott folyamatterületek és gyakorlatok halmazaként mind az öt érettségi szinten 1991-ben kezdődött, az 1.1-es verzió 1993 januárjában készült el. [A CMM könyvként jelent meg](https://en.wikipedia.org/wiki/Capability_Maturity_Model#cite_note-sei93cmm-3) 1995-ben, elsődleges szerzői, Mark C. Paulk, Charles V. Weber, [Bill Curtis](https://en.wikipedia.org/wiki/Dr_Bill_Curtis "Dr Bill Curtis") és Mary Beth Chrissis. Amerikai Egyesült Államok New York, USA.

### Képesség-érettségi modell integrációja

A CMM-modell szoftverfejlesztésben való alkalmazása néha problémás volt. Több olyan modell alkalmazása, amelyek nincsenek integrálva egy szervezeten belül, költséges lehet a képzés, az értékelés és a fejlesztési tevékenységek során. A [Capability Maturity Model Integration](https://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration "Képesség-érettségi modell integrációja") (CMMI) projektet azért hozták létre, hogy megoldja a szoftverfejlesztési folyamatok több modelljének alkalmazásának problémáját, így a CMMI modell felváltotta a CMM modellt, bár a CMM modell továbbra is általános elméleti folyamatképességi modell, amelyet a szoftverfejlesztési folyamatokban használnak közkincs.

### Más folyamatokhoz igazítva

A CMM-et eredetileg arra szánták, hogy értékelje a kormányzati vállalkozók képességét egy szerződéses szoftverprojekt végrehajtására. Bár a szoftverfejlesztés területéről származik, széles körben alkalmazható, alkalmazták és alkalmazzák a _folyamatok_ (pl. [IT szolgáltatásmenedzsment](https://en.wikipedia.org/wiki/IT_service_management "IT szolgáltatás menedzsment") folyamatok) érettségének általános modelljeként az IS/IT (és más) szervezetekben.

## Modell témakörök

### Fejlettségi, érettségi modellek

Az [érettségi modellt](https://en.wikipedia.org/wiki/Maturity_model "Érettségi modell") strukturált szintek halmazának tekinthetjük, amelyek leírják, hogy egy szervezet viselkedése, gyakorlata és folyamatai mennyire képesek megbízhatóan és fenntarthatóan elérni a kívánt eredményeket.

Az érettségi modell használható viszonyítási alapként és a megértéshez – például különböző szervezetek összehasonlító értékeléséhez, ahol van valami közös, ami összehasonlítási alapként használható. Például a CMM esetében az összehasonlítás alapját a szervezetek szoftverfejlesztési folyamatai jelentenék.

### Szerkezete:

A modell öt szempontot foglal magában:

- _Érettségi szintek:_ 5-szintű folyamatérettségi kontinuum - ahol a legfelső (5.) szint egy képzeletbeli ideális állapot, ahol a folyamatokat szisztematikusan irányítanák a folyamatoptimalizálás és a folyamatos folyamatfejlesztés kombinációjával.
- _Kulcsfontosságú folyamatterületek:_ a kulcsfontosságú folyamatterület olyan kapcsolódó tevékenységek csoportját azonosítja, amelyek együttes végrehajtása során fontosnak tartott célokat érnek el.
- _Célok:_ egy kulcsfontosságú folyamatterület céljai összefoglalják azokat az állapotokat, amelyeknek létezniük kell ahhoz, hogy az adott kulcsfontosságú folyamatterület hatékonyan és tartósan megvalósuljon. A célok megvalósulásának mértéke azt jelzi, hogy a szervezet mekkora képességet hozott létre ezen az érettségi szinten. A célok az egyes kulcsfontosságú folyamatterületek hatókörét, határait és szándékát jelzik.
- _Közös jellemzők: a_ közös jellemzők közé tartoznak azok a gyakorlatok, amelyek egy kulcsfontosságú folyamatterületet valósítanak meg és intézményesítenek. Ötféle közös jellemző létezik: a teljesítmény iránti elkötelezettség, a teljesítési képesség, az elvégzett tevékenységek, mérés és elemzés, valamint a megvalósítás ellenőrzése.
- _Kulcsgyakorlatok:_ A kulcsgyakorlatok az infrastruktúra és a gyakorlat azon elemeit írják le, amelyek a leghatékonyabban járulnak hozzá a terület megvalósításához és intézményesítéséhez.

### Szintek

A modell kontinuuma mentén öt szintet határoznak meg, és a SEI szerint:
_"A szervezet szoftverfolyamatainak kiszámíthatósága, hatékonysága és ellenőrzése úgy vélik, hogy javulni fog, ahogy a szervezet feljebb lép ezen az öt szinten. Bár nem szigorúak, az empirikus bizonyítékok a mai napig alátámasztja ezt a hitet."_

1. _Kezdeti_ (kaotikus, ad hoc, egyéni heroics) - egy új vagy dokumentálatlan ismétlési folyamat használatának kiindulópontja.
2. _Megismételhető_ – a folyamat legalább kellően dokumentált ahhoz, hogy megkísérelje megismételni ugyanazokat a lépéseket.
3. _Meghatározott_ – a folyamat szabványos [üzleti folyamatként van meghatározva/megerősítve](https://en.wikipedia.org/wiki/Business_process "Üzleti folyamat")
4. _Képes_ – a folyamat mennyiségi irányítása az egyeztetett mérőszámoknak megfelelően történik.
5. _Hatékony_ – a folyamatmenedzsment magában foglalja a folyamatok szándékos optimalizálását/fejlesztését.

Ezen érettségi szinteken belül vannak kulcsfontosságú folyamatterületek, amelyek az adott szintet jellemzik, és minden ilyen területhez öt tényező tartozik: célok, elkötelezettség, képesség, mérés és ellenőrzés. Ezek nem feltétlenül egyediek a CMM-re, és képviselik azokat a szakaszokat, amelyeken a szervezeteknek át kell menniük az érettség felé vezető úton.

A modell egy elméleti kontinuumot ad, amely mentén a folyamatérettség fokozatos fejlesztése egyik szintről a másikra. A szintek átugrása nem megengedett/megvalósítható.

1. szint – _Kezdeti_

Az ezen a szinten lévő folyamatokra jellemző, hogy (jellemzően) nem dokumentáltak és dinamikus változásban vannak, és hajlamosak arra, hogy a felhasználók vagy események _ad hoc , ellenőrizetlen és reaktív módon irányítsák őket._ Ez kaotikus vagy instabil környezetet biztosít a folyamatoknak. (Példa - egy sebész, aki kis számú alkalommal hajt végre új műtétet - a negatív kimenetel szintje nem ismert).

2. szint – _Megismételhető_

Erre az érettségi szintre jellemző, hogy egyes folyamatok megismételhetők, esetleg konzisztens eredménnyel. A folyamatfegyelem valószínűleg nem lesz szigorú, de ahol létezik, segíthet a meglévő folyamatok fenntartásában a stressz idején.

3. szint – _Meghatározott_

Az ezen a szinten lévő folyamatokra jellemző, hogy meghatározott és dokumentált szabványos folyamatok halmazai vannak kialakítva, amelyek idővel bizonyos fokú javuláson esnek át. Ezek a szabványos eljárások működnek. Előfordulhat, hogy a folyamatokat nem alkalmazták szisztematikusan vagy ismételten – ez elegendő ahhoz, hogy a felhasználók hozzáértővé váljanak, vagy a folyamat számos helyzetben érvényesíthető legyen. Ez egy fejlesztési szakasznak tekinthető - szélesebb körű felhasználással és felhasználói kompetenciák fejlesztésével a folyamat a következő érettségi szintre fejlődhet.

4. szint – _felügyelt (képes)_

Az ezen a szinten lévő folyamatokra jellemző, hogy a folyamatmérők segítségével a folyamatcélok hatékony elérése bizonyítható a működési feltételek széles skáláján. A folyamat alkalmasságát több környezetben is tesztelték, és a folyamatot finomították és adaptálták. A folyamathasználók többféle és változatos körülmények között tapasztalták meg a folyamatot, és képesek bizonyítani a hozzáértést. A folyamat érettsége lehetővé teszi az egyes projektekhez való alkalmazkodást mérhető minőségi veszteségek vagy a specifikációktól való eltérések nélkül. A folyamatképesség erről a szintről jön létre. (Példa - sebész, aki több százszor hajt végre műtétet, és a negatív kimenetel szintje megközelíti a nullát).

5. szint – _Optimalizálás (hatékony)_

Az ezen a szinten lévő folyamatokra jellemző, hogy a hangsúly a folyamatok teljesítményének folyamatos javításán van, mind inkrementális, mind innovatív technológiai változtatásokkal/fejlesztésekkel. _Az 5. érettségi szinten a folyamatok a folyamatok változásainak statisztikailag gyakori okainak_ kezelésével és a folyamat megváltoztatásával (például a folyamatteljesítmény átlagának eltolásával) foglalkoznak a folyamat teljesítményének javítása érdekében. Ez a meghatározott mennyiségi folyamatfejlesztési célok elérésének valószínűségének fenntartásával egyidejűleg történne.

2008 és 2019 között az értékelések körülbelül 12%-a volt 4. és 5. szintű.

### Kritikák

A modell eredetileg az volt, hogy értékelje a kormányzati vállalkozók képességét egy szoftverprojekt végrehajtására. Erre a célra használták, és alkalmas is lehet rá, de a kritikusok rámutattak, hogy a CMM szerinti folyamatérettség nem feltétlenül kötelező a sikeres szoftverfejlesztéshez.

### Szoftverfolyamat keretrendszer

A dokumentált szoftverfolyamat-keretrendszer célja, hogy útmutatást nyújtson azoknak, akik fel akarják mérni egy szervezet vagy projekt összhangját a kulcsfontosságú folyamatterületekkel. Minden érettségi szinthez öt ellenőrzőlista-típus tartozik:

típus
Leírás

Irányelv
Leírja a kulcsfontosságú folyamatterületek által javasolt irányelvek tartalmát és KPA-céljait.
Alapértelmezett
Leírja a kiválasztott munkatermékek ajánlott tartalmát, amelyeket a Főbb folyamatterületek ismertetnek.
Folyamat
Leírja a kulcsfontosságú folyamatterületek által javasolt folyamatinformáció-tartalmat. Ezeket ellenőrzőlistákká finomítják a következőkhöz:
- Szerepek, belépési feltételek, bemenetek, tevékenységek, kimenetek, kilépési feltételek, felülvizsgálatok és auditok, kezelt és ellenőrzött munkatermékek, mérések, dokumentált eljárások, képzés és eszközök
- Eljárás: leírja a kulcsfontosságú folyamatterületek részben leírt dokumentált eljárások ajánlott tartalmát.
- Leküzdött szint: áttekintést nyújt a teljes érettségi szintről. Ezeket ellenőrző listákká finomítják a következőkhöz:
- kulcsfontosságú folyamatterületek céljai, irányelvei és szabványai;
- folyamatleírások;
- eljárások;
- kiképzés;
- szerszámok;
- felülvizsgálatok és auditok;
- munkatermékek;
- mérések