Verbesserung von Softwareprozessen mit CMMI · PDF fileWestfälische...

Westfälische Wilhelms-Universität Münster

Ausarbeitung

Verbesserung von Softwareprozessen mit CMMI

im Rahmen des Seminars Software Management

Philip Demey

Themensteller: Prof. Dr. Herbert Kuchen

Betreuer: Dipl. Medienwiss. Susanne Gruttmann

Institut für Wirtschaftsinformatik

Praktische Informatik in der Wirtschaft

II

Inhaltsverzeichnis

1 Verbesserung der Qualität von Softwareprozessen ................................................... 3

2 Qualitätsmodelle zur Prozessverbesserung ................................................................ 5

2.1 Qualitätsmanagementprozesse ........................................................................... 5

2.2 Reifegradmodelle ............................................................................................... 6

2.3 Entstehung des CMMI ....................................................................................... 8

3 Aufbau des CMMI ................................................................................................... 10

3.1 Elemente ........................................................................................................... 10

3.2 Anwendungsgebiete und Erweiterungen.......................................................... 11

3.3 Darstellungsvarianten ....................................................................................... 12

3.4 Prozessgebiete .................................................................................................. 15

4 Einführung von CMMI mit dem IDEAL Modell .................................................... 20

4.1 Initiating Phase ................................................................................................. 21

4.2 Diagnosing Phase ............................................................................................. 21

4.3 Establishing Phase ............................................................................................ 21

4.4 Acting Phase..................................................................................................... 22

4.5 Learning Phase ................................................................................................. 23

5 Bewertung des CMMI Einsatzes ............................................................................. 24

A Prozessgebiete .......................................................................................................... 26

Literaturverzeichnis ........................................................................................................ 28

Kapitel 1: Verbesserung der Qualität von Softwareprozessen

3

1 Verbesserung der Qualität von Softwareprozessen

„Die einzige Konstante in der Welt ist die Veränderung.“

Heraklit (griechischer Philosoph)

Die Qualität von Softwareprodukten ist sowohl für den Erfolg des Produkts selber, als

auch für die einsetzende Organisation entscheidend. Was macht aber die Qualität von

Produkten aus? Es ist mittlerweile unumstritten, dass die Produktqualität im direkten

Zusammenhang mit der Qualität der Erstellungsprozesse dieser Produkte steht. Eine

hohe Prozessqualität kann also auch die Entstehung einer hohen Produktqualität för-

dern. Diese Verbindung lässt erkennen, dass die Verbesserung der Entwicklungsprozes-

se der wesentliche Ansatzpunkt für eine höhere Softwareproduktqualität ist.

Die Gründe für eine Verbesserung der Entwicklungsprozesse sind vielfältig: Durch die

Vermeidung von Fehlern in den erstellten Produkten kommt es zu einer Erhöhung der

Kundenzufriedenheit und damit verbunden zur einer besseren Kundenbindung. Folglich

kann dies natürlich auch in einer möglichen Umsatzsteigerung münden. Durch die

Vermeidung und Erkennung von Fehlern im Entwicklungsprozess kommt es weiterhin

zu einer Vermeidung von Kosten und einer Verkürzung der Entwicklungszeit. Dadurch

kann die Organisation schneller und flexibler am Markt reagieren und zusätzlich für

eine bessere Termintreue sorgen. Schließlich können Vorgaben seitens der Auftragge-

ber oder des Gesetzgebers durch eine Verbesserung der Prozesse und Einhaltung be-

stimmter Standards abgedeckt werden.

Vorhaben zur Verbesserung der Prozessqualität sind organisatorische Veränderungen,

die in der Organisation massive Auswirkungen auf die Planung und Durchführung der

Projekte haben können. Um diese Veränderungen in einem geordneten Rahmen durch-

zuführen und auf bisherige Erfahrungen zugreifen zu können, werden oft Reifegradmo-

delle eingesetzt. Reifegradmodelle können ähnlich wie Entwurfsmuster wichtige Erfah-

rungen und „Best Practices“ bei der Erstellung von Softwaresystemen zusammenfassen,

dokumentieren und strukturieren. So können die Prozesse neuer Softwareprojekte von

den Erfahrungen anderer Projekte profitieren. Reifegradmodelle bieten aber zugleich

auch geregelte Maßstäbe zum Vergleich von Projekten und Organisation untereinander.

Durch ein festes Rahmenwerk und definierte Vorgehensweisen helfen sie den aktuellen

Stand der Prozesse zu ermitteln und schaffen damit zugleich die Basis für eine weitere

Verbesserung.

Kapitel 1: Verbesserung der Qualität von Softwareprozessen

4

Das Capability Maturity Model Integration (CMMI) ist ein Reifegradmodell das am

Software Engineering Institute (SEI) in Pittsburgh / USA entwickelt wurde. Es bietet

verschiedene Varianten zur Verbesserung von Prozessen an, die in Verbindung mit der

Entwicklung oder dem Erwerb von Software, Hardware und Systemen aus beiden ste-

hen. Diese Arbeit geht speziell auf das CMMI-DEV in Version 1.2 ein, das sich mit der

Entwicklung der genannten Komponenten beschäftigt. Die aktuelle Version ist in

[SEI06] zu finden und dient zusammen mit [Ch07] und [Kn07] als Grundlage dieser

Arbeit. Im weiteren Verlauf dieser wird CMMI als Synonym für die CMMI-DEV Va-

riante des Reifegradmodells verwendet.

Ziel dieser Arbeit ist es das CMMI-DEV näher vorzustellen. Dafür sollen in Kapitel 2

zunächst einige Grundlagen und die Geschichte des CMMI erläutert werden. In Kapitel

3 wird dann detailliert auf den Aufbau und die Elemente des CMMI eingegangen. An-

schließend werden Aspekte für die Einführung von CMMI in Organisationen und ein

exemplarisches Einführungsmodell erklärt. In Kapitel 5 wird abschließend eine kurze

Zusammenfassung und Bewertung des CMMI-Ansatzes gegeben.

Kapitel 2: Qualitätsmodelle zur Prozessverbesserung

5

2 Qualitätsmodelle zur Prozessverbesserung

In diesem Kapitel soll zunächst ein kurzer Überblick über die Grundlagen von Quali-

tätsmanagement gegeben und einige Definitionen wichtiger Begriffe durchgeführt wer-

den. Anschließend werden verfügbare Qualitätsmodelle zur Prozessverbesserung vor-

gestellt und dann auf das CMMI als Mittel zur Software-Prozessverbesserung näher

eingegangen.

2.1 Qualitätsmanagementprozesse

Die Motivation für Prozessverbesserung geht auf Erkenntnisse zurück, dass zwischen

der Qualität der Produkte und der Qualität der Prozesse einer Organisation ein fester

Zusammenhang besteht [Sc08 S. 6]. Diese Erkenntnis kann eine Organisation dazu ver-

anlassen Maßnahmen des Qualitätsmanagement einzusetzen.

Qualitätsmanagement (QM) bezeichnet (nach DIN EN ISO 8402 Abschnitt 3.2) alle

Tätigkeiten die Qualitätspolitik, Ziele und Verantwortungen festlegen sowie diese ver-

wirklichen. Das Qualitätsmanagement kann sich dazu verschiedener Qualitätsmanage-

mentprozesse bedienen:

Vorgehensmodelle legen eine spezifische Vorgehensweise fest. Beispiele für

Vorgehensmodell sind z. B. der Rational Unified Process (RUP) oder das

V-Modell XT.

Reifegradmodelle bewerten die Prozessreife und bieten Werkzeuge zur schritt-

weisen Verbesserung. Beispiele für Reifegradmodelle sind das hier vorgestellte

CMMI oder ISO 15504 (SPICE).

Qualitätsmanagementmodelle behandeln die Softwareentwicklung nur sehr

oberflächlich da ihre Anwendungsgebiete weit gefächert sind. Im Allgemeinen

beschreiben Qualitätsmanagementmodelle die Strukturierung der QM-

Aktivitäten und einen organisatorischen Rahmen. Ein bekannter Vertreter ist

z. B. ISO 9001.

IT-Managementmodelle, z. B. ITIL.

Auch eine Kombination der Modelle ist möglich. So lässt sich z. B. das CMMI in Kom-

bination mit dem V-Modell XT umsetzen. Das Vorgehensmodell stellt dabei den Rah-


6

men für die Prozessverbesserungsmaßnahmen bereit. Für die Bewertung der Entwick-

lungsprozesse dient das CMMI [Wa07 S. 23].

Da diese Arbeit den Fokus auf das Reifegradmodell CMMI legt, sollen im Folgenden

die Begriffe Projekt, Prozess und Prozessgebiet im Kontext des CMMI definiert wer-

den.

Im Sinne des CMMI hält ein Projekt eine Menge an Ressourcen, die zur Erstellung ei-

nes oder mehrere Produkte dienen. Ein Projekt besitzt einen definierten Anfang sowie

einen Projektplan. Der Projektplan spezifiziert was geliefert werden muss und die dafür

zugeordneten Ressourcen. Weiterhin beschreibt er die verwendeten Hilfsmittel, Aufga-

ben und einen Zeitplan. Eine weitere Unterteilung des Projektes in Teilprojekte ist mög-

lich. Dadurch kann eine bessere Strukturierung erreicht werden.

Das CMMI definiert einen Prozess als Aktivitäten, die Praktiken aus dem CMMI-

Modell umsetzen. Aktivitäten eines Prozesses können auch einer oder mehreren Prakti-

ken der Prozessgebiete zugeordnet werden. Diese spezielle Definition macht eine Be-

wertung und Verbesserung der Prozesse auf Basis des CMMI-Modells möglich.

Mehrere zusammengehörige Praktiken werden in einem Prozessgebiet gruppiert. Wer-

den alle diese Praktiken umgesetzt, so erfüllen sie eine Menge von Zielen dieses Pro-

zessgebietes. Das Erfüllen der Ziele eines Gebietes ist im CMMI die Grundlage für eine

Verbesserung in diesem Bereich.

2.2 Reifegradmodelle

Ein Reifegradmodell ist nach [Sc08 S. 13] ein Modell zur Bewertung und Verbesserung

von Prozessen. Es beinhaltet bestimmte Praktiken gegen die reale Prozesse verglichen

werden. Anhand der Ergebnisse können sowohl Reifegradstufen als auch Stärken und

Schwächen der Prozesse ermittelt werden.

Nach [Ho08] sind Reifegradmodelle ein Teil der Managementprozesse die sich mit ver-

schiedenen Vorgehensweisen und Arbeitsabläufen befassen und dadurch eine geregelte

Durchführung eines Software-Projekts gewährleisten. Reifegradmodelle dienen dazu,

die Arbeitsabläufe einer Organisation oder eines Projektes zu analysieren und zu opti-

mieren. Die Prozesse werden dazu nach einer bestimmten Systematik auf Projekt- oder

Organisationsebene bewertet. Die gewonnenen Erkenntnisse sollen anschließend zur

weiteren Verbesserung der Prozesse dienen.


7

Die Reife von Organisationen kann in verschiedenen Stufen bewertet werden. Reife-

gradmodelle bieten dafür die konkreten Anleitungen und Vorgehensweisen. Dadurch ist

sowohl ein Vergleich von Organisationen oder Projekten untereinander möglich als

auch die Voraussetzung für Verbesserungen der Prozesse.

Die Reifegrade sind mit einer Menge von Anforderungen verbunden, die zur Erreichung

des Reifegrades erfüllt sein müssen. Dazu werden in Reifegradmodellen oft konkrete

Maßnahmen beschrieben die der Organisation bei der Erfüllung der Anforderungen hel-

fen sollen. Diese Maßnahmen stellen allerdings nur den Rahmen für eine konkrete Pro-

zessbeschreibung vor und lassen sich daher für die konkrete Durchführung an die Ge-

gebenheiten einer Organisation anpassen.

Assessments (im CMMI Kontext auch Appraisals genannt) dienen Reifegradmodellen

dazu den Reifegrad einer Organisation oder eines Projektes festzustellen. Die Anforde-

rungen sollen dazu einer möglichst objektiven Bewertung unterzogen werden. Dafür

werden die Strukturen und Arbeitsabläufe mit den Anforderungen abgeglichen und die

erreichte Stufe festgelegt. Durch Assessments sollen zum einen die Reifegrade messbar

und damit vergleichbar gemacht werden. Zum anderen werden Hinweise und Vorschlä-

ge für spätere Verbesserungen erarbeitet. Bewertungen werden in Fremd- oder Selbstas-

sessments und internen bzw. externen Assessments unterschieden. Fremdassessments

werden oft bei der Auswahl von Subunternehmern oder Zuliefereren benutzt. Interne

Assessments kann eine Organisation durchführen, wenn sie z. B. Kosten sparen möchte,

die durch den Einsatz eines externen, neutralen Assessors entstehen würden. Die vom

SEI vorgesehene Methode für CMMI-Appraisals ist SCAMPI (Standard CMMI Apprai-

sal Method for Process Improvement). Diese Methode existiert in drei Klassen, die sich

durch die Intensität und Umfang unterscheiden. SCAMPI-Appraisals lassen sich auch

für die Bewertung der Umsetzungen nach ISO 15504 einsetzen.

Ein weiterer Vertreter von Reifegradmodellen ist ISO 15504 oder auch SPICE genannt

(Software Process Improvement and Capability Determination). Ähnlich wie CMMI

legt ISO 15504 ebenfalls Fähigkeitsstufen von 0 bis 5 fest. Prozesse werden hier durch

ihre Prozessattribute bewertet. Das Bewertungssystem ist ein Rating der Prozessattribu-

te auf einer Skala von 0 - 100%. Die Einstufung eines Prozesses geschieht über eine

Durchschnittsberechnung aller Prozessattribute. Das CMMI ist konsistent und kompati-

bel mit ISO 15504.


8

2.3 Entstehung des CMMI

Als das US-Verteidigungsministerium 1986 bei der Vergabe von komplexen Software-

projekten große Probleme mit seinen Auftragnehmern hatte, beauftragte es das SEI mit

der Entwicklung eines Lösungsansatzes um bei der zukünftigen Vergabe von Projekten

sicher sein zu können, dass der Auftragnehmer wie versprochen liefert. Aus dieser Mo-

tivation heraus entstand 1991 das Capability Maturity Model (CMM). Das SEI begann

damit relevante Arbeitsprozesse und Vorgehensweisen zusammenzutragen, die für die

Qualität von Softwareprojekten kritisch sind. Die gefundenen Vorgehensweisen und

Best Practices wurden in 5 Stufen bzw. Reifegraden gegliedert [SEIa].

Zunächst wurde das CMM nur von verpflichteten Auftragnehmern des US-

Verteidigungsministeriums verwendet. Nach und nach begannen aber verschiedene Un-

ternehmen das CMM auf freiwilliger Basis einzusetzen um ihre eigenen Prozesse zu

verbessern. 1993 wurde die Version 1.1 des CMM herausgegeben, in die weitere Ver-

besserungen eingeflossen sind. Mittlerweile wurde das CMM nicht nur für Software

angewendet sondern auch in verschiedenen Abwandlungen z. B. für die Systementwick-

lung eingesetzt. Die Verabschiedung der Version 2.0 wurde 1998 vom Verteidigungs-

ministerium zurückgezogen da die verschiedenen CMM Varianten mittlerweile unterei-

nander inkompatibel waren und nur schwierig gemeinsam einsetzbar waren.

Bereits 1997 wurde das SEI mit der Entwicklung eines integrierten Reifegradmodells

beauftragt. In die Entwicklung des neuen Capability Maturity Model Integrated sollten

drei verwandte Abwandlungen des CMM integriert werden [SEI08]:

Das ursprüngliche CMM für Softwareentwicklung (SW-CMM Version 2.0),

Das CMM für Systementwicklung (EIA/IS 731),

Das CMM für die integrierte Produktentwicklung (IPD-CMM Version 0.98).

Weiterhin sollten Verbesserungen und neue Erkenntnisse aus den vorherigen Jahren in

das neue Modell eingearbeitet werden. Zusätzliche wurde eine Kompatibilität zu ISO

15504 und eine leichte Erweiterbarkeit des Modells angestrebt. Letztlich sollte der Um-

stieg von vorherigen Modellen auf das neue CMMI möglichst wenig Aufwand bereiten.

Die Pilotversion 1.0 wurde im Herbst 2000 herausgegeben. Kurze Zeit später wurde

zusätzlich die Erweiterung „Integrierte Produkt- und Prozessentwicklung“ (+IPPD) für

Software- und Systementwicklung beschrieben. In 2002 kam die überarbeitete Version


9

1.1 heraus, die die vorherigen drei Modelle ablöste. Bis Ende 2005 wurde die Unterstüt-

zung des alten SW-CMM eingestellt. In der folgenden Zeit wurden weitere Modelle in

das CMMI integriert. Da dadurch Überschneidungen zwischen den einzelnen Teilberei-

chen entstanden wurde das CMMI 2006 grundlegend überarbeitet und bietet in der Ver-

sion 1.2 ein integriertes Gesamtmodell. Weiterhin wurden in der Version weitere Ver-

besserungen und Vereinfachungen umgesetzt. Für die unterschiedlichen Anwendungs-

gebiete bietet das CMMI nun sog. Konstellationen in denen nun bisherige Varianten zur

System- und Softwareentwicklung, Teile von IPPD und Lieferantenauswahl in das

CMMI-DEV zusammengefasst wurden. Weitere angekündigte Konstellationen sind das

CMMI-ACQ für die Akquisition und ein CMMI-SVC für Dienstleistungen.

Kapitel 3: Aufbau des CMMI

10

3 Aufbau des CMMI

Im vorangegangenen Kapitel wurden verschiedene Modelle zur Verbesserung von

Softwareprozessen insbesondere das CMMI vorgestellt. Nun sollen in diesem Kapitel

die Elemente und der Aufbau des CMMI näher erläutert werden. Dafür werden zunächst

die Elemente des CMMI als Überblick vorgestellt. Anschließend sollen verschiedene

mögliche Anwendungsgebiete vorgestellt werden. Danach wird auf die beiden mögli-

chen Darstellungsvarianten eingegangen. Abschließend werden die Prozessgebiete des

CMMI den Darstellungsvarianten zugeordnet und jeweils vorgestellt.

3.1 Elemente

Das CMMI besteht aus verschiedenen Strukturelementen die den Aufbau bestimmen.

Prozessgebiete sind dabei wichtige Elemente die mehrere Anforderungen zu einem

Thema zusammenfassen, z. B. Konfigurationsmanagement oder Anforderungsmanage-

ment. Ein Prozessgebiet kann jeweils mehrere Prozesse umfassen. Ein Prozess kann

umgekehrt aber ebenfalls zu unterschiedlichen Prozessgebieten gehören. Prozessgebiete

werden in der stufenförmigen Darstellung zu Reifegraden und in der kontinuierlichen

Darstellung zu Kategorien zusammengefasst. Die beiden unterschiedlichen Darstel-

lungsvarianten werden in Unterkapitel 3.3 näher erläutert.

Jedem Prozessgebiet sind eine Reihe von Zielen zugeordnet die sich in spezifischen und

generischen Zielen unterscheiden. Spezifische Ziele gehören dabei fest zu einem jewei-

ligen Prozessgebiet. Generische Ziele beschreiben die Tätigkeiten, die umzusetzen sind

damit die spezifischen Ziele dauerhaft und effizient umgesetzt werden. Generische Ziele

werden Prozessgebiet-übergreifend formuliert. Sie sind an die jeweiligen Reifegrade

angelehnt und beschreiben unterschiedliche Intensitäten mit der die Prozessgebiete in-

stitutionalisiert werden.

Ein weiteres Strukturelement sind Praktiken die den Zielen zugeordnet werden. Jedem

Ziel ist mindestens eine Praktik zugeteilt. Analog zu Zielen werden Praktiken in spezifi-

sche und generische Praktiken unterschieden die dazu dienen spezifische und generi-

sche Ziele umzusetzen.

Der Zusammenhang zwischen den Strukturelementen des CMMI sind für die stufen-

förmige und die kontinuierliche Darstellung in Abbildung 1 schematisch aufgezeigt.


11

Reifegrad

Generische

PraktikSpezifische

Praktik

Generisches

ZielSpezifisches

Ziel

Prozessgebiet

0,n

1

1

1,n

1, n

1

1

1

1,n1,n

Kategorie

Generische

PraktikSpezifische

Praktik

Generisches

ZielSpezifisches

Ziel

Prozessgebiet

1,n

1

1

1,n

1, n

1,n

1

1

1,n1,n

Stufenförmige Darstellung Kontinuierliche Darstellung

Abbildung 1: Zusammenhang der Strukturelemente in verschiedenen Darstellungsvarianten

3.2 Anwendungsgebiete und Erweiterungen

Seit der Version 1.2 des CMMI sind die ehemals vier getrennten Varianten für System-

entwicklung, Software, integrierte Produkt- und Prozessentwicklung sowie Lieferanten-

auswahl in das Anwendungsgebiet Entwicklung (CMMI-DEV) zusammengefasst.

Für Akquisition wurde 2007 das CMMI-ACQ verabschiedet und beschreibt [SEI07a]

Anleitungen und Regeln für die Akquisition von Produkten und Dienstleistungen. Das

Modell soll dabei helfen Barrieren im Akquisitionsprozess abzubauen bzw. zu verhin-

dern. Es sollen sowohl für den Ankäufer als auch für den Lieferanten gemeinsame

Richtlinien etabliert werden, die die Akquisition mit geringeren Kosten- und Zeitauf-

wand verbinden. Das CMMI-ACQ baut auf 16, mit dem CMMI-DEV gemeinsamen

Prozessgebieten, sowie einigen individuellen Gebieten auf.

Das CMMI für Dienstleistungen (CMMI-SVC) wurde in 2007 nicht als eigenständiges

Modell verabschiedet, sondern in die CMMI Product Suite integriert [SEI07b]. In der


12

Product Suite sind verschiedene Produkte des SEI zusammengefasst die sich mit dem

Thema CMMI befassen.

Zusätzlich zu den beschriebenen Anwendungsgebieten gibt es zwei Erweiterungen für

das CMMI-DEV:

+IPPD (Integrated Product and Process Development),

+SAFE (Safety Management und Safety Engineering) für die Entwicklung von

sicherheitskritischen Produkten.

Die +IPPD Ergänzung besteht aus je einem zusätzlichen spezifischen Ziel in den Pro-

zessgebieten „Organisationsweise Prozessdefinition“ (OPD) und „Integrierte Projekt-

management“ (IPM). Die +SAFE Erweiterung fügt zwei neue Prozessgebiete zu CMMI

hinzu: Sicherheits-Management und Sicherheits-Engineering.

3.3 Darstellungsvarianten

Das CMMI bietet zwei verschiedene Varianten der Darstellung. Zum einen die stufen-

förmige Darstellung und zum Anderen die kontinuierliche Darstellung.

Stufenförmige Darstellung

In der stufenförmigen Darstellung gibt es fünf Reifegrade:

Reifegrad 1: Initial,

Reifegrad 2: Gemanagt,

Reifegrad 3: Definiert,

Reifegrad 4: Quantitativ gemanagt,

Reifegrad 5: Optimierend.

Jedem Reifegrad, außer Reifegrad 1, sind konkrete Prozessgebiete mit konkreten An-

forderungen zugewiesen. Die Reifegrade in der stufenförmigen Darstellung sind kumu-

lativ definiert. Um Reifegrad n+1 zu erreichen muss also sowohl der Reifegrad n er-

reicht werden als auch zusätzliche Anforderungen erfüllt werden.

Im Reifegrad 1 sind Prozesse ad hoc bzw. chaotisch organisiert und wenig bis gar nicht

definiert. Der Erfolg hängt hier von einzelnen Mitarbeitern ab. Wenn diese Mitarbeiter

ausfallen kann das gesamte Projekt zusammenbrechen. Der Reifegrad 2 zeichnet sich

dadurch aus, dass wesentliche Projektmanagementprozesse betrieben werden. Darunter

fallen die Erfassung von Kosten, Aufstellen eines Zeitplans und Festlegung der Funk-


13

tionalität eines Projektes. Der Fokus verlagert sich in Reifegrad 3 von einzelnen Projek-

ten auf die gesamte Organisation. Es existieren einheitliche Prozesse für die gesamte

Organisation. Zusätzlich zu Managementaktivitäten werden auch Entwicklungsaktivitä-

ten durchgeführt. Dadurch können Mitarbeiter, Daten und Erfahrungen zwischen ver-

schiedenen Projekten ausgetauscht werden. Diese profitieren so von der organisations-

weiten Standardisierung. Im Reifegrad 4 können Ergebnisse von Arbeitsabläufen und

Prozessen durch intensive Nutzung von Kennzahlen und Messungen besser kontrolliert

und vorhergesagt werden. Es kann z. B. der Aufwand eines Projektes oder eine Fehler-

quote gemessen werden. Messungen sind erst in diesem Reifegrad effektiv zu verwer-

ten, da durch den unternehmensweiten Einsatz der Messungen (aus Reifegrad 3) diese

auch verglichen werden können. Zusätzlich werden unternehmensweit einheitliche

Messmethoden angewendet. Schließlich liegt der Fokus in Reifegrad 5 auf kontinuierli-

chen Verbesserungen. Es wird eine systematische Analyse von auftretenden Fehlern,

sowie die systematische Einführung von Verbesserungen vorgenommen.

In der stufenförmigen Darstellung gibt es zwei generische Ziele die der Institutionalisie-

rung der Prozesse dienen:

Generisches Ziel 1: Einen gemanagten Prozess institutionalisieren,

Generisches Ziel 2: Einen definierten Prozess institutionalisieren.

Das Ziel einen gemanagten Prozess zu institutionalisieren ist den Prozessgebieten des

Reifegrads 2 zugeordnet. Das Ziel einen definierten Prozess zu institutionalisieren aller-

dings allen Prozessgebieten des Reifegrads 3 und höher, aber auch einigen Prozessge-

bieten des Reifegrads 2.

Kontinuierliche Darstellung

Im Gegensatz zur stufenförmigen Darstellung gibt es in der kontinuierlichen Darstel-

lung fünf generische Ziele die verschiedene Stufen der Institutionalisierung ausdrücken.

Zusätzlich gibt es noch eine Stufe 0, die für den Fall gilt, dass keines der generischen

Ziele erfüllt ist. Die generischen Ziele in dieser Darstellung sind:

Generisches Ziel 1: Spezifische Ziele erreichen,

Generisches Ziel 2: Einen gemanagten Prozess institutionalisieren,

Generisches Ziel 3: Einen definierten Prozess institutionalisieren,

Generisches Ziel 4: Einen quantitativ gemanagten Prozess institutionalisieren,

Generisches Ziel 5: Einen optimierenden Prozess institutionalisieren.


14

Jedes generische Ziel ist einem Fähigkeitsgrad zugeordnet:

Fähigkeitsgrad 0: Unvollständig,

Fähigkeitsgrad 1: Durchgeführt,

Fähigkeitsgrad 2: Gemanagt,

Fähigkeitsgrad 3: Definiert,

Fähigkeitsgrad 4: Quantitativ gemanagt,

Fähigkeitsgrad 5: Optimierend.

Der Fähigkeitsgrad 0 trifft zu, wenn keines der Ziele erfüllt ist. Fähigkeitsgrad 1 in die-

ser Darstellung zu erreichen ist bereits eine echte Leistung. Im Gegensatz zum Reife-

grad 1 in der stufenförmigen Darstellung, mit dem keine Anforderungen verbunden.

Dieser Reifegrad stellt dort die unterste Stufe der Reifegrade dar.

Ebenso wie in der stufenförmigen Darstellung sind die Fähigkeitsgrade hier kumulativ

definiert.

Der hauptsächliche Unterschied zur stufenförmigen Darstellung besteht darin, dass je-

des Prozessgebiet einzeln einem Fähigkeitsgrade zugeordnet wird. So ist eine wesent-

lich feinere Unterscheidung möglich. Eine Organisation kann sich so auf bestimmte

Prozessgebiete festlegen und ihren Fähigkeitsgrad in diesem Prozessgebieten verbes-

sern.

In der kontinuierlichen Darstellung sind die Prozessgebiete in vier Kategorien eingeteilt,

die aber für die Umsetzung des Modells keine Bedeutung haben und nur zur Strukturie-

rung dienen:

Prozessmanagement,

Projektmanagement,

Ingenieurdisziplinen,

Unterstützung.

Auswahl der Variante

Zur Auswahl der passenden Darstellungsvariante gibt es jeweils einige Empfehlungen,

z. B. in [SEI06 Kapitel 1] oder [Ch07 S. 22ff]. Generell gibt es keine falsche Repräsen-

tation sondern nur eine für die eigenen Zwecken besser passende Variante. Wurde in

einer Organisation vor der CMMI Einführung bereits ein Reifegradmodell benutzt, so


15

rät [Ch07] dazu, die dort genutzte Repräsentation beizubehalten um den Übergang zu

erleichtern.

Die kontinuierliche Darstellung bietet mehr Flexibilität wenn CMMI zur Prozessverbes-

serung genutzt wird. Die Organisation kann sich bei dieser Darstellung auf bestimmte

Problemgebiete konzentrieren oder bestimmte Bereiche priorisieren. Weiterhin können

verschiedene Bereiche mit unterschiedlicher Intensität behandelt werden. Dazu sollte

allerdings eventuelle Abhängigkeiten zwischen den Prozessgebieten beachtet werden.

Letztlich macht es die kontinuierliche Darstellung einfacher von oder zur ISO 15504 zu

migrieren.

Für die stufenförmige Darstellung spricht der besser erkennbarere Pfad für Verbesse-

rungen. Der Weg stellt sich klarer dar, da sich eine Organisation an den einzelnen Stu-

fen orientieren kann und eventuelle Abhängigkeiten in diesen bereits berücksichtigt

sind. Wichtige Themen lassen sich hier nicht zurückstellen sondern sind durch die Stu-

fenstruktur vorgegeben. Somit ist dafür gesorgt, dass weitere Verbesserungen auf einer

adäquaten Basis aufsetzen können. Bei der stufenförmigen Darstellung besteht aller-

dings die Gefahr, dass die Organisation nur das Ziel verfolgt, eine bestimmte Stufe zu

erreichen anstatt eine wirkliche Prozessverbesserung anzustreben.

Um sich nicht auf eine Repräsentation festlegen zu müssen kann eine Organisation auch

beide Repräsentationen miteinander kombinieren. In den meisten Fällen hält sich eine

Organisation in der Praxis sowieso nicht exakt an die Vorgaben [Ch07 S. 25].

3.4 Prozessgebiete

In diesem Unterkapitel sollen die Prozessgebiete und Ihre Besonderheiten jeweils kurz

Erläutert werden. Tabelle 1 und Tabelle 2 aus Anhang A geben zunächst einen Über-

blick über die Zuordnung der Prozessgebiete zu den Reifegraden in der stufenförmigen

Darstellung, sowie zu den Kategorien in der kontinuierlichen Darstellung.

Anforderungsmanagement (REQM)

Alle Anforderungen an ein Projekt sollen erfasst, gesteuert kontrolliert und bewertet

werden. Dabei müssen nicht nur die Kundenanforderungen berücksichtigt werden, son-

dern auch die der Organisationsleitung, der Entwicklungsabteilung oder ggf. die des

Gesetzgebers. Im Anforderungsmanagement geht es darum Anforderungen entgegenzu-

nehmen und zu bearbeiten oder Entscheidungen über bestehende Anforderungen zu


16

fällen. Nicht identifizierte Anforderungen zu ermitteln gehört nicht zu dem Gebiet des

Anforderungsmanagement sondern zur Anforderungsentwicklung.

Projektplanung (PP)

Das Ziel der Projektplanung ist es Planungen zur Errichtung und Pflege von Projektak-

tivitäten durchzuführen. Sie basiert auf den bereits erfassten Anforderungen und legt die

Umsetzung dieser fest. Das Prozessgebiet der Projektplanung umfasst weiterhin die

Entwicklung und Pflege des Projektplans sowie die Aufstellung von Schätzungen bzgl.

Aufwand und Kosten. Dies kann z. B. auf Basis historischer Daten anderer Projekte

geschehen.

Projektverfolgung und -steuerung (PMC)

Die Projektverfolgung und -steuerung wird zur Überwachung des Projektfortschritts

eingesetzt, so dass Korrekturen und Anpassungen vorgenommen werden können, wenn

das Projekt vom festgelegten Plan signifikant abweicht.

Management von Lieferantenvereinbarungen (SAM)

Im Management von Lieferantenvereinbarungen wird die Beschaffung von Produkten

und Produktkomponenten, wie z. B. Software, Hardware oder Kombinationen daraus,

verwaltet. Es soll sichergestellt werden, dass die Arbeit und Ergebnisse der Lieferanten

den Anforderungen entsprechen. Aufgaben von SAM sind u. a. die Auswahl von Liefe-

ranten, die Entwicklung und Pflege von Lieferantenvereinbarungen, das Nachverfolgen

bestimmter Lieferantenprozesse und die Bewertung der Lieferanten.

Qualitätssicherung von Prozessen und Produkten (PPQA)

Dem Management und den Mitarbeitern einen objektiven Einblick in Prozesse und den

dazugehörigen Arbeitsergebnissen zu geben ist das Ziel von PPQA. Es soll geprüft wer-

den, ob Vorgaben für Prozesse und Arbeitsergebnisse eingehalten werden und ggf. nicht

eingehaltene Vorgaben identifiziert werden. Diese Vorgaben sind meist formale Krite-

rien wie die Einhaltung von definierten Prozessen oder Programmierstandards.

Messung und Analyse (MA)

Der Zweck der Messung und Analyse ist es dem Management Informationen zur Ent-

scheidungsunterstützung zu geben. Dafür sollen die Zielsetzungen der Messungen spe-

zifiziert werden und so sichergestellt werden, dass der benötigte Informationsbedarf


17

gedeckt wird. MA soll weiterhin Details der verwendeten Metriken und Analysetechni-

ken spezifizieren.

Konfigurationsmanagement (CM)

Aufgabe des Konfigurationsmanagement ist es die Integrität von Arbeitsergebnissen

sicherzustellen. Dies umfasst Dokumentationen, Pläne und auch verschiedene Codetei-

le. Durch die Einführung eines Bibliothekssystems können diese Elemente dort abgelegt

und verwaltet werden. Baselines bezeichnen dabei eine stabile Basis der Arbeitsergeb-

nisse auf die weitere Versionen aufbauen können.

Anforderungsentwicklung (RD)

Anforderungsentwicklung ist die Fortführung des Anforderungsmanagement, das mit

bekannten Anforderungen arbeitet. Im Prozessgebiet RD stehen Methoden und Prakti-

ken zur Identifizierung, Vervollständigung und Konsolidierung von Anforderungen im

Vordergrund. Die erarbeiteten Anforderungen gehen später in ein Dokument wie z. B.

dem Lastenheft ein.

Technische Umsetzung (TS)

In der technischen Umsetzung wird das vorher spezifizierte System (basierend auf den

Ergebnissen der Anforderungsentwicklung) entworfen, entwickelt und implementiert.

Verschiedene Lösungsalternativen sollen miteinander verglichen werden. Es soll eine

bewusste Entscheidung auf Basis von festgelegten Kriterien getroffen werden, ob z. B.

die benötigten Produktkomponenten gekauft oder selbst erstellt werden („make or

buy“).

Produktintegration (PI)

Basierend auf der technischen Umsetzung werden in der Produktintegration einzelne

Produktkomponenten zu einem funktionierenden Gesamtprodukt zusammengesetzt. Die

Integration kann z. B. iterativ erfolgen, indem das Produkt von der untersten Ebene auf-

steigend zusammengesetzt wird. Für jede Ebene soll dabei die Integration vorbereitet

und nach erfolgtem Zusammensetzen das Ergebnis bewertet werden.

Verifikation (VER)

Durch die Verifikation wird geprüft, ob die geleisteten Arbeitsergebnisse den Spezifika-

tionen entsprechen. Aufgabe der Verifikation ist sowohl die Vorbereitung dieser Prü-


18

fung als auch die Durchführung und die Identifikation von Korrekturmaßnahmen. Tests

und Reviews sind dabei wichtige Methoden zur Durchführung der Verifikation.

Validation (VAL)

Während bei der Verifikation die Arbeitsergebnisse gegen die Spezifikationen geprüft

werden, wird bei der Validierung sichergestellt, dass die Ergebnisse den Zweck erfül-

len, den der Kunde angefordert hat.

Organisationsweiter Prozessfokus (OPF)

Das Prozessgebiet OPF hat zum Ziel alle Prozesse der Organisation zu verbessern. Da-

für müssen die Stärken und Schwächen der Prozesse bekannt sein. Informationen für die

Verbesserung können aus verschiedenen Quellen stammen: Messdaten, Rückmeldungen

der Prozessbenutzer oder Ergebnisse aus Reviews oder Appraisals.

Organisationsweite Prozessdefinition (OPD)

Die Definition und Pflege aller Prozesse ist die Aufgabe von OPD. Alle Projekte sollen

diese Prozesse nutzen und an den eigenen Bedarf anpassen können.

Organisationsweites Training (OT)

Durch ein organisationsweites Training sollen die Fähigkeiten und das Wissen der

internen und externen Mitarbeiter so entwickelt werden, dass sie ihre Rollen effektiv

und effizient ausüben können.

Integriertes Projektmanagement (IPM)

Das IPM bindet die Aktivitäten der Prozessgebiete PP, PMC und SAM in die gesamte

Organisation ein. Weiterhin sollen alle Stakeholder (alle Personen die Interesse am Ar-

beitsergebnis oder Einfluss auf dieses haben, z. B. Kunden, Lieferanten oder eigene

Mitarbeiter) in das Projekt einbezogen werden. Wichtige Aktivitäten des IPM sind die

Anpassung der organisationsweiten Prozesse an die einzelnen Projekte, die Integration

der verschiedenen Projektpläne in einen gemeinsamen Projektplan und die Verbesse-

rung und der Ausbau der organisationsweiten Prozesse. Die Verbesserung und der Aus-

bau der Prozesse sollen dadurch erreicht werden, dass Arbeitsergebnisse und Messwerte

aus einzelnen Projekten der gesamten Organisation zur Verfügung gestellt werden.

Risikomanagement (RSKM)

Im Risikomanagement sollen potentielle Probleme identifiziert werden bevor sie eintre-

ten. So soll der Projekterfolg weiterhin sichergestellt werden. Nach Bedarf sollen Kor-


19

rekturaktivitäten geplant und umgesetzt werden. Wichtige Parameter für diese Maß-

nahmen sind die Höhe des Risikos und die Kosten der Korrekturmaßnahme. Die Höhe

des Risikos kann durch den Erwartungswert des Risikos abgebildet werden (Höhe des

potentiellen Schadens x Wahrscheinlichkeit des Eintretens).

Entscheidungsanalyse und -findung (DAR)

Durch einen formalisierten Entscheidungsprozess sollen erforderliche Entscheidungen

herbeigeführt werden. Zu diesem Zweck werden identifizierte Alternativen gegen defi-

nierte Kriterien abgewertet.

Performanz der organisationsweiten Prozesse (OPP)

Aufgabe des Prozessgebietes OPP ist es die Leistung eines Prozesses quantitativ zu

messen und die Werte als Grundlage für Vorhersagen und darauf basierender Entschei-

dungen bereitzustellen.

Quantitatives Projektmanagement (QPM)

Im quantitativen Projektmanagement sollen die Zahlen aus dem Prozessgebiet „Perfor-

manz der organisationsweiten Prozesse“ zur Steuerung der Projekte genutzt werden.

Die Auswahl und Anpassung der in einem Projekt benutzten Prozesse sollen auf Basis

historischer Daten erfolgen.

Organisationsweite Innovation und Verbreitung (OID)

Die Einführung von Verbesserungen und Änderungen wurde zwar in den vorangegan-

genen Prozessgebieten thematisiert, in der organisationsweiten Innovation und Verbrei-

tung soll diese aber systematisch und quantitativ gemanagt werden. Quellen für Pro-

zessverbesserungen sind Verbesserungsvorschläge aus der eigenen Organisation, neue

Technologien und festgestellte Fehler. Änderungen sollen zunächst in Pilotprojekten

getestet werden und bei Erfolg auf die gesamte Organisation ausgerollt werden.

Ursachenanalyse und Problemlösung (CAR)

In der Ursachenanalyse und Problemlösung sollen nicht nur die Symptome von Fehlern

ermittelt werden, sondern auch die ihre Ausgangsursachen ermittelt und behoben wer-

den. Dabei muss entschieden werden, welche Fehler behandelt werden und welche

nicht. CAR basiert dabei auf der Erfassung von Kennzahlen und Messungen anderer

Prozessgebiete.

Kapitel 4: Einführung von CMMI mit dem IDEAL Modell

20

4 Einführung von CMMI mit dem IDEAL Modell

In diesem Kapitel sollen Praktiken für die Umsetzung und Einführung von CMMI vor-

gestellt werden. Exemplarisch für eine Einführungsstrategie soll dabei auf das IDEAL

Modell des SEI eingegangen werden. Eine weitere Vorgehensweise wird z. B. mit dem

Phasenmodell aus [Sc08, Kapitel 2.1] vorgestellt. 1996 wurde das IDEAL Modell vom

SEI vorgestellt [SEI97]. Es soll als Handbuch zur Software-Prozessverbesserung die-

nen; IDEAL steht dabei für die fünf wesentlichen Phasen, die auch in Abbildung 2 zu

sehen sind:

Initiating,

Diagnosing,

Establishing,

Acting,

Learning.

Natürlich ist das IDEAL-Modell eine standardisierte Handlungsanleitung. Jede Organi-

sation handelt aber in einem anderen Kontext und setzt Methoden anders um. Daher

kann dieses Modell modifiziert und an die Gegebenheiten in einer Organisation ange-

passt werden.

Abbildung 2: Das IDEAL Modell


21

4.1 Initiating Phase

Die Initiative zur Verbesserung der Prozesse geschieht durch einen Stimulus bzw. einen

gegebenen Anlass. Dabei darf nicht der Reifegrad selber als Ziel stehen, sondern die

Verbesserungen, die mit einem höheren Reifegrad einhergehen, müssen das Ziel sein.

Die Ziele der Verbesserung sollten sich aus den Geschäftszielen ergeben. Diese Ziele

können z. B. Verbesserung der Termintreue oder Kostenreduktion sein. Der Reifegrad

darf hier nur das Mittel zum Zweck sein.

In der Initiating Phase sollten andere aktive Verbesserungsinitiativen eingebunden wer-

den. Dadurch soll doppelte Arbeit vermieden werden. Weiterhin müssen Budget und

Personal für die Verbesserungsaktionen zur Verfügung gestellt und eingeplant werden.

4.2 Diagnosing Phase

Bezüglich CMMI soll in der Diagnosing Phase eine Standortanalyse für die Organisati-

on durchgeführt werden um festzustellen, ob die Organisation grundsätzlich in der Lage

ist, die gesetzten Ziele zu erreichen. Weiterhin sollen Veränderungen identifiziert wer-

den, die für die Erreichung der Ziele nötig sind.

Die Standortbestimmung wird mittels eines SCAMPI-Appraisals durchgeführt, das ei-

nen Überblick für den aktuellen Zustand der Organisation gibt. Neben den festgestellten

Stärken und Schwächen sollen hier auch Informationen über die Prozesse gesammelt

werden, die dann der gesamten Organisation zur Verfügung zu stellen sind.

Auf Basis der neuen Erkenntnisse werden anschließend Verbesserungsvorschläge erar-

beitet und vorgeschlagen die in der folgenden Phase geplant und priorisiert werden

müssen.

4.3 Establishing Phase

Die Establishing Phase ist in drei Aktivitäten unterteilt: Priorisierung, Strategieentwick-

lung und Planung.

Die entwickelten Verbesserungsvorschläge aus der Diagnosing Phase können norma-

lerweise nicht alle gleichzeitig umgesetzt werden. Daher muss eine geeignete Reihen-

folge erstellt werden. Es kann z. B. zwischen Sofortmaßnahmen und strategischen Zie-

len unterschieden werden. Allerdings muss eine weitere Priorisierung der Vorschläge


22

erfolgen. Dies kann unter Berücksichtigung der Unternehmensziele und der Ergebnisse

aus der Standortanalyse erfolgen.

Anschließend an die Priorisierung muss eine Strategie entwickelt werden, wie die Ver-

besserungsvorschläge am besten umgesetzt werden können. Wichtige Aspekte bei die-

ser Aktivität sind z. B. Ressourcenverfügbarkeit oder die Struktur der Organisation. Die

Strategie muss die Ergebnisse der Standortbestimmung natürlich aufgreifen und sie dar-

auf abstimmen.

Die entwickelte Strategie bildet die Grundlage für eine detaillierte Planung der Prozess-

verbesserung. Ergebnis dieser Planung sind Zeitpläne, Aufgaben, Verantwortlichkeiten,

Ressourcen und die Lenkung von Anforderungen und Dokumenten. Zusätzlich werden

Risiken identifiziert und mögliche Gegenmaßnahmen geplant. Auf Basis dieser Ergeb-

nisse werden Arbeitsgruppen gebildet, die in der Acting Phase die Maßnahmen umset-

zen.

4.4 Acting Phase

Die Hauptarbeit dieser Phase besteht darin, dass Teams Lösungen zu den einzelnen

Vorschlägen aus der Establishing Phase erarbeiten. Oftmals geschieht dies in mehreren

Iterationen. Dabei kann die Planung laufend angepasst und verbessert werden. Die Ac-

ting Phase umfasst vier Hauptaktivitäten:

Erarbeitung der Lösung,

Pilotierung und Validierung der Lösung,

Überarbeitung der Lösung,

Rollout der Prozesse in der Organisation.

Das Ziel der Acting Phase ist eine optimal an die Bedürfnisse der Organisation ange-

passte Lösung. Komplexe und umfangreiche Lösungen müssen nicht um jeden Preis

gefunden werden. Es gilt die KISS-Regel: „Keep it simple and smart“.

Die gefundene Lösung wird nun probeweise angewendet und validiert. Das Feedback

aus dieser Pilotierung wird genutzt um die Lösung anschließend zu überarbeiten und

anzupassen. Wurden umfangreiche Änderungen umgesetzt, muss erneut die Pilotierung

durchgeführt werden um neue Ergebnisse zu erhalten.

Abschließend wird die Lösung in der Organisation eingeführt. Dafür gibt es verschiede-

ne Vorgehensweisen die von der Größe der Organisation abhängt. Weitere Einflussfak-


23

toren sind die zur Verfügung stehenden Ressourcen. Schulungen und Beratung für die

verschiedenen Projekte der Organisation gehören zu dieser letzten Hauptaktivität.

4.5 Learning Phase

Nachdem die Lösungen in der vorangegangenen Phase erarbeitet und umgesetzt wur-

den, sollen in der Learning Phase die durchgeführten Aktivitäten analysiert und daraus

weitere Verbesserungsvorschläge für zukünftige Aktivitäten abgeleitet werden.

Die Learning Phase bildet somit die Projektabschlussphase und hat folgende Ziele:

Erfahrungen sollen für zukünftige Projekte nutzbar gemacht werden,

Transparenz der Ergebnisse des Projektes soll geschaffen werden,

Zielsetzung und Planung für einen weiteren Verbesserungszyklus durchführen,

wenn nötig.

Sollte das Projekt in einen erneuten Verbesserungszyklus einlaufen, so wird die Initia-

ting Phase nicht nochmals durchlaufen, sondern startet mit der zweiten Phase. Dies ist

auch in Abbildung 2 zu erkennen.

Kapitel 5: Bewertung des CMMI Einsatzes

24

5 Bewertung des CMMI Einsatzes

Das CMMI bringt nicht nur Vorteile durch die Verbesserung der Prozesse mit sich. Zur

Konzeption bzw. Vollständigkeit des CMMI gibt es in der Literatur einige Kritikpunkte.

[Kn07] führt auf, dass der Schritt von Reifegrad 1 auf Reifegrad 2 zu groß sei. Durch

die kontinuierliche Darstellung und die damit verbundene Einführung des Fähigkeitgra-

des 0 könne dieser Nachteil allerdings ausgeglichen werden. Weiterhin ist noch ungek-

lärt ob es sich auszahlt ist, ab Reifegrad 3 intensive Messungen und Analysen zu nut-

zen.

Das CMMI deckt Prozesse der Software- und Systementwicklung ab. Andere Prozesse

einer Organisation bleiben dabei teilweise unberücksichtigt. Daher kann es geschehen,

dass diese Prozesse vernachlässigt werden, wodurch eine Verbesserung der Organisati-

on behindert wird. Zu diesen Prozessen gehören u. a. Marketing, Vertrieb oder auch der

Kundendienst und Support. Um auch diese Bereiche abzudecken könnte die Organisati-

on auch andere Modelle des Qualitätsmanagement einsetzen, z. B. Standard der Reihe

ISO 900x [Th02] oder ITIL für Produktion und Betrieb der Software [Vi05].

Ein weiterer Einwand gegen die Nutzung von CMMI ist die Prozessorientierung des

Modells. Organisationen in innovativen und schnelllebigen Umfeldern können an Fle-

xibilität und Innovationskraft verlieren, wenn sie sich zu stark an ein prozessorientiertes

Qualitätsmodell orientieren [Kn07]. Abhilfe schafft evtl. die Anwendung von agilen

Methoden in einigen Bereichen, auch wenn der flexible Ansatz von agilen Methoden oft

im Gegensatz zum Ansatz des CMMI steht. Der Vorteil von agilen Methoden liegt hier

in der Fokussierung auf den Entwicklungsprozess, während das CMMI sich auf das

Management der Softwareentwicklung fokussiert. Weitere Literatur zu diesem Thema

ist z. B. in [Pa01] zu finden.

Für kleine Organisationen kann es oftmals schwierig sein CMMI zu nutzen. Die Kosten

durch die Einführung von CMMI würden bei diesen Organisationen oft die Einsparun-

gen übersteigen. Das Berücksichtigen der Grundkonzepte von CMMI kann aber auch

Vorteile in kleinen Projekten bringen.

Das SEI hat in [SEIb] Untersuchungen zu Performanzsteigerungen durch den Einsatz

von CMMI veröffentlicht. Diese Zahlen sind allerdings kritisch zu beurteilen da das SEI

natürlich an positiven Ergebnissen durch den CMMI Einsatz interessiert ist. Weiterhin

ist die Anzahl der Datenpunkte recht gering. Die Untersuchung besagt, dass durch den

Kapitel 5: Bewertung des CMMI Einsatzes

25

Einsatz von CMMI ein Return on Investment (ROI) von ca. 5:1 erreicht werden konnte.

Die Kundenzufriedenheit wuchs durchschnittlich um 14% wobei die Produktivität sogar

um 62% zunahm.

Der BITKOM Verband führte 2004 eine Befragung u. a. zum Bekanntheitsgrad des

CMMI durch in die Ergebnisse von 39 Unternehmen eingingen [Bi04]. Danach war

CMMI bei knapp über 60% der befragten Unternehmen bekannt und ca. 20% planten es

zukünftig einzusetzen. Nur knapp unter 20% setzten CMMI bereits ein, wohingegen

z. B. über 60% den ISO 9001 Standard einsetzten. Interessant ist, dass ca. 30% angaben,

dass ihre Kunden die Einhaltung von CMMI forderten. Daraus wird zwar zum einen die

Motivation deutlich CMMI auf Forderung von Kunden einzusetzen, zum anderen lag

die Zahl für ISO 9001 bei über 60%. Der Einsatz und Bekanntheitsgrad von CMMI lag

also im Jahr 2004 noch weit hinter anderen Standards wie ISO 9001 zurück. Aktuell

wäre aber zu Vermuten, dass die Akzeptanz von CMMI gestiegen ist. Dies lässt sich

unter anderem daraus ableiten, dass in der Befragung über 70% der Teilnehmer CMMI

eine steigende Bedeutung zumaßen.

Die Kombination von CMMI mit Vorgehensmodellen wie das V-Modell XT und die

Kompatibilität mit ISO 15504 oder ITIL machen CMMI zu einem interessanten Ansatz

die Prozesse in einer Organisation zu verbessern und damit eine steigende Produktquali-

tät zu erreichen

Das CMMI sollte aber immer als Werkzeug zur Prozessverbesserung genutzt werden

und nicht als Mittel eine bestimmte Stufe zu erreichen. Nicht eine bestimmte Reifegrad-

stufe ist für eine erfolgreiche Prozessverbesserung maßgebend, sondern der Wille selbst

die Prozesse zu verbessern. CMMI kann dafür ein geeignetes Rahmenwerk sein. Eine

Organisation kann so von bewährten Praktiken und strukturierten Erfahrungen profitie-

ren.

Anhang A: Titel von Anhang 1

26

A Prozessgebiete

Reifegrad 2

(Gemanagt)

Anforderungsmanagement (REQM)

Projektplanung (PP)





Konfigurationsmanagement (CM)

Reifegrad 3

(Definiert)




Verifikation (VER)

Validation (VAL)

Organisationsweiter Prozessfokus (OPF)






Reifegrad 4

(Quantitativ gemanagt)



Reifegrad 5

(Optimierend)



Tabelle 1: Prozessgebiete nach Reifegrad in der stufenförmigen Darstellung

Anhang A: Titel von Anhang 1

27

Prozessmanagement Organisationsweiter Prozessfokus (OPF)





Projektmanagement

Projektplanung (PP)






Ingenieursdisziplinen Anforderungsmanagement (REQM)




Verifikation (VER)

Validation (VAL)

Unterstützung Konfigurationsmanagement (CM)





Tabelle 2: Prozessgebiete nach Kategorie in der kontinuierlichen Darstellung

Literaturverzeichnis

[Bi04] BITKOM: Ergebnisse einer BITKOM Befragung zu System Life Cycle Mo-

dellen, http://www.bitkom.org/de/themen_gremien/55109_28200.aspx, abge-

rufen am 30.11.2008.

[Ch07] Mary G. Chrissis, Mike Konrad, Sandy Shrum: CMMI Second Edition –

Guidelines for Process Integration and Product Improvement, Addison-

Wesley, 2007.

[Ho08] Dirk W. Hoffmann: Software-Qualität. Springer, 2008.

[Kn07] Ralf Kneuper: CMMI. Verbesserung von Software- und Systementwicklungs-

prozessen mit Capability Maturity Model Integration (CMMI-DEV), dpunkt,

2007.

[Pa01] Mark C. Paulk: Extreme Programming from a CMM Perspective, 2001,

http://www.sei.cmu.edu/publications/articles/paulk/xp-from-a-cmm-

perspective.html, abgerufen am 09.12.2008.

[Sc08] Jürgen Schmied et al: Mit CMMI Prozesse Verbessern. Umsetzungsstrategien

am Beispiel Requirements Engineering, dpunkt, 2008.

[SEI06] CMMI Product Team: CMMI for Development, Version 1.2, Software Engi-

neering Institute, 2006,

http://www.sei.cmu.edu/publications/documents/06.reports/06tr008.html, ab-

gerufen am 01.11.2008.

[SEI07a] CMMI Product Team: CMMI for Acquisition, Version 1.2, Software Enginee-

ring Institute, 2007,

http://www.sei.cmu.edu/publications/documents/07.reports/07tr017.html, ab-


[SEI07b] CMMI Product Team: CMMI for Services, Software Engineering Institute,

2007, http://www.sei.cmu.edu/cmmi/models/CMMI-Services-status.html, ab-


[SEI97] Jennifer Gremba, Chuck Myers: The IDEAL Model: A Practical Guid for

Improvement, Software Engineering Institute, 1997,

http://www.sei.cmu.edu/ideal/ideal.bridge.html, abgerufen am 06.12.2008.

[SEIa] Software Engineering Institute: History,

http://www.sei.cmu.edu/cmmi/faq/his-faq.html, abgerufen am 11.11.2008.

[SEIb] Software Engineering Institute: CMMI Performance Results,

http://www.sei.cmu.edu/cmmi/results.html, abgerufen am 09.12.2008.

[Th02] Georg Erwin Thaller: Software- und Systementwicklung. Aufbau eines prak-

tikablen QM-Systems nach ISO 9001:2000, Heinz Heise, 2002.

[Vi05] Frank Victor, Holger Günther: Optimiertes IT-Management mit ITIL, Teub-

ner, 2005.

[Wa07] Ernest Wallmüller: SPI. Software Process improvement mit CMMI, PSP/TSP

und ISO 15504, Hanser, 2007.

Verbesserung von Softwareprozessen mit CMMI · PDF fileWestfälische...

Documents

Transcript of Verbesserung von Softwareprozessen mit CMMI · PDF fileWestfälische...