Hintergrundinformationen zu CMMI
Die definitive Anleitung für die Capability Maturity Model Integration (CMMI) bei der Entwicklung wurde vom Software Engineering Institute veröffentlicht unter dem Titel "CMMI: Guidelines for Process Integration and Product Improvement." (deutsche Ausgabe: CMMI 1.3 für die Entwicklung: Richtlinien für Prozessintegration und Produktverbesserung). Dieses Buch beschreibt speziell die CMMI for Development (CMMI-DEV) Version 1.3, die zur Zeit, in der dieser Text verfasst wurde, eines der Modelle innerhalb der aktuellen CMMI-Produktreihe ist. Dieses Modell ist extrem stabil und dürfte auch weit über 2010 hinaus noch aktuell bleiben. Hilfreich könne auch "CMMI Distilled: A Practical Introduction to Integrated Process Improvement" sein, das gut verständlich über das Thema informiert. Weitere Informationen über diese Bücher finden Sie unter Zusätzliche Ressourcen weiter unten in diesem Thema.
CMMI erblickte 1987 das Licht der Welt als Capability Maturity Model (CMM), ein Projekt am Software Engineering Institute, dem Forschungszentrum der Carnegie-Mellon-Universität. Dieses Zentrum wurde vom US-Verteidigungsministerium eingerichtet und finanziert. CMM for Software wurde 1991 veröffentlicht und beruht auf einer Checkliste kritischer Erfolgsfaktoren bei Softwareentwicklungsprojekten in den 70er- und 80erjahren. Das Modell beruht außerdem auf Forschungen der Firma International Business Machines (IBM) und den beiden führenden Köpfen des 20. Jahrhunderts in Sachen Qualitätssicherung, Philip Crosby und W. Edwards Deming. Sowohl der Name Capability Maturity Model als auch die fünf Ebenen der stufenweisen Darstellung (die wir uns später in diesem Thema noch ansehen werden) sind von Crosbys Manufacturing Maturity Model inspiriert. In der Anwendung in Verteidigungsprogrammen hat CMM beachtliche Verbreitung gefunden und eine Reihe von Überarbeitungen und Iterationen durchlaufen. Sein Erfolg führte zur Entwicklung von CMM für eine Reihe von Themen über Software hinaus. Die Verbreitung neuer Modelle war verwirrend, weshalb die Regierung ein zweijähriges Projekt finanzierte, an dem über 200 Experten aus Industrie und Wissenschaft beteiligt waren. Sie arbeiten an einem einzigen, erweiterbaren Framework, in dem Systemtechnik, Software Engineering und Produktentwicklung integriert werden sollten. Das Ergebnis war CMMI.
Das Wichtigste, was man über CMMI-DEV wissen muss, ist die Tatsache, dass es sich um ein Modell handelt. Es ist kein Prozess oder eine Vorschrift, an die man sich halten muss. Vielmehr ist es eine Reihe von Verhaltensweisen in Unternehmen, die sich in der Softwareentwicklung und dem System Engineering als vorteilhaft erwiesen haben. Wozu ein solches Modell? Welchem Zweck dient es? Und wie sollte man es am besten einsetzen? Das sind kritische Fragen und vielleicht die am häufigsten missverstandenen Bereiche im Zusammenhang mit CMMI.
Wozu ein Modell?
Ohne ein Modell, wie Ihre Firma funktioniert, welche Funktionen benötigt werden und wie diese miteinander interagieren ist es schwer, die Arbeit zu verbessern. Ein Modell gibt uns ein Verständnis der einzelnen Elemente im Unternehmen und hilft uns, eine Sprache und die gemeinsame Diskussion über das zu entwickeln, was verbessert werden muss und wie man dies erreicht. Ein Modell bietet folgende Vorteile:
Es liefert einen gemeinsame Rahmen und eine einheitliche Sprache für die Kommunikation
Nutzt jahrelange Erfahrungen
Hilft Nutzern, den Überblick zu behalten, wenn sie sich auf spezielle Verbesserungen konzentrieren
Wird von vielen Trainern und Beratern unterstützt
Kann als Standard bei Meinungsverschiedenheiten herangezogen werden
Wie ist die der Zweck des CMMI-Modells?
Das Fachbuch erläutert, dass der Zweck des Modells darin besteht, die Reife eines Unternehmensprozesses zu bewerten und Leitlinien für die Verbesserung von Prozessen anzubieten, die zu besseren Produkten führen. Im direkten Gespräch mit Mitarbeitern des Software Engineering Institute hört man auch, dass CMMI ein Modell für das Risikomanagement ist und die Fähigkeit eines Unternehmens zur Handhabung von Risiken beschreibt. Diese Einschätzung zeigt, wie wahrscheinlich die Firma Versprechen einhalten oder Produkte hoher Qualität liefern kann, die für den Markt attraktiv sind. Als eine andere Betrachtungsmöglichkeit bietet dieses Modell einen Indikator, wie gut ein Unternehmen unter Stress funktioniert. Ein Unternehmen mit hoher Reife und Leistungsfähigkeit verkraftet schwierige Ereignisse locker, reagiert, führt Änderungen durch und geht weiter. Ein solches mit geringer Reife und weniger Kompetenz neigt dazu, unter Stress in Panik zu verfallen und Vermeidungsverhalten an den Tag zu legen oder alle Prozesse komplett über Bord zu werden und sich ins Chaos zu flüchten.
CMMI hat sich nicht als guter Indikator für die wirtschaftliche Leistungsfähigkeit eines Unternehmens bewährt. Auch wenn reifere Unternehmen vielleicht besser mit Risiken umgehen und vorhersehbarer sind, gibt es Belege für Risikoscheu bei Firmen mit einem höheren Reifegrad. Sie kann zu einem Mangel an Innovation führen oder ein Beleg für mehr Bürokratie sein, die mehr Vorlaufzeiten und fehlende Wettbewerbsfähigkeit zur Folge haben kann. Firmen mit geringerer Reife sind tendenziell innovativer und kreativer, aber chaotisch und unvorhersehbar. Wenn die Ergebnisse erreicht wurden, dann ist das häufig das Ergebnis heroischer Anstrengungen Einzelner oder von Managern.
Wie setzt man das CMMI am besten ein?
Das Modell wurde als Grundlage für eine Initiative zur Prozessverbesserung entwickelt. Sein Einsatz zur Bewertung stellt nur ein Hilfsmittel zur Messung von Verbesserungen dar. Die Erfolge bei seinem Einsatz sind durchwachsen. Nur allzu leicht kann man das Modell als Prozessdefinition verstehen und versuchen, ihm zu folgen, statt es als Karte zu betrachten, die Lücken in vorhandenen Prozessen aufzeigt, die es zu füllen gilt. Fundamentaler Baustein von CMMI ist ein Prozessbereich, der Ziele und eine Reihe von Aktivitäten definiert, die häufig eingesetzt werden, um diese zu erfüllen. Ein Beispiel für einen Prozessbereich sind die Prozess- und Produktqualitätssicherungsaktivitäten. Ein anderer ist das Konfigurationsmanagement. Es ist wichtig zu verstehen, dass ein Prozessbereich kein Prozess ist. Ein einzelner Prozess kann mehrere Prozessbereiche haben und ein ein Prozessbereich wiederum mehrere Prozesse.
CMMI-DEV ist im Grunde genommen zwei Modelle mit denselben zugrunde liegenden Elementen. Das erste und vertrauteste ist stufenweise Darstellung, die die 22 Prozessbereiche darstellt, die einem der fünf Reifegrade von Unternehmen zugeordnet sind. Bei einer Einschätzung eines Unternehmens würde man die Ebene bewerten, auf der es tätig ist und das als Indikator seiner Fähigkeit dient, Risiken zu managen und damit gegebene Versprechen einzuhalten.
.png "Stufenförmige CMMI-Darstellung")
Die Reifegrade 4 und 5 werden oft als höhere Reifegrade bezeichnet. Es gibt häufig einen klaren Unterschied zwischen Unternehmen mit höherer Reife, bei denen die Verhaltensweisen rund um quantitatives Management und Optimierung beobachtbar sind und solchen mit niedrigerer Reife, die einfach verwaltet werden oder definierten Prozessen folgen. Unternehmen mit einem höheren Reifegrad weisen geringere Schwankungen bei Prozessen auf und setzen oftmals Frühindikatoren als Bestandteil einer statistisch vertretbaren Managementmethode ein. Als Folge sind sie sowohl vorhersehbarer als auch schneller in der Reaktion auf neue Informationen, davon ausgehend, dass anderweitige Bürokratie dem nicht im Wege steht. Wo bei Unternehmen mit niedriger Reife heroische Anstrengungen zu beobachten sind, folgen solche mit hoher Reife vielleicht unter Stress blind Prozessen und erkennen nicht, dass eine Prozessänderung die angemessene Reaktion wäre.
Das zweite, die kontinuierliche Darstellung, bildet die Prozessfähigkeit in jeder der 22 Prozessbereiche einzeln ab. Damit kann das Unternehmen seine Verbesserungsbemühungen maßgeschneidert an die Prozesse anpassen, die den höchsten Geschäftswert darstellen. Diese Darstellung entspricht eher dem ursprünglichen Modell von Crosby. Bewertungen anhand dieses Modells führen zu Profilen im Zusammenhang mit der Leistungsfähigkeit und nicht zu einer einzigen Zahl. Natürlich gibt es – weil der Reifegrad eines Unternehmens der Grad ist, den die meisten Manager und Führungskräfte verstehen – Möglichkeiten, die Ergebnisse einer laufenden Modellbewertung in den fünf Stufen zuzuordnen.
.png "Kontinuierliche CMMI-Darstellung")
Das stufenweise Modell als Grundlage für ein Prozessverbessungsprogramm einzusetzen kann gefährlich sein, denn die mit der Implementierung betrauten Personen können vergessen, dass CMMI kein Prozess- oder Workflow-Modell ist, sondern Ziele liefert, die Prozesse und Workflows erreichen sollen. Diese Ziele zu erreichen verbessert die Reife des Unternehmens und die Wahrscheinlichkeit, dass sich die Dinge wie geplant entwickeln. Der wahrscheinlich größte Fehler besteht darin, das Erreichen eines Reifegrads als Ziel zu setzen und dann Prozesse und eine Infrastruktur zu schaffen, um die Bewertung zu bestehen. Das Ziel jeder Prozessverbesserungsaktivität sollten messbare Verbesserungen sein und nicht eine Zahl.
Das fortlaufende Modell scheint mehr Erfolge zu haben als eine Anleitung zur Prozessverbesserung und manche Beratungsunternehmen haben sich entschlossen, nur anhand des fortlaufenden Modells tätig zu begleiten. Der offensichtlichste Unterschied besteht darin, dass ein Prozessverbesserungsprogramm, das um das fortlaufende Modell herum aufgebaut ist, keine künstlichen Ziele hat, die von den Reifegraden vorgegeben sind. Das fortlaufende Modell bietet sich also ganz natürlich für den Einsatz bei der Prozessverbesserung in Bereichen an, wo es am wahrscheinlichsten auch zu wirtschaftlichen Vorteilen für das Unternehmen führt. Deshalb erhalten alle, die dem fortlaufenden Modell folgen, auch eher positive Rückmeldungen von einer Initiative, die auf dem CMMI-Modell basiert. Außerdem führt positives Feedback eher zur Entwicklung einer Aufwärtsspirale von Verbesserungen.
Elemente des CMMI-Modells
Das CMMI-Modell ist in 22 Prozessbereiche aufgeteilt, die in der folgenden Tabelle zu sehen sind:
Akronym |
Prozessbereich |
|---|---|
CAR |
Ursachenanalyse und Lösung (Causal Analysis & Resolution) |
CM |
Konfigurationsmanagement (Configuration Management) |
DAR |
Entscheidungsanalyse und Lösung (Decision Analysis & Resolution) |
IPM |
Integriertes Projektmanagement (Integrated Project Management) |
MA |
Messung und Analyse (Measurement & Analysis) |
OID |
Organisatorische Innovation und Bereitstellung (Organizational Innovation & Deployment) |
OPD |
Organisatorische Prozessdefinition |
OPF |
Organisatorischer Prozessfokus |
OPP |
Organisatorischee Prozessleistung (Organizational Process Performance) |
OT |
Organisatorisches Training |
PI |
Produktintegration |
PMC |
Projektüberwachung und -kontrolle (Project Monitoring & Control) |
PP |
Projektplanung |
PPQA |
Prozess- und Produktqualitätssicherung (Process & Product Quality Assurance) |
QPM |
Quantitatives Projektmanagement (Quantitative Project Management) |
RD |
Anforderungsdefinition (Requirements Definition) |
REQM |
Anforderungsmanagement (Requirements Management) |
RSKM |
Risikomanagement |
SAM |
Verwaltung von Lieferantenvereinbarungen (Supplier Agreement Management) |
TS |
Technische Lösung (Technical Solution) |
VER |
Überprüfung |
VAL |
Validierung |
In der stufenweisen Darstellung werden die Prozessbereiche jeder Stufe zugeordnet, wie in der folgenden Abbildung dargestellt.
.png "Stufenförmige Darstellung mit Prozessbereichen")
In der fortlaufenden Darstellung werden die Prozessbereiche funktionalen Gruppierungen zugeordnet, wie in der folgenden Abbildung dargestellt.
.png "Kontinuierliche Darstellung mit Prozessbereichen")
Jeder Prozessbereich besteht aus verpflichtenden, erwarteten und informativen Komponenten. Nur die verpflichtenden Komponenten sind tatsächlich erforderlich, damit einer Bewertung anhand des Modells entsprochen wird. Die verpflichtenden Komponenten sind sehr spezifische und allgemeine Ziele für jeden Prozessbereich. Die erwarteten Komponenten sind die spezifische und allgemeine Praktiken für jedes spezifische oder allgemeine Ziel. Beachten Sie: Nur weil eine erwartete Komponente einfach erwartet wird und nicht erforderlich ist, kann das heißen, dass eine spezifische oder allgemeine Praktik durch eine vergleichbare ersetzt werden kann. Die erwarteten Praktiken stellen Leitlinien für die mit der Umsetzung und Bewertung betrauten Personen dar. Wird eine alternative Praktik gewählt, ist der Umsetzende aufgefordert, dies dem Bewerter zu kommunizieren und zu begründen, weshalb eine alternative Praktik angezeigt ist. Informative Komponenten liefern Details, die die Umsetzenden dabei unterstützen, eine Prozessverbesserungsinitiative in Gang zu bringen, die sich am CMMI-Modell orientiert. Zu den informativen Komponente zählen Sub-Praktiken allgemeiner und spezifischer Praktiken sowie typische Arbeitsprodukte.
Es ist sehr wichtig zu verstehen, dass nur allgemeine und spezifische Ziele verpflichtend sind. Alles andere stellt eine Leitlinie dar. Die Beispiele von erwarteten und informativen Komponenten, die sich in der CMMI-Literatur finden, stammen häufig aus großen Integrationsprojekten in Raumfahrt und Verteidigung. Diese Projekte werden von Unternehmen durchgeführt, die das Software Engineering Institute der Carnegie-Mellon-Universität unterstützen. Diese Projekte spiegeln nicht unbedingt die Art von Projekten wider, die in Ihrem Unternehmen laufen. Sie stellen auch nicht unbedingt neuere Branchentrends dar wie beispielsweise das Aufkommen von Methoden zur agilen Softwareentwicklung.
Zusätzliche Ressourcen
Weitere Informationen finden Sie in den folgenden Webressourcen:
CMMI for Development, Version 1.3, Improving processes for developing better products and services Software Engineering Process Management Program
CMMI: Guidelines for Process Integration and Product Improvement (2. Auflage, Mary Beth Chrissis, Mike Konrad und Sandy Shrum; Addison-Wesley Professional, 2006 (deutsche Ausgabe: CMMI 1.3 für die Entwicklung: Richtlinien für Prozessintegration und Produktverbesserung, Addison-Wesley Verlag, 2011).
CMMI Distilled: A Practical Introduction to Integrated Process Improvement (3. Auflage), Dennis M. Ahren, Aaron Clause, and Richard Turner; Addison-Wesley Professional, 2008.