Vad är CMM?
Capability Maturity Model används som ett riktmärke för att mäta mognaden i en organisations mjukvaruprocess.
CMM utvecklades vid Software Engineering Institute i slutet av 80-talet. Det utvecklades som ett resultat av en studie finansierad av US Air Force som ett sätt att utvärdera underleverantörernas arbete. Senare baserat på CMM-SW-modellen som skapades 1991 för att bedöma mognaden av mjukvaruutveckling, är flera andra modeller integrerade med CMM-I de är
I den här handledningen lär vi oss,
- Vad är CMM-nivåer (Capability Maturity Model)?
- Vad händer på olika nivåer av CMM?
- Hur lång tid tar det att implementera CMM?
- Intern struktur för CMM
- Begränsningar av CMM-modeller
- Varför använda CMM?
Vad är CMM-nivåer (Capability Maturity Model)?
- Första
- Repeterbar / hanterad
- Definierat
- Kvantitativt hanterad
- Optimerande
Vad händer på olika nivåer av CMM?
Nivåer | Aktiviteter | Fördelar |
---|---|---|
Nivå 1 Initial |
| Ingen. Ett projekt är Total Chaos |
Nivå 2 hanterad |
|
|
Nivå 3 definierad |
|
|
Nivå-4 Kvantitativt hanterad |
|
|
Nivå 5 Optimering |
|
|
Följande diagram ger en bildrepresentation av vad som händer på olika CMM-nivå
Hur lång tid tar det att implementera CMM?
CMM är den mest önskvärda processen för att upprätthålla produktens kvalitet för alla programvaruutvecklingsföretag, men dess implementering tar lite längre tid än vad som förväntas.
- CMM-implementering sker inte över natten
- Det är bara inte bara ett "pappersarbete".
- Typiska tider för implementering är
- 3-6 månader -> för beredning
- 6-12 månader -> för implementering
- 3 månader -> för beredning av bedömningen
- 12 månader -> för varje ny nivå
Intern struktur för CMM
Varje nivå i CMM definieras i nyckelprocessområde eller KPA , förutom nivå 1. Varje KPA definierar ett kluster av relaterade aktiviteter som när de utförs kollektivt uppnår en uppsättning mål som anses viktiga för att förbättra programvarufunktionen
För olika CMM-nivåer finns det uppsättning KPA, till exempel för CMM-modell 2 är KPA
- REQM- Kravshantering
- PP- Projektplanering
- PMC- Projektövervakning och kontroll
- SAM- hantering av leverantörsavtal
- PPQA-process och kvalitetssäkring
- CM-konfigurationshantering
På samma sätt har du för andra CMM-modeller specifika KPA: er. För att veta om implementeringen av en KPA är effektiv, varaktig och repeterbar, kartläggs den på följande basis
- Åtagande att utföra
- Förmåga att prestera
- Aktiviteter utförs
- Mätning och analys
- Verifierar genomförandet
Begränsningar av CMM-modeller
- CMM bestämmer vad en process ska adressera istället för hur den ska implementeras
- Det förklarar inte alla möjligheter till förbättring av programvaruprocesser
- Den koncentrerar sig på programvaruproblem men överväger inte strategisk affärsplanering, att använda tekniker, etablera produktlinje och hantera mänskliga resurser
- Den säger inte om vilken typ av verksamhet en organisation ska ha
- CMM kommer inte att vara användbart i projektet som har en kris just nu
Varför använda CMM?
Idag fungerar CMM som ett "godkännande" i mjukvaruindustrin. Det hjälper på olika sätt att förbättra mjukvarukvaliteten.
- Den styr mot en repeterbar standardprocess och minskar därmed inlärningstiden för hur man får saker gjort
- Att öva på CMM innebär att man övar standardprotokoll för utveckling, vilket innebär att det inte bara hjälper teamet att spara tid utan också ger en tydlig bild av vad man ska göra och vad man kan förvänta sig
- Kvalitetsaktiviteterna gelar bra med projektet snarare än att betraktas som en separat händelse
- Det fungerar som en pendlare mellan projektet och teamet
- CMM-ansträngningar är alltid att förbättra processen
Sammanfattning
CMM introducerades först i slutet av 80-talet i US Air Force för att utvärdera underleverantörernas arbete. Senare, med förbättrad version, implementerades den för att spåra kvaliteten på programvaruutvecklingssystemet.
Hela CMM-nivån är uppdelad i fem nivåer.
- Nivå 1 (initial): Där kraven på systemet vanligtvis är osäkra, missförstådda och okontrollerade. Processen är vanligtvis kaotisk och ad-hoc.
- Nivå 2 (hanterad): Beräkna projektkostnad, schema och funktionalitet. Programvarustandarder definieras
- Nivå 3 (definierad): Ser till att produkten uppfyller kraven och avsedd användning
- Nivå 4 (kvantitativt hanterad): Hanterar projektets processer och delprocesser statistiskt
- Nivå 5 (mognad): Identifiera och distribuera nya verktyg och processförbättringar för att möta behov och affärsmål