Backfiring

In manchen Fällen ist es sinnvoll, die FP nicht durch das traditionelle Zählen zu ermitteln, sondern durch automatische Verfahren wie das Backfiring. Bei diesem Verfahren werden mittels Umrechnungstabellen die Function Points aus bestehendem Quellcode generiert.

Dies ist gerade in der Einführungsphase der FP-Methode in einem Unternehmen möglicherweise nützlich. Nur so ist es möglich, innerhalb kürzester Zeit für einen Software-Bestand die FP zu erheben.
In vielen Fällen ist Backfiring auch nur der einzige Weg für die Ermittlung, da sich ein Altsystem oft aufgrund fehlender Dokumentation nicht komplett zählen lässt. Zwar erreicht man durch dieses Verfahren keinen exakten Wert, jedoch lässt sich die Funktionalität so zumindest näherungsweise ermitteln.

Zu beachten ist jedoch, dass Backfiring in der Fachwelt kontrovers diskutiert wird und damit eine sehr kritisch betrachtete Methode darstellt.
Die Aussagefähigkeit steht und fällt mit der Qualität des der Methode zu Grunde liegenden Datenmaterials, abgebildet in Form von Umrechnungstabellen.
Nur wenn die in den Umrechnungstabellen verwendeten Umrechnungsgrößen in Korrelation zu der Realität stehen, können die durch das Backfiring ermittelten Function Points einen Näherungswert für die tatsächlich durch die zu messende Software abgebildeten Function Points darstellen.

Aus diesem Grund werden die Umrechnungstabellen in der Regel dem zu messenden Softwarebestand angepasst.
Die Grundlage bildet der Quellcode des zu messenden Programms, der mittels LOC-Methoden analysiert wird. Aufgrund der Codekomplexität und Größe der LOC versucht man nun, unter zu Hilfenahme von aus Erfahrungsdaten gewonnenen Umrechnungstabellen Rückschlüsse auf die funktionale Größe, gemessen in Function Points, zu ziehen. Dabei ist jedoch ein wesentlicher Punkt zu beachten:

Es dürfen nur Anweisungen im Quellcode gezählt werden. Insbesondere ist dies bei der Programmiersprache COBOL von entscheidender Bedeutung, da sich der COBOL-Code besonders durch die Kommentarzeilen und Copystrecken auszeichnet. Es ist demnach wichtig, was als Anweisung definiert wurde (Vgl. [HÜRTEN99], S. 51).
Da es in der Praxis jedoch mit Schwierigkeiten verbunden ist, die Anzahl der Anweisungen in den LOC zu identifizieren, wird in der Praxis in der Regel für die Ermittlung der FP mittels Backfiring nur die Anzahl der Lines of Code verwendet.

Wie aus dem COBOL-Beispiel deutlich wurde, ist die Codegröße abhängig von der verwendeten Programmiersprache. Es muss daher ein Weg gefunden werden, der die Möglichkeit ebnet, eine Aussage dahingehend zu tätigen, wie viele Codezeilen für eine bestimmte Programmiersprache benötigt werden, um einen FP zu kodieren.
Hierzu wurde durch Capers Jones der Begriff der „durchschnittlichen Expansionsrate“ geprägt. Diese sagt aus, wie viele Anweisungen im Quellcode notwendig sind, um einen FP zu generieren (Vgl. [BUNDSCHUH00], S. 104).

Bundschuh und Fabry veröffentlichten in ihrem Buch „Aufwandschätzung von IT- Projekten“ eine Umrechnungstabelle, die einen Überblick über die gängigen Expansionsraten der verschiedenen Programmiersprachen gibt.
Diese Umrechnungstabelle mit den durchschnittlichen Expansionsraten der Programmiersprachen hat jedoch nur einen allgemeinen Charakter.
Die tatsächlichen, bei einem konkreten Umfeld gültigen durchschnittlichen Expansionsraten, können dabei zum Teil erheblich von den in der Tabelle aufgeführten Werten abweichen.
Es ist für einen konkreten Fall daher unabdingbar, diese Werte dem jeweiligen Fall, ausgehend von vorher ermittelten Erfahrungsdaten, anzupassen.
Die Tabelle von Bundschuh und Fabry soll auf Grund ihres in der Literatur sonst nur selten vorkommenden Umfanges im Folgenden abgebildet werden. In den meisten Fällen begnügen sich die Autoren nur mit einem Auszug.
 

Sprache oder Dialekt

Durchschnittliche Expansionsrate

Basic AssemblerMacro Assembler
C
ANSI COBOL 74
Fortran
Interpreted Basic
ANSI COBOL 85
Fortran 90
Microfocus COBOL
LISP
C++
CICS
IBM CICS/VS
ORACLE
Visual Basic 2
Visual C++
SAS
Symantec C++
EIFFEL
Smaltalk IV
ABAP/4
Programmgeneratoren
ANSI SQL
EXCEL 3-4

320
213
128
107
107
107
107
80
80
64
55
46
40
40
35
34
32
29
21
21
16
16
13
6

(Quelle: [BUNDSCHUH00], S, 104-105)

Wie man aus der abgebildeten Tabelle sehr schön erkennen kann, sinkt die durchschnittliche Expansionsrate mit der Komplexität und Mächtigkeit einer Programmiersprache. Das bedeutet, für die Generierung eines Function Points sind immer weniger LOC notwendig.

Dieser Zusammenhang wird in der grafischen Darstellung in der folgenden Abbildung noch deutlicher:

expansionsrate

Wenn nun beispielsweise ein Softwareprogramm aus 5.000 Quellcodezeilen besteht und in der Programmiersprache Visual C++ implementiert ist, so lässt sich näherungsweise für dieses Programm folgende Anzahl an FP bestimmen:

backfire2

Demnach würde in diesem Beispiel das Programm ca. 147 Function Points enthalten.

Da bei der eben dargelegten Methode die von Hürten aufgestellte Forderung nach der Verwendung von reinen Anweisungszeilen anstatt von LOC nicht berücksichtigt wurde, ist das Ergebnis zwar noch nicht genau genug, jedoch in den meisten Fällen ausreichend, zumal gerade bei der Erfassung der Funktionalität von Altsystemen dies oft die einzige Möglichkeit darstellt und eine ungenaue Zählung immer noch besser ist als gar keine (Vgl. [BUNDSCHUH00], S. 106).

 

[Willkommen] [Wirtschaft] [Informatik] [Bücher] [Impressum]

Copyright (c) 2012 Dipl.-Wirt.-Inform. Dennis A. Winkler, Stand: 02.07.2012
Diese Website ist unter folgenden URLs zu erreichen:
http://www.dennis-winkler.de  -  http://www.winkler-boerse.de