Bakgrund till CMMI (Capability Maturity Model Integration)

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

Den slutgiltiga guiden till CMMI (Capability Maturity Model Integration) for Development publiceras av Software Engineering Institute som "CMMI: Guidelines for Process Integration and Product Improvement" (CMMI: Guidelines for Process Integration and Product Improvement). Den här boken beskriver specifikt CMMI for Development (CMMI-DEV) version 1.3, som är en av modellerna i CMMI-produktsviten. Du kan också se "CMMI Distilled: A Practical Introduction to Integrated Process Improvement" vara en användbar och tillgänglig bok om CMMI.

Kommentar

Vägledningen här baseras på version 1.3 för CMMI och stöder CMMI-processen som är tillgänglig med Azure DevOps. Det finns för närvarande inga planer på att uppdatera det här innehållet för att stödja senare versioner.

Historiska anteckningar

CMMI började 1987 som Capability Maturity Model (CMM), ett projekt vid Software Engineering Institute (SEI). SEI är ett forskningscenter vid Carnegie-Mellon University, som grundades och finansierades av USA Department of Defense. Cmm for Software, som först publicerades 1991, började som en checklista för kritiska framgångsfaktorer. Modellen byggde också på forskning vid International Business Machines (IBM) Corporation och kvalitetssäkringsledare från 1900-talet som Philip Crosby och W. Edwards Deming. Både namnet, Capability Maturity Model och den mellanlagrade representationen på fem nivåer inspirerades av Crosbys modell för tillverkningsmognad. Cmm tillämpades främst på försvarsprogram och genomförde en betydande implementering och genomgick flera revisioner. Dess framgång ledde till utvecklingen av CMM:er för en mängd olika ämnen utöver programvara. Spridningen av nya modeller var förvirrande. Som svar finansierade regeringen ett tvåårigt projekt för att skapa ett enda, utökningsbart ramverk som integrerade systemteknik, programvaruteknik och produktutveckling. Detta arbete involverade mer än 200 bransch- och akademiska experter. Resultatet blev CMMI.

CMMI-DEV är en modell. Det är inte en process eller ett recept som ska följas. I stället tillhandahåller CMMI-DEV en uppsättning organisationsbeteenden som har visat sig vara till nytta inom programvaruutveckling och systemteknik. Varför ska jag använda en sådan modell? Vad är dess syfte? Och hur bör det användas bäst? Dessa kritiska frågor är kanske de mest missförstådda problemen med CMMI.

Varför ska jag använda en modell?

Förbättringsarbetet kräver en modell för hur din organisation fungerar, vilka funktioner de behöver och hur dessa funktioner interagerar. En modell ger dig en förståelse för organisationselement och hjälper dig att diskutera hur och vad som kan och bör förbättras.

En modell erbjuder följande fördelar:

• Tillhandahåller ett gemensamt ramverk och språk som hjälper dig att kommunicera
• Utnyttjar många års erfarenhet
• Hjälper användarna att ta hänsyn till den stora bilden samtidigt som de fokuserar på förbättringar
• Stöds ofta av utbildare och konsulter
• Kan hjälpa till att lösa meningsskiljaktigheter genom att tillhandahålla överenskomna standarder

Vad är syftet med CMMI-modellen?

Syftet med CMMI-modellen är att utvärdera mognaden för en organisations processer och att ge vägledning om att förbättra processer, med målet att förbättra produkter. CMMI är också en modell för riskhantering och ger ett sätt att mäta en organisations förmåga att hantera risker. Möjligheten att hantera riskfaktorer i organisationers förmåga att leverera högkvalitativa produkter. Ett annat perspektiv på att hantera risker är hur väl en organisation presterar under stress. En organisation med hög mognad och hög kapacitet kan enkelt svara på oväntade, stressiga händelser. En organisation med låg mognad och lägre kapacitet tenderar att få panik under stress, blint följa förintade procedurer eller kasta ut all process helt och hållet och retrench tillbaka till kaos.

CMMI är dock inte en beprövad indikator på organisationens ekonomiska resultat. Även om organisationer med högre mognad kan hantera risker bättre och vara mer förutsägbara, finns det bevis för att företag med högre mognad tenderar att vara riskvilliga. Riskaversion kan leda till brist på innovation eller tecken på större byråkrati som leder till långa ledtider och brist på konkurrenskraft. Företag med lägre mognad tenderar att vara mer innovativa och kreativa men kaotiska och oförutsägbara. När resultaten uppnås är de ofta resultatet av heroiska insatser av individer eller chefer.

Vilket är det bästa sättet att använda CMMI-modellen?

Modellen utformades för att användas som grund för ett initiativ för processförbättring, där den endast används i utvärdering ett stödsystem för att mäta förbättringar. Det har varit blandade framgångar med den här användningen. Det är alltför lätt att missta modellen för en processdefinition och försöka följa den, i stället för en karta som identifierar luckor i befintliga processer som kan behöva fyllas i. Den grundläggande byggstenen i CMMI är ett processområde som definierar mål och flera aktiviteter som ofta används för att uppfylla dem. Ett exempel på ett processområde är Process- och produktkvalitetssäkring. En annan är Konfigurationshantering. Det är viktigt att förstå att ett processområde inte är en process. En enda process kan korsa flera processområden och ett enskilt processområde kan omfatta flera processer.

CMMI-DEV är egentligen två modeller som delar samma underliggande element. Den första och mest bekanta är den mellanlagrade representationen, som presenterar de 22 processområden som är mappade till en av fem organisationsmognadsnivåer. En bedömning av en organisation skulle bedöma på vilken nivå den fungerade, och den här nivån skulle vara en indikator på dess förmåga att hantera risker och, som, uppfylla sina löften.

Nivåerna 4 och 5 kallas ofta för högre mognadsnivåer. Det finns ofta en tydlig skillnad mellan organisationer med högre mognad, som visar kvantitativ hantering och optimering av beteenden och organisationer med lägre mognad, som bara hanteras eller följer definierade processer. Organisationer med högre mognad visar lägre variabilitet i processer och använder ofta ledande indikatorer som en del av en statistiskt försvarbar hanteringsmetod. Därför tenderar organisationer med högre mognad att vara både mer förutsägbara och snabbare på att svara på ny information, förutsatt att annan byråkrati inte kommer i vägen. När organisationer med låg mognad tenderar att demonstrera heroiska insatser kan organisationer med hög mognad blint följa processer när de är stressade och inte inse att en processändring kan vara ett lämpligare svar.

Modeller för kontinuerlig representation bearbetar kapacitet inom vart och ett av de 22 processområdena individuellt, vilket gör det möjligt för organisationen att skräddarsy sina förbättringsinsatser efter de processer som erbjuder högsta affärsvärde. Denna representation är mer i linje med Crosbys ursprungliga modell. Utvärderingar mot den här modellen resulterar i kapacitetsprofiler snarare än ett enda tal. Eftersom organisationens mognadsnivå är den nivå som de flesta chefer och chefer förstår finns det sätt att mappa resultatet av en kontinuerlig modellutvärdering till de fem stegen.

Att använda den mellanlagrade modellen som grund för ett processförbättringsprogram kan vara farligt när implementerare glömmer att CMMI inte är en process eller en arbetsflödesmodell. I stället är CMMI utformat för att ge mål för processer och arbetsflöden att uppnå. Att uppfylla sådana mål förbättrar organisationens mognad och sannolikheten för att händelserna utvecklas som planerat. Kanske är det största felläget att uppnå en nivå målet och sedan skapa processer och infrastruktur helt enkelt för att klara utvärderingen. Målet med någon processförbättringsaktivitet bör vara mätbar förbättring, inte ett tal.

Den kontinuerliga modellen har haft framgång som en guide till processförbättringar. Vissa konsultföretag väljer endast att ge vägledning kring kontinuerlig modell. Den mest uppenbara skillnaden är att ett processförbättringsprogram som är utformat kring kontinuerlig modell inte har artificiella mål som bestäms av mognadsnivåer. Den kontinuerliga modellen lämpar sig också för att tillämpa processförbättringar på områden där det mest sannolikt kommer att dra nytta av en ekonomisk fördel för organisationen. Därför är det mer troligt att de som följer den kontinuerliga modellen får positiv feedback från ett initiativ som baseras på CMMI-modellen. Dessutom är det mer sannolikt att positiv feedback leder till utvecklingen av en god cykel av förbättringar.

Element i CMMI-modellen

I följande tabell visas de 22 processområden som utgör CMMI-modellen (version 1.3):

Akronym	Processområde
BIL	Kausal analys och lösning
KB	Konfigurationshantering
DAR	Beslutsanalys och lösning
IPM	Integrerad projekthantering
MA	Mått och analys
OID	Organisationsinnovation och distribution
OPD	Definition av organisationsprocess
OPF	Fokus på organisationsprocess
OPP	Prestanda för organisationsprocess
OT	Organisationsträning
PI	Produktintegrering
PMC	Projektövervakning och -kontroll
PP	Projektplanering
PPQA	Process- och produktkvalitetssäkring
QPM	Kvantitativ projekthantering
RD	Kravdefinition
REQM	Kravhantering
RSKM	Riskhantering
SAM	Hantering av leverantörsavtal
TS	Teknisk lösning
VER	Verifiering
VAL	Validering

I den mellanlagrade representationen mappas processområdena mot varje steg, enligt följande bild.

I kontinuerlig representation mappas processområdena till funktionella grupper, enligt följande bild.

Varje processområde består av nödvändiga, förväntade och informativa komponenter. Endast de komponenter som krävs krävs för att uppfylla en bedömning mot modellen. De nödvändiga komponenterna är de specifika och allmänna målen för varje processområde. De förväntade komponenterna är de specifika och allmänna metoderna för varje specifikt eller allmänt mål. Observera att eftersom en förväntad komponent bara förväntas och inte krävs, indikerar detta att en specifik eller allmän praxis kan ersättas av en motsvarande praxis. De förväntade metoderna finns där för att vägleda implementerare och appraisers. Om en alternativ metod väljs är det upp till implementören att ge råd till en appraiser och motivera varför en alternativ metod är lämplig. Informativa komponenter ger information som hjälper implementer att komma igång med ett initiativ för processförbättring som styrs av CMMI-modellen. Informativa komponenter inkluderar subpractices av generiska och specifika metoder och typiska arbetsprodukter.

Endast allmänna och specifika mål krävs. Allt annat tillhandahålls som en guide. Till exempel på förväntade och informativa komponenter hämtade CMMI-litteraturen data från stora rymd- och försvarssystemprojekt. Dessa projekt kanske inte återspeglar den typ av projekt som genomförs i din organisation, och de kanske inte heller återspeglar nyare trender i branschen, till exempel framväxten av agila metoder för programvaruutveckling .

Relaterade artiklar

• CMMI-processen
• Software Engineering Institute släpper version 1.3 av CMMI Product Suite
• CMMI för utveckling: Riktlinjer för processintegrering och produktförbättring, tredje utgåvan
• CMMI för utveckling: Riktlinjer för processintegrering och produktförbättring (SEI-serien inom programvaruteknik)
• Vad är agil utveckling?