Capability Maturity Model (CMM) & het zijn niveaus in Software Engineering

Wat is CMM?

Capability Maturity Model wordt gebruikt als een benchmark om de volwassenheid van het softwareproces van een organisatie te meten.

CMM is eind jaren 80 ontwikkeld door het Software Engineering Institute. Het werd ontwikkeld als resultaat van een studie die werd gefinancierd door de Amerikaanse luchtmacht als een manier om het werk van onderaannemers te evalueren. Later gebaseerd op het CMM-SW-model dat in 1991 werd gecreëerd om de volwassenheid van softwareontwikkeling te beoordelen, zijn meerdere andere modellen geïntegreerd met CMM-I.

In deze tutorial zullen we leren,

• Wat zijn Capability Maturity Model (CMM) -niveaus?
• Wat gebeurt er op verschillende CMM-niveaus?
• Hoe lang duurt het om CMM te implementeren?
• Interne structuur van CMM
• Beperkingen van CMM-modellen
• Waarom CMM gebruiken?

Wat zijn Capability Maturity Model (CMM) -niveaus?

1. Eerste
2. Herhaalbaar / beheerd
3. Bepaald
4. Kwantitatief beheerd
5. Optimaliseren

Wat gebeurt er op verschillende CMM-niveaus?

Niveaus	Activiteiten	Voordelen
Niveau 1 initieel	Op niveau 1 is het proces meestal chaotisch en ad hoc Een vaardigheid wordt gekarakteriseerd op basis van de individuen en niet op basis van de organisatie Vooruitgang niet gemeten De producten die worden ontwikkeld, zijn vaak gepland en overschrijden het budget Grote variaties in planning, kosten, functionaliteit en kwaliteitsdoelstellingen	Geen. Een project is Total Chaos
Niveau 2 beheerd	Beheer van vereisten Schat projectparameters zoals kosten, planning en functionaliteit Meet de werkelijke voortgang Ontwikkel plannen en proces Standaarden voor softwareprojecten zijn gedefinieerd Identificeer en controleer producten, probleemrapportages, etc. Processen kunnen verschillen tussen projecten	Processen worden gemakkelijker te begrijpen Managers en teamleden besteden minder tijd aan het uitleggen hoe dingen worden gedaan en meer tijd aan het uitvoeren ervan Projecten worden beter ingeschat, beter gepland en flexibeler Kwaliteit is geïntegreerd in projecten De kosten kunnen in eerste instantie hoog zijn, maar gaan overuren omlaag Vraag meer papierwerk en documentatie
Niveau 3 gedefinieerd	Verduidelijk de eisen van de klant Los ontwerpvereisten op, ontwikkel een implementatieproces Zorgt ervoor dat het product voldoet aan de vereisten en het beoogde gebruik Analyseer beslissingen systematisch Corrigeer en beheers mogelijke problemen	Procesverbetering wordt de standaard Oplossing evolueert van 'gecodeerd' naar 'ontwikkeld' Kwaliteitspoorten verschijnen tijdens de hele projectinspanning en het hele team is bij het proces betrokken Risico's worden beperkt en overrompelt het team niet
Niveau 4 kwantitatief beheerd	Beheert de projectprocessen en subprocessen statistisch Begrijp de procesprestaties, beheer het project van de organisatie kwantitatief	Optimaliseert de procesprestaties in de hele organisatie Bevordert kwantitatief projectmanagement in een organisatie.
Niveau 5 optimaliseren	Detecteer en verwijder de oorzaak van defecten vroegtijdig Identificeer en implementeer nieuwe tools en procesverbeteringen om aan behoeften en bedrijfsdoelstellingen te voldoen	Bevordert organisatorische innovatie en implementatie Geeft een impuls aan causale analyse en oplossing

Het volgende diagram geeft een picturale weergave van wat er op verschillende CMM-niveaus gebeurt

Hoe lang duurt het om CMM te implementeren?

CMM is het meest wenselijke proces om de kwaliteit van het product te behouden voor elk softwareontwikkelingsbedrijf, maar de implementatie ervan duurt iets langer dan verwacht.

• CMM-implementatie vindt niet van de ene op de andere dag plaats
• Het is gewoon niet alleen een "papierwerk".
• Typische tijden voor implementatie zijn
  • 3-6 maanden -> voor voorbereiding
  • 6-12 maanden -> voor implementatie
  • 3 maanden -> ter voorbereiding van de beoordeling
  • 12 maanden -> voor elk nieuw niveau

Interne structuur van CMM

Elk niveau in CMM wordt gedefinieerd in het sleutelprocesgebied of KPA , behalve niveau-1. Elke KPA definieert een cluster van gerelateerde activiteiten, die, wanneer ze gezamenlijk worden uitgevoerd, een reeks doelen bereiken die als essentieel worden beschouwd voor het verbeteren van de softwarecapaciteit

Voor verschillende CMM-niveaus zijn er sets van KPA's, bijvoorbeeld voor CMM-model-2 zijn KPA's

• REQM - Beheer van vereisten
• PP- Projectplanning
• PMC- Projectbewaking en -controle
• SAM- Beheer van leveranciersovereenkomsten
• PPQA-proces en kwaliteitsborging
• CM-configuratiebeheer

Evenzo heb je voor andere CMM-modellen specifieke KPA's. Om te weten of de implementatie van een KPA effectief, duurzaam en herhaalbaar is, wordt deze op de volgende basis in kaart gebracht

1. Toewijding om te presteren
2. Vermogen om te presteren
3. Activiteiten presteren
4. Meting en analyse
5. Implementatie verifiëren

Beperkingen van CMM-modellen

• CMM bepaalt wat een proces moet aanpakken in plaats van hoe het moet worden geïmplementeerd
• Het verklaart niet elke mogelijkheid tot verbetering van softwareprocessen
• Het concentreert zich op softwareproblemen, maar houdt geen rekening met strategische bedrijfsplanning, het toepassen van technologieën, het opzetten van een productlijn en het beheren van human resources
• Het zegt niet in wat voor soort bedrijf een organisatie zou moeten zijn
• CMM zal niet nuttig zijn in het project dat momenteel in crisis verkeert

Waarom CMM gebruiken?

Tegenwoordig fungeert CMM als een "keurmerk" in de software-industrie. Het helpt op verschillende manieren om de softwarekwaliteit te verbeteren.

• Het leidt naar een herhaalbaar standaardproces en verkort zo de leertijd om dingen voor elkaar te krijgen
• Het oefenen van CMM betekent het oefenen van het standaardprotocol voor ontwikkeling, wat betekent dat het niet alleen het team helpt om tijd te besparen, maar ook een duidelijk beeld geeft van wat te doen en wat te verwachten
• De kwaliteitsactiviteiten passen goed bij het project en worden niet als een afzonderlijk evenement beschouwd
• Het fungeert als een pendelaar tussen het project en het team
• CMM-inspanningen zijn altijd gericht op verbetering van het proces

Overzicht

CMM werd voor het eerst geïntroduceerd in de late jaren 80 bij de Amerikaanse luchtmacht om het werk van onderaannemers te evalueren. Later, met een verbeterde versie, werd het geïmplementeerd om de kwaliteit van het softwareontwikkelingssysteem te volgen.

Het volledige CMM-niveau is onderverdeeld in vijf niveaus.

• Niveau 1 (initieel): Waar vereisten voor het systeem meestal onzeker, verkeerd begrepen en ongecontroleerd zijn. Het proces is meestal chaotisch en ad hoc.
• Niveau 2 (beheerd): maak een schatting van de projectkosten, planning en functionaliteit. Softwarestandaarden zijn gedefinieerd
• Niveau 3 (gedefinieerd): zorgt ervoor dat het product voldoet aan de vereisten en het beoogde gebruik
• Niveau 4 (kwantitatief beheerd): beheert de projectprocessen en subprocessen statistisch
• Niveau 5 (volwassenheid): Identificeer en implementeer nieuwe tools en procesverbeteringen om te voldoen aan behoeften en bedrijfsdoelstellingen