UD - Logo

Einsatzmöglichkeiten der Function Point Analyse

Dr. Uwe Doetzkies
erzeugt: 20.01.2014
letzte Änderung: 20.01.2014 
Dr. Uwe Doetzkies

Ergebnis (Zusammenfassung)

Obwohl die Function-Point-Analyse  hauptsächlich  dazu dient, ein Maß für die erwartete Komplexität einer Software (der fachlich-funktionale Umfang) zu liefern, lässt sie sich in der Praxis für eine Anzahl davon abgeleiteter Fragestellungen verwenden:

Einleitung

Die Function-Point-Analyse wurde ursprünglich bei IBM zur Messung der Produktivität der Software-Entwicklung entwickelt. Um Produktivität messen zu können ist es notwendig, das Produkt in geeigneter Weise zu bewerten. Die Wertzahl muss so beschaffen sein, dass verschieden große oder komplexe Produkte unterschiedliche Werte liefern, die aber in einem (angenommenen) konstanten Zusammenhang zu ihrer wahren Größe stehen.
Anschließend kann für jede Entwicklung die Produktivität durch Vergleich mit der benötigten Zeit ermittelt werden.

Function Points

Der fachlich-funktionale Umfang, wie dieser Wert in der Wikipedia beschrieben wird, wird in Function Points ausgedrückt.
Als ich Ende des vergangenen Jahrtausends erstmalig mit Function Points in Berührung kam, war diese Methode fast nur "Insidern" bekannt. Die wahre Bedeutung erschloss sich mir - und vielleicht anderen Anfängern - noch nicht, da ich zu sehr versucht war, die einzelnen Function Points im fertigen Programm zu "entdecken". Als Software-Entwickler habe ich ein Indiz gesucht, dass wieder ein Function Point fertig implementiert wurde. Eine - von heute zurückblickend - naive Sicht auf die Methode.

Projektbewertung

Nach der Lektüre des Buches "Function-Point-Analyse" (s. Quellen) um 2006, hatte ich ein Werkzeug in der Hand, den Umfang von Programmen zu bestimmen. Für meine Entwicklungsarbeiten half mir das aber noch nicht weiter.
Eines Tages jedoch erhielt ich den Auftrag, für ein neues Projekt ein Konzept (ggf. mit Alternativen) zu erarbeiten und dazu eine Aufwands- und Terminschätzung abzugeben. Das ganze sollte dazu dienen, einem Kunden einen Lösungsvorschlag zu präsentieren inkl. eines fundierten Kosten- und Terminangebotes.
Das Erstellen des Konzeptes war nicht das Problem, eine Aufgabe, mit der ich bereits promoviert hatte. Dass bei der Konzeption automatisch auch Alternativen anfallen, ist auch normal - nur wurden diese jetzt nicht intuitiv selektiert, sondern in ihrer Gesamtheit aufgehoben.
Doch wie konnte ich nun dem Management Aufwände und Termine zeigen? Genau in jenem Moment verstand ich den Sinn der Function Points. Sie sind das gesuchte Maß zum Vergleich von Lösungsalternativen und zur Bewertung des Umfangs eines Projektes. Nun musste ich nur noch mein Konzept und die Alternativen "nach Buch" bewerten und die ermittelten Werte in eine Excel-Tabelle eintragen - und ich hatte die gesuchten Zahlen.
Die nächste Schwierigkeit wartete schon: das eben Erkannte dem Management verständlich zu machen - aber das ist eine andere Aufgabe.

Aufwandsschätzung

In dem Werk von Poensgen/Bock finden sich Angaben, wie sich Function-Points in Entwicklungstage umrechnen lassen, auch mit dem Hinweis, dass die angegebene Formel nur für ein bestimmtes Unternehmen (IBM) gilt. Daher musste diese Formel zuerst einmal validiert werden.
Diese Validierung kann auf zwei Arten erfolgen:
 Im Ergebnis erhält man eine Umrechnungsformel für das eigene Unternehmen, nach Abschluss des Projektes lassen sich auch hier Korrekturen vornehmen.
(*) Es ist klar, dass alle gefundenen Werte auch irgendwo in das Projekt gehören, dass es also auch Argumente dafür gibt, diese Werte einfach mit zu berücksichtigen. Dies muss dann aber auch wieder für alle bewerteten Projekte einheitlich erfolgen - und gleichzeitig zu den Informationen für das zu bewertende Projekt führen. Diese Vergleichbarkeit herzustellen - das ist nicht so einfach wie es scheint.

Angebotserstellung

Klar, mit einem Zahlenwert in der Hinterhand lässt sich gut rechnen. Angenommen, wir erhalten für ein Projekt einen berechneten Aufwand von 10 Personentagen und wissen, dass wir die Arbeit auf zwei Entwickler aufteilen können, dann veranschlagen wir noch einen gewissen Kommunikationsaufwand für die Entwickler, einen Prozentsatz Reserve und (für dieses Projekt) unproduktive Zeit und können so zu einer Termin- und Kostenschätzung kommen.

Angebotsprüfung

Als freier Software-Entwickler stößt man auch manchmal auf Projektangebote, die zeitlich begrenzt sind. Ausschreibungen der Art "Suchen jemanden, der xyz macht - Umfang 20 Tage" sind nicht selten. Häufig ist xyz in der Ausschreibung nicht genau beschrieben, hier kann nur die persönliche Erfahrung - oder eine Nachfrage - weiterhelfen. Mit etwas genaueren Informationen lässt sich eine grobe Abschätzung der Function Points dieses Auftrages berechnen. Wie lange man braucht um einen FP zu bearbeiten, kann man durch Analyse der eigenen Projekte ermitteln, bei mir sind es ca. 5h/FP (das lässt sich nun wieder in Euro/FP umrechnen, aber solche Angaben wollte noch niemand bei einer Projektbewerbung erfahren).
Die so berechneten Werte erlauben dann die Beurteilung, ob die Aufgabe in der zur Verfügung stehenden Zeit überhaupt erledigt werden kann.

Ausblicke

Das in Poensgen/Bock beschriebene Verfahren ist inzwischen weiter verbessert und normiert worden (ISO/IEC 20926:2009). Die Normierung verspricht eine vom Prüfer weitgehend unabhängige Berechnung der Function Points. Ungeachtet dessen bleiben natürlich die Einflüsse des konkreten Konzeptes auf das Ergebnis der Analyse und die Einflüsse der konkreten Entwicklungsparameter auf Aufwands- und Kostenschätzungen. Doch auch dafür sind Methoden bekannt.
Weiter lässt sich eine modifizierte Form der Function-Point-Analyse zur anwenderorientierten Leistungsmessung von informationsverarbeitenden Systemen einsetzen, wie ich es in meinem Beitrag vorschlage.

Quellen

Kommentar senden