Capability Maturity Model (CMM) og dets niveauer i softwareteknologi
Hvad er CMM?
Capability Maturity Model bruges som et benchmark til at måle modenheden af en organisations softwareproces.
CMM blev udviklet på Software engineering instituttet i slutningen af 80'erne. Det blev udviklet som et resultat af en undersøgelse finansieret af det amerikanske luftvåben som en måde at evaluere underleverandørers arbejde på. Later baseret på CMM-SW-modellen oprettet i 1991 for at vurdere modenheden af softwareudvikling, er flere andre modeller integreret med CMM-I, de er
Hvad er Capability Maturity Model (CMM) niveauer?
- Initial
- Gentagelig/administreret
- Defineret
- Kvantitativt styret
- Optimering
Hvad sker der på forskellige niveauer af CMM?
Niveauer | Aktiviteter | Fordele |
---|---|---|
Niveau 1 Initial |
|
Ingen. Et projekt er Total Chaos |
Niveau 2 Administreret |
|
|
Niveau-3 defineret |
|
|
Niveau-4 Kvantitativt styret |
|
|
Niveau-5 optimering |
|
|
Følgende diagram giver en billedlig repræsentation af, hvad der sker på forskellige CMM-niveauer
Hvor lang tid tager det at implementere CMM?
CMM er den mest ønskværdige proces til at opretholde kvaliteten af produktet for enhver softwareudviklingsvirksomhed, men implementeringen tager lidt længere tid end forventet.
- CMM-implementering sker ikke natten over
- Det er bare ikke bare et "papirarbejde".
- Typiske tidspunkter for implementering er
- 3-6 måneder -> til forberedelse
- 6-12 måneder -> til implementering
- 3 måneder -> til vurderingsforberedelse
- 12 måneder ->for hvert nyt niveau
Intern struktur af CMM
Hvert niveau i CMM er defineret i nøgleprocesområde eller KPA, bortset fra niveau-1. Hver KPA definerer en klynge af relaterede aktiviteter, som, når de udføres kollektivt, opnår et sæt mål, der anses for at være afgørende for at forbedre softwarekapaciteten
For forskellige CMM-niveauer er der sæt af KPA'er, for eksempel for CMM model-2, KPA er
- REQM- Kravstyring
- PP- Projektplanlægning
- PMC- Projektovervågning og kontrol
- SAM- Leverandøraftalestyring
- PPQA-Proces og Kvalitetssikring
- CM-Configuration Management
Ligeledes har du for andre CMM-modeller specifikke KPA'er. For at vide, om implementering af en KPA er effektiv, varig og gentagelig, kortlægges den på følgende grundlag
- Forpligtelse til at præstere
- Evne til at præstere
- Aktiviteter udføres
- Måling og analyse
- Verifikation af implementering
Begrænsninger af CMM-modeller
- CMM bestemmer, hvad en proces skal adressere i stedet for hvordan den skal implementeres
- Det forklarer ikke alle muligheder for forbedring af softwareprocesser
- Den koncentrerer sig om softwarespørgsmål, men overvejer ikke strategisk forretningsplanlægning, vedtagelse af teknologier, etablering af produktlinje og styring af menneskelige ressourcer
- Det fortæller ikke om, hvilken slags virksomhed en organisation skal være i
- CMM vil ikke være nyttig i projektet, der har en krise lige nu
Hvorfor bruge CMM?
I dag fungerer CMM som et "godkendelsesstempel" i softwareindustrien. Det hjælper på forskellige måder med at forbedre softwarekvaliteten.
- Det guider mod gentagelig standardproces og reducerer dermed læringstiden på, hvordan man får tingene gjort
- At øve CMM betyder at øve standardprotokol til udvikling, hvilket betyder, at det ikke kun hjælper teamet med at spare tid, men også giver et klart overblik over, hvad de skal gøre, og hvad de kan forvente
- Kvalitetsaktiviteterne hænger godt sammen med projektet i stedet for at tænkes som en separat begivenhed
- Det fungerer som en pendler mellem projektet og teamet
- CMM's indsats er altid mod at forbedre processen
Resumé
CMM blev først introduceret i slutningen af 80'erne i US Air Force for at evaluere underleverandørers arbejde. Later på, med forbedret version, blev det implementeret for at spore kvaliteten af softwareudviklingssystemet.
Hele CMM-niveauet er opdelt i fem niveauer.
- Niveau 1 (Initial): Hvor krav til systemet normalt er usikre, misforståede og ukontrollerede. Processen er normalt kaotisk og ad hoc.
- Niveau 2 (Administreret): Estimer projektomkostninger, tidsplan og funktionalitet. Softwarestandarder er defineret
- Niveau 3 (Defineret): Sørger for, at produktet opfylder kravene og den påtænkte anvendelse
- Niveau 4 (Kvantitativt styret): Styrer projektets processer og delprocesser statistisk
- Niveau 5 (Modenhed): Identificer og implementer nye værktøjer og procesforbedringer for at imødekomme behov og forretningsmål