Function-Point-Analysis - Theorie und Praxis, Grundlage für ein  modernes Softwaremanagement, Edition Expert-Soft, Renningen,
2. erw. Auflage 2005

Impressum:
Robert Hürten,
Nippes 2
53945 Blanklenheim
Tel.:02697-901270
Email:
robert.huerten@t-online.d e

BuiltWithNOF
FP-Einführung

 

Die Schritte bei der Einführung

des Function-Point-Verfahrens (FPV)

 

Die Einführung des Function-Point-Verfahrens (FPV) als Bestandteil des Projektmanagements ist nicht mit der Anschaffung eines Softwareproduktes zu vergleichen. Das FPV ist eine Methode für die Ermittlung der Größe einer betriebswirtschaftlichen Aufgabe. In Verbindung mit einem zuverlässigen Berichtswesen kann das FPV als Grundlage für eine Vielzahl von planerischen und steuernden Aktivitäten genutzt werden. Beispiele dafür sind die Aufwandsschätzung und die Ermittlung der Produktivität einer Softwareentwicklungsumgebung. Die Einführung von neuen Methoden in der Softwareentwicklung verlangt von Systemanalytikern und Programmierern stets eine Umstellung bzw. eine Anpassung ihrer gewohnten Arbeitsweisen. Somit hängt auch der Erfolg des FPV von der Bereitschaft der Mitarbeiter ab, dieses Verfahren zu akzeptieren und anzuwenden. Deswegen ist der Schulung der Mitarbeiter der Softwareabteilung besondere Bedeutung beizumessen.

Damit die Anwendung des FPV den angestrebten Erfolg für die Unternehmen bringt, empfiehlt es sich in folgenden Schritten vorzugehen:

1. Informationen über das FPV in das Unternehmen holen, damit eine Entscheidung für oder gegen den Einsatz des FPV getroffen werden kann

2. Aufbau einer FPV-Kernmannschaft

3. Nachkalkulation abgeschlossener Projekte

4. Ermittlung der Kriterien und Gewichtungen der im Unternehmen zu verwendenden qualitativen Einflußfaktoren.

5. Untersuchung der vorhandenen Entwicklungsumgebung(en) zur Ermittlung der davon abhängigen Einflußfaktoren und deren Kriterien und Gewichtungen.

6. Ableitung der Produktivitätskurven des Unternehmens im Hinblick auf die verschiedenen Entwicklungsumgebungen.

7. Erstellung von Richtlinien zur Anwendung des FPV

8. Schulung der Mitarbeiter in der Anwendung des FPV

9. Kontrolle der laufenden Anwendung.

1. Informationen über das FPV in das Unternehmen holen

Der Anstoß, sich mit dem FPV zu beschäftigen kommt heute öfter aus dem Controlling-Bereich als aus der Datenverarbeitung selber. Veröffentlichungen und Seminarhinweise sind dazu häufig die Auslöser. Die Erfahrung zeigt, daß die Literatur heute noch nicht ausreicht, um das Gelesene in die praktische Anwendung umzusetzen. Deswegen empfiehlt es sich, Schulungen zum FPV zu besuchen, die Workshopcharakter haben sollten und die viel Raum zur fachlichen Diskussion lassen.

Der Mitarbeiter, der als Erster ein solches Seminar besucht, sollte von sich aus die Motivation mitbringen, sich mit Aspekten der Leistungsmessung bei der Softwareentwicklung auseinanderzusetzen. Er sollte z.B. die Terminüberschreitungen bei DV-Projekten nicht als eine wesentliche Eigenschaft der Datenverarbeitung ansehen, mit der man leben muß, sondern als ein Hemmnis für eine planvolle Arbeit.

Ein Bericht dieses zuerst im FPV geschulten Mitarbeiters sollte eine der Grundlagen für die Entscheidungsfindung für oder gegen die Einführung des FPV sein. Zusätzlich sollte das Entscheidungsgremium versuchen, Informationen von Unternehmen zu erhalten, die bereits mit dem FPV arbeiten. Dies ist u.a. deswegen wichtig, um auch eine Vorstellung von dem zeitlichen und finanziellen Aufwand für eine erfolgreiche Einführung zu erhalten.

Wenn die Entscheidung für die Einführung des FPV gefallen ist, so sollte ein Mitarbeiter als FPV-Manager bestimmt werden. Dieser hat dann nicht nur die Verantwortung in der Einführungsphase, sondern er sollte dann später auch überwachen, daß das FPV entsprechend den Organisationsanweisungen richtig angewandt wird.

2. Aufbau einer FPV-Kernmannschaft

Bei der Einführung des FPV in Unternehmen ist es nicht zweckmäßig, eine breite Schulung durchzuführen. Bevor nämlich das FPV eingesetzt werden kann , sollten einige abgeschlossene Projekte nachkalkuliert werden. Ziele dieser Nachkalkulationen ist es zu ermitteln, welchen Stand die Produktivität der Softwareentwickler hat.

Die Zusammensetzung der Kernmannschaft orientiert sich an den Projekten, die für eine Nachkalkulation vorgesehen sind. Für jedes Projekt sollte dessen Leiter und, wenn möglich, ein weiterer Mitarbeiter bestimmt werden. Zur Kernmannschaft sollten ferner Mitarbeiter aus der Abteilung Projektmanagement bzw. Tools und Methoden gehören.

Die Kernmannschaft sollte gemeinsam geschult werden . Der Schwerpunkt der Schulung muß darauf liegen, die Bedeutung der bei FPV zu definierenden Funktionen und den anzusetzenden Gewichtungen darzulegen, damit diese bei allen Nachkalkulationen nach den gleichen Kriterien angewandt werden. Es muß z.B. erreicht werden, daß bei einer Elementarfunktion Eingabe alle Schätzer die gleiche Einstufung in leicht, mittel oder schwer vornehmen und die gleichen Einflußfaktoren hinsichtlich der Qualität oder des Entwicklungsumfeldes ansetzen. Um dies zu erreichen, muß die Schulung Übungen enthalten, anhand derer die Kernmannschaft überprüft, ob sie die vorgegebenen Regeln einheitlich anwendet.

3. Nachkalkulation abgeschlossener Projekte.

Während die Ermittlung der Größe eines Projektes nach den vorgegebenen Regeln der Function-Point-Analysis erfolgen muß, kann der Schritt von der Aufgabengröße zum erforderlichen Aufwand für die DV-mäßige Umsetzung nie nach einer starren Formel erfolgen. Wäre dies der Fall, so blieben die Erfahrung der Mitarbeiter, die eingesetzten Software-Tools u.ä. außer Betracht. Derartige Einflüße berücksichtigt das FPV für jede Entwicklungsumgebung in einer entsprechenden Produktivitätskurve.

Grundsätzlich kann man zunächst mit Produktivitätskurven arbeiten, die in gleichgelagerten Unternehmen ermittelt wurden. Es empfiehlt sich jedoch dringend, frühzeitig zu untersuchen, ob nicht eine eigene Produktivitätskurve sinnvoll ist. Um dies zu erfahren, sind Nachkalkulationen durchzuführen.

Bei der Auswahl von Projekten für die Nachkalkulation ist darauf zu achten, daß diese repräsentativ für die meisten Anwendungsgebiete sind. Sie sind z.B. nach Dialoganwendungen, Batchverarbeitung , ihrer Größe etc. auszusuchen.

Die erste Aufgabe der FPV-Kernmannschaft ist es, abgeschlossene Projekte nachzukalkulieren. Grundlage der Nachkalkulation darf nicht die ursprüngliche Aufgabenstellung sein. Das Projekt muß in seinem Umfang dem Stand entsprechen, auf den sich die vorhandenen, bekannten Istwerte des Aufwandes beziehen. Es muß sichergestellt sein, daß sich der Funktionsumfang und die genutzten Istwerte auf den gleichen Termin beziehen.

Da die Ermittlung des Funktionsumfanges eines Projektes beim FPV immer aus der Sicht des Anwenders zu erfolgen hat, ist das organisatorische und DV-technische Umfelds nicht zu berücksichtigen. Für die Nachschätzung legt der Schätzer am besten das Anwenderhandbuch zu Grunde, weil dies eine Beschreibung ist, die der Anwedersicht am nächsten kommt.

Bei der Ermittlung der "Netto-Summe" der Function-Points anhand der Einflußfaktoren muß sich der Schätzer in die Vergangenheit zurückversetzen.. Der Schätzer muß berücksichtigen, welche Qualitätsanforderungen seinerzeit Standard waren und welche Anforderungen abweichend davon gestellt wurden.

Zu der Bewertung der gefundenen Produktivität als Verhältnis von Function-Points/Mannmonate ist es zunächst unerheblich, welche Produktivitätskurve zum Vergleich herangezogen wird. (Z.B. eine der IBM-Kurven oder eine aus der Branche)

In allen Fällen werden mit großer Wahrscheinlichkeit Abweichungen zu der Vergleichskurve festzustellen sein. Die Ursachen dazu liegen entweder

in projektbezogenen Sonderheiten bei der Projektabwicklung oder

in der firmenspezifischen Produktivität.

Projektbezogene Sonderheiten liegen z.B. vor, wenn in dem Projekt, das nachkalkuliert wurde, starke Personalfluktuation herrschte oder wenn die Aufgabenstellung im Projektverlauf so erweitert wurde, daß bereits abgeschlossene Arbeiten nicht mehr zu verwerten waren und neu erstellt werden mußten.

Die firmenspezifische Produktivität zum Zeitpunkt der Projektdurchführung braucht nicht mehr dem heutigen Stand zu entsprechen. Gründe dafür können z.B. sein, daß die Mitarbeiter heute höher qualifiziert sind oder daß neue , wirkungsvolle Software-Tools eingesetzt werden.

Die Ergebnisse der Nachkalkulation sind in jedem Fall genau zu analysieren und entsprechend dem heutigen Stand zu bereinigen.

Für die Zuordnung der Elemtarfunktionen (Ein-,-, Ausgaben, Abfragen und Datenbestände) zu den Gruppen einfach, mittel und komplex sollte heute auf Grund der Anzahl der Datenelemente und der betroffenen Informationsobjekte erfolgen.

4. Ermittlung der Kriterien und Gewichtung der im Unternehmen zu verwendeten qualitativen Einflußfaktoren

Die Schätzung mit dem FPV nutzt eine Statistik, die auf Projekten in der Vergangenheit basiert. Durch diese Statistik werden die Qualitätsanforderungen der einzelnen Projekte auf firmenspezifische Mittelwerte verdichtet. Der FPV-Anwender sollte seine Standardqualitätsanforderungen ermitteln, damit neue Projekte an diesem Standard gemessen werden können.

Anhand der nachkalkulierten Projekte ist deswegen auch zu untersuchen, welche Qualitätsnormen beim Anwender vorhanden sind. Für die Abweichungen von diesen Normen sind dann Zu- oder Abschläge zur Ermittlung der Function-Points festzulegen.

5. Untersuchung der vorhandenen Entwicklungsumgebung zur Ermittlung der davon abhängigen Einflußfaktoren und deren Kriterien und Gewichtungen.

Wenn aus abgeschlossenen Projekten der Vergangenheit statistische Aussagen zur Produktivität einer Softwareentwicklungsabteilung abgeleitet werden, so basieren diese auf einer konkreten Entwicklungsumgebung. In diese Aussagen fließen z.B. das Know How der Mitarbeiter, die Mächtigkeit der verwendeten Programmiersprache, das zugrunde liegende Betriebssystem etc. ein. Die Größen, die das Entwicklungsumfeld beschreiben, sind zu ermitteln, damit bei der Schätzung neuer Projekte Abweichungen von der Standardentwicklungsumgebung ermittelt und bewertet werden können.

6. Ableitung der Produktivitätskurven im Hinblick auf verschiedene Entwicklungsumgebungen

Um eine statistisch abgesicherte Produktivitätskurve ableiten zu können, benötigt man mindesten 20 - 30 nachgeschätzte Projekte. Diese liegen bei der Einführung des FPV nicht vor und sind auch kurzfristig nicht zu beschaffen.

Man vergleicht deswegen die Ergebnisse der von der Kernmannschaft nachgeschätzten Projekte mit bekannten Produktivitätskurven. Mit der Kurve, die am besten die Nachschätzungen abdeckt, sollte man dann den Aufwand für die folgenden Projekte schätzen.

Nachgeschätzte Projekte

Summe der Function Points

Ist Aufwand lt. Berichtswesen in Mannmonate

Aufwand lt. Kurve I

Aufwand lt Kurve II

Verhält nis Ist/Kur ve

Projekt 1

297

15.

17.

23,6

0,88

Projekt 2

482

32,5

31

43

1,03

Projekt 3

571

40

39

55

1,02

Projekt 4

887

53

64

96

0,83

In der obigen Tabelle entspricht die bekannte Kurve I am besten der nachgeschätzten Entwicklungsumgebung.

Mit der aufgezeigten Methode läßt sich schnell und mit wenig Aufwand eine hinreichend genaue firmenspezifische Produktivitätskurve ermitteln.

7. Erstellen von Richtlinien zur Anwendung des FPV.

Das FPV führt nur dann zu verläßlichen Ergebnissen, wenn es von allen Anwendern nach den gleichen Regeln genutzt wird. Es ist deshalb unbedingt notwendig, daß Richtlinien zum FPV vorhanden sind, die eine einheitliche Vorgehensweise definieren. In den Richtlinien sind nicht nur die Regeln, nach denen zu arbeiten ist, zu hinterlegen, sondern auch die Anforderungen an die Datenbasis zu definieren, die den Schätzungen zugrunde liegen soll.

Eine Richtlinie zur Anwendung für die Anwendung des FPV wird ca. 20 bis 30 Seiten umfassen.

8. Schulung der Mitarbeiter in der Anwendung des FPV

Da das FPV die Ermittlung der geforderten Funktionen aus der Sicht des Anwenders verlangt, erfordert es keine besonderen DV-Kenntnisse. Vielmehr ist es notwendig, die betriebswirtschaftlichen Anforderungen der zu schätzenden Projekte zu kennen.

Aus diesem Grund empfiehlt es sich, nicht nur Projektleiter aus dem DV-Bereich, sondern auch die Anwendungsbetreuer/DV-Kontakter auf der Seite der Fachabteilungen zu schulen.

Bei der Schulung ist auf zwei Punkte besonders zu achten: es muß vermittelt werden,

- daß das FPV nicht die Erfahrung ersetzt, sondern nur absichert und

- daß das FPV eine spezielle Methode zur Schätzung des Softwareaufwandes ist und keine starre Formel.

Wesentlicher Bestandteil der Schulung sollte ein Workshop sein, in dem die Teilnehmer an einem Beispiel die Anwendung des FPV üben und die Vorgehensweise und Ergebnisse diskutieren.

9. Kontrolle der laufenden Anwendungen

Die Anwender des FPV sollten darauf achten, daß das FPV entsprechend den Richtlinien angewandt wird. Es sollte deswegen im DV-Controlling oder einer anderen entsprechenden Stelle ein Mitarbeiter mit der Kontrolle der FPV-Anwendung beauftragt werden. Es soll überwacht werden, daß die Schätzungen einheitlich nach den Regeln in den Richtlinien durchgeführt werden. Durch die Kontrolle soll auch vermieden werden, daß die Einflußfaktoren für Qualität und Abweichungen im Entwicklungsumfeld unterschiedlich gehandhabt werden. Die Kontrolle wird nur in großen Häusern eine Arbeitskraft voll auslasten.

Wenn die oben dargestellten 9 Punkte zur Einführung des FPV beachtet werden, so wird man schon recht früh gute Ergebnisse bei der Aufwandschätzung und im Projektmanagement erreichen.

Für den anschließenden praktischen Einsatz ist dann wichtig, einen Erfahrungsaustausch mit anderen FPV-Anwendern zu suchen. dadurch kann die statistische Basis des Verfahrens verbreitert und abgesichert werden.

© Robert Hürten, 1999

Zurück

 

[Start] [Veröffentlichungen]