Functional Size Measurement

Functional Size Measurement (FSM) hat seine Wurzeln in den 70’er Jahren und wurde durch das so genannte Produktivitäts-Paradoxon, welches von Capers Jones beschrieben wurde, bekannt.

Ausschlaggebend waren die Unzulänglichkeiten der Lines of Code  (LOC)- Methoden, welche zur Bewertung von Software, sei es beispielsweise in Form von Qualität, Aufwand oder Umfang herangezogen wurden.

Durch LOC wird lediglich die Anzahl der Codezeilen nach bestimmten Regeln gezählt. Nur leider gibt es bei dieser Vorgehensweise ein entscheidendes Problem: Je komplexer und mächtiger eine Programmiersprache ist, desto weniger LOC werden pro realisierter Funktion generiert.

Bei der Annahme, dass die Produktivität gleich der durchschnittlichen Programmierleistung in LOC ist, würde, aus dem Blickwinkel der LOC-Methoden, die Produktivität sinken und zwar bei steigender Effizienz der Programmiersprache. In der Realität wächst jedoch die Produktivität des Programmierens in der Regel mit der Komplexität und Mächtigkeit einer Programmiersprache.

Noch deutlicher wird dieses Paradoxon, wenn man für die Realisierung einer Funktion beispielsweise im 1. Fall die Programmiersprache Assembler verwendet und im 2. Fall die Programmiersprache C++. Für die Realisierung einer identischen Funktion sind bei einem Assemblerprogramm wesentlich mehr Codezeilen zu generieren als in der Sprache C++. Demnach wäre die Produktivität beim Assemblerprogramm unter Einbeziehung von LOC-Methoden höher als bei dem C++ Programm, da die LOC im 1. Fall größer sind als im 2. Fall. Dieses Ergebnis ist jedoch in der Realität nicht nachvollziehbar. Warum sollte die Produktivität der Software-Entwicklung im 1. Fall höher sein als im 2. Fall, obwohl doch in beiden Fällen die gleiche Funktion abgebildet wird?

Ein Vergleich der LOC in den beiden Fällen ist demnach in der Regel nicht zulässig. Und genau hier liegt die Schwachstelle bei der Verwendung von LOC-Methoden.
Anders sieht es bei der Verwendung von FSM-Methoden aus. Hier wird nur die Funktionalität einer Software für die Bewertung herangezogen. Und diese ist die ausschlaggebende Bewertungskomponente, denn aus Nutzersicht ist es völlig irrelevant, welche Programmiersprache und welche Codezeilenanzahl Verwendung finden. Entscheidend ist, dass die Software die Funktionalität bietet, die vom Nutzer gewünscht ist. Ein Vergleich über alle in der Praxis verwendeten Programmiersprachen ist daher zulässig.

Dieses Produktivitätsparadoxon ist demnach ein entscheidendes Argument gegen die Verwendung von LOC-Methoden.
Natürlich haben LOC-Methoden trotzdem ihre Existenzberechtigung. Diese mögen für die Produktivitätsermittlung weniger geeignet sein, für andere Messausprägungen sind sie dagegen gut verwendbar.
So können LOC-Methoden u. a. für die Ermittlung des Wartungsaufwandes herangezogen werden. Hierbei gilt folgende Regel ([DUMKE96], S. 23):
„Je größer die LOC, je größer ist der Wartungsaufwand“.

Die Grundintension der funktionalen Größenmessung ist, dass die durch die Software abgebildete Realität sich dem Nutzer als Funktionalität der Software darstellt. Die Funktionalität ist dabei die Basiskennzahl für die Bewertung von Software-Produkten.
Die Funktionalität einer Software stellt sich dem Anwender beispielsweise anhand der Software-Oberfläche in Form von Formularen, Listen, Bildschirmen, gesendeten oder empfangenden Informationen einerseits und in den für den Nutzer gespeicherten Informationen andererseits dar (Vgl. [HÜRTEN99] Seite 10).
Je mehr Formulare der Nutzer beispielsweise verwendet, umso größer ist für ihn die Funktionalität. Dabei ist jedoch zu beachten, dass nicht allein die Anzahl der Listen, Formulare etc. ausschlaggebend ist, sondern auch die in den einzelnen Listen oder Formularen enthaltenden Informationen.
Robert Hürten definiert die Funktionalität einer Software so:
„Die Anzahl der Informationen, die der Anwender einer Software nutzt, bestimmt aus Sicht dieses Anwenders die Größe der Funktionalität dieser Software.“
(Quelle:[HÜRTEN99], S. 10).
Hieraus lässt sich nun der Begriff FSM ableiten. FSM ist demnach der Prozess der Messung von funktionalen Größen von Software.
Die ISO definiert daher zweckmäßigerweise:
Functional Size Measurement = „The process of measuring Functional Size.“ [ISO 14143].

Wobei Functional Size laut ISO für Folgendes steht:
Functional Size = „A size of the software derived by quantifying the Functional User Requirements.“ [ISO 14143].
Die Verwendung der Basisgröße Funktionalität bezieht sich aber gerade nicht auf das “WIE” einer Software, sondern vielmehr auf das “WAS”. Ausschlaggebend ist daher, was eine Software kann und was ein Nutzer wissen muss, um diese effektiv anzuwenden.

Robert Hürten nennt zwei wichtige Vorteile:
1.„Eine funktionsabhängige Basisgröße ist unabhängig von dem jeweiligen Stand der Hard- und Softwaretechnologie“ und
2.„Die Funktionalität wird auf einer Sprachebene beschrieben, die sowohl vom Anwender als auch vom Informatiker verstanden wird.“
(Quelle: [HÜRTEN99], S. 10-11).

Ein weiterer nicht zu vernachlässigender Vorteil der Betrachtung der Funktionalität ist die zeitliche Anwendbarkeit. Die Funktionalität kann früh, zum Beispiel schon in der Fachkonzeptphase  der Softwarenetwicklung eingesetzt werden.
Es ist so möglich, noch vor der eigentlichen Programmiertätigkeit die Größe der Software zu messen und den Aufwand des Software-Produktes zu schätzen.
Dieser zeitliche Effekt und die Unabhängigkeit der Basisgröße Funktionalität von dem jeweiligen Stand der Hard- und Softwaretechnologie ermöglicht es nun, differente Methoden der Software-Entwicklung und der technischen Plattformen auf ihre Wirtschaftlichkeit und Produktivität hin zu untersuchen bzw. zu vergleichen, um so ein sinnvolles internes und externes Benchmarking von Software-Projekten durchzuführen.
Im Bereich der funktionalen Größenmessung gibt es eine Vielzahl an Methoden. Dies gründet sich aus dem historischen Verlauf der Entwicklung.
Wie aus der folgenden Abbildung ersichtlich ist, war die FSM-Historie vielfältigen Veränderungen unterworfen, so dass zu unterschiedlichen Zeiten mannigfaltige FSM-Methoden entwickelt wurden, die wiederum von anderen abgelöst wurden.
 

fsm

Quelle: [LOTHER01], S.2)

Die ursprünglich von Albrecht entwickelte FP-Methode wurde seit den 90er Jahren durch die IFPUG erweitert und standardisiert. Sie ist eine der heute am gebräuchlichsten Formen, die in der Praxis Anwendung finden.
Neben dieser Entwicklungsevolution wurden parallel dazu andere Verfahren entwickelt, die für spezielle Fälle Anwendung finden. Insbesondere die von Symons entwickelte MKIIFP wurde durch ihre neuen Ansätze bekannt.
Eine relativ neue und in der Fachwelt viel beachtete Methode ist die COSMIC FFP-Methode, bei der vor allem der Aspekt der Funktionalität von Interesse ist, die die Software dem Nutzer bereitstellt.
Diese und andere wichtige Softwaregrößenmessmethoden sollen im Folgenden näher betrachtet werden. Zusätzlich dazu wird auf eine in der Fachwelt kontrovers diskutierte Methode, dem Backfiring, eingegangen, mit deren Hilfe die funktionalen Größen nicht durch traditionelles Zählen, sondern durch die Nutzung von Umrechnungstabellen geschätzt werden.

FSM-Methoden:

Function Point Methode nach IFPUG

Mark II Function Point Methode

Full Function Point Methode 1.0

COSMIC Full Function Point Methode

Backfiring

Fazit

[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