Capability Maturity Model (CMM) og dets nivåer i programvareteknikk

Hva er CMM?

Capability Maturity Model brukes som en benchmark for å måle modenheten til en organisasjons programvareprosess.

CMM ble utviklet ved Software engineering instituttet på slutten av 80-tallet. Den ble utviklet som et resultat av en studie finansiert av US Air Force som en måte å evaluere arbeidet til underleverandører. Later basert på CMM-SW-modellen opprettet i 1991 for å vurdere modenheten til programvareutvikling, er flere andre modeller integrert med CMM-I de er

Hva er Capability Maturity Model (CMM) nivåer?

Initial
Repeterbar/administrert
Definert
Kvantitativt administrert
Optimalisere

Hva skjer på ulike nivåer av CMM?

Nivåer	Aktiviteter	Fordeler
Nivå 1 Initial	På nivå 1 er prosessen vanligvis kaotisk og ad hoc En evne karakteriseres ut fra individene og ikke av organisasjonen Fremgang ikke målt Produktene som utvikles er ofte planlagt og over budsjett Store variasjoner i tidsplan, kostnader, funksjonalitet og kvalitetsmål	Ingen. Et prosjekt er Total Chaos
Nivå 2 administrert	Kravstyring Estimer prosjektparametere som kostnad, tidsplan og funksjonalitet Mål faktisk fremgang Utvikle planer og prosess Programvareprosjektstandarder er definert Identifiser og kontroller produkter, endringer i problemrapporter osv. Prosesser kan variere mellom prosjekter	Prosesser blir lettere å forstå Ledere og teammedlemmer bruker mindre tid på å forklare hvordan ting gjøres og mer tid på å utføre det Prosjekter er bedre estimert, bedre planlagt og mer fleksible Kvalitet er integrert i prosjekter Kostnadene kan være høye i utgangspunktet, men går ned overtid Be om mer papirarbeid og dokumentasjon
Nivå-3 definert	Avklare kundekrav Løse designkrav, utvikle en implementeringsprosess Sørger for at produktet oppfyller kravene og tiltenkt bruk Analyser beslutninger systematisk Rett opp og kontroller potensielle problemer	Prosessforbedring blir standarden Løsningen går fra å være "kodet" til å bli "konstruert" Kvalitetsporter vises gjennom hele prosjektarbeidet med hele teamet involvert i prosessen Risikoer reduseres og overrasker ikke teamet
Nivå-4 Kvantitativt administrert	Styrer prosjektets prosesser og delprosesser statistisk Forstå prosessytelse, administrere organisasjonens prosjekt kvantitativt	Optimaliserer prosessytelsen på tvers av organisasjonen Fremmer kvantitativ prosjektledelse i en organisasjon.
Nivå-5 Optimalisering	Oppdag og fjern årsaken til defekter tidlig Identifiser og implementer nye verktøy og prosessforbedringer for å møte behov og forretningsmål	Fremmer organisatorisk innovasjon og distribusjon Gir drivkraft til årsaksanalyse og oppløsning

Følgende diagram gir en billedlig representasjon av hva som skjer på forskjellige CMM-nivåer

Hvor lang tid tar det å implementere CMM?

CMM er den mest ønskelige prosessen for å opprettholde kvaliteten på produktet for ethvert programvareutviklingsselskap, men implementeringen tar litt lengre tid enn forventet.

CMM-implementering skjer ikke over natten
Det er bare ikke bare et "papirarbeid".
Typiske tidspunkter for gjennomføring er
3-6 måneder -> for forberedelse
6-12 måneder -> for gjennomføring
3 måneder -> for vurderingsforberedelse
12 måneder ->for hvert nytt nivå

Intern struktur av CMM

Hvert nivå i CMM er definert til nøkkelprosessområde eller KPA, bortsett fra nivå-1. Hver KPA definerer en klynge av relaterte aktiviteter, som når de utføres kollektivt oppnår et sett med mål som anses som avgjørende for å forbedre programvarekapasiteten

For forskjellige CMM-nivåer er det sett med KPA-er, for eksempel for CMM modell-2, KPA er

REQM- Kravstyring
PP- Prosjektplanlegging
PMC- Prosjektovervåking og kontroll
SAM- Leverandøravtalestyring
PPQA-prosess og kvalitetssikring
CM-Configuration Management

På samme måte, for andre CMM-modeller, har du spesifikke KPA-er. For å vite om implementeringen av en KPA er effektiv, varig og repeterbar, kartlegges den på følgende grunnlag

Forpliktelse til å prestere
Evne til å prestere
Aktiviteter utføres
Måling og analyse
Verifiserer implementering

Begrensninger for CMM-modeller

CMM bestemmer hva en prosess skal adressere i stedet for hvordan den skal implementeres
Det forklarer ikke alle muligheter for forbedring av programvareprosesser
Den konsentrerer seg om programvarespørsmål, men vurderer ikke strategisk forretningsplanlegging, ta i bruk teknologier, etablere produktlinje og administrere menneskelige ressurser
Den forteller ikke om hva slags virksomhet en organisasjon skal være i
CMM vil ikke være nyttig i prosjektet som har en krise akkurat nå

Hvorfor bruke CMM?

I dag fungerer CMM som et "godkjenningsstempel" i programvareindustrien. Det hjelper på ulike måter å forbedre programvarekvaliteten.

Den veileder mot repeterbar standardprosess og reduserer dermed læringstiden for hvordan du får ting gjort
Å praktisere CMM betyr å praktisere standard protokoll for utvikling, noe som betyr at det ikke bare hjelper teamet med å spare tid, men også gir en klar oversikt over hva de skal gjøre og hva de kan forvente
Kvalitetsaktivitetene henger godt sammen med prosjektet i stedet for å tenkes på som et eget arrangement
Den fungerer som en pendler mellom prosjektet og teamet
CMM-innsatsen er alltid mot forbedring av prosessen

Sammendrag

CMM ble først introdusert på slutten av 80-tallet i US Air Force for å evaluere arbeidet til underleverandører. Later på, med forbedret versjon, ble den implementert for å spore kvaliteten på programvareutviklingssystemet.

Hele CMM-nivået er delt inn i fem nivåer.

Level 1 (Initial): Der krav til systemet vanligvis er usikre, misforståtte og ukontrollerte. Prosessen er vanligvis kaotisk og ad hoc.
Level 2 (Administrert): Estimer prosjektkostnad, tidsplan og funksjonalitet. Programvarestandarder er definert
Level 3 (Definert): Sørger for at produktet oppfyller kravene og tiltenkt bruk
Level 4 (Kvantitativt styrt): Styrer prosjektets prosesser og delprosesser statistisk
Level 5 (Modenhet): Identifiser og implementer nye verktøy og prosessforbedringer for å møte behov og forretningsmål