Der smarte GQM-Editor

Dieser Text richtet sich an Studierende der Informatik, die das Thema GQM und Abstraction Sheets vertiefen wollen und gerenell an Interessenten bezüglich GQM. In diesem Text werden Hintergrundinformationen in der Farbe grün und Anweisungen bezüglich des smarten GQM-Editors in blau dargestellt.
 
Der smarte GQM-Editor wurde auf der SEUH 2013 in Aachen vorgestellt. Hier ist ein Link zum PDF-Paper.
 
Bei Fragen zu GQM und dem smarten GQM-Editor helfe ich gerne weiter. Über Anmerkungen und konstruktive Kritik freue ich mich!
 
Raphael Pham (mail),
http://www.se.uni-hannover.de/pages/en:mitarbeiter_raphael_pham

Motivation des GQM Ansatzes

GQM ist eine Methode, um zielgerichtet einen Mess- und Verbesserungsprozess durchzuführen. Vermessen oder verbessert werden können Eigenschaften von Produkten oder Prozessen. 

[Beispiele für Produkte im Software Engineering sind dabei: Z.B. Produzierter Code oder die eingesetzte Test Suite. Zu verbessernde Prozesse könnten sein: Testprozess muss schneller werden; Debugging muss effizienter werden.] 

Möchte man nun etwas verbessern, so wird man um die Aktivität des Messens nicht herumkommen: Idealerweise misst man zu Anfang des Verbesserungsvorhabens und stellt damit fest, wie der Ausgangszustand war. Hat man Verbesserungsmaßnahmen umgesetzt, so misst man nochmal und vergleicht die Ergebnisse - so kann man die Wirkung der Verbesserungsmaßnahmen quantifizieren bzw. sichtbar machen. Die Aktivität des Messens birgt jedoch gewisse Fallstricke: Zum einen braucht man eine Metrik, die sich überhaupt auf den eigenen Fall anwenden lässt. Zum anderen muss man die "richtige" Metrik wählen. Die Metrik ist das Maß, mit dem wir eine Eigenschaft messen wollen. Bei simpleren (sprich: konkreteren) Eigenschaften, wie z.B. der Länge einer Java-Klasse, scheint es einfach, die richtige Metrik zu finden. 

[Die Eigenschaft "Länge einer Java-Klasse" lässt sich zum Beispiel mit dem Maß "Anzahl der Zeilen der Java Klasse" messen. Vielleicht ist aber auch "Anzahl der Methoden" besser geeignet? Was ist eigentlich mit "Länge einer Java-Klasse" hier ganz genau gemeint?] 

Meist interessieren uns aber Eigenschaften unser Produkte oder Prozesse, die eben nicht so einfach gestrickt sind. Welche Metrik (welches Maß) wenden wir an, wenn wir z.B. die Bedienbarkeit unserer GUI oder die Testbarkeit unserer Plugins messen wollen? Diese Ziele sind abstrakter - wir müssen die Metriken hier mit Bedacht wählen. Wenn wir Metriken nehmen, die wir gerade zur Hand haben oder einfach zu erheben sind, erhalten wir am Ende Ergebnisse deren Aussagen wir nicht ausreichend interpretieren können und die uns nicht weiterbringen. Genau an dieser Stelle setzt GQM an: Wir wollen Ziele messen, die für unser Projekt individuell sind - darum sollte auch die Auswahl (bzw. die Erstellung) der anzuwendenden Metrik an dieses Ziel angepasst werden. Einfach auf gut Glück oder auf Verdacht die alt-bekannten Metriken zu verwenden führt meist zu Frust. GQM ist damit ein Top-Down-Ansatz: Von abstrakten Zielen konkretisieren wir auf individuell-zugeschnittene Metriken. 

[Im Gegensatz dazu steht der Bottom-Up-Ansatz: Mit bereits vorhandenen Metriken die abstrakten Ziele messen.] 

Grob gesagt, funktioniert GQM folgendermaßen: Das abstrakte Ziel wird auf genauere Unterziele heruntergebrochen (GOAL). Zu einem solchen Unterziel werden Fragen erarbeitet, mit denen man beantworten kann, in wie weit dieses Unterziel schon erreicht worden ist (QUESTION). Die Antwort dieser Fragen werden mit der passenden Metrik gemessen (METRIC). Daraus ergibt sich der Name des Ansatzes: Goal --> Question --> Metric. Bei Anwendung des GQM-Ansatzes muss man nicht zwangsläufig eine neue Metrik auf die Beine stellen. Grundsätzlich sind ja bereits existierende Metriken nicht schlecht und bei jeder Metrik müsste man das Rad neu-erfinden. GQM hilft eher dabei, gezielt die richtigen Fragen zu stellen, um die am besten geeignete Metrik oder Kombination aus existierenden Metriken zu finden. 

[Können die gefundenen Fragen von den existierenden Metriken nicht bedient werden, so kann man aber durchaus neue Metriken aufstellen.]

Einführung zu GQM: Ein Beispiel

In diesem Beispiel unterstützen wir die Firma FunGate bei der Entwicklung einer Taschenrechner-App. FunGate entwickelt die Taschenrechner-App Calculator agil, d.h., FunGate spricht sich häufig mit dem Kunden ab, validiert bereits umgesetzte Features und pflegt neu-aufgekommene Kundenwünsche flexibel ein. Nun ist der aktuelle Kunde sehr änderungsfreudig und FunGate möchte noch flexibler werden in seinem Entwicklungsprozess.

Erste Etappe GOAL

Der Qualitätsagent von FunGate beginnt mir der ersten Etappe von GQM und stellt einen groben Zielbaum auf:
 
Oben kommt das abstrakteste Ziel hin, dieses wird in Unterziele verfeinert. 
 
Messen und Ergebnisse interpretieren ist aufwändig, deswegen können nicht alle Unterziele können weiterbearbeitet werden. Man priorisiert die Unterziele. Ein ausgewähltes Unterziel wird nun hergenommen und in eine Zielfacette gesteckt: Der GQM-Anwender muss sich an dieser Stelle Gedanken um wichtige Eigenschaften des Ziels machen - so vergisst man diese nicht. Was ist der eigentliche Betrachtungsgegenstand und aus welcher Perspektive muss man ihn betrachten?
 
Die Unterziele werde in Zielfacetten eingefügt - neue Sichtweisen entstehen.
 
Hier können Eigenschaften von Unterzielen auftauchen, an die man nicht gedacht hat - die jedoch auch wichtig sind. So muss man an das Unterziel G2.1a unterschiedlich rangehen - je nachdem, ob man es aus der Sicht eines Entwicklers oder Benutzers betrachtet. Die Zielfacette macht auch deutlich, "wo" sich der abstrakte Teil des Messziels versteckt: Der sogenannte Qualitätsaspekt bezeichnet diejenige Eigenschaft des Betrachtungs-gegenstandes, die verbessert werden soll. Der Qualitätsaspekt wird auch kurz Q-Aspekt genannt.

Zweite Etappe QUESTION (Abstraction Sheet)

 

[FunGate stellt für die folgenden Schritte ein neues Webtool zur Verfügung: den smarten GQM-Editor. Du kannst ihn aufrufen unter: 

smarter GQM-Editor 

Melde dich mit einem Benutzernamen an; deine eingetragenen Werte kannst du auch dort speichern und später aufrufen.] 

Ein solche Unterziel (als Zielfacette) wird nun in die zweite Etappe von GQM (QUESTION) übernommen und in den Kopf eines Abstraction Sheets eingetragen. Das Abstraction Sheet bietet dem Anwender eine streng definierte Struktur um die Fragen zu einem gegebenen Messziel abzuleiten, die beantworten, wie nah man schon an das Ziel herangekommen ist.  

Ein leeres Abstraction Sheet mit eingetragener Zielfacette.

Das Abstraction Sheet ist in vier Quadranten eingeteilt. Die Ausfüllreihenfolge der Quadranten bildet ein U. Jeder Quadrant verlangt vom Anwender, sich Gedanken über den noch abstrakten Q-Aspekt zu machen und sich klarzumachen, was dieser genau bedeutet. Dies ist der wichtigste Schritt des GQM-Ansatzes: Im Abstraction Sheet muss der Anwender genau angeben, was er genau unter diesem Q-Aspekt verstehen will. 

[Wenn der Q-Aspekt vor der Messung nicht genau definiert wird -- und man nur mit einem grobem Verständnis von z.B. Testbarkeit im Kopf anfängt zu messen -- merkt man am Ende mglw., dass man von falschen Voraussetzungen ausgegangen ist.]

Ein vollausgefülltes Abstraction Sheet.

1.Quadrant oben, links: Der abstrakte Q-Aspekt wird auf *konkrete* (am besten: messbare) Eigenschaften des Betrachtungsgegenstandes konkretisiert, sogenannte Qualitätsfaktoren oder Q-Faktoren. Welche Merkmale machen den Q-Aspekt in diesem Projekt ganz konkret aus? 

[In unserem Fall ist mit der "Dokumentation" (abstrakter Q-Aspekt) von "Änderungen" (Gegenstand) genau gemeint: Dass überhaupt Commit-Nachrichten geschrieben werden und dass diese auch beschreiben, was in dem Commit verändert wurde.] 

2. Quadrant unten, links: Zu jedem Q-Faktor wird eine sogenannte Ausgangshypothese aufgestellt, die erklärt, wie es zu Messbeginn um den Q-Faktor steht. So ist hinterher klar, wie schlecht es vorher tatsächlich gewesen ist. Hier sollten am besten genaue Werte eingetragen werden - notfalls sind Vermutungen auch in Ordnung.

[Wie oft kommt es denn gerade vor, dass keine Commit-Nachrichten geschrieben werden? Und wie oft haben Commit-Nachrichten nichts mit den eigentlichen Änderungen zu tun?]

3. Quadrant unten, rechts: Jetzt weiß man, was man genau unter dem Q-Aspekt versteht und wie es darum steht. In diesem Schritt stellt man eine Vermutung auf, wie die konkreten Q-Faktoren beeinflusst werden können. Das ist die sogenannte Einflusshypothese. Dieser Schritt erfordert Hintergrundwissen und etwas Denkarbeit.

[Wir vermuten, dass die Anzahl der Änderungen in einem Commit Einfluss auf die Vollständigkeit der Commit-Nachricht haben könnte!]

4. Quadrant oben, rechts: Aus den Einflusshypothesen können nun leicht die konkreten Faktoren extrahiert werden, die Einfluss auf unsere Q-Faktoren haben - wir haben sie gerade in den Einflusshypothesen erwähnt. Wenn unsere vermutete Einflusshypothese stimmt, dann können wir die definierten Q-Faktoren verbessern, indem wir diese Einfluss-Faktoren verbessern. Damit wird auch klar, warum das Aufstellen der Einflusshypothese wichtig ist: Sie stellt den vermuteten Zusammenhang zwischen Q-Faktor und Einflussfaktor her. 

Im vierten Quadranten stehen nun die Faktoren, die Einfluss auf die definierten Q-Faktoren haben. An diesen Einflussfaktoren kann man die gesuchten Fragen ableiten: "Wie steht es um den Einflussfaktor 'Anzahl der Änderungen in einem Commit'? Welche Werte nimmt dieser Einflussfaktor in meinem Projekt an? Und wie beeinflusst das dann meinen Q-Faktor 'Bezug zu gemachten Änderungen'?"

[Unter der Voraussetzung, dass die getroffene Einflusshypothese stimmt ("Der Q-Faktor wird durch den Einflussfaktor beeinflusst.", dritter Quadrant), kann man mit den Antworten auf diese Fragen abschätzen, wie es um den Q-Faktor bestellt ist. Da der Q-Faktor den abstrakten Q-Aspekt des Messziels definiert, weiß man, wie gut man das Ziel erreicht hat.]

[Hat man das Abstraction Sheet abgeschlossen, muss der nächste Schritt manuell erfolgen und wird noch nicht halb-automatisch unterstützt. Hat man die nächste Etappe METRIC mit einer passenden Metrik beendet, kann man auf "Weiter zur Messplanübersicht" klicken.]

 

Dritte Etappe METRIC

Als Q-Faktor haben wir nun definiert 'Anzahl der Änderungen in einem Commit' und als Question dazu haben wir erhalten "Welche Werte nimmt dieser Einflussfaktor in meinem Projekt an?". Jetzt brauchen wir eine Metrik (ein Maß), um die Antwort auf diese Frage messen zu können: Wie soll die 'Anzahl der Änderungen in einem Commit' gezählt werden? Wir müssen die Anzahl der Änderungen in den Commits zählen - da wir eine allgemeine Aussage über unser Commitverhalten treffen wollen, ist es ratsam mit Durchschnittswerten zu arbeiten und Commits aus verschiedenen Projekten zu berücksichtigen. Dafür bieten sich aktuelle Projekte von FunGate an - wir sind nämlich daran interessiert zu wissen, wie es *gerade* bei FunGate aussieht und nicht, wie es vor fünf Jahren war. Mit etwas Denkarbeit ergibt sich als Metrik: Durchschnittliche Anzahl der Änderungen in den Commits der letzten drei aktuellen Projekte von FunGate.

[Nicht immer ist die Metrik so offensichtlich aus dem Einflussfaktor herauszulesen. Den Einflussfaktor 'Sensibilisierung der Entwickler' auf die Wichtigkeit von Commit-Messages könnte man z.B. mit der Anzahl der Schulungen zu diesem Thema quantifizieren. Die ausgewählte Metrik soll so genau wie möglich den Einflussfaktor zählbar machen - dazu ist hier etwas Denkarbeit verlangt. Wichtig ist aber: Es muss etwas ausgewählt werden, das konkret ist und das man überhaupt (und einfach) zählen kann! Wählt man etwas abstraktes - wie z.B. 'Verständnis des Problems' -- so ist nichts gewonnen; diese Metrik lässt sich nicht praktisch anwenden.]

Vierte Etappe MEASUREMENT SCHEME (Messplan)

Nun wissen wir, dass wir den abstrakten Q-Aspekt 'Dokumentation' der Änderungen im Quellcode durch 'Anzahl der Änderungen in einem Commit' bezeichnen wollen und diese Änderungen mit der obigen Metrik (s. dritte Etappe) messen möchten. Mit dem Messplan dokumentieren wir nun, wie das ganz konkret gemessen werden soll - wir erstellen einen Vorgehensplan mit Struktur. Die Idee ist folgende: Wir wenden die gefundene Metrik an und erhalten verschiedene Werte für den Einflussfaktor (den sollte die Metrik ja messen).
[In diesem Fall erhalten wir verschiedene Werte für die Anzahl der Änderungen in Commits in den Projekten von FunGate.]
Anschließend wird geprüft, ob der betroffene Q-Faktor bei diesen verschiedenen Ausprägungen des (vermuteten) Einflussfaktors auch wirklich andere Werte annimmt - und ob diese Werte sich verbessern, oder verschlechtern.
 
[In der Messplanübersicht sucht man aus, welches Q-Faktor-Einflussfaktor-Paar man mit  einer Metrik und einem Messplan messen will. Wenn die ausgesucht Metrik auch gleich den anderen Q-Faktor und Einflussfaktor mitmisst, kann man hier auch Faktoren kombinieren.]
 
 
Die Übersicht über die gefundenen Q- und Einflussfaktoren als Paare.
 
Anschließend sieht man, dass zuerst die rechte Seite bearbeitet werden soll - die linke Seite ist noch nicht freigegeben. Das liegt daran, dass man zuerst die möglichen Ausprägungen für den Einflussfaktor erarbeiten muss, um anhand dieser dann die beeinflussten Werte für den Q-Faktor zu ermitteln. Da Q-Faktor und Einflussfaktor nicht Plätze tauschen sollten, muss man hier also mit der rechten Seite anfangen. 
 
Der leere Messplan - man sollte mit der rechten Seite anfangen.
 
Der Messplan ist in vier Teile eingeteilt: Q-Faktor und Einflussfaktor sind gegeben. In das Feld Fragen lassen sich die gefundenen Questions eintragen. Im Messplan/Metrik-Teil gibt man schrittweise Anweisungen, wie die gefundene Metrik aus der dritten Etappe umgesetzt werden soll: Was ist genau zu tun, um den Metrik-Wert zu erhalten. Im letzten Teil trägt man die verschiedenen gefundenen Werte bzw. Ausprägungen ein. Ausprägungen von Einflussfaktoren sind den zugehörigen Werten für den Q-Faktor gegenüberstellt.
 
Ein ausgefüllter Messplan. 
 
Damit ist die Vorbereitung für eine GQM-Messung abgeschlossen: Das abstrakte Messziel wurde durch konkrete Q-Faktoren greifbar gemacht und Einflussfaktoren gefunden. Der Zusammenhang zwischen diesen beiden Faktoren wurde mit einer Einflusshypothese festgehalten. Geeignete Fragen, die uns zeigen, wie es um den Q-Faktor und den Einflussfaktor steht, wurden aufgestellt. Mit diesen Fragen lies sich passende Metrik finden und mit dieser Metrik konnte ein konkreter Messplan aufgestellt werden.