Capability Maturity Model Integration for Development (CMMI-DEV)

Das Capability Maturity Model Integration for Development (CMMI-DEV), oft auch nur als CMMI benannt, ist ein Qualitätsmanagementmodell für die System- und Softwareentwicklung und verwandte Bereiche und Nachfolger des bekannten CMM. Die zugrunde liegende Philosophie des CMMI ist ähnlich der von ISO 9000, allerdings spezifisch ausgerichtet auf System- und Softwareentwicklung und dadurch wesentlich konkreter. Außerdem unterstützt CMMI die kontinuierliche Verbesserung stärker, da es sich hier um ein stufenförmiges Modell handelt.

In den letzten Jahren hat sich in Deutschland ISO 9000 als das am weitesten verbreitete Qualitätsmanagementmodell durchgesetzt. Durch seine allgemeinen, abstrakten Formulierungen ist es sehr breit einsetzbar, benötigt dafür allerdings im konkreten Fall sehr viel Interpretation, um das Modell anwenden zu können. Lediglich für die Softwareentwicklung gibt es eine (informative, nicht normative) Interpretationsnorm ISO 9000-3, die die Umsetzung der allgemeinen Anforderungen auf die Softwareentwicklung beschreibt.

Dieser Beitrag beschreibt einen alternativen Ansatz, nämlich das Capability Maturity Model Integration (CMMI) [CMMI10]. Eine ausführliche Beschreibung von CMMI findet man in [Kneu07], eine Reihe von Fallbeispielen aus Unternehmen in [KnWa09]. Von der vorigen CMMI-DEV Version 1.2 gibt es auch eine offizielle, vom SEI autorisierte deutsche Übersetzung, siehe [CKS09].

CMMI wurde am Software Engineering Institute (SEI), Pittsburgh/USA, ursprünglich im Auftrag des amerikanischen Verteidigungsministeriums als Werkzeuge für die Beurteilung von Softwarelieferanten entwickelt. Wie ISO 9000 basieren auch diese beiden Modelle auf der Philosophie, Arbeitsergebnisse zu verbessern, indem die Arbeitsprozesse zur Erstellung dieser Ergebnisse verbessert werden. CMMI unterscheidet sich von ISO 9000 vor allem dadurch, dass es für den spezifischen Anwendungsbereich der Software- und Systementwicklung formuliert ist und dadurch wesentlich konkretere Aussagen machen kann. Außerdem ist es ein Stufenmodell, das einen Verbesserungspfad über fünf Stufen beschreibt, während ISO 9000 nur die zwei Stufen erfüllt und nicht erfüllt kennt.

Wenn CMMI auch nicht die gleiche Verbreitung gefunden hat wie ISO 9000 (und auch wohl nie finden wird), gibt es doch schon recht viele Unternehmen, die es einsetzen. Öffentlich bekannt ist z.B. von Siemens, Bosch, E-Plus, EDS und DB Systems, dass sie CMM bzw. CMMI einsetzen. In der deutschen Automobilbranche läuft zur Zeit eine Debatte, CMMI oder das ähnliche SPICE-Modell für die Softwareentwicklung verbindlich vorzuschreiben.

Aufbau des CMMI

Varianten des CMMI

CMMI kann in zwei verschiedenen Formen eingesetzt werden, nämlich in einer Darstellung mit Reifegraden oder in einer Darstellung mit Fähigkeitsgraden, die die gleichen Inhalte unterschiedlich strukturieren.

Daneben gibt es drei sogenannte Konstellationen, die sich jeweils auf ein bestimmtes Anwendungsgebiet beziehen, nämlich CMMI for Development (CMMI-DEV) für die Software- und Systementwicklung, CMMI for Acquisition (CMMI-ACQ) für die Beschaffung von Produkten und Leistungen, und CMMI for Services (CMMI-SVC) für die Erbringung von Dienstleistungen. Diese drei Konstellationen haben einen gemeinsamen Kern und jeweils einige spezifische Inhalte. Die folgende Beschreibung behandelt das CMMI-DEV.

Prozessgebiete

Prozessgebiete (Process Areas, PA) sind eines der wichtigsten Strukturelemente im CMMI. Ein Prozessgebiet ist jeweils eine Zusammenfassung aller Anforderungen zu einem Thema, z.B. zu Projektplanung, (organisationsweitem) Training oder Ursachenanalyse und Problemlösung und entspricht damit ganz grob einem Element der früheren ISO 9000-Versionen.

Eine inhaltliche Beschreibung der verschiedenen Prozessgebiete folgt unten, hier geht es um die gemeinsame Struktur dieser Prozessgebiete. Jedes Prozessgebiet umfasst eine Reihe von Zielen, die dabei erreicht werden sollen:

Jedem Ziel sind ein oder mehrere Praktiken zugeordnet, mit denen das Ziel erreicht werden soll. Es gibt spezifische Praktiken, die zu jeweils einem Prozessgebiet gehören und dazu dienen, ein spezifisches Ziel zu erreichen, und generische Praktiken, die dazu dienen, ein generisches Ziel zu erreichen.

Darstellung in Reifegraden

In der Darstellung in Reifegraden des CMMI gibt es fünf Stufen, genannt Reifegrade (maturity levels), nämlich:

Jedem dieser Reifegrade (ausgenommen Reifegrad 1) sind eine Reihe von Prozessgebieten mit konkreten Anforderungen zugeordnet (siehe Tabelle 1), deren Erfüllung jeweils einen wichtigen Aspekt des Entwicklungsprozesses unterstützt.

 ReifegradProzessgebiete
5Prozessoptimierung Organisationsweites Innovationsmanagement (Organizational Innovation and Deployment)
Ursachenanalyse und -beseitigung (Causal Analysis and Resolution)
4Quantitativ geführt Organisationsweites Prozessfähigkeitsmanagement (Organizational Process Performance)
Quantitatives Projektmanagement (Quantitative Project Management)
3Definiert Anforderungsentwicklung (Requirements Development)
Technische Umsetzung (Technical Solution)
Produktintegration (Product Integration)
Verifizierung (Verification)
Validierung (Validation)
Organisationsweite Prozessausrichtung (Organizational Process Focus)
Organisationsweite Prozessentwicklung (Organizational Process Definition)
Organisationsweite Aus- und Weiterbildung (Organizational Training)
Fortgeschrittenes Projektmanagement (Integrated Project Management)
Risikomanagement (Risk Management)
Entscheidungsfindung (Decision Analysis and Resolution)
2Geführt Anforderungsmanagement (Requirements Management)
Projektplanung (Project Planning)
Projektverfolgung und -steuerung (Project Monitoring and Control)
Zulieferungsmanagement (Supplier Agreement Management)
Messung und Analyse (Measurement and Analysis)
Prozess- und Produkt-Qualitätssicherung (Process and Product Quality Assurance)
Konfigurationsmanagement (Configuration Management)
1Initial  

Tabelle 1: Die Prozessgebiete des CMMI für Entwicklung und ihre Zuordnung zu Reifegraden

Darstellung in Fähigkeitsgraden

In der Darstellung in Fähigkeitsgraden hat eine Organisation keinen einheitlichen Reifegrad, sondern jedes Prozessgebiet wird getrennt bewertet und die Organisation hat einen Fähigkeitsgrad (Capability Level, im Gegensatz zum Reifegrad, Maturity Level) pro Prozessgebiet. In Summe erhält man ein sogenanntes Fähigkeitsprofil, das eine wesentlich detailliertere Beschreibung ermöglicht. In dieser Darstellung des CMMI gibt es drei generische Ziele, oder anders ausgedrückt, es gibt drei Stufen der Institutionalisierung eines Prozessgebietes, plus die Stufe 0, falls keines der generischen Ziele erfüllt ist.

Anmerkung: Bis Version 1.2 von CMMI gab es zusätzlich noch zwei weitere generische Ziele GG4 und GG5, die aber mit Version 1.3 weggefallen sind.

Jedes generische Ziel ist einem Fähigkeitsgrad zugeordnet. Dieser bezieht sich allerdings auf jeweils ein Prozessgebiet und nicht die Gesamtheit der Prozessgebiete, wie im stufenförmigen Modell.

Prozessgebiete des CMMI

Dieser Beitrag beschränkt sich auf die Prozessgebiete des CMMI-SE/SW auf den Reifegraden 2 und 3, da diese die größte praktische Bedeutung haben.

Reifegrad 2

Anforderungsmanagement

"Anforderungsmanagement" (Requirements Management, REQM) sorgt dafür, dass alle Anforderungen, die an das Projekt gestellt werden, erfasst, analysiert und bewertet werden. Dazu gehören also in erster Linie die direkten Anforderungen des Kunden ("die Liste soll alphabetisch geordnet sein"), aber auch Anforderungen aus Sicht der Betriebsführung ("wenn die Netzverbindung zu mehr als n% ausgelastet ist, soll eine Warnmeldung gegeben werden"), vom Gesetzgeber, von der eigenen Entwicklungsorganisation oder evtl. von anderen. Zusätzlich zu diesen Anforderungen gibt es noch Rahmenbedingungen, die genauso berücksichtigt werden müssen, z.B. maximal zur Verfügung stehendes Budget und Ressourcen.

Projektplanung

Die "Projektplanung" (Project Planning, PP) basiert auf den anfangs erfassten Anforderungen und setzt diese um in einen Projektplan, der die üblichen Faktoren wie Budget, Zeitplan, Projektrisiken, Projektressourcen etc. umfasst. Besonderen Wert legt CMMI dabei auf nachvollziehbare Schätzungen von Aufwand und Kosten, die u.a. die Größe der Arbeitsergebnisse (gemessen z.B. in Codezeilen, Funktionspunkten oder Anzahl Anforderungen) mit berücksichtigen. Dies geschieht normalerweise auf Basis von historischen Daten, die dazu aber erst einmal erfasst werden müssen.

Projektverfolgung und -steuerung

"Projektverfolgung und -steuerung" (Project Monitoring and Control, PMC) dient dazu, ein Projekt entsprechend der Planung durchzuführen und bei Abweichungen von der Planung zu reagieren. Wie bei allen anderen Prozessgebieten fordert das CMMI auch hier nichts Überraschendes, sondern formuliert als Anforderungen, was sich in der Praxis als wesentliche Faktoren für den Projekterfolg herausgestellt hat und was man zum großen Teil in fast jedem Lehrbuch über Projektmanagement nachlesen kann. Vieles klingt wie eine Selbstverständlichkeit und erst wenn man versucht, alle diese Selbstverständlichkeiten gleichzeitig umzusetzen, wird einem bewusst, wie schwierig dies ist.Die wichtigsten geforderten Aktivitäten bei der Projektverfolgung und -steuerung nach CMMI sind die laufende Überwachung des Projektes anhand des Plans und die Durchführung von Korrekturmaßnahmen bei Bedarf.

Zulieferungsmanagement

Wird ein Teil des Projektes nicht von der Entwicklungsorganisation selbst durchgeführt, sondern an einen Unterauftragnehmer weitergegeben, so muss man sicherstellen, dass auch diese Arbeit und ihre Ergebnisse den Anforderungen entsprechen. Dabei kann es sich um fertige Standardprodukte handeln, um komplette Individualentwicklung durch einen Unterauftragnehmer oder, als Mittelweg, die individuelle Anpassung einer Standardsoftware. Dieses Thema wird im "Zulieferungsmanagement" (Supplier Agreement Management, SAM) behandelt. Es umfasst die Auswahl geeigneter Lieferanten sowie deren Steuerung, beginnend mit der Vereinbarung von Rechten und Pflichten beider Seiten. Zu dieser Vereinbarung gehört üblicherweise die Erstellung eines Projektplanes durch den Unterauftragnehmer, der vom Auftragnehmer überprüft und genehmigt wird und gegen den er den Fortschritt überprüft.

Messung und Analyse

Ziel von "Messung und Analyse" (Measurement and Analysis, MA) ist es, dem Management Informationen als Basis von Entscheidungen bereitzustellen. Im CMM gab es zu jedem Schlüsselprozessgebiet die Anforderung, Metriken zu erfassen. Im CMMI wurden diese einzelnen Anforderungen in einem eigenen Prozessgebiet auf Reifegrad 2 in der Kategorie "Unterstützung" zusammengefasst. Das verleiht ihnen einerseits eine größere Bedeutung, andererseits erlaubt es mehr Flexibilität, da man jetzt nicht mehr notwendigerweise zu jedem Prozessgebiet Metriken benötigt; stattdessen wird die Festlegung der zu erhebenden Metriken am Informationsbedarf ausgerichtet. Dieses Vorgehen ist stark am Goal-Question-Metric-Ansatz (GQM) orientiert, bei dem man ausgehend von den Zielen der Messung Fragen identifiziert, die zum Erreichen der Ziele beantwortet werden müssen. Diese Fragen werden im nächsten Schritt weiter heruntergebrochen in konkrete Metriken.

Prozess- und Produkt-Qualitätssicherung

Qualitätssicherung nach CMMI umfasst nur einen Teil dessen, was üblicherweise unter Qualitätssicherung verstanden wird. Thema der Qualitätssicherung nach CMMI ist die Prüfung, dass Vorgaben für Prozesse und Arbeitsergebnisse eingehalten werden, also eher die formale Korrektheit (Einhaltung von definierten Prozessen, Programmierstandards, Namenskonventionen etc.). Dies wird üblicherweise durch Reviews abgedeckt. In dem Prozessgebiet "Prozess- und Produkt-Qualitätssicherung" (Process and Product Quality Assurance, PPQA) wird die objektive Prüfung der Arbeitsergebnisse und der zugehörigen Entwicklungsprozesse gefordert. Zusätzlich fordern alle Prozessgebiete im Rahmen einer generischen Praktik die objektive Bewertung der Einhaltung des jeweiligen Prozesses.

Konfigurationsmanagement

Aufgabe des "Konfigurationsmanagements" (Configuration Management, CM) ist es, die Integrität der Arbeitsergebnisse sicherzustellen, also von Plänen, der Dokumentation und den verschiedenen Codeteilen. Um das umzusetzen, richtet man üblicherweise ein Bibliothekssystem ein, in dem die einzelnen Teile abgelegt und verwaltet werden. Je nach individuellem Bedarf muss eine solche Bibliothek notwendige Zugriffsbeschränkungen, Versionierung, Sicherung und Wiederherstellung sowie Auswertungen unterstützen. In den meisten (nicht-trivialen) Fällen wird dazu ein geeignetes Werkzeug für das Konfigurationsmanagement notwendig sein, aber aus CMMI-Sicht ist z.B. auch die Ablage im Dateisystem akzeptabel, wenn sie durch entsprechende organisatorische Maßnahmen unterstützt wird.

Reifegrad 3

Anforderungsentwicklung

"Anforderungsentwicklung" (Requirements Development, RD) ist der Einstieg in den Entwicklungsprozess und gleichzeitig die Vertiefung des "Anforderungsmanagements", das von bekannten Anforderungen ausgeht, die erfasst, analysiert, entschieden und ggf. umgesetzt werden. Thema der Anforderungsentwicklung sind die Methoden für die Identifizierung und Analyse der Anforderungen. Anforderungsentwicklung beginnt mit der Entwicklung der Anforderungen des Kunden, also damit herauszufinden, was der Kunde tatsächlich will. Ausgangspunkt dafür sind die "Bedürfnisse der Betroffenen, Erwartungen, Einschränkungen und Schnittstellen", die im Normalfall zuerst nur unvollständig bekannt und inkonsistent sind und zunächst einmal identifiziert, vervollständigt und konsolidiert werden müssen. Das Ergebnis dieser Aktivität geht üblicherweise in ein Dokument wie das Grobkonzept oder Lastenheft ein.

Technische Umsetzung

Basierend auf den Ergebnissen der Anforderungsentwicklung wird in der "Technischen Umsetzung" (Technical Solution, TS) das spezifizierte System entworfen und implementiert. Hier wird die Verlagerung des Schwerpunktes von Projektleitung und Management auf Reifegrad 2 zu Entwicklung und Entwickler auf Reifegrad 3 besonders deutlich. Der erste Schritt bei der technischen Umsetzung ist die Auswahl von Lösungen für Produktkomponenten, basierend auf einer Untersuchung der Lösungsalternativen. Damit soll verhindert werden, dass man sich gleich auf einen Lösungsansatz festlegt, ohne die Alternativen zu betrachten. Dazu gehört beispielsweise eine bewusste Entscheidung auf Basis selbst festgelegter Kriterien, ob man ein benötigtes System bzw. benötigte Software selbst erstellt (Individualsoftware), fertig kauft (Standardsoftware) oder Vorhandenes wiederverwendet.

Produktintegration

Unter "Produktintegration" (Product Integration, PI) versteht CMMI die Integration der einzelnen Komponenten zu einem Produkt. Diese Integration geschieht üblicherweise iterativ, von der untersten Ebene der Klassen/Programme/Funktionen über die Ebene der Architekturbausteine wie Clientteil, Serverteil, Datenbank und DBMS sowie Netzwerk bis hin zur Integration des neuen Produktes in seine typischerweise aus verschiedenen anderen Produkten oder Anwendungen bestehende Umgebung. Aufgabe der Produktintegration ist es, auf jeder Ebene die Integration vorzubereiten und durchzuführen und das Ergebnis zu evaluieren, bevor man die nächste Integrationsebene erreicht. Produktintegration ist also ein iterativer Prozess, bei dem jeweils die einzelnen Komponenten integriert werden, das Ergebnis gegen vorher definierte Kriterien geprüft wird (kommt z.B. die erwartete Antwort auf eine Anfrage vom Client an den Server zurück?) und nach erfolgreicher Integration der nächste Integrationsschritt kommt.

Verifizierung

Unter "Verifizierung" (Verification, VER) versteht man die Prüfung eines Ergebnisses auf Übereinstimmung mit seiner Spezifikation (vgl. "Validation" unten). Die Anforderungen des CMMI zur Verifizierung sind relativ allgemein formuliert; gefordert wird die Vorbereitung der Verifizierung inklusive der Auswahl der zu verifizierenden Arbeitsergebnisse, die Durchführung von Reviews sowie allgemein die Durchführung der Verifizierung. Wichtigste Methoden zur Verifizierung sind Test und Review, wobei nicht jeder Test und jeder Review zur Verifizierung, also zur Prüfung gegen eine vorher erstellte (funktionale oder nichtfunktionale) Spezifikation, dient. Eine weitere, wesentlich seltener verwendete Verifizierungsmethode ist die statische Analyse.

Validierung

Unter "Validierung" (Validation, VAL) versteht man die Prüfung eines Ergebnisses gegen die (expliziten oder impliziten) Anforderungen des Kunden. Im Gegensatz zur Verifizierung ist Validierung also ein prinzipiell informeller Schritt, da man hier gegen die informellen Anforderungen, nicht gegen die formell dokumentierten Anforderungen prüft. Eine andere Formulierung des Unterschiedes ist folgende:

Organisationsweite Prozessausrichtung

Aufgabe der "Organisationsweiten Prozessausrichtung" (Organizational Process Focus, OPF) ist die kontinuierliche Verbesserung der Prozesse der Organisation. Verbesserungsinformationen als Grundlage für Entscheidungen über Verbesserungen können aus vielen Quellen stammen:

Wenn man die Nutzung der definierten Prozesse und die Sammlung der Verbesserungsvorschläge ernsthaft angeht, bekommt man sehr schnell mehr Vorschläge zusammen, als man umsetzen kann und will. Manche davon werden sich widersprechen oder keine echte Verbesserung sein bzw. zumindest nicht den Aufwand rechtfertigen. Aus diesem Grund umfasst OPF zuerst die Sammlung der vorgeschlagenen Prozessverbesserungen und anschließend die Entscheidung, welche davon tatsächlich umgesetzt werden sollen.

Organisationsweite Prozessentwicklung

Im Prozessgebiet "Organisationsweite Prozessentwicklung" (Organizational Process Definition, OPD) werden die in der Organisation zu nutzenden Prozesse bereitgestellt, damit die Projekte diese (im Rahmen des "Fortgeschrittenen Projektmanagements") für den eigenen Bedarf anpassen und nutzen können. Dazu gehört vor allem die Aufgabe, alle wichtigen Prozesse der Organisation zu definieren und diese Definition zu pflegen. Welche Prozesse als ausreichend wichtig angesehen werden und wie detailliert die Definition sein soll, muss jeweils individuell entschieden werden. Wichtigstes Kriterium ist dabei wie üblich der Nutzen, den die Organisation aus der Definition der Prozesse zieht, was allerdings einen großen Interpretationsspielraum lässt. Einen hohen Nutzen zieht man typischerweise vor allem aus der Definition solcher Prozesse, die ein hohes Risiko beinhalten oder die sehr häufig durchgeführt werden, sowie gruppenübergreifender Prozesse, bei denen ein hoher Abstimmungsbedarf herrscht.

Organisationsweite Aus- und Weiterbildung

Aufgabe der "Organisationsweiten Aus- und Weiterbildung" (Organizational Training, OT) ist es, dafür zu sorgen, dass die Mitarbeiter und andere Personen qualifiziert sind, ihre Aufgaben wahrzunehmen. Unter Training wird im CMMI nicht nur Schulung im engeren Sinne verstanden, sondern Training umfasst alle Maßnahmen zur Qualifizierung der Mitarbeiter, also beispielsweise auch Training-on-the-job oder Coaching.

Fortgeschrittenes Projektmanagement

Auf Reifegrad 2 wurden die verschiedenen Projektmanagementthemen auf Ebene des einzelnen Projektes betrachtet. Das "Fortgeschrittene Projektmanagement" (Integrated Project Management, IPM) bindet diese Aktivitäten in die Organisation ein und umfasst folgende Punkte:

Risikomanagement

Beim "Risikomanagement" (Risk Management, RSKM) geht es darum, Projektrisiken, also Risiken, die den Projekterfolg beeinträchtigen oder sogar verhindern können, zu managen und den Projekterfolg trotz der Risiken sicherzustellen. Eine geeignete Methode dafür ist z.B. die FMEA.

Entscheidungsfindung

"Entscheidungsfindung" (Decision Analysis and Resolution, DAR) dient der Unterstützung der anderen Themen, indem es eine systematische Vorgehensweise bei der Entscheidungsfindung fordert und unterstützt. CMMI fordert dabei eine Vorgehensweise basierend auf der Festlegung der Bewertungskriterien, der Identifikation der Lösungsalternativen und schließlich der Entscheidung für eine bestimmte Lösung.

Appraisals

SCAMPI

Mit Hilfe eines Appraisals kann ermittelt werden, auf welcher Stufe (Reifegrad bzw. Fähigkeitsprofil) sich ein Unternehmen im Reifegradmodell befindet und wie die Softwareprozesse weiter verbessert werden können. Damit wird eine Aussage über die Prozessreife eines Unternehmens gemacht. Die vom SEI definierte Methode für CMMI-Begutachtungen ist SCAMPI (Standard CMMI Appraisal Method for Process Improvement). SCAMPI-Begutachtungen dienen einerseits zur internen Prozessverbesserung, mit Betonung der Selbstbewertung und der Identifizierung von Verbesserungsmöglichkeiten.

Andererseits können SCAMPI-Begutachtungen einem Auftraggeber dazu dienen, die Prozessreife eines (potenziellen) Auftragnehmers zu bewerten, und bilden damit eine Grundlage für die Vergabe eines Auftrages. Dies war die ursprüngliche Intention bei der Entwicklung des CMM – das amerikanische Verteidigungsministerium wollte eine Entscheidungsgrundlage bei der Vergabe von Aufträgen im Softwarebereich.

Übrigens, falls Sie sich wundern, warum hier von "Appraisals" und nicht "Assessments" die Rede ist: Das SEI hat die Begrifflichkeiten hier verändert und spricht bei CMMI nicht mehr, wie bei CMM, von Assessments, sondern von Appraisals. Inhaltlich handelt es sich aber dabei (nahezu) um das Gleiche.

Bei Appraisals, insbesondere auch SCAMPI-Appraisal, wird zwischen drei verschiedenen Klassen von Appraisals unterschieden:

Ausblick

CMMI ist ein sehr hilfreicher Ansatz für das Qualitätsmanagement im Bereich der Software- und Systementwicklung sowie verwandter Bereiche. Organisationen, die in diesem Bereich arbeiten, sollten prüfen, ob ihnen die Nutzung des CMMI helfen kann, ggf. auch in Kombination mit ISO 9000. Sie gewinnen damit eine im Vergleich zu ISO 9000 wesentlich konkretere Unterstützung für die Entwicklungsaktivitäten sowie eine stärkere Unterstützung der kontinuierlichen Verbesserung.

Literatur