Capability Maturity Model Integration
Das Capability Maturity Model Integration (CMMI) der ISACA ist eine Familie von Referenzmodellen für unterschiedliche Anwendungsgebiete – derzeit für die Produktentwicklung, den Produkteinkauf und die Serviceerbringung. Ein CMMI-Modell ist eine systematische Aufbereitung bewährter Praktiken, um die Verbesserung einer Organisation zu unterstützen. Ein CMMI-Modell kann genutzt werden, um
- einen Überblick über bewährte Praktiken (z. B. bei der Projektplanung) zu bekommen,
- die Stärken und Schwächen einer Organisation objektiv zu analysieren oder
- Verbesserungsmaßnahmen zu bestimmen und in eine sinnvolle Reihenfolge zu bringen.
Primär sind die CMMI-Modelle ein Mittel, um die Arbeit einer Organisation zu verbessern. Sekundär sind offizielle Überprüfungen eines Reifegrades (siehe Appraisal) eine in der Industrie de facto anerkannte Auszeichnung. CMMI wird deshalb häufig auch als Reifegradmodell bezeichnet, obwohl die Reifegrade nur ein Aspekt unter vielen von CMMI sind.
Alle CMMI-Modelle ("Constellation" genannt) haben die gleiche Struktur und einen gemeinsamen inhaltlichen Kern. Zurzeit gibt es drei veröffentlichte CMMI-Modelle:
- Das "CMMI for Development" (CMMI-DEV) unterstützt die Verbesserung von Organisationen, die Software, Systeme oder Hardware entwickeln.
- Das "CMMI for Supplier Management" (CMMI-SPM) unterstützt die Verbesserung von Organisationen, die Software, Systeme oder Hardware von Lieferanten beziehen, aber nicht selbst entwickeln (bis Version 1.3 Acquisition (CMMI-ACQ)).
- Das "CMMI for Services" (CMMI-SVC) unterstützt die Verbesserung von Organisationen, die Dienstleistungen erbringen.
Geschichtliche Entwicklung
- 1979 veröffentlichte Philip B. Crosby das Quality Management Maturity Grid, welches als Vorläufermodell des CMMI gilt.
- 1986 begann auf Initiative des US-Verteidigungsministeriums das Software Engineering Institute (SEI) an der Carnegie Mellon University/Pittsburgh, welches dem US-Verteidigungsministerium untersteht, mit der Entwicklung eines Systems zur Bewertung der Reife von Softwareprozessen.
- 1991 wurde das Modell als Capability Maturity Model 1.0 herausgegeben.
- 1993 wurde CMM überarbeitet und in der Version 1.1 bereitgestellt.
- 1997 wurde CMM 2.0 kurz vor der Verabschiedung vom US-Verteidigungsministerium zurückgezogen und das CMMI-Projekt gestartet.
- 2000 wurde CMMI – damals noch unter dem Namen Capability Maturity Model Integrated – als Pilotversion 1.0 herausgegeben.
- 2002 wurde CMMI unter dem neuen Namen Capability Maturity Model Integration (kurz CMMI) freigegeben.
- 2003 ist die Unterstützung des SEI für die alte Version CMM ausgelaufen, und
- seit 2005 liefen die Lizenzen der Assessmentleiter für CMM aus. D. h., es gibt keine offiziellen CMM-Assessments mehr.
- 2006 ist die neue Version 1.2 des CMMI veröffentlicht worden. Mit dieser sind einige grundlegende Veränderungen einhergegangen. So wurde u. a. die neue Version in CMMI-DEV (CMMI for Development) umbenannt.
- 2007 ist die Version 1.2 des CMMI for Acquisition erschienen.
- 2009 ist die Version 1.2 des CMMI for Services erschienen.
- 2010 wurde eine Version 1.3 aller CMMI-Modelle (CMMI-DEV, CMMI-ACQ, CMMI-SVC) herausgegeben.[1]
- 2018 erschien die Version 2.0 von CMMI-DEV, CMMI-SVC und CMMI Supplier Management (SPM). Letzteres ist die neue Bezeichnung des bisherigen CMMI-ACQ.[2]
Einordnung der CMMI-Modelle
Die CMMI-Modelle sind Referenzmodelle, die bewährte Praktiken zusammenfassen. Im Gegensatz zu einem konkreten Vorgehensmodell definiert ein CMMI-Modell grundsätzliche Praktiken z. B. einer guten Produktentwicklung (das „Was“), aber keine konkreten Schritte (das „Wie“). Das primäre Ziel der CMMI-Modelle ist es, eine kontinuierliche Prozessverbesserung zu unterstützen, indem Praktiken bzw. Kriterien von einer professionellen Organisation definiert werden. Die konkrete und adäquate Ausgestaltung der Arbeit bzw. Arbeitsweise obliegt der Organisation und ist eine wichtige Teilaufgabe der Prozessverbesserung. Da CMMI keine konkrete Vorgehensweise definiert, kann CMMI auf sehr unterschiedliche Organisationen und Organisationsgrößen angewendet werden. So kann z. B. die Forderung von CMMI, dass bei der Projektplanung eine Zustimmung der Projektbeteiligten (Stakeholder) zum Projektplan eingeholt werden muss, auf sehr unterschiedliche Art und Weise konkret in einer Organisation umgesetzt werden. Es gibt daher nicht „die eine“ richtige CMMI-Umsetzung.
Eine besondere Eigenschaft der CMMI-Modelle ist, dass sie nicht nur auf die fachlichen Praktiken eingehen, sondern auch auf die unterstützenden Aufgaben der Organisation, wie z. B. Ressourcen-Bereitstellung oder Durchführung von Trainingsmaßnahmen. Ein weiteres besonderes Merkmal ist, dass CMMI sehr viel Wert auf den gelebten Prozess legt und so im Gegensatz zu solchen – häufig als „Schrankware“ bezeichneten – Prozessen steht, die dokumentiert, aber nicht gelebt werden.
Aufbau eines CMMI-Modells
Ein CMMI-Modell definiert eine Reihe von Prozessgebieten (z. B. Projektplanung, Anforderungsentwicklung, organisationsweite Prozessdefinition). Ein Prozessgebiet (Process Area) spezifiziert Ziele und bewährte Praktiken einer professionellen Arbeit. Beispiel: Beim Prozessgebiet „Projektplanung“ sind die Ziele „Schätzungen aufstellen“, „Einen Projektplan entwickeln“ und „Verpflichtung auf den Plan herbeiführen“. Die Praktiken zum Ziel „Schätzungen aufstellen“ sind „Umfang des Projekts schätzen“, „Attribute der Arbeitsergebnisse und Aufgaben schätzen“, „Projektlebenszyklus definieren“ und „Schätzungen von Aufwand und Kosten aufstellen“. Für die Prozessgebiete, Ziele und Praktiken gibt CMMI jeweils zusätzliche erklärende Informationen. So wird z. B. jedes Prozessgebiet zunächst erläutert und andere in Verbindung stehende Prozessgebiete aufgezählt. Danach werden die Ziele und Praktiken aufgeführt. Jede Praktik wird durch einen Erklärungstext, durch typische Arbeitsergebnisse und durch typische Arbeitsschritte weiter erläutert. Diese Hinweise sollen bei der Umsetzung helfen, sind aber keine Prüfgrundlage in einer Einschätzung (Appraisal).
Die Prozessgebiete werden in Kategorien eingeteilt. Bei allen drei CMMI-Modellen sind dies:
- Projektmanagement (Project Management) bzw. im CMMI for Services Arbeitsmanagement (Work Management)
- Unterstützung (Support)
- Prozessmanagement (Process Management).
Die Prozessgebiete dieser Kategorien sind in den drei CMMI-Modellen grundsätzlich ähnlich, allerdings unterscheiden sich die Prozessgebiete teilweise. So spricht z. B. CMMI for Services von Arbeitsmanagement und CMMI for Development von Projektmanagement, da Dienstleistungen häufig durch Teams und Entwicklungen typischerweise durch Projekte umgesetzt werden.
Prozessmanagement bzw. Prozessverbesserung sind vor allem eine organisationsweite Aufgabe. Die Prozessgebiete in der Kategorie Unterstützung werden in manchen Organisationen projekt- oder teamspezifisch, in manchen Organisationen organisationsweit umgesetzt.
Jedes der drei CMMI-Modelle hat jeweils eine weitere Kategorie, in der die für das entsprechende Anwendungsgebiet spezifischen Prozessgebiete enthalten sind:
- Beim CMMI for Development: Entwicklung (Engineering)
- Beim CMMI for Acquisition: Beschaffung (Acquisition)
- Beim CMMI for Services: Etablierung und Lieferung von Services (Service Establishment and Delivery)
Diese Struktur bei den CMMI-Modellen von gemeinsamen Kategorien und spezifischen Kategorien ist einer der großen Vorteile von CMMI. Auf der einen Seite werden die spezifischen Themen adressiert (wie z. B. Services), andererseits lassen sich die CMMI-Modelle durch den gemeinsamen Kern und die gemeinsame Struktur nahtlos miteinander kombinieren. Letzteres ist insbesondere für Organisationen interessant, die z. B. sowohl Entwicklung als auch Services anbieten (z. B. IT-Entwicklung und IT-Services, oder Entwicklung von Autos und Wartung von Autos). Solche Organisationen finden in der CMMI-Familie ein aufeinander abgestimmtes Set von Modellen, so dass Verbesserungen übergreifend "gedacht" werden können.
Prozessgebiete des CMMI for Development Version 1.3
Die folgende Tabelle führt die Prozessgebiete des CMMI for Development Version 1.3 auf – und die Zuordnung der Prozessgebiete zu den Kategorien, und Reifegraden.
| Prozessgebiet (engl.) | Prozessgebiet (dt.) | Kategorie | Reifegrad |
|---|---|---|---|
| Causal Analysis and Resolution (CAR) | Ursachenanalyse und Problemlösung | Support | 5 |
| Configuration Management (CM/SCM) | Konfigurationsmanagement | Support | 2 |
| Decision Analysis and Resolution (DAR) | Entscheidungsanalyse und -findung | Support | 3 |
| Integrated Project Management (IPM) | Integriertes Projektmanagement | Project Management | 3 |
| Measurement and Analysis (MA) | Messung und Analyse | Support | 2 |
| Organizational Performance Management (OPM) | Organisationsweites Prozessfähigkeitsmanagement | Process Management | 5 |
| Organizational Process Definition (OPD) | Organisationsweite Prozessdefinition | Process Management | 3 |
| Organizational Process Focus (OPF) | Organisationsweiter Prozessfokus | Process Management | 3 |
| Organizational Process Performance (OPP) | Organisationsweite Prozessfähigkeit | Process Management | 4 |
| Organizational Training (OT) | Organisationsweites Training | Process Management | 3 |
| Product Integration (PI) | Produktintegration | Engineering | 3 |
| Project Monitoring and Control (PMC) | Projektverfolgung und -steuerung | Project Management | 2 |
| Project Planning (PP) | Projektplanung | Project Management | 2 |
| Process and Product Quality Assurance (PPQA) | Qualitätssicherung von Prozessen und Produkten | Support | 2 |
| Quantitative Project Management (QPM) | Quantitatives Projektmanagement | Project Management | 4 |
| Requirements Development (RD) | Anforderungsentwicklung | Engineering | 3 |
| Requirements Management (REQM) | Anforderungsmanagement | Project Management | 2 |
| Risk Management (RSKM) | Risikomanagement | Project Management | 3 |
| Supplier Agreement Management (SAM) | Management von Lieferantenvereinbarungen | Project Management | 2 |
| Technical Solution (TS) | Technische Umsetzung | Engineering | 3 |
| Validation (VAL) | Validierung | Engineering | 3 |
| Verification (VER) | Verifizierung | Engineering | 3 |
Institutionalisierung und Fähigkeitsgrade
Neben den fachlichen Praktiken, die spezifisch für ein Prozessgebiet sind, spricht CMMI auch explizit die Thematik der Institutionalisierung an. Mit „Institutionalisierung“ ist gemeint, dass die Arbeitsweisen in der Organisation selbstverständlich und als Teil der täglichen Arbeit gelebt werden. Insbesondere in Zeiten von Stress haben institutionalisierte Arbeitsweisen Bestand. Neben den fachlichen Praktiken definiert CMMI Praktiken, welche die Institutionalisierung umsetzen. Diese Praktiken zur Institutionalisierung werden als generische Praktiken (Generic Practices) bezeichnet, da sie für alle Prozessgebiete gleich sind. Die Umsetzung vieler generischer Praktiken ist eine Aufgabe der Organisation.
CMMI beschreibt den Grad der Reife eines einzelnen Prozessgebiets durch sogenannte „Fähigkeitsgrade“ (capability levels). Der Grad der Institutionalisierung ist ab Version 1.3 wie folgt definiert:
- 0 – Incomplete
- Die Arbeit wird so durchgeführt, dass die fachlichen Ziele (in CMMI "Specific Goals" genannt, z. B. bei der Projektplanung ein Projektplan) nicht erreicht werden.
- 1 – Performed
- Die Arbeit wird so durchgeführt, dass die fachlichen Ziele erreicht werden.
- 2 – Managed
- Die Arbeit wird gelenkt.
- 3 – Defined
- Die Arbeit wird mit Hilfe eines angepassten Standardprozesses durchgeführt und die Arbeitsweise verbessert.
Die generischen Praktiken und die Fähigkeitsgrade gehören zum Kern von CMMI und sind in allen CMMI-Modellen identisch.
Reifegrade
Neben den Fähigkeitsgraden eines einzelnen Prozessgebiets definiert CMMI „Reifegrade“ (maturity levels). Ein Reifegrad umfasst eine Menge von Prozessgebieten, die mit dem zum Reifegrad korrespondierenden Fähigkeitsgrad etabliert sein müssen. Jeder Reifegrad ist ein Entwicklungsplateau in der Prozessverbesserung der Organisation. CMMI bietet damit eine Hilfe für die Verbesserung, indem es die Prozessgebiete bezüglich der Verbesserung priorisiert. Die Reifegrade sind:
- 1 – Initial
- Keine Anforderungen. Diesen Reifegrad hat jede Organisation automatisch.
- 2 – Managed
- Die Projekte werden geführt. Ein ähnliches Projekt kann erfolgreich wiederholt werden.
- 3 – Defined
- Die Projekte werden nach einem angepassten Standardprozess durchgeführt und es gibt eine organisationsweite kontinuierliche Prozessverbesserung.
- 4 – Quantitatively Managed
- Es wird eine statistische Prozesskontrolle durchgeführt.
- 5 – Optimizing
- Die Arbeit und Arbeitsweise werden mit Hilfe einer statistischen Prozesskontrolle verbessert.
Die Reifegrade sind in allen CMMI-Modellen grundsätzlich identisch, aber die Zuordnung der Prozessgebiete zu den fünf Reifegraden ist spezifisch für jedes CMMI-Modell (da jedes CMMI-Modell unterschiedliche Prozessgebiete enthält).
Die Bewertung des Reifegrades bzw. des Fähigkeitsgrads einer Organisation geschieht durch eine SCAMPI-Untersuchung (SCAMPI-Appraisal), die nur durch vom SEI autorisierte Personen geleitet werden kann. Die Liste aller vom SEI autorisierten Lead Appraiser, also diejenigen Personen, die ein solches SCAMPI leiten dürfen, findet sich auf den Seiten des Software Engineering Institutes (siehe Weblinks unten). Die deutschsprachigen autorisierten Lead Appraiser haben sich im German CMMI Lead Appraiser and Instructor Board (CLIB) zusammengeschlossen.
| Level | Firmen |
|---|---|
| 1 (Initial) | 80 |
| 2 (Managed) | 726 |
| 3 (Defined) | 1306 |
| 4 (Quantitatively Managed) | 51 |
| 5 (Optimizing) | 184 |
CMMI und CMM
CMMI hat das Software-Capability Maturity Model (kurz SW-CMM oder verkürzt nur CMM) ersetzt. CMM wurde vom SEI abgekündigt und wird nicht mehr unterstützt. CMMI ersetzt nicht nur verschiedene Qualitätsmodelle für unterschiedliche Entwicklungsdisziplinen (z. B. für Software- oder Systementwicklung), sondern integriert diese in einem neuen, modularen Modell. Dieses modulare Konzept ermöglicht zum einen die Integration weiterer Entwicklungsdisziplinen (z. B. Hardwareentwicklung), zum anderen auch die Anwendung des Qualitätsmodells in übergreifenden Disziplinen (z. B. Entwicklung von Chips mit Software).
Zielorientierung und falsche Verwendung von CMMI
Für eine erfolgreiche Verwendung von CMMI ist ein konkretes Verbesserungsziel zwingend notwendig.
Mit einem konkreten Verbesserungsziel ist CMMI eine sehr nützliche Unterstützung bei der Verbesserung. CMMI hilft, gezielt die relevanten Praktiken durchzugehen, bei denen die Frage im Vordergrund steht, ob diese Praktiken im Sinne des Verbesserungsziels unter Kontrolle sind oder ob eine Optimierung sinnvoll erscheint. Ein Beispiel für eine Umsetzung von CMMI mit Schlankheit und Effizienz als Verbesserungsziele ist z. B. Scrum, das Projekt- und Anforderungsmanagement-Methoden bietet.
Ohne ein Verbesserungsziel kann eine Organisation nur zufällig Verbesserungen erreichen – mit oder ohne CMMI. Im Gegenteil: Verbesserungen ohne ein Ziel können schnell Bürokratismus erzeugen, wenn Praktiken ziellos (und dann sicherheitshalber übererfüllt) umgesetzt werden.
Abgrenzung zu anderen Normen
Im Unterschied zur DIN EN ISO 9001 gehen die CMMI-Modelle spezifisch auf die Praktiken in einem bestimmten Anwendungsgebiet ein.
Während die DIN EN ISO 9001 die gesamte Organisation und damit mehr die Breite abdeckt, geht CMMI bei den konkreten Tätigkeiten weit mehr in die Tiefe und bietet konkrete Prozessgebiete und Praktiken. Die CMMI-Modelle und die DIN EN ISO 9001 haben jedoch denselben Grundgedanken. Die Anforderungen der CMMI-Modelle lassen sich auf die Anforderungen der DIN EN ISO 9001 abbilden (diese Tabelle ist auf den SEI-Webseiten verfügbar).
Die CMMI-Modelle setzen die Anforderungen der Norm ISO/IEC 15504 (SPICE) an ein Prozessmodell um. Das Appraisal-Verfahren SCAMPI setzt die Anforderungen der Norm ISO/IEC 15504 an ein Bewertungsverfahren teilweise um.
Neben den CMMI-Modellen gibt es auch die Prozessmodellnormen ISO/IEC 12207 für Software- und ISO 15288 für die Systementwicklung. Im Gegensatz zu CMMI gehen diese beiden Normen aber nicht über die Definition der Titel der Praktiken von CMMI hinaus (keine umfangreichen Erklärungen wie in CMMI). Es gibt auch keine Integration der beiden Normen. Inhaltlich fordern ISO/IEC 12207 und ISO 15288 im Wesentlichen das Gleiche wie CMMI für Entwicklung (CMMI-DEV). Zu der Norm ISO 12207 gibt es ein in ISO/IEC 15504 (SPICE) Teil 5 exemplarisch definiertes, CMMI-unabhängiges Bewertungsverfahren (engl. "process assessment model").
CMMI für Entwicklung (CMMI-DEV) wird für die Entwicklung von Produkten oder für Wartungsprojekte zu existierenden Produkten verwendet. Das CMMI for Services (CMMI-SVC) wird für Organisationen verwendet, die Dienstleistungen anbieten. CMMI-SVC adressiert alle Arten von Dienstleistungsorganisationen. Für IT-Betriebsorganisationen stellt CMMI for Services eine Alternative zu ITIL dar. Im Vergleich zu ITIL ist CMMI for Services höher aggregiert. CMMI for Services und CMMI for Development können miteinander integriert werden, so dass sie zusammen den gesamten Produkt-Lifecycle abdecken.
Literatur
- Mary B. Chrissis, Mike Konrad, Sandy Shrum: CMMI. Richtlinien für Prozess-Integration und Produkt-Verbesserung. 1. Auflage. Addison-Wesley Verlag, München 2009, ISBN 978-3-8273-2784-0.
- Brian P. Gallagher, Mike Phillips, Karen J. Richter, Sandy Shrum: CMMI-ACQ. Guidelines for Improving the Acquisition of Products and Services. Addison-Wesley, 2009, ISBN 978-0-321-58035-1.
- Eileen C. Forrester, Brandon L. Buteau, Sandy Shrum: CMMI for Services. Guidelines for Superior Service. Addison-Wesley, 2009, ISBN 978-0-321-63589-1.
- Malte Foegen, Mareike Solbach, Claudia Raak: Der Weg zur professionellen IT. Springer, Berlin 2007, ISBN 3-540-72471-0.
- Christian Hertneck, Ralf Kneuper: Prozesse verbessern mit CMMI® for Services: Ein Praxisleitfaden mit Fallstudien. dpunkt.verlag, Heidelberg 2011, ISBN 978-3-89864-657-4.
- Hubert Hofmann, Yedlin, Debbie; Mishler, John; Kushner, Susan: CMMI for Outsourcing: Guidelines for Software, Systems, and IT Acquisition. Addison-Wesley Professional, 2007, ISBN 0-321-47717-0.
- Ralf Kneuper: CMMI. Verbesserung von Softwareprozessen mit Capability Maturity Model Integration. 3. Auflage. dpunkt.verlag, Heidelberg 2007, ISBN 978-3-89864-464-8.
- Ralf Kneuper, Ernest Wallmüller: CMMI in der Praxis. Fallstudien zur Verbesserung der Entwicklungsprozesse mit CMMI. dpunkt.verlag, Heidelberg 2009, ISBN 978-3-89864-571-3.
- Jürgen Schmied, Paul-Roux Wentzel, Michael Gerdom, Uwe Hehn: Mit CMMI Prozesse verbessern! dpunkt.verlag, 2008, ISBN 978-3-89864-538-6.
- Ernest Wallmüller: SPI - Software Process Improvement mit CMMI und ISO 15504. Hanser, München 2006, ISBN 3-446-40492-9.
Weblinks
- CMMI Main page, verwaltet vom CMMI Institute
- Alle CMMI-Modelle als PDF- oder Word-Datei, bereitgestellt vom SEI
- Deutsche Übersetzung von CMMI for Development v1.3 (PDF; 3,5 MB), bereitgestellt vom SEI
- IDEAL - Vorgehensmodell zur Prozessverbesserung mittels CMMI, verwaltet vom SEI
- German CMMI Lead Appraiser and Instructor Board (CLIB)
- CMMI for Development v1.2 Browser (der Inhalt der PDF-Datei als Browser)
- Erklärung von CMMI in zwei Videos (Länge: fünf oder 30 Minuten)
Einzelnachweise
- CMMI Version 1.3 Information Center. Abgerufen am 6. Januar 2011.
- History Of CMMI. Abgerufen am 16. Juni 2020.
- Sally Godfrey (2008) What is CMMI ? (Memento vom 4. April 2009 im Internet Archive). NASA presentation. Accessed 8 dec 2008.
- Published Appraisal Results. Abgerufen am 22. Januar 2009.