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.

Ö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.

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.

Wann ist Softwareentwicklung agil?

Die folgenden Eigenschaften kennzeichnen agile Softwareentwicklung:

• Teile des Systems werden zu verschiedenen Zeiten entwickelt und das System jeweils um die fertig gestellten Teile erweitert (inkrementelle Entwicklung).
• Fehlerursachenanalysen und Messungen werden benutzt, um Verbesserungen herbeizuführen (Lernfähigkeit des Teams wie auch der Organisation).
• Alle Beteiligten arbeiten eng und direkt zusammen, beispielsweise durch ein hohes Maß an Teamarbeit oder eine stetige Mitarbeit des Auftraggebers bzw. Produktverantwortlichen.

Diese Eigenschaften sind mit ingenieurmäßigem Vorgehen wie auch mit industrieller Softwareentwicklung völlig vereinbar.

Tatsächlich gibt es Modelle zur agilen Softwareentwicklung bereits seit Anfang der 90er Jahre. Sie folgen ebenfalls Prozessen und sind aufgrund der meist kurzen Entwicklungszyklen (Sprints) noch stärker auf Messungen beispielsweise von Projektfortschritt, Codequalität, Testabdeckung, usw. und eine schnelle Rückkopplung zu den Entwicklern angewiesen.

Softwareentwicklung mit Methoden der industriellen Produktion

Methoden der industriellen Produktion können eine Antwort sein auf 

• die zunehmende Komplexität von Anforderungen,
• kürzer werdende Entwicklungszeiten und
• steigenden Kostendruck.

Dabei geht es in der Softwareentwicklung weniger um die Serienfertigung eines immer gleichen Produktes als um folgende Aspekte:

• Standardisierung von System- und Anwendungsarchitekturen
• Wiederverwendung von Komponenten
• Automatisierung von Entwicklungs- und Qualitätssicherungsprozessen
• Messbarkeit von Leistung und Ergebnisqualität

Während für die Softwareentwicklung heute zahlreiche Standards, Konzepte zur Wiederverwendung und Werkzeuge zur Automatisierung zur Verfügung stehen und in vielen Unternehmen auch etabliert sind wird das Messen entweder völlig vernachlässigt oder durch Schätzen ersetzt. Dabei sind präzise und regelmäßige Messungen der Produktivität eine wichtige Grundlage dafür, den Aufwand für anstehende Entwicklungsvorhaben schnell und verlässlich zu ermitteln (siehe auch Messung der Produktivität in der Softwareentwicklung).

Die Bedeutung von Prozessen in der kommerziellen Softwareentwicklung

Prozesse geben Verfahrenssicherheit durch festgelegte Arbeitsabläufe und sind Teil der organisatorischen QS. Ich behaupte: Eine kommerzielle Softwareentwicklung kann ohne Prozesse nicht erfolgreich sein.

Dabei folgen auch agile Vorgehensmodelle wie Scrum ihren eigenen Prozessen. Sie basieren auf einer Ablauf- und Terminplanung, die sich gegenüber „schwergewichtigeren“ Vorgehensmodellen durch kürzere Lieferzyklen (Sprints) auszeichnet. Umgekehrt sind die meisten (nicht-agilen) Vorgehensmodelle ebenfalls in der Lage, mit kurzfristigen Änderungen der Projektziele und Anforderungen umzugehen.

Die Welt der Prozessmodelle ist also keinesfalls polarisiert in agiles Vorgehen versus Ableger des klassischen Wasserfallmodells. Vielmehr unterscheiden sich die verschiedenen Vorgehensmodelle nur in der Explizitheit ihrer Prozessdefinitionen, der Flexibilität, mit der Prozesse und Methoden an unterschiedliche Rahmenbedingungen angepasst werden können und der Bedeutung, die der Einhaltung von Prozessen gegenüber menschlichen Interaktionen oder Änderungen zukommt.

Eine größere Bedeutung als die Prozesse selbst hat nach meiner Erfahrung die Festlegung von Quality Gates, durch die eine vorhersagbare Ergebnisqualität im Eingang oder Ausgang eines Prozesses, einer Iteration oder einer Projektphase festgelegt wird. Quality Gates werden durch Prüfungen (Testmethoden oder auch Schwellenwerte für Metriken) und Erfolgskriterien definiert, die ein Testobjekt erfüllen muss, damit das „Gate“ durchschritten werden darf, so dass das Ergebnis verwendet bzw. an den nachfolgenden Entwicklungsschritt übergeben werden kann. Zu Beginn eines Entwicklungszyklus kann so eine Prüfung der Anforderungen auf Konformität mit den verfolgten Zielen, Realisierbarkeit, Vollständigkeit, Konsistenz, usw. vorgeschrieben sein, deren Sinnhaftigkeit keine Frage von leicht- oder schwergewichtigen oder agilen Vorgehensmodellen ist.