<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>verringer ter Einstiegshürde</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Raphael Pham</string-name>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Kurt Schneider</string-name>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Leibniz Universität Hannover</string-name>
        </contrib>
      </contrib-group>
      <fpage>141</fpage>
      <lpage>148</lpage>
      <abstract>
        <p>Die GQM Methode ist bereits ausreichend definiert. Man muss sie jedoch selbst einmal angewendet haben, um sie durchdringen zu können. Dabei können sogenannte Abstraction Sheets unterstützend eingesetzt werden. In der Lehre an der Leibniz Universität Hannover hat sich gezeigt, dass das Ausfüllen dieser Formulare vielen Studenten Probleme bereitet. Sie sind von Abstraction Sheets überfordert oder erkennen den Sinn darin nicht. Als Folge lehnen die Studenten die GQM Methode ab und erlernen sie nicht. Wir stellen einen smarten Editor vor, welcher konkret die Erstellung des Abstraction Sheets und die Entwicklung von zugehörigen Metriken unterstützt. Der Anwender wird mit prozess-gesteuerten Fragestellungen zum korrekten Ausfüllen beider Formulare angeregt. Unerfahrene Anwender können den vollen Unterstützungsumfang des smarten Editors ausschöpfen und so an die GQM Methode herangeführt werden. Erfahrene Benutzer können den Editor verwenden, um Abstraction Sheets, Questions und Metriken zu erstellen und zu verwalten.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>Zusammenfassung</title>
    </sec>
    <sec id="sec-2">
      <title>Motivation</title>
      <p>
        Ein Fallstrick beim Messen von Software
Entwicklungsprozessen oder Produkten ist, dass man das misst, was
einfach zu messen ist - und nicht das, was man
messen sollte, um aussagekräftige Ergebnisse zu erhalten
        <xref ref-type="bibr" rid="ref1">(Basili, 1992)</xref>
        . Man wendet sich an bereits bekannte
oder einfach zu erhebende Metriken. Hier verwendet
die GQM Methode einen Top-Down Ansatz: Anstatt
mittels vorhandener Werkzeuge (z.B. bekannte
Metriken) projekt-individuelle Ziele zu messen
(BottomUp), werden diese Ziele konkretisiert und durch
eigens entwickelte Metriken operationalisiert. Dies soll
gewährleisten, dass tatsächlich gemessen wird, was
auch gemessen werden soll - und auch nicht mehr.
      </p>
      <p>
        Grundlegende Ideen zu GQM entstanden während
einer Untersuchung am Goddard Space Flight Center
        <xref ref-type="bibr" rid="ref2">(Basili u. Weiss, 1984)</xref>
        . Später stellt
        <xref ref-type="bibr" rid="ref1">(Basili, 1992)</xref>
        das
GQM Paradigma vor und
        <xref ref-type="bibr" rid="ref15 ref3">(Van Latum u. a., 1998)</xref>
        erweitern die GQM Methode um sogenannte Abstraction
Sheets. Seit seiner Einführung konnte die GQM
Methode erfolgreich in verschiedenen Industrieprojekten
eingesetzt werden.
        <xref ref-type="bibr" rid="ref15 ref3">(Van Latum u. a., 1998)</xref>
        und
        <xref ref-type="bibr" rid="ref15 ref3">(Birk
u. a., 1998)</xref>
        beschreiben den Einsatz bei Schlumberger
RPS.
        <xref ref-type="bibr" rid="ref4 ref5">(Gantner u. Schneider, 2003)</xref>
        haben den
GQMProzess in zwei Fällen aus der Automobilindustrie
angewendet und beschreiben eingehend den Einsatz
von Abstraction Sheets.
        <xref ref-type="bibr" rid="ref7">(Kilpi, 2001)</xref>
        setzt eine
angepasste GQM Variante bei Nokia ein.
        <xref ref-type="bibr" rid="ref16">(Van Solingen u.
Berghout, 1999)</xref>
        bietet eine eingehende Betrachtung
von GQM samt Fallbeispielen.
      </p>
      <p>
        Dem Erfolg von GQM in der Praxis folgend, wird
die GQM Methode auch an der Leibniz Universität
Hannover gelehrt. Dem Thema GQM ist ein Kapitel
der Vorlesung zur Software-Qualität gewidmet und
es wird auch im dazugehörigen Übungsbetrieb
behandelt. Erfahrungsgemäß lässt sich ein besserer
Lernerfolg erzielen, wenn GQM praktisch angewendet
wird. Das Konzept von Abstraction Sheets und deren
korrekte Erstellung bereitet den Studierenden jedoch
öfter Schwierigkeiten - obwohl der Prozess zum
Erstellen eines Abstraction Sheets klar vorgegeben ist.
Studierende zeigten wiederholt Schwierigkeiten
Abstraction Sheets korrekt auszufüllen. Das mühsame
Aufzeichnen der Formulare per Hand könnte eine
zusätzlich Hürde darstellen. In dieser Arbeit stellen wir
einen Editor für Abstraction Sheets vor, der
Studierende mit Hilfsmechanismen aktiv beim Anwenden der
GQM Methode unterstützt. Der unsichere Anwender
wird mit gezielten Fragestellungen durch den
Ausfüllprozess geführt. Studierenden soll so eine mögliche
Ablehnung gegenüber der komplex anmutenden GQM
Methode genommen werden. Studierende sollen mit
diesem Werkzeug Gelegenheit erhalten, das korrekte
Ausfüllen von Abstraction Sheets zu üben.
        <xref ref-type="bibr" rid="ref18">(Werner,
2012)</xref>
        hat die in dieser Arbeit vorgestellten Konzepte
in einem lauffähigen Webtool realisiert.
      </p>
    </sec>
    <sec id="sec-3">
      <title>Die GQM Methode</title>
      <p>
        Die GQM Methode wurde bereits in zahlreichen
Veröffentlichungen behandelt. Im folgenden wird ein
kurzer Überblick über die GQM Methode gegeben (in
der Form, in welcher diese an der Leibniz Universität
Hannover gelehrt wird
        <xref ref-type="bibr" rid="ref14">(Schneider, 2007)</xref>
        ), um den
Wirkungsbereich unseres GQM-Editors aufzuzeigen.
      </p>
      <p>Der grundlegende Ablauf der GQM Methode sieht
die schrittweise Erstellung eines GQM-Modells (auch
GQM-Baum genannt) vor: Abstraktere Ziele werden</p>
      <p>
        AS
6
6
Abbildung 1: GQM Methode an der Leibniz Universität
Hannover, basierend auf
        <xref ref-type="bibr" rid="ref16">(Van Solingen u. Berghout,
1999)</xref>
        in konkrete Subziele (Goal) aufgeteilt. Subziele
werden durch beschreibende Fragen (Question) scharf
und zweckmäßig umrissen. Zur Beantwortung der
charakterisierenden Fragen werden Metriken (Metric)
erstellt, die den Erfüllungsgrad der Fragen und somit
den Erreichungsgrad des Ziels angeben. Abb. 2 zeigt
einen solches GQM-Modell.
      </p>
      <p>Zu Lehrzwecken spalten wir Teile der GQM
Methode auf und definieren sechs Schritte:
1. Ziele erheben und verfeinern (Goal)
2. Facettenbeschreibung der Ziele (Goal)
3. Ableitung von charakterisierenden Fragen
(Question) zu den Zielen
4. Ableitung von zugehörigen Metriken, (Metric)
5. Messplan für eigentliche Datenerhebung erstellen
(Metric)
6. Datenerhebung und Auswertung (Collection,
Interpretation)</p>
      <p>
        Die Einordnung dieser Schritte in das umfangreiche
Prozessmodell der GQM Methode nach
        <xref ref-type="bibr" rid="ref16">(Van Solingen
u. Berghout, 1999)</xref>
        ist in Abb. 1 eingezeichnet.
      </p>
      <p>Schritt 1 produziert einen sogenannten Zielbaum,
welcher ein high-level Messziel auf konkretere
Subziele verfeinert und in Beziehung miteinander setzt.
Aus diesem Zielbaum werden Subziele zur weiteren
Bearbeitung ausgewählt. Die Facettendarstellung des
Messziels (Schritt 2) forciert die Auseinandersetzung
mit verschiedenen Aspekten eines Ziels und regt zur
abgewandelten Betrachtung an.</p>
      <p>
        Für die Ableitung von charakterisierenden Fragen
zu einem Messziel (nun vorliegend als Zielfacette,
Schritt 3) wird ein spezielles Formular eingesetzt, das
sogenannte Abstraction Sheets
        <xref ref-type="bibr" rid="ref15 ref3">(Van Latum u. a., 1998)</xref>
        ,
        <xref ref-type="bibr" rid="ref16">(Van Solingen u. Berghout, 1999)</xref>
        ,
        <xref ref-type="bibr" rid="ref4 ref5">(Gantner u.
Schneider, 2003)</xref>
        . Es bietet eine festgelegte Struktur. Mittels
vier vordefinierten Fragestellungen baut der
Anwender systematisch ein Modell des zu untersuchenden
Messziels auf und gelangt zu tiefergreifendem
Verständnis. Der Qualitätsaspekt des
Betrachtungsgegenstandes (z.B. "Verständlichkeit"von "Quellcode") wird
auf konkrete und projektindividuelle Eigenschaften
heruntergebrochen. Diese heißen Qualitätsfaktoren
des Qualitätsaspektes. Ziel ist es, für jeden konkreten
Aspekt des Qualitätsaspekts einen beeinflussenden
Faktor zu finden (sogenannte Einflussfaktoren). Beide
gefundenen Faktoren sind über eine Einflusshypothese
zu verbinden. Nun ergibt sich eine das Messziel
charakterisierende Frage (Question) als Zustandsabfrage
von Qualitätsfaktoren.
      </p>
      <p>Die aufgestellte Einflusshypothese wird in Schritt
4 und 5 überprüft. Dabei wird eine Metrik zur
Zustandsabfrage des Qualitätsfaktors basierend auf dem
Zustand des Einflussfaktoren entwickelt: Es werden
verschiedene (mögliche) Ausprägungen für den
Einflussfaktoren ermittelt und jeweils der Einfluss auf den
Qualitätsfaktor gemessen. Für diesen Vorgang wird
ein eigenes Tabellentemplate verwendet.</p>
      <p>
        Die einzelnen Prozessschritte samt Formularen
skizziert Abb. 2. Eingehende Betrachtungen der GQM
Methode finden sich in
        <xref ref-type="bibr" rid="ref14">(Schneider, 2007)</xref>
        oder auch
        <xref ref-type="bibr" rid="ref16">(Van Solingen u. Berghout, 1999)</xref>
        .
      </p>
      <p>Der GQM-Editor nimmt ein Facettenziel entgegen
und unterstützt maßgeblich die Erstellung eines
zugehörigen Abstraction Sheets und zugehöriger
Messpläne (Schritt 3 und Schritt 4). Die Erstellung und
Verfeinerung von Messzielen oder deren Darstellung
als Facette werden nicht unterstützt (Schritt 1 und
Schritt 2). Beide Schritte lassen sich relativ schnell auf
Papier bewältigen und erfordern (gemäß
Lehrerfahrungen) weniger Unterstützung. Auch die eigentliche
Durchführung und anschließende Interpretation
werden nicht von unserem GQM-Editor unterstützt.</p>
    </sec>
    <sec id="sec-4">
      <title>Das Abstraction Sheet</title>
      <p>Das Abstraction Sheet (AS) bietet dem Anwender eine
streng definierte Struktur um methodisch und
zielsicher charakterisierende Fragen zu einem gegebenen
Messziel abzuleiten. Dabei ist die
Ausfüllreihenfolge der Quadranten vorgegeben und bildet ein U.
Jeder Quadrant verlangt dem Anwender ab, bestimmte
Aspekte des Messziels anzugeben. Auf diese Weise
wird der abstrakte Qualitätsaspekt des Messziels in
Qualitätsfaktoren konkretisiert, beeinflussende
Faktoren (Einflussfaktoren) identifiziert und zugehörige
Einflusshypothesen aufgestellt. Begonnen wird ein AS
mit dem Eintragen des Messziels in Facettenform
(oberer Teil von 3), welche aus dem vorigen Prozessschritt
2 übernommen wurde. Der Ablauf im Detail:
1. Oben, links: Der Qualitätsaspekt wird auf
konkrete Eigenschaften des Betrachtungsgegenstandes
konkretisiert, sogenannte Qualitätsfaktoren.
Welche Merkmale machen den Qualitätsaspekt in
diesem Projekt ganz konkret aus? In Fall von Abb. 3:
Verständlichkeit von Quellcode bedeutet für den
Ausfüllenden z.B. die Verzweigungstiefe.
2. Unten, links: Zu jedem Qualitätsfaktor wird eine
Ausgangshypothese aufgestellt, wie es zu
Messbeverfeinerte Ziele</p>
      <p>Goal
Goal</p>
      <p>Goal
Metric</p>
      <p>Metric
Question</p>
      <p>Question</p>
      <p>Question</p>
      <p>Question
charakterisierende</p>
      <p>Fragen</p>
      <p>Legende</p>
      <p>Ergebnis-Übergabe
Beitrag zum GQM-Baum
zugeschnittene</p>
      <p>Metriken</p>
      <p>Verbessere...</p>
      <p>Unterziel
1.1</p>
      <p>Unterziel</p>
      <p>1.2
Unterziel
1.1.1</p>
      <p>Unterziel
1.1.2
…</p>
      <sec id="sec-4-1">
        <title>Zweck AsQpe-kt Gsetagnedn- pPeekrtisv-e</title>
        <p>... ... ... ...
... ... ... ...</p>
      </sec>
      <sec id="sec-4-2">
        <title>Zweck AsQp-ekt Gsetagnedn- pPeekrtisv-e</title>
        <p>... ... ... ...</p>
        <p>1
2
4
3</p>
        <p>Q-Faktoren E-Faktoren</p>
        <p>...</p>
        <p>Question
Metrik
Ergebnis</p>
        <p>...</p>
        <p>Question
Metrik
Ergebnis
…
Zielbaum, Verfeinerung von</p>
        <p>Zielen</p>
        <p>Facettendarstellung,
Perspektivenwechsel</p>
        <p>Abstraction Sheet,
Ableitung von Questions</p>
        <p>Messplan, experimentelle
Überprüfung</p>
        <p>Messen,
interpretieren</p>
        <p>Abbildung 2: Übersicht über die GQM Methode, Einordnung der Prozessschritte und Formulare
ginn darum steht. Alternativ können auch
nachgemessene Werte eingetragen werden.
3. Unten, rechts: Der Anwender stellt
Einflusshypothesen für jeden Qualitätsfaktor auf: Wie könnte
der Qualitätsfaktor zu beeinflussen sein?
4. Oben, rechts: Aus den Einflusshypothesen werden</p>
        <p>Einflussfaktoren extrahiert.</p>
        <p>Abb. 3 zeigt ein ausgefülltes AS. Obwohl die
Anforderungen an den Inhalt eines Quadranten klar
definiert sind, bereitet es Studenten öfter Schwierigkeiten,
korrekte und brauchbare AS zu produzieren.</p>
        <p>Auf einen Studierenden, der das Konzept des
Abstraction Sheets noch nicht vollständig durchdrungen
hat, kann dieses Formular abschreckend und komplex
wirken. Zählt man das Eintragen des Messziels mit,
so werden mehr als vier verschiedene Abfragen an
den Studierenden gestellt. Hinzu kommt, dass
diese Felder konzeptbedingt jeweils eng gefasste Ziele
verfolgen und korrekte Antworten für die
erfolgreiche Anwendung voraussetzen: Werden z.B. im ersten
Quadranten die Qualitätsfaktoren nicht mit
konkretisierenden Attributen belegt — sondern bleiben so
abstrakt wie das Messziel — so führt das Abstraction
Sheet nicht zu dem gewünschten Ergebnis. In Abb.
3 würde der ungeübte Studierende als ersten
Qualitätsaspekt möglicherweise einfach ein Synonym für
das Messziel eintragen, z.B. Verständnis. Damit ist
in diesem Schritt jedoch nichts gewonnen. Der
Studierende füllt die nachfolgenden Felder aus — und
kommt dennoch nicht zum erwarteten Ergebnis und
ist enttäuscht. Damit dieser Fall nicht eintritt, bietet
unser Editor dem Studierenden gezielte Hilfestellung.</p>
        <p>Durch kontextabhängige, konkret formulierte
Fragestellungen wird der Anwender durch das Abstraction
Sheet geführt.</p>
        <p>Auch wenn der Hauptgrund der nicht-erfolgreichen
Anwendung des Abstraction Sheets auf Unverständnis
des zugrundeliegenden Konzeptes zurückzuführen ist,
so kann eine derart geführte (wiederholte)
Anwendung zur Durchdringung des Konzeptes führen bzw.
beitragen.</p>
      </sec>
    </sec>
    <sec id="sec-5">
      <title>Der smarte GQM-Editor</title>
      <p>Die Inhalte der Quadranten 1 bis 4 sind abhängig von
einander: Inhalte werden von Quadrant zu Quadrant
weitergegeben und verarbeitet. Z.B.: Hat der
Anwender in Quadrant 1 das Qualitätsziel auf zwei konkrete
Faktoren heruntergebrochen, so tauchen diese beiden
Faktoren mit einer zusätzlichen Statuseinschätzung
(genauer: Ausgangshypothese) im zweiten
Quadranten wieder auf. Dieses Beispiel zeigt zwei Ebenen, auf
denen der Anwender agieren muss, um das AS
auszufüllen: Zum einen muss er einen kreativen Schritt
tätigen und das Q-Ziel konkretisieren - dabei muss er
genau wissen, was gerade von ihm verlangt wird. Zum
anderen muss er die Einträge manuell in den
nächsten Schritt übertragen und dort weiterverarbeiten. An
diesen Stellen setzt unser GQM-Editor an: Der
Anwender wird bei einem kreativen Vorgang durch eine
gezielte Fragestellung als dezenter Hinweistext
unterstützt (Grauer Hilfstext). Weiterhin übernimmt der
GQM-Editor manuelle Schritte, überträgt
Zwischenergebnisse in Folge-Quadranten und versucht damit
die nächsten Einträge teilweise zu generieren
(Automatischer Hilfstext). Beide Unterstützungsvarianten</p>
      <p>Abbildung 3: Ein ausgefülltes Abstraction Sheet im GQM-Editor
werden dynamisch anhand von vorhergegangenen
Eingaben im AS generiert. Auf diese Weise lassen sie
eine kontextbezogene Unterstützung zu. Dies ist eine
der Stärken des GQM-Editors von denen besonders
unerfahrene Anwender profitieren können. Beide
Unterstützungstexte werden als vorgeschlagene
Antworteinträge in den Quadranten eingeblendet — die der
Anwender nach Belieben ändern und anpassen kann.</p>
      <p>Für erfahrene Benutzer können die beiden
Unterstützungsmechanismen ausgeschaltet werden, sodass
der GQM-Editor als reiner Editor fungiert. Alle drei
Mechanismen (keine Hilfe, grauer Hilfstext,
automatischer Hilfstext) können für jeden Quadranten
individuell eingestellt werden (siehe Dropboxen in den
Quadranten, Abb. 3).</p>
      <p>Die Hilfstexte haben eine weitere Funktion: Sie
erscheinen in der Reihenfolge, in der das AS ausgefüllt
werden sollte. Jeweils der nächst-auszufüllende
Quadrant wird mit grauem oder schwarzem Hilfstext
gefüllt. Dies soll den Anwender durch den Ausfüllprozess
leiten. Da es sich bei den Hilfstexten nur um
Vorschläge handelt, kann der Anwender aber auch gegen diese
Reihenfolge verstoßen und z.B. die voreingetragenen
Werte entfernen.</p>
      <sec id="sec-5-1">
        <title>Grauer Hilfstext</title>
        <p>Das Einblenden von grauem Hilfstext ist die erste
Unterstützungsstufe unseres GQM-Editors und für
unerfahrene Anwender gedacht. Der Hilfstext soll dem
Anwender an geeigneter Stelle ins Gedächtnis rufen,
was in dem aktuellen Quadranten einzutragen ist. Er
Abbildung 4: Hilfestellung im Quadrant 1
dient als Gedankenstütze, um die Aufgabe klar zu
definieren: Der Anwender wird explizit — und angepasst
an vorherige Eingaben — nach dem einzutragenden
Inhalt gefragt. So erscheint der graue Hilfstext im
ersten Quadranten, sobald der Anwender das
Messziel als Zielfacette eingetragen hat. Die eingetragenen
Werte werden dynamisch im Text verarbeitet und sind
kontextualisiert: Anhand der eingegeben Zielfacette
in Abb. 3 (gelb unterlegt) generiert der Editor den
grauen Hilfstext: “Was ist für einen Entwickler ein
Merkmal für Verständlichkeit, wenn es um Quellcode
geht?” (siehe Abb. 4).</p>
        <p>Sobald der Anwender auf ein Feld mit grauem
Hilfstext klickt und einen Eintrag vornehmen will,
verschwindet dieser und das Textfeld ist für den
Anwender freigegeben. Die graue Farbe wurde bewusst dem
Anschein eines flüchtigen Tooltipps nachempfunden.
Abbildung 5: Hilfestellung im Quadranten 2 und 3</p>
      </sec>
      <sec id="sec-5-2">
        <title>Automatischer Hilfstext</title>
        <p>Die zweite Unterstützungsstufe wendet sich an sehr
unerfahrene Anwender: Der GQM-Editor generiert
Teile des Eintrags als schwarzen Text vor und lässt
gezielt Lücken, die der Anwender ausfüllen soll. Dies
lenkt die Gedanken der Anwender in gezielte Bahnen
und es werden konkrete Werte verlangt.</p>
        <p>Das Ausfüllen von Quadrant 1 bedarf eines
kreativen Schrittes, der durch den grauen Hilfstext
unterstützt wird. Teile von Antworten zu generieren ist
hier nicht möglich. Quadrant 2 (Ausgangshypothese)
bietet jedoch die Möglichkeit, die Q-Faktoren
automatisch in die rudimentäre Form einer Hypothese zu
überführen. Dabei kann der Aussagenkern der
Hypothese nicht generiert werden, da dies wieder eines
kreativen Schrittes bedarf. Jedoch wird das Eintragen
dieses Aussagenkerns durch einen gezielten
Lückentext unterstützt:</p>
        <p>Bevor der Anwender in das Feld zum Eintragen
der ersten Ausgangshypothese klickt, hat der Editor
dort in grau eingetragen: “Wie steht es momentan
um die/den ’Verzweigungstiefe’? Welche
Erfahrungswerte, Vermutungen und/oder Messwerte gibt es zu
diesem Qualitätsfaktor?” Dies erinnert den Anwender
an die von ihm geforderte Ausgangshypothese.
Sobald er in das Feld klickt, erscheint die folgende
vorgenerierte Antwort in schwarzem und editierbarem
Text: “Verzweigungstiefe ist/sind momentan zu &lt;bitte
Eigenschaft eintragen&gt;. Momentan beträgt
Verzweigungstiefe: &lt;bitte Wert eintragen&gt;.” Der Benutzer
kann diese Vorlage verwenden, um seine
Ausgangshypothese zu verfassen oder eine eigene formulieren (s.
Abb. 5).</p>
        <p>Ähnlich lässt sich mit Quadrant 3 verfahren (siehe
Abb. 5), jedoch nicht mit Quadrant 4: Die
Einflussfaktoren zuverlässig aus den resultierenden
Einflusshypothesen zu extrahieren, ist aufgrund von sprachlichen
Abweichungen und Eigenarten schwierig.</p>
        <p>Letztendlich lässt sich diese zweite
Unterstützungsstufe nur für den zweiten Quadranten
(Ausgangshypothese) und dritten Quadranten (Einflusshypothese)
einschalten. Quadranten 1 und 4 können lediglich die
erste Unterstützungsstufe einsetzen.</p>
        <p>Da möglicherweise die generierte Antwort nicht zu
dem aktuellen Messprojekt passt, lässt sich diese
generierte Antwort wie ein normales Textfeld bearbeiten
und auch löschen. In Abb. 5 hat der Anwender die
zweite Ausgangshypothese angepasst.</p>
      </sec>
      <sec id="sec-5-3">
        <title>Der Messplan</title>
        <p>Nachdem der Anwender mithilfe des Abstraction
Sheets Einflussfaktoren der Qualitätsfaktoren und
zugehörige Einflusshypothesen aufgestellt hat, folgt der
Schritt der experimentellen Überprüfung eines
solchen Zusammenhangs. Der sogenannte Messplan
fordert den Anwender auf, verschiedene Ausprägungen
des Einflussfaktors zu ermitteln und dann zu
überprüfen, wie sich der Qualitätsfaktor verhält. Auf diese
Weise soll die Einflusshypothese validiert bzw. falsche
Annahmen aufgedeckt werden.</p>
        <p>Die beiden Faktoren werden automatisch aus dem
Abstraction Sheet übernommen und bleiben an der
selben Stelle stehen. Dies soll Verwirrungen beim
unerfahrenen Anwender vermeiden. Bedingt durch die
Idee der experimentellen Überprüfung muss der
Anwender mit der rechten Seite des Messplans beginnen
und zuerst den Einflussfaktor betrachten. Da dies
etwas unintuitiv erscheinen mag, wird standardmäßig
die linke Seite mit einem Hinweis ausgeblendet (siehe
Abb. 6). Persönliche Workflows können auch realisiert
werden; der Hinweis lässt sich ausschalten.</p>
        <p>Jede Seite des Messplans gliedert sich in drei Teile,
die nacheinander ausgefüllt werden.
1. Frage nach den möglichen Ausprägungen des
Fak</p>
        <p>tors.
2. Handlungsanweisungen, diese Ausprägungen zu</p>
        <p>ermitteln.
3. Ausprägungen ermitteln und eintragen.</p>
        <p>Die Formulierung der einleitenden Frage nach den
Ausprägungen wird mit grauem Hilfstext bzw.
schwarzem Lückentext unterstützt (siehe Abb. 6, beide Texte
in den Feldern “Frage” sind generiert). Jedoch sind
Schritt 2 und 3 stark projektabhängig und individuell.</p>
        <p>Dementsprechend kann der GQM-Editor diese nicht</p>
        <p>Abbildung 6: Linke Seite des Messplans wird zu Beginn ausgeblendet.
mit automatisch generierten Antworten unterstützen,
bietet jedoch hier die erste Hilfestufe an (grauer Text
als Gedankenanstoß). Weiterhin gibt der graue
Hinweistext dem unerfahrenen Benutzer die Reihenfolge
zum Ausfüllen vor. Jede Eingetragene Ausprägung für
den Einflussfaktor ist einem Eintragungsfeld für eine
Ausprägung gegenübergestellt. Auf diese Weise soll
dem Anwender die Gegenüberstellung und der Effekt
der verschiedenen Faktor-Ausprägungen vereinfacht
werden.</p>
      </sec>
    </sec>
    <sec id="sec-6">
      <title>Verwandte Arbeiten</title>
      <p>Zur Unterstützung der GQM Methode wurden bereits
einige Tools entwickelt. Jedoch ist keines der
untersuchten Tools fokussiert auf unerfahrene Benutzer
oder bietet Hilfestellung beim eigentlichen Ausfüllen
von Abstraction Sheets und Messplänen.</p>
      <p>
        Die Enwicklung von GQMaspect wurde an der
Universität Kaiserslautern begonnen und später am
Fraunhofer IESE (Institut für experimentelles Software
Engineering) weitergeführt
        <xref ref-type="bibr" rid="ref13 ref6">(Hoffmann u. a., 1997)</xref>
        ,
        <xref ref-type="bibr" rid="ref17">(Voigtlaender, 1999)</xref>
        . GQMaspect unterstützt die gesamte
GQM Methode: Aufnahme und Verwaltung der Goals,
Erstellen von Abstraction Sheet mittels Editor bis hin
zur Verwaltung von Messplänen. Mit GQMaspect
lassen sich Beziehungen zwischen einzelnen Produkten
der Arbeitsphasen der GQM Methode herstellen (Ein
Goal wird einem AS zugewiesen, etc) und es können
Vollständigkeitsabfragen gemacht werden (wurde
jedes definierte Goal mit einem AS weiterverfolgt?). Der
Ansatz unseres GQM-Editors unterstützt hier lediglich
die Erstellung von Abstraction Sheets und Messplänen
— Goals werden nicht nennenswert behandelt. Im
Gegensatz zu unserem GQM-Editor bietet GQMaspect
dem Anwender jedoch wenig Unterstützung, wenn es
um das eigentliche Erstellen von neuen GQM-Inhalten
geht. Anwendergruppe von GQMaspect sind
erfahrene GQM-User, während GQM-Editor für den
Lehrgebrauch bzw. für unerfahrene Anwender konstruiert
wurde.
      </p>
      <p>
        GQM–DIVA (GQM–Definition Interpretation
Validation) wurde im Rahmen einer Diplomarbeit an der
Universität Kaiserslautern entwickelt
        <xref ref-type="bibr" rid="ref12">(van Maris u. a.,
1995)</xref>
        . Das Tool überprüft die Konsistenz der Einträge
eines GQM-Baumes (hier genannt: GQM-Plan), damit
keine fehlerhaften Daten weiterverwendet werden.
Dieser GQM-Baum kann mit fiktiven Messwerten in
Simulation ausgewertet werden. Damit sollen Lücken
(fehlende Daten) im GQM-Baum aufgedeckt werden.
GQM-Diva benötigt ein fertig ausgefülltes Abstraction
Sheet als Eingabe. Dessen Erstellung wird nicht
unterstützt. Auch die Erstellung eines Messplans wird von
GQM-DIVA nicht abgedeckt.
      </p>
      <p>
        <xref ref-type="bibr" rid="ref4 ref5">(Chen u. a., 2003)</xref>
        stellen mit dem Multi-Agent
System ISMS (Intelligent Software Measurement System)
eine Vision eines intelligenten Wizzards zur
Durchführung der GQM Methode vor. Der Anwender gibt
ein Unternehmensziel ein und beantwortet
interaktive Fragen. Schrittweise werden verfeinerte Messziele,
individuelle Metriken, etc. anhand der
Anwenderantworten auf intelligente Weise herausgeschält. Dies soll
mithilfe von eigenen Agents und einer
angeschlossenen Knowledge Base samt Reasoning Mechanism
geschehen. Am Ende soll ein fertiger und
einsatzbereiter Messplan ausgegeben werden. Der Ansatz ist
interessant, scheint jedoch noch nicht praktisch
umgesetzt zu sein. Auch werden Abstraction Sheets nicht
betrachtet.
      </p>
      <p>
        MetriFlame ist von VTT Electronics entwickelt
worden und dient zur Sammlung, Analyse und
Präsentation von Messdaten. Die Grundidee ist, dass dieses Tool
automatisch Daten für eine anstehende Messung
sammelt, indem es sich mit verschiedenen Datenbanken
anderer Tools verbinden kann.
        <xref ref-type="bibr" rid="ref13 ref6">(Parviainen u. a., 1997)</xref>
        setzte MetriFlame bei der Andererwendung der GQM
Methode ein, um passende Metriken zu finden und
Daten zu sammeln. MetriFlame erlaubt die Generierung
von GQM Bäumen auf Basis von bereits gespeicherten
Metriken. Das Aufstellen von Abstraction Sheets oder
Messplänen wird nicht unterstützt.
      </p>
      <p>
        Das GQM-Tool von
        <xref ref-type="bibr" rid="ref8">(Lavazza, 2000)</xref>
        bietet die
Möglichkeit GQM Bäume zu erstellen. Deren Struktur wird
auf Konsistenz überprüft, indem z.B. kontrolliert wird,
ob jedes Messziel zu mindestens einer Frage
verfeinert wurde und es zu jeder Frage mindestens eine
Metrik gibt. Messziele, Abstraction Sheets, Questions
und Metriken werden als Produkte der GQM Methode
unterstützt. Einzelne Komponenten von GQM-Plänen
können wiederverwendet werden. Das GQM-Tool ist
mit einer Datenbank verbunden. Auch dieses Tool
bietet keine Hilfestellungen an, die erklären, wie ein
Abstraction-Sheet auszufüllen ist.
      </p>
    </sec>
    <sec id="sec-7">
      <title>Diskussion</title>
      <p>Der smarte GQM-Editor verwendet Texteingaben des
Anwenders, um nächst-auszufüllende Felder mit
kontextualisierten Hilfstexten oder sogar vorgenerierten
Antworten zu bestücken. Die Konstruktion der
grauen und schwarzen Hilfstexte basiert auf Textmustern,
welche wir durch wiederholtes Bearbeiten und Lehren
von Abstraction Sheets in der Lehre erkannt haben.
Grob gesagt hat das begleitete Erklären von
Abstraction Sheets anhand solch gearteter Kommentare den
höchsten Lernerfolg bei Studenten erzielt.</p>
      <p>Der smarte GQM-Editor setzt eine einfache
Textersetzung nach diesen Regeln ein. Dieser Mechanismus
ist zuverlässiger, je eindeutiger die Eingabetexte sind.
Z.B. lässt sich anhand der starren Form der
MesszielFacette des Abstraction Sheets (vier Eingabefelder,
jeweils meist nur ein Wort) ein relativ passender und
hilfreicher grauer Hinweistext im ersten Quadranten
erzeugen (siehe Abb. 4). Je variabler die Eingabetexte
werden, desto unzuverlässiger kann der generierte
Text im nächsten Feld ausfallen. Dies kann dazu
führen, dass der generierte Text unbrauchbar wird. Graue
Hilfstexte verschwinden jedoch auch beim Anklicken
und vorgenerierte Antworten (schwarzer Text)
können einfach anwenderseitig bearbeitet oder gelöscht
werden. Werden diese Textstücke generell zu
verwirrend, kann der Anwender diese Unterstützung auch
insgesamt ausschalten.</p>
      <p>Die Feinheiten der deutschen Grammatik
(männliche, weibliche Artikel, Plural, Singular) werden nicht
gesondert behandelt. Die generierten Texte sind in
dieser Hinsicht möglichst allgemein ausgelegt und
verwenden mitunter unschöne Doppelbelegungen wie
z.B. "die/den". Ein Plugin zur korrekten Lösung
solcher Fälle lässt sich jedoch nachträglich einfügen.
Generell priorisieren wir den Lerneffekt beim
unerfahrenen Anwender gegenüber vollkommen korrekter
Sprachkonstrukte. Mögliche sprachliche Fehler oder
Ungenauigkeiten werden hingenommen, solange der
Anwender versteht, was gemeint ist bzw. was gerade
von ihm verlangt wird.</p>
      <p>Der smarte GQM-Editor stellt keine Silver-Bullet für
die GQM Methode oder das Erstellen von
Abstraction Sheets dar. Der Anwender soll jedoch verstehen,
was von ihm verlangt wird und wie solche Formulare
gehandhabt werden. Der smarte GQM-Editor “hilft
dabei auf die Sprünge” — kreative und korrektive
Arbeitsschritte seitens des Anwenders werden dabei
aber nicht ausgeschlossen.</p>
      <p>Die praktische Nützlichkeit der hier vorgestellten
Konzepte konnte nicht im universitären Umfeld
evaluiert und validiert werden. Eine umfangreiche
Evaluation ist bereits in Planung. Da diese Konzepte aber auf
praktischer Lehrerfahrung basieren, sind wir
zuversichtlich, dass Studierende davon profitieren werden.</p>
    </sec>
    <sec id="sec-8">
      <title>Zusammenfassung und Ausblick</title>
      <p>
        Die GQM Methode wurde seit seiner Vorstellung
durch
        <xref ref-type="bibr" rid="ref1">(Basili, 1992)</xref>
        erfolgreich in Industrieprojekten
eingesetzt und hat die Entwicklung von
verschiedenen Werkzeugen angetrieben. Lehrerfahrung an der
Leibniz Universität Hannover zeigt jedoch, dass die
GQM Methode bei Studierenden nur Akzeptanz findet,
wenn sie praktisch ausprobiert und eingesetzt wird.
Jedoch schrecken die komplex anmutenden Formulare
wie Abstraction Sheet oder Messplan Studierende ab.
      </p>
      <p>In dieser Arbeit wird ein lauffähiger smarter
GQMEditor vorgestellt. Er bietet eine webbasiert
EditorOberfläche für die beiden Formulare Abstraction Sheet
und Messplan und richtet sich in erster Linie an
unerfahrene GQM-Anwender (wie z.B. Studierende).</p>
      <p>Der GQM-Editor verarbeitet vorhergegangene
Anwendereingaben, um kontextualisierte Hinweistexte
an passenden Stellen einzublenden. Z.B. wird der
Anwender in jedem Quadrant eines Abstraction Sheets
explizit und individualisiert nach den einzutragenden
Inhalten gefragt. Diese Hinweistexte sollen als
Denkanstoß dienen und dem unsicheren Studierendem
helfen, diese Formulare zu verstehen.</p>
      <p>Zusätzlich kann der smarte GQM-Editor
Antwortteile im Abstraction Sheet auf Wunsch anhand
vorheriger Eingaben generieren. Antwortteile, die nicht
automatisch generiert werden können, werden durch
Lückentexte repräsentiert. Diese sollen den Anwender
anregen, passende Antworten einzutragen.</p>
      <p>Die generierten Texte erscheinen in der
angedachten Ausfüllreihenfolge. Sie können vom Nutzer
angepasst, gelöscht bzw. ausgeschaltet werden. Die
erstellten Abstraction Sheets und Messpläne können vom
Anwender gespeichert und verwaltet werden.</p>
      <p>Eine umfangreiche Evaluierung des vorgestellten
smarte GQM-Editor in der universitären Lehre wird
vorbereitet. Dabei soll die Akzeptanz der GQM
Methode und der zugehörige Wissensgewinn bei
Studierenden gemessen werden.</p>
      <p>Die Konzepte des smarten GQM-Editors sind als
Initiative zu verstehen, komplizierte Techniken besser
zu erlernen und vermitteln. Tool-basiert kann die
SELehre damit unterstützt werden.</p>
    </sec>
    <sec id="sec-9">
      <title>Literatur</title>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          <source>[Basili</source>
          <year>1992</year>
          ] BASILI,
          <string-name>
            <surname>Victor</surname>
            <given-names>R.</given-names>
          </string-name>
          :
          <article-title>Software modeling and measurement: the goal/question/metric paradigm</article-title>
          . College Park, MD : Maryland Univ.,
          <source>1992 (Computer science technical report Series)</source>
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          [Basili u.
          <source>Weiss</source>
          <year>1984</year>
          ] BASILI,
          <string-name>
            <surname>Victor</surname>
            <given-names>R. ; WEISS</given-names>
          </string-name>
          ,
          <string-name>
            <surname>David</surname>
            <given-names>M.:</given-names>
          </string-name>
          <article-title>A Methodology for Collecting Valid Software Engineering Data</article-title>
          . In: Software Engineering, IEEE Transactions on SE-
          <volume>10</volume>
          (
          <year>1984</year>
          ), nov.,
          <source>Nr</source>
          . 6,
          <string-name>
            <surname>S.</surname>
          </string-name>
          728 -
          <fpage>738</fpage>
          . http://dx.doi.org/10.1109/TSE.
          <year>1984</year>
          .
          <volume>5010301</volume>
          . - DOI 10.1109/TSE.
          <year>1984</year>
          .
          <volume>5010301</volume>
          .
          <string-name>
            <surname>- ISSN</surname>
          </string-name>
          0098-
          <fpage>5589</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          [Birk u. a. 1998
          <string-name>
            <surname>] BIRK</surname>
            ,
            <given-names>A. ; SOLINGEN</given-names>
          </string-name>
          , R. van ; JARVINEN, J.:
          <article-title>Business impact, benefit, and cost of applying GQM in industry: an in-depth, long-term investigation at Schlumberger RPS</article-title>
          .
          <source>In: Software Metrics Symposium</source>
          ,
          <year>1998</year>
          .
          <article-title>Metrics 1998</article-title>
          . Proceedings. Fifth International,
          <year>1998</year>
          , S.
          <fpage>93</fpage>
          -
          <lpage>96</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          [Chen u. a. 2003] CHEN,
          <string-name>
            <surname>T.</surname>
          </string-name>
          ; FAR,
          <string-name>
            <surname>B.H. ; WANG</surname>
          </string-name>
          ,
          <string-name>
            <surname>Y.</surname>
          </string-name>
          :
          <article-title>Development of an intelligent agent-based GQM software measurement system</article-title>
          .
          <source>In: Proceedings of ATS</source>
          ,
          <year>2003</year>
          ,
          <string-name>
            <surname>S. 188</surname>
          </string-name>
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          [Gantner u.
          <source>Schneider</source>
          <year>2003</year>
          ]
          <article-title>GANTNER, Thomas ; SCHNEIDER, Kurt: Zwei Anwendungen von GQM: Ähnlich, aber doch nicht gleich</article-title>
          .
          <source>In: Metrikon</source>
          <year>2003</year>
          (
          <year>2003</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          [Hoffmann u. a. 1997] HOFFMANN,
          <string-name>
            <given-names>M.</given-names>
            ;
            <surname>BIRK</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            ;
            <surname>ELS</surname>
          </string-name>
          ,
          <string-name>
            <surname>F. van ; KEMPKENS</surname>
          </string-name>
          , R.:
          <source>GQMaspect V1</source>
          . 0:
          <string-name>
            <given-names>User</given-names>
            <surname>Manual</surname>
          </string-name>
          .
          <source>Fraunhofer-IESE</source>
          ,
          <year>1997</year>
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          <source>[Kilpi</source>
          <year>2001</year>
          ] KILPI,
          <string-name>
            <surname>T.</surname>
          </string-name>
          :
          <article-title>Implementing a software metrics program at Nokia</article-title>
          . In: Software, IEEE
          <volume>18</volume>
          (
          <year>2001</year>
          ), nov/dec, Nr. 6,
          <string-name>
            <surname>S.</surname>
          </string-name>
          72 -
          <fpage>77</fpage>
          . http://dx.doi.org/10.1109/52.965808. - DOI 10.1109/52.965808.
          <string-name>
            <surname>- ISSN</surname>
          </string-name>
          0740-
          <fpage>7459</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          <source>[Lavazza</source>
          <year>2000</year>
          ] LAVAZZA,
          <string-name>
            <surname>L.</surname>
          </string-name>
          :
          <article-title>Providing automated support for the GQM measurement process</article-title>
          . In:
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          <string-name>
            <surname>Software</surname>
          </string-name>
          , IEEE
          <volume>17</volume>
          (
          <year>2000</year>
          ), may/jun, Nr. 3,
          <string-name>
            <surname>S.</surname>
          </string-name>
          56 -
          <fpage>62</fpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>http://dx.doi.org/10.1109/52.896250. - DOI</mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          10.1109/52.896250.
          <string-name>
            <surname>- ISSN</surname>
          </string-name>
          0740-
          <fpage>7459</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          [van Maris u. a. 1995] MARIS, M. van ; DIFFERDING,
          <string-name>
            <given-names>D.I.C.</given-names>
            ;
            <surname>GIESE</surname>
          </string-name>
          ,
          <string-name>
            <surname>D.I.P.</surname>
          </string-name>
          :
          <article-title>Ein Werkzeug zur Definition, Interpretation und Validation von GQM-Planen</article-title>
          .
          <article-title>(</article-title>
          <year>1995</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          [Parviainen u. a. 1997] PARVIAINEN,
          <string-name>
            <surname>P.</surname>
          </string-name>
          ; JARVINEN, J. ; SANDELIN,
          <string-name>
            <surname>T.</surname>
          </string-name>
          :
          <article-title>Practical experiences of tool support in a GQM-based measurement programme</article-title>
          .
          <source>In: Software Quality Journal</source>
          <volume>6</volume>
          (
          <year>1997</year>
          ),
          <year>Nr</year>
          . 4,
          <string-name>
            <surname>S.</surname>
          </string-name>
          283-
          <fpage>294</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          <source>[Schneider</source>
          <year>2007</year>
          ]
          <article-title>SCHNEIDER, Kurt: Abenteuer Softwarequalität: Grundlagen und Verfahren für Qualitätssicherung und Qualitätsmanagement</article-title>
          . Dpunkt,
          <year>2007</year>
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          [Van Latum u. a. 1998
          <string-name>
            <surname>] VAN LATUM</surname>
            ,
            <given-names>F. ; VAN SOLINGEN</given-names>
          </string-name>
          , R. ; OIVO,
          <string-name>
            <given-names>M.</given-names>
            ;
            <surname>HOISL</surname>
          </string-name>
          ,
          <string-name>
            <given-names>B.</given-names>
            ;
            <surname>ROMBACH</surname>
          </string-name>
          ,
          <string-name>
            <surname>D.</surname>
          </string-name>
          ; RUHE, G.:
          <article-title>Adopting GQM based measurement in an industrial environment</article-title>
          .
          <source>In: Software, IEEE</source>
          <volume>15</volume>
          (
          <year>1998</year>
          ), jan/feb, Nr. 1,
          <string-name>
            <surname>S.</surname>
          </string-name>
          78 -
          <fpage>86</fpage>
          . http://dx.doi.org/10.1109/52.646887. - DOI 10.1109/52.646887.
          <string-name>
            <surname>- ISSN</surname>
          </string-name>
          0740-
          <fpage>7459</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          [Van Solingen u.
          <source>Berghout</source>
          <year>1999</year>
          ]
          <string-name>
            <surname>VAN SOLINGEN</surname>
          </string-name>
          , R. ; BERGHOUT, E.: The Goal/Question/Metric Method:
          <article-title>a practical guide for quality improvement of software development</article-title>
          .
          <source>McGraw-Hill</source>
          ,
          <year>1999</year>
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          <source>[Voigtlaender</source>
          <year>1999</year>
          ] VOIGTLAENDER,
          <string-name>
            <surname>und Kempkens R. C.</surname>
          </string-name>
          <article-title>: GQMaspect II. System Documentation</article-title>
          .
          <source>Fraunhofer-IESE</source>
          ,
          <year>1999</year>
        </mixed-citation>
      </ref>
      <ref id="ref18">
        <mixed-citation>
          <source>[Werner</source>
          <year>2012</year>
          ]
          <article-title>WERNER, Florian: Entwurf eines regelbasierten GQM-Editors mit geringer Einstiegshürde, Leibniz Universität Hannover</article-title>
          , Fachgebiet Software Engineering,
          <source>Bachelor's Thesis</source>
          ,
          <year>2012</year>
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>