Ein kontrolliertes Experiment über die Auswirkung von Feedback ...

3 Vorbereitung des Experiments mit der GQM-Methode | 28
3 Vorbereitung des Experiments mit der GQM-Methode
3.1 Vorstudie
In der Vorstudie soll herausgearbeitet werden, worum es bei der Messung genau gehen soll.
Klar ist, dass die Ergebnisse zwei unabhängiger Stichproben miteinander verglichen werden
sollen. Dabei soll nur die eine Gruppe das Werkzeug Fast Feedback benutzen. Sie wird im
Folgenden als Experimentgruppe bezeichnet. Die andere Gruppe soll als Hilfsmittel
ausschließlich ein leeres Blatt Papier zur Verfügung gestellt bekommen. Dieses wird ihnen
aus drei Gründen elektronisch in Form eines leeren Word-Dokuments bereitgestellt. Das hat
erstens den Grund, dass die Probanden der verschiedenen Gruppen das jeweilige Werkzeug
möglichst alle unter den gleichen Rahmenbedingungen benutzen sollen und ein Unterschied
in der Art der Textverarbeitung (Papier gegen PC) eine Störvariable bedeuten könnte.
Zweitens sind handschriftliche Dokumente grundsätzlich schwierig auszuwerten. Drittens
wurde Word als Textverarbeitungsprogramm ausgewählt, weil davon auszugehen ist, dass die
Probanden aufgrund des Bekanntheitsgrades von Word ausreichend mit den zugehörigen
Funktionen vertraut sind und keine Einarbeitungszeit benötigen. Das von der zweiten Gruppe
verwendete Werkzeug ist also Word und die Gruppe soll im Folgenden als Kontrollgruppe
bezeichnet werden. Zur weiteren Erarbeitung dessen, worum es in der Messung nun genau
gehen soll, werden in diesem Kapitel zunächst die Hypothesen aus den Grundlagen
herausgearbeitet, dann wird das Experiment sinnvoll eingeschränkt und anschließend mit der
GQM-Methode vorbereitet. So ist eine präzise Planung und korrekte Erstellung des
Messplans möglich.
3.1.1 Herausarbeitung der Hypothesen
3.1.1.1 Hypothese 1 – Fehler in der Anforderungserhebung
„Die Wichtigkeit des Requirements Engineering wird vielfach unterschätzt.“ [Poh08, S.10] In
der Anforderungserhebungsphase werden die Anforderungen in der Regel zunächst nur vage
formuliert. Verschiedene Stakeholder haben wahrscheinlich sogar unklare und
widersprüchliche Ansichten zur gewünschten Software. Dazu kommt, dass sich der
Anforderungsingenieur erst in den Kontext der zu entwickelnden Software einarbeiten muss.
Werden die Anforderungen dann im nächsten Schritt dokumentiert, so kommt es nicht selten
dazu, dass sich Missverständnisse, Widersprüche, Inkonsistenzen und ähnlich fehlerhaft
dokumentierte Anforderungen in den Dokumenten verfestigen. „Beispielsweise werden
Anforderungen übersehen oder missverständlich und unvollständig spezifiziert.“ [Poh08,
S.10] Diese Fehler können ernste und kostenintensive Probleme zur Folge haben. [Schn08]
Natürlich können sich auch Tippfehler und problematische Satzstrukturen einschleichen, um
die es aber im Rahmen dieses Experiments nicht gehen soll, da die zu untersuchende Software
nicht darauf ausgelegt ist, solche Fehler zu finden. Vielmehr verspricht eine die
Anforderungserhebung unterstützende Software wie Fast Feedback dadurch Verbesserung,
dass früher im Prozess ein Demonstrations-Prototyp mit Hilfe von Mock-ups skizziert werden
kann, der dem Kunden die Möglichkeit zu einem schnellen Feedback gibt. Die
Dokumentation und die Validierung fließen so in die Anforderungserhebung mit ein. Ein Ziel
der Verwendung von Fast Feedback soll also sein, möglichst viele fehlerhaft dokumentierten
Anforderungen zu erkennen und das am besten zu einem frühen Zeitpunkt, damit hohe