Die Function-Point-Methode. Eine Einführung

Inhalt

1. Einführung

2. Ziel dieser Arbeit

3. Historie und Grundannahmen

4. Vorgehensweise
4.1. Festlegung des Zähltyps
4.2. Zählungsumfang / Festlegung der Systemgrenze
4.3. Function-Point-Zählung
4.4. Ermittlung des Einflussfaktors
4.5. Errechnung der gewichteten Function Points

5. Aufsetzende Aufwandsschätzungen

6. Grenzen

Literaturverzeichnis

1. Einführung

„Die Ergebnisse einer Umfrage der Standish Group (CIO.com, 18. Juni 2009), an der 400 Unternehmen teilnahmen, zeigen [..] eine ernüchternde Realität. Nur 32% aller IT-Projekte sind bezüglich der Einhaltung ihres Zeitplans, Budgets und ihrer Anforderungen erfolgreich. Ca. 24% werden als gescheitert betrach- tet, werden komplett eingestellt oder nach Abschluss nicht genutzt. 44% stehen in ihrem Verlauf vor Schwierigkeiten unterschiedlicher Komplexität. IT-Projekte können am Ende ein Vielfaches dessen kosten, was ursprünglich veranschlagt war.“¹ Laut diesen Umfrageergebnissen ist es noch immer ein großes Problem zuverlässige Aufwandsschätzungen für IT-Projekte durchzuführen. Ein vielfach bewährtes Verfahren ist die Function-Point-Methode, welche 1979 von Allan J. Albrecht bei IBM entwickelt und 2003 als ISO-Norm² standardisiert worden ist. Jährlich werden ca. 200 Personen als sog. „Function-Point-Zähler“ zertifiziert, welche speziell für die Anwendung dieser Methode geschult werden. „Eine Stu- die des MIT (Massachussetts Institute of Technology) zeigte, dass zertifizierte Function-Point-Zähler mit ca. 9 % Genauigkeit die gleiche Anzahl von Function Points ermittelt haben.“³ Das MIT bestätigt somit, dass die fachgerechte Anwen- dung dieser Methode durchaus zu belastbaren Schätzungen führt. Nicht zuletzt deshalb ist es in Italien gesetzlich vorgeschrieben, dass Softwareanbieter bei staatlichen Stellen den Funktionsumfang Ihrer Software in Function-Points an- geben müssen.⁴ Caper Jones, international äußerst anerkannter Experte im Be- reich der Aufwandsschätzung, fasst die Vernachlässigung dieser Aufgabe wie folgt zusammen: „Wer diese Software-Entwicklungsaufgabe nicht professionell wahrnimmt, handelt in seinem Beruf grob fahrlässig.“⁵

2. Ziel dieser Arbeit

Das Ziel dieser Ausarbeitung ist die Vorstellung der Function-Point-Methode und einiger Grundregeln, mit Hilfe derer die Schätzqualität gesteigert werden kann. An dieser Stelle muss darauf hingewiesen werden, dass seit der Erstel- lung der Function-Point-Methode (FPM) eine Vielzahl von Varianten entwickelt worden sind, welche zwar auf die ursprüngliche Methode aufbauen, sich jedoch in der Berechnung der Function-Points (FP) unterscheiden Innerhalb dieser Arbeit beziehen wir uns somit ausschließlich auf die Berechnungslogik der International Function Point Users Group (IFPUG).

Dieses Assignment bezieht sich des Weiteren auf eine konkrete Fallstudie, in welcher die Function-Point-Methode verwendet werden soll, um die geschätz- ten Personenmonate zu berechnen, die für die Realisierung eines zu entwi- ckelnden Systems im „Miet- und Service-Center“ (MSC) erwartet werden kön- nen. Textabschnitte, welche sich auf dieses konkrete Entwicklungsprojekt be- ziehen, werden im Folgenden mit einem grauen Balken am linken und rechten Seitenrand gekennzeichnet.

3. Historie und Grundannahmen

Nachdem A.J. Albrecht die FPM 1979 entwickelte, wurde 1986 die IFPUG gegründet, um die Weiterentwicklung der Methode zu gewährleisten und die internationale Standardisierung vorzunehmen.

Vier Annahmen, welche der Entwicklung der FPM unterlagen, haben ein An- wendungsprojekt als erfolgreich klassifiziert. Wenn ein Anwendungsprojekt

- zum geplanten Termin eingeführt wird,
- der Kostenplan eingehalten wird,
- das Ergebnis mit den Benutzeranforderungen übereinstimmt und
- die Benutzeranforderungen organisatorisch optimal gelöst werden.⁶

Das Ziel ist es eine für den Benutzer qualitativ gute Anwendung zu entwickeln und zu beantworten was das System leisten soll und nicht wie es das tun soll.⁷

Die FPM beleuchtet den zu leistenden Aufwand grundsätzlich aus Benutzersicht und schätzt den Aufwand (unabhängig von der einzusetzenden Technologie, den angewendeten Tools, Techniken und der Qualität des Personals) auf Grund- lage des Funktionsumfangs des zu entwickelnden Systems. Die ermittelten FP sollen allein die Komplexität des Systems wiederspiegeln.

4. Vorgehensweise

Die prinzipielle Vorgehensweise ist in drei Schritte gegliedert, welche in die Berechnung der bewerteten FP münden. Folgend können die ermittelten FP für die Aufwandsschätzung, wie bspw. der Berechnung des Personalaufwands in Personen- oder Mannmonate (PM bzw. MM), genutzt werden.

Schritt 1- Festlegung des Zähltyps

Schritt 2 - Zählungsumfang / Festlegung der Systemgrenze

Schritt 3 - Function-Point-Zählung

Schritt 4 - Ermittlung des Einflussfaktors

Schritt 5 - Errechnung der gewichteten Function Points

In den folgenden Abschnitten werden die einzelnen Schritte detailliert erläutert. Einen ersten Überblick verschafft auch die folgende Abbildung.

Abbildung in dieser Leseprobe nicht enthalten

Vorgehensweise zu FP-Berechnung nach FPM

4.1. Festlegung des Zähltyps

Die folgenden drei Zähltypen werden nach IFPUG unterschieden:

- Neuentwicklungsprojekt
- Weiterentwicklungsprojekt
- Anwendungssystem

Bei einem Neuentwicklungsprojekt wird das Anwendungssystem von Grund auf neu erstellt und beinhaltet hierdurch lediglich Function Points, welche der Zählung hinzugefügt werden müssen. Anders formuliert, erhöht sich der Projektumfang (Aufwand) und gleichzeitig erhöht sich auch die Funktionalität / Komplexität (des zuvor noch nicht existenten) Anwendungssystems.

Bei einem Weiterentwicklungsprojekt wird die Funktionalität eines bestehenden Anwendungssystems verändert. Hierbei kommt es zu einer Erhöhung des Projektumfangs (Aufwand), jedoch kann die Funktionalität des Anwendungssystems entweder erweitert oder aber auch verringert werden.

4.2. Zählungsumfang / Festlegung der Systemgrenze

Die IFPUG unterscheidet nach Counting-Scope und Application Boundary.

Der Counting-Scope identifiziert den Umfang der von einem Function Point Count umfasst werden soll. Dieser Scope kann (technisch gesehen) auch mehrere Anwendungssysteme umfassen, welche Aufgaben (Funktionen) des zu erstellenden Systems ausführen sollen (bspw. per Remote Procedure Calls).

Dahingegen legt das Application Boundary die Grenzen zwischen Benutzer und Anwendungssystem fest.

Diese Einteilungen sind wichtig, um im nächsten Schritt eine Einteilung von Funktionstypen vornehmen zu können, denn hierfür muss jede funktionale An- forderung genau in einer dieser Funktionstypen zugeordnet werden können.

[...]

¹ (The13, S. 1)

² Vgl. (functional size measurement method, 2009)

³ (Bundschuh M. F., 2004)

⁴ (Bundschuh M. , 2005, S. 23)

⁵ Vgl. (Jones, 1996)

⁶ Vgl. (Noth & Kretzschmar, 1984, S. 27)

⁷ Vgl. (Noth & Kretzschmar, 1984, S. 29)