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.

Prozessgebiete (Process Areas), Kategorien (Categories) und Reifegrade (Maturity Levels) beim CMMI for Development Version 1.3
Prozessgebiet (engl.)Prozessgebiet (dt.)KategorieReifegrad
Causal Analysis and Resolution (CAR)Ursachenanalyse und ProblemlösungSupport5
Configuration Management (CM/SCM)KonfigurationsmanagementSupport2
Decision Analysis and Resolution (DAR)Entscheidungsanalyse und -findungSupport3
Integrated Project Management (IPM)Integriertes ProjektmanagementProject Management3
Measurement and Analysis (MA)Messung und AnalyseSupport2
Organizational Performance Management (OPM)Organisationsweites ProzessfähigkeitsmanagementProcess Management5
Organizational Process Definition (OPD)Organisationsweite ProzessdefinitionProcess Management3
Organizational Process Focus (OPF)Organisationsweiter ProzessfokusProcess Management3
Organizational Process Performance (OPP)Organisationsweite ProzessfähigkeitProcess Management4
Organizational Training (OT)Organisationsweites TrainingProcess Management3
Product Integration (PI)ProduktintegrationEngineering3
Project Monitoring and Control (PMC)Projektverfolgung und -steuerungProject Management2
Project Planning (PP)ProjektplanungProject Management2
Process and Product Quality Assurance (PPQA)Qualitätssicherung von Prozessen und ProduktenSupport2
Quantitative Project Management (QPM)Quantitatives ProjektmanagementProject Management4
Requirements Development (RD)AnforderungsentwicklungEngineering3
Requirements Management (REQM)AnforderungsmanagementProject Management2
Risk Management (RSKM)RisikomanagementProject Management3
Supplier Agreement Management (SAM)Management von LieferantenvereinbarungenProject Management2
Technical Solution (TS)Technische UmsetzungEngineering3
Validation (VAL)ValidierungEngineering3
Verification (VER)VerifizierungEngineering3

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

Charakteristik der verschiedenen Reifegrade (engl. Original).[3]

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.

Veröffentlichte Ergebnisse von CMMI Appraisals (Stand 01/2009)[4]
LevelFirmen
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

  • Eileen C. Forrester, Brandon L. Buteau, Sandy Shrum: CMMI for Services. Guidelines for Superior Service. Addison-Wesley, 2009, ISBN 978-0-321-63589-1.
  • Christian Hertneck, Ralf Kneuper: Prozesse verbessern mit CMMI® for Services: Ein Praxisleitfaden mit Fallstudien. dpunkt.verlag, Heidelberg 2011, ISBN 978-3-89864-657-4.
  • Malte Foegen, Mareike Solbach, Claudia Raak: Der Weg zur professionellen IT. Springer, Berlin 2007, ISBN 978-3-540-72471-1.
  • 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.
  • Hubert Hoffmann, Debbie Yedlin, John Mishler, Susan Kushner: CMMI for Outsourcing: Guidelines for Software, Systems, and IT Acquisition. Addison-Wesley Professional, 2007, ISBN 978-0-321-47717-0.
  • 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.
  • Ralf Kneuper: CMMI. Verbesserung von Softwareprozessen mit Capability Maturity Model Integration. 3. Auflage. dpunkt.verlag, Heidelberg 2007, ISBN 978-3-89864-464-8.
  • Ernest Wallmüller: SPI – Software Process Improvement mit CMMI und ISO 15504. Hanser, München 2006, ISBN 3-446-40492-9.
  • 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.

Weblinks

Einzelnachweise

  1. CMMI Version 1.3 Information Center. Abgerufen am 6. Januar 2011.
  2. History Of CMMI. Abgerufen am 16. Juni 2020.
  3. Sally Godfrey (2008) What is CMMI ? (Memento vom 4. April 2009 im Internet Archive). NASA presentation. Accessed 8 dec 2008.
  4. Published Appraisal Results. (Nicht mehr online verfügbar.) Archiviert vom Original am 4. Januar 2017; abgerufen am 22. Januar 2009.  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/sas.cmmiinstitute.com

Auf dieser Seite verwendete Medien

Characteristics of Capability Maturity Model.svg
The five process maturity levels in the Capability Maturity Model.