Jede Software hat eine Architektur!

Metriken und Queries in Sonargraph

In Sonargraph wird zwischen zwei verschiedenen Analysetypen unterschieden. Metriken analysieren den Quellcode und zeigen optimierbare Stellen im Quelltext an. Diese können direkt in Sonargraph eingesehen werden. Queries hingegen sind Abfragen auf die mit Qualitätszahlen gefüllte Datenbank und haben eher Berichtcharakter.

Metriken werden im Tab METRICS ausgewertet (Abb. 1). Dabei wird pro Metrik der Scope (metric level) unterschieden (Standard ist die system-, verzeichnis- und dateiweite Betrachtung. Insgesamt gibt es 22 metric levels). Für jeden metric level können Schwellenwerte angegeben werden, d. h. die zulässige Mindest- und Maximalwerte einer Metrik. Werden für eine Metrik diese Schwellenwerte verletzt, wird dies entsprechend kenntlich gemacht. Es sind bereits viele Standardmetriken voreingestellt, diese lassen sich nach Bedarf beliebig verändern. Im Konfigurationsmenü kann die Auswertung angepasst werden. Um die Verteilung der eingesetzten Metriken und Queries zu vereinfachen, werden alle Metriken in einem Qualitätsmodell gespeichert. Dieses ist wie ein Profil zu verstehen und enthält alle ausgewählten Metriken mit den dazugehörigen Einstellungen. So können je nach Projektanforderung Vorlagen erstellt werden, die nur die wichtigsten und relevanten Metriken enthalten.

Eine besondere Rolle nimmt die Metrik #in_cycles in Sonargraph ein. Es gibt eine eigene Ansicht, um Zyklen zu analysieren und darzustellen. Dabei wird zwischen drei Kategorien (Logical, Package und Physical) und vier Ebenen (Build Unit, Directory, Physical und Source File) unterschieden. In unserem Beispiel haben wir einen einfachen Zyklus zwischen zwei Klassen eingebaut: Profile <-> User (Abb. 4). Der Zyklus kann z. B. durch Entfernen der Referenz von User auf Profile aufgelöst werden.

Abb. 4: Cycles View. (Vergrößern)

Auf die Prozesse kommt es an

Ein Tool anzuwenden und Maßnahmen abzuleiten ist eine Sache, aber wie kann sichergestellt werden, dass auch nachhaltig Verbesserungen herbeigeführt werden? Im Team muss es als natürlicher Vorgang empfunden werden, sich über Architektur- und Softwarequalität Gedanken zu machen, um den maximalen Nutzen zu erhalten. Am besten kann dies durch ständige Wiederholung und Überprüfung erreicht werden. Hierfür lohnt es sich, einen Prozess zu definieren, der in das übliche Projektmanagementmodell (z. B. Scrum, Kanban, Wasserfall) mit eingebettet wird. Dies kann z. B. bedeuten, zu Beginn jedes Sprints die aktuellen Zahlen zu interpretieren und daraus bei Bedarf Maßnahmen für den Sprint abzuleiten oder zumindest im Backlog festzuhalten. Bei einem Wasserfall-Vorgehen kann z. B. zur Erfüllung von Meilensteinen vereinbart werden, eine Qualitätsanalyse durchzuführen, deren Ergebnis die Einhaltung der vereinbarten Regel beweist.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.