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"

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