Goal Question Metric

Goal Question Metric (GQM) ist eine systematische Vorgehensweise zur Erstellung spezifischer Qualitätsmodelle im Bereich der Softwareentwicklung. Diese lässt sich als Baumstruktur darstellen. Als Wurzel steht das Ziel (Goal), das über die Knoten (Questions) zu den Blättern (Metric) verfeinert wird. Auf diesem Weg werden Fragen und Softwaremaße abgeleitet. Auf dem Weg von den Blättern zur Wurzel werden die gemessenen Werte interpretiert.

Geeignete Metriken lassen sich in der Softwaremetrie identifizieren über die Beantwortung der folgenden Fragen:

• Welches Ziel soll durch die Messung erreicht werden? (Goal)
• Was soll gemessen werden bzw. welche Fragen soll die Messung beantworten? (Question)
• Welche Metrik ist/welche Metriken sind in der Lage, die notwendigen Eigenschaften zu beschreiben? (Metric)

„Wie kann man entscheiden, was man messen muss, um seine Ziele zu erreichen?“

Genau vor einem solchen Problem standen die Erfinder des Goal-Question-Metric-Modells, Victor R. Basili und David M. Weiss, als sie, in der Umgebung des Software-Engineering-Labors, des NASA Goddard Space Flight Center, an verschiedenen Flugdynamik-Projekten arbeiteten. Die Definition von Zielen (Goals) half ihnen, sich auf das Wesentliche und Wichtige zu konzentrieren. Das Aufschreiben von Fragen (Questions) erleichterte es, die Ziele genauer zu spezifizieren und hierdurch ließen sich gleichzeitig relevante Metriken (Metrics) ableiten. GQM war geboren und etablierte sich schnell als das Qualitätsmodell am Goddard Space Flight Center.

Das GQM-Modell beschreibt die Verfahrensweise zur Erstellung eines Qualitätsmodells, wobei sich das Modell in sechs Schritte unterteilen lässt:

1. Charakterisierung des Unternehmens- und Projektumfeldes, Erfassung des Mission Statement, Definition von Messzielen
2. Formulieren von Fragen zur genaueren Definition der Ziele
3. Messziele identifizieren und Metriken ableiten
4. Entwicklung von Mechanismen zur Datensammlung
5. Daten sammeln, analysieren und interpretieren
6. Erfahrungen zusammenfassen und anwenden

Kurz: „Der GQM-Prozess beginnt mit der Charakterisierung des Organisations- und Projektumfeldes. Unter Berücksichtigung des Umfeldes werden im zweiten Schritt Informationsbedürfnisse mittels Zielen und korrespondierenden Fragen erfasst. Anschließend werden im dritten Schritt Messungen dokumentiert, die der Quantifizierung dieser Informationsbedürfnisse dienen. Im vierten und fünften Schritt werden die Messungen durchgeführt und die resultierenden Daten interpretiert. Abschließend findet im sechsten Schritt eine Nachbereitung statt. Dabei werden beispielsweise die Qualitätsplanung und gewonnene Erkenntnisse gesichert.“

Die Literatur ist sich bei der Aufteilung der sechs Schritte allerdings nicht ganz einig. Daher stößt man bei der Recherche nach GQM auf verschiedenste Einteilungen und diverse unterschiedliche Bezeichnungen. Einig ist sich die Literatur nur darüber, dass es sechs Schritte sind und die Verfahren, die ihnen zu Grunde liegen, immer in der gleichen Reihenfolge angewendet werden. Die ersten drei Schritte des GQM-Modells werden häufig auch als Definitionsphase bezeichnet. In dieser Phase werden auch die Ziele (Goals), Fragen (Questions) und Metriken (Metrics) ermittelt, die dem GQM-Modell seinen Namen geben.

Ziele (Goals) identifizieren, was wir erreichen möchten; Fragen (Questions), sofern beantwortet, sagen uns, ob wir die Ziele erreichen, oder helfen uns, sie zu verstehen und zu interpretieren; und die Metriken (Metrics) identifizieren die Messungen, die nötig sind, um die Fragen (Questions) zu beantworten, und quantifizieren die Ziele (Goals). Die Ziele, Fragen und Metriken mit deren dazugehörigen Maßen, Schaubildern und sonstigen Ausweitungen, werden als GQM-Plan zusammengefasst. Dabei können mehrere Fragen einem Ziel und einer Frage mehreren Metriken zugeordnet werden. Anders gesagt: Die Beziehung zwischen „Zielen und Fragen“ und „Fragen und Metriken“ ist beide Male 1 zu n. Das gesamte GQM-Modell wird „Top-Down“ definiert, d. h., es ist ein zielorientierter Ansatz, der von den Zielen ausgehend nach unten Fragen und Metriken definiert. Die Analyse und Interpretation geschieht dann wiederum „Bottom-Up“, d. h. von unten nach oben.

In diesem ersten Schritt geht es darum, GQM-Ziele (goals) zu definieren. Es gibt zwei Arten von GQM-Zielen:

• Geschäftsziele (business goals)
• Messziele (measurement goals)

Geschäftsziele, gerne auch als Mission Statement bezeichnet, sind das übergeordnete Leitbild eines Unternehmens und definieren dessen langfristige Ziele. Ein Unternehmen definiert immer Geschäftsziele. Diese müssen identifiziert und als Fokus zur Erstellung von Messzielen verwendet werden. Ohne Geschäftsziele hätte die gesamte Messung keine Ausrichtung. Geschäftsziele treiben infolgedessen die Identifizierung von Messzielen an, wobei sich Geschäftsziele und Messziele nicht zwangsläufig voneinander unterscheiden müssen, daher wird im Folgenden nur noch von GQM-Zielen gesprochen.

Jedes GQM-Ziel sollte durch fünf Aspekte ausgedrückt werden:

• Objekt der Messung
• Zweck
• Qualitätsfokus
• Blickwinkel
• Kontext

Objekt der Messung festlegen bedeutet herauszufinden, worüber man mehr erfahren möchte: „Was möchte man messen?“ GQM erlaubt es, verschiedenste Objekte zu untersuchen. Dies könnten verallgemeinert gesagt Prozesse, Produkte, Ressourcen, Projekte etc. sein, um nur einige Beispiele zu nennen.

Zweck festlegen bestimmt, was erreicht werden soll. Beispiele hierfür wären Charakterisierung, Verbesserung, Überwachung, Auswertung, Vorhersage oder Optimierung.

Qualitätsfokus festlegen: Der Qualitätsfokus ist ein Element des Messziels. Die folgenden Beispiele zeigen eine große Auswahl an Qualitätsattributen:

• Zuverlässigkeit/Verfügbarkeit
• Benutzbarkeit
• Sicherheit
• Funktionale Sicherheit
• Skalierbarkeit
• Wartbarkeit
• Anpassbarkeit
• Time to Market
• Performance
• Effizienz
• Portabilität
• Schnittstellenkompatibilität

Blickwinkel festlegen: Dies ist die Perspektive, von der das Messobjekt betrachtet wird, wobei dies in der Regel der Kunde, der Entwickler, der Tester, der Projektleiter oder der Vertragsnehmer ist.

Kontext festlegen: Hier wird bestimmt, in welchem Zusammenhang das Messobjekt steht. Der Kontext sollte möglichst genau erläutert werden, wobei es sich anbietet, Angaben über Firma, Abteilung, Projekt und Zeitraum zu machen.

Die Definition der GQM-Ziele kann mit folgendem Hilfssatz dargestellt werden:

Analysiere den Entwicklungsprozess
zum Zwecke der Änderung
in Bezug auf Korrektheit
vom Blickwinkel des Entwicklers
im Kontext des Projekts X.

Das Sammeln der Ziele kann auf verschiedene Arten und Weisen passieren. Die meistverbreiteten Methoden sind Workshops und Interviews. Wichtig ist hierbei, dass Ziele von den verschiedensten Prozessbeteiligten erhoben werden, um ein möglichst breites Spektrum zu erhalten. Die Ziele selbst werden in einem sogenannten Abstraction Sheet dokumentiert. Häufig werden mehrere Abstraction Sheets in einem GQM-Plan festgehalten, die dann vor der weiteren Bearbeitung mit Prioritäten versehen werden. Der GQM-Plan ist das Dokumentationswerkzeug der Goal Question Metric. Der Aufbau ist einfach. Er beginnt mit einer thematischen Einleitung passend zum definierten Ziel. Anschließend werden Fragen, mit den jeweils dazugehörigen Metriken niedergeschrieben. Die nachfolgende Vorlage kann bei der Fertigung eines GQM-Plans helfen.

Q.1 Frage1
M.1.1 Metrik1
M.1.2 Metrik2
Q.2 Frage2
M.2.1 Metrik1
M.2.2 ...
Q.3 ...

Abstraction Sheets werden genutzt, um einem GQM-Ziel wichtige Informationen zuzuordnen, bzw. sie mit dem GQM-Ziel zu gruppieren. Es können parallel mehrere Abstraction Sheets existieren. Das Sheet ist in fünf Teile aufgeteilt:

• Die fünf Aspekte (Objekt der Messung, Zweck, Qualitätsfokus, Blickwinkel, Kontext) drücken aus, zu welchem GQM-Ziel das Sheet gehört.
• Qualitätsfaktoren beziehen sich unmittelbar auf das GQM-Ziel. Um sie herauszufinden, sollte man sich die Frage stellen: „Welche Faktoren müssen bei diesem GQM-Ziel betrachtet werden und welche beeinflussen es?“
• Die Hypothese ist die geschätzte, bzw. erwartete Antwort auf die definierten Qualitätsfaktoren.
• Einflussfaktoren beziehen sich wiederum direkt auf die Qualitätsfaktoren: „Was beeinflusst die Qualitätsfaktoren?“
• Einflüsse auf die Hypothesen werden im letzten Abschnitt des Sheets festgehalten: „Wie beeinträchtigen die Einflussfaktoren die Hypothesen?“

In dieser Phase des Modells werden Fragen (questions) gestellt, die sich aus den Abstraction Sheets ableiten. Für jede festgehaltene Komponente eines Abstraction Sheets lässt sich in der Regel auch eine Frage formulieren. Das Beantworten dieser Fragen hilft somit, dem Ziel (goal) näher zu kommen. Um Fragen zu definieren, sollte man zunächst ermitteln, was man über die Eigenschaften im Qualitätsfokus des Ziels lernen möchte. Hierbei sollten folgende Punkte beachtet werden:

• Übereinstimmung mit dem Ziel
  Die Fragen dürfen einzig den Zweck und den Blickwinkel widerspiegeln.
• Quantifizierbarkeit
  Die Fragen müssen so formuliert werden, dass sie über Messwerte beantwortet werden können. Also nicht „Welche Testfälle wären in diesem Kontext gut?“, sondern „Welche Testfälle haben die meisten Fehler gefunden?“. Kompliziertere Fragen sollten in mehrere einfache Fragen unterteilt werden.
• Bedeutung der Antwort
  Es muss geklärt werden was mit der Antwort auf diese Frage getan werden kann und was mögliche Maßnahmen sind, um das entsprechende Ziel zu erreichen. Wenn die definierte Frage zu keinen verbesserten Handlungen führt, sollte die Notwendigkeit der Frage noch mal überdacht werden.
• Verständliche Diagramme
  Es muss klar sein, was auf den Achsen des Diagramms dargestellt wird, welche Analyse der Darstellung vorausgeht und welche Daten ausgeschlossen wurden.
• Benutzung von bekannten Diagrammtypen
  Bei der Auswahl der Diagrammarten sollte wann immer möglich, auf bekannte (zum Fragentyp passende) Diagramme zurückgegriffen werden.
• Kosten/Nutzen
  Es ist zu evaluieren, ob der Nutzen, den man sich aus der Beantwortung der Frage verspricht, die Kosten der Datensammlung aufwiegt.
• Klarheit der Begriffe
  Es sollte sichergestellt sein, dass Begriffe wie Qualität, Effektivität, Effizienz oder Zuverlässigkeit präzise definiert sind.
• Vernünftige Anzahl von Fragen
  Erfahrungen aus erfolgreich durchgeführten Messprogrammen zeigen, dass drei bis sieben Fragen pro Ziel definiert werden sollten.
• Gutes Verhältnis zwischen Qualitäts- und Einflussfaktoren
  Es sollte durch die Frage „Was beeinflusst diesen Qualitätsaspekt“ überprüft werden, ob es wichtige Einflüsse gibt. Jedoch sollten nicht mehr als etwa dreimal so viele Einflussfaktoren wie Qualitätsfaktoren definiert sein, da man letztendlich an Letzteren interessiert ist.

Dieser Schritt baut auf den Vorherigen auf und versucht, mit Hilfe der zuvor ausgearbeiteten GQM-Ziele, Metriken (metrics) abzuleiten. Wichtig ist insbesondere, die passende Metrik zu der gestellten Frage zu finden, was sich oftmals als einfacher herausstellt, als zuvor gedacht. Als besonders geeignet stellen sich folgende Maße, bzw. Metriken und die sich daraus ergebenden Maße, heraus:

• Depth of Inheritance Tree (DIT)
• Number of Children of a Class (NOC)
• Response for a Class (RFC)
• Weighted Methods per Class (WMC)
• Coupling between Object Classes (CBO)
• Lack of Cohesion of Methods (LCOM)
• Constructive Cost Model I+II (COCOMO I+II)
• Halstead-Metrik
• McCabe-Metrik (zyklomatische Komplexität)
• Lines of Code (LOC)
• Function-Point-Verfahren
• Fehlerdichte
• Schwierigkeitsgrad

In diesem Arbeitsschritt wird beschrieben, wie die Daten und Maße zu erfassen sind, die für den GQM-Plan notwendig sind. Man spricht auch von der Erstellung eines Messplans. Folgende Punkte sollten mit Hilfe des Messplans abgedeckt werden:

• Formale Definition der Messungen
• Schriftliche Abfassung der Messungen
• Alle Output-Werte der Messungen
• Die Person oder Rolle, die die Messungen durchführt
• Der Zeitpunkt, wann die Messungen durchgeführt werden
• Das Medium (Werkzeug oder Fragebogen), das benutzt wird, um die Messungen durchzuführen

Für die gesamte Datenerhebung und -messung gilt, dass Personen, die Messungen durchführen, bzw. Daten sammeln, speziell geschult werden müssen. Dies ist notwendig, damit die Datensammlung gültig, einheitlich und vergleichbar ist. Nach diesem Schritt liegen Rohdaten, oder auch Primärdaten genannt, vor. Sie erhalten diesen Namen, da sie noch in keiner Weise aufbereitet wurden und in dieser Form noch nicht repräsentativ sind.

Der Messplan beinhaltet, wie Rohdaten am effizientesten erhoben werden und an wen sie zur Bearbeitung weitergegeben werden. Er wird definiert durch die Metriken, die zuvor ausgewählt wurden. Er handelt die Vorgehensweise während der Messung ab, welche Rohdaten wie erhoben werden müssen.

In diesem Schritt werden die zuvor im Messplan festgelegten Rohdaten gesammelt. Dieser Schritt beschreibt nun, auf welche Art die Rohdaten erfasst werden. Die Hauptarbeit ist dennoch nicht die Erhebung der Rohdaten, sondern die Analyse und Interpretation der Rohdaten, so dass man am Ende dieses Schrittes aufbereitete Daten, sogenannte Sekundärdaten, erhält. Man kann Rohdaten mit Hilfe verschiedener Verfahren erfassen:

• Fragebögen
• Datenblätter
• Interviews
• Beobachtung
• Automatisierte Tools

Fragebögen können halbautomatisch über ein Webfrontend im Inter- oder Intranet abgefragt werden oder klassisch über Papierbögen. Mit Fragebögen lassen sich idealerweise Erfahrungen, Wahrnehmungen und Gefühle erfassen.

Datenblätter können ebenfalls halbautomatisch oder klassisch abgefragt werden. Der Unterschied zu Fragebögen liegt darin, dass sie statischer und technischer sind. Sie können also viel exakter technische Maße aufnehmen.

Interviews sind Besprechungen mit einer oder mehreren Personen. Interviews sind dynamischer als vorige Methoden, da neben den vorgegebenen Fragen auch noch zusätzlicher Input gesammelt werden kann. Der Aufwand ist zwar größer, dies kann sich aber lohnen.

Beobachtung bedeutet, dass eine speziell geschulte Person (der Beobachter) am Entwicklungsprozess im Unternehmen teilnimmt. Der Beobachter observiert einen definierten Prozess oder eine Aktion eines Prozesses wie beispielsweise die Erstellung von Berichten oder die Zusammenarbeit im Team. Die Beobachtung kann, je nach Prozessgröße, einige Wochen bis hin zu Jahren dauern. Die Ergebnisse dieser Methode werden in einem Logbuch festgehalten.

Automatisierte Tools können nicht immer verwendet werden, machen aber die Arbeit leichter und schneller. Besonders wird die automatische Datenerhebung bei allen Prozessen verwendet, deren Output (z. B. Quellcode) bereits in elektronischer Form vorliegt.

Unabhängig vom verwendeten Verfahren müssen die erfassten Rohdaten validiert und aufbereitet werden, bevor sie zur Analyse verwendet werden können. Validieren bedeutet in diesem Zusammenhang nicht nur das reine Überprüfen der Rohdaten auf Korrektheit, sondern auch das Kontrollieren auf Vollständigkeit und Konsistenz. Es kommt immer wieder vor, dass in den Rohdaten Ausreißer vorhanden sind. Ausreißer sind Werte, die von den restlich erhobenen Werten stark abweichen. Diese müssen aufgespürt werden, i. d. R. automatisiert, und entfernt werden, da sie sonst das Messergebnis verfälschen würden.

Sobald valide Rohdaten vorliegen beginnt der Abschnitt der Analyse. Die Datenanalyse ist nötig, um Messergebnisse zu erhalten. Die validierten und analysierten Messergebnisse helfen dann wiederum, die Messziele (oder GQM-Ziele) anzutreiben und Verbesserungen einzuleiten. Hier erkennt man auch sehr gut die Bottom-Up Interpretation des GQM-Modells.

In diesem letzten Arbeitsschritt des GQM-Modells werden alle zuvor gewonnenen Ergebnisse zusammen mit einer Beschreibung gebündelt. Es gibt hier wiederum zwei Arten der Ergebnisbündelung:

• Messergebnisse
• Lessons Learned

Messergebnisse in Form von validierten und analysierten Daten liegen mit dem Abschluss des dritten Schritts vor. Diese werden hier nochmals zusammengefasst und stehen zur weiteren Bearbeitung zur Verfügung.

Lessons Learned ist eine komprimierte Sammlung von Erfahrungen, Entwicklungen, Hinweisen, Fehlern, Risiken etc., die während eines Prozesses gemacht wurden. Man bündelt sie in Lessons Learned zusammen, um sie zu einem späteren Zeitpunkt in einer ähnlichen Situation, bzw. für eine gleiche Problemstellung nochmals verwenden zu können. Im Gegensatz zu den Messergebnissen sind Lessons Learned eher eine qualitative Auswertung.

Das Goal-Question-Metric-Modell ist ein Qualitätsmodell zur Sicherung und Verbesserung der Qualität von Prozessen, welches von Dr. Victor R. Basili entwickelt wurde. GQM ist nicht auf einen bestimmten Prozess spezialisiert, sondern vielseitig einsetzbar. Es hilft technische, wie auch personenbezogene Prozesse zu analysieren. Weiterhin handelt es sich um ein zielorientiertes Modell, das in sechs Schritten aufgebaut ist. Die ersten drei Schritte nennen sich auch „Definitionsphase“. In der Definitionsphase werden zunächst die Ziele (goals) definiert, die erreicht werden sollen. Fragen (questions) helfen die Ziele besser zu spezifizieren und Metriken (metrics) werden definiert, um den Prozess messbar zu machen. Die letzten drei Schritte werden auch „Interpretationsphase“ bezeichnet. In dieser Phase wird ein Plan erstellt, der beschreibt, wie die nötigen Messdaten, für die in der Definitionsphase festgelegten Metriken, eingeholt werden. Mit Hilfe des Plans werden die Rohdaten erfasst, anschließend validiert und analysiert. Zum Schluss werden die gemachten Ergebnisse festgehalten, um sie nochmals anwenden zu können und Verbesserungsmaßnahmen einzuleiten. Ein Zusammenschrift der Ergebnisse in Form von „Lessons Learned“ ist ebenfalls eine gängige Maßnahme.

• V. R. Basili, H. D. Rombach: The TAME project. Towards improvement-oriented software environments. In: IEEE Transactions on Software Engineering. Band 14, Nr. 6, 1988, S. 758–773, doi:10.1109/32.6156. 
• Victor Basili, Adam Trendowicz, Martin Kowalczyk, Jens Heidrich, Carolyn Seaman, Jürgen Münch, Dieter Rombach: Aligning Organizations Through Measurement: The GQM+Strategies Approach. Springer International Publishing, 2014, ISBN 978-3-319-05046-1, doi:10.1007/978-3-319-05047-8. 
• Reiner Dumke: Software Engineering. Eine Einführung für Informatiker und Ingenieure: Systeme, Erfahrungen, Methoden, Tools. Band 4, 2003, S. 234. 
• Helmut Balzert: Lehrbuch der Softwaretechnik: Softwaremanagement. Spektrum Akademischer Verlag, 2008, ISBN 978-3-8274-1161-7
• Rini van Solingen und Egon Berghout: Goal/Question/Metric Method. McGraw-Hill Publishing Company, 1999, ISBN 978-0-07-709553-6
• Christ Ebert, Reiner Dumke: Software-Metriken in der Praxis. Springer-Verlag Berlin Heidelberg New York, 1996, ISBN 3-540-60372-7, S. 28–34. 

• Victor R. Basili, Gianluigi Caldiera, H. Dieter Rombach: The Goal Question Metric Approach. In: Encyclopedia of Software Engineering. John Wiley & Sons, 1994, S. 528–532 (umd.edu [PDF; 404 kB]). 
• Danilo Assmann, Ralf Kalmar, Teade Punter: Handbuch: Messen und Bewerten von Webapplikationen mit der Goal/Question/Metric Methode. Handbuch. 2014, Fraunhofer-Gesellschaft, (PDF; 2,74 MB).