Ökonomische Messungen (Automatisierung und ihre Grenzen)

Umfangsmessungen sollen regelmäßig erfolgen, damit der Zuwachs des funktionalen Umfangs einer Anwendung und damit auch die Weiterentwicklungsproduktivität für jedes Release oder Inkrement ermittelt werden können. Nur durch den Vergleich zyklischer Messungen lassen sich Verbesserungen oder Verschlechterungen erkennen und verfügt die Organisation über aktuelle Erfahrungswerte der eigenen Produktivität, die der Schlüssel zur Bestimmung des Aufwands neuer Entwicklungsvorhaben sind (siehe Messung der Produktivität in der Softwareentwicklung).

Die Erfahrung zeigt, dass regelmäßige Messungen vernachlässigt werden, wenn der Messaufwand zu hoch ist. Auf Zählungen basierende Messverfahren ermöglichen durch die Abbildung der Zählobjekte auf konstruktive Merkmale eines bestehenden Systems einen hohen Automatisierungsgrad, wenn entsprechende Programme oder Skripte zur Zählung implementiert werden. Der Aufwand für ihre Implementierung macht sich schnell bezahlt, wenn wiederholte Messungen eines Systems keinen manuellen Aufwand mehr erfordern. Mögliche Ansatzpunkte für eine automatisierte Zählung sind:

• Dialogmodelle in Form von XML- oder XHTML-Dateien, wie sie viele GUI-Frameworks heute verwenden

• XML-Schemata, die Schnittstellen- oder Nachrichtenstrukturen definieren werden

• Metadaten eines DBMS, die Informationen über Tabellen und Attribute enthalten

Bei automatisierten Messungen, die sich stärker an konstruktiven Merkmalen einer Anwendung als an ihren Anwendungsfällen orientieren, besteht die Gefahr von Unschärfen aufgrund der mehrfachen Verwendung von Zählobjekten. Als Beispiel mag der Vergleich zwischen zwei Systemen dienen, die beide unterschiedliche Implementierungen der selben Anwendungsfälle sind:

• Bei System A wurden ähnliche Dialoge mehrmals und teilweise redundant implementiert.

• Bei System B wurde stattdessen ein generischer Dialog implementiert, der sich je nach Anwendungsfall bzw. Aufruf entsprechend anpasst. 

Eine automatisierte Umfangsmessung auf Basis konstruktiver Merkmale liefert für System B einen niedrigeren Umfangswert, der nicht korrekt ist, da beide Systeme Implementierungen der selben Anwendungsfälle sind. Im ungünstigsten Fall fördert dies nicht wünschenswerte Entwicklungspraktiken (Copy & Paste) und schlechtes Design, wenn Entwickler die gemessene Produktivität gezielt durch die Erzeugung redundanter Zählobjekte erhöhen. Tatsächlich ist jedoch die Wiederverwendung von Komponenten und Services ein wichtiger Schlüssel für die Steigerung der Produktivität und Verbesserung der Wartbarkeit.

Fazit: Automatisierte, auf konstruktiven Merkmalen basierende Messungen machen Messverfahren meist erst praxistauglich, führen jedoch zu einer eingeschränkten Vergleichbarkeit von Systemen mit unterschiedlichem Wiederverwendungsgrad.