Function-Point-Verfahren

Das Function-Point-Verfahren (auch -Analyse oder -Methode, kurz FPA) dient zur Bewertung des fachlich-funktionalen Umfangs eines Informationstechnischen Systems, im Folgenden als Anwendung bezeichnet. Das Ergebnis einer Function-Point-Bewertung wird als "Functional Size" bezeichnet und in der Einheit "Function Points", kurz fp, angegeben. Die FPA ist die am weitesten verbreitete Ausprägung verschiedener unter dem Begriff Functional Size Measurement zusammengefasster Bewertungsverfahren.

Function-Points werden in der Softwareentwicklung als Basis für Aufwandsschätzung, Benchmarking und allgemein zur Ableitung von Kennzahlen zur Produktivität und Qualität herangezogen. Eine Function-Point-Bewertung ist unabhängig von der zu Grunde liegenden Technologie der Anwendung.

Die Functional-Size wird bestimmt, in dem man die funktionalen Anforderungen an eine Anwendung in kleinste, für den Anwender sinnvolle Aktivitäten, die Elementarprozesse, zerlegt. Gleiche Elementarprozesse werden nur einmal gewertet. Jedem Elementarprozess wird ein definierter Punktwert zugeordnet. Die Summe der Punktwerte aller Elementarprozesse ergibt die Functional-Size.

Streng genommen ist die FPA bzw. ihr Ergebnis nicht als eine Messgröße zu betrachten, die Bezeichnungen der FPA als Softwaremetrik bzw. im Englischen als "Functional Size Measurement" sind insofern nicht ganz treffend. Richtigerweise sollte von einem Bewertungsverfahren gesprochen werden.

Standards

Allan J. Albrecht entwickelte die Function-Point-Analyse Ende der 1970er für das Unternehmen IBM^[1]. Das Verfahren hat sich im Laufe der Zeit in verschiedene Varianten entwickelt, die heute unter dem Begriff Functional Size Measurement zusammengefasst werden. Dieser ist durch die ISO-Norm ISO/IEC 14143 ^[2] definiert.

Aktueller Standard

In aller Regel wird mit der Bezeichnung Function-Point-Analyse, kurz FPA, die Variante der International Function Point Users Group (IFPUG) bezeichnet, die als ISO-Norm ISO/IEC 20926 ^[3] standardisiert ist. Der aktuelle ISO-Standard entspricht dem Standard der IFPUG in der Version CPM 4.3.1^[4], wobei CPM für "Counting Practices Manual" steht.

Für weitere Alternativen zur FPA siehe auch Functional Size Measurement.

Wesentliche Änderungen

Mit der Aufnahme des IFPUG-Standards in den ISO-Katalog zum ersten Mal im Jahre 2003 hat es gegenüber früheren Versionen eine wesentliche Änderung gegeben: der sogenannte Wertfaktor (im Standard Value Adjustment Factor, kurz VAF, im Deutschen manchmal auch als Wichtungsfaktor bezeichnet) ist im Regelfall nicht mehr anzuwenden, die Unterscheidung zwischen "unjustierten" und "justierten Function-Points" ist damit entfallen. Dies wurde von der IFPUG in ihrem Standard CPM 4.3.1 nachvollzogen.

Mit dem Wertfaktor sollten neben den fachlich-funktionalen Anforderungen auch nicht-funktionale Anforderungen im Function-Point-Wert berücksichtigt werden. Dies ist nach dem ISO-Standard ISO/IEC 14143 ^[2] jedoch nicht mehr zulässig. Auf die Anwendung des Wertfaktors wurde auch früher schon verzichtet, wenn etwa Function-Points als Grundlage für eine Aufwandsschätzung verwendet wurden, und diese nicht-funktionalen Anforderungen bereits im Aufwandsschätzmodell berücksicht sind. Dies ist etwa bei dem Aufwandsschätzmodell COCOMO der Fall.

Methode

Anwendersicht

Für die Bestimmung der Functional-Size ist die Anwendersicht ("User View") maßgeblich. Der Begriff des Anwenders (user) in der FPA entspricht konzeptuell dem Akteur in der Unified Modelling Language. Ein Anwender kann sowohl eine natürliche Person, eine andere Software als auch beispielsweise eine Maschine sein. Der Begriff der Anwendersicht ist deshalb keinesfalls wörtlich zu nehmen. Die Anwendersicht fokussiert sich darauf, dass bei der Bewertung nur diejenigen Funktionen der Software zu berücksichtigen sind, die der Unterstützung der jeweiligen Geschäftsprozesse dienen.

Identifikation der Transaktionen

Ein Elementarprozess ist definiert als die für den Anwender sinnvollste, kleinste Aktivität, die das System nach ihrer Ausführung in einem konsistenten Zustand lässt. Elementarprozesse werden nach drei Transaktionstypen ("Transactional Functions") unterschieden.

• Eingabe ("External Input", EI)
• Ausgabe ("External Output", EO)
• Abfrage ("External Inquiry", EQ)

Entscheidend ist dabei der Hauptzweck des Elementarprozesses. Eine Eingabe hat als Hauptzweck die Pflege eines internen Datenbestandes und die Verarbeitung von Daten, die von außerhalb der Anwendung stammen. Eine Ausgabe oder Abfrage haben den Hauptzweck der Präsentation von Informationen an der Anwendungsgrenze. Für eine Ausgabe ist zusätzlich gefordert, dass ihre Verarbeitungslogik mathematische Berechnungen oder Formeln, die Bildung abgeleiteter Daten, die Pflege eines internen Datenbestands oder eine Veränderung des Systemverhaltens beinhaltet.

Aus der Definition der Transaktionen ergibt sich, dass nur solche Elementarprozesse bewertet werden, die im Zusammenhang mit einem Datenfluss über die Anwendungsgrenze stehen.

Gleiche Transaktionen sollen nur einmal gewertet werden. Zwei Transaktionen gelten dann als gleich, wenn sie die gleichen Daten verwenden und die gleiche Verarbeitungslogik beinhalten, wobei kleinere Variationen nicht ausgeschlossen sind. Variationen gelten auf jeden Fall dann nicht mehr als "klein" in diesem Sinne, wenn den beiden Transaktionen zwei erkennbar unterschiedliche fachlich-funktionale Anforderungen zu Grunde liegen.

Funktionaler Hierarchiebaum

Beispiel für einen funktionalen Hierarchiebaum

Der Prozess der Identifikation der Transaktionen folgt weitgehend dem aus der Strukturierten Analyse bekannten Vorgehen. Deshalb liegt es nahe, das Ergebnis in Form eines funktionalen Hierarchiebaums darzustellen. Die Notation dieses funktionalen Hierarchiebaums ist nicht Teil des Standards, jedoch hat sich seine Verwendung in der Praxis weitgehend eingebürgert.

Identifikation der Datenbestände

Neben den Transaktionen bewertet die FPA auch die durch die Software verwalteten Datenbestände ("data functions"). Ein Datenbestand ist als eine Menge fachlich erkennbarer und logisch zusammengehöriger Daten definiert. Auch hier gilt, dass die Bewertung aus Anwendersicht erfolgen soll. Datenbestände werden weiterhin unterschieden in

• Interne Datenbestände ("Internal Logical File", kurz ILF) und
• Externe Datenbestände ("External Interface File", EIF).

Die Bezeichnungen sind sprechend: Interne Datenbestände sind solche, die innerhalb der bewerteten Anwendung gepflegt (schreibender Zugriff) werden. Externe Datenbestände werden von der bewerteten Anwendung nur referenziert oder gelesen, aber in einer anderen Anwendung gepflegt.

Ermittlung der Functional-Size für eine Anwendung

Für die Zuordnung des Punktwerts zu Transaktionen und Datenbeständen gibt es ausführliche Regeln im Standard, die sogenannten "Komplexitätsregeln". Der Punktwert für eine Transaktion ergibt sich aus der Anzahl der verwendeten Felder und der Zahl der in der Transaktion verwendeten Datenbestände. Für die Datenbestände wird der Punktwert aufgrund der Anzahl der enthaltenen Felder und der Anzahl von Feldgruppen bestimmt. Als Feldgruppe wird eine Menge fachlich zusammenhängender Datenfelder verstanden, zum Beispiel die Menge der Felder Anrede, Titel, Vorname und Nachname, die zusammen den Namen einer natürlichen Person darstellen.

Die folgende Tabelle zeigt die für die einzelnen Transaktionstypen und Datenbestandstypen möglichen minimalen, mittleren und maximalen Punktwerte:

Elementarprozess	Minimaler Punktwert	Mittlerer Punktwert	Maximaler Punktwert
Eingabe	3	4	6
Ausgabe	4	5	7
Abfrage	3	4	6
Interner Datenbestand	7	10	15
Externer Datenbestand	5	7	10

Die Summe der Punktwerte aller Transaktionen und Datenbestände ist dann die Functional-Size der Anwendung.

Functional-Size für Softwareanpassungen und -erweiterungen

Häufig ist die Bestimmung einer Functional-Size nicht für eine bestehende Anwendung gefordert, sondern soll zur Bewertung eines Projekts herangezogen werden, in dem eine neue Anwendung entsteht oder bestehende Anwendungen angepasst und erweitert werden. Im Standard gibt es hierfür einfache Regeln.

Die Functional-Size eines Neuentwicklungsprojekts wird mit dem Ergebnis der durch das Projekt gelieferten Anwendung gleichgesetzt.

Die Functional-Size eines Erweiterungsprojekts ergibt sich als Summe der Punktwerte aller neu hinzugefügten, geänderten und entfernten Transaktionen und Datenbestände. Dabei wird für ein Projekt jede Transaktion und jeder Datenbestand maximal einmal als geändert gewertet, unabhängig vom tatsächlichen Umfang der konkreten Änderungen. Die Zuordnung der Punktwerte zu den jeweiligen Transaktionen und Datenbeständen erfolgt entsprechend der oben beschriebenen Regeln für die Ermittlung der Functional-Size einer Anwendung.

Sowohl für Neuentwicklungs- als auch für Erweiterungsprojekte werden, soweit vorhanden, auch die Funktionen bewertet, die der Konvertierung der Daten aus früheren Versionen der Anwendung dienen.

Auch wenn diese Regeln auf den ersten Blick recht einfach erscheinen, haben sie sich in der Praxis bewährt und bieten eine gute Grundlage für die Bewertung von Erweiterungsprojekten, die in der industriellen Praxis der Softwareentwicklung heute bei weitem der häufigste Projekttyp sein dürften.

Rapid-Näherung

In der Praxis spielen die Komplexitätsregeln eine geringe Rolle, da weit verbreitet ein Näherungsverfahren, unter dem Namen "Rapid" bekannt, angewendet wird.^[5] Danach werden grundsätzlich einer Eingabe 4 fp, einer Ausgabe 5 fp, einer Abfrage 4 fp, einem Internem Datenbestand 7 fp und einem Externen Datenbestand 5 fp zugeordnet. Bei größeren Anwendungen und Projekten (etwa > 100 fp) wird davon ausgegangen, dass der aufgrund dieser Näherung entstehende Fehler gegenüber einer detaillierten Komplexitätsbewertung vernachlässigbar ist.

Beispiel

Zur Veranschaulichung dient ein kleines Beispiel anhand einer Anwendung, die die Planung, Organisation und Durchführung von Seminaren eines Seminarveranstalters unterstützen soll. Um das Beispiel überschaubar zu halten, stellen die im Folgenden dargestellten fachlich-funktionalen Anforderungen nur einen Ausschnitt der gesamten Anforderungen dar. Es sei darauf hingewiesen, dass sich in Teil 4 des CPM^[4] weitere ausführliche und vollständige Beispiele finden, die insbesondere auch das konkrete Vorgehen für die Identifikation der Transaktionen und Datenbestände erläutern.

Fachlich-funktionale Anforderungen

Der Kunde hat u.a. die folgenden konkreten Anforderungen formuliert:

Die Anwendung soll die Planung und Verwaltung von Seminarveranstaltungen (im Folgenden kurz Veranstaltungen) unterstützen. Dazu muss es möglich sein, eine Veranstaltung mit ihren relevanten Merkmalen anzulegen. Fehlende oder fehlerhafte Eingaben sollen auch später noch korrigiert werden können. Natürlich wird auch eine Übersicht der Veranstaltungen sowie eine Detailansicht für einzelne Veranstaltungen benötigt. Es sollen die folgenden Geschäftsfälle unterstützt werden:

• Stornierung einer Veranstaltung, für die es noch keine bestätigten Anmeldungen gibt
• Stornierung einer Veranstaltung, für die es bereits bestätigte Anmeldungen gibt
• Terminverlegung einer Veranstaltung

Bewertung

Für diese Anwendung werden die folgenden Transaktionen und Datenbestände identifiziert, wobei der Punktwert nach der Rapid-Näherung zugeordnet wird:

Elementarprozess	Erläuterung	Typ	Punktwert
Veranstaltungen	Datenbestand, in dem die Veranstaltungen mit ihren Merkmalen abgelegt sind	ILF	7
Veranstaltungsliste anzeigen	beinhaltet auch die Möglichkeit, nach bestimmten Kriterien zu filtern und sortieren	EQ	4
Veranstaltungsdetails anzeigen	zusätzlich wird abgeleitet aus der Zahl der Anmeldungen und der verbleibenden Zeit ein Seminarstatus berechnet und in Form einer Ampel angezeigt	EO	5
Veranstaltung anlegen	Neuanlage einer Veranstaltung mit allen Merkmalen	EI	4
Veranstaltungsdetails ändern	nicht explizit gefordert, aber für den Geschäftsprozess notwendig	EI	4
Veranstaltung ohne Teilnehmer stornieren	eine relativ einfache Verarbeitungslogik	EI	4
Veranstaltung mit Teilnehmern stornieren	besondere Verarbeitungslogik erforderlich	EI	4
Veranstaltungstermin verlegen	besondere fachliche Verarbeitungslogik	EI	4
Summe der bewerteten Anforderungen			36

Die letzten drei Transaktionen unterscheiden sich von der Transaktion "Veranstaltungsdetails ändern", weil für sie jeweils eine besondere Verarbeitungslogik definiert ist. Die Transaktion "Veranstaltungsdetails ändern" wurde aufgenommen, weil es möglich sein soll, fehlerhafte Eingaben bei der Neuanlage zu korrigieren. Dabei darf aber etwa ein bereits eingegebener Termin nicht mehr einfach überschrieben werden.

Aufwandsschätzung

Die Function-Point-Methode wurde von Allan J. Albrecht als Messgröße zur Bestimmung der Produktivität der Projekte der IBM definiert.^[1] Erst später versuchte man, Aufwandsschätzungen aus dem Function-Point-Wert abzuleiten.

Es liegt auf der Hand, dass sich der zu erwartende Aufwand für ein Softwareprojekt nicht alleine aufgrund der fachlich-funktionalen Anforderungen an die Anwendung bestimmen lässt. Hierzu sind vielmehr eine Reihe weiterer Aspekte zu berücksichtigen. Dazu gehören unter anderem:

• Nicht-funktionale Anforderungen
• Technologische Rahmenbedingungen
• Für die Entwicklung verfügbare Technologien, Sprachen und Werkzeuge
• Qualifizierung und Erfahrung des Projektteams
• Rahmenbedingungen im Projektumfeld

Mit Hilfe von Aufwandsschätzmodellen wie COCOMO versucht man, aus der Functional-Size und diesen weiteren Aufwandsfaktoren einen zu erwartenden Projektaufwand abzuleiten. Aufwandsschätzungen anhand der Functional-Size sind natürlich auch anhand von Referenzdaten durchführbar, die aber dafür genügend differenziert sein müssen und idealerweise die Rahmenbedingungen des zu schätzenden Projekts möglichst getreu abbilden. Die FPA ist also keine Aufwandsschätzmethodik an sich, sondern kann als Maß für die fachlich-funktionalen Anforderungen und in Verbindung mit Schätzmodellen oder Referenzdaten für Aufwandsschätzungen bereits zu frühen Projektzeitpunkten eingesetzt werden.

Kritik und Diskussion

Die häufig geäußerte Kritik an der FPA bezieht sich vor allem auf vier Aspekte:

• Aufwand
• Nachvollziehbarkeit bzw. Eindeutigkeit
• Aktualität
• Ungleichgewichtigkeit

Aufwand

Kritisiert wird häufig der mit einer Function-Point-Bewertung verbundene Aufwand.

Es ist anzunehmen, dass der Aufwand für die Durchführung einer Bewertung von verschiedenen Faktoren abhängt. Dies dürften vor allem die Art der Durchführung selbst sein (wie detailliert wird die Bewertung durchgeführt?), die Erfahrung und Qualifikation der durchführenden Personen und die Qualität und Vollständigkeit der Dokumentation der zu bewertenden Anforderungen bzw. Anwendung. Generell kann man heute davon ausgehen, dass der Aufwand für die FP-Bewertung im Bereich weniger Promille des zu erwartenden Aufwands für das Entwicklungsprojekt liegt.

In der 1990 durchgeführten Studie des MIT^[6] wurde ein Aufwand von im Mittel einer Stunde pro 100 fp für eine detaillierte Bewertung festgestellt. Dem steht ein typischer Entwicklungsaufwand von etwa 400 bis 1.600 Stunden pro 100 fp gegenüber.

Nachvollziehbarkeit und Eindeutigkeit

Befürchtet wird, dass die Regeln des Standards immer noch Spielraum für die Bewertung lassen und die Ergebnisse deshalb abhängig von den durchführenden Personen streuen können. Hierzu gibt es Untersuchungen mit unterschiedlichen Ergebnissen.

In der oben zitierten Studie des MIT^[6] wurde eine Streuung von 11% in den durch verschiedene Individuen ermittelten Ergebnissen festgestellt. Eine jüngere Studie von Tsoi^[7] kommt zu deutlich pessimistischeren Erkenntnissen: danach beträgt die Streuung bis zu 30%. Ein wesentlicher Unterschied beider Studien lag in der Größe der bewerteten Anwendungen (ca. 500 fp bei MIT, ca. 40 fp bei Tsoi) und in der Qualifikation der Testpersonen (die vom MIT untersuchten 54 Testpersonen hatten im Mittel 1,5 Jahre Erfahrung mit der FPA, während 15 der von Tsoi herangezogenen 21 Testpersonen Studenten waren und keine der Testpersonen über Vorkenntnisse der FPA verfügte.)

Die Problematik der Eindeutigkeit der Ergebnisse scheint also vor allem eine Frage der Qualifizierung der durchführenden Personen zu sein.

Aktualität

Ein häufig gemachter Einwand ist, dass die FPA aus der "Zeit der Großrechner" (also etwa 1970er bis 1980er Jahre) und der damals üblichen Strukturierten Analyse stamme, und deshalb für auf moderneren Analyse- und Designmethoden beruhende Software wenig Aussagekraft besitze.

Dem gegenüber steht, dass Function-Point-Bewertungen heute auch etwa zur Bewertung agiler, auf SCRUM basierender Projekte eingesetzt werden.

Wahrscheinlich liegt diesem Einwand die Verwechslung von Verfahren zur Analyse von Anforderungen einerseits und Verfahren für das Design von Software andererseits zu Grunde. Richtig ist, dass für eine Function-Point-Bewertung eine funktionale Zerlegung der fachlich-funktionalen Anforderungen erforderlich ist, jedoch ist es keine Bedingung, dass diese auch Grundlage für das technische Design der Anwendung wird.

Ungleichgewichtigkeit

Nach diesem Einwand "benachteiligt" die FPA Anwendungen mit einem hohen Anteil von Systemschnittstellen und Batchverarbeitung, da nach den Regeln der FPA nur diejenigen Funktionen berücksichtigt würden, die ein Anwender auch sehen könne.

Diesem Einwand liegt das Missverständnis des wörtlichen Verständnisses der Anwendersicht (siehe oben) zugrunde. Es spielt in der FPA jedoch keine Rolle, ob eine Programmfunktion im Rahmen der Dialogverarbeitung oder der Stapelverarbeitung, an einer Maschine-Mensch-Schnittstelle oder an einer Systemschnittstelle zu einer anderen Anwendung implementiert ist. Fehlerhafte Unterbewertungen von Systemschnittstellen und Batchverarbeitung sind häufig auf deren mangelnde fachlich-funktionale Spezifikation zurück zu führen.

Siehe auch

• Aufwandsschätzung
• COCOMO
• Delphi-Methode

Weblinks

• Deutschsprachige Anwendergruppe für Softwaremetriken und Aufwandschätzung e.V.
• Deutschsprachige Function-Point-Anwendergruppe (defpag.org) e.V.
• International Function Point Users Group
• Wiki zur Function-Point-Analyse (deutschsprachig)

Literatur

• Manfred Bundschuh, Axel Fabry: Aufwandschätzung von IT-Projekten, MITP Verlag 2004, ISBN 3-8266-0864-X
• Robert Hürten: Function-Point Analysis Theorie und Praxis, 2. erweiterte Auflage, expert verlag 2005, ISBN 3-8169-2398-4
• Benjamin Poensgen, Bertram Bock: Die Function-Point-Analyse - ein Praxishandbuch, Dpunkt Verlag 2005, ISBN 3-89864-332-8 (Neuauflage 2011 in Vorbereitung)

Einzelnachweise

1. ↑ ^{a b} Allan J. Albrecht: Measuring Application Development Productivity, Proc. of IBM Application Development Symp. In IBM Application Development Symp. (October 1979), pp. 83-92.
2. ↑ ^{a b} ISO/IEC 14143-1:2007: Information technology - Software measurement - Functional size measurement - Part 1: Definition of concepts, International Organization for Standardization, Geneva, Switzerland.
3. ↑ ISO/IEC 20926:2009: Software and systems engineering - Software measurement - IFPUG functional size measurement method 2009, International Organization for Standardization, Geneva, Switzerland.
4. ↑ ^{a b} IFPUG CPM 4.3.1 - Function Point Counting Practices Manual Version 4.3.1, International Function Point Users Group, Princeton Junction/NJ, USA, 2010. ISBN 978-0-9753783-4-2
5. ↑ Siehe Poensgen/Bock 2005, Seite 103.
6. ↑ ^{a b} Chris F. Kemerer: Reliability of Function Point Measurements, Center for Informations Systems Research, MIT, Oktober 1990.
7. ↑ Tsoi, Ho-Leung: To Evaluate The Function Point Analysis: A Case Study, in International Journal of The Computer, the Internet and Management Vo 13#1, pp 31-40, 2005.