Neuauflage Software Metriken

Softwaremetriken sind Maßzahlen, die Quantität, Komplexität und Qualität von Software messbar machen, von Anforderungen über Architektur und Code bis hin zu Testergebnissen. Sie dienen der Projektsteuerung, Aufwandsschätzung und Qualitätssicherung. Ohne sie bewegt sich ein Projekt wie ein Auto ohne Tacho, Tankanzeige und Navi.

Das Wichtigste in Kürze

• Softwaremetriken werden in der Praxis trotz ihres klaren Nutzens noch immer zu selten eingesetzt, obwohl schon einfache Maßzahlen wie Fehlertrends oder Testfallanzahlen die Projektsteuerung erheblich verbessern.
• Einzelne Metriken liefern erst dann belastbare Aussagen, wenn man sie zueinander in Beziehung setzt: Zehn Testfälle für 500.000 Lines of Code zeigen sofort, dass das Verhältnis nicht stimmt.
• Softwaremetriken lassen sich nicht nur auf Code anwenden, sondern genauso auf Anforderungsdokumente, Architekturentwürfe und Testergebnisse, was die meisten Projekte völlig ungenutzt lassen.
• Wer historische Fehlerdaten mit geschätzten Testfallzahlen kombiniert, kann Fehlermengen für spätere Projektphasen erstaunlich genau vorhersagen, wie ein Projektbeispiel mit plus/minus zehn Prozent Abweichung zeigt.
• Den Einstieg in Metriken muss man nicht mit komplexen Formeln beginnen: Eine schlichte Liste aus Geschäftsvorfall, Komplexitätsstufe und erwarteter Testfallanzahl reicht aus, um einen ersten soliden Planungswert zu erzeugen.

Warum Softwaremetriken oft stiefmütterlich behandelt werden

Softwaremetriken werden in vielen Projekten kaum genutzt, obwohl Softwareentwicklung ein Ingenieurbereich ist. Das hat zwei Gründe. Metriken zu erheben bedeutet Arbeit, und sie bringen manchmal unangenehme Tatsachen ans Licht.

Manfred Baumgartner beobachtet diesen Umgang über viele Jahre. Selbst einfache Metriken werden häufig nicht sinnvoll angewendet, dabei wären gerade sie leicht zu bekommen. Im Vergleich zu anderen Produktionsverfahren und Ingenieurtechniken wird in der Softwareentwicklung erstaunlich wenig gemessen.

Ein Teil des Problems liegt im Selbstverständnis der Branche. Software gilt vielen als etwas Künstlerisches, das sich dem Ingenieurmäßigen entzieht. Genau dieses Selbstbild führt dazu, dass Mengen, Komplexität und Qualität ungemessen bleiben.

Ein Projekt ohne Metriken ist ein Auto ohne Tacho

Metriken sind die Sensoren eines Projekts. Ohne sie fährst du blind. Ein Auto ohne Tachometer, Tankanzeige und Navi gibt dir nur ein vages Gefühl für Geschwindigkeit, aber keine verlässliche Aussage über deine Lage.

Das Bild lässt sich direkt übertragen. Wie viel Budget habe ich noch, wie viel Zeit, wie weit komme ich damit? Diese Fragen sind im Projektverlauf genauso relevant wie die Tankanzeige im Auto. Viele Projekte laufen trotzdem so, als hätten sie keinen einzigen dieser Sensoren.

40 km/h sind im Ort schnell und auf der Autobahn langsam. Eine Zahl bekommt ihre Bedeutung erst durch den Kontext. Genau deshalb reicht es nicht, eine Metrik zu erheben. Du musst wissen, wofür sie steht.

Drei Dimensionen: Quantität, Komplexität, Qualität

Metriken lassen sich entlang von drei Dimensionen ordnen: Quantität, Komplexität und Qualität. Dieser Dreiklang gibt einer ansonsten unübersichtlichen Fülle von Kennzahlen eine Struktur.

Quantitätsmetriken sind die einfachsten. Du zählst Lines of Code, du zählst Testfälle, du zählst Artefakte. Schon das ist eine brauchbare Aussage, etwa wenn du den nötigen Testaufwand abschätzen willst.

Komplexität ist schwerer zu fassen, aber aufwandsbestimmender. Wie komplex eine Software ist, treibt den Test- und Retestaufwand stärker als die reine Menge. Qualität ist der dritte Aspekt, und der Begriff selbst ist nicht allgemein definiert, was die Messung anspruchsvoll macht.

Eine Zahl allein sagt nichts, der Bezug macht sie nützlich

Quantitätsmetriken werden erst durch Bezug aussagekräftig. Zehn Testfälle bei 500.000 Lines of Code zeigen sofort, dass etwas nicht zusammenpasst. Die einzelne Zahl ist wertlos, die Relation ist der Befund.

Es gibt keine universelle Faustregel. Niemand kann sagen, für 100.000 Lines of Code brauchst du genau 150 Testfälle. Jede Software entsteht anders. Unterschiedliche Programmiersprachen erzeugen unterschiedliche Mengen an Code, und wer stark mit Libraries arbeitet, hat wenig selbst entwickelten Code, muss aber für allen Code Testfälle bereithalten.

Daraus folgt eine praktische Konsequenz für Organisationen. Maßzahlen funktionieren am besten als Rahmen oder Leitlinie, der iterativ justiert wird. Werte lassen sich kaum von einer Applikation auf die nächste übertragen, sehr wohl aber innerhalb eines Unternehmens über die Zeit anpassen.

Nicht nur Code lässt sich messen

Messbar ist weit mehr als nur der Code. Anforderungen, Entwurf, Architektur, Code und Tests bilden jeweils eigene Messobjekte mit eigenen Metriken.

Bei Anforderungen ist die Messung schwieriger geworden. Wo früher Lasten- und Pflichtenhefte standen, finden sich heute oft nur Stories in agilen Projekten. Aus reinem Text eine Menge oder Komplexität abzuleiten, gelingt schwer. Wo es beschriebene oder modellgetriebene Anforderungen gibt, sind Metriken aber möglich.

Code-Metriken sind das, woran die meisten zuerst denken. Früher zählte man GOTO-Statements, heute Klassenaufrufe und Lines of Code. Daneben stehen Testmetriken mit Fokus auf Test-Deliverables und Testergebnisse.

Der Entwurf lässt sich überraschend gut prüfen. Du kannst in einem Entwurfsdokument die Möglichkeitsformen zählen. Steht in jedem zweiten Satz ein “vielleicht”, ein “es könnte” oder “unter Umständen”, wird die Umsetzung schwer, besonders im Test. Entwickler haben damit oft weniger Probleme, weil unscharfe Formulierungen ihnen Spielraum geben.

Wofür du eine Metrik einsetzt, entscheidet alles

Vor jeder Metrik steht die Frage nach dem Zweck. Was willst du damit tun? Erst die Antwort darauf macht aus einer Zahl ein nützliches Werkzeug.

Aus Entwurfsmetriken lässt sich Aufwand ableiten, etwa wie viel Entwicklungs- und Testaufwand ein Entwurf erwarten lässt. Das gehört zur Planung von Vorhaben oder Teilvorhaben. Andere Metriken dienen der Qualitätssicherung des Testobjekts selbst, also der Prüfung, ob Standards und Kriterien eingehalten sind.

Bei einer Softwaremigration ist es hilfreich, vorab das Volumen und die innere Qualität des Bestands zu kennen. Ob ein System sauber und straightforward entwickelt ist oder Kraut und Rüben, macht für ein Refactoring einen großen Unterschied. Function-Point-Messung liefert dafür ein genormtes Maß für den fachlichen Umfang, das sich aus dem bestehenden Code berechnen lässt.

Der Trend zählt mehr als der einzelne Messwert

Bei Altprojekten ist die Trendrichtung oft wertvoller als der absolute Wert. Eine statische Analyse über gewachsenen Code liefert schnell erschlagend hohe Zahlen. Die ehrlichere und brauchbarere Vorgabe lautet dann: Es darf nicht schlechter werden.

Dieser Ansatz nimmt Druck heraus. Du musst nicht alle Altlasten umbauen. Es genügt, den Wert auf seinem Level zu halten, während neuer Code dazukommt und Bestehendes umgebaut wird.

Metriken helfen auch bei Architekturentscheidungen. Wenn mehrere Systeme in verschiedenen Programmiersprachen dasselbe leisten, zeigen Komplexitäts- und Qualitätskennzahlen, welches System sich zur Weiterentwicklung eignet und welches besser ausläuft.

Was in der Praxis gemessen wird, und was fehlt

Aus Testsicht ist die Fehler- und Fehlertrend-Auswertung der Klassiker. Sie ist verbreitet, aber bei der Interpretation bleibt oft Luft nach oben.

In agilen Projekten verschwimmt die Datenlage. Nicht jeder Fehler landet explizit in einem Fehlermanagementwerkzeug, manches versickert in einem nicht auswertbaren Backlog. Einige Unternehmen führen die Dokumentation konsequent weiter, andere verlieren die Spur.

Auf der technischen Ebene wird durchaus gemessen. Metriken aus dem CI/CD-Prozess und Code-Abdeckung auf Unit-Test-Ebene sind vorhanden. Die Auseinandersetzung mit dem, was diese Zahlen über tatsächliche Qualität und Umfang aussagen, bleibt dabei oft zu dünn.

Auch Produktivitätsmessung scheitert häufig an fehlenden Daten. Wenn der Fachbereich massiv in Testprojekte involviert ist, seine Stunden aber gar nicht auf Testprozesse heruntergebrochen erfasst werden, lässt sich keine belastbare Produktivität berechnen. Burn-down- und Burn-up-Charts werden aufgesetzt, verschwinden aber im Trubel, ohne dass jemand Maßnahmen daraus ableitet.

Eine einfache Metrik, die im echten Projekt getragen hat

Eine Metrik muss nicht komplex sein, um zu wirken. Ein pragmatischer Ansatz aus einem realen Projekt bestand aus drei Spalten: Geschäftsvorfall, Komplexität, Anzahl Testfälle.

Die Schätzlogik war simpel. Niedrige Komplexität bedeutete zwei bis drei Testfälle, mittlere etwa zehn, hohe rund zwanzig, unsichere Fälle potenziell Hunderte. Summiert ergab das eine erste Aufwandsschätzung: Anzahl Testfälle mal Tage pro Testfall.

Entscheidend war die Justierung nach jedem Sprint. Geplante Testfälle wurden mit den tatsächlich entworfenen verglichen und die Schätzwerte pro Komplexitätsstufe angepasst. Der Plan wurde zahlengetrieben definiert und inhaltsgetrieben nachgeschärft.

Das Ergebnis war verblüffend genau. Das Vorgehen war auch mit einer erwarteten Fehleranzahl pro Testfall hinterlegt, basierend auf historischen Daten. Am Projektende lag die tatsächliche Fehlerzahl rund zehn Prozent neben der Monate vorher erstellten Schätzung. Über das Gesetz der großen Zahl näherten sich die Werte dem Planwert an.

Man muss nicht die Hoffnung haben, dass die nächsten Sprints wesentlich besser werden. Die Hoffnung kannst du haben, aber sie ist meist unberechtigt. — Manfred Baumgartner

Diese Projektion in die Zukunft ist der eigentliche Wert. Wer früh sieht, dass die Fehler sich statistisch verteilen statt am Anfang zu klumpen, kann handeln: zusätzliche Testressourcen ziehen oder rechtzeitig ein Warnsignal an die Projektleitung geben.

Wie du mit einem Metrik-Kompendium arbeitest

Ein Kompendium liest man nicht von vorne bis hinten, sondern punktuell. Die einleitenden Kapitel zum Bewusstsein der drei Dimensionen Quantität, Komplexität und Qualität lohnen sich am Stück. Ab dort hilft der Index für den gezielten Zugriff.

Für eine Dimension wie den Entwurf gibt es mehrere Messansätze nebeneinander, etwa nach Tom Gilb oder nach Card und Glass. Es existiert keine einzige, von einem Normungsinstitut einheitlich festgelegte Messung. Diese Vielfalt ist eine Einladung, den für das eigene Umfeld passenden Ansatz auszuwählen.

Der erste Schritt ist immer derselbe. Verschaff dir einen Überblick, dann such gezielt heraus, was du im Projekt anwenden kannst. Keine dieser Metriken kommt fertig aus dem Werkzeug. Du musst selbst etwas dafür tun.