O'Reilly logo

Mit CMMI Prozesse verbessern!: Umsetzungsstrategien am Beispiel Requirements Engineering by Uwe Hehn, Michael Gerdom, Paul-Roux Wentzel, Jürgen Schmied

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

3 Standortbestimmung76
3.2 Durchführung
Für die Interviews wird ein eigener Raum benötigt. Sofern vorhanden,
sollte jeder Interviewte seinen Laptop inklusive Netzzugang mitbrin-
gen. Falls dies nicht möglich ist, so muss zumindest ein Rechner mit
Zugang zum Projektverzeichnis und zum Intranet vorhanden sein.
Während der Interviews werden Projektdokumente auf Nachfrage des
Assessors vom Interviewten vorgestellt, bei Bedarf auch die Standard-
prozesse der Organisation, die typischerweise im Intranet stehen.
3.2.1 Interviews durchführen
Es gibt verschiedene Fragetechniken, um die Anforderungen des
CMMI während der Standortbestimmung mit dem Vorgehen im Pro-
jekt zu vergleichen. Am Anfang eines neuen Interviews (siehe
Abschnitt 6.2.5) hat es sich bewährt, zunächst mit einem positiven
Einstieg zu beginnen. Dies bedeutet konkret, den Interviewten zu
begrüßen und auch noch einmal zu hinterfragen, ob ihm die Ziele und
die Vorgehensweise der Standortbestimmung klar sind.
Danach sollte das Thema kurz umschrieben werden, um das es in
diesem Interview gehen wird. Nach der kurzen Beschreibung und auch
Abgrenzung des oder der zu betrachtenden Prozessgebiete werden
typischerweise offene Fragen benutzt. Sie sollen den Interviewten dazu
animieren, seine Arbeitsweisen in Bezug auf das Interviewthema selber
zu erläutern.
Hier wird vom Appraiser großen Wert auf die »Beweise für
Arbeitsweisen« gelegt. Die größte Bedeutung haben dabei die tatsäch-
lich existierenden Projektdokumente. Dabei wird zwischen direkten
und indirekten Dokumenten unterschieden. Ein direktes Dokument ist
typischerweise ein konkretes Arbeitsergebnis eines Prozesses (z.B. das
Pflichtenheft als direktes Dokument zum Requirements Development).
Ein indirektes Dokument ist ein Dokument, das zwar eine Aussage zu
der gerade offenen Fragestellung zulässt, aber i.d.R. kein konkretes
Arbeitsergebnis des Prozesses darstellt (z.B. eine formlose E-Mail vom
Kunden an den Projektleiter, in der eine zusätzliche Anforderung
gestellt wird). Auch Prozessdokumente (z.B. Dokumentenvorlagen
und Checklisten) gelten als weitere Beweise für die Arbeitsweisen des
Interviewten. Existieren weder Projekt- noch Prozessdokumente, so
werden nur die mündlichen Interviewaussagen in das Protokoll aufge-
nommen.
Während des Interviews werden neben den offenen Fragen schritt-
weise auch immer mehr geschlossene Fragen gestellt, um offene Punkte
aus Sicht des CMMI zu hinterfragen. Der Appraiser muss aber unbe-
773.2 Durchführung
dingt CMMI-Sprachjargon vermeiden. Es gehört zu den Fähigkeiten
eines Assessors, CMMI-Sprechweisen in die Sprachwelt eines Entwick-
lungsingenieurs und umgekehrt die Aussagen des Interviewten auch
wieder zurück in die Sprachwelt des CMMI zu übersetzen.
3.2.2 Feedback-Sitzung durchführen
Bereits während der eigentlichen Interviewphase werden Konsolidie-
rungen zu den Interviewergebnissen durchgeführt. Werden die Inter-
views von mehreren Appraisern geleitet, müssen die Ergebnisse mitein-
ander abgeglichen werden. Aber auch wenn nur ein einzelner Appraiser
zur Verfügung steht, haben sich Pausen zwischen den Einzelinterviews
für eine Konsolidierung bewährt – in diesem Falle mehr im Sinne eines
kurzen Reviews über das Gehörte und Gesehene.
Die Konsoldierung dient der Verifikation der Ergebnisse. Die Vali-
dierung der Ergebnisse erfolgt üblicherweise durch eine Feedback-Sit-
zung, d.h., der Appraiser präsentiert dem Projektteam abschließend
die Feststellungen, ohne dass in der Regel Vorgesetzte anwesend sind.
Diese werden später in einer gesonderten Präsentation informiert. In
der Feedback-Sitzung wird geklärt, ob der Appraiser die Äußerungen
des Projektteams richtig verstanden hat und ob sich das Projektteam
mit den Feststellungen identifizieren kann.
3.2.3 CMMI-Anforderungen an konkrete Prozessgebiete
Da wir in diesem Buch zum Thema Prozessverbesserung den Schwer-
punkt auf die Disziplin Requirements Engineering legen, werden nach-
folgend die hierfür im CMMI relevanten Prozessgebiete Requirements
Development und Requirements Management genauer beschrieben.
Für analoge Beschreibungen zu weiteren Prozessgebieten sei wieder
auf [Chr 06] oder auf [Kne 07] verwiesen.
Zwischen Requirements Development und Requirements Manage-
ment besteht ein enger Zusammenhang. Requirements Development
beschäftigt sich mit der Eruierung und Auswahl der Anforderungen
sowie mit dem Ableiten der Produktanforderungen aus den Kunden-
anforderungen. Dieses Vorgehen lässt sich hierarchisch über die ver-
schiedenen Architekturebenen eines Produktes beliebig fortsetzen. So
werden schließlich auch die Anforderungen an einzelne Produktkom-
ponenten von den darüberstehenden Produktanforderungen abgelei-
tet. Ein weiterer wichtiger Aspekt des Requirements Development ist
die Analyse und Validierung der identifizierten Anforderungen.
3 Standortbestimmung78
Die sich aus dem Requirements Development ableitenden Akti-
vitäten sind eng mit den Requirements Management zuordenbaren
Aktivitäten verzahnt. Das Requirements Management adressiert die
Verwaltung der Anforderungen, das Thema Verfolgbarkeit von Anfor-
derungen durch den gesamten Entwicklungsprozess hindurch, Sicher-
stellung des einheitlichen Verständnisses über umzusetzende Anforde-
rungen sowie die Sicherstellung der Konsistenz zwischen den Anforde-
rungen und den Arbeitsergebnissen des Projektes (siehe Abb. 3–4).
Requirements Development
Zweck des Requirements
Development
Nach CMMI ist der Zweck des Prozessgebietes Requirements Deve-
lopment die Erstellung und Analyse von Kundenanforderungen, Pro-
dukt- und Produktkomponentenanforderungen.
SG 1 Develop Customer Requirements
SP 1.1 Elicit Needs
SP 1.2 Develop the Customer Requirements
SG 2 Develop Product Requirements
SP 2.1 Establish Product and Product Component
Requirements
SP 2.2 Allocate Product Component Requirements
SP 2.3 Identify Interface Requirements
Abb. 3–4
Zusammenhang zwischen
Requirements
Management und
Requirements
Development
(in Anlehnung an eine
Abbildung von Tim Kasse)
R
e
q
u
i
r
e
m
e
n
t
s
M
a
n
a
g
e
m
e
n
t
RD
REQM
Requirements Development

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