Function Point Analyse

von Maud Schlich

Eigentlich scheint es ja ganz einfach zu sein, eine Function Point Analyse durchzuführen.

Den Anfang macht die Abgrenzung des Systems zu den umliegenden Systemen.

Beispiel: easyPresenter ist ein kleines Stück Software (Microsoft PowerPoint VBA), das die Aufgabe lösen soll, wahlweise aus einer Microsoft Word oder Microsoft Excel Datei eine Powerpoint Datei zu erstellen. Dazu kann der Anwender das Aussehen der Powerpoint Datei konfigurieren, z.B. indem er das Logo ein- oder ausblendet, eine zusätzliche Grafik anzeigt, die Anzahl der Gliederungsebenen bestimmt, Datum, Copyright oder Seitenzahlen anzeigen lässt und ähnliches.

Skizze der Systemgrenzen

Dabei ist immer die Anwendersicht zu beachten, die Existenz der Konfigurationsdateien und des Logfiles (grüne Farbe) ist in diesem System für den Anwender nicht transparent. Wohl aber einige der Paramter, die in der Konfigurationsdatei abgespeichert werden.

Anschließend sind die Komponenten und darin die einzelnen Elementarprozess zu definieren.

Und hierin liegt dann schon die erste Schwierigkeit: was eigentlich ist ein Elementarprozess? Klar ist, er ist der kleinste Prozess aus Anwendersicht, der ein in sich abgeschlossenes Ergebnis erreicht – auch dann, wenn die eigentliche Absicht des Anwenders darüber hinaus geht.

Beispiel:  Der Anwender möchte wissen, wieviel Stück von einem Artikel noch auf Lager sind. Dazu nutzt er zuerst die Möglichkeit, in einer Suchmaske alle relevanten Artikelnummern mit Artikelbeschreibung zu einem Stichwort zu suchen. Dann selektiert er die gewünschten und lässt sich dazu die Stückzahlen anzeigen.

Ist das nun ein Elementarprozess oder handelt es sich um zwei? Die Standardantwort lautet wohl: “Kommt darauf an.” In obigem Beispiel ist es durchaus möglich, dass der Anwender mehrere Male sucht, bis er die gewünschten  Artikelnummern plus Artikelbeschreibung gefunden hat. Und jedes Mal könnte er die Suche auch an dieser Stelle abbrechen und hätte damit ein in sich abgeschlossenen Prozess erreicht.

Es kommt also darauf an, nicht nur das Endziel des Anwenders zu sehen, sondern auch evtl. Zwischenziele, die bereits einen Abschluss des Prozesses darstellen.

Die Zerlegung der Anwendung in Elementarprozesse ist ein sehr wichtiger Schritt, der häufig zu sorglos durchgeführt wird. Hier hilft es zu der Benennung der Prozesse auch immer das Ziel und das Prozessergebnis in Stichworten zu notieren. Ist dies nicht möglich, so handelt es sich vermutlich um Prozesschritte und nicht um eigene Elementarprozesse.

Anschließend werden den Elementarprozessen die Funktionsarten zugeordnet:

  • Eingabe (external input – EI)
  • Ausgabe (external output – EO)
  • Abfrage (external inquiry – EQ)

und Datenbestände gezählt:

  • Interner Datenbestand (internal logical file -ILF)
  • Referenzdatenbestand (external interface file – EIF)

Auch hier gibt es öfters Schwierigkeiten und daher ist die Bestimmung der Merkmale zur Definition des CPM (Counting Practices Manual, aktuelle Version: 4.3) wichtig. Optimal ist es, wenn man eine einfache Checkliste nutzt. Es gibt auch Software, die entsprechende Hilfsfragen stellt.

Beispiel:  In easyPresenter gibt es die Möglichkeit die Sprache umzuschalten – sicher ein Elementarprozess, weil in sich abgeschlossen.

Auswahl der Sprache

Aber was für einer? Eine Eingabe? Auf den ersten Blick wohl nicht, weil ja keine Datenbestände verändert werden und auch keine zugeordnet werden können. Dennoch ist es eine, da es sich um eine Änderung des Systemverhaltens handelt. Zugehörige Datenbestände gibt es allerdings keine – die dazu benutzten Konfigurationsdateien werden nicht betrachtet.

Auch hier helfen Fragen in einer Checkliste weiter, die aus dem CPM abgeleitet werden.

Zur Bestimmung der Komplexität der Funktionen benötigt man die Anzahl der Datenfelder (data element type – DET) und der Datenbestände, die referenziert werden (file type referenced – FTR). Damit lässt sich dann die Komplexität als Function-Point Werte aus dem CPM  gemäß der Tabellen ablesen.

Ähnlich bei der Bestimmung der Komplexität der Datenbestände: hier zählt man wiederum die Anzahl der Datenfelder und die Untergruppen von Datenelementen (record element types – RETs). Auch dazu gibt es im CPM die entsprechenden Tabellen.

Das Problem liegt aber nicht in der Vorgehensweise, sondern in der Abgrenzung. Ist dies nun aus Anwendersicht ein Elementarprozess oder nicht? Sind das eigene Datenfelder oder nicht? Ist das nun innerhalb des Systems oder nicht?

Hilfreich hierbei sind Checklisten, die sich jedes Unternehmen für seine eigenen Anwendungen erstellt und die typische Fragestellungen enthalten.

Aktuell erstelle ich für einen Kunden derzeit eine solche Checkliste, sobald sie fertig ist und vom Kunden validiert wurde, werde ich sie hier veröffentlichen.


Whitepaper-Banner flach

Zurück