Functional Sizing

Functional Sizing, kurz FS, ist der modernere Oberbegriff für Bewertungsverfahren wie die Function-Point-Analyse. Man hat damit versucht, sozusagen ein Dach für die verschiedenen „Sizing“-Ansätze in der Softwareentwicklung zu schaffen.

Der Begriff Functional in FS wird leicht missverstanden, ein Problem, dass auch im Zusammenhang mit Function-Points leider immer wieder auftaucht: Functional meint hier den Zweck oder die Aufgabe, hat also mit dem in der Softwareentwicklung gebräuchlichen Begriffen Funktion oder Funktionales Design nichts zu tun. Es geht also nicht um die Bewertung von Funktionen, sondern des Zwecks oder der Aufgaben, die eine Software erfüllt. Andere nennen das auch einfach „Anforderungen“. FS ist also nichts anderes, als die Bewertung des Umfangs von Anforderungen an Software.

Von der formalen Seite her ist Functionals Sizing als ISO-Standard ISO/IEC 14143 definiert. Dieser Metastandard hat selbst keine Bedeutung für die Praxis, sondern definiert, welche Anforderungen Standards zum Functional Sizing erfüllen müssen. Insgesamt sind heute fünf verschiedene FS-Standards als ISO-Standard hinterlegt:

  • IFPUG Functional size measurement method – ISO/IEC 20926:2009, vulgo: Function Point Analysis (FPA)
  • COSMIC Functional size measurement method – ISO/IEC 19761:2003, vulgo: Full Function Points (FFP)
  • MK II Function Point Analysis – ISO/IEC 20968:2002
  • NESMA Function Points – ISO/IEC 24570:2005
  • FISMA Function Points – ISO/IEC 29881:2010

Es gibt auch FS-Verfahren, die nicht formal standardisiert sind, wie etwa die Use Case Points (UCP), von denen es im wesentlichen zwei Versionen gibt (Kerner, Frohnhof).

Jetzt kann und sollte man die Unterschiede, Vor- und Nachteile und Anwendungsgebiete dieser Verfahren natürlich diskutieren. Andererseits: In der Praxis ist das wesentliche Kriterium für eine Entscheidung natürlich die Verbreitung am Markt, denn letztlich sollen die mit der Bewertung gewonnenen Ergebnisse ja mit anderen Unternehmen und Projekten verglichen werden.

Hier hat die „klassische“ FPA ganz sicher die Nase weit vorn. In einzelnen Anwendungsbereichen kann COSMIC eine Alternative sein. Im deutschsprachigen Raum spielen dagegen die drei nationalen Derivate (MKII – Großbrittanien, NESMA – Niederlande, FISMA – Finnland) überhaupt keine Rolle.

Story Points gehören trotz ihres ähnlich klingenden Namens übrigens nicht in die Klasse der Functional-Sizing-Verfahren. Sie dienen im Rahmen des SCRUM-Prozesses ausschließlich der Team-internen Aufwandsschätzung für einzelne Sprints.

Median, Mittelwert oder gewichtetes Mittel?

Wenn es um den Vergleich von Portfolios von Projekten geht, etwa in Bezug auf ihre Produktivität, stellt sich immer die Frage, welches denn die geeignete Bezugsgröße dafür ist. „Der Mittelwert“ ist die wohl häufigste Antwort, wenn man jemand danach fragt. Aber ist das in diesem Fall auch richtige Kenngröße? Welche anderen sinnvollen Kenngrößen gibt es?

Um diese Fragen zu beantworten, habe ich in dieser EXCEL-Datei ein kleines Beispiel zusammengestellt. Es enthält die Functional Size und den Aufwand für eine Stichprobe von 55 Projekten.

Mittelwert – keine gute Wahl

Mit „Mittelwert“ ist praktisch immer der Mittelwert einer Gauss’schen Normalverteilung gemeint. Dieser bestimmt sich als Quotient aus der Summe der Werte dividiert durch ihre Anzahl. Wenn ich also für zwanzig Projekte die Produktivität gemessen habe (etwa in fp/pm), dann addiert man die einzelnen Werte auf und teilt die Summe durch 20 – das Ergebnis ist der Mittelwert.

Die Rapid-Näherung

Um sich die eigentlich immer mühselige und manchmal fast unmögliche Arbeit des Abzählens der Felder (DETs), Feldgruppen (RETs) und referenzierten Datenbestände (FTRs) zu sparen, wenden vielen Function-Point-Experten die sogenannte Rapid-Näherung an.

Dabei werden den Transaktionen und Datenbeständen jeweils fest die folgenden Punktwerte zugeordnet:

  • Eingaben (EI): 4 fp
  • Ausgaben (EO): 5 fp
  • Abfragen (EQ): 4 fp
  • Internen Datenbeständen (ILF): 7 fp
  • Externen Datenbeständen (EIF): 5 fp

Das sind also bei den Transaktionen die Werte jeweils für die mittlere Komplexität und bei den Datenbeständen jeweils für die niedrigste Komplexität. Die Verwendung dieser Werte hat sich bereits vor vielen Jahren eingebürgert.