Aufwandsschätzungen in der agilen Softwareentwicklung

Einsatz von Methoden zur Messung des funktionalen Umfangs

Stefan Luckhaus

• Verlag: tredition
• Jahr: 2016
• ISBN:
  9783732365951
• Thema: Technik & Maschinenbau
• Thema: Maschinenbau Allgemein

Softwareentwicklung unterliegt Risiken, sobald sie an feste, vertraglich vereinbarte Rahmenbedingungen gebunden ist; Rahmenbedingungen wie die Lieferung eines festen Funktionsumfangs zu einem festen Preis und an einem vereinbarten Liefertermin. Viele dieser Risiken können durch die Prinzipien agiler Softwareentwicklung gemindert werden. Die Planung und Steuerung, um Entwicklungsprojekte innerhalb dieser Parameter navigieren zu können, erfordert außerdem Methoden zur Aufwandsschätzung. Damit diese die Vorteile agiler Entwicklung nicht mindern, müssen sie schnell anwendbar, im Idealfall automatisierbar sein und sich nach jedem Sprint selbst kalibrieren.Dieses 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.

Methoden zur Bestimmung des Entwicklungsumfangs

Function Point-Analyse

Die bekannteste Methode zur Messung des funktionalen Umfangs, die Function Point-Analyse (FPA), wurde von Allan J. Albrecht Ende der 70er Jahre entwickelt. Sie zählt die Elementarprozesse eines Anwendungsfalls und die dabei relevanten Datenstrukturen. Bei den Elementarprozessen unterscheidet man zwischen den folgenden Typen:

• Externe Eingabe (External Input, EI). Daten überschreiten im Rahmen eines Anwendungsfalls die Systemgrenzen von außerhalb kommend.
• Externe Ausgabe (External Output, EO). Daten überschreiten im Rahmen eines Anwendungsfalls die Systemgrenzen nach außen.
• Externe Abfrage (External Inquiry, EQ). Daten wie beispielsweise Abfragekriterien überschreiten die Systemgrenzen von außerhalb kommend und stoßen einen Abfrageprozess an, dessen Ergebnisse die Systemgrenzen nach außen überschreiten.

Bei der Zählung werden Elementarprozesse jeweils mit einem Punktwert berücksichtigt, der von der Anzahl der unterschiedlichen beteiligten Felder (Data Element Types, DETs) und der Anzahl der unterschiedlichen beteiligten Datenbestände (File Types Referenced, FTRs) abhängt. Diese Punktwerte sind in Matrizen mit dreistufigen, nach oben offenen Intervallskalen festgelegt (siehe Abbildung 3).

Abbildung 3: Punktwertmatrizen (1) der Function Point-Analyse

Bei Datenstrukturen, die relevant für die Elementarprozesse sind und daher ebenfalls gezählt werden müssen, wird zwischen den folgenden Typen unterschieden:

• Interner Datenbestand (Internal Logical File, ILF). Dabei handelt es sich um alle Teile des Datenhaushalts, die von der betrachteten Anwendung gepflegt werden, bei denen daher das Hinzufügen, Löschen oder Aktualisieren von Daten zu den Anwendungsfällen gehört.
• Externer Datenbestand (External Interface File, EIF). Dies sind Datenbestände, auf die seitens der betrachteten Anwendung nur lesend zugegriffen wird, das Hinzufügen, Löschen und Aktualisieren von Daten also nicht Gegenstand ihrer Anwendungsfälle ist.

Der Punktwert, mit dem eine Datenstruktur bei der Zählung berücksichtigt wird, hängt ab von der Anzahl unterschiedlicher Felder der Struktur (Data Element Types, DETs) und der Anzahl unterschiedlicher Feldgruppen (Record Element Types, RETs), aus denen die Struktur gebildet wird. Eine Feldgruppe ist eine Menge fachlich zusammengehörender Felder. Beispiele dafür sind der Name einer Person, der sich aus den Feldern Anrede, Titel, Vorname und Nachname zusammensetzt, oder die Adresse, im einfachsten Fall bestehend aus Straße, Postleitzahl und Ort. Eine Anschrift wäre also ein ILF bestehend aus den zwei Feldgruppen (RETs) Name und Adresse mit insgesamt 7 Feldern (DETs). Auch für Datenstrukturen sind die Punktwerte in Matrizen mit dreistufigen, nach oben offenen Intervallskalen festgelegt (siehe Abbildung 4).

Abbildung 4: Punktwertmatrizen (2) der Function Point-Analyse

Die hier beschriebene Variante der Function Point-Analyse wurde von der International Function Point Users Group (IFPUG) in der Norm ISO/IEC 20926 standardisiert [ISO/IEC 20926 2009]. Es gibt Varianten dieser Methode, die ebenfalls in ISO-Normen standardisiert sind, beispielsweise die Mark II FPA-Methode der UKSMA (United Kingdom Software Metrics Association) oder die Methoden der FISMA (Finnish Software Measurement Association) und der NESMA (Netherlands Software Metrics Users Association). Die Methode der IFPUG ist die weltweit bekannteste Methode und gilt als Standard für Messungen des funktionalen Umfangs.

Für das bereits im vorhergehenden Kapitel verwendete Beispiel des Anwendungsfalls „Search Flight“ würde die Berechnung wie folgt aussehen:

1.	Reisender gibt das Abflugdatum und die ersten Buchstaben des Reiseziels ein (Name oder Code):
	1 Externe Eingabe (EI) mit 1 FTR und 2 DETs = 3 FP
2.	System sucht in der Datenbank nach übereinstimmenden Flughäfen und zeigt eine Liste mit Namen und Codes an:
	1 Externer Datenbestand (EIF) mit 1 RET und 2 DETs = 5 FP
3.	Reisender wählt einen Eintrag aus der Liste aus und klickt auf den Button „Search“:
	1 Externe Eingabe (EI) mit 1 FTR und 1 DET (der ID des ausgewählten Listeneintrags) = 3 FP
4.	System sendet eine Nachricht vom Typ „Flight Search Request“ mit Datum und Flughafen-Code an das Computerreservierungssystem (CRS):
	1 Externe Ausgabe (EO) mit 1 FTR und 2 DETs = 4 FP
5.	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:
	1 Externe Eingabe (EI) mit 1 FTR und 7 DETs = 3 FP
6.	System zeigt in einer Tabelle alle Flüge unter Angabe dieser Informationen an:
	1 Externe Ausgabe (EO) mit 1 FTR und 7 DETs = 4 FP

In der Summe ergibt dies einen funktionalen Umfang von 22 Function Points (FP).

Liegt aus der letzten Retrospektive ein Erfahrungswert für die Produktivität vor, d.h. die Information, wie viele Function Points im Durchschnitt pro Arbeitseinheit umgesetzt werden können, lässt sich daraus der voraussichtliche Personalaufwand errechnen:

Bei einer angenommenen durchschnittlichen Produktivität von 5,5 FP/PT (Function Points je Personentag) ist somit für die errechneten 22 Function Points des Anwendungsfalls „Search Flight“ mit einem Entwicklungsaufwand von 4 Personentagen zu rechnen – für die gleichen Tätigkeiten und unter den gleichen Rahmenbedingungen, unter denen der Erfahrungswert für die durchschnittliche Produktivität gemessen wurde.

COSMIC-Methode

Die Überlegung, nicht Elementarprozesse zu zählen und die daran beteiligten Datenelemente zur Ermittlung der Punktwerte zu verwenden, sondern die Datenelemente selbst zu zählen führte in den 80er Jahren zur Entwicklung der Full Function Points-Methode (FFP-Methode). Basierend darauf wurde 1998 das Common Software Measurement International Consortium (COSMIC) gegründet [COSMIC 2015]. Die FFP- bzw. COSMIC-Methode wurde 2003 als Standard in der Norm ISO/IEC 19761 anerkannt [COSMIC FSM 2...

Inhaltsverzeichnis

• Cover
• Titelblatt
• Urheberrecht
• Inhaltsverzeichnis
• Merkmale und Bedeutung agiler Softwareentwicklung
• Methoden zur direkten und indirekten Aufwandsschätzung
• Methoden zur Bestimmung des Entwicklungsumfangs
• Messung des Referenzwerts für eine indirekte Aufwandsschätzung
• Fazit
• Glossar
• Literaturverzeichnis
• Über den Autor