Function-Point-Analyse - Benjamin Poensgen - E-Book

Function-Point-Analyse E-Book

Benjamin Poensgen

0,0

Beschreibung

Bei der Entwicklung von Software kommt es nicht nur darauf an, ein qualitativ hochwertiges Produkt zu erstellen, sondern auch dessen Entwicklungsdauer und -kosten im Griff zu behalten. Mithilfe der Function-Point-Analyse (FPA) kann schon zu einem frühen Zeitpunkt der Entwicklung der Aufwand für die zu erstellende Anwendung geschätzt werden. Nach einer Einführung in die FPA wird das konkrete Vorgehen anhand eines Beispiels dargestellt. Dabei werden Tipps für die Zählpraxis gegeben und Vorgehensalternativen aufgezeigt. Die 2. Auflage ist auf den Function-Point-Standard 4.3 aktualisiert worden.

Sie lesen das E-Book in den Legimi-Apps auf:

Android
iOS
von Legimi
zertifizierten E-Readern
Kindle™-E-Readern
(für ausgewählte Pakete)

Seitenzahl: 214

Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:

Android
iOS
Bewertungen
0,0
0
0
0
0
0



Function-Point-Analyse

Dr. Benjamin Poensgen ist Geschäftsführer der QuantiMetrics GmbH, Wiesbaden. Nach seinem Physikstudium war er in der Softwareentwicklung und im Marketing bei verschiedenen Software-herstellern in Deutschland und den USA tätig. 1996 erwarb Dr. Poensgen als einer der ersten deutschsprachigen Function-Point-Experten das Zertifikat als geprüfter Function-Point-Spezialist (CFPS). Seitdem hat er zahlreiche Großunternehmen in der Einführung der Function-Point-Analyse und von Kennzahlensystemen für die Anwendungsentwicklung beraten und die Durchführung von Benchmarking-Analysen verantwortet.

Function-Point-Analyse

Ein Praxishandbuch

2., aktualisierte Auflage

Benjamin Poensgen

Benjamin [email protected]

Lektorat: Christa PreisendanzCopy Editing: Ursula Zimpfer, HerrenbergHerstellung: Nadine ThieleUmschlaggestaltung: Helmut Kraus, www.exclam.deDruck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn

Fachliche Beratung und Herausgabe von dpunkt.büchern im Bereich Wirtschaftsinformatik: Prof. Dr. Heidi Heilmann · [email protected]

Bibliografische Information der Deutschen NationalbibliothekDie Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:Buch 978-3-89864-762-5PDF 978-3-86491-163-7

2., aktualisierte Auflage 2012Copyright © 2012 dpunkt.verlag GmbHRingstraße 19B69115 Heidelberg

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Vorwort zur 2. Auflage

2009 wurde die neue Version CPM 4.3.1 des Function-Point-Standards der IFPUG (International Function Point Users Group) veröffentlicht, die seit Anfang 2010 anzuwenden ist. Nach fünf Jahren war dies für mich ein Anlass, eine neue Auflage unseres Buches in Angriff zu nehmen.

2010 war auch das Todesjahr von Allan J. Albrecht (1927–2010). Sein Name ist untrennbar mit der Function-Point-Analyse verbunden. Als Mitarbeiter von IBM entwickelte er in den 1970er-Jahren die Function-Point-Analyse zur Bewertung der Produktivität von Softwareprojekten [Albrecht 79]. Warum überhaupt die Produktivität messen?, fragt Albrecht in diesem Artikel und gibt selbst die Antwort: »Sind wir so gut, wie wir nur sein können? Sind wir wettbewerbsfähig? Verbessern wir uns? ... Produktivitätsmessungen helfen diejenigen Faktoren zu identifizieren und zu optimieren, die die Produktivität verbessern, und helfen gleichzeitig die Dinge zu vermeiden, die für die Produktivität schädlich sind.«

Was hat sich in der 2. Auflage des Buches geändert? Der Standard ist mit seiner neuen Version CPM 4.3.1 erfreulich einfacher geworden. Dies schlägt sich in einem tatsächlich kürzeren Kapitel 3 nieder, in dem das Regelwerk beschrieben wird. Auch die Terminologie hat sich teilweise geändert. Aus dem »unjustierten Function-Point-Wert« wurde z.B. die »Functional Size«. Ich habe versucht, diese Änderungen vollständig umzusetzen.

Das Kapitel 4, das in der ersten Auflage nur ein Beispiel behandelte, habe ich jetzt um zwei weitere Beispiele ergänzt. Diese behandeln die Bewertung von Anforderungen an eine Neuentwicklung sowie von Anforderungen für eine Weiterentwicklung eines bestehenden Systems. Letzteres dürfte im Alltag eines Function-Point-Experten wohl die mit Abstand häufigste Situation sein.

Eingegangen sind auch zahlreiche kleinere Anpassungen und Verbesserungen, die vor allem auf Rückmeldungen unserer Leser und auf Erfahrungen in unseren Ausbildungsseminaren zurückgehen.

Last, but not least: Mein Koautor der ersten Auflage, Bertram Bock, hat sich schon vor mehreren Jahren neuen beruflichen Aufgaben außerhalb der Softwareentwicklung gestellt. Das hat die Arbeit für mich nicht leichter gemacht. Die Freiheit, sich nicht abstimmen zu müssen, kann nicht die dadurch auch fehlenden guten und kreativen Ideen und die kritischen Rückmeldungen ausgleichen.

Ein kleiner Hinweis noch in eigener Sache: Im vergangenen Jahr erschien das von Hans-Jürgen Plewan und mir verfasste Buch »Produktive Softwareentwicklung« [Plewan & Poensgen 11]. Sie finden dort u.a. eine ausführliche Diskussion der Einordnung der Function-Point-Analyse in den Kontext der Produktivitätsund Qualitätsverbesserung von Softwareprojekten. In dem hier vorliegenden Buch habe ich daher, wie in der ersten Auflage, den Schwerpunkt auf dem Function-Point-Verfahren selbst belassen.

Wiesbaden, im März 2012Benjamin Poensgen

Vorwort

Die Function-Point-Analyse (FPA) hat in Deutschland einen schlechten Ruf. Bis heute stößt man regelmäßig auf Artikel in Fachzeitschriften, die ihr kein gutes Zeugnis ausstellen. Zu den am häufigsten genannten Kritikpunkten gehören: Sie funktioniere nur für Dialoganwendungen, nicht aber für Batchprogramme, sie funktioniere nur mit »alten« Programmiersprachen wie Assembler und Cobol, nicht aber mit C oder gar mit objektorientierten Sprachen, und nicht zuletzt, sie sei in der Anwendung zu aufwändig.

Forscht oder fragt man einmal nach, so stellt sich schnell heraus, dass der oder die Autoren vom »Hörensagen« berichten oder aus anderen Quellen »zitieren« und selbst eigentlich kaum oder sogar keine Erfahrung mit der Anwendung der FPA besitzen. Aber auch Fachliteratur und Lehrbücher scheinen weitgehend auf dem Stand der 1980er Jahre stehen geblieben zu sein. Die Beschränkung der Darstellung auf ältere Standards und die ausschließliche Betrachtung der FPA als Aufwandsschätzverfahren entsprechen nicht mehr dem heutigen Stand.

Die Function-Point-Analyse entwickelt sich weltweit, und zunehmend auch im deutschsprachigen Raum, zu einer Standardmessgröße für den fachlichen Funktionsumfang von IT-Anwendungen. Sie wird für Projekt- und Kostenkalkulationen, zur Bewertung von Projektangeboten externer Lieferanten, im IT-Controlling und für Wertanalysen von IT-Anwendungen eingesetzt. Wie jedes Messverfahren erfordert die FPA bei den durchführenden Gutachtern oder »Function-Point-Experten« eine entsprechende Ausbildung und vor allem Erfahrung. Sie ist in der Anwendung aber dann auch nicht aufwändiger als andere Bewertungsverfahren. Es ist also Zeit für ein wirklich aktuelles Buch zur Function-Point-Analyse.

Das Buch richtet sich an alle, die in der Praxis mit der FPA zu tun haben oder zu tun haben werden. Für angehende FP-Experten soll es eine erste theoretische Grundlage bilden. Allen anderen, seien es Projektleiter, IT-Controller, Mitarbeiter im IT-Einkauf, Manager usw., soll es eine erste Einführung sowie eine Referenz für das Verständnis der FPA und ihrer Anwendungen liefern. Für den Leser, der die FPA bereits kennt, mag dieses Buch zur Auffrischung dienen; vielleicht steuert es selbst für einen »alten FP-Hasen« noch den einen oder anderen neuen Aspekt bei. Wir freuen uns natürlich, wenn unser Buch auch in der Ausbildung zum Einsatz kommt, obwohl wir bei der Abfassung bewusst die wissenschaftlichen Aspekte zugunsten der Praxisnähe zurückgestellt haben.

Wir sind beide selbst seit mehreren Jahren als Function-Point-Experten tätig. Benjamin Poensgen hat als einer der ersten deutschsprachigen FP-Experten bereits 1996 das Zertifikat als »Certified Function Point Specialist« (CFPS) erworben. Bertram G. Bock kennt die FPA aus eigener Erfahrung und Anwendung seit 1999. Jeder von uns hat in den vergangenen Jahren mehrere hundert Function-Point-Analysen für Projekte und Anwendungen in verschiedenen Unternehmen und Branchen durchgeführt. Gemeinsam mit unseren Kollegen der QuantiMetrics GmbH, Wiesbaden, haben wir ein Trainingsprogramm für angehende FP-Experten entwickelt und in den vergangenen drei Jahren mehrere hundert Mitarbeiter von Banken, Versicherungen und Großunternehmen aus den Logistik- und Telekombranchen geschult.

Unsere Erfahrungen wollen wir mit diesem Buch weitergeben. Dabei haben uns ganz wesentlich unsere Kollegen aus der QuantiMetrics GmbH unterstützt und eigene Erfahrungen eingebracht. Für ihre kritischen Anmerkungen, Hinweise, Korrekturen, inhaltlichen Beiträge und Formulierungshilfen danken wir vor allem Brigitte Hansen, Eva M. Schielein, Daniel Hoffmann und Engin Sirma. Nicht zuletzt danken wir Frau Prof. Dr. Heidi Heilmann, die dieses Buch seitens des Verlages fachlich betreut hat, für die intensive Auseinandersetzung mit unserem Manuskript und die zahlreichen kritischen und konstruktiven Hinweise.

Wiesbaden, im August 2005Benjamin Poensgen, Bertram G. Bock

Inhaltsverzeichnis

1       Einleitung

2       Einführung in die Function-Point-Analyse

2.1    Anwendungsgebiete von A bis Z

2.2    Wie alles anfing ...

2.3    Woher kommt der Name »Function Points«?

2.4    Der neue Standard IFPUG CPM 4.3.1

2.5    Was bewertet die FPA?

2.6    Grundprinzip Funktionsmodellierung

2.7    Transaktionen und Datenbestände

2.8    Der funktionale Baum

2.9    Bewertung von IT-Systemen und Projekten

2.10  FPA im Projektzyklus

2.11  Für welche Software ist die FPA geeignet?

2.12  Für welche Projekte ist die FPA geeignet?

3       Das Regelwerk

3.1    Der Standard

3.2    Analysetyp

3.3    Anwendersicht

3.4    Grenze und Analyseauftrag

3.5    Elementarprozesse

3.6    Die Transaktionen

3.7    Die Datenbestände

3.8    Komplexitätsregeln

3.9    Berechnung der Functional Size

3.10  Die Neuerungen im CPM 4.3

4       Beispiele

4.1    Baselines – Mozilla Thunderbirds Adressbuch

4.2    Seminarverwaltung

4.3    Erweiterung Seminarverwaltung

4.4    Was man aus den Beispielen lernen kann

5       Tipps für die Zählpraxis

5.1    Anforderungen richtig verstehen

5.2    Standardsituationen

5.3    Näherungen und Abschätzungen

5.4    Standardsoftware

5.5    Besondere Anwendungstypen

6       Vorgehen

6.1    Welche Vorgehensalternativen gibt es?

6.2    Durchführung eines Interviews

6.3    FPA in der Anforderungsanalyse

6.4    Dokumentationen der Analyse

6.5    Eindeutigkeit der Ergebnisse

6.6    Mit welchem Aufwand ist zu rechnen?

6.7    Zertifizierung

7       Aufwandsschätzung

7.1    Grenzen der Aufwandsschätzung mit der FPA

7.2    Kosten- und Aufwandstreiber

7.3    Messung von Kosten und Aufwand

7.4    Erfahrungsbasierte Prognose

7.5    COCOMO

7.6    Andere Schätzmodelle

7.7    Prognose und Vorgehensmodell

7.8    Prognose und Planung

8       Varianten zur FPA

8.1    Functional Size Measurement nach ISO 14143

8.2    Use Case Points

8.3    Story Points

8.4    Weitere Alternativen

8.5    Zusammenfassung

Glossar der englischen Fachbegriffe

Abkürzungsverzeichnis

Literaturverzeichnis

Index

1 Einleitung

Wohl jedem, der sich mit der Entwicklung von Software oder IT-Anwendungen beschäftigt, sind Function Points (FPs) in der einen oder anderen Form schon begegnet. Im Informatikstudium oder der Fachliteratur häufig als »Funktionspunkteverfahren« oder »FP-Methodik« bezeichnet, wird das Verfahren dort in der Regel als eines von mehreren Aufwandsschätzmethoden dargestellt.

Dabei leistet die Function-Point-Analyse (FPA) wesentlich mehr: Als Bewertungsstandard für den fachlich-funktionalen Leistungsumfang eines IT-Systems ist sie zentrales Element sowohl für jegliche Art von Bewertungen von Softwareentwicklungsprojekten als auch von Bewertungen der Software selbst. Nicht zuletzt unterstreicht die Aufnahme der Function-Point-Analyse in den Katalog der ISO-Standards (ISO 20926) die Wichtigkeit eines solchen Verfahrens.

Deshalb müssen heute aber auch weitere Berufsgruppen und Aufgabenbereiche innerhalb der Unternehmen dieses Bewertungsverfahren kennen und zum Teil auch selbst anwenden können. Hier seien neben den Softwareentwicklern, die die Function-Point-Analyse für ihre Aufwandsschätzungen verwenden, noch folgende Gruppen genannt:

Fachexperten aus den Fachbereichen der Unternehmen nutzen die Function-Point-Analyse zur Beschreibung und Messung der fachlichen Anforderungen. Noch bevor die Softwareentwicklung konkrete Projektaufwandsschätzungen erstellt, können die Fachbereiche so erste Kalkulationen und Grobabschätzungen für ihre Mittel- und Langfristplanung durchführen.

Für das IT-Controlling liefert die Function-Point-Analyse die wesentliche Bezugsgröße für die Einschätzung der Leistung der Softwareentwicklungsbereiche und Softwarelieferanten.

Dem IT-Einkauf hilft die Function-Point-Analyse bei der Bewertung von Projekt- und Outsourcing-Angeboten. Diese können mit Function Points gegen Marktstandards verglichen werden.

Dem Management von IT-Bereichen schließlich dient das Bewertungsverfahren zur Steuerung und zur Prozessverbesserung. Mit Function Points kann die Effizienz von Softwareentwicklung und -wartung gemessen wie auch konkrete Ziele definiert werden.

Die Zielsetzung diese Buches ist es, allen, die mit der Planung und Bewertung von IT-Anwendungen zu tun haben, also nicht nur Softwareentwicklern und -architekten, sondern auch Mitarbeitern der Fachbereiche und aus dem IT-Controlling sowie Managern, eine Einführung und Übersicht über die Function-Point-Analyse zu liefern.

Wer die Function-Point-Analyse bereits kennt, wird in diesem Buch zumindest neue Aspekte finden. In der bisherigen angelsächsischen und auch deutschen Literatur zur Function-Point-Analyse, aber auch in vielen Standardwerken zu Methoden in der Softwareentwicklung wird sie in der Anwendung recht einseitig als Aufwandsschätzverfahren behandelt. Dadurch aber wird die fundamentale Bedeutung der Function-Point-Analyse in der Softwareentwicklung ebenso wie ihre viel breiteren Anwendungsgebiete vollständig übersehen. Wir sind dagegen der Ansicht, dass bei richtigem Verständnis der Function-Point-Analyse ihre verschiedenen Anwendungsgebiete unmittelbar ersichtlich werden.

Wie bei vielen anderen Verfahren auch, ist die Kenntnis der Regeln eine Sache, eine effiziente Anwendung und Umsetzung eine andere. Erstere kann durch Literaturstudium oder den Besuch von Seminaren erlangt werden, Letzteres erfordert eigene praktische Erfahrungen und Übung. Unser Anspruch ist es deshalb, eine allgemein verständliche, anwendungsorientierte Einführung in die Function-Point-Analyse zu geben und praktisch tätigen Function-Point-Experten die notwendigen theoretischen Grundlagen zu vermitteln. Gleichzeitig mag dieses Buch Anwendern und Function-Point-Experten als Nachschlagewerk in der täglichen Arbeit dienen.

Ein wichtiges Motiv bei der Abfassung dieses Buches war für uns der Praxisbezug. Mit der Anwendung der Function-Point-Analyse haben wir selbst jeden Tag zu tun. Aber nicht nur unsere persönliche Erfahrung aus der Durchführung zahlreicher Function-Point-Analysen, sondern auch die unserer Kollegen von QuantiMetrics1 sind in dieses Buch eingeflossen. Wir wenden in unserer Arbeit die Function-Point-Analyse in der Aufwandsschätzung, im Benchmarking bis hin zur Angebotsbewertung an. Unsere Kunden kommen aus allen Branchen: Banken, Versicherungen, Logistik- und Telekommunikationsunternehmen, IT-Dienstleister usw.

Unser Ansatz zur Anwendung der Function-Point-Analyse, und damit auch zu diesem Buch, beruht dabei auf drei Maximen:

Wir verstehen die Function-Point-Analyse als Bewertungsverfahren, nicht als »Methode«. Die Functional Size wird innerhalb verschiedener Methoden z. B. der Aufwandsschätzung oder des Benchmarkings verwendet.

Die fachliche Sicht steht für uns im Vordergrund der Durchführung von Function-Point-Analysen. Richtig angewendet, hilft die Function-Point-Analyse die Frage zu beantworten, was eine IT-Anwendung oder ein IT-Projekt zur Unterstützung der Geschäftsprozesse leistet.

Die Praxistauglichkeit der Umsetzung: Wie lassen sich Function-Point-Analysen mit vertretbarem Aufwand, aber hinreichend guten Ergebnissen hinsichtlich Nachvollziehbarkeit und Vergleichbarkeit durchführen?

Diesen Prinzipien werden Sie im gesamten Verlauf unseres Buches immer wieder begegnen. Zunächst gibt Kapitel 2 eine Übersicht über Hintergründe, Anwendungsgebiete und Grundprinzipien des Verfahrens. Es ist als Einführung für jeden Leser interessant.

Kapitel 3 beschreibt dann ausführlich die Regeln für die Messung von Function Points und die Durchführung einer Function-Point-Analyse. Diese sind im Counting Practices Manual (CPM) der IFPUG [IFPUG 10] sowie im entsprechenden ISO-Dokument [ISO 20926] festgelegt. Sie sollten deshalb in Zweifelsfällen immer als »letzte Instanz« zurate gezogen werden. Die in diesem Buch gewählte Darstellung von Regeln und Beispielen folgt dem Anspruch, den ISO- bzw. IFPUG-Standard vollständig abzubilden.

Das Kapitel 4 erläutert die Anwendung der Regeln des CPM anhand verschiedener Beispiele.

Praktische Tipps für die Durchführung einer Function-Point-Analyse sind in Kapitel 5 ausführlich beschrieben. Insbesondere dieses Kapitel basiert auf unseren praktischen Erfahrungen in der jahrelangen Durchführung von Function-Point-Analysen und der Ausbildung zahlreicher Function-Point-Experten.

Kapitel 6 beschreibt das praktische Vorgehen bei der Durchführung von Function-Point-Analysen im betrieblichen Alltag. Hierzu gehört z. B. die Interviewtechnik für die Sammlung der notwendigen Informationen. In diesem Kapitel werden auch die Anforderungen an die Form der Dokumentation der Analyseergebnisse beschrieben.

Kapitel 7 schließlich zeigt die Verwendung von Function-Point-Werten in verschiedenen Aufwandsschätzverfahren für Softwareprojekte auf. Die Function-Point-Analyse ist ein Größenmaß zur Beschreibung des funktionalen Umfangs von IT-Anwendungen. Als solches ist sie eine wesentliche Basisgröße für Aufwandsund Kostenprognosen von Softwareprojekten, und es ist wichtig zu verstehen, wie sie in den verschiedenen Modellen verwendet wird.

Kapitel 8 gibt eine kurze Sicht auf weitere Verfahren, die im engeren oder weiteren Sinne als Alternativen zur Function-Point-Analyse betrachtet werden.

Wer sich tiefer in das Thema Function-Point-Analyse einarbeiten möchte, wird sicherlich alle Kapitel des Buches, idealerweise in der gegebenen Reihenfolge, lesen wollen. Für denjenigen Leser, der nur an einer Einführung und einem Überblick über das Verfahren interessiert ist, mag dagegen die Lektüre des Kapitels 2 und vielleicht des Kapitels 4 genügen.

2 Einführung in die Function-Point-Analyse

Die Function-Point-Analyse wird heute in vielen Unternehmen für die Aufwandsschätzung, im Rahmen der Projektplanung und im Projektmanagement eingesetzt. Sie findet im IT-Controlling und in der wirtschaftlichen Bewertung von IT-Projekten und IT-Systemen Anwendung. Wir geben in diesem Kapitel einen Überblick über die Anwendungsgebiete, die Historie und die Grundprinzipien der Function-Point-Analyse.

2.1 Anwendungsgebiete von A bis Z

Die Anwendungsgebiete der Function-Point-Analyse reichen von A wie Aufwandsschätzung bis Z wie Zieldefinitionen.

Heute versteht man Function Points über die Aufwandsschätzung hinaus als generelles Maß für die fachliche Funktionalität eines Softwareprogramms. Die Einsatzgebiete für diese Messgröße sind damit z. B.

die Bewertung von Projektangeboten externer Lieferanten,

Wertbestimmung bestehender Softwareprogramme,

Kosten- und Risikoabschätzungen von IT-Vorhaben,

Projektcontrolling und

Benchmarking von Projekten.

Die Herausforderung in der Aufwandsschätzung besteht darin, den Aufwand für ein Projekt möglichst früh sicher vorhersagen zu können. Möglichst früh, das heißt: Die fachlichen Anforderungen sind bekannt, mehr oder weniger detailliert, aber nicht die Art und Weise der technischen Umsetzung.

Diese Aufgabenstellung ähnelt also in etwa der, die Baukosten für ein Einfamilienhaus abzuschätzen, wobei bekannt ist, welche Familie in dem Haus wohnen soll, wie viele Erwachsene und Kinder und welche Ansprüche diese haben. Wie kann man die Baukosten vernünftig abschätzen, ohne dass schon ein detaillierter Bauplan vorliegt? Die Lösung liegt in einer Herangehensweise in zwei Schritten:

Wie viele Quadratmeter Wohnfläche braucht die Familie?

Wie viel kostet ein Quadratmeter Wohnfläche der geforderten Ausstattung und Lage?

Übertragen auf die Aufwandsschätzung eines Softwareprojekts heißt dies: Wie viele Function Points stecken hinter den fachlichen Anforderungen? Was kostet die Entwicklung eines Function Points in der geforderten Qualität und Performance?

Doch hat man erst einmal ein funktionales Leistungsmaß für die Aufwandsschätzung definiert, so liegt es natürlich nahe, auch das Ergebnis des Softwareprojekts, also das fertige Softwaresystem, mit diesem Maß zu bewerten. Damit eröffnet sich für die Function-Point-Analyse noch eine Reihe weiterer Anwendungsmöglichkeiten.

Die gelieferte Leistung eines Projekts lässt sich über Function Points definieren. Damit hat die Function-Point-Analyse im IT-Projektcontrolling eine besondere Bedeutung. Sie ist die Bezugsgröße bzw. das Leistungsmaß, das in Relation zu verbrauchten Ressourcen – Aufwand, Kosten und Zeit – gesetzt wird.

Ein zentrales Element strategischer Steuerung ist das Benchmarking. Der Begriff Benchmarking, abgeleitet aus dem englischen benchmark, geht auf Robert C. Camp [Camp 94] zurück. Er hat Benchmarking als Managementverfahren begründet. Kurz gefasst, lässt sich dies mit dem Satz »Lernen durch Vergleichen« beschreiben. Durch den Vergleich der eigenen Leistungsfähigkeit mit der anderer Unternehmen sollen Organisationen Verbesserungspotenziale und »Best-Practices« erkennen. Vergleichen kann man nur, wenn man über ein gemeinsames Maß verfügt: Für Softwaresysteme und -projekte liefert dies die Function-Point-Analyse.

Ein weiteres Anwendungsgebiet liegt in Ausschreibungen und in der Auftragsvergabe von Softwareprojekten. Das klassische Vorgehen kennt zwei Alternativen: Entweder sind die funktionalen Anforderungen (auch als Pflichtenheft bezeichnet) genau bekannt und bilden damit die Ausschreibungsgrundlage oder die Erfassung und Beschreibung der funktionalen Anforderungen ist Teil des Projekts selbst.

Im ersteren Fall besteht der Nachteil darin, dass die Erstellung eines Pflichtenhefts selbst schon erheblichen Aufwand und Kosten erfordert – und spezifisches IT-Know-how, das vielleicht gerade beim Auftraggeber gar nicht vorhanden ist. Im letzteren Fall bereitet die Vergleichbarkeit der Angebote das Problem: Denn jeder Anbieter wird potenziell zu einem eigenen Pflichtenheft kommen. Ein direkter Vergleich ist damit unmöglich.

Die Verwendung von Function Points ist hier eine neue, dritte Alternative: Ein Preis in »Euro pro Function Point« ist aus Sicht der Einkäufer eine kalkulierbare Größe. Ein schöner Nebeneffekt ist dabei, dass Auftraggeber und Auftragnehmer schon zusammenkommen können, bevor die Anforderungen im Detail hundertprozentig feststehen.

Function Points werden in diesem Kontext – der Vergabe von Softwareentwicklungsleistungen – also als Vergütungsbasis verwendet.

Auch ein »fertiges« Softwaresystem, eine IT-Anwendung, lässt sich mit Function Points bewerten. Dieser Wert wird z. B. für den Vergleich von Wartungs- und Betriebskosten und -aufwand verwendet. Der Function-Point-Wert spielt auch eine wichtige Rolle im Portfoliomanagement und bei Due-Diligence-Untersuchungen, also dort, wo es darauf ankommt, den betriebswirtschaftlichen Wert eines IT-Systems zu bestimmen.

2.2 Wie alles anfing ...

Die erste dokumentierte Beschreibung der Function-Point-Analyse dürfte wohl der oben zitierte Beitrag von Allan J. Albrecht [Albrecht 79] auf einem Symposium der IBM im Jahre 1979 gewesen sein. Albrecht war klar, dass eine sinnvolle Messung der Produktivität nur in Bezug auf die für den Anwender der Software gelieferte Funktionalität möglich ist und unabhängig von der konkret eingesetzten Technologie sein muss. Albrecht bestimmte die Produktivität dann aus dem Verhältnis des Projektaufwands zu den von ihm vergebenen Function Points.

Recht schnell entstand nun die Idee, diese Produktivitätsgleichung »umzudrehen« und anhand des Function-Point-Werts den zu erwartenden Aufwand für ein Softwareprojekt zu bestimmen. So publizierte z. B. die IBM ihre berühmte »IBMKurve« [IBM 85], die für 54 Projekte den Zusammenhang von Aufwand und Function Points darstellte.

Die Wahrnehmung der Methodik bei den Anwendern folgte dann der für alle neuen Technologien bekannten »Hype-Kurve« (Abb. 2–1). Die Veröffentlichung der IBM-Kurve hatte die Erwartung geweckt, nun endlich über ein einfaches und gleichzeitig zuverlässiges Verfahren zur Aufwandsschätzung zu verfügen. Anfang der 90er-Jahre gab es deshalb in fast allen deutschen Großunternehmen den Versuch, das Verfahren zur Aufwandsschätzung einzusetzen. Rückblickend lässt sich eine Reihe von Gründen finden, warum die meisten dieser Versuche zum Scheitern verurteilt waren:

Da ist zunächst die Unerfahrenheit der Anwender mit der Methodik zu nennen. Die sichere und effiziente Durchführung einer Function-Point-Analyse erfordert eine gründliche Ausbildung und praktische Erfahrung. Über beides verfügten die »Pioniere« nicht. Aus dieser Zeit stammt deshalb der irrige Glaube, die Function-Point-Analyse sei aufwendig und liefere keine belastbaren Ergebnisse.

Auf der anderen Seite waren die Erwartungen an die Ergebnisse des Verfahrens unrealistisch hoch gesetzt. Heute wissen wir, dass eines der zentralen Probleme der frühen Projektaufwandsschätzung vor allem in einer lückenhaften oder unklaren Definition der fachlichen Anforderungen liegt. Dieses Problem kann aber auch mit der Function-Point-Analyse nicht gelöst werden.

Aber selbst da, wo die Anforderungen vollständig mit Function Points beschrieben waren, fehlten die für eine Aufwandsschätzung notwendigen differenzierten Erfahrungsdaten. Die in der historischen IBM-Kurve veröffentlichten Function-Point-Aufwandsrelationen, die ja nur eine beispielhafte Darstellung waren, erwiesen sich – wie nicht anders zu erwarten – für die meisten Unternehmen als unzutreffend.

Kein Wunder also, dass die ersten Anwender sich zunächst enttäuscht wieder von dem Verfahren abwandten.

Abb. 2–1     Hype-Kurve der Function-Point-Analyse

Etwa Mitte der 90er-Jahre trat die Aufwandsschätzung als Motivation für die Function-Point-Analyse immer mehr in den Hintergrund. Heute beobachten wir ein stetiges Wachstum der Bedeutung der Function-Point-Analyse. Im Zuge von Wirtschaftlichkeitsbetrachtungen wird der Function-Point-Wert von Projekten und IT-Anwendungen deren Kosten gegenübergestellt. Im Outsourcing und Offshoring werden die Angebote und Leistungen der Dienstleister mit Function Points bewertet.

Die Aufwandsschätzung ist also heute nur ein Anwendungsgebiet der Function-Point-Analyse unter vielen. Die Motive und Triebkräfte für ihren Einsatz kommen heute eher aus kaufmännischen und Controlling-Bereichen.

2.3 Woher kommt der Name »Function Points«?

In den frühen Veröffentlichungen [Albrecht 79] nannte Albrecht seinen Ansatz noch »function value measure« (was man etwa als Nutzwertmessgröße übersetzen könnte). Der Begriff »function« wurde von ihm im Sinne von Nutzen verwendet. Er hat also weniger mit der »Funktion« im Sinne der Mathematik oder Informatik zu tun.

Albrecht machte den Nutzen eines IT-Systems daran fest, wie viele Möglichkeiten es zur Ein- und Ausgabe sowie zur Speicherung von Daten bietet. Er betrachtete die fertiggestellte Anwendung und zählte die externen »Eingaben«, »Ausgaben« sowie »Abfragen« sowie die wesentlichen Datenbestände. Deren Summe wurde jeweils mit einem festen Gewichtungsfaktor multipliziert (jeweils 4 für Eingaben und Abfragen, 5 für Ausgaben und 10 für Datenbestände). Die sich daraus ergebende Zahl wurde, in Abhängigkeit von weiteren, qualitativen Merkmalen, noch mit einem Korrekturfaktor – später als Wertfaktor bezeichnet – versehen. Das Ergebnis nannte Albrecht »functions points«und beschrieb diese als eine dimensionslose Zahl, die eine sinnvolle Aussage über den Nutzwert für den Auftraggeber erlaubt.

In den 1970er-Jahren waren wahrscheinlich die meisten IT-Systeme noch so einfach »gestrickt«, dass diese einfachen Definitionen ausreichten. Moderne Anwendungen sind in der Regel wesentlich komplexer, sie verfügen etwa über umfangreiche »interne« Verarbeitungslogik oder präsentieren ihre Oberfläche workflow- bzw. ablaufgesteuert. Datenbestände, Ein- und Ausgaben oder Abfragen sind so für den Anwender oft gar nicht mehr so einfach erkennbar. Auch interne Architektur und Design der Anwendungen folgen nicht mehr unbedingt diesem einfachen Schema.

Wie im nächsten Abschnitt beschrieben wird, unterscheidet sich der moderne Standard der Function-Point-Analyse vom dem Albrecht‘schen Ansatz vor allem in zwei Aspekten:

Bewertet werden die fachlichen elementaren Funktionen und logischen Datenbestände.

Der Bewertungsansatz bezieht sich auf die fachlichen Anforderungen.

Dadurch wird erreicht, dass die Bewertung weitgehend unabhängig von der konkret sichtbaren Oberfläche oder dem internen Design einer Anwendung wird. Die von Albrecht eingeführten Begriffe haben sich bis heute gehalten, wenn sie auch in einer zum Teil recht abweichenden Bedeutung verwendet werden.

2.4 Der neue Standard IFPUG CPM 4.3.1

Bereits 1984 gründete sich die International Function Point User Group, IFPUG, um einen Function-Point-Standard zu definieren und weiterzuentwickeln. Die aktuelle Version des Standards ist jeweils in einem Handbuch, dem Counting Practices Manual, kurz CPM, beschrieben. Seit 2010 gilt der neue als CPM 4.3.1 bezeichnete Standard der IFPUG.

Mit dieser Version hat es noch einmal eine wesentliche Änderung gegeben: Der sogenannte Wertfaktor, mit dem auch qualitative Merkmale der Anwendung berücksichtigt werden sollten, ist nun lediglich noch eine Option im IFPUG-Standard. Die IFPUG hatte sich zu diesem Schritt entschlossen, um den Anforderungen der ISO an Standards für »Functional Size Measurement« zu genügen.

Diese Anforderungen sind im Standard ISO/IEC 14143-1:2007 Functional Size Measurement beschrieben. Sie schließen explizit die Berücksichtigung qualitativer Merkmale und nicht funktionaler Anforderungen bei der Bestimmung der Functional Size aus. Der aktuelle IFPUG-Standard ist damit unter der Bezeichnung ISO/IEC 20926:2009 IFPUG Functional Size Measurement Method 2009 als ISO-Standard anerkannt. Damit ist der Wertfaktor zwar noch eine Option im IFPUG-Standard, die Anwendung dieser Option ist jedoch nicht zum ISO-Standard konform.

Der Wertfaktor fand in der Praxis schon seit vielen Jahren kaum noch Anwendung. Die Kritik richtete sich vor allem darauf, dass eine Vermischung der Bewertung quantitativer und qualitativer Merkmale methodisch sehr fragwürdig ist. Das wäre schließlich so, als ob man die Grundfläche eines Hauses aufgrund seiner Lage und Ausstattung mit mehr oder weniger Quadratmeter angeben würde. Insofern hat die IFPUG mit dem neuen Standard auch die geübte Praxis anerkannt. Im Gegensatz noch zur 1. Auflage haben wir uns deshalb entschieden, den Wertfaktor in diesem Buch nicht mehr zu behandeln.

Es überrascht nicht, dass es im Laufe der vergangenen dreißig Jahre eben doch einige Änderungen in der Definition der Function-Point-Analyse und in ihrer Anwendung gegeben hat. Die wesentlichen Unterschiede sind in Tabelle 2–1 zusammengefasst.

Albrecht 1979 bzw. IFPUG 1984

ISO / IFPUG - 2010

Bewertung von Artefakten (Masken, Tabellen usw.)

Bewertung fachlich-funktionaler Anforderungen

Wertfaktor zur Berücksichtigung qualitativer Merkmale

Wertfaktor nur noch bei IFPUG als Option, in der Praxis nicht genutzt

Detailliertes »Auszählen« aller Elementarprozesse

Erprobte und verbreitete Näherungsverfahren

Erfassung auf Papier

Effiziente Werkzeuge für Erfassung und Dokumentation

Tab. 2–1     Vergleich der FPA »früher« und »heute«

2.5 Was bewertet die FPA?

Immer wieder wird in der Informatikliteratur die Function-Point-Analyse im Zusammenhang mit Softwaremetriken genannt. Auch wir selbst sprechen häufig etwas ungenau vom »Function-Point-Zählen«. Wir werden sehen, dass diese Begriffe jedoch nicht wirklich zutreffend sind, denn tatsächlich handelt es sich bei der Function-Point-Analyse um ein Bewertungsverfahren. Bewertet werden die Anzahl und Komplexität der fachlichen Funktionen, die ein IT-System seinen Nutzern zur Verfügung stellt, und die damit verwalteten fachlichen Datenbestände.

Wenn wir im Zusammenhang mit der Function-Point-Analyse über IT-Systeme sprechen, dann meinen wir in erster Linie solche Systeme, die im betrieblichen Ablauf die Durchführung von Geschäftsprozessen unterstützen. Das kann z. B. die Anlage eines Versicherungsvertrags bei einer Versicherung sein, aber auch der Check-in bei einer Fluglinie.

Ein IT-System unterstützt die Durchführung eines Geschäftsprozesses. Ist die Durchführung mehr oder weniger vollständig durch das IT-System unterstützt, sagt man auch: Das IT-System bildet den Geschäftsprozess ab. Das heißt, der Geschäftsprozess und das IT-System werden letzten Endes gleichgesetzt. Heute kennen wir in vielen Branchen Geschäftsprozesse, die ohne entsprechende IT-Anwendungen gar nicht mehr existieren könnten.