Dr. Ralf Kneuper

Beratung für
Softwarequalitätsmanagement und
Prozessverbesserung

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:

• Spezifische Ziele gelten nur für das jeweilige Prozessgebiet und beschreiben die speziellen Anforderungen für dieses Prozessgebiet.
• Generische Ziele beschreiben die sogenannte "Institutionalisierung" des Prozessgebietes, also all das, was zu tun ist, damit die spezifischen Ziele regelmäßig, dauerhaft und effizient umgesetzt werden. Diese Ziele sind übergreifend für die verschiedenen Prozessgebiete formuliert und werden daher als generisch bezeichnet. Die verschiedenen generischen Ziele beschreiben die unterschiedliche Intensität, mit der das jeweilige Prozessgebiet institutionalisiert wird.

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:

• Reifegrad 1 "initial" (initial): Die Prozesse sind als ad hoc oder sogar chaotisch charakterisiert. Prozesse sind wenig oder nicht definiert und der Erfolg eines Projektes hängt in erster Linie vom Einsatz und der Kompetenz einzelner Mitarbeiter ab ("Helden").
• Reifegrad 2 "geführt" (managed) fordert, die wesentlichen Managementprozesse zu etablieren, um Kosten, Zeitplan und Funktionalität von Projekten zu planen und zu steuern. Vereinfacht gesagt besteht Reifegrad 2 aus einer detaillierten Beschreibung dessen, was Projektmanagement ausmacht. Dahinter steckt die Erfahrung, dass ein funktionierendes Projektmanagement die Grundlage aller weiteren Verbesserung ist, bzw. umgekehrt ohne Projektmanagement auch alles Weitere wie z.B. definierte Prozesse nicht erfolgreich umgesetzt werden kann.
• Reifegrad 3: "definiert" (defined): Hier verlagert sich der Schwerpunkt der Arbeit von den einzelnen Projekten auf die Organisation als Ganzes und von den Management-Aktivitäten zu den Entwicklungsaktivitäten. Die meisten Anforderungen der Reifegrad 3 beziehen sich darauf, einheitliche Prozesse für die gesamte Organisation einzuführen, während auf Reifegrad 2 noch jedes Projekt weitgehend eigene, individuelle Prozesse nutzen konnte. Dabei geht es in erster Linie (aber nicht nur) um die Entwicklungsprozesse im Lebenszyklus von Systemen oder Software. Reifegrad 3 entspricht ganz grob den Anforderungen von ISO 9001, soweit es um die System- oder Softwareentwicklung selbst geht, wobei allerdings viele Unterschiede im Detail bestehen.
• Reifegrad 4: "quantitativ geführt" (quantitatively managed): Wenn eine Organisation einheitliche Prozesse eingeführt hat, dann empfiehlt das CMMI als nächsten Schritt die intensive Nutzung von Metriken und Kennzahlen, um eine bessere Entscheidungsgrundlage für Verbesserungsaktivitäten zu bekommen. Auf den niedrigeren Reifegraden werden zwar schon Metriken verwendet, vor allem zur Projektsteuerung, aber den vollen Nutzen kann man erst daraus ziehen, wenn man auf Reifegrad 3 einheitliche Prozesse eingeführt hat und unterschiedliche Kennzahlen nicht mehr auf unterschiedliche Prozesse oder gar Messmethoden zurückzuführen sind.
• Reifegrad 5: "Prozessoptimierung" (optimizing): Reifegrad 5, die höchste Stufe im Modell, legt das Hauptaugenmerk auf die kontinuierliche Verbesserung mit der systematischen Auswahl und Einführung von Verbesserungen sowie der systematischen Analyse von noch auftretenden Fehlern und Problemen.

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.

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.

• GG 1: Spezifische Ziele erreichen
• GG 2: Geführte Prozesse institutionalisieren
• GG 3: Definierte Prozesse institutionalisieren

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:

• Validierung prüft, ob man "das Richtige" implementiert hat.
• Verifizierung prüft, ob man richtig implementiert hat.

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:

• Rückmeldungen der Benutzer der Prozesse, also der Mitarbeiter, die nach diesen Prozessen arbeiten (sollen).
• Daten aus Messungen an den Prozessen, die beispielsweise belegen, ob ein bestimmtes Problem besteht und der Prozess verbessert werden sollte.
• Ergebnisse von Reviews und Qualitätssicherungsmaßnahmen.

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:

• Die Anpassung der allgemein gültigen (organisationsweiten) Prozesse, wie sie im Rahmen der organisationsweiten Prozessdefinition erstellt und festgelegt wurden, auf das einzelne Projekt (Tailoring) und die Durchführung des Projektes gemäß diesen angepassten Prozessen.
• Die Integration der verschiedenen für das Projekt relevanten Pläne zu einem gemeinsamen Projektplan.
• Die Zusammenarbeit der Entwicklungsgruppe mit den anderen am Erfolg eines Softwareprojektes beteiligten Gruppen, wie z.B. Vertrieb, Qualitätswesen oder Rechenzentrum.

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:

• Appraisalmethoden der Klasse A sind vor allem auf zuverlässige und korrekte Ergebnisse optimiert, sind aber damit auch am aufwändigsten. Die wichtigste Methode dieser Klasse ist SCAMPI. Appraisalmethoden der Klasse A erfüllen damit gleichzeitig die Anforderungen von ISO 15504 (SPICE) und werden als einzige vom SEI als ausreichend angesehen, um eine Aussage über den Reifegrad bzw. die Fähigkeitsgrade einer Organisation zu machen.
• Appraisalmethoden der Klasse B stellen geringere Anforderungen an die Zuverlässigkeit der Ergebnisse. Diese müssen u.a. nicht so gründlich durch mehrere Quellen bestätigt werden, dadurch wird der Aufwand für das Assessment geringer.
• Appraisalmethoden der Klasse C sind eher auf häufige, schnelle Überprüfungen ausgelegt und reduzieren dazu den Aufwand und die Anforderungen an die Zuverlässigkeit der Ergebnisse für das Appraisal weiter. Auch wenn die Ergebnisse eines Appraisals der Klasse C nicht so zuverlässig sind wie die der Klassen A und B, reichen sie für viele Zwecke vollkommen aus. Durch den geringeren Aufwand ist es beispielsweise möglich, die Appraisal relativ häufig durchzuführen und die eigene Verbesserung laufend zu überprüfen.

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

• [CKS09] CMMI. Richtlinien für Prozess-Integration und Produkt-Verbesserung. Addison-Wesley, 2009.
• [CMMI10] CMMI for Development, Version 1.3 (CMMI-DEV). November 2010. Technical Report CMU/SEI-2010-TR-033. Verfügbar unter http://www.sei.cmu.edu/cmmi/
• [Kneu07] Kneuper: CMMI. Verbesserung von Softwareprozessen mit Capability Maturity Model Integration, 3. Auflage. dpunkt.verlag, Heidelberg 2007.
• [KnWa09] Kneuper, Wallmüller: CMMI in der Praxis. Fallstudien zur Verbesserung der Entwicklungsprozesse mit CMMI. dpunkt.verlag, Heidelberg 2009.