CMMI Transition til Version 2 (Del 2)

Del 2 af 3: Strukturelle modelændringer

CMMI Transition til Version 2 (Del 2)

Share:

Capability Maturity Model Integration (CMMI) er en model til at forbedre organisationers performance. Modellen giver mulighed for at sammenligne sig med andre organisationer, identificere de bedste tiltag til forbedring, og den giver et stort katalog af konkrete tiltag hertil samt en fleksibel infrastruktur til at gennemføre forandringer i den praktiske verden.

CMMI udkom i 2018 i en ny og forbedret udgave kaldet version 2. Den ejes nu af CMMI Institute som er en del af ISACA. I denne serie af tre indlæg gennemgår vi det nye og interessante ved version 2 med udgangspunkt i en organisation, som har implementeret tidligere versioner (typisk CMMI for Development version 1.3) og som evaluerer transitionen til den nu gældende version af CMMI.

De tre indlæg omfatter

  1. Anvendelsesmuligheder (”det store billede”)
  2. Strukturelle modelændringer (”metamodellen”)
  3.  Ændringer af modellens praktikker (”konkrete effekter”)

Vi tager her udgangspunkt i, at læseren har et vist kendskab til CMMI (ellers kan man få det her). Beskrivelserne tager afsæt i vores personlige oplevelser og omfattende erfaringer med CMMI. Vi vægter beskrivelserne ud fra dette, og der er derfor heller ikke tale om en direkte oversættelse af modelejernes synspunkter.

Vi håber, at læseren får værdi af disse gennemgange og vil meget gerne kontaktes for uddybninger eller kommentarer.

Strukturelle modelændringer

Beskrivelserne i CMMI er baseret på en bagvedliggende beskrivelsesmodel også kaldet en metamodel. Forståelsen af disse beskrivelser er afgørende for en korrekt forståelse af CMMI. I det følgende beskrives ændringerne i forbindelse med version 2, idet der tager udgangspunkt i bottom up-tilgang. Denne del af vores gennemgang af transitionen til version 2 er meget modelorienteret og vil nok mest tiltale personer, som har procesforbedring som sit hovederhverv.

Beskrivelsesmodellen

CMMI har nu fire kategorier, som indholdsmæssigt er videreført fra den tidligere version (se boksen):

  • Doing, som handler om det, der gøres, for at frembringe og levere gode løsninger
  • Managing, der handler om planlægning og opfølgning
  • Enabling, som er nødvendige støttefunktioner for ovenstående eks. konfigurationsstyring
  • Improving, indeholdende aktiviteter for at fastholde og forbedre performance.

Categories and Capability Areas

I hver kategori findes en række måltemaer (eng. ”capability areas”) som indikeret på figuren. Disse udtrykker de helt store mål med CMMI (svarer på ”hvorfor” vi gør det, og hvad vi vil opnå) og integrerer forskellige praksisområder gennem fælles formål. Praksisområder hed procesområder i version 1, men har fået nyt navn, fordi det forvirrede nogle til at tro, at en implementering af CMMI også skulle have eksakt de samme områder.

En samlet oversigt over praksisområder, måltemaer og kategorier for den del af CMMI, der omfatter udvikling, er angivet herunder.

Practice Areas

Ændringen fra procesområder til praksisområder har også medført ændringer i beskrivelsesmodellen. Som et eksempel kan ses konfigurationsstyring (som er valgt udelukkende fordi, det er den simpleste praksisbeskrivelse).

Model Structure

Som det fremgår, så findes der ikke længere goals (version 1: Specific Goals og Generic Goals), de er nu delvist erstattet af praksisgrupper. Det kan henføres til, at der ikke er praksisspecifikt indhold i disse praksisgrupper – de beskriver niveauerne generelt – til gengæld findes der nu også krav til implementering i selve beskrivelsen af praksisområdet (se næste afsnit).

Angivelsen af krævet kontra informativt materiale er ændret. Nu indeholder praksisområdet krav, idet man skal leve op til både Intent og Value for området. Ligeledes er fortolkningen af praktikker nu krævede elementer, hvor man skal leve op til både Statement og Value (se figuren).

Practice Area Structure

Vi vil tillade os at konkludere, at tankegangen bag beskrivelserne i version 1 er videreført i version 2, men dog ændret i terminologi og konkret form.

Fra generiske praktikker til praksisområder

En meget væsentlig ændring i version 2 er, at de generiske praktikker er erstattet af to praksisområder, som ikke matcher tidligere procesområder; Governance (GOV) og Implementation Infrastructure (II).

Samtidigt glider det svært udtalelige ord ”institutionalisering” ud til fordel for udtrykket ”processens persistens og vane”.

Processens persistens og vane

Ordet ”persistens” skal i denne sammenhæng tænkes som modstandsdygtighed/udholdenhed, en evne til ”hele tiden at finde sted” og en modstand mod ”nedbrydning ved manglende fokus eller over tid”. Sammen med ordet ”vane”, så mener vi, det udtrykker nogenlunde det samme som det tidligere ord ”institutionalisering” – dvs. en evne, hvor processen er en del af ens kultur, udføres konsekvent og dermed ikke fraviges under pres.

Governance (GOV)

Dette praksisområde er orienteret mod seniorledelsens rolle som sponsorer for processer og som ledere af procesarbejdet. Gennem deres indsats sikres overensstemmelse mellem organisationens mål samt performance og organisationens procesforbedring og procesresultater. Området kan lidt abstrakt ses som den ledelsesmæssige infrastruktur for processer.

Praktikkerne i Governance er omskrivninger, der dækker følgende (nu udgåede) generiske praktikker:

  • GP 2.1       Establish an Organizational Policy
  • GP 2.3       Provide Resources
  • GP 2.4       Assign Responsibility
  • GP 2.5       Train People
  • GP 2.8       Monitor and Control the Process
  • GP 2.10     Review Status with Higher Level Management.

Implementation Infrastructure (II)

Dette praksisområde handler om at sikre, at processer udføres på en persistent og vanelignende måde, samt forbedres løbende.

Praktikkerne i Implementation Infrastructure er omskrivninger, der dækker følgende (nu udgåede) generiske praktikker:

  • GP 2.2       Plan the Process
  • GP 2.3       Provide Resources
  • GP  2.9       Objectively Evaluate Adherence
  • GP 3.1       Establish a Defined Process
  • GP  3.2       Collect Improvement Data.

Ændringer

Ved gennemgang af listen af generiske praktikker herover ses, at to generiske praktikker ikke er dækket af de to praksisområder – de er dog dækket andre steder i modellen. Dermed kan opsummeres, at formen er ændret væsentligt, men indholdsmæssigt er de generiske praktikker videreført.

Et andet spørgsmål er så, om version 2 kræver mere eller andet. Svaret er nok, at det afhænger af den konkrete implementering af CMMI version 1, for seniorledelsen kræves nu eksplicit involveret i målsætning, ressourcer, uddannelse, målinger/performance og procesoverholdelse. Det har altid været en god implementering, men desværre ikke altid tilfældet i praksis.

Modenhedsniveauer

CMMI i version 2 har modenhedsniveauer ligesom før i form af modenhedsprofiler for niveau 2, 3, 4 og 5 (modenhedsniveau 1 er ikke defineret som en profil).

Maturity Levels

Det er en afgørende forskel, at de overfor omtalte procesområder Governance (GOV) og Implementation Infrastructure (II) er obligatoriske i alle profiler.

CMMI for udvikling, modenhedsniveau 2 omfatter følgende praksisområder:

  • Requirements Development & Management (RDM)
  • Process Quality Assurance (PQA)
  • Supplier Agreement Management (SAM)*
  • Estimating (EST)
  • Planning (PLAN)
  • Monitor & Control (MC)
  • Configuration Management (CM)
  • Governance (GOV)
  • Implementation Infrastructure (II)
  • Managing Performance & Measurement (MPM).

* Supplier Agreement Management er fortsat det eneste valgfri praksisområde i modellen.

Omtalte profil inkluderer alle niveau 1 og 2 praktikker i de nævnte praktikområder. Som et eksempel kan nævnes konfigurationsstyring (vist herover) som inkluderer: CM 1.1 og CM 2.1 til 2.6 (i alt syv).

Indholdet af modenhedsniveau 3, 4 og 5 er illustreret på figuren herunder.

Maturity Levels defined as Maturity Profiles

Kapabilitetsniveauer

Kapabilitetsniveauer (eng. capability levels) understøtter at begrænse CMMI til udvalgte procesområder. Som nævnt før er Governance (GOV) og Implementation Infrastructure (II) obligatoriske i alle profiler.

Som et eksempel på en meget begrænset profil kan nævnes Configuration Management (CM) dvs. alene ét praksisområde. Denne profil vil på kapabilitetsniveau 2 indeholde CM (niveau 1 og 2), GOV (niveau 1 og 2) og II (niveau 1 og 2). På kapabilitetsniveau 3 indeholder den tilsvarende CM (niveau 1 og 2), GOV (niveau 1, 2 og 3) og II (niveau 1, 2 og 3). Det er ikke en skrivefejl, at CM niveau 3 ikke er med, da CM ikke indeholder praktikker på niveau 3.

Delkonklusion

I mange praktiske situationer vil ovennævnte ændringer kunne have en begrænset effekt. Vi synes dog, at der er gode takter i, at praktikker nu kræver, at organisationen skal leve op til både Statement og Value dvs., at der beskrive både hvad man gør, og hvad det skal resultere i.

Nogle fandt konceptet med generiske praktikker svært at forstå, mens andre kunne se en skønhed i det. Det gode ved de generiske praktikker er dog videreført, og man kan glæde sig over den simplificering og reduktion, det betyder i forbindelse med appraisal, når eks. modenhedsniveau 2 kun kræver det halve antal beviser (se evt. del 1 af analysen).