Képességi lejárati modell (CMM) & ez a Szoftvertechnika szintjei

Mi a CMM?

A képességi lejárati modellt viszonyítási alapként használják a szervezet szoftveres folyamatának érettségének mérésére.

A CMM-et a Software Engineering Intézetben fejlesztették ki a 80-as évek végén. Az amerikai légierő által finanszírozott tanulmány eredményeként fejlesztették ki, hogy értékeljék az alvállalkozók munkáját. Később a szoftverfejlesztés érettségének értékelésére 1991-ben létrehozott CMM-SW modell alapján több más modell is integrálódik a CMM-I-be

Ebben az oktatóanyagban megtanuljuk,

• Mi a képességi lejárati modell (CMM) szintje?
• Mi történik a CMM különböző szintjein?
• Mennyi ideig tart a CMM megvalósítása?
• A CMM belső felépítése
• A CMM modellek korlátai
• Miért használja a CMM-et?

Mi a képességi lejárati modell (CMM) szintje?

1. A kezdeti
2. Ismételhető / kezelt
3. Meghatározott
4. Mennyiségileg kezelt
5. Optimalizálás

Mi történik a CMM különböző szintjein?

Szintek	Tevékenységek	Előnyök
1. szint Kezdő	Az 1. szinten a folyamat általában kaotikus és eseti A képességet az egyének és nem a szervezet alapján jellemzik A fejlődés nem mérhető A kifejlesztett termékek gyakran ütemezettek és meghaladják a költségvetést A menetrend, a költség, a funkcionalitás és a minőségi célok széles variációi	Egyik sem. A projekt a teljes káosz
2. szint kezelt	Igénykezelés Becsülje meg a projekt paramétereit, például a költségeket, az ütemezést és a funkcionalitást Mérje meg a tényleges haladást Tervek és folyamat kidolgozása Meghatározták a szoftver projekt szabványait A termékek azonosítása és ellenőrzése, a problémabejelentések változásai stb. A folyamatok különbözőek lehetnek a projektek között	A folyamatok könnyebben felfoghatók A vezetők és a csapattagok kevesebb időt fordítanak a dolgok elmagyarázására, és több időt fordítanak azok végrehajtására A projektek jobban becsültek, jobban megtervezettek és rugalmasabbak A minőséget beépítik a projektekbe A költségszámítás kezdetben magas lehet, de túlórázik Kérjen további papírokat és dokumentációt
3. szint definiálva	Tisztázza az ügyfelek igényeit Tervezési követelmények megoldása, megvalósítási folyamat kidolgozása Gondoskodik arról, hogy a termék megfeleljen a követelményeknek és a rendeltetésszerű használatnak Szisztematikusan elemezze a döntéseket Javítsa ki és ellenőrizze a lehetséges problémákat	A folyamat fejlesztése válik szabványossá A megoldás a "kódolástól" a "tervezésig" halad Minőségi kapuk jelennek meg a projekt során, az egész csapat részvételével A kockázatok enyhülnek, és nem lepik meg a csapatot
4. szint mennyiségileg kezelt	Statisztikai úton kezeli a projekt folyamatait és részfolyamatait A folyamat teljesítményének megértése, a szervezet projektjének kvantitatív irányítása	Optimalizálja a folyamat teljesítményét a szervezet egészében Elősegíti a kvantitatív projektmenedzsmentet egy szervezetben.
5. szint optimalizálása	Korán fedezze fel és távolítsa el a hibák okát Új eszközök és folyamatfejlesztések azonosítása és telepítése az igények és az üzleti célok kielégítése érdekében	Elősegíti a szervezeti innovációt és bevezetést Lendületet ad az ok-okozati elemzésnek és a felbontásnak

Az alábbi ábra képi ábrázolást ad arról, mi történik a különböző CMM-szinteken

Mennyi ideig tart a CMM megvalósítása?

A CMM a legkívánatosabb folyamat a termék minőségének fenntartására bármely szoftverfejlesztő vállalat számára, de megvalósítása alig tart tovább a vártnál.

• A CMM megvalósítása nem egyik napról a másikra történik
• Csak nem csupán "papírmunka".
• A megvalósítás tipikus időpontja
  • 3-6 hónap -> előkészítésre
  • 6-12 hónap -> megvalósításra
  • 3 hónap -> az értékelés előkészítéséhez
  • 12 hónap -> minden új szintre

A CMM belső felépítése

A CMM minden szintjét kulcsfolyamat-területre vagy KPA-ra definiálják , kivéve az 1. szintet. Mindegyik KPA meghatározza a kapcsolódó tevékenységek klaszterét, amelyek együttesen végrehajtva elérik a szoftverek képességének javításához elengedhetetlennek tartott célkitűzéseket

Különböző CMM szintek esetén vannak KPA-k, például a CMM-2 modell esetében a KPA vannak

• REQM- Igénykezelés
• PP- Projekttervezés
• PMC- Projektfigyelés és -ellenőrzés
• SAM- Beszállítói megállapodás kezelése
• PPQA-folyamat és minőségbiztosítás
• CM-konfigurációkezelés

Hasonlóképpen, más CMM-modellek esetében sajátos KPA-k vannak. Annak megismeréséhez, hogy a KPA megvalósítása hatékony, tartós és megismételhető-e, a következő alapon térképezzük fel

1. Elkötelezettség a teljesítésre
2. Teljesítési képesség
3. Tevékenységek végeznek
4. Mérés és elemzés
5. A megvalósítás ellenőrzése

A CMM modellek korlátai

• A CMM határozza meg, hogy egy folyamatnak mit kell címeznie, és nem a megvalósítás módját
• Nem magyarázza meg a szoftverfolyamatok fejlesztésének minden lehetőségét
• Szoftveres kérdésekre összpontosít, de nem veszi figyelembe a stratégiai üzleti tervezést, a technológiák átvételét, a termékcsalád létrehozását és az emberi erőforrások kezelését
• Nem mondja el, hogy egy szervezet milyen üzleti tevékenységet folytasson
• A CMM nem lesz hasznos a jelenleg válságos projektben

Miért használja a CMM-et?

Ma a CMM "jóváhagyási pecsétként" működik a szoftveriparban. Különböző módon segíti a szoftver minőségének javítását.

• Útmutató az ismételhető szabványos folyamat felé, és ezáltal csökkenti a tanulási időt a dolgok végrehajtására
• A CMM gyakorlása azt jelenti, hogy a fejlesztéshez szokásos protokollt kell gyakorolni, ami azt jelenti, hogy nemcsak a csapatot segíti az időmegtakarításban, hanem egyértelmű képet ad arról is, hogy mit kell tennie és mire számíthat
• A minőségi tevékenységek jobban megfelelnek a projektnek, nem pedig külön eseményként gondolják őket
• Ingázóként működik a projekt és a csapat között
• A CMM erőfeszítései mindig a folyamat javítására irányulnak

Összegzés

A CMM-et először a 80-as évek végén vezették be az amerikai légierőben, hogy értékeljék az alvállalkozók munkáját. Később, továbbfejlesztett verzióval, a szoftverfejlesztő rendszer minőségének nyomon követésére valósították meg.

A teljes CMM szint öt szintre oszlik.

• 1. szint (kezdeti): Ahol a rendszerre vonatkozó követelmények általában bizonytalanok, félreértettek és ellenőrizetlenek. A folyamat általában kaotikus és eseti.
• 2. szint (kezelt): Becsülje meg a projekt költségét, ütemezését és funkcionalitását. Szoftver szabványok vannak meghatározva
• 3. szint (meghatározott): Biztosítja, hogy a termék megfeleljen a követelményeknek és a rendeltetésszerű használatnak
• 4. szint (mennyiségileg kezelt): Statisztikai úton kezeli a projekt folyamatait és részfolyamatait
• 5. szint (érettség): Új eszközök és folyamatfejlesztések meghatározása és telepítése az igények és az üzleti célok kielégítése érdekében