Kas ir CMM?
Spēju termiņa modeli izmanto kā etalonu, lai izmērītu organizācijas programmatūras procesa briedumu.
CMM tika izstrādāts programmatūras inženieru institūtā 80. gadu beigās. Tas tika izstrādāts ASV Gaisa spēku finansēta pētījuma rezultātā, lai novērtētu apakšuzņēmēju darbu. Vēlāk, pamatojoties uz CMM-SW modeli, kas izveidots 1991. gadā, lai novērtētu programmatūras izstrādes briedumu, daudzi citi modeļi ir integrēti CMM-I, tie ir
Šajā apmācībā mēs iemācīsimies,
- Kas ir spēju brieduma modeļa (CMM) līmeņi?
- Kas notiek dažādos CMM līmeņos?
- Cik ilgs laiks nepieciešams CMM ieviešanai?
- CMM iekšējā struktūra
- CMM modeļu ierobežojumi
- Kāpēc izmantot CMM?
Kas ir spēju brieduma modeļa (CMM) līmeņi?
- Sākotnējais
- Atkārtojams / Pārvaldīts
- Definēts
- Kvantitatīvi Pārvalda
- Optimizēšana
Kas notiek dažādos CMM līmeņos?
Līmeņi | Aktivitātes | Ieguvumi |
---|---|---|
1. līmeņa sākotnējais |
| Nav. Projekts ir kopējais haoss |
Pārvalda 2. līmeni |
|
|
Definēts 3. līmenis |
|
|
4. līmenis kvantitatīvi pārvaldīts |
|
|
5. līmeņa optimizācija |
|
|
Pēc diagrammas ir attēlots, kas notiek dažādos CMM līmeņos
Cik ilgs laiks nepieciešams CMM ieviešanai?
CMM ir vēlamākais produkta kvalitātes uzturēšanas process jebkuram programmatūras izstrādes uzņēmumam, taču tā ieviešana prasa nedaudz ilgāku laiku, nekā paredzēts.
- CMM ieviešana nenotiek vienā dienā
- Tas vienkārši nav tikai "papīrs".
- Tipiski ieviešanas laiki ir
- 3-6 mēneši -> sagatavošanai
- 6-12 mēneši -> ieviešanai
- 3 mēneši -> novērtējuma sagatavošanai
- 12 mēneši -> katram jaunam līmenim
CMM iekšējā struktūra
Katrs CMM līmenis ir definēts galvenajā procesa apgabalā vai KPA , izņemot 1. līmeni. Katrā KPA ir definēta saistīto darbību kopa, kas, veicot kopīgi, sasniedz mērķu kopumu, kas tiek uzskatīts par būtisku programmatūras spēju uzlabošanai
Dažādiem CMM līmeņiem ir noteikti KPA, piemēram, CMM-2 modelim, KPA ir
- REQM - prasību pārvaldība
- PP- projekta plānošana
- PMC - projekta uzraudzība un kontrole
- SAM- Piegādātāja līgumu pārvaldība
- PPQA process un kvalitātes nodrošināšana
- CM-konfigurācijas pārvaldība
Tāpat arī citiem CMM modeļiem jums ir noteiktas KPA. Lai uzzinātu, vai KPA ieviešana ir efektīva, ilgstoša un atkārtojama, tā tiek kartēta, pamatojoties uz sekojošo
- Apņemšanās uzstāties
- Spēja uzstāties
- Aktivitātes veic
- Mērīšana un analīze
- Īstenošanas pārbaude
CMM modeļu ierobežojumi
- CMM nosaka procesa virzienu, nevis tā ieviešanas veidu
- Tas nepaskaidro visas programmatūras procesa uzlabošanas iespējas
- Tas koncentrējas uz programmatūras jautājumiem, bet neņem vērā stratēģisko biznesa plānošanu, tehnoloģiju ieviešanu, produktu līnijas izveidi un cilvēkresursu pārvaldību
- Tajā nav norādīts, kādā uzņēmējdarbībā organizācijai vajadzētu būt
- CMM šobrīd nebūs noderīga projektā, kam ir krīze
Kāpēc izmantot CMM?
Šodien CMM programmatūras nozarē darbojas kā "apstiprinājuma zīmogs". Tas dažādos veidos palīdz uzlabot programmatūras kvalitāti.
- Tas ved uz atkārtojamu standarta procesu un tādējādi samazina mācību laiku, kā paveikt lietas
- Praktizēt CMM nozīmē praktizēt standarta izstrādes protokolu, kas nozīmē, ka tas ne tikai palīdz komandai ietaupīt laiku, bet arī sniedz skaidru priekšstatu par to, kas jādara un ko var sagaidīt
- Kvalitatīvās aktivitātes labi iederas projektā, nevis tiek uzskatītas par atsevišķu pasākumu
- Tas darbojas kā piepilsētas loceklis starp projektu un komandu
- CMM centieni vienmēr ir vērsti uz procesa uzlabošanu
Kopsavilkums
CMM pirmo reizi tika ieviests 80. gadu beigās ASV gaisa spēkos, lai novērtētu apakšuzņēmēju darbu. Vēlāk ar uzlabotu versiju tā tika ieviesta, lai izsekotu programmatūras izstrādes sistēmas kvalitātei.
Viss CMM līmenis ir sadalīts piecos līmeņos.
- 1. līmenis (Sākotnējais): kur prasības sistēmai parasti ir neskaidras, pārprastas un nekontrolētas. Process parasti ir haotisks un ad-hoc.
- 2. līmenis (Pārvalda): novērtējiet projekta izmaksas, grafiku un funkcionalitāti. Ir definēti programmatūras standarti
- 3. līmenis (noteikts): pārliecinās, vai produkts atbilst prasībām un paredzētajam lietojumam
- 4. līmenis (kvantitatīvi pārvaldīts): statistiski pārvalda projekta procesus un apakšprocesus
- 5. līmenis (briedums): identificējiet un izvietojiet jaunus rīkus un procesu uzlabojumus, lai apmierinātu vajadzības un biznesa mērķus