O'Reilly logo

CMMI: Verbesserung von Software- und Systementwicklungsprozessen mit Capability Maturity Model Integration (CMMI-DEV) by Ralf Kneuper

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

39
4 Die Prozessgebiete des CMMI
Dieses Kapitel gibt einen Überblick über die Prozessgebiete des
CMMI, sortiert nach den Stufen der stufenförmigen Darstellung. Es
enthält für jedes Prozessgebiet eine Erläuterung der wichtigsten Ideen,
die hinter diesem Prozessgebiet stecken, und Hinweise zur praktischen
Umsetzung der manchmal recht abstrakt-theoretisch formulierten
Anforderungen. Die Beschreibung der Prozessgebiete sollte jeweils im
Zusammenhang mit den Anforderungen des Prozessgebietes gelesen
werden, wie sie in Anhang A enthalten sind. Diese Anforderungen
werden nur in Ausnahmefällen in der Beschreibung wiederholt.
Spezifische und
generische Ziele und
Praktiken (SG, SP, GG, GP)
Um den Bezug herzustellen, wird stellenweise auf die in Anhang A
wiedergegebenen spezifischen Ziele (SG n) und Praktiken (SP g.p)
sowie die in Anhang B wiedergegebenen generischen Ziele (GG g) und
Praktiken (GP g.p) verwiesen.
Ergänzt wird die Beschreibung der Prozessgebiete durch eine
Erläuterung der generischen Ziele und Praktiken in Kapitel 4.5.
»Erstellen und Pflegen«
Bei der Lektüre von Anhang A stößt man häufig auf Begriffe wie
»Erstellen und Pflegen« (»Establish and Maintain«), wie z.B. in der
generischen Praktik GP 2.2 (Prozess planen): »Den Plan für die Umset-
zung des Prozesses erstellen und pflegen.« In diesem Begriff ist aus-
drücklich (siehe Glossar des CMMI-DEV v1.2) die Dokumentation
und Nutzung eingeschlossen, d.h., im genannten Beispiel genügt es
nicht, den Plan zu erstellen, sondern er muss auch nachvollziehbar
dokumentiert sein, und dieser Plan muss genutzt und umgesetzt sowie
bei Bedarf aktualisiert werden.
4.1 Prozessgebiete auf Stufe 2 (gemanagt)
Die Prozessgebiete (Process Areas, PA) der Stufe 2 befassen sich haupt-
sächlich mit dem Projektmanagement und enthalten daher in erster
Linie Anforderungen, die von einzelnen Projekten zu erfüllen sind.
4 Die Prozessgebiete des CMMI
40
Dabei gibt es starke Interaktionen zwischen den einzelnen PAs, insbe-
sondere zwischen den ersten drei.
4.1.1 Anforderungsmanagement
»Anforderungsmanagement« (Requirements Management, REQM)
sorgt dafür, dass alle Anforderungen, die an das Projekt gestellt wer-
den, gemanagt, also erfasst, analysiert, bewertet, entschieden und ent-
sprechend der Entscheidung umgesetzt werden. Dazu gehören in erster
Linie die direkten Anforderungen des Kunden (»die Liste soll alphabe-
tisch geordnet sein«), aber auch Anforderungen aus Sicht der Betriebs-
führung (»wenn die Netzverbindung zu mehr als n% ausgelastet ist,
soll eine Warnmeldung gegeben werden« oder »als Datenbank ist das
Produkt X in der Version n.m einzusetzen«), vom Gesetzgeber (z.B.
Datenschutz, Grundsätze ordnungsmäßiger Buchführung), von der
eigenen Entwicklungsorganisation (»es ist ein wöchentlicher Statusbe-
richt nach vorgegebener Vorlage zu erstellen«) oder evtl. von anderen.
Zusätzlich zu diesen Anforderungen gibt es noch Rahmenbedingun-
gen, die genauso berücksichtigt werden müssen, z.B. maximal zur Ver-
fügung stehendes Budget und Ressourcen.
Anforderungs-
management und
Anforderungsentwicklung
Im Gegensatz zum Prozessgebiet »Anforderungsentwicklung«
(siehe Kap. 4.2.1) von Reifegrad 3 geht es beim Anforderungsmanage-
ment darum, explizit gestellte Anforderungen entgegenzunehmen und
zu bearbeiten. Die tatsächlichen, aber nicht formulierten Anforderun-
gen zu identifizieren, ist Aufgabe der Anforderungsentwicklung. Die
oben erwähnte Analyse der Anforderungen bezieht sich darauf, die
erfassten Anforderungen auf Konsistenz, Auswirkungen, Umsetzbar-
keit etc. zu analysieren, aber nicht darauf, fehlende Anforderungen zu
ergänzen.
Entscheidung über
Anforderungen
Typische Ergebnisse der Entscheidung über eine Anforderung sind:
Die Anforderung wird im laufenden Projekt umgesetzt.
Die Anforderung wird später (in einem Folgeprojekt oder einer
Folgeversion) umgesetzt.
Die Anforderung wird nicht umgesetzt.
Die Anforderung wird zurückgestellt.
Wird beschlossen, die Anforderung umzusetzen, so muss dabei festge-
legt werden, wer die Kosten für die Umsetzung trägt (typischerweise
der Kunde oder die Entwicklungsorganisation).
Nach der Bewertung der Anforderung werden alle Beteiligten
informiert und die Anforderung wird ggf. umgesetzt. Aufgabe des

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required