CMMI: Capability Maturity Model Integration

Neben ISO 9000 gewinnt das amerikanische Capability Maturity Model Integration (CMMI) vom Software Engineering Institute (SEI) der Carnegie Mellon University in Europa zunehmend eine stärkere Bedeutung. CMMI beschreibt sehr detailliert, welche Praktiken und Prozesse für eine professionelle und qualitative Softwareentwicklung notwendig sind. CMMI unterscheidet fünf Stufen von Reifegraden, die der Herstellungsprozess von Software in einem Unternehmen aufweisen kann: Initial, Managed, Defined, Quantitatively Managed und Optimizing. Für jede Stufe definiert CMMI eine Reihe von Prozessgebieten wie z.B. das Änderungsmanagement (Change Management), die eine Organisation dieser Stufe durchführt. Zusätzlich definiert CMMI konkrete Anforderungen an die Prozesse. Durch Aufsteigen auf eine höhere Stufe kann ein Unternehmen seine Entwicklungsprozesse, die Qualität seiner Produkte und die Kostensituation signifikant verbessern. Dieser Artikel gibt eine Einführung in CMMI.

Ziel: Professionelle Anwendungsentwicklung

Die Möglichkeiten der Software-Industrie prägen die Visionen vieler Firmen. Weltweite, vernetzte Systeme, Verteilung mit Datenkonsistenz, eBusiness-Lösungen und vieles mehr sind Schlagworte, die Wirklichkeit werden sollen. Mit den Visionen wachsen auch die Ansprüche an die Software-Entwicklung. Ansprüche, denen der Projektalltag oftmals nicht gewachsen ist. Projekte überschreiten meist den Zeit- und Kostenrahmen und liefern nicht die gewünschte Funktionalität. Hauptursachen für die auftauchenden Probleme sind mangelnde Professionalität.

Um Professionalität zu erreichen, gewinnen Zertifizierungen aus einer Reihe von Gründen eine besondere Bedeutung. Zum einen sind die einer Zertifizierung zu Grunde liegenden Kriterien sehr gute Checklisten, um seinen eigenen „Reifegrad“ gezielt entwickeln und überprüfen zu können. Zum anderen können offizielle Zertifizierungen als Dokumentation eines Reifegrades nach außen (Kunden oder interne Auftraggeber) verwendet werden. Nicht zuletzt hat eine offizielle Zertifizierung aber auch den Effekt, dass die für einen Reifegrad notwendigen Maßnahmen (z.B. Versionierung oder Kostenkontrolle) tatsächlich eingeführt werden, da sie durch externe Auditoren/Assessoren unabhängig überprüft werden.

Vielfach wird auch in der Software-Industrie noch eine Zertifizierung auf Basis der ISO 9000 Normenreihe vorgenommen. Oft führt dies dazu, dass sie von Nichteingeweihten oft falsch interpretiert und damit überschätzt wird. Eine ISO-Zertifizierung ist nicht mit einer Art Garantie für das Funktionieren einer Software zu verwechseln. Die ISO Normenreihe definiert lediglich, dass ein Qualitätsmanagement dokumentiert ist; das heißt zertifiziert wird, ob eine Dokumentation vorhanden ist. Darüber hinaus geht die ISO 9000 Reihe auch nicht auf die Spezifika und damit Notwendigkeiten der Softwareentwicklung ein, die ganz eigene Erfolgs-Schlüsselfaktoren hat.

Daher gewinnt das amerikanische Capability Maturity Model Integration (CMMI), der Standard des Software Engineering Institute (SEI) der Carnegie Mellon University in Pittsburgh, Pennsylvania, in Europa eine immer stärkere Bedeutung (siehe [1], [2]). CMMI konzentriert sich auf die Prozesse, die an der Herstellung von Produkten, hier insbesondere Software, beteiligt sind. Dahinter steht die Idee, dass die Qualität von Software wesentlich von den Entwicklungsprozessen bei der Herstellung abhängt, also von dynamischen Elementen, und nicht so sehr von statischen wie Programmiersprachen. CMMI unterscheidet fünf Stufen von Reifegraden, die der Herstellungsprozess von Software in einem Unternehmen aufweisen kann: Initial, Managed, Defined, Quantitatively Managed und Optimizing. Durch Aufsteigen auf eine höhere Stufe kann ein Unternehmen seine Entwicklungsprozesse und damit auch die Qualität seiner Produkte verbessern.

CMMI kann verwendet werden, um die Stärken und Schwächen einer Produktentwicklung objektiv zu analysieren, um Verbesserungsmaßnahmen zu bestimmen und diese in eine sinnvolle Reihenfolge zu bringen. Primär ist CMMI ein Werkzeug, um die Produktentwicklung zu verbessern und ein “roter Faden” für eine erfolgreiche Veränderung. Sekundär ist eine offizielle Überprüfung eines Reifegrades, eine in der Industrie de-facto anerkannte Auszeichnung.

CMMI ist ein Prozessmodell. Im Gegensatz zu einer konkreten Prozessbeschreibung (Methode, Vorgehensmodell) definiert CMMI Anforderungen an eine gute Produktentwicklung (das “Was”), aber keine konkreten Schritte (das “Wie”). Das primäre Ziel von CMMI ist es, eine kontinuierliche Prozessverbesserung zu unterstützen, indem Anforderungen bzw. Kriterien an eine professionelle Produktentwicklungs-Organisation definiert werden. Die Definition des Entwicklungsprozesses obliegt der Organisation und ist eine wichtige Teilaufgabe der Prozessverbesserung. Da CMMI keinen konkreten Entwicklungsprozess definiert, kann es auf sehr unterschiedliche Organisationen und Organisationsgrößen angewendet werden. So kann z.B. die Forderung von CMMI “Bei der Projektplanung muss eine Zustimmung der Projektbeteiligten zum Projektplan eingeholt werden” auf sehr unterschiedliche Arten in einer Organisation umgesetzt werden. Es gibt daher nicht “die eine” richtige Umsetzung von CMMI.

Eine besondere Eigenschaft von CMMI ist, dass nicht nur die Entwicklungsprojekte an sich adressiert werden, sondern auch die projektbezogenen Aufgaben der Organisation (z.B. Bereitstellung von Ressourcen, Durchführung von Trainingsmaßnahmen). Desweiteren legt CMMI sehr viel Wert auf den gelebten Prozess.

CMMI (für: CMM Integration) ist die aktuelle Version des CMMModells. Die neue Version von CMM integriert zum einen die vorherigen unterschiedlichen Modelle (daher das I im Namen) und bietet sowohl eine stufenförmige als auch eine kontinuierliche Darstellung (siehe [4]). Die stufenförmige Darstellung entspricht im wesentlichen den Stufen des klassischen CMM Modells. In der kontinuierlichen Darstellung kann jeder Prozess in einem Unternehmen separat für sich bewertet werden. So können in den einzelnen Prozess-Bereichen (Process Areas) unterschiedliche Stufen erreicht werden. Dies ergibt ein differenzierteres, aber auch weniger eindeutiges Bild, bezogen auf die Einstufung in die fünf Stufen der Reifegrade. Darüber hinaus bietet ein kontinuierliches Modell weniger Hilfestellungen für eine sinnvolle Reihenfolge von Verbesserungsschritten als ein stufenförmiges Modell. In CMMI sind das kontinuierliche und das stufenförmige Modell nur Darstellungsvarianten mit demselben Inhalt und können aufeinander abgebildet werden.

Mit den Erfahrungen des CMM-Modells und anderer Zertifizierungsverfahren wurde eine internationale Norm entwickelt: ISO 15504 (siehe [5]). Die Norm ISO 15504 definiert, wie ein Qualitätsmodell, wie z.B. CMMI, strukturiert sein muss, und wie Assessments einer Organisation auf Basis eines solchen Qualitätsmodells durchgeführt werden. Im Teil 5 der Norm wird ein Beispiel-Assessmentverfahren (SPICE) für das Qualitätsmodell ISO 12207 beschrieben. CMMI und das vom SEI definierte Assessment-Verfahren (SCAMPI) erfüllen ebenfalls die Norm ISO 15504.

Die Reifegrade von CMMI

Das Capability Maturity Model Integration (CMMI) definieren fünf Stufen von Reifegraden, die der Herstellungsprozess von Software in einem Unternehmen aufweisen kann. CMMI definiert die Stufen Initial, Managed, Defined, Quantitatively Managed und Optimizing. Für jede Stufe, mit Ausnahme der ersten, definiert das CMMI eine Reihe von Prozessgebieten, die eine Organisation umgesetzt haben muss, die sich auf dieser Stufe befindet. Zu jedem Prozessgebiet gehört eine Reihe von Zielen und Praktiken, die konkret beschreiben, was für die Umsetzung eines Prozessgebiets in einem Unternehmen gelebt werden muss. Die Bedeutung der Stufen in CMMI ist im wesentlichen unverändert zu denen der Vorgängerversion CMM.

Auf Stufe 1 (Initial) ist der Software-Prozess eine “black box”. Die Softwareentwicklung verläuft ad hoc und chaotisch. Es gibt keine Vorgaben zur Planung und Steuerung von Projekten. Der Erfolg oder Mißerfolg hängt in erster Linie von den Bemühungen, der Motivation und der Qualifikation der beteiligten Personen ab. Zwar kann auch auf dieser Stufe ein Projekt- und Qualitätsmanagement vorhanden sein, es wird aber nicht konsequent angewendet. Projekte dieser Art werden kurzfristig und reaktiv geführt, so dass Entscheidungen vielfach revidiert werden. Tatsächlich können auch auf dieser Stufe gute Ergebnisse erzielt werden – wider den Projektumständen. Solche Projekte leben vom heroischen Einsatz der “Helden”. Extreme Terminüberschreitungen sind auf dieser Stufe daher ebenso vorprogrammiert wie empfindliche Qualitätsmängel. Darüber hinaus können Erfahrungen aus solchen Projekten nur unzureichend in einem neuen Projekt genutzt werden. Die überwiegende Mehrzahl der Unternehmen befindet sich auf dieser Stufe.

Auf Stufe 2 (CMMI: Managed, CMM: Repeatable) sind grundlegende Projektmanagement-Aufgaben, wie Planung, Kontrolle und Steuerung von Zeit, Kosten, Funktionalität und Qualität etabliert. Der Software-Prozess besteht aus einer Reihe von “black boxes” mit definierten Meilensteinen. Damit besteht eine stabile Projektverwaltung, und die Erfahrungen aus früheren Projekten können in neue Vorhaben einfließen. Kosten und Termine werden dabei laufend überwacht. So wird auch der Ablauf der Prozesse in einem bestimmtem Rahmen vorhersagbar.

Die Prozessgebiete der Stufe 2 sind:

• Anforderungsmanagement
• Projektplanung
• Projektverfolgung und -steuerung
• Zulieferungsmanagement
• Messung und Analyse
• Prozess- und Produktqualitätssicherung
• Konfigurationsmanagement

Auf Stufe 3 (Defined) ist ein organisationsweit gültiger Software-Prozess definiert und eingeführt. Dieser Prozess umfasst sowohl die Projektmanagement-Aufgaben als auch die softwaretechnischen Tätigkeiten. Alle Projekte nutzen eine auf das Projekt zugeschnittene Version des organisationsweit definierten Prozesses. Auf der dritten Stufe ist die interne Struktur der Phasen definiert und sichtbar. Manager und Entwickler verstehen ihre Rollen und Verantwortlichkeiten innerhalb des Prozesses.

Die Prozessgebiete der Stufe 3 sind:

• Entscheidungsfindung
• Risikomanagement
• Fortgeschrittenes Projektmanagement
• Organisationsweite Prozessausrichtung
• Organisationsweite Prozessentwicklung
• Organisationsweite Aus- und Weiterbildung
• Anforderungsentwicklung
• Technische Umsetzung
• Produktintegration
• Verizifierung
• Validierung

Auf Stufe 4 (CMMI: Quantitatively Managed, CMM: Managed) wird die Qualität der Produkte und die Produktivität der Prozesse durch ein organisationsweites Metrikprogramm quantitativ gemessen. Das Management hat dadurch eine objektive Basis um Entscheidungen treffen zu können.
Werden die Prozessdaten in einer unternehmensweiten Datenbank gesammelt, so kann die Produktivität der Entwicklung überprüft werden. Dies ist vor allem für Aufwandsschätzungen sinnvoll. Gerade hier zeigt sich die Logik der aufeinander aufbauen Stufen: nur mit der Erhebung von Daten (Stufe 4) können Projektaufwände verlässlich geschätzt werden. Eine solche Datenerhebung ist nur möglich – und die Daten an sich sinnvoll – wenn sie auf einem gemeinsamen Projektverständnis und Vorgehen beruhen (Stufe 3), und dieses Verständnis im Projekt tatsächlich umgesetzt und dadurch das Projekt aktiv gesteuert wird (Stufe 2).

Die Prozessgebiete der Stufe 4 sind:

• Organisationsweites Prozessleistung
• Quantitatives Projektmanagement

Auf der fünften Stufe (Optimizing) ist ein kontinuierlicher Verbesserungsprozess etabliert. Dieser basiert auf den quantitativen Informationen über den Prozess (siehe Stufe 4) und die Anwendung innovativer Ideen und Technologien.

Die Prozessgebiete der Stufe 5 sind:

• Organisationsweites Leistungsmanagement
• Ursachenanalyse und -beseitigung

Entwicklung von Organisationen

Der Übergang von einem CMMI-Level zu einem nächsten ist eine zeitintensive Aufgabe. Typischerweise benötigen Unternehmen im Mittel zwei Jahren, um die nächste Reifegrad-Stufe zu erreichen.

Die Verbesserung der Qualität und Professionalität der Anwendungsentwicklung ist eine Veränderung des Unternehmens – eine typische “Organizational Change Management” Aufgabe. Eine solche Veränderung bzw. Weiterentwicklung des Unternehmens muss, um erfolgreich zu sein, wie ein Projekt geführt werden.

Um eine dauerhafte Verbesserung der Effizienz und Professionalität in den Projekten zu erreichen und um ein gemeinsames Verständnis eines Software-Entwicklungsprozesses zu leben und zu tragen, müssen die folgenden kritischen Erfolgsfaktoren erfüllt werden:

• Eine Unterstützung durch das Top-Management ist essentiell, um die Bedeutung bei den Mitarbeitern darstellen und die kulturellen und organisatorischen Änderungen durchsetzen zu können.
• Die Zielerreichung des CMMI Level 2 oder höher muss eine zwingende Notwendigkeit sein. Nur in diesem Fall wird eine solche Initiative vom Management und von den Mitarbeitern getragen.
• Eine klare Richtung ist die Voraussetzung für eine klare Kommunikation und das langfristige Einhalten einer eingeschlagenen Richtung.
• Messbare Ziele bzw. Ergebnisse sind notwendig, um den Erfolg messen und das CMMI Level 2 Projekt (oder einen höheren angestrebten Level) entsprechend steuern zu können.
• Ein Fokus im CMMI Projekt ist notwendig, um durch die Konzentration der Kräfte auf einen wohldefinierten Bereich schnelle Erfolge zu erzielen (z.B. durch ein Pilotprojekt). Dieser Fokus wird hin zu einer Unterstützung auf breiter Basis ausgeweitet, welche die Verbesserungen langfristig trägt. Diese Unterstützung kann nur mit fachlichen Kenntnissen des Change Teams (Projektteam) und einem direkten Nutzen für die Betroffenen erreicht werden.
• Kommunikation ist Voraussetzung, um die Mitarbeiter aktiv zu beteiligen und zu informieren, um ihre Unterstützung zu gewinnen und um Gerüchten vorzubeugen.
• Eine Prozess-Architektur ist notwendig, um einer einheitlichen und nachvollziehbaren Vorgehensweise zu folgen.
• Die Führung als Projekt mit einem straffen Projektmanagement ist notwendig für die gezielte und gesteuerte Verfolgung der Ziele – zur Einhaltung der klaren Richtung

Referenzen

1. Mark C. Paulk, Bill Curtis, Mary Beth Chrissis, Charles V. Weber: Capability Maturity Model SM for Software, Version 1.1, Technical Report CMU/SEI-93-TR-024, ESC-TR-93-177, Pittsburgh, 1993
2. J. Bamberger: Essence of the Capability Maturity Model, IEEE Computer Society, 1997
3. Mark C. Paulk, Charles V. Weber, Suzanne M. Garcia, Mary Beth Chrissis, Marilyn Bush: Key Practices of the Capability Maturity Model SM , Version 1.1, Technical Report CMU/SEI 93-TR-025, ESC-TR-93-178, Pittsburgh, 1993
4. CMMI Product Team: Capability Maturity Model Integration (CMMI) Version 1.1, Technical Report CMU/SEI-2002-TR-012, ESC-TR-2002-012, Pittsburgh, 2002
5. ISO organization: International Standard ISO/IEC 15504-1, ISO/IEC 15504-2, ISO/IEC 15504-3, ISO/IEC 15504-4, ISO/IEC 15504-5, Genf, 2004 bis 2005
6. Software Engineering Institute: Process Maturity Profile, http://www.sei.cmu.edu/sema/profile.html, Pittsburgh, 2001

---