Methoden zur direkten und indirekten Aufwandsschätzung (3)

Indirekte Schätzungen durch Bestimmung des funktionalen Umfangs

Eine bewährte Methode zur indirekten Aufwandsschätzung ist die Bestimmung des funktionalen Umfangs (anstelle beispielsweise Story Points) und die Verrechnung mit einem Erfahrungswert, welcher Umfang mit einem bestimmten Personalaufwand umgesetzt werden kann (auch häufig als Produktivität oder Effizienz bezeichnet). Die Grundlagen zur Messung des funktionalen Umfangs sind im Industriestandard ISO/IEC 14143 definiert. Sie erfordern eine Präzisierung der User Stories in Anwendungsfälle.

Beispiel eines Anwendungsfalldiagramms

Ein Anwendungsfall steht für ein Verhalten, das ein System nach außen – bezogen auf die definierten Systemgrenzen – anbietet, dessen Ergebnisse also für einen Akteur von außen wahrnehmbar sind. Dabei können Akteure sowohl Anwender als auch andere Systeme oder Maschinen, Hardware oder Software, sein. Die nebenstehende Abbildung zeigt das Anwendungsfalldiagramm einer (stark vereinfachten) Internet Booking Engine für Flüge. Innerhalb der Systemgrenzen (dargestellt als Rechteck mit der Beschriftung „Internet Booking Engine“) sind Anwendungsfälle durch Ellipsen dargestellt. Sie stehen in Beziehung mit Akteuren, im Beispiel ein Reisender und ein Computerreservierungssystem (CRS), was durch Linien zwischen den Akteuren und den Use-Cases dargestellt wird.

Jeder Anwendungsfall steht für Aktionen, aus denen sich die für eine Bestimmung des funktionalen Umfangs relevanten sogenannten Basis-Funktionskomponenten oder Elementarprozesse identifizieren lassen. Der Anwendungsfall „Search Flight“ könnte beispielsweise vereinfacht aus folgenden Elementarprozessen bestehen:

1. Reisender ruft den Flight Search Dialog auf.
2. Reisender gibt das Abflugdatum ein.
3. Reisender gibt die ersten Buchstaben des Reiseziels ein (Name oder Code).
4. System sucht in der Datenbank nach übereinstimmenden Flughäfen und zeigt eine Liste mit Namen und Codes an.
5. Reisender wählt einen Eintrag aus der Liste aus und klickt auf dem Button „Search“.
6. System sendet eine Nachricht vom Typ „Flight Search Request“ mit Datum und Flughafen-Code an das CRS.
7. System empfängt eine Nachricht vom Typ „Flight Search Response“ vom CRS und liest die Felder Abflugzeit, Ankunftszeit, Fluggesellschaft, Flugnummer, Klasse, Preis und Währung aller aufgeführten Flüge aus.
8. System zeigt in einer Tabelle alle Flüge unter Angabe dieser Informationen an.

In Kenntnis dieser Elementarprozesse kann mit jeder funktionsorientierten Messmethode leicht der funktionale Umfang bestimmt und mit Hilfe eines Erfahrungswerts für die Produktivität der zu erwartende Entwicklungsaufwand ermittelt werden. 

Alternativen:

• Expertenschätzungen
• Indirekte Schätzungen mit Story Points

Buchempfehlung: "Aufwandsschätzungen in der agilen Softwareentwicklung"

Methoden zur direkten und indirekten Aufwandsschätzung (2)

Indirekte Schätzungen mit Story Points

Eine direkte Schätzung des Entwicklungsaufwands (siehe: Expertenschätzungen) ist von den persönlichen Fähigkeiten des Schätzers abhängig und nicht von der Leistungsfähigkeit des Teams, das für die Entwicklung vorgesehen ist. Im Gegensatz zu einer direkten Schätzung ermitteln indirekte Methoden zunächst die Größe der zu entwickelnden Objekte oder Anforderungen und stellen diese anschließend in Relation zu Erfahrungswerten idealerweise des gleichen Teams aus früheren Sprints. 

Im Fall der Story Point-Methode bewerten Schätzer die Größe von User Stories, jedoch nicht in einer absoluten Maßeinheit sondern relativ zueinander. Beispiel: „Die Auswahl des Zielflughafens und Datums ist eine 1. Die Abfrage verfügbarer Flüge ist im Verhältnis dazu eine 3. Die Buchung eines ausgewählten Flugs ist dann eine 8.“ Die Skala für die zu vergebenden Story Points orientiert sich an der Fibonacci-Folge: 1, 2, 3, 5, 8, 13 und so weiter. Dadurch entfallen kleinteilige Diskussionen und Entscheidungen zwischen den zulässigen Werten werden erleichtert. Gleichzeitig macht die Skala jedoch auch deutlich, dass die Genauigkeit der Bewertung mit zunehmender Größe abnimmt.

Die Berechnung des voraussichtlichen Entwicklungsaufwands auf Basis von Story Points erfordert einen Erfahrungswert, wie viele Story Points das Team unter vergleichbaren Rahmenbedingungen je Inkrement bzw. Sprint umsetzen kann. Dieser Erfahrungswert wird Velocity genannt und nach jedem abgeschlossenen Sprint dadurch aktualisiert, dass die Größe der tatsächlich entwickelten Stories mit der dafür benötigten Zeit ins Verhältnis gesetzt wird.

Eine Aufwandsschätzung durch Story Points hat den Vorteil, dass sie schnell angewendet werden kann und von der aktuellen Leistungsfähigkeit des Teams und nicht einzelner Individuen ausgeht. Durch die permanente Nachkalibrierung der Velocity kann sich diese innerhalb von wenigen Sprints an Veränderungen beispielsweise in der Team-Zusammensetzung oder sonstiger Rahmenbedingungen anpassen.

Ein Nachteil der Methode ist die Detaillierung des Schätzobjekts: eine User Story, die eine Anforderung meist nur umgangssprachlich in einem Satz beschreibt. Unerwartete Komplexität, die erst bei der Umsetzung festgestellt wird, führt dann häufig zu einer Überschreitung des geschätzten Aufwands.

Alternativen:

• Expertenschätzungen
• Indirekte Schätzungen durch Bestimmung des funktionalen Umfangs

Buchempfehlung: "Aufwandsschätzungen in der agilen Softwareentwicklung"

Methoden zur direkten und indirekten Aufwandsschätzung (1)

Expertenschätzungen

Eine bewährte Methode, um sich dem notwendigen Aufwand zur Umsetzung von Anforderungen bzw. User Stories anzunähern, ist die Expertenschätzung. Ein oder auch mehrere Experten schätzen unabhängig voneinander den Aufwand auf Basis ihrer Erfahrungen mit vergleichbaren Aufgabenstellungen. Da diese Erfahrungen sehr unterschiedlich sein können und sich oft an den eigenen Fähigkeiten orientieren ist eine Mittelwertbildung über mehrere Schätzergebnisse naheliegend. Ein weiteres Problem dieser Methode ist neben der Subjektivität, dass Experten meist Mitglieder eines Entwicklungsteams sind und für die Dauer der Schätzung nicht produktiv zum Entwicklungsprozess beitragen können.

Bei der Delphi-Methode stellt ein Moderator zu Beginn mehreren Experten Details der zu schätzenden User Stories vor, die sie anschließend völlig unabhängig voneinander schätzen. Danach wertet der Moderator die Ergebnisse aus und präsentiert die Abweichungen. Diskussionen sind dabei unerwünscht, um eine Gruppendynamik durch dominante Experten zu vermeiden. Jeder Experte hat die Möglichkeit, seine Schätzung zu überdenken und gegebenenfalls zu verändern. Dieser Prozess wird so lange wiederholt, bis die Abweichungen eine Toleranzschwelle nicht mehr überschreiten. Ein Vorteil der Delphi-Methode liegt in der iterativen Verfeinerung der einzelnen Expertenschätzungen und der damit verbundenen meist höheren Genauigkeit. Ein Nachteil ist die noch größere zeitliche Bindung der Experten.

Alternativen:

• Indirekte Schätzungen mit Story Points
• Indirekte Schätzungen durch Bestimmung des funktionalen Umfangs

Buchempfehlung: "Aufwandsschätzungen in der agilen Softwareentwicklung"

Agile Prinzipien sind Methoden zur Risikominderung

Viele Risiken kommerzieller Softwareentwicklung können durch agile Prinzipien gemindert werden:

Risiko: Die Anforderungen des Auftraggebers werden nicht ausreichend abgedeckt. Seine Erwartungen beispielsweise an die Gebrauchstauglichkeit des Produkts werden nicht vollständig erfüllt.
Maßnahmen: Das geplante Produkt wird inkrementell entwickelt, das heißt in möglichst kurzen Zyklen, deren Ergebnis jeweils lauffähige Software ist, die vom Auftraggeber hinsichtlich der Erfüllung seiner Erwartungen überprüft werden kann. Der Auftraggeber, insbesondere seine fachlichen und technischen Experten, arbeiten eng und intensiv mit dem Entwicklungsteam zusammen.

Risiko: Ziele und Anforderungen des Auftraggebers verändern sich, bevor die Entwicklung abgeschlossen ist, beispielsweise infolge von Veränderungen des Marktes.
Maßnahmen: Ein Prinzip des Agilen Manifests lautet: "Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden." Agile Softwareentwicklung zeichnet sich grundsätzlich durch die Bereitschaft aus, neue oder geänderte Anforderungen zu berücksichtigen. Jedoch schließt dies nicht eine Einigung zwischen Vertragspartnern bezüglich der kaufmännischen Auswirkungen von Veränderungen auf ein Entwicklungsprojekt aus.

Risiken: Falsche Einschätzung des Entwicklungsfortschritts, Verzögerungen durch Kommunikationsprobleme, Verlust von Know-how durch Personalausfall.
Maßnahmen: Diese Risiken werden in der agilen Entwicklung durch ein hohes Maß an Teamarbeit gemindert. Tägliche kurze Meetings dienen der Diskussion aufgetretener Probleme, der gemeinsamen Einschätzung des Fortschritts und der Verteilung anstehender sowie, falls es sinnvoll erscheint, auch der Umverteilung begonnener Aufgaben. Die Vermeidung starrer Rollen- und Aufgabenzuordnungen macht das Team robust gegenüber dem Ausfall einzelner Mitglieder.

Risiko: Mehraufwand durch zu spät erkannte Qualitätsdefizite.
Maßnahmen: Ein Merkmal agiler Entwicklung sind automatisierte Prozesse zur täglichen Neuerstellung einer lauffähigen Anwendung. Dabei durchläuft der Code in der Regel eine automatisierte Codeanalyse, durch programmierte Komponententests wird die Funktionalität einzelner Komponenten überprüft und, soweit möglich, werden nach der Integration zu einer lauffähigen Anwendung Skripte zur Ausführung von Testfällen aufgerufen.

Risiko: Invalide Planung hinsichtlich des erforderlichen Personalaufwands, um den Entwicklungsauftrag in der notwendigen Zeit erfüllen zu können.
Maßnahmen: Diesem Risiko kann durch die Verwendung von Aufwandsschätzmethoden begegnet werden, deren Genauigkeit sich mit jeder Retrospektive verbessert. Solche Methoden werden in meinem Buch "Aufwandsschätzungen in der agilen Softwareentwicklung" beschrieben.

Das Buch zu Aufwandsschätzungen in der agilen Softwareentwicklung

Agile Softwareentwicklung und ein fest vereinbarter Liefertermin oder Festpreis schließen sich nicht aus. Im Gegenteil: Die Prinzipien agiler Softwareentwicklung erweisen sich als gute Maßnahmen zur Minderung typischer Risiken, denen Entwicklungsprojekte mit verbindlichen Vorgaben ausgesetzt sind.

Kritisch für die Erreichung von Projektzielen ist eine verlässliche Planung, die ohne großen Aufwand erstellt und im Fall geänderter Anforderungen flexibel nachjustiert werden kann. Bewährt haben sich unter diesen Rahmenbedingungen indirekte Aufwandsschätzungen auf Basis von Umfangsmessungen. Sie erfordern einen nach präzisen Regeln ermittelten Wert für den Umfang der funktionalen Anforderungen sowie einen Erfahrungswert für die eigene Produktivität unter vergleichbaren Rahmenbedingungen.

Zum Shop

Notwendig für die Bestimmung des funktionalen Umfangs sind Kenntnisse der gewählten Methode, beispielsweise der Function Point-, Data Interaction Point- oder COSMIC-Methode, sowie eine ausreichende Präzisierung der Anforderungen, beispielsweise eine Beschreibung durch Anwendungsfälle und Elementarprozesse. Unter diesen Voraussetzungen ist der Wert, den man erhält, eine valide Kennzahl für den Umfang der funktionalen Anforderungen. Er ist unabhängig von der Person, die ihn ermittelt, und bei jeder wiederholten Anwendung auf dieselben Anforderungen erhält man den gleichen Wert. 

Einen Erfahrungswert für die eigene Produktivität, das heißt den mit einer bestimmten Arbeitsleistung des eigenen Teams typischerweise implementierbaren funktionalen Umfang, erhält man durch regelmäßige Nachbetrachtungen fertiggestellter Inkremente bzw. Releases. Dabei setzt man den implementierten Umfang mit der dafür benötigten Arbeitsleistung ins Verhältnis. Die methodische Bestimmung des implementierten Umfangs basiert – je nach Methode - auf der Zählung von beispielsweise Elementarprozessen oder Datenelementen, die bei entsprechender Abbildung auf konstruktive Merkmale automatisiert werden kann. Ein einmal erstelltes Zählprogramm kann in kürzester Zeit den Umfang der implementierten Anwendung und durch Vergleich mit dem vorhergehenden Ergebnis den durch den letzten Entwicklungsprozess entstandenen Zuwachs des funktionalen Umfangs liefern.

Regelmäßig erhobene und gegenübergestellte Messwerte für Produktivität und Qualität (im einfachsten Fall die Fehleranzahl) helfen, Handlungsbedarf zu erkennen und die Wirksamkeit zuvor umgesetzter Verbesserungsmaßnahmen zu verifizieren.

Das Buch beschreibt, wie Umfangsmetriken in der Praxis einer an agilen Werten orientierten Softwareentwicklung gewinnbringend eingesetzt werden können, welche Unterschiede und Einschränkungen es gibt, wie die Genauigkeit der Aufwandsschätzungen mit jedem Sprint erhöht werden kann und wie automatisierte Messungen möglich sind. Es ist als E-Book, Paperback und Hardcover erhältlich (im Tredition-Buch-Shop oder bei Amazon.de).
 

Buchreihe "Produktivitätssteigerung in der Softwareentwicklung"

Die PASS-Gruppe setzt seit mehreren Jahren Kennzahlen als Grundlage ihres IT-Managements in über 10 unterschiedlichen Anwendungslandschaften mit mehr als 500 Kunden und über 250.000 Anwendern ein und veröffentlicht ihre Erfahrungen nun in Form einer Buchreihe. In einzelnen Bereichen belegen die regelmäßig erhobenen Kennzahlen eine um den Faktor 100 höhere Auslieferungsproduktivität als noch vor wenigen Jahren und sie zeigen auf, in welchen Bereichen weitere Verbesserungen möglich sind.

Warum Produktivität messen?

IT hat bereits nahezu alle Lebensbereiche durch fundamentale Innovationen verändert. Unsere Zukunft wird von der Virtualisierung und smarten Helfern, also mit Intelligenz ausgestatteten Dingen, dominiert werden. Software ist der Stoff, aus dem Innovationen entstehen. Softwareentwicklung ist eine Schlüsselkompetenz.

Für Unternehmen, die Software entwickeln, sind Produktivität und Qualität kritische Erfolgsfaktoren. Nur mit geeigneten Messmethoden, durch regelmäßige Messungen und eine schnelle Rückkopplung der Messwerte an das Team und an sein Management können einerseits der Aufwand geplanter Entwicklungen zuverlässig ermittelt und andererseits Produktivität und Qualität kontinuierlich verbessert werden.

Band 1: "Produktivitäts- und Leistungsmessung - Messbarkeit und Messmethoden"

Buchreihe "Produktivitätssteigerung in der Softwareentwicklung"

Das erste Buch der Reihe erläutert zunächst eine für die Softwareentwicklung praktikable Definition des Produktivitätsbegriffs und zeigt dadurch die Bedingungen auf, unter denen Produktivität überhaupt gemessen werden kann. Es beschreibt den Standard ISO/IEC 14143 als wichtige gemeinsame Basis aller modernen funktionsorientierten Messmethoden. Einige Methoden werden im Detail und anhand von Praxisbeispielen erklärt - bewährte wie auch neue – und ihre Vor- und Nachteile gegenübergestellt. Das Buch geht auf die Automatisierbarkeit von Messungen ein, zeigt jedoch auch ihre Grenzen auf, deren Überschreitung aufgrund einer zu starken Orientierung an konstruktiven Merkmalen an Stelle von Anwendungsfällen zu invaliden Messungen führt.

Ein weiteres Thema ist der Einfluss der Komplexität auf den zu messenden Umfang, die unterschiedliche Berücksichtigung der Komplexität durch verschiedene Messmethoden und die Grenzen der Messbarkeit durch funktionsorientierte Metriken, beispielsweise bei Systemen mit überdurchschnittlich hoher algorithmischer Komplexität.

Band 2: "Managementmodell, Aufwandsermittlung und KPI-basierte Verbesserung"

Das zweite Buch beschreibt ein Modell, das auf drei Leistungskennzahlen (Key Performance Indicators, KPIs) basiert: Produktivität (gemessen unter Anwendung der im ersten Buch beschriebenen Messmethoden), Kosten und Qualität. Es erklärt ihre zyklische Erhebung, ihre analytische Auswertung und Indikatoren, beispielsweise aus der Gegenüberstellung des zeitlichen Verlaufs von Produktivität und Qualität oder als Ergebnis methodischer Fehlerursachenanalysen, die zu Verbesserungsmaßnahmen in wichtigen Einflussbereichen der Softwareentwicklung, sogenannten Key Performance Areas (KPAs), führen. Um den Nutzen der Maßnahmen vorab einschätzen zu können liefert es Erfahrungswerte wie auch ein Verfahren zur Berechnung ihrer Wirksamkeit. Das beschriebene Modell ist ein Navigationsinstrument, das dem Management stets zeigt, in welche Richtung und mit welcher Geschwindigkeit es sich hinsichtlich seiner drei KPIs bewegt.

Die Bücher sind als E-Book, Paperback und Hardcover erhältlich (im PASS-Buchshop oder bei Amazon.de).

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.

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

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

Die Wirksamkeit von Verbesserungsmaßnahmen

In meinem Post Maßnahmen zur Produktivitätssteigerung habe ich Bereiche aufgeführt, die starken Einfluss auf die Produktivität haben. Für mögliche Verbesserungsmaßnahmen stellt sich in der Praxis oft die Frage, wie effektiv diese sind, d.h. ob der Aufwand zur Verbesserung in einem akzeptablen Verhältnis zum Nutzen steht.

Diagramm 1

Eine bedeutende Rolle spielt dabei der Wirkungsbereich (die Reichweite) einer Verbesserungsmaßnahme, d.h. wie groß der Anteil am gesamten Entwicklungsprozess ist, der von der Maßnahme beeinflusst wird. Beispiel: Eine Maßnahme, mit der die Produktivität in einem Teilbereich des Entwicklungsprozesses, der insgesamt nur die Hälfte des Gesamtaufwandes ausmacht (blauer Bereich), auf das Doppelte gesteigert wird, erhöht die Produktivität des gesamten Entwicklungsprozesses nur um ein Drittel. Erklärung: Produktivität und Aufwand sind reziprok, d.h. eine Erhöhung der Produktivität führt zu einer Reduzierung des Aufwands und umgekehrt (siehe: Messung der Produktivität in der Softwareentwicklung). Die beschriebene Maßnahme führt zu einer Aufwandsreduktion von 50% in 50% des gesamten Prozesses, d.h. 25% resultierende Aufwandsreduktion. Es verbleiben 3/4 des ursprünglichen Aufwandes, was aufgrund des reziproken Verhältnisses 4/3 der ursprünglichen Produktivität entspricht, also einer Steigerung um 1/3.

Diagramm 2

Um die effektiv wirksame Produktivitätsverbesserung mehrerer Maßnahmen einschätzen zu können spielt es eine Rolle, ob sich diese Maßnahmen gegenseitig beeinflussen. Solange sie unabhängig voneinander sind kann die Gesamtproduktivität leicht dadurch bestimmt werden, dass man für jede Maßnahme die Aufwandsreduktion ermittelt und diese in Relation zum Anteil am Gesamtprozess setzt. So erhält man den verbleibenden Restaufwand und dadurch auch die insgesamt wirksame Produktivitätserhöhung. Diagramm 2 zeigt zwei Maßnahmen zur Produktivitätssteigerung um 100%, die unabhängig voneinander wirken und jeweils nur Bereiche beeinflussen, die jeweils ein Viertel des Gesamtaufwands ausmachen (blau und grün). Der aus beiden Maßnahmen resultierende Gesamtaufwand beträgt noch 3/4 des ursprünglichen Aufwands, die Gesamtproduktivität 4/3, d.h. sie ist um 33% (1/3) höher.

Diagramm 3

Bei Verbesserungsmaßnahmen, deren Einflussbereiche identisch sind, die sich also auch gegenseitig beeinflussen, kann man die Aufwandsreduzierungen miteinander multiplizieren. Diagramm 3 zeigt das Beispiel zweier Maßnahmen mit jeweils einer Produktivitätsverdopplung im gleichen Bereich (blau). Es ergibt sich für den resultierenden Restaufwand 50% * 50% = 25% (ein Viertel) in einem Teilbereich, der vor Umsetzung der Maßnahmen 25% vom Gesamtaufwand ausgemacht hat. Insgesamt beträgt der Restaufwand damit noch 13/16, die Produktivität hat sich auf 16/13, also um ca. 23% erhöht.

Aus diesen Fallbeispielen gehen zwei Schlussfolgerungen hervor:

• Verbesserungsmaßnahmen sind umso effektiver, je größer ihre Auswirkungen auf den Gesamtprozess sind (Anteil am Gesamtaufwand).
• Die aus mehreren Maßnahmen resultierende Produktivitätsverbesserung hängt davon ab, wie sich diese gegenseitig beeinflussen. Meist gilt: Je unabhängiger sie wirken können, umso größer ist ihre Effektivität. In der Praxis ist dies schwer vorherzusagen. Daher kann vorab bestenfalls ein Intervall bestimmt werden, in dem die zu erwartende Verbesserung liegen wird.

Maßnahmen zur Produktivitätssteigerung

Erfahrungsgemäß wird die Produktivität in der Softwareentwicklung von folgenden Aspekten beeinflusst – in unterschiedlicher Ausprägung und ohne Anspruch auf Vollständigkeit:

• Wissen und Erfahrung der Mitarbeiter

• Ihre Motivation, insbesondere die Bereitschaft zur Produktivitätssteigerung

• Wissensmanagement, d.h. die Fähigkeit, den Mitarbeitern das erforderliche Wissen zur richtigen Zeit zugänglich zu machen

• Risikomanagement, d.h. die Fähigkeit, negative Einflüsse auf die Produktivität zu antizipieren und frühzeitig gegenzusteuern

• Konstruktive QS, beispielsweise durch vorgegebene Prozesse, Methoden und Richtlinien, die Verfahrenssicherheit geben, oder durch Standards und wieder verwendbare Komponenten, die den Neuentwicklungs- und Testaufwand reduzieren

• Automation. Im Bereich der Entwicklung durch Code-Generierung oder im Bereich der analytischen Qualitätssicherung durch Testautomation. So reduziert automatisiertes Testen den Testaufwand, erhöht gleichzeitig die Zuverlässigkeit der Testergebnisse und ermöglicht durch frühe und regelmäßige Tests eine Verbesserung der Auslieferungsqualität (siehe: Kann Qualitätssicherung die Produktivität erhöhen?)

In diesen Bereichen lohnt sich daher eine Suche nach geeigneten Verbesserungsmaßnahmen.

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.

Messung der Produktivität von IT-Dienstleistungen

Aus der Gesamtsicht eines Unternehmens wird die Produktivität von IT-Dienstleistungen durch die Gesamtleistung der folgenden drei Bereiche bestimmt:

• Effizienz: Betrachtet die Wirtschaftlichkeit hinsichtlich einer Kosten/Nutzen-Relation. Bei einer Betrachtung der Softwareentwicklung entspricht der Nutzen dem Output an produzierter Software und die Kosten entsprechen dem Entwicklungsaufwand (Input).
• Kapazität: Wird durch die Fähigkeit des Dienstleisters beeinflusst, flexibel auf Änderungen in der Nachfrage zu reagieren und gleichzeitig seine Mitarbeiter optimal auszulasten.
• Effektivität: Das Verhältnis von erreichtem zu definiertem Ziel. Wird durch externe Faktoren wie die Marktposition, das Image des Dienstleisters, die Einschätzung der Leistungsqualität und auch der Qualität von Interaktionen während der Leistungserbringung durch den Kunden, usw. beeinflusst.

Einflussfaktoren auf die Produktivität von IT-Dienstleistungen

Bei einer ganzheitlichen Betrachtung sind alle involvierten Bereiche der Organisation, d.h. neben der Delivery auch Marketing, Vertrieb, Disposition von Mitarbeitern, usw. zu betrachten. Die Herausforderung besteht darin, geeignete Metriken beispielsweise für die Bewertung der vom Kunden empfundenen Qualität zu finden.

Bei der Steuerung ist zu beachten, dass sich die verschiedenen Bereiche wechselseitig beeinflussen. Beispielsweise kann eine Verbesserung der Effizienz durch Standardisierung vom Kunden als negativ empfunden werden und sich so nachteilig auf die Effektivität auswirken. Mit welcher Gewichtung sich diese Bereiche auf die Gesamtproduktivität auswirken hängt außerdem von der Art der Dienstleistung, den Kunden bzw. Branchen, dem Geschäfts-/Abrechnungsmodell oder Vertragstyp, der Positionierung im Markt, usw. ab. Für weitere Informationen empfehle ich den PAC Research Report für das vom Bundesministerium für Bildung und Forschung geförderte Projekt „ProdIT“ (http://www.berlecon.de/studien/downloads/121212_ProdIT_Master_Final.pdf).

Bei einer Messung der Produktivität in der Softwareentwicklung wird häufig nur die Effizienz betrachtet (siehe: Messung der Produktivität in der Softwareentwicklung). Eine solche Vereinfachung ist möglich, wenn Einflüsse durch die Disposition bzw. Auslastung von Mitarbeitern vernachlässigbar sind und es sich um einen feststehenden Entwicklungsprozess handelt, bei dem Kriterien für die finale Ergebnisqualität definiert sind und eingehalten werden. Dient die Produktivitätsbetrachtung jedoch als Entscheidungsunterstützung über die reine Delivery hinaus, beispielsweise im Hinblick auf die Marktposition einer Standardsoftware oder die Qualität der Zusammenarbeit mit (Groß)Kunden, sollten dabei ggf. auch externe Faktoren wie die Erreichung der Kundenziele, Berücksichtigung neuer oder geänderter Anforderungen, Qualität und Zuverlässigkeit von Beistellleistungen, Transparenz von Zwischenergebnissen, usw. betrachtet werden. 

Ist die Function Point-Methode noch aktuell?

Wie in meinem Post Methoden zur Messung des Softwareumfangs dargelegt erfordert die Vergleichbarkeit von Kennzahlen zwischen verschieden großen Systemen eine Messung ihrer Größe, d.h. ihres Umfangs. Ebenso wie die Vorab-Ermittlung des Aufwands für ein geplantes Entwicklungsvorhaben. 

Die bekannteste Methode zur Analyse des funktionalen Umfangs (wie in der Norm ISO/IEC 14143 zum Functional Size Measurement beschrieben) ist seit 1979 die Function Point-Analyse (FPA). Aktuell ist die Methode standardisiert in der Norm ISO/IEC 20926:2009. Sie ist nun frei von Schätzungen, denn es wird nur gezählt und alle Kriterien für die Punktwerte sind festgelegt. Somit kommen durch verschiedene Personen durchgeführte Messungen stets zu dem gleichen Ergebnis, vorausgesetzt diese verfügen über ausreichendes Methoden-Know-how. 

Zählobjekte der Function Point-Analyse

Die Function Point-Methode orientiert sich an den Anwendungsfällen eines Systems und zählt Elementarprozesse, mit denen Daten über die Systemgrenzen hinweg ein- oder ausgegeben werden (EI = External Input, EO = External Output, EQ = External Inquiry), sowie Datenstrukturen in internen und externen Datenbeständen (ILF = Internal Logical File, EIF = External Interface File). Eine nach der klassischen Methode durchgeführte Function Point-Analyse erfordert eine genaue Kenntnis der Anwendungsfunktionalität. Dies kann aufwendig sein. Es gibt jedoch Ansätze für eine automatisierte Zählung der entsprechenden Objekte (siehe beispielsweise http://www.omg.org/spec/AFP/1.0/Beta1/PDF/). Diese erfordern jedoch eine genaue Kenntnis der den Elementarprozessen entsprechenden Codestrukturen und Namenskonventionen, da ansonsten konstruktive und keine funktionalen Merkmale der Anwendung gezählt werden. Dennoch lohnt der Implementierungsaufwand, denn einmal eingerichtet kann die Zählung nach Änderungen an der Anwendung ohne großen Aufwand wiederholt werden.  

Punktwert-Matrix für Strukturen in 
internen Datenbeständen

Ein genereller Nachteil der Function Point-Methode ist, dass Punktwerte durch dreistufige, nach oben offene Intervallskalen festgelegt sind. Bei der Zählung von Datenbeständen beispielsweise ergeben sich die Punktwerte aus einem dreistufigen Intervall für die Anzahl ihrer Datenelemente (DET = Data Element Type) und einem weiteren Intervall für die Anzahl der Feldgruppen (RET = Record Element Type). In der Folge erhalten beispielsweise alle Datenstrukturen mit mehr als 50 Datenelementen und mehr als einer Feldgruppe den selben Punktwert – ungeachtet der tatsächlichen Anzahl. Das ist grob und schränkt die Vergleichbarkeit von Umfangsmessungen ein.

Die meisten Unternehmen, die überhaupt Messungen des funktionalen Umfangs durchführen, setzen heute die Function Point Analyse ein. Leider sehr oft in Form von Näherungsverfahren wie Rapid, die völlig auf eine Komplexitätsbewertung verzichten und die Intervallskalen durch Durchschnittswerte ersetzen. Messungen zeigen jedoch, dass die Zählung von Elementarprozessen und Datenstrukturen ohne Berücksichtigung der Anzahl beteiligter Datenelemente bzw. ihrer Komplexität zu Einschränkungen bei der Vergleichbarkeit führt. Es gibt andere Messverfahren, die sich ebenfalls an der ISO/IEC 14143 orientieren, bei denen diese Unschärfe verbessert wurde. 

Kann Qualitätssicherung die Produktivität erhöhen?

Kein Zweifel: Intensives Testen erhöht die Qualität. Dabei hat manuelles Testen auch Risiken: Das Testergebnis ist oft von der jeweiligen Tagesform der Tester abhängig. Beim wiederholten Ausführen der selben Testfälle lässt meist die Aufmerksamkeit nach. Außerdem kostet die Arbeit der Tester Zeit und Budget. Durch den erhöhten Aufwand wird die Produktivität geringer.

Neben dem Qualitätsverständnis der Entwickler, der konstruktiven Qualitätssicherung durch Prozesse, Methoden, Tools, Frameworks, wieder verwendbare Komponenten, usw. ist Testautomation ein wichtiger Schlüssel zur Erhöhung der Qualität, ohne dass dies zu Lasten der Produktivität geht. Testautomation kann sogar zu einer Erhöhung der Produktivität führen, da dadurch viele Fehler früher erkannt werden (mutmaßlich mehr Fehler und wesentlich früher als beim manuellen Testen) und somit die Kosten zu ihrer Behebung niedriger sind. Bewährt haben sich in der Praxis die folgenden Maßnahmen:

• Kontinuierliche Integration aller vom Entwickler freigegebenen Komponenten zu einer lauffähigen Anwendung (automatisierter Build-Prozess). Dadurch wird permanent verifiziert, dass der Code auch kompilierbar ist, Referenzen auf beispielsweise Bibliotheken aufgelöst werden können, usw.

• Ausführung aller JUnit-Klassen, die von den Entwicklern erstellt wurden – im Rahmen der kontinuierlichen Integration.

• Durchführen einer toolgestützten Codeanalyse zur Überprüfung der vereinbarten Programmierrichtlinien. Dafür stehen heute sehr leistungsfähige Tools wie die Plattform Sonar zur Verfügung, die ebenfalls im Rahmen der kontinuierlichen Integration ausgeführt werden können (siehe auch: Regelmäßige Analyse der Codequalität mit Sonar)

• Automatisierte GUI-Tests (Black-Box-Tests), bei denen Skripte Eingaben in Web-Dialoge vornehmen, GUI-Elemente aktivieren und das Vorhandensein zugesicherter Ergebniswerte oder Zustände überprüfen. Hier haben sich Tools wie Sahi oder Selenium bewährt. Damit können komplexe Szenarien mit Anwendungsfällen definiert werden, die ein permanentes Funktionieren der Anwendung bei jedem neuen Build verifizieren helfen (Regressionstests). 

• Automatisierte Belastungstests, die das Verhalten einer Anwendung in Bezug auf eine Dauer- oder Überlast beispielsweise bezüglich der Nutzung durch viele konkurrierende Benutzer, der Verarbeitung großer Datenmengen oder einer hohen Zahl von Transaktionen analysieren.

Durch konsequenten Einsatz automatisierter Testmethoden lassen sich Qualität und Produktivität zweifellos deutlich verbessern. Je früher Fehler erkannt werden, umso geringer ist der Aufwand zu ihrer Behebung. Je höher der Automatisierungsgrad, umso geringer der Personalaufwand. Beides wirkt sich positiv auf die Produktivität aus.