Die Bedeutung der Komplexität

In der Softwareentwicklung versteht man unter Komplexität den Aufwand zum Verstehen eines Programms oder Algorithmus. Daraus folgt, dass der Aufwand für die Neu- oder Weiterentwicklung einer Software nicht nur (je nach Messmethode) von der Anzahl der Elementarprozesse, Datenstrukturen, Datenelemente, usw. abhängig sein kann sondern auch von der Komplexität. Dabei sind jedoch verschiedene Arten der Komplexität zu unterscheiden.

Die Komplexität einer Implementierung steht für den Aufwand zum Verstehen der Implementierung (Code und Design) und ist für Abschätzungen des Wartungs- und Weiterentwicklungsaufwands von Bedeutung. Es gibt eine Vielzahl von Metriken, mit denen sich unterschiedliche Aspekte messen lassen: Die zyklomatische Komplexität mit der Metrik von McCabe, die lexikalische/textuelle Komplexität mit der Metrik von Halstead, die Klassenkomplexität mit der RfC-Metrik, usw. Für die Bestimmung des Aufwands neuer, geplanter Entwicklungsvorhaben ist sie ohne Bedeutung, da sie erst mit der Implementierung entsteht und sich vor allem dadurch auszeichnet, dass unterschiedliche Implementierungen des selben Anwendungsfalls eine unterschiedlich hohe Komplexität haben können.

Die Komplexität einer Implementierung spielt bei funktionsorientierten Umfangsmessungen keine Rolle. Anders die Komplexität der funktionalen Anforderungen, die jedoch nicht weniger abstrakt ist. Sie steht für den Aufwand zum Verstehen und Umsetzen aller Ablaufschritte der Szenarien eines Anwendungsfalls. Bei der Function Point-Analyse wird sie von Strukturparametern wie der Anzahl der an einem Elementarprozess beteiligten Datenelementtypen und Datenbestände abgeleitet. Die Data Interaction Point-Methode bewertet die Komplexität nach der Verwendung von Datenelementen, beispielsweise zur Ein-/Ausgabe, bei Persistenz oder Nur-Lese-Zugriff, usw. Die COSMIC-Methode berücksichtigt keine Komplexität, was bei Geschäftsanwendungen ein Nachteil ist.

Alle zum Standard ISO/IEC 14143 konformen funktionsorientierten Messmethoden ignorieren die algorithmische Komplexität der Fachlogik, die in den Prozessen und Funktionen des Systems steckt. Sie gehen von einer gegenüber dem funktionalen Umfang nachrangigen Bedeutung der algorithmischen Komplexität aus. Tatsächlich beschränkt sich die algorithmische Komplexität bei den meisten Systemen auf die Validierung von Eingaben, Abfragen der Datenbestände, Aufbereitung von Ausgaben, eher einfache logische Operationen und Berechnungen, usw. Da die Anzahl dieser Funktionen oft mit der Anzahl an Interaktionen mit den Akteuren korreliert ist der dadurch verursachte Fehler vermutlich gering. Dies gilt jedoch nicht für Systeme, bei denen die algorithmische Verarbeitung im Vordergrund steht. Als Beispiel mag ein Routenplanungsprogramm dienen: Input ist eine Start- und eine Zielangabe, Output eine Liste von Streckenabschnitten. Jede funktionsorientierte Metrik würde nur die Interaktionen mit dem Anwender berücksichtigen und einen geringen funktionalen Umfang messen. Da die Entwicklung des ohne Zweifel hochkomplexen Planungsalgorithmus einen hohen Aufwand erfordert, würde man aufgrund des geringen Umfangs auf eine gegenüber anderen Systemen sehr niedrige Produktivität schließen, was nicht korrekt ist. Fazit: Funktionsorientierte Messverfahren sind nicht für Systeme mit überdurchschnittlich hoher algorithmischer Komplexität geeignet.

Die COSMIC-Methode

Die COSMIC-Methode ist eine Umfangsmetrik (siehe Methoden zur Messung des Softwareumfangs), die durch die Norm ISO/IEC 19761 beschrieben wird. Sie ist konform zum Standard "Functional Size Measurement" (ISO/IEC 14143) und orientiert sich daher (ähnlich der Function Point Analyse) an den Anwendungsfällen eines System.

Zählobjekte der COSMIC-Methode

COSMIC verwendet eine eigene Definition der Akteure, die sogenannten "Functional Users", bei denen es sich neben menschlichen Benutzern und externen Systemen um beliebige Hardware- oder Software-Komponenten handeln kann, die entweder Daten über die Systemgrenzen hinweg an die zu messende Software senden und dadurch einen funktionalen Prozess anstoßen oder Daten aus einem funktionalen Prozess der zu messenden Software über die Systemgrenzen hinweg erhalten und verarbeiten (Datenbewegungen). Je nach Richtung werden diese als Entries oder Exits bezeichnet. Zusätzlich werden auch Zugriffe auf im Datenhaushalt abgelegte Datenelemente (Read oder Write) gezählt, die in Beziehung zu den funktionalen Prozessen stehen.

Ein Vorteil der COSMIC-Methode ist das Zählen von Datenelementen und nicht, wie bei der Function Point Analyse, Datenstrukturen oder Elementarprozessen. Ein weiterer Vorteil ist, dass hinsichtlich des Datenhaushalts Datenbewegungen, d.h. Lese- und Schreiboperationen, gezählt werden und nicht der statische Umfang einer Datenbank. Diese Eigenschaften sowie die breite Definition der "Functional Users" macht die Methode gut geeignet für die Messung des funktionalen Umfangs von Echtzeit-Systemen.

Ein Nachteil ist die Tatsache, dass alle Entries, Exits, Reads und Writes mit den gleichen Punktwerten gezählt und so Komplexitätsunterschiede bei den vor- bzw. nachgelagerten funktionalen Prozessen der Datenbewegungen nicht berücksichtigt werden. 

Der Einfluss vernachlässigter QS auf die Produktivität

Die Produktivität eines Entwicklungsprojektes kann (kurzfristig) dadurch gesteigert werden, dass man die Qualitätssicherung vernachlässigt und eine mangelhaft getestete Anwendung in den Produktionsbetrieb übergibt. Ein Grund dafür kann Termindruck sein. Eine scheinbar positive Auswirkung: Die höhere Neuentwicklungsproduktivität gegenüber anderen Projekten mit höherem Testaufwand.

Über die Laufzeit des Entwicklungsprojektes hinaus sind die Auswirkungen jedoch:

• Eine höhere Fehlerrate gegenüber anderen Systemen
• Eine geringere Produktivität bei der Entwicklung künftiger Releases oder Inkremente, bedingt durch den hohen Aufwand für Fehleranalysen und Korrekturen

Diese Auswirkungen sind meist nicht von Dauer, da die Fehleranzahl aufgrund der nach Produktivsetzung notwendigen Anstrengungen auf ein "normales" Maß zurückgeführt werden kann. Dennoch ist dieses Vorgehen kurzsichtig, denn der Aufwand für Tests, Fehleranalysen und Korrekturen verlagert sich dabei vom Entwicklungsprojekt auf die anschließende Weiterentwicklung. Mitunter wird dabei auch Testaufwand auf die ersten Anwender eines Systems verlagert.

Das untenstehende Diagramm zeigt einen in solchen Fällen typischen Verlauf von Fehlerdichte und Produktivität nach der Produktivsetzung (Rel. 1.0). Im Gegensatz zu den Auswirkungen Technischer Schulden "erholen" sich solche Projekte über einen längeren Zeitraum betrachtet meist wieder, d.h. die Fehlerdichte wird aufgrund der inzwischen gefundenen und korrigierten Fehler sukzessive niedriger und die Produktivität aufgrund des geringer gewordenenen Korrekturaufwands wieder höher.

Verlauf von Fehlerdichte und Produktivität bei vernachlässigter QS (Beispiel)

Anzeichen vernachlässigter QS werden durch Messungen der Testabdeckung erkennbar.

Für bessere Maßnahmen zur Steigerung der Produktivität siehe Maßnahmen zur Produktivitätssteigerung.

Der Einfluss technischer Schulden auf die Produktivität

Es gibt Maßnahmen, mit denen die Produktivität von Neuentwicklungen gesteigert werden kann, die dennoch wenig empfehlenswert sind. Beispiele:

• Unvollständige Umsetzung von Anforderungen
• Aufgeschobene Korrekturen bekannter Fehler
• Vernachlässigung von Kommentierung und technischem Design
• Unzureichende oder fehlende Dokumentation
• Unzureichende Testabdeckung 
• Komplexe und daher nicht automatisierbare Build- und Deploy-Prozesse

Ein Entwicklungsprojekt, das dadurch seine Produktivität erhöht, nimmt sogenannte technische Schulden auf, die im Rahmen der späteren Weiterentwicklung mit Zinsen zurückgezahlt werden müssen. Die Zinsen beziehen sich darauf, dass

• der Aufwand für Weiterentwicklungen steigt und somit die Produktivität künftiger Releases oder Inkremente geringer wird,
• der Aufwand für Fehleranalysen und Korrekturen überdurchschnittlich hoch ist.

Die Auswirkungen technischer Schulden sind meist sehr langwierig und sehen etwa so aus, wie es das untenstehende Diagramm zeigt: Nach Abschluss der Entwicklung und Produktivsetzung der Anwendung (Rel 1.0) stellt man für die Weiterentwicklung (Releases 1.1, 1.2, usw.) eine immer schlechter werdende Produktivität fest (siehe: Messung der Produktivität in der Softwareentwicklung). Vorausgesetzt, der Aufwand für Fehleranalysen und -korrekturen geht in den Input der Produktivitätsmessungen mit ein. 

Verlauf von Fehlerdichte und Produktivität bei technischen Schulden (Beispiel)

Durch regelmäßige Codeanalysen werden viele Anzeichen technischer Schulden frühzeitig, schon während früher Phasen der Neuentwicklung, erkennbar (siehe: Regelmäßige Analyse der Codequalität mit Sonar). 

Für bessere Maßnahmen zur Steigerung der Produktivität: siehe Maßnahmen zur Produktivitätssteigerung.

Die PASS Data Interaction Point-Methode (DIP-Methode)

Die Data Interaction Point-Methode der PASS Consulting Group ist eine funktionsorientierte Umfangsmetrik (siehe: Methoden zur Messung des Softwareumfangs). Sie zählt alle Datenelemente, die in Interaktionen des betrachteten Systems mit den Akteuren seiner Anwendungsfälle, was sowohl menschliche Benutzer wie auch Fremdsysteme sein können, involviert sind. Die Komplexität wird in Form unterschiedlicher Punktwerte berücksichtigt, wenn beispielsweise Eingabeelemente in einem Dialog einen höheren Punktwert haben als reine Anzeigeelemente. 

Zählobjekte der Data Interaction Point-Methode

Die Grundprinzipien, d.h. die Orientierung an den Anwendungsfällen wie auch das Zählen relevanter Datenobjekte aus der Außensicht der Akteure, sind die gleichen, auf denen auch die Function Point-Analyse (FPA) und die COSMIC-Methode basieren. Ein Unterschied gegenüber FPA ist jedoch die Detaillierungsebene, auf der gezählt wird. Function Points zählt Datenstrukturen, deren Punktwerte sich aufgrund ihrer Anzahl an Datenelementen und Feldgruppen aus einer dreistufigen, nach oben offenen Intervallskala ergeben. Die DIP- und die COSMIC-Methode zählen direkt die Datenelemente. Während COSMIC jedoch keine Punktwerte unterscheidet ergeben sich die Punktwerte bei der DIP-Methode aus der Verwendung eines Datenelements, d.h. ob es sich beispielsweise um einen Nur-Lese- oder auch Schreibzugriff handelt, und orientieren sich somit an der Interaktionskomplexität.

Die DIP-Methode ist gut für den Vergleich von auf Umfangsmessungen basierenden Kennzahlen geeignet, wie beispielsweise der Produktivität (siehe auch: Kennzahlen zur Steuerung der Softwarewartung und -entwicklung).

Auch Messungen helfen, Qualität zu erzeugen

Neben Fehlerursachenanalysen (siehe meinen Beitrag Fehler helfen, Qualität zu erzeugen) sind auch regelmäßige Messungen und Benchmarks eine wichtige Basis der kontinuierlichen Verbesserung. Dabei decken bereits die folgenden drei Metriken die wichtigsten Aspekte ab:

• Produktivität (Effizienz): Die Leistung des Entwicklungsprozesses bis zum Erreichen einer definierten auslieferungsfähigen (äußeren und inneren) Qualität (siehe Messung der Produktivität in der Softwareentwicklung).

• Fehlerrate (Fehlerdichte): Der Quotient aus der Anzahl von Produktionsfehlern pro Zeiteinheit und dem Umfang eines Systems. Dabei muss präzise festgelegt sein, welche Fehlerarten berücksichtigt werden. 

• Wartungsaufwand: Der Quotient aus dem in einer definierten Zeiteinheit benötigten Aufwand für Wartungstätigkeiten und dem Systemumfang. Idealerweise differenziert nach Tätigkeitstypen wie Fehleranalyse, Fehlerkorrektur, Beratung, usw.

Wichtig sind für jeden dieser Aspekte Soll-Vorgaben bzw. Schwellenwerte (Baselines), deren Über- bzw. Unterschreitung Klärungs- oder, in einer nächsten Stufe, Handlungsbedarf signalisiert. Die Festlegung dieser Schwellenwerte wird durch Vergleiche zwischen verschiedenen Systemen, Projekten oder Shops erleichtert, bei denen unter Anwendung der exakt gleichen Meßmethode Kennzahlen ermittelt werden.

In der einfachsten Form kann bereits der Mittelwert oder, falls man dabei Extremwerte unberücksichtigt lassen möchte, der Median ein Schwellenwert sein. Dort, wo ein Messwert schlechter als der Mittelwert oder Median aller Messwerte ist, kann durch eine Analyse oder auch ein Assessment geklärt werden, was die Ursachen dafür sind. Ursachen führen wiederum meist zu möglichen Verbesserungsmaßnahmen. Deren Wirksamkeit wird durch den weiteren Verlauf der Kennzahl bei den nächsten Messungen transparent.

Fehler helfen, Qualität zu erzeugen.

Auch wenn das Auftreten von Fehlern nicht als „Normalfall“ angesehen werden soll (siehe: Ist Software mit Null-Fehler-Qualität möglich?), ist jeder Fehler auch eine Chance zur Verbesserung.

Für jeden Fehler sollte die genaue Ursache analysiert werden. Dabei geht es nicht um oberflächliche Ursachen wie „Programmierfehler“. Bewährt hat sich die 5-Why-Methode, bei der mehrfach (nicht zwingend fünfmal) nach dem „Warum“ gefragt wird. Erst wenn man die Ursache-Wirkungs-Kette so weit zurückverfolgt hat, dass es keine sinnvolle Antwort auf das „Warum?“ mehr gibt, hat man mit großer Wahrscheinlichkeit den Ursprung des Fehlers gefunden.

An diesem Punkt ist es nun wichtig, dass die identifizierte Fehlerursache einer Kategorie zugewiesen werden kann und die zur Auswahl stehenden Kategorien unternehmensweit einheitlich festgelegt sind. Technisch kann meist im verwendeten Ticketing System oder Error Tracking Tool eine entsprechende Auswahlliste hinterlegt werden. Die Standardisierung ist wichtig um Auswertungen zur Fehleranzahl in den verschiedenen Fehlerursachen-Kategorien vornehmen zu können. Sie lassen erkennen, in welchen Bereichen Verbesserungsmaßnahmen besonders effektiv erscheinen.

In Kenntnis der Fehlerursachen sollte nun nach Verbesserungsmaßnahmen gesucht werden, die das erneute Auftreten von Fehlern dieser Art verhindern. Dabei kann es sich um Verbesserungen im Bereich der konstruktiven Qualitätssicherung, beispielsweise der Entwicklungsmethoden und -Werkzeuge, oder auch des Teams oder anderen Bereichen handeln. Selbstverständlich kann es Fälle geben, in denen das erneute Auftreten eines Fehlers nicht durch Verbesserungsmaßnahmen verhindert werden kann.

Eine kontinuierliche Verbesserung auf dieser Basis wird nur funktionieren, wenn es einen Verantwortlichen gibt, der die so identifizierten Maßnahmen kommuniziert, ihre Umsetzung plant, kontrolliert und nach erfolgter Umsetzung die Wirksamkeit der Maßnahmen überprüft.

Dieses Verfahren, das ähnlich in der Automobilindustrie schon seit den 70’er Jahren verwendet wird, dient der künftigen Vermeidung von Fehlern, was eindeutig eine bessere Investition ist als in Maßnahmen zur Erkennung, Verwaltung oder Beseitigung von Fehlern. Mit anderen Worten: Es erzeugt Qualität.

Regelmäßige Analyse der Codequalität mit Sonar

Mit der Plattform Sonar können unterschiedliche Projekte einer statischen Codeanalyse unterzogen und die Ergebnisse in einer einheitlichen Form präsentiert werden. Sonar selbst verfügt über eigene Prüfregeln, ergänzt diese jedoch durch Integration zusätzlicher Analysetools wie (in der Java-Welt) FindBugs, Checkstyle oder PMD.

Die Erfahrungen mit dem Einsatz in einem großen Portfolio unterschiedlicher Anwendungen sind gut. Die für Java mehr als 800 verfügbaren Regeln sind gut beschrieben, lassen sich aktivieren und deaktivieren und können bezüglich der Schwere von Regelverletzungen (Blocker, Critical, usw.) sowie Parametern konfiguriert werden. Die Erfahrung hat gezeigt, dass es sich lohnt, nicht die Standardeinstellungen zu verwenden sondern diese Konfiguration mit erfahrenen Entwicklern durchzusprechen und eher weniger als mehr Regeln als kritisch einzustufen (Blocker). Dafür sollte im Vorgehensmodell bzw. in den Quality Gates für die Softwareentwicklung klar festgelegt sein, dass beispielsweise ein Release nicht eingesetzt werden darf, solange es Blocker enthält. Immerhin handelt es sich dabei mit hoher Wahrscheinlichkeit um potentielle Laufzeitfehler.

Zusammenfassung der Ergebnisse einer Codeanalyse mit Sonar (Beispiel)

Zusätzlich zu diesen Regeln misst Sonar die Kommentardichte, den Anteil auskommentierten oder duplizierten Codes, die zyklomatische Komplexität, den Grad des Methoden-Zusammenhalts (LCOM4) und die Klassen-Komplexität (RFC), die sich als Indikatoren für die Code-Qualität bewährt haben. Basierend auf den eigenen Programmierrichtlinien, in denen unter Anderem Richtwerte für diese Metriken festgelegt sein sollten, kann in einem Profl definiert werden, ab welchem Schwellenwert für eine Metrik die Über-/Unterschreitung in Sonar als Warning oder als Error angezeigt wird. So kann man sicherstellen, dass alle mit diesem Profil analysierten Anwendungen nach dem gleichen Maßstab gemessen werden.

Die Codeanalyse kann gut in den Build-Prozess einer Anwendungen integriert werden, so dass nach jedem neuen Build, je nach Konfiguration also beispielsweise jede Nacht oder auch kontinuierlich, auch ein neues Analyseergebnis zur Verfügung steht.

Ein Webclient stellt die Analyseergebnisse in Dashboards dar. Die Möglichkeiten zur Strukturierung auch großer Anwendungsportfolios sind sehr gut. Es stehen zahlreiche Werkzeuge zur Verfügung um beispielsweise Zeitverläufe zu analysieren oder Hotspots zu erkennen. Per Drill-down kann man jede Regelverletzung bis auf Code-Ebene verfolgen und diese, je nach Berechtigung, ggf. als „false positive“ deklarieren.

Mit einem Werkzeug wie Sonar können Programmierrichtlinien nicht nur festgelegt sondern auch überprüft werden. Und dies ohne großen Zeitaufwand und in kurzen Zyklen.

Informationen zu Sonar findet man unter http://www.sonarqube.org/ oder http://docs.codehaus.org/display/SONAR/Documentation.

Kennzahlen zur Steuerung der Softwareentwicklung

Ein wirksames Management der Softwareentwicklung erfordert nur drei Leistungskennzahlen (KPIs):

• Produktivität (Effizienz): Der Quotient aus dem Umfang der produzierten bzw. geänderten Software und dem dafür benötigten Aufwand (siehe: Messung der Produktivität in der Softwareentwicklung).
• Fehlerrate (Fehlerdichte): Der Quotient aus der Anzahl von Produktionsfehlern pro Zeiteinheit und dem Umfang eines Systems. Dabei muss präzise festgelegt sein, welche Fehlerarten berücksichtigt werden.
• Fehlerbehebungskosten: Der Quotient aus dem in einer definierten Zeiteinheit benötigten Aufwand zur Fehlerbeseitigung und dem Systemumfang.

Die Ermittlung dieser Kennzahlen ist völlig unabhängig von einem Vorgehensmodell, d.h. sie ist sowohl bei schwergewichtigen Prozessen als auch bei agiler Entwicklung sinnvoll und möglich. Gerade agile Softwareentwicklung erfordert zeitnahe Leistungskennzahlen zur Justierung.

Die Vorteile des Einsatzes von Kennzahlen in der Softwarewartung und -entwicklung sind:

• Leistung und Qualität werden messbar und vergleichbar. Eine Organisation kann dadurch feststellen, ob Veränderungen zu einer Verbesserung oder Verschlechterung geführt haben und in welchem Maße.
• Kennzahlen ermöglichen die quantitative Festlegung von Erfolgskriterien und eine präzise Kontrolle der Zielerreichung.
• Tendenzen werden erkennbar. Kennzahlen dienen als Indikatoren für notwendige Handlungsbedarfe.
• Leistung und Qualität werden vorhersagbar. Auf Basis von Erfahrungswerten für die zu erwartende Produktivität kann beispielsweise der Aufwand geplanter Entwicklungsvorhaben bestimmt werden.