Methoden zur Messung des Softwareumfangs

Kennzahlen (KPIs) eignen sich zur Prüfung, ob sich bestimmte Aspekte von Wartung, Entwicklung oder Betrieb in einem erwarteten Bereich befinden, ob sie verbessert werden können oder gar Handlungsbedarf erfordern. Die entsprechenden Schwellenwerte bzw. Baselines lassen sich durch Beobachtung über einen längeren Zeitraum oder durch Benchmarking, d.h. durch den Vergleich von Kennzahlen zwischen verschiedenen Systemen, ermitteln.

Ein gutes Beispiel, um die Notwendigkeit einer Normalisierung von KPIs zu verdeutlichen, ist die Fehlerrate. Selbstverständlich kann man eine Fehlerrate definieren als die Anzahl von Fehlern (relevanter Fehlertypen) in einem bestimmten Zeitabschnitt. Mit dieser Metrik ist es jedoch schwierig zu bewerten, ob ein System mit 20 Fehlern im Monat besser oder vielleicht sogar schlechter ist als ein anderes System mit 30 Fehlern im Monat. Es fehlt ein weiteres Maß, mit dem die Fehleranzahl normalisiert werden kann. Analog zur Losgröße in der Industrie sollten wir die Menge oder Größe der Software quantifizieren, denn wenn das System mit seinen 30 Fehlern im Monat die doppelte „Größe“ gegenüber dem anderen System mit 20 Fehlern im Monat hat, ist seine Fehleranzahl als weniger kritisch zu bewerten. Dies führt zum Begriff der Fehlerdichte (siehe auch Kennzahlen zur Steuerung der Softwarewartung und -entwicklung).

Es gibt unzählige Ansätze, die Größe bzw. den Umfang von Software zu messen. In den 70’er Jahren hat man Codezeilen gezählt (Lines of Code-Metrik). Mit ihrer Abhängigkeit von der Programmiersprache und dem Programmierstil ist diese Metrik für viele Kennzahlen nicht geeignet. Besser ist eine Orientierung an den Anwendungsfällen eines Systems, wie dies im Standard ISO/IEC 14143 für funktionsorientierte Messungen beschrieben ist.

Eine weit verbreitete funktionsorientierte Umfangsmetrik ist die Function Point-Methode. Sie zählt für die Anwendungsfälle relevante Elementarprozesse und  Datenstrukturen und ist somit unabhängig vom Code oder anderen technologischen Aspekten. Dies erfordert jedoch ein Verständnis der vollständigen Funktionalität, was die Anwendung der Methode auf große IT-Systeme zeitaufwendig macht. Die Punktwerte der Elementarprozesse und Datenbestände orientieren sich an der Komplexität und sind durch dreistufige Intervallskalen festgelegt. Siehe dazu auch meinen Post Ist die Function Point-Methode noch aktuell?

Die DIP-Methode (Data Interaction Point-Methode) der PASS Consulting Group zählt im Hinblick auf die Anwendungsfälle relevante Datenelemente und ihre Interaktionen mit dem Benutzer oder mit Fremdsystemen. Das Zählen der Datenelemente und ihrer Entsprechung in Dialogen und Schnittstellen kann meist automatisiert werden. Die Punktwerte orientieren sich an der Komplexität und ergeben sich aus der Verwendung eines Datenelements. Siehe auch Die PASS Data Interaction Point-Methode (DIP-Methode).

Möglich sind durchaus viele weitere Umfangsmetriken, sofern diese 

• objektiv (Messwerte sind unabhängig vom Messenden), 
• zuverlässig (Wiederholte Messungen kommen zum gleichen Ergebnis) und 
• valide (Messwerte repräsentieren die zu messende Größe) sind.