Bibtex

@InCollection{,
  Year    = "2019", 
  Title    = "CMMI (Capability Maturity Model Integration)", 
  Author    = "Jacobs, Prof. Dr. Stephan", 
  Booktitle    = "Gronau, Norbert ; Becker, Jörg ; Kliewer, Natalia ; Leimeister, Jan Marco ; Overhage, Sven (Herausgeber): Enzyklopädie der Wirtschaftsinformatik – Online-Lexikon",
  Publisher    = "Berlin : GITO",
  Url    = "https://wi-lex.de/index.php/lexikon/entwicklung-und-management-von-informationssystemen/systementwicklung/reifegradmodelle/cmmi-capability-maturity-model-integration/", 
  Note    = "[Online; Stand 4. November 2024]",
}

CMMI (Capability Maturity Model Integration)

Stephan Jacobs


Das CMMI ist das vor allem im anglo-amerikanischen Bereich am meisten verbreitete Reifegradmodell in der Softwareentwicklung. CMM 1.0, der Vorgänger des heutigen CMMI, wurde 1991 vom Software Engineering Institute (SEI) veröffentlicht. 2002 erschien das Nachfolgemodell CMMI. Seit 2010 gibt es die derzeit aktuelle Version CMMI 1.3.

Historie

In den achtziger Jahren gab es bei der Vergabe von Softwareprojekten häufig große Probleme. Projekte lieferten schlechte Qualität und unvollständige Funktionalität; Projekte lieferten zu spät und überzogen regelmäßig ihr Budget. Einer der größten Auftraggeber für Software, das amerikanische Verteidigungsministerium (Department of Defense, DoD), veranlasste daher eine Untersuchung durch das SEI, neue Lösungsansätze in der Softwareentwicklung zu suchen. Das Ergebnis dieser Untersuchung war das Capability Maturity Model (CMM), das 1991 in der Version 1.0 veröffentlicht wurde.

Während das ursprüngliche Modell auf die Entwicklung von Software fokussiert, stellten Weiterentwicklungen von CMM die Systementwicklung oder die Produktentwicklung in den Mittelpunkt (IPD-CMM). Um diese unterschiedlichen Modelle zu integrieren, wurde CMMI (CMM Integrated) spezifiziert und in der Version 1.1 im Jahre 2002 für den breiten Einsatz veröffentlicht.

Mit dem im Jahr 2006 veröffentlichten CMMI 1.2 fand wiederum eine Differenzierung statt. CMMI-DEV (CMMI for Development) setzt CMMI 1.1 fort, fokussiert weiterhin auf die Entwicklung. 2007 erschien CMMI-ACQ (CMMI for Acquisition), das sich auf die Beschaffung von Hard- und Software konzentriert. Zwei Jahre später wurde CMMI-SVC (CMMI for Services) veröffentlich, das Prozesse im Bereich der IT-Dienstleistungen unterstützt.

Die derzeit aktuelle Version CMMI 1.3 stammt aus dem Jahre 2010. Inhaltlich fanden im Vergleich zu den Vorgängerversionen nur wenige Anpassungen statt. Allerdings wurde die Sprache zwischen den drei Modellen vereinheitlicht.

CMMI

CMMI unterscheidet zwei verschiedene Darstellungsformen: Die schon aus CMM bekannte stufenförmige Darstellung sowie die kontinuierliche Darstellung.

Stufenförmige Darstellung des CMMI

In der stufenförmigen Darstellung umfasst CMMI fünf sogenannte Reifegrade, denen bestimmte Prozessgebiete (Key Process Areas) zugeordnet werden (vgl. Abbildung 1). Die Prozessgebiete werden u.a. durch Ziele und Praktiken genauer definiert. Dabei legt diese Definition fest, was in diesem Prozessgebiet erreicht werden muss nicht wie. Um einen Reifegrad zu erreichen, müssen sämtliche Prozessgebiete dieses Reifegrads sowie die Prozessgebiete der niedrigeren Reifegrade beherrscht werden.

Wichtig bei den Reifegraden ist nicht nur die Zuordnung der Prozesse sondern auch ein sich ändernder Fokus. Der Reifegrad 1 (Initial) wird ohne Vorbedingung vergeben. Hier befinden sich alle Organisationen und Projekte, die mindestens ein für Reifegrad 2 (geführt) notwendiges Prozessgebiet nicht unter Kontrolle haben. Der Fokus auf Reifegrad 2 ist das Projekt. Jedes einzelne Projekt kann auf unterschiedliche Art und Weise beispielsweise den Prozess Projektplanung angehen. Eine Vereinheitlichung der Prozesse innerhalb einer Organisation für alle Projekte ist auf dieser Stufe nicht vorgesehen. Auf dem Reifegrad 3 (Definiert) wechselt der Fokus weg vom Projekt hin zur Organisation. Auf dieser Ebene wird erwartet, dass Prozesse organisationsweit definiert und durchgeführt werden. Dies wird besonders deutlich an den mit „organisationsweit“ beschriebenen Prozessgebieten. Auf Ebene 4 (Quantitativ geführt) muss eine Messkultur implementiert sein, mit deren Hilfe es möglich ist, Entscheidungen zu unterstützen und deren Konsequenzen zu prognostizieren. Ebene 5 (Prozessoptimierung) konzentriert sich auf die kontinuierliche Verbesserung aller Prozessgebiete.

Auffällig an der stufenförmigen Darstellung ist, dass auf der zweiten Ebene hauptsächlich projektorientierte und kaum technische Prozessgebiete definiert sind. Hintergrund dieser Reihenfolge ist die Erkenntnis, dass Softwareprojekte selten an technischen Problemen scheitern, häufiger am fehlenden Projektmanagement.

Abb1 CMMI stufenförmig B
Abb. 1: Stufenförmige Darstellung (siehe: CMMI für Entwicklung, Version 1.3, Seite 45).

Kontinuierliche Darstellung des CMMI

Die kontinuierliche Darstellung sortiert die Prozessgebiete nicht nach ihrer Wichtigkeit sondern kategorisiert sie anhand ihres Einsatzgebietes. Abbildung 2 zeigt die vier Kategorien und die Zuordnung der Prozessgebiete.

Abb2 CMMI kontinuierlich B
Abb. 2: Kontinuierliche Darstellung (siehe CMMI für Entwicklung, Version 1.3, Seite 45)

Zusätzlich zu den Prozessgebieten gibt es sogenannte Fähigkeitsgrade (nicht zu verwechseln mit den Reifegraden!). Der Fähigkeitsgrad wird für jeden Prozess separat gemessen. Dabei gibt es vier unterschiedliche Stufen:

  • 0: unvollständig

  • 1: durchgeführt

  • 2: geführt

  • 3: definiert

Ist ein Prozessgebiet in Stufe 0 (unvollständig) so bedeutet dies, dass die spezifischen Ziele des Prozesses nicht erreicht werden. Beispielsweise gibt es beim Prozess Projektplanung keine Pläne, keine Abschätzung bzgl. Aufwand und Kosten. Ist der Prozess auf Stufe 1, werden die spezifischen Ziele eines Prozesses erreicht. In obigem Beispiel gibt es Pläne und Aufwandsabschätzungen. Allerdings sind diese nicht das Ergebnis von Prozessen sondern basieren auf der individuellen Kompetenz eines Mitarbeiters und nicht auf von der Organisation institutionalisierten Fähigkeiten. Stufe 2 setzt voraus, dass für das Prozessgebiet Ressourcen, Training etc. zur Verfügung gestellt werden allerdings reicht hier die Projektperspektive. Auf Stufe 3 ändert sich der Fokus, es wird eine einheitlich Prozessdefinition für die gesamte Organisation vorausgesetzt.

In der stufenförmigen Darstellung wird jeder Prozess einzeln betrachtet. Es kann daher z.B. vorkommen, dass einzelne Prozesse im Bereich Projektmanagement auf der Fähigkeitsstufe 3 sind – es gibt also organisationsweite Vorgaben wie ein Projekt durchgeführt wird. Dagegen sind die technischen Prozesse auf Fähigkeitsstufe 2, das heißt wie die einzelnen technischen Prozessgebiete implementiert werden ist von Projekt zu Projekt verschieden.

Nutzen von CMMI

CMMI kann in zweierlei Hinsicht genutzt werden. Einerseits ist der Reifegrad im CMMI-Modell ein häufig benutzter Benchmark für die Fähigkeiten eines Unternehmens. So ist es beispielsweise notwendig, mindestens Reifegrad 3 erreicht zu haben, um vom DoD (s.o.) einen Auftrag zu bekommen. Indische Softwarefirmen benutzen CMMI, um ihre Kompetenz im Bereich der Softwareentwicklung zu dokumentieren. Tatsächlich stammen eine Reihe der Firmen, die den Reifegrad 5 erreicht haben, aus Indien.

Dieser eher externen Sicht steht die Möglichkeit gegenüber, das in CMMI steckende Wissen für die Verbesserung der eigenen Organisation zu verwenden. CMMI kann hier als roter Faden verwendet werden. Es hilft festzustellen, welches die eigenen Stärken und Schwächen sind, und welche Schritte als nächstes getan werden sollten. Vor allem lassen sich auch die Schritte identifizieren, die nicht als nächstes getan werden sollten.

Kritik

Eine Kritik, die gerade aus der Perspektive der agilen Softwareentwicklung häufig an CMMI gerichtet wird, ist die Gefahr der Bürokratisierung. Dies ist vor allem dann der Fall, wenn statt der Erreichung von Verbesserung die ausführliche Dokumentation und Einhaltung von Prozessen in den Vordergrund rückt.

Ein weiterer Kritikpunkt ist die Tendenz von Organisationen, einen bestimmten Reifegrad behalten zu wollen und deshalb auf die Entwicklung innovativer Projekte und die Einführung innovativer Methoden zu verzichten.


Literatur

Ralf Kneuper: CMMI : Verbesserung von Softwareprozessen mit Capability Maturity Model Integration : 3.Auflage, dpunkt.verlag, Heidelberg, 2007

Ralf Kneuper, Ernest Wallmüller, CMMI in der Praxis: Fallstudien zur Verbesserung der Entwicklungsprozesse mit CMMI, 1.Auflage, dpunkt.verlag, Heidelberg, 2009

Ernest Wallmüller : SPI : Software Process Improvement mit CMMI, PSP/TSP und ISO 15504, Hanser Verlag, München, 2007

Internetquellen

Software Engineering Institute (SEI), CMMI for Development, Version 1.3: http://www.sei.cmu.edu/reports/10tr033.pdf (Abruf: 23.8.2013)

Software Engineering Institute (SEI), CMMI für Entwicklung, Version 1.3: (deutsche Übersetzung) : http://www.sei.cmu.edu/library/assets/whitepapers/10tr033de_v11.pdf (Abruf: 23.8.2013)

Hier weiterverbreiten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert