Spätestens seit Beginn des 20. Jahrhunderts, als die Automobilindustrie entstand, werden die industriellen Fertigungsprozesse beobachtet, analysiert und optimiert, weil sie großen Einfluss auf die Produktivität und auf die Qualität der Produkte haben.
Da Software nur entwickelt, nicht gefertigt wird (siehe Abschnitt 2.3.2), lässt sich die Prozessoptimierung nicht einfach übernehmen. Man kann aber die Grundideen auf die Software-Entwicklung übertragen. Seit den Achtzigerjahren entstanden verschiedene Ansätze zur Bewertung und Verbesserung der Software-Prozesse. Bekannt und weit verbreitet sind die ISO-9000-Normenfamilie (insbesondere die Norm ISO 9000-3) und das Reifegradmodell für Entwicklungsprozesse CMM (Capability Maturity Model). In den letzten Jahren hat SPICE an Bedeutung gewonnen. In diesem Kapitel werden CMM/CMMI (Abschnitt 11.2) und SPICE (Abschnitt 11.3) vorgestellt.
Wir verzichten auf eine Behandlung der ISO-9000-Normen; sie sind bis auf wenige Teile nicht softwarespezifisch. Erfahrungen mit ISO 9000 für Software-Projekte sind negativ (Bellin, Stelzer, Mellis, 1996). Durch CMMI und SPICE hat ISO 9000 für Software-Projekte weiter an Bedeutung verloren.
Natürlich ist der Prozess nicht der einzige Faktor, der sich auf die Qualität der erstellten Software auswirkt. Insbesondere die Fähigkeiten der Mitarbeiter, aber auch die eingesetzten Techniken haben erheblichen Einfluss. Darum darf nicht nur der Prozess betrachtet werden, will man die Software-Entwicklung als Ganzes verbessern. Außerdem ist zu beachten, dass wir uns in der Software-Entwicklung – anders als bei der Herstellung eines industriellen Massenprodukts, z. B. einer elektrischen Handbohrmaschine – mit dem Entwicklungsprozess befassen, nicht mit dem Fertigungsprozess. Während der Fertigungsprozess unmittelbare Auswirkungen auf das Produkt hat, steht zwischen dem Entwicklungsprozess und dem Produkt das Projekt. Selbst dort, wo der Prozess nicht einmal ansatzweise definiert ist, kann das Projekt ein ordentliches Produkt hervorbringen; umgekehrt ist ein perfekter Prozess keineswegs eine Garantie für eine gute Entwicklung. Wir sehen folgenden Zusammenhang:
Der Entwicklungsprozess muss so gestaltet sein, dass er das Projekt in allen Punkten, die einheitlich organisiert und durchgeführt werden sollten, festlegt. In allen Punkten, die nur auf der Ebene des Projekts entschieden werden können, sollte der Prozess generisch bleiben, d. h. eine projektspezifische Ausprägung erlauben oder keine Vorgaben machen. Der Prozess kann nur nützen, wenn ihn alle Beteiligten, Manager wie Entwickler, akzeptieren; dazu sollte sein Nutzen messbar sein.
Die Techniken (Sprachen, Methoden, Werkzeuge) müssen so ausgewählt werden, dass sie die durchzuführenden Tätigkeiten möglichst gut unterstützen.
Die Mitarbeiter müssen so gut ausgebildet sein, dass sie den Entwicklungsprozess umsetzen und die gewählten Techniken anwenden können.
Alle drei Faktoren müssen aufeinander abgestimmt sein. Ein guter Software-Entwicklungsprozess allein garantiert nicht, dass auch die Ergebnisse der Entwicklung gut sind.
Das US-Verteidigungsministerium (DoD) ist der weltweit größte Auftraggeber für Software. Die Software ist in der Regel Teil eines (Waffen-)Systems, z. B. eines Kampfflugzeugs. Wird sie nicht termingerecht und in der geforderten Qualität geliefert, ist das gesamte System unbrauchbar.
Darum hat das DoD ein starkes Interesse daran, mögliche Software-Lieferanten vor Erteilung eines Auftrags bewerten und vergleichen zu können. 1987 finanzierte es den Aufbau des Software Engineering Institute (SEI) auf dem Gelände der Carnegie Mellon University in Pittsburgh, Pennsylvania, mit der das SEI auch organisatorisch verbunden ist. Die erste und bis heute wichtigste Aufgabe des SEI bestand darin, ein Verfahren zur Durchführung einer solchen Bewertung zu entwickeln und zu verbreiten. Das Ergebnis war das Capability Maturity Model (CMM), das 1991 vorgestellt wurde.
CMM ist im Kern ein detaillierter Katalog von Anforderungen (Kriterien), eine Art Checkliste in fünf Stufen. Eigentlich sind es nur vier; für die Eintrittsstufe 1 gibt es keine Kriterien. Somit bleibt eine Organisation1, die nicht allen Kriterien der Stufe 2 genügt, auf Stufe 1 oder wird dorthin zurückgestuft. Erfüllt die Organisation alle Kriterien, so steht sie auf Stufe 5, dem höchsten Reifegrad. Damit wird ihr bescheinigt, dass ihre Prozesse organisatorisch optimale Voraussetzungen für erfolgreiche Software-Projekte bieten. Technische Aspekte werden dabei aber ebenso wenig berücksichtigt wie die Kompetenz der Entwickler. Auf CMM basierend entstanden Bewertungsmodelle für verschiedene Bereiche (z. B. für die Systementwicklung oder für die integrierte Produktentwicklung).
1997 wurde ein Nachfolgeprojekt gestartet, das die CMM-Varianten, die es auch für Hardware- und Systemprojekte gab, zusammenführen und nach den Erfahrungen mit CMM verbessern sollte. So entstand CMMI (Capability Maturity Model Integration), das seit August 2006 in der Version 1.2 vorliegt; die Version 1.3 ist für 2010 angekündigt. CMMI ist modular aufgebaut, damit bereichsspezifische Varianten – sogenannte Konstellationen – auf einer gemeinsamen Basis erstellt werden können. Die aktuelle Version bietet Konstellationen für die Produktentwicklung (CMMI-DEV), für die Akquisition (CMMI-ACQ) und für Dienstleistungen (CMMI-SVC). Jede Konstellation enthält ein angepasstes CMMI-Modell, dazu die Schulungsunterlagen und Begutachtungsverfahren. Wir stellen nachfolgend CMMI für die Software-Entwicklung, also CMMI-DEV, vor. Dabei stützen wir uns auf den technischen Bericht des SEI (CMMI, 2006a) sowie auf die Bücher von Kneuper (2007) und Ahern, Clouse, Turner (2008).
Bevor wir auf die Details des CMMI eingehen, betrachten wir die angestrebten Ziele und die Annahmen, die der Bewertung zu Grunde liegen. Folgende Ziele sollen mit dem Reifegradmodell erreicht werden:
Das Modell soll sich auf alle Organisationen, in denen Software bearbeitet wird, anwenden lassen und ein Bild der aktuellen Prozessqualität liefern.
Die Schwächen, aber auch die Stärken des realen, also praktisch gelebten Prozesses sollen durch die Begutachtung klar sichtbar werden, damit daraus eine Anleitung zur Prozessverbesserung abgeleitet werden kann.
Die Prozessbewertung soll neutral sein gegenüber der eingesetzten Technik. Beispielsweise hat CMMI keine Präferenz für die objektorientierte gegenüber einer konventionellen Entwicklung.
Die Reifegrade sollen aufeinander aufbauen; eine höhere Stufe setzt alle niedrigeren Stufen voraus. Der Übergang auf die nächsthöhere Stufe soll durch systematische Verbesserungen erreichbar sein, sodass man systematisch von Stufe zu Stufe aufsteigen kann.
Das Modell soll konsistent zum ISO-Standard 15504 (SPICE) sein (siehe 11.3).
CMMI beruht auf folgenden Annahmen:
Die Reife eines Software-Prozesses ist umso höher, je besser die benutzten Prozesse definiert, beschrieben und geplant sind und je genauer sie beobachtet und gesteuert werden.
Hohe Prozessreife erfordert statistische Kontrolle. Die Erfassung von Kennzahlen und ihre statistische Auswertung unterstützen eine kontinuierliche Verbesserung.
Je höher der Reifegrad ist, desto genauer können Termine, Kosten und Qualität prognostiziert werden; das Risiko, die Projektziele zu verfehlen, sinkt, die Qualität der entwickelten Produkte steigt.
CMMI nutzt als oberstes Strukturierungselement sogenannte Prozessbereiche. Jeder Prozessbereich (process area) wird durch Ziele beschrieben, die erreicht werden müssen, sowie durch Aufgaben (practices), die eine Organisation beherrschen muss, um die Ziele zu erreichen. CMMI unterscheidet zwischen spezifischen Zielen, die genau einen Prozessbereich betreffen, und generischen Zielen, die beschreiben, was eine Organisation tun muss, damit die spezifischen Ziele auch dauerhaft erfüllt werden. Diese gelten naturgemäß für mehrere Prozessbereiche. Die gleiche Unterscheidung gibt es auch für die Aufgaben. Tabelle 11–1 nennt und beschreibt die Prozessbereiche, die CMMI definiert; wir verwenden die englischen Originalbegriffe, auf denen auch die Abkürzungen beruhen.
Prozessbereich |
Der Prozessbereich umfasst alle Tätigkeiten, um ... |
Requirements Management (REQM) |
... die Anforderungen an die zu entwickelnden Produkte und Komponenten zu verwalten und Inkonsistenzen zwischen den Anforderunge, den Projektplänen und den Arbeitsergebnissen zu erkennen. |
Project Planning (PP) |
... alle Pläne zu erstellen und zu pflegen, die die Projektaktivitäten festlegen. |
Project Monitoring and Control (PMC) |
... den Projektfortschritt festzustellen, damit angemessene Korrekturmaßnahmen ergriffen werden können, wenn der Fortschritt des Projekts wesentlich vom Projektplan abweicht. |
Measurement and Analysis (MA) |
... die Organisation in die Lage zu versetzen, Messungen durchzuführen. |
Process and Product Quality Assurance (PPQA) |
... Mitarbeitern und Management einen objektiven Einblick in die Qualität der Prozesse und der Arbeitsergebnisse zu liefern. |
Configuration Management (CM) |
... die Integrität von Arbeitsergebnissen zu sichern und zu wahren. Dazu werden Konfigurationen identifiziert und überwacht und auf der Basis von Konfigurationsaudits Berichte über den Status der Konfigurationen erstellt. |
Supplier Agreement Management (SAM) |
... den Einkauf von Produkten zu steuern, mit deren Lieferanten eine formelle Vereinbarung besteht. |
Requirements Development (RD) |
... die Kundenanforderungen an Produkte und Produktkomponenten zu erfassen, zu analysieren und zu validieren. |
Technical Solution (TS) |
... zu den Anforderungen Lösungen (Produktkomponenten) zu entwerfen und zu implementieren. |
Product Integration (PI) |
... das Produkt aus den Produktkomponenten zusammenzubauen. Dabei muss sichergestellt werden, dass es funktioniert wie in den Anforderungen gefordert. |
... sicherzustellen, dass die Arbeitsergebnisse die spezifizierten Anforderungen erfüllen. |
|
Validation (VAL) |
... sicherzustellen, dass ein Produkt den geplanten Zweck erfüllt, wenn es in der Einsatzumgebung betrieben wird. |
Organizational Process Focus (OPF) |
... die organisationsweite Prozessverbesserung zu planen und durchzuführen. Dazu müssen die Schwächen und Stärken der Prozesse und der Prozessdokumentation bekannt sein. |
Organizational Process Definition (OPD) |
... die Prozesse zu definieren und die Prozessdokumente zu erstellen und zu pflegen, die in der Organisation genutzt werden. |
Organizational Training (OT) |
... die Mitarbeiter so auszubilden, dass sie in der Lage sind, ihre Rollen effektiv und effizient auszufüllen. |
Integrated Project Management (IPM) |
... ein Projekt nach einem definierten Prozess aufzusetzen und durchzuführen. Dieser Prozess wird aus dem Standardprozess der Organisation hergeleitet, indem dieser projektspezifisch angepasst wird. |
Risk Management (RSKM) |
... Risiken zu identifizieren, Maßnahmen zur Risikobehandlung zu planen und, falls notwendig, durchzuführen. |
Decision Analysis and Resolution (DAR) |
... notwendige Entscheidungen in einem formalen Prozess vorzubereiten. Dabei werden Alternativen nach festgelegten Kriterien bewertet. |
Organizational Process Performance (OPP) |
... auf quantitativer Basis (also aus im Prozess erhobenen Daten) festzustellen, wie gut der eingesetzte Standardprozess ist. |
Quantitative Project Management (QPM) |
... ein Projekt entsprechend dem definierten Prozess auf der Basis von Kennzahlen zu führen. |
Organizational Innovation and Deployment (OID) |
... organisatorische und technische Maßnahmen auszuwählen und in der Organisation durchzuführen, die die Prozesse und die angestrebten Qualitätsziele messbar verbessern. |
Causal Analysis and Resolution (CAR) |
... die Ursachen von Fehlern und anderen Problemen zu identifizieren und zukünftig zu vermeiden. |
Tab. 11–1 Kurzbeschreibung der CMMI-Prozessbereiche
Die Tabelle zeigt: CMMI definiert nichts Neues oder gar Revolutionäres, sondern fasst in den einzelnen Prozessbereichen Aufgaben und Tätigkeiten zusammen, die nach allgemeinen Erfahrungen notwendig sind, um Entwicklungsprojekte erfolgreich durchzuführen.
Mittels CMMI soll die Reife einer Organisation, die Software entwickelt, ermittelt und der Organisation ein Weg gewiesen werden, um die Prozessreife schrittweise zu verbessern. Dazu bietet das CMMI zwei Varianten an, die stufenförmige und die kontinuierliche.
Diese CMMI-Variante definiert eine Skala von fünf aufeinander aufbauenden Reifegraden (Abb. 11–1). Um einen Reifegrad zu erreichen, muss die Organisation alle Anforderungen dieser Stufe und aller darunterliegenden Stufen erfüllen.
Abb. 11–1 Die Reifegrade des CMMI in der stufenförmigen Variante
Alle Reifegrade – bis auf Stufe 1 – werden durch Prozessbereiche beschrieben. Jeder Prozessbereich ist genau einem Reifegrad zugeordnet (Tab. 11–2). Eine Organisation, die nach dem gestuften Reifegradmodell bewertet wird, muss alle Prozessbereiche einer Stufe beherrschen, um diese Stufe zu erreichen. Es handelt sich also um K.-o.-Kriterien: Defizite in irgendeinem Prozessbereich können nicht durch Stärken in anderen Bereichen ausgeglichen werden.
Der Prozess ist nicht bewusst gestaltet, sondern hat sich mehr oder minder zufällig entwickelt. Das ist nicht zwingend schlecht; aber in der Praxis bedeutet es doch meist, dass die Planung unzulänglich und der Projektverlauf chaotisch ist und dass Kostenvorgaben und Termine meist erheblich überschritten werden. Wenn Projekte trotzdem leidlich erfolgreich abgeschlossen werden, so haben einzelne Mitarbeiter weit mehr geleistet, als ihnen zuzumuten ist. Kurz: Der Erfolg hängt an Einzelkämpfern, den »Helden«, und ist darum nicht planbar.
Diese Stufe ist dadurch charakterisiert, dass wichtige Bereiche der Software-Entwicklung organisiert und den Beteiligten vorgegeben sind (z. B. die Verwaltung der Anforderungen, die Qualitätssicherung und insbesondere das Projektmanagement). Obwohl es keinen organisationsweit definierten Software-Prozess gibt, sondern jedes Projekt einem eigenen, speziellen Prozess folgen kann, ist eine minimale Prozessdisziplin gewährleistet. Damit ist sichergestellt, dass der Erfolg in einem früheren Projekt in weiteren, ähnlichen Projekten wiederholt wird, wie es die alte CMM-Bezeichnung der Stufe 2 »repeatable« andeutet.
Auf dieser Stufe wird nicht mehr das einzelne Projekt betrachtet, sondern es geht darum, dass alle Projekte einer Organisation einem einheitlichen Schema folgen. Dazu muss ein organisationsweiter Standardprozess definiert, dokumentiert und angewendet werden. Der Standardprozess lässt einige Freiheiten für die Projekte; darum beginnt jedes Projekt mit der projektabhängigen Anpassung des Standardprozesses.
Die auf Stufe 3 erreichte Standardisierung des Prozesses erlaubt, für alle Projekte einheitliche Metriken einzuführen. Die Beteiligten erhalten auf diese Weise Kennzahlen, die sie in die Lage versetzen, Probleme frühzeitig zu erkennen und Korrekturmaßnahmen zu ergreifen. Damit findet das Prinzip der Regelschleife Anwendung (Abschnitt 8.5.1).
Reifegrad |
Abk. |
Prozessbereiche |
||
1 |
ungeformt |
(initial) |
|
– |
2 |
gesteuert |
(managed) |
REQM |
Requirements Management |
PP |
Project Planning |
|||
PMC |
Project Monitoring and Control |
|||
MA |
Measurement and Analysis |
|||
PPQA |
Process and Product Quality Assurance |
|||
CM |
Configuration Management |
|||
SAM |
Supplier Agreement Management |
|||
3 |
definiert |
(defined) |
RD |
Requirements Development |
TS |
Technical Solution |
|||
PI |
Product Integration |
|||
VER |
Verification |
|||
VAL |
Validation |
|||
OPF |
Organizational Process Focus |
|||
OPD |
Organizational Process Definition |
|||
OT |
Organizational Training |
|||
IPM |
Integrated Project Management |
|||
RSKM |
Risk Management |
|||
DAR |
Decision Analysis and Resolution |
|||
4 |
geregelt |
(quantitatively managed) |
OPP |
Organizational Process Performance |
QPM |
Quantitative Project Management |
|||
5 |
optimierend |
(optimizing) |
OID |
Organizational Innovation and Deployment |
CAR |
Causal Analysis and Resolution |
|||
Tab. 11–2 Prozessbereiche der Reifegrade
In einer sich ändernden Welt können die Prozesse nicht statisch sein, sie bedürfen der Verbesserung und Anpassung. Auf Stufe 5 werden wie auf Stufe 4 die Prozesse routinemäßig in den Projekten angewendet. Auf Basis der erhobenen Prozess- und Produktmetriken werden die Prozesse organisatorisch und technisch laufend den sich ändernden Randbedingungen angepasst. Fehler und Probleme werden systematisch analysiert, damit sie in Zukunft vermieden werden.
Die Einstufung einer Organisation basiert darauf, inwieweit sie die spezifischen und generischen Ziele erfüllt und die damit verbundenen spezifischen und generischen Aufgaben beherrscht, die den Prozessbereichen zugeordnet sind.
Die folgenden drei generischen Ziele (GZ) mit den dazugehörenden generischen Aufgaben (GA) sind für die ersten drei Stufen definiert (Tab. 11–3).
GZ 1 Erfülle die spezifischen Ziele |
||
|
GA 1.1 |
Beherrsche die spezifischen Aufgaben |
GZ 2 Institutionalisiere einen gesteuerten Prozess |
||
|
GA 2.1 |
Erstelle eine organisationsweite Strategie für die Planung und Umsetzung des Prozesses |
|
GA 2.2 |
Plane den Prozess |
|
GA 2.3 |
Stelle Ressourcen bereit |
|
GA 2.4 |
Weise Verantwortlichkeiten zu |
|
GA 2.5 |
Schule die am Prozess beteiligten Personen |
|
GA 2.6 |
Verwalte die Konfigurationen der Arbeitsergebnisse des Prozesses |
|
GA 2.7 |
Ermittle und beteilige die betroffenen Personen |
|
GA 2.8 |
Überwache und steuere den Prozess |
|
GA 2.9 |
Bewerte objektiv die Einhaltung des Prozesses |
|
GA 2.10 |
Prüfe den Status und die Ergebnisse des Prozesses mit dem Management |
GZ 3 Institutionalisiere einen definierten Prozess |
||
|
GA 3.1 |
Beschreibe und pflege einen definierten Prozess |
|
GA 3.2 |
Sammle Verbesserungsinformationen |
|
zusätzlich |
alle Aufgaben des generischen Ziels GZ 2 |
Tab. 11–3 Generische Ziele und Aufgaben der stufenförmigen CMMI-Variante
Als Beispiel für spezifische Ziele und Aufgaben wählen wir den Prozessbereich Requirements Management der Stufe 2. Für diesen Bereich gibt CMMI nur das spezifische Ziel Verwalte die Anforderungen an, das erfüllt ist, wenn die folgenden spezifischen Aufgaben beherrscht sind:
1. Verstehe die Anforderungen
2. Lege die Anforderungen fest
3. Verwalte Änderungen an den Anforderungen
4. Stelle die birektionale Nachverfolgbarkeit der Anforderungen sicher (das sogenannte Tracing)
5. Stelle Inkonsistenzen zwischen der Projektarbeit und den definierten Anforderungen fest
GZ 1 fordert, dass für jeden Reifegrad (größer 1) alle spezifischen Aufgaben der Prozessbereiche beherrscht sein müssen. Erfüllt beispielsweise eine Organisation die generischen Ziele GZ 1 und GZ 2 für alle sieben Prozessbereiche der Stufe 2 (beherrscht also alle spezifischen Aufgaben der einzelnen Prozessbereiche und die GZ-2-Aufgaben im Kontext jedes Prozessbereichs), dann befindet sie sich auf Stufe 2.
Allgemein gilt: Eine Organisation erhält dann den Reifegrad X, wenn für alle Prozessbereiche der Stufe X die generischen Ziele GZ 1 bis GZ X erfüllt sind.
Mit der kontinuierlichen CMMI-Variante können die spezifischen Stärken und Schwächen einer Organisation besser als in der stufenförmigen identifiziert werden, da jeder Prozessbereich einzeln betrachtet und bewertet werden kann. Dazu legt CMMI fünf generische Ziele fest. Diese gelten für alle Prozessbereiche, bauen aufeinander auf und definieren dadurch jeweils einen Fähigkeitsgrad für die Prozessbereiche. In Tabelle 11–4 ist dargestellt, wie die generischen Ziele und die Fähigkeitsgrade zusammenhängen.
Generisches Ziel |
Fähigkeitsgrad |
|
|
– |
0: unvollständig |
GZ 1 |
Erfülle alle spezifischen Ziele des Prozessbereichs |
1: durchgeführt |
GZ 2 |
Institutionalisiere einen gesteuerten Prozess |
2: gesteuert |
GZ 3 |
Institutionalisiere einen definierten Prozess |
3: definiert |
GZ 4 |
Institutionalisiere einen geregelten Prozess |
4: geregelt |
GZ 5 |
Institutionalisiere einen optimierenden Prozess |
5: optimierend |
Tab. 11–4 Ziele und Fähigkeitsgrade der kontinuierlichen CMMI-Variante
Ein Prozessbereich wird mit dem Fähigkeitsgrad x bewertet, wenn das generische Ziel x erfüllt ist. Wird keines der Ziele erfüllt, dann ist der Fähigkeitsgrad in diesem Prozessbereich 0.
Wird eine Organisation nach der kontinuierlichen Variante bewertet, dann kann ein Profil der Fähigkeitsgrade für die betrachteten Prozessbereiche erstellt werden (siehe Abb. 11–2). Dieses zeigt, wie gut die Bereiche beherrscht werden, und bildet die Basis für gezielte Verbesserungen bestimmter Prozessbereiche.
Abb. 11–2 Beispiel für ein Fähigkeitsgradprofil von Prozessbereichen
Eine Organisation kann CMMI für verschiedene Ziele nutzen:
Nach einer offiziellen Begutachtung (Appraisal) bekommt die Organisation ein quasi amtliches Zeugnis ihrer Prozessqualität. Je höher die Einstufung ist, desto besser ist das Zeugnis für die Außendarstellung geeignet. Firmen, die für US-Bundesbehörden, vor allem für das Militär und die NASA, arbeiten wollen, haben ohne eine respektable Einstufung kaum eine Chance, Aufträge zu erhalten. Darum sind diese Firmen auf den oberen Stufen (4 und 5) stark vertreten. Eine zweite Gruppe sind Firmen in Indien (und neu auch in China), die ohne gewachsene Klientel auf dem Weltmarkt nach Aufträgen und Partnern suchen. Da ein Auftraggeber in Amerika oder Europa in der Regel gar nichts über die potenziellen Partner in Asien weiß, ist eine gute Einstufung im CMMI ein starkes Werbeargument.
Eine interne Begutachtung wird durchgeführt, um Hinweise auf Schwachstellen zu erhalten, damit der Prozess verbessert werden kann. Außerdem erhält die Organisation dadurch ein leidlich objektives Bild ihrer Kompetenz im (organisatorischen) Software Engineering. Natürlich ist die interne Begutachtung auch ein sinnvoller und in der Regel notwendiger Schritt auf dem Weg zu einer offiziellen Einstufung.
In den Appraisal Requirements for CMMI (ARC) werden Mindestanforderungen beschrieben, die eine Begutachtungsmethode erfüllen muss (CMMI, 2006b). Die Methoden werden in drei Stufen klassifiziert (siehe auch Tab. 11–5):
Methoden der Stufe A sind die aufwändigsten. Sie müssen so beschaffen sein, dass das Ergebnis einer Begutachtung zuverlässig und nachvollziehbar ist. Nur mit Begutachtungsmethoden dieser Stufe dürfen Reife- oder Fähigkeitsgrade ermittelt werden.
Die Methoden der Stufe B stellen geringere Anforderungen an die Zuverlässigkeit der Ergebnisse; so müssen nicht mehr alle Informationen durch mehrere Quellen belegt sein. Das senkt die Kosten des Gutachtens.
In die Stufe C fallen alle Methoden, deren Ziel es ist, eine Organisation schnell und mit geringem Aufwand zu begutachten. Die Anforderungen an die Zuverlässigkeit werden dazu noch weiter reduziert.
Mittlerweile liegen mit SCAMPI (Standard CMMI Appraisal Method for Process Improvement) standardisierte Begutachtungsmethoden für alle Stufen vor (SCAMPI, 2005; SCAMPI, 2006). Jedoch können insbesondere für die Stufen B und C unternehmensspezifische Begutachtungsmethoden definiert werden; diese müssen aber den entsprechenden ARC-Anforderungen genügen.
Begutachtungsstufe |
Merkmale |
Stufe A |
– zuverlässige und korrekte Ergebnisse |
Stufe B |
– geringere Ansprüche an die Zuverlässigkeit der Ergebnisse |
Stufe C |
– schnelle und häufige Überprüfungen |
Tab. 11–5 Merkmale der CMMI-Begutachtungsstufen
Das Ziel, das mit einer Begutachtung angestrebt wird, bestimmt die Begutachtungsstufe. Geht es darum, einem potenziellen Auftraggeber darzulegen, dass die Organisation einen bestimmten CMMI-Reifegrad erreicht hat, dann muss eine Begutachtung der Stufe A durchgeführt werden. Soll jedoch immer wieder ohne großen Aufwand festgestellt werden, wo die Schwächen der Prozesse liegen, dann kann das mit Begutachtungen der Stufe C geschehen.
Je nach Begutachtungsstufe werden verschiedene Hilfsmittel eingesetzt, um die Informationen zu erheben, die für die Bewertung benötigt werden: Es werden Interviews durchgeführt, Fragebögen ausgewertet und existierende Dokumente gesichtet.
Begutachtungen werden immer von einem Team mit einem Leiter durchgeführt. Damit die Begutachtungen auch in der Art und Weise, wie sie durchgeführt werden, weltweit vergleichbar sind, legt SCAMPI einen Prozess fest, der bei allen Begutachtungen einzuhalten ist (SCAMPI, 2006). Dieser Begutachtungsprozess definiert die folgenden drei Phasen:
1. Planung und Vorbereitung (Plan and Prepare for Appraisal)
Nachdem die Ziele der Begutachtung mit dem Management abgestimmt sind, wird eine erste Planung für die Begutachtung erstellt, die insbesondere auch Angaben über die Begutachtungsmethode und die geschätzten Kosten und Zeiten enthält. Anschließend wird der Leiter bestimmt und das Team, das die Begutachtung durchführen wird, zusammengestellt. Neben Projektleitern und Mitgliedern des Managements kommen erfahrene Entwickler in Frage. Diese Mitarbeiter werden, falls notwendig, durch eine gemeinsame Schulung mit CMMI und der anzuwendenden Begutachtungsmethode vertraut gemacht. Abschließend werden schon vorhandene Dokumente und andere Daten gesammelt, die für die Begutachtung benötigt werden. Diese Informationen werden auf Vollständigkeit geprüft, und es wird festgelegt und geplant, welche weiteren Informationen noch gesammelt und ausgewertet werden müssen.
2. Durchführung (Conduct Appraisal)
Auf Basis dieser Planung und der Prüfung der schon vorhandenen Dokumente werden die noch fehlenden Informationen durch Fragebögen, Interviews oder durch weitere Dokumente erhoben. Die Gutachter werten anschließend alle Informationen aus und versuchen herauszufinden, wie der Software-Prozess in den Projekten umgesetzt wird. Sie bewerten dazu jeden untersuchten Prozessbereich und identifizieren Diskrepanzen zwischen den Zielen und dem aktuellen Zustand des Prozesses. Auf dieser Basis wird eine Liste von detaillierten Befunden erstellt und zusammen mit den Teilnehmern der Begutachtung validiert. Abschließend wird das Ergebnis der Begutachtung festgelegt. Das Resultat kann, je nach Begutachtungsmethode, die Bewertung mit einem Reifegrad und/oder einem Stärken-Schwächen-Profil sein, das die Fähigkeitsgrade der betrachteten Prozessbereiche zeigt.
3. Präsentation der Ergebnisse (Report Results)
Das Ergebnis der Begutachtung wird dokumentiert und den Beteiligten in geeigneter Art und Weise präsentiert. Alle erhobenen Informationen und erstellten Dokumente werden abschließend geordnet und archiviert.
Zu der Frage, wie Unternehmen bewertet werden, gibt es Angaben in einer Publikationsreihe des SEI, in der die Ergebnisse der durchgeführten Begutachtungen, soweit das SEI darüber informiert ist, erfasst und statistisch ausgewertet werden. Diese Publikationsreihe wird als »Process Maturity Profile« (SEI, o.J.) bezeichnet und halbjährlich fortgeschrieben. Abbildung 11–3 ist diesem Dokument (Stand Herbst 2009) entnommen. In der ersten Rubrik »Not Given« werden die Begutachtungen zusammengefasst, bei denen kein Reifegrad vergeben wurde (vermutlich, weil das nicht angestrebt oder weil Stufe 2 offensichtlich unerreichbar war).
Abb. 11–3 Statistik der erzielten CMMI-Reifegrade (nach SEI, o.J., Stand Herbst 2009)
Neben den Jahresangaben sind oben rechts die kumulierten Zahlen der begutachteten Organisationen angegeben. Die fallenden Werte in den Stufen Initial und Managed sowie die steigenden Werte für die Stufe Defined zeigen, dass die durchschnittliche Höhe der Einstufungen, also die Prozessbewertung, in diesen Stufen Jahr für Jahr steigen. Natürlich ist diese Entwicklung auch darauf zurückzuführen, dass durch CMMI explizit definiert ist, was eine Organisation beherrschen muss, um eine gewisse Stufe zu erreichen; darauf können sich die Organisationen vor einer Begutachtung einstellen. Auffällig ist weiterhin ein Trend, der in den hohen Stufen Quantitatively Managed und Optimizing zu beobachten ist und gegenläufig zu den entsprechenden CMM-Statistiken für den Zeitraum 1987-2005 ist. Während dort die Zahl der Einstufungen auch in diesen Stufen stetig zunahm (SEI, o.J., Stand 2005), nimmt die Zahl der Einstufungen nun über die Jahre ab. Das kann daran liegen, dass die Investitionen, die notwendig sind, um dauerhaft diese Stufen zu halten, von den Organisationen nicht mehr geleistet werden (weil sich diese möglicherweise nicht auszahlen).
CMM und CMMI haben sich jedoch als Verfahren etabliert, mit denen man Software-Entwicklungsprozesse bewerten und verbessern kann. Da CMMI noch recht jung ist und erst wenige Erfahrungen dazu vorliegen, beziehen wir uns in diesem Abschnitt auf die Erfahrungen, die mit CMM gewonnen wurden. Vieles davon lässt sich auf CMMI übertragen.
Es gibt viele Studien, die über die Erfahrungen mit der CMM-Prozessbewertung und -verbesserung berichten (z. B. Wohlwend, Rosenbaum, 1994; Welsch, Lichter, Zeller, 1995; Komiyama, Sunazuka, Koyama, 2000). Hier überwiegen natürlich die positiven Erfahrungen, die sich in verbesserter Produktqualität und gesteigerter Produktivität ausdrücken. Es gibt aber auch kritische Stimmen, die die Grundannahmen von CMM und damit auch seine Anwendung in Frage stellen (siehe Bach, 1994; Mellis, Stelzer, 1999). Folgende Kritikpunkte werden genannt:
Die Basis von CMM bildet das Erfahrungswissen einer bestimmten Personengruppe. Ihr Erfahrungshintergrund ist geprägt von Software-Entwicklungsprojekten im Umfeld des US-Verteidigungsministeriums. Diese Erfahrungen sind nicht repräsentativ für die große Masse der Software-Projekte.
CMM berücksichtigt die Veränderungen organisatorischer und technischer Randbedingungen nur ungenügend. Es bietet eine statische Sicht auf die Entwicklungsprozesse und institutionalisiert diese Sicht in der Organisation. In diesem Sinn verhindert CMM Innovationen.
Die Einordnung der Prozessbereiche in die Reifegrade ist willkürlich und diskutabel. So ist ein systematisches Trainingsprogramm auch bereits auf Stufe 2 sinnvoll; Maßnahmen zur Fehlerverhütung sind auf allen Stufen geboten.
Auch die vom SEI publizierten Prozessreife-Profile, die den großen Erfolg von CMMI untermauern sollen, müssen aus unserer Sicht mit zwei wichtigen Warnungen versehen werden:
Die wenigsten Organisationen unterwerfen sich einer Bewertung nach CMMI; wir sehen in den Statistiken also nur eine kleine Minderheit, die nicht repräsentativ für die Gesamtheit ist. Ganz sicher würden die allermeisten Organisationen Stufe 2 in CMMI nicht erreichen.
Dieser Effekt ist nicht in allen Staaten gleich. Die Profile erwecken den Eindruck, dass die Prozessreife außerhalb der USA im Durchschnitt besser ist. Tatsächlich dürfte aber der erhebliche Druck auf viele amerikanische Firmen, eine Prozessbewertung vorzuweisen, dazu führen, dass der Anteil der bewerteten Organisationen größer ist, was zu einem schlechteren Durchschnitt führt.
Die Statistiken beruhen auf freiwilligen Meldungen. Darum muss vermutet werden, dass die Daten nicht nur unvollständig, sondern auch verfälscht sind. Vermutlich ist es in manchen totalitären Staaten lebensgefährlich, schwache Resultate nach Pittsburgh zu melden. Und selbst dort, wo keine Repressionen zu befürchten sind, werden firmeninterne Bewertungen mit unerfreulichem Resultat nur selten den Weg in eine Statistik finden.
Es wäre darum tollkühn, die absoluten Zahlen und die Verteilungen aus den Profilen für bare Münze zu nehmen; zuverlässiger dürften die Trends sein, die man aus dem Vergleich über mehrere Jahre ablesen kann.
Wie in Abschnitt 10.6.1 geschildert wurde, können Prozesse sehr bürokratisch verstanden und durchgesetzt werden. Das gilt natürlich auch für die Prozessbewertung und -verbesserung; aus einer sinnvollen Maßnahme wird dann eine Dressurnummer. Solche Erfahrungen haben zur Satire provoziert. In seinem Capability Im-Maturity Model (CIMM) hat Thomas M. Schorsch (1996) die CMM-Skala nach unten verlängert und die Stufen 0 bis -3 eingeführt. Sie können auf Deutsch mit den Begriffen nachlässig, hemmend, hochmütig und destruktiv bezeichnet werden. Wer die Realität mit offenen Augen wahrnimmt, wird zugeben, dass Schorsch kaum übertrieben hat.
Level 0: Negligent (Indifference)
Failure to allow successful development process to succeed. All problems are perceived to be technical problems. Managerial and quality assurance activities are deemed to be overhead and superfluous to the task of software development process. Reliance on silver pellets.
Level -1: Obstructive (Counter Productive)
Counterproductive processes are imposed. Processes are rigidly defined and adherence to the form is stressed. Ritualistic ceremonies abound. Collective management precludes assigning responsibility. Status quo über alles.
Level -2: Contemptuous (Arrogance)
Disregard for good software engineering institutionalized. Complete schism between software development activities and software process improvement activities. Complete lack of a training program.
Level -3: Undermining (Sabotage)
Total neglect of own charter, conscious discrediting of peer organization’s software process improvement efforts. Rewarding failure and poor performance.
Trotz aller Kritik hat CMM/CMMI ohne Zweifel einen wesentlichen Beitrag dazu geleistet, dass die Art und Weise der Software-Entwicklung, d. h. der im Projekt gelebte Prozess, den angemessenen Stellenwert bekommen hat. Gute, zielorientierte Prozesse sind eine notwendige Voraussetzung, um langfristig erfolgreich Software zu entwickeln. Das lässt sich wie folgt zusammenfassen:
Die Reifegrade 2 und 3 definieren zentrale Voraussetzungen und Kompetenzen für die Software-Entwicklung. Sie sollten von jedem Software-Hersteller beherrscht werden. Allerdings gilt die Stufe 2, auf der der Prozess nur partiell definiert ist, als instabil; wer nicht zügig weiter zur Stufe 3 aufsteigt, wird auch Stufe 2 nicht lange behaupten können.
Durch eine Begutachtung lassen sich wichtige Mängel des Entwicklungsprozesses identifizieren. Diese Diagnose bildet eine gute Ausgangsbasis, um den Prozess gezielt zu verbessern.
Die Durchführung von Verbesserungsmaßnahmen verursacht erheblichen Aufwand. Sie greifen nur, wenn sie von den Entwicklern und vom Management gewünscht sind. Ihr Erfolg wird oft nicht sofort, sondern erst mittelfristig sichtbar. Teilweise ist er auch schwer nachweisbar (messbar).
Als europäische Reaktion auf das amerikanische CMM wurde in den Neunzigerjahren ein EU-Projekt zur Entwicklung eines Bewertungsverfahrens initiiert, das besser an die europäischen Gegebenheiten angepasst ist. Das entstandene Verfahren trägt den Namen Bootstrap (Bicego, Khurana, Kuvaja, 1998). Es wurde vom Bootstrap-Institute – einem Zusammenschluss verschiedener IT-Firmen – in einer Reihe von Versionen weiterentwickelt. Bootstrap wurde erfolgreich eingesetzt, hat aber nie große Verbreitung erreicht. Inzwischen ist es vom Markt verschwunden.
Basierend auf den Erfahrungen mit CMM, Bootstrap und anderen Ansätzen wurde auf internationaler Ebene durch die ISO das Bewertungsverfahren SPICE (Software Process Improvement and Capability dEtermination) entwickelt. SPICE harmonisiert die bestehenden Ansätze und definiert einen Standard für Bewertungsverfahren. SPICE liegt seit 2003 in der fünfteiligen internationalen Norm ISO/IEC 15504 vor. Einen guten Einstieg in diese umfangreiche Norm zur Prozessbewertung geben Hörmann et al. (2006); die folgenden Aussagen stützen sich auf diese Quelle.
Wie CMMI definiert auch SPICE Reifegrade, jedoch sechs, beginnend mit der Eintrittsstufe 0, die der CMMI-Stufe 1 entspricht. Stufe 1 ist erreicht, wenn tatsächlich ein Prozess existiert. Die Reifegrade von SPICE können folgendermaßen charakterisiert werden:
Stufe 0 – Der unvollständige Prozess (incomplete)
Es gibt keinen Prozess, oder der Prozess wird nicht gelebt oder erfüllt seinen Zweck nicht.
Stufe 1 – Der ausgeführte Prozess (performed)
Es existiert ein Prozess, der angewendet wird und die geforderten Ergebnisse liefert.
Stufe 2 – Der gesteuerte Prozess (managed)
Diese Stufe erfordert, dass der Prozess systematisch umgesetzt wird: Er wird geplant, überwacht und angepasst. Die Anforderungen an die Arbeitsergebnisse des Prozesses sind klar beschrieben; es ist definiert, wie die Arbeitsergebnisse zu dokumentieren sind, wie sie zusammenhängen und wie sie gepflegt werden.
Stufe 3 – Der etablierte Prozess (established)
Im gesamten Unternehmen wird ein einheitlicher, definierter und dokumentierter Prozess verwendet, der durch »Tailoring« an die speziellen Eigenschaften der einzelnen Projekte angepasst wird. Durch geeignete Maßnahmen wird sichergestellt, dass dieser Prozess erfolgreich eingesetzt werden kann.
Stufe 4 – Der vorhersagbare Prozess (predictable)
Die Qualität des Prozesses und der erstellten Produkte wird kontinuierlich ermittelt und analysiert. Damit wird festgestellt, ob die Vorgaben erfüllt wurden.
Stufe 5 – Der optimierende Prozess (optimizing)
Da die Qualität des Prozesses und der Produkte laufend ermittelt und analysiert wird, können bei den ersten Anzeichen für eine Verschlechterung (z. B. eine Verzögerung oder steigende Fehlerzahlen) Gegenmaßnahmen ausgewählt und ergriffen werden.
Die Prozesse, die für eine Organisation relevant sind und bewertet werden sollen, werden in Prozessreferenzmodellen festgelegt, die branchenspezifisch sein können. Beispiele für branchenspezifische Prozessreferenzmodelle sind Automotive SPICETM (Höhn et al., 2009) oder »SPICE for SPACE« der Luft- und Raumfahrtindustrie (Cass et al., 2001). SPICE definiert auf Basis der in der Norm ISO/IEC 12207 (Prozesse im Lebenszyklus von Software) beschriebenen Prozesse ein Referenzmodell, das aus drei Prozesskategorien (»Prozessdimensionen«) besteht:
Primary Life Cyle Processes
Diese Kategorie enthält Prozesse aus den Bereichen Akquisition, Engineering (also Analyse, Entwurf, Test etc.), Lieferung und Betrieb.
Organizational Life Cycle Processes
Darin sind alle Prozesse aus den Bereichen Management, Prozessverbesserung, Wiederverwendung, Ressourcen und Infrastruktur zusammengefasst.
Supporting Life Cycle Processes
Hier finden sich Prozesse wie Qualitätssicherung, Konfigurations- und Änderungsverwaltung oder Dokumentation.
Aus einem Prozessreferenzmodell können einzelne Prozesse für eine Begutachtung ausgewählt werden; es entsteht das Prozessbegutachtungsmodell. SPICE bewertet die Prozesse nicht summarisch; jeder Prozess wird einzeln bewertet und eingestuft. Dazu definiert dieses Verfahren für die Reifegrade 1 bis 5 die sogenannten Prozessattribute (Tab. 11–6).
Stufe |
Das Prozessattribut |
bewertet, inwieweit ... |
1 |
Prozessdurchführung |
... der Prozess zweckmäßig ist und die geforderten Ergebnisse erzielt. |
2 |
Management der Prozessdurchführung |
... die Ausführung des Prozesses geplant und überwacht wird. |
Management der Arbeitsergebnisse |
... die Arbeitsergebnisse definiert, dokumentiert und geprüft werden. |
|
3 |
Prozessdefinition |
... der Standardprozess definiert, gepflegt und angepasst wird. |
Prozessanwendung |
... der Standardprozess in den Projekten umgesetzt wird. |
|
4 |
Prozessmessung |
... der Prozess gemessen wird und die dabei gewonnenen Ergebnisse verwendet werden. |
Prozesssteuerung |
... Analyse- und Steuerungstechniken eingesetzt werden, um den Prozess zu korrigieren, damit die Ergebnisse innerhalb definierter Grenzen bleiben. |
|
5 |
Prozessinnovation |
... der Prozess systematisch verbessert und veränderten Geschäftszielen angepasst wird. |
Prozessoptimierung |
... die Auswirkungen von potenziellen Prozessänderungen analysiert und die Umsetzung genehmigter Änderungen gesteuert wird. |
Tab. 11–6 SPICE-Prozessattribute
Im Prozessbegutachtungsmodell werden die Prozessattribute ausgewählt, die bewertet werden sollen (z. B. die der Stufen 1 bis 3). In einer Begutachtung werden diese dann für jeden Prozess betrachtet, und es wird überprüft, ob diese Prozessattribute auch tatsächlich in den realen Prozessen vorhanden sind. Die Bewertung der Prozessattribute geschieht auf einer Ordinalskala mit den vier Werten nicht, teilweise, überwiegend oder vollständig erfüllt. Damit ein Prozess in den Reifegrad R eingestuft werden kann, müssen alle Prozessattribute der darunterliegenden Stufen 1 bis R-1 als vollständig erfüllt, die Attribute der Stufe R mindestens als überwiegend erfüllt bewertet werden.
SPICE bietet verschiedene Begutachtungsarten (z. B. Selbstbegutachtung, externe Zertifizierungsbegutachtung), gibt detaillierte Anweisungen, wie eine Begutachtung durchzuführen ist, und enthält auch ein generisches Modell zur Prozessverbesserung (Abschnitt 11.4).
Da SPICE als Norm eine breite Basis hat und sich viele Industriezweige für SPICE entschieden haben, wird SPICE in Zukunft der maßgebliche Rahmen für Prozessbewertungen und -verbesserungen sein. Weitere Informationen zu diesem Thema findet man auf den Webseiten der SPICE User Group (SPICE, o.J.).
CMMI und SPICE sind keine Prozessmodelle und auch keine Programme zur Prozessverbesserung; die Resultate einer Bewertung mit CMMI oder SPICE weisen aber den Weg, wie die Fähigkeiten einer Organisation und ihre Entwicklungsprozesse verbessert werden können. Prozessverbesserung wird dabei als fortlaufender, niemals abgeschlossener Prozess gesehen.
Damit die für die Umsetzung der Verbesserungsmaßnahmen notwendigen Ressourcen zur Verfügung gestellt werden, muss es in der Organisation eine Stelle mit entsprechenden Kompetenzen geben: die SEPG (Software Engineering Process Group). Der Leiter dieser Gruppe sorgt dafür, dass die Entwicklungsprozesse weiterentwickelt und verbessert werden. Die SEPG sollte nicht in die Linienorganisation eingebunden, sondern als Stabsstelle direkt dem Management unterstellt sein. Die SEPG organisiert die Verbesserungsmaßnahmen in Form eines Projekts.
Auch für Projekte zur Prozessverbesserung wurden Vorgehensweisen entwickelt. SPICE beschreibt im vierten Teil der Norm ein generisches, zyklisches Modell zur Prozessverbesserung; es definiert dafür acht Schritte (Abb. 11–4).
1. Geschäftsziele klären
Damit die für die Verbesserungsmaßnahmen benötigten Mittel sinnvoll eingesetzt werden, müssen die Maßnahmen auf die mittel- und langfristigen Ziele der Organisation abgestimmt sein. Die Ziele der Verbesserungsmaßnahmen sind zu definieren.
2. Verbesserungszyklus initiieren
Die notwendigen organisatorischen Voraussetzungen für die Prozessverbesserung werden geschaffen, die Verantwortlichkeiten für die Prozessverbesserung werden definiert. Falls es noch keine SEPG gibt, wird sie eingerichtet.
3. Aktuelle Prozesse bewerten
Der aktuelle Zustand der Entwicklungsprozesse wird aufgenommen und bewertet. Dies geschieht in der Regel durch eine interne Begutachtung.
4. Verbesserungsmaßnahmen planen
Aus den Ergebnissen der Begutachtung werden Verbesserungsvorschläge abgeleitet, nach Prioritäten geordnet und geplant. Diese Planung muss auf die anderen Aktivitäten der Organisation abgestimmt sein.
5. Verbesserungsmaßnahmen durchführen
Die geplanten Verbesserungsmaßnahmen werden meist zuerst in Pilotprojekten durchgeführt. Es wird geprüft, ob die Maßnahmen den gewünschten Effekt erzielen (z. B. durch Prüfung von Arbeitsergebnissen oder Sammeln und Analysieren entsprechender Daten). Ist dies der Fall, dann werden sie von der gesamten Organisation übernommen. Schulungen, die im Kontext der geplanten Verbesserungsmaßnahmen notwendig sind, werden organisiert und durchgeführt.
6. Verbesserung überprüfen
In diesem Schritt wird festgestellt, ob oder inwieweit die Ziele der Verbesserungsmaßnahmen erreicht wurden. Dies kann durch Messungen und Bewertungen oder durch Begutachtung der verbesserten Prozesse geschehen.
7. Verbesserung stabilisieren
Die Erfahrung zeigt, dass erreichte Verbesserungen leicht wieder verloren gehen (z. B. durch den üblichen Zeitdruck in Entwicklungsprojekten), wenn nicht ständig darauf geachtet wird, dass die eingeführten Verfahren auch (immer) angewendet werden. Dies ist Aufgabe der SEPG, die natürlich die entsprechenden Kompetenzen benötigt.
8. Prozesse überwachen
Die Aktivitäten aus Schritt 7 werden in der Organisation institutionalisiert, d. h., die Prozesse werden systematisch überwacht. Dadurch werden Schwachstellen identifiziert, die durch Verbesserungsmaßnahmen beseitigt werden können.
Am SEI wurde schon 1996 im Kontext von CMM das sogenannte IDEALModell entwickelt (McFeeley, 1996), um Prozesse systematisch und kontinuierlich zu verbessern. Es teilt ein Verbesserungsprojekt in fünf Phasen ein: Initiating, Diagnosing, Establishing, Acting und Learning. Es ist in die SPICE-Norm eingeflossen und kann als eine Ausprägung des SPICE-Modells zur Prozessverbesserung angesehen werden.
Abb. 11–4 Schritte der Prozessverbesserung (gemäß SPICE)
Der Aufwand, der in Verbesserungsmaßnahmen investiert werden muss, ist erheblich. Hörmann et al. (2006) geben an, dass im Mittel 5-10 % des Entwicklungsbudgets notwendig sind, um die Prozesse von einem Reifegrad auf den nächsten anzuheben. Gibson, Goldenson und Kost (2006) haben in einer Studie 35 CMMI-basierte Prozessverbesserungsprogramme, deren Ergebnisse publiziert wurden, ausgewertet. Sie haben ermittelt, dass der Median der erzielten Verbesserungen bei den Kosten 34%, bei der Qualität 48% und bei der Entwicklungsdauer 50% ist. Bei der Interpretation dieser Zahlen ist aber Vorsicht angebracht: Ähnlich wie bei den CMMI-Profilen liegt auch hier eine einseitige Auswahl zu Grunde; die zahlreichen gescheiterten Prozessverbesserungsprogramme sind von dieser Statistik nicht erfasst.
Das SEI verfolgt auch, wie lange Organisationen benötigen, um den nächsten Reifegrad zu erreichen. In SEI (o.J., Stand 2009) sind folgende Medianwerte (Angaben in Monaten) publiziert:
Man erkennt, dass die Stufe 2 recht schnell erreicht werden kann und dass die beiden nächsten Schritte, nach Stufe 3 und nach Stufe 4, etwa gleich viel Zeit benötigen. Der Übergang zur Stufe 5 ist dann in kürzerer Zeit zu schaffen. Dies sind natürlich nur Erfahrungswerte, die im Einzelfall erheblich über-, aber auch unterschritten werden können. Pankaj Jalote hat (im privaten Gespräch) den Verdacht geäußert, dass die in der Regel beteiligten Berater kein großes Interesse daran haben, die Sache wesentlich schneller hinter sich zu bringen (was nach seiner Erfahrung ohne Probleme möglich wäre; vgl. Jalote, 1999).
