Application Value Assessment
Die Messung, Prüfung und Beurteilung der Quantität, Qualität und Komplexität von Anwendungssystemen bildet eine fundierte Basis für Entscheidungen zur IT-Strategie. Gerade bei Legacy-Systemen mit großem, gewachsenem Codeumfang und einer hohen Sprachenvielfalt können so Daten ermittelt und eine Vergleichbarkeit geschaffen werden, die für eine Bewertung verschiedener Weiterentwicklungsszenarien (Wartung, Migration, Sanierung, etc.) herangezogen werden können. Hierfür ist es jedoch nötig, aus der sehr großen Menge an möglichen Kennzahlen und Metriken die geeigneten auszuwählen.
Ziele eines Messprojekts
Typische Ziele, die mit einem Projekt zur Vermessung von Anwendungssystemen verfolgt werden, sind:
- Die Ermittlung der Größe, Komplexität und Qualität des Codes eines Systems
- Der Aufbau einer Metrikdatenbank zur laufenden Qualitätssicherung
- Die Identifikation und Schätzung alternativer Weiterentwicklungsstrategien
Um das erste Ziel, die Vermessung des Systems, erfüllen zu können, ist es notwendig, den Sourcecode der Applikation so zu strukturieren und für die Messung aufzubreiten, dass eine sinnvolle Vergleichbarkeit der Messergebnisse möglich wird. Eine Einteilung kann z.B. nach Sprachen (Cobol, PL1, C++, etc.) oder auch nach speziellen fachlichen Bereichen erfolgen. In weiterer Folge können somit die einzelnen Bereiche in Bezug auf die Größe, Qualität und Komplexität mit einander verglichen und Auffälligkeiten detaillierter untersucht werden. Die Messung ist dabei nicht nur auf Programmcode beschränkt, es können auch Datenbanken und Benutzeroberflächen vermessen werden.
Der Aufbau einer Metrikdatenbank ermöglicht die laufende Vermessung des Systems über die Zeit. Somit kann bei Änderungen oder Erweiterungen des Systems beobachtet werden, ob sich z.B. die Qualität insgesamt verbessert oder verschlechtert hat. Idealerweise wird eine laufende Messung im Qualitätssicherungsprozess eingebettet.
Die Ergebnisse der Messung bieten eine einheitliche Basis, um verschiedene Weiterentwicklungsszenarien zu bewerten und deren Aufwand zu schätzen. Dies kann als Grundlage für die künftige IT-Strategie verwendet werden. Mögliche Szenarien sind:
- Jährliche Wartung des Systems
- Neuentwicklung des Systems
- Migration
- Sanierung
- Kapselung
Auswahl der Metriken
Voraussetzung für jedes Messprojekt ist die Auswahl der geeigneten Metriken. Diese Auswahl ist auch der erste Schritt im Messprozess der ISO9126. Die Literatur gibt jedoch wenig Anhaltspunkte, welche Metriken auszuwählen sind. Softwaresysteme sind komplexe Konstrukte mit vielen verschiedenen Eigenschaften, die gemessen werden können. In seinem Buch “Software Complexity Metrics” hat Horst Zuse allein mehr als 300 Metriken identifiziert. Jede Kennzahl, bzw. Metrik misst eine andere Eigenschaft, z.B. die McCabe-Metrik die interne Ablaufkomplexität, die Halstead-Metrik die Komplexität der Sprache oder die Function-Point-Metrik die Interaktionen zwischen einem System und seiner Umgebung. Letztlich ist es eine Frage der Zielsetzung des Messprojektes und der Art des Systems, welche Metriken am geeignetsten sind.
In den von einem der Autoren in den letzten 20 Jahren durchgeführten Messprojekten ist durch die Erfahrungen mit den verschiedensten Systemen eine Zusammenstellung von Größen-, Komplexitäts- und Qualitätsmetriken entstanden, die sich bei der Analyse und Bewertung von Anwendungssystemen schon vielfach bewährt haben. Darunter finden sich Komplexitätsmetriken wie z.B. Datenkomplexität, Steuerflusskomplexität und Sprachkomplexität aber auch Qualitätsmetriken wie z.B. für die Messung der Portabilität, Wartbarkeit, Konformität und Testbarkeit.
Der Messprozess
Der Messprozess zur Durchführung der Messung, Prüfung und Bewertung des Systems besteht typischerweise aus folgenden Schritten:
- Auswahl der Metriken
- Strukturierung des zu messenden Systems
- Konfiguration der Tools, Anpassung an lokale Gegebenheiten (z.B.: eigene Sprachkonstrukte)
- Durchführung der Vermessung
- Übernahme der Messwerte in eine Metrikdatenbank
- Auswertung der Messergebnisse
- Durchführung der Schätzungen
Ergebnisse
Neben den Metrikberichten zu Größe, Qualität und Komplexität des Systems und den Teilsystemen/Komponenten sowie den Aufwandsschätzungen zu verschiedenen Weiterentwicklungsstrategien lassen sich Auswertungen erstellen, um die Informationen für verschiedene Zielgruppen aufzubereiten. Dies erfolgt z.B. in Form von Scorecards, die die Qualitäten und Komplexitäten zueinander in Relation bringen, oder in Management-Dashboards, um einen aktuellen Überblick über das System zu erhalten.
Häufig gestellte Fragen
Warum lohnt sich eine Vermessung bei gewachsenen Legacy-Systemen besonders?
Weil bei großem Codeumfang und hoher Sprachenvielfalt sonst jede Einschätzung Meinung bleibt. Messung, Prüfung und Beurteilung von Quantität, Qualität und Komplexität liefern Daten und schaffen Vergleichbarkeit zwischen Teilen des Systems. Auf dieser Basis lassen sich Weiterentwicklungsszenarien wie Wartung, Migration oder Sanierung gegeneinander bewerten, statt sie nach Bauchgefühl auszuwählen.
Wie lassen sich Messergebnisse aus unterschiedlichen Teilen eines Anwendungssystems überhaupt vergleichen?
Der Sourcecode muss vor der Messung so strukturiert und aufbereitet werden, dass eine sinnvolle Vergleichbarkeit entsteht. Eingeteilt wird beispielsweise nach Sprachen wie Cobol, PL1 oder C++ oder nach fachlichen Bereichen. Anschließend vergleicht man die Bereiche nach Größe, Qualität und Komplexität und untersucht Auffälligkeiten genauer. Messbar ist dabei nicht nur Programmcode, sondern auch Datenbanken und Benutzeroberflächen.
Was bringt eine Metrikdatenbank gegenüber einer einmaligen Messung?
Sie erlaubt die laufende Vermessung des Systems über die Zeit. Bei Änderungen oder Erweiterungen wird sichtbar, ob sich die Qualität insgesamt verbessert oder verschlechtert hat. Der Nutzen entsteht vor allem dann, wenn die wiederkehrende Messung fest im Qualitätssicherungsprozess eingebettet ist und nicht als einmalige Momentaufnahme stehen bleibt.
Welche Weiterentwicklungsszenarien lassen sich mit Messergebnissen gegeneinander abwägen?
Betrachtet werden typischerweise die jährliche Wartung des Systems, eine Neuentwicklung, eine Migration, eine Sanierung und die Kapselung. Die Messergebnisse liefern für alle diese Varianten eine einheitliche Bewertungs- und Schätzbasis. Damit werden Aufwände vergleichbar, und die Entscheidung kann als Grundlage der künftigen IT-Strategie dienen.
Gibt es eine Standardauswahl an Metriken für die Bewertung von Software?
Nein. Welche Metriken geeignet sind, hängt von der Zielsetzung des Messprojekts und der Art des Systems ab. Die Literatur gibt dazu wenig Anhaltspunkte: Horst Zuse identifizierte in seinem Buch “Software Complexity Metrics” allein mehr als 300 Metriken. Die Auswahl bildete 2009 zugleich den ersten Schritt im Messprozess der ISO 9126.
Was messen McCabe, Halstead und Function Points jeweils?
Jede dieser Metriken zielt auf eine andere Eigenschaft. Die McCabe-Metrik erfasst die interne Ablaufkomplexität, die Halstead-Metrik die Komplexität der Sprache, die Function-Point-Metrik die Interaktionen zwischen einem System und seiner Umgebung. Wer nur eine davon erhebt, beschreibt entsprechend nur einen Ausschnitt des Systems.
Welche Arten von Metriken gehören in eine Bewertung von Anwendungssystemen?
Bewährt hat sich eine Zusammenstellung aus Größen-, Komplexitäts- und Qualitätsmetriken. Auf der Komplexitätsseite stehen etwa Datenkomplexität, Steuerflusskomplexität und Sprachkomplexität. Auf der Qualitätsseite werden unter anderem Portabilität, Wartbarkeit, Konformität und Testbarkeit gemessen. Diese Auswahl entstand aus Messprojekten, die einer der Autoren in den rund zwanzig Jahren bis 2009 durchgeführt hat.
Wie bereitet man Messergebnisse für unterschiedliche Zielgruppen auf?
Neben den Metrikberichten zu Größe, Qualität und Komplexität des Gesamtsystems und seiner Komponenten sowie den Aufwandsschätzungen entstehen zielgruppengerechte Auswertungen. Scorecards setzen Qualitäten und Komplexitäten zueinander in Relation. Management-Dashboards liefern einen laufenden Überblick über den Zustand des Systems, ohne dass die Empfänger die einzelnen Metriken im Detail kennen müssen.
