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 standardisiert ist. Der aktuelle ISO-Standard entspricht dem Standard der IFPUG in der Version CPM 4.3.1, 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 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ücksichtigt sind. Dies ist etwa bei dem Aufwandsschätzmodell COCOMO der Fall.

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

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", kurz 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:

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. Danach werden grundsätzlich einer Eingabe 4 fp, einer Ausgabe 5 fp, einer Abfrage 4 fp, einem internen 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.

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:

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.

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 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 wurde eine Streuung von 11 % in den durch verschiedene Individuen ermittelten Ergebnissen festgestellt. Eine jüngere Studie von Tsoi 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ückzuführen.