RUT - utvecklingshandbok 10.7 Användning av CMM v 1.2

1999-05-27 LiTH RUT - utvecklingshandbok 10.7 Användning av CMM v 1.2 Nicklas Eriksson (version 1.0) Örjan Blohm (version 1.1) Björn Wingman (version 1.2) Mattias Kling (version1.3) SAMMANFATTNING Software Engineering Institute, SEI, har tagit fram en modell som används allt mer inom mjukvaruindustrin och som anses allt viktigare. Modellen heter Capability Maturity Model (CMM) och syftar till höja en organisations processutvecklingsmognad genom att peka ut kritiska områden för förbättringar i organisationen. CMM beskriver en mognadsskala numrerad från 1 till 5, där nivå 1 är sämst och nivå 5 är bäst. Då ett företag börjar använda CMM befinner det sig i allmänhet på nivå 1 som kännetecknas av kaotiskt utvecklingsarbete och fördyrade och försenade projekt. Idag finns endast ett fåtal företag i världen som har uppnått nivå 5, där man behärskar alla styrmedel som krävs för att garantera att projekt blir klara i tid och med hög kvalitet. RUT - utvecklingshandbok 10.7 Användning av CMM v 1.2 1

Användningsområde 1 Användningsområde Capability Maturity Model, från och med nu förkortat CMM, är ett instrument för att utveckla företagets rutiner mot ett mer planerat och förutsägbart projektarbete. Speciell hänsyn tas till förmågan att genomföra projekt, samt organisationens mognad vid genomförandet av projektet. Målet med denna metod är att man ska öka både förmågan att genomföra ett projekt och organisationens mognadsgrad. Ett företag som ligger lågt på CMM:s skala har förmodligen improviserade och ineffektiva processer. Även om det skulle finnas en planering så följs denna troligen inte. Ständiga kriser karakteriserar detta företag och på grund av dessa blir kvaliteten och funktionaliteten på systemet lidande för att man ska bli färdig till deadline. Detta medför att kvaliteten på produkterna blir varierande. Ett företag som ligger högre på CMM:s skala har dokumenterad erfarenhet från tidigare projekt och kan därför göra realistiska planer. Planerarna upptäcker brister i tid för att hinna bekämpa dessa och kan ändra processen för att sedan slippa dessa brister i kommande projekt. 1.1 Läsanvisningar Läsaren bör ha i åtanke att alla översättningar av termer i denna processbeskrivning är utförda av olika studenter eftersom ingen har kunnat finna någon svensk officiell översättning. Det rekommenderas att läsaren kontrollerar termers engelska motsvarighet i avsnitt 12. Vidare gäller att CMM är mycket omfattande och för att använda metoden på ett korrekt sätt krävs utbildning som ligger långt utanför detta dokuments ambitionsnivå. Därför får läsaren se detta som en översiktlig introduktion till metoden. 2 Förutsättningar Innan en organisation bestämmer sig för att börja introducera CMM bör de noga överväga detta då det kommer att leda till mycket stora förändringar. Man bör även ha goda resurser både vad gäller ekonomi och personal eftersom mognaden enligt CMM tar lång tid och personalen måste känna sig motiverad genom hela processen. Ständig kompetensökning måste ske för att utvecklingen inte skall stagnera. När organisationens ledning väl bestämt sig för att använda sig av CMM, bör de ge en CMM-expert i uppdrag att undersöka vad som behövs för den aktuella organisationen. Trots att det är ett stort steg som kommer att ta år att genomföra och för alltid prägla organisationens arbete, säger tidigare erfarenheter att det lönar sig genom kortare utvecklingscykler, nöjdare kunder och en väl motiverad personal. 2 RUT - utvecklingshandbok 10.7 Användning av CMM v 1.2

Genomförande Resterande avsnitt i detta kapitel är avsett som en introduktion till CMM med tonvikten på termer och koncept. 3 Genomförande 3.1 Översikt Innan vi kan diskutera hur metoden används, måste den använda terminologin introduceras och förklaras. Detta är syftet med detta avsnitt. 5 - Optimerande 4 - Kontrollerad 1 - Initial 2 - Repeterbar 3 - Definierad Processmognad Figur 1. Mognadsnivåerna i CMM Kort beskrivning av mognadsnivåerna Se Figur 1. för en översikt av de fem mognadsnivåer som beskrivs av CMM. Nedan följer en kortfattad beskrivning av vad som kännetecknar en organisation på de olika mognadsnivåerna. Nivå 1 (Initial) Den lägsta nivån är nivå 1 som inte är en stabil miljö för att utveckla programvara. Organisationen har ofta problem med att leverera system på de utsatta tidpunkterna vilket medför att det regelbundet uppstår kriser. Under sådana kriser överger man planering och eventuellt kvalitetstänkande för att istället koda och testa. Organisationen lyckas förmodligen färdigställa systemet, dock ofta med förseningar och en sprucken budget som följd (se Figur 2.). Man är beroende av att individerna i utvecklingsgruppen utför hjältedåd för att få produkten levererad, och inte organisationen själv. Om den eller de personer som håller ihop utvecklingsarbetet skulle lämna företaget, kan man vänta sig en tid av kaos och misslyckanden. Nivån har fått sitt namn av det faktum att det är den nivå som en organisation hamnar på när den inte vidtagit några åtgärder för att öka processutvecklingsförmågan. RUT - utvecklingshandbok 10.7 Användning av CMM v 1.2 3

Genomförande Nivå 2 (Repeterbar) På denna nivå klarar man av att upprepa resultaten från liknande projekt eftersom man har infört grundläggande rutiner för planering och övervakning av arbetet. Projektledarna bevakar kostnader och planering, eventuella problem tas om hand när de dyker upp. Den planerade projekttiden blir lite längre än på nivå 1, men flera projekt klarar det uppsatta målet, fast fortfarande blir en stor del kraftigt försenade. På denna nivå måste organisationen vara mycket disciplinerad för att allt ska fungera. Namnet kommer sig just av att organisationen nu har förmågan att upprepa (repetera) de saker som var bra med tidigare, liknande projekt. Nivå 3 (Definierad) På denna nivå ska allt som har med programutvecklingen vara dokumenterat, både programvaruproduktionen och planeringen. Allt är standardiserat och konsistent. Arbete, kostnad och planering hålls under kontroll och kvaliteten följs upp. Arbetet karakteriseras av en gemensam förståelse av roller och ansvar i hela organisationen. Projektens sluttid blir mer koncentrerat kring det utsatta målet och sannolikheten för att projektet ska vara mycket försenat är måttlig. Projekttiden blir kortare jämfört med nivå 2 (se Figur 2.). Nivåns namn syftar på att organisationen nu på ett precist sätt har definierat hur sitt utvecklingsarbete skall gå till. Nivå 4 (Kontrollerad) Här sätter man upp kvantitativa och kvalitativa mål på produkter, processer och metoder enligt väldefinierade mått. Man har kontroll på både produkten och processerna och resultatet går att förutsäga. Variation i tidsåtgång och kvalitet kan förutses och planeras för, och tidsplanen hålls inom en viss känd felmarginal. De flesta projekt blir färdiga på utsatt tid och den beräknade projekttiden är i snitt ännu kortare (se Figur 2.). Som namnet antyder kan organisationer på denna nivå kontrollera och styra sitt utvecklingsarbete för att klara av att nå målet på rätt tid och med bibehållen kvalitet. Nivå 5 (Optimerande) På denna nivå gör man kontinuerligt förbättringar i processerna. Man har metoder för att hitta och åtgärda svagheter i processen innan de kommer till uttryck. Slöseri med resurser är oacceptabelt och de allra flesta projekt är slutförda vid det planerade leveransdatumet. Den sista nivån har fått sitt namn p.g.a. att organisationen nu kontinuerligt söker förbättra (optimera) de processer som styr utvecklingsarbetet. 4 RUT - utvecklingshandbok 10.7 Användning av CMM v 1.2

Genomförande Sannolikhet Sannolikhet Sannolikhet Sannolikhet Sannolikhet Beräknat leveransdatum Tid Fördelning av leveransdatum Tid Tid Tid Tid Optimerande (5) Kontrollerad (4) Definierad (3) Repeterbar (2) Initial (1) Figur 2. Organisationens förmåga att slutföra projekt i tid. CMM s struktur Figur 3. visar kopplingen mellan de termer som CMM definierar. En mycket central sådan term är mognadsnivå, som omtalats ovan. En mognadsnivå är en väldefinierad platå i evolutionen mot en mer mogen mjukvaruprocess. Varje mognadsnivå består av ett antal nyckelprocessområden. Dessa nyckelprocessområden identifierar en mängd relaterade aktiviteter som, då de utförs tillsammans, anses viktiga för att höja processförmågan. Nyckelprocessområdena är avsiktligt gjorda så att de helt skall hamna på en specifik mognadsnivå. En organisation måste uppfylla alla nyckelprocesser i en viss nivå för att uppnå denna nivå. Till varje nyckelprocessområde hör ett antal mål som alla måste uppnås för att organisationen skall kunna sägas ha uppnått det. En starkare term som används ibland är institutionalisering. Man säger att man har institutionaliserat den processförmåga som karaktäriseras ett nyckelprocessområde, då RUT - utvecklingshandbok 10.7 Användning av CMM v 1.2 5

Genomförande man på en kontinuerlig basis uppnått det nyckelprocessområdets samtliga mål. Ett nyckelprocessområde är organiserat i fem underavdelningar som kallas gemensamma drag. Dessa skall ange om nyckelprocessområdet har implementerats och institutionaliserats på ett effektivt och varaktigt sätt. De gemensamma dragen består i sin tur av ett antal nyckelaktiviteter som beskriver den infrastruktur och de aktiviteter som mest bidrar till en effektiv implementation och institutionalisering av nyckelprocessområdet. Mognadsnivåer indikerar består av Processförmåga Nyckelprocessområden uppnår organiserade genom Mål Gemensamma drag Implementering eller institutionalisering pekar ut består av Nyckelaktiviteter Infrastruktur eller aktiviteter beskriver Figur 3. Strukturen på CMM Nyckelprocessområden Som framgår av Figur 4 består varje mognadsnivå av en mängd nyckelprocessområden. Dessa skall samtliga vara implementerade för att organisationen skall kunna sägas befinna sig på den nivån. Undantaget är dock nivå 1 som inte kan ha några nyckelprocessområden eftersom det inte ställs några krav på en nivå 1 - organisation. Nyckelprocessområde är ett samlingsnamn för en grupp av aktiviteter, och visar på vad organisationen bör koncentrera sig på för att nå en högre mognadsgrad. Alla processer som berör programutveckling finns inte med utan bara de som har identifierats som avgörande för organisationens processkicklighet. Många processer utvecklas successivt mellan nivåerna. 6 RUT - utvecklingshandbok 10.7 Användning av CMM v 1.2

Genomförande Nedan beskrivs kortfattat de olika nyckelprocessområderna nivå för nivå. Optimerande (5) Kontinuerligt förbättrande process Kontrollerat processbyte Kontrollerat teknikbyte Felförebyggande åtgärder Kontrollerad (4) Förutsägbar process Kvantitativ processtyrning Kvalitetsstyrning Definierad (3) Standardiserad process Organisationens processfokus Organisationens processdefinition Integrerad mjukvarustyrning Mjukvaruproduktion Koordination mellan grupper Utbildningsprogram Granskningar Repeterbar (2) Diciplinerad process Kravhantering Projektplanering Projektuppföljning Underleverantörshantering Kvalitetssäkring Konfigurationskontroll Initial (1) Figur 4. Nyckelprocessområden för de olika mognadsnivåerna Nivå 1 Eftersom man inte kan befinna sig lägre än på nivå 1 så kan man inte definiera några nyckelprocessområden på denna nivå. RUT - utvecklingshandbok 10.7 Användning av CMM v 1.2 7

Genomförande Nivå 2 Kravhantering behövs och denna ska se till att kunden och projektgruppen ska få en gemensam bild av kundens krav. Detta är nödvändigt för att planering och ledning av projektet ska lyckas. Projektplanering bestämmer hur utveckling och ledning av projektet ska utföras. Det är viktigt att denna är förnuftigt upplagd eftersom hela projektet bygger på denna. Projektuppföljning är nödvändigt för att de som leder projektet ska ha kontroll och kunna ta nödvändiga beslut om projektet glider ifrån planeringen. Underleverantörshantering syftar till att kontrollera att underleverantörer uppfyller sina åtaganden och följer uppsatta standarder. Kvalitetssäkring används för att ge ledningen insyn i projektarbetet och därigenom en möjlighet att på ett tidigt skede korrigera eventuella avvikelser. Konfigurationskontroll används för att den utvecklade produkten skall bibehålla sin integritet genom projektets livstid. Nivå 3 Organisationens processfokus syftar till att finna organisationens tillgångar med avseende på processutveckling samt att upprätta en ansvarsfördelning. Organisationens processdefinition betyder att man skapar en tillgång på processer som ska hjälpa till vid projektledning. De kan man sedan använda som grund vid utbildning. Utbildningsprogram är nödvändigt för att utveckla skickligheten och kunskapen hos personer som jobbar inom projektet. Integrerad mjukvarustyrning fås genom att integrera programutvecklingen och projektledning till en sammanhängande väldefinierad process. Sedan skräddarsys verksamhetens miljö och de tekniska hjälpmedel som behövs för att projektet ska fungera. Mjukvaruproduktion ska vara en väldefinierad process som integrerat alla tekniska aktiviteter som analys, design, kodning, testning m.m. Detta för att man ska producera en bra produkt på ett effektivt sätt. Koordination mellan grupper bör utarbetas för att utvecklingsgrupperna ska kunna sammarbeta så att projektet genomförs på bästa sätt. Granskningar är ett effektivt sätt att få bort defekter på nya processer på ett så tidigt stadium som möjligt genom att titta på redan genomförda projekt. Granskningar kan genomföras på ett antal olika sätt, t.ex. genom inspektioner. Nivå 4 Kvantitativ processtyrning betyder att man försöker att kontrollera processernas prestanda i projektet. Prestandan bestäms genom att man studerar de verkliga resultaten från projektet. Man försöker speciellt att hitta anledningar till variation i resultatet, för att sedan korrigera dem om det är möjligt. 8 RUT - utvecklingshandbok 10.7 Användning av CMM v 1.2

Genomförande Kvalitetsstyrning behövs för att uppskatta produkternas kvalitet för att sedan jämföra med de uppsatta målen. Nivå 5 Felförebyggande åtgärder betyder att man försöker identifiera orsaker till defekter på produkten och ändra den definierade processen så att dessa brister förebyggs. Kontrollerat teknikbyte behövs för att utvärdera nya tekniker, verktyg och metoder som kan förbättra effektiviteten i processerna, och att sprida dessa nya tekniker i organisationen på ett organiserat sätt. Kontrollerat processbyte görs för att hela tiden öka organisationens kvalitet och produktivitet och minska utvecklingstiden. Gemensamma drag Varje nyckelprocessområde är uppdelade i fem grupper som kallas gemensamma drag. Dessa innehåller något som kallas nyckelaktiviteter vilka syftar till att försäkra att nyckelprocessområdet har implementerats och instutionaliserats på ett effektivt och varaktigt sätt. Nedan beskrivs de olika gemensamma dragen kortfattat. Åtaganden beskriver hur en organisation ska försäkra sig om att en process har etablerats på ett permanent sätt. Detta omfattar bl.a. organisationens högsta ledning. Förutsättningar beskriver vilka villkor som måste vara uppfyllda för att en organisation ska lyckas i genomförande av en process. Villkoren kan t.ex. vara speciella resurser, struktur på organisationen och utbildning. Aktiviteter beskriver vilka regler och metoder som behövs för att klara av målen förknippade med ett nyckelprocessområde. Detta involverar hur man planerar för, utför och följer upp sitt arbete. Mätning och analys beskriver vilka behov man har av mätning på processer och analys av mätresultat för att bestämma status och effektivitet för processer. Verifiering syftar till att försäkra sig om att man genomför sitt arbete efter de processer man definierat. Typiskt omfattar detta olika granskningar. Det som nämns under Aktiviteter är det som måste uppfyllas för att klara av en viss processförmåga. De andra punkterna kan ses som hjälpmedel för att intitutionalisera dessa aktiviteter. Nyckelaktiviteter Nyckelaktiviteter beskriver strukturer och aktiviteter som på bästa sätt förverkligar målen i sitt nyckelprocessområde. Varje nyckelaktivitet består av en enkel mening som sedan är kopplad till en beskrivning som eventuellt förtydligats med exempel. Alla dessa nyckelaktiviteter finns sammanställda i [3]. RUT - utvecklingshandbok 10.7 Användning av CMM v 1.2 9

Genomförande 3.2 Detaljbeskrivning CMM definierar en mängd kriterier avsedda att bedömma en organisations mognad. Dessa kan användas av en organisation både till att förbättra sin egen utvecklingsprocess samt till att bedömma risker vid kontraktssituationer mot andra företag. Det finns två besläktade metoder för att bedömma en organisations mognad. Metoderna har många likheter, men målet med deras användning är olika. CMM är en gemensam grund för båda. Metoderna är: Processbedömning används av en organisation för att bedömma status för aktuella utvecklingsprocesser. Detta med syftet att peka ut viktiga områden för förbättringar. Man studerar vanligtvis sin egen organisation. Utvärdering av förmåga används för att identifiera vilken leverantör som innebär minst risk innan kontrakt skrivs. Metoden kan också användas för att värdera utvecklingsprocesser i löpande projekt. Här studerar man vanligtvis andra organisationer än sin egen. 3.3 Metod Trots att processbedömningen och utvärdering av förmåga har olika mål, använder de sig av en gemensam metod som kortfattat beskrivs i detta avsnitt. Metoden har sex steg vilka visas grafiskt i Figur 5., och förklaras nedan. 1. Först väljer man medlemmar till gruppen som skall genomföra utvärderingen eller bedömningen. Dessa personer bör samtliga vara väl förtrogna med CMM, mjukvaruutveckling och projektstyrning. 2. Den undersökta organisationen eller gruppen fyller i enkäter om organisationens verksamhet och genomför eventuellt också andra diagnostiska tester. Syftet med detta är att få underlag för nästa steg. 3. Svaren från föregående steg analyseras. Man identifierar vilka områden som man bör fokusera på i framtiden. Dessa områden motsvarar CMM:s nyckelprocessområden. 4. Undersökningsgruppen besöker nu objektet för att där undersöka processer och granska dokument m.m. CMM:s nyckelprocessområden och nyckelaktiviteter leder undersökningsgruppen i arbetet att undersöka om nyckelprocessområdenas olika mål är uppfyllda. 5. Organisationens starka respektive svaga sidor sammanställs. Om man genomför man en processbedömning blir denna sammanställning basen för ett processförbättringsförslag. Rör det sig istället om en utvärdering av förmåga kommer sammanställningen att utgöra en väsentlig del av riskanalysen för den leverantören. 6. Slutligen sammanfattas resultaten i något som kallas en KPA-profil (som på svenska skulle bli NPO-profil eftersom Key Process Areas översätts till NyckelProcessOmråde). Profilen visar grafiskt vilka av de olika nyckelprocessområdenas mål som har uppfyllts respektive inte uppfyllts. 10 RUT - utvecklingshandbok 10.7 Användning av CMM v 1.2

Resultat (1) (2) (3) Välj undersökningsgrupp Mognadsenkät testar CMMkriterier Analys av svar (4) Platsbesök Intervjuer och granskningar Resultat baserat på CMM (5) KPA-profil (6) Figur 5. Gemensamma steg i bedömning och utvärdering 4 Resultat 4.1 Produkter Då man genomgått denna metod får man ett mått på vilken mognadsgrad som organisationen befinner sig på. Man får även reda på vilka områden som måste förbättras för att få en effektivare organisation. Detta i form av en KPA- profil. 4.2 Produktmallar Det går inte att skilja produkter från produktmallar när man diskuterar CMM. 5 Mallar och blanketter Det finns ett antal mallar som kan användas i arbetet med CMM. Dock är dessa alltför omfattande för att inkluderas i sin nuvarande form. Dessutom är de på engelska och en översättning blir komplicerad. 6 Kontroll av resultatet Hur man tolkar KPA-profiler och andra utdata från användandet av CMM är något som kommer i en senare version av dokumentet. RUT - utvecklingshandbok 10.7 Användning av CMM v 1.2 11

Exempel med förklaringar 7 Exempel med förklaringar Ett exempel på ett företag som använt metoden är Ericsson, i [4] beskrivs vad de kom fram till. De hamnade på nivå 1 och det är på denna nivå som större delen av dagens programutvecklinsföretag befinner sig. Ericsson räknar med att det ska ta ett par år innan de nått nästa nivå. De siktar inte på att komma till den högsta nivån eftersom denna inte är realistisk för de system som företaget utvecklar. 8 Lösning till vanliga problem I dagsläget existerar inte några vanliga problem. 9 Anpassning till PUMPRO-kursen CMM i sin helhet lämpar sig dåligt för en så kort kurs som PUM eftersom det tar mycket lång tid att sätta sig in i metoden. Vidare bygger många tankar i CMM på kontinuitet, vilket blir svårt att simulera i en kurs. Dock kan man göra så att kursledningen ger som direktiv att projekten skall sträva efter t.ex. nivå 2. Även detta kan bli svårt med tanke på studenternas bristande kunskap i kursens början. 12 RUT - utvecklingshandbok 10.7 Användning av CMM v 1.2

Processbeskrivningens historik 10 Processbeskrivningens historik Tabell 1: Historik Version Datum Kommentarer Utfört av 1.3 1999-05-27 Rättat en mängd grammatiska fel. Rättat bildtexter. Ytterliga förtydlingar på flera ställen. 1.2 1996-02-14 Rättade språkliga fel, formulerade om för att förtydliga. Lade till en ordlista från svenska till engelska. Utvidgade stycket om genomförande något. 1.1 1996-02-14 Översatte engelska termer till svenska samt förändrade ordlistan till att avspegla detta. Korrigerade språkliga felaktigheter. Lade till en beskrivning av hur metoden skall användas (se kapitel 3). Figur 1., Figur 4. och Figur 5. har införts i denna version. Resterande figurer har översatts. Ändrade dokumentet till att följa den nya mallen. Lade till läsanvisningar. Omarbetade all text till att bli mer utförlig. Mattias Kling Björn Wingman Örjan Blohm 1.0 1995-02-16 Nytt dokument. Nicklas Eriksson 11 Föreslagna förändringar som ännu ej åtgärdats Blanketter och enkäter för kontroll av CMM-nivå. Kontrollera om det eventuellt finns officiell översättning till svenska. Lägg till utseende på och tolkning av KPA-profiler. Lägg tilloch samordna med RUT:ar 0.2 och 10.7. 12 Ordlista De officiella engelska termerna kan ha förlorat sin innebörd vid översättningen till svenska och därför har jag inkluderat denna ordlista. Kontakta gärna den senaste författaren om du anser dig ha en bättre översättning av någon term. Jag har tagit en stor del av översättningarna från [5] samt samverkat med författaren till [6]. 12.1 Engelska till svenska ability to perform activities performed capability commitment to perform common features defect prevention implementation institutionalization integrated software management intergroup coordination förutsättningar aktiviteter skicklighet åtaganden gemensamma drag felförebyggande åtgärder implementation institutionalisering integrerad mjukvarustyrning koordination mellan grupper RUT - utvecklingshandbok 10.7 Användning av CMM v 1.2 13

Ordlista key practices key process area maturity maturity level measurement and analysis organization process definition organization process focus peer reviews process capability process change management quantitative process management requirements management software capability evaluation software configuration management software process assessment software product engineering software project planning software project tracking and oversight software quality assurance software quality management software subcontract management technology change management training program verifying implementation nyckelaktiviteter nyckelprocessområden mognad mognadsnivå mätning och analys organisationens processdefinition organisationens processfokus granskningar procesförmåga kontrollerat processbyte kvantitativ processtyrning kravhantering utvärdering av förmåga konfigurationskontroll processbedömning mjukvaruproduktion projektplanering projektuppföljning kvalitetssäkring kvalitetsstyrning underleverantörshantering kontrollerat teknikbyte utbildningsprogram verifiering 14 RUT - utvecklingshandbok 10.7 Användning av CMM v 1.2

Ordlista 12.2 Svenska till engelska aktiviteter felförebyggande åtgärder förutsättningar gemensamma drag granskningar implementation institutionalisering integrerad mjukvarustyrning konfigurationskontroll kontrollerat processbyte kontrollerat teknikbyte koordination mellan grupper kravhantering kvalitetsstyrning kvalitetssäkring kvantitativ processtyrning mjukvaruproduktion mognad mognadsnivå mätning och analys nyckelaktiviteter nyckelprocessområden organisationens processdefinition organisationens processfokus procesförmåga processbedömning projektplanering projektuppföljning skicklighet underleverantörshantering utbildningsprogram utvärdering av förmåga verifiering åtaganden activities performed defect prevention ability to perform common features peer reviews implementation institutionalization integrated software management software configuration management process change management technology change management intergroup coordination requirements management software quality management software quality assurance quantitative process management software product engineering maturity maturity level measurement and analysis key practices key process area organization process definition organization process focus process capability software process assessment software project planning software project tracking and oversight capability software subcontract management training program software capability evaluation verifying implementation commitment to perform RUT - utvecklingshandbok 10.7 Användning av CMM v 1.2 15

Referenser 1 Referenser 1. Capability Maturity Model, Version 1.1 Mark C. Paulk m.fl. Software Engineering Institute Carnegie Mellon University Pittsburgh Pennsylvania 15213 2. Capability Maturity Model for Software, Version 1.1 Mark C. Paulk m.fl. Software Engineering Institute Carnegie Mellon University Pittsburgh Pennsylvania 15213 3. Key Practices of the Capability Maturity Model, Version 1.1 Mark C. Paulk m.fl. Software Engineering Institute Carnegie Mellon University Pittsburgh Pennsylvania 15213 4. Ericsson vill få programutvecklingen under kontroll Cecilia Lindemalm Datateknik nr2-95 5. ISO 9001 versus CMM Thomas Ericson Arbete i kursen Programvarukvalitet (TDDB 03) 1995 6. RUT - utvecklingshandbok 0.2 Jämförelse av RUT och CMM, version 1.0 Roger Isberg, 1996 16 RUT - utvecklingshandbok 10.7 Användning av CMM v 1.2