CMMIÒ-modellen (Capability Maturity Model Integration) er udviklet af Software En-gineering Institute (SEI) ved Carnegie Mellon Universitetet i Pittsburgh, USA. Den blev først beskrevet i [Humphrey89] (og hed oprindeligt blot CMM), men der er senere kommet opdateringer som kan hentes gratis fra www.sei.cmu.edu.
Der findes flere CMMIÒ-modeller, men her vil vi se på modellen som beskriver softwareudvikling, CMMI-SW. Den omfatter en række procesområder man skal beher-ske. Procesområderne kan inddeles i 5 modenhedsniveauer, 1-5, hvor 1 er det mest
Niveau Fokus Procesområder
1. Begynder Helte
2. Styret Projektstyring Kravstyring
Projektplanlæging Projektstyring
Underleverandørstyring Måling og analyse
Kvalitetssikring af produkt og proces Konfigurationsstyring
3. Dokumenteret Udviklingsprocessen Udvikling af krav Teknisk løsning Produktintegration Verifikation Validering
Organisatorisk procesfokus Organisatorisk procesdefinition Organisatorisk uddannelse Integreret projektledelse Risikostyring
Beslutningsanalyse 4. Kvantitativt styret Kvalitet i proces og
produkt
Organisatorisk procesydeevne Kvantitativ projektledelse 5. Optimerende Vedvarende
procesforbedring
Organisatorisk fornyelse og udbredelse Årsagsanalyse og forbedring
umodne (begynderniveauet), og 5 er det optimale. Dette kaldes den trinvise repræsen-tation. Men det er vigtigt at understrege at (i modsætning til den tidligere CMM-mo-del) findes også en kontinuert repræsentation hvor man kigger på hvor meget de enkelte procesområder beherskes – uden skelen til trin.
Selv om I ikke skal CMMI-certificeres, kan det være nyttigt at se på de discipliner som modellen fremhæver er vigtige. Det er nemlig de steder hvor du som projektleder får størst udbytte af at sætte ind i forhold til jeres projekt.
Niveau 1 – Begynderniveauet (eng.: Initial)
Dette kaldes også det kaotiske niveau, her er typisk ikke styr på ret meget. Når det alli-gevel en gang imellem lykkes at aflevere kørende systemer til kunderne, skyldes det dygtige udviklere, såkaldte helte.
Niveau 2 – Det styrede niveau (eng.: Managed)
Vi kan gentage vores succeser – vel at mærke så længe vi laver de samme ting. Kaster vi os over nye områder, går det ofte galt. Og bliver vi pressede, forfalder vi gerne til brandslukning – som vi plejer.
På niveau 2 fokuseres på projektets fundamentale processer, og følgende procesom-råder beherskes:
– KRAVSTYRING. Formålet med kravstyring er hele tiden at have overblik over kravene til projektet. Der skal derfor etableres en effektiv proces til at styre ændringer til kra-vene undervejs i projektforløbet.
– PROJEKTPLANLÆGNING. Der skal udarbejdes og vedligeholdes fornuftige estimater og planer for projektet.
– PROJEKTOPFØLGNING. Fremdriften i projektet skal synliggøres så man bliver i stand til at opdage hvis planerne skrider og handle derefter. Vi skal altså kunne se hvor projektet er henne.
– UNDERLEVERANDØRSTYRING. Eventuelle underleverandører til projektet skal udvæl-ges omhyggeligt, og vi skal kunne styre dem effektivt.
– MÅLINGogANALYSE. Vi skal have etableret et sæt målinger som kan forsyne os med de nødvendige informationer for at kunne styre projektet ordentligt.
– KVALITETSSIKRING. Der skal være passende synlighed, både mht. kvaliteten af selve udviklingsprocessen og mht. kvaliteten af det udviklede produkt. Det betyder bl.a.
fokus på test af den udviklede software og fokus på reviews/inspektioner undervejs i udviklingsforløbet.
– KONFIGURATIONSSTYRING. Sammenhængen og integriteten mellem de ofte mange
forskellige indgående komponenter i produktet skal sikres. Dette gøres typisk med automatiserede værktøjer (f.eks. SourceSafe, PVCS eller CVS).
Niveau 3 – Det dokumenterede niveau (eng.: Defined)
Her er der styr på alle udviklingsprocesserne. Vi flytter fokus op fra at kigge på projek-tet til nu at kigge på hele organisationen og dermed skabe et fælles udgangspunkt for alle projekter.
På niveau 3 beherskes følgende procesområder:
– UDVIKLING AF KRAV. Vi skal være i stand til at tage udgangspunkt i kundens behov for derved at opstille de krav til produktet (og eventuelle komponenter) som opfyl-der kundens behov. Kun på denne måde kan vi lave en brugbar kravspecifikation.
– TEKNISK LØSNING. Det er her vi har fokus på at omsætte produktkravene til et køren-de system. Vi skal kunne vælge køren-den bedste tekniske løsning (herunkøren-der teknologi, ar-kitektur og design).
– PRODUKTINTEGRATION. Dette procesområde drejer sig om at have styr på det at sammensætte det kørende produkt ud fra de indgående komponenter.
– VERIFIKATION. Vi skal sikre os at produktet opfylder de opstillede krav. Vi skal med andre ord sikre os at det vi har lavet er lavet rigtigt.
– VALIDERING. Vi skal sikre os at produktet opfylder behovet. Vi skal med andre ord sikre os at det er det rigtige vi har lavet.
– ORGANISATORISK PROCESFOKUS. Der skal udarbejdes en plan for forbedring af udvik-lingsaktiviteterne, og aktiviteterne skal koordineres på tværs af hele organisationen.
– ORGANISATORISK PROCESDEFINITION. Det er under dette procesområde der tænkes på softwarehåndbog, definition og beskrivelse af softwareudviklingsprocessen samt dokumenterede retningslinjer.
– ORGANISATORISK UDDANNELSE. Vi skal sikre at alle personer der deltager i projektet har modtaget en passende uddannelse i de metoder, standarder, værktøjer og andet der benyttes.
– INTEGRERET PROJEKTLEDELSE. I dette procesområde fokuseres på at få styringen af de enkelte projekter tilpasset organisationens vedtagne måde at køre projekter på.
– RISIKOSTYRING. Vi skal kunne identificere potentielle risici før de opstår så vi eventu-elt kan iværksætte modforanstaltninger.
– BESLUTNINGSANALYSE. Vi skal kunne træffe vigtige projektbeslutninger på et kvalifi-ceret grundlag og på en kvalifikvalifi-ceret måde.
Niveau 4 – Det kvantitativt styrede niveau (eng.: Quantitatively Managed) Her er der fokus på måling og dataindsamling som kan synliggøre processerne.
På niveau 4 beherskes følgende procesområder:
– ORGANISATORISK PROCESYDEEVNE. Dette procesområde fokuserer på at måle hvor ef-fektive vi er. Her måler vi f.eks. både på udviklingshastighed og på fejlhyppighed.
– KVANTITATIV PROJEKTLEDELSE. Her drejer det sig om at bruge målingerne aktivt i pro-jektledelsen. Vi opsætter mål, og vi laver statistiske analyser. På denne måde bliver vi også i stand til at kunne forudsige værdier om projektet, f.eks. omkring antal fejl.
Niveau 5 – Det optimerende niveau (eng.: Optimizing)
Her forsøger vi hele tiden at gøre tingene endnu bedre ved en konstant fin-tuning af vores processer.
På niveau 5 beherskes følgende procesområder:
– ORGANISATORISK FORNYELSE OG UDBREDELSE. Formålet er her at udvælge og udbre-de udbre-de forbedringer til vores processer som vi fra målingerne ved har en virkning.
– ÅRSAGSANALYSE OG FORBEDRING. Formålet med aktiviteterne i dette område er sy-stematisk at finde årsagerne til fejl for herigennem at forhindre at de gentager sig.
Er dit firma ISO9001-certificeret, er der ingen garanti for at I har styr på softwareudvik-lingen set i CMMI-perspektiv. Typisk vil en ISO9001-certificeret virksomhed opfylde de fleste af procesområderne på CMMI niveau 2 og mange af dem på niveau 3. Så en så-dan virksomhed vil formentlig befinde sig et sted mellem niveau 2 og 3 på CMMI-ska-laen. Men det er ikke sikkert.
Som et kuriosum kan nævnes at ifølge Software Engineering Institute ligger 40% af softwarevirksomhederne på niveau 4 eller 5 i Indien. Du kan på SEIs hjemmeside finde den aktuelle fordeling af virksomheder på de fem niveauer.
Der findes som nævnt endnu flere modenhedsmodeller som alle også kan findes på www.sei.cmu.edu. F.eks. findes en modenhedsmodel for anskaffelse, så hvis du kom-mer fra indkøbssiden, kan du kigge på Software Acquisition Capability Maturity Mo-del, SA-CMMI. Her vil det også være relevant at kigge på EUs model for anskaffelses-projekter, ISPL: Information System Procurement Library (tidligere kendt som Euro-method – se [Hughes99]).
Der findes i øvrigt en europæisk pendant til CMMI. Den kaldes Bootstrap (se [Ku-vaja94]). En selvevaluering i miniformat kan hentes gratis på www.esi.es/Bootcheck.
Der findes også en ISO-standard for modenhedsvurdering. Den gik tidligere under navnet SPICE efter projektgruppen der udviklede den (Software Process Improvement
and Capability dEtermination), men kaldes nu ISO/IEC 15504. Læs mere om den i [Emam97] eller på nettet.