Wenn ein Malermeister für das Streichen eines kleinen Raums zwei Wochen Arbeitszeit berechnet und der Auftraggeber ihn fragt: "Wie kann es sein, dass das Streichen von 55 m² zwei Wochen dauert?", so wird ihm die Antwort: "Wir haben ja auch 400 Liter Farbe verbraucht" als Erklärung kaum ausreichen.

Wenn hingegen ein Software-Dienstleister für die von ihm erbrachte Leistung zwölf Personenmonate in Rechnung stellt, dann ist es durchaus denkbar, dass der Auftraggeber die Aussage: "Wir haben ja auch 120.000 Zeilen Code programmiert" als Erklärung für diesen Aufwand akzeptiert. Welcher Leistungsumfang tatsächlich erbracht wurde, ist jedoch in der Regel unbekannt. Der Auftraggeber kann nur vermuten, ob der Arbeitsaufwand angemessen war.

Ein objektives Maß für die Größe der gelieferten Software könnte hier Klarheit schaffen. Mit "Größe einer Software" ist dabei nicht die Dateigröße oder die Code-Länge der lauffähigen Software gemeint – diese hängt auch von vielen technischen Faktoren ab, sondern der Leistungsumfang, den die Software dem Anwender liefert. Zur Angabe der Größe einer Software benötigen wir deshalb eine Maßeinheit aus Sicht des Anwenders und nicht des Entwicklers.

Ein von technischen Rahmenbedingungen unabhängiges Maß für die Software-Größe würde es möglich machen, z.B. verschiedene Angebote für eine Software-Produktion auf einer objektiven Bezugsgröße miteinander zu vergleichen oder in einem Software-Entwicklungsprojekt den Fortschritt verlässlich zu ermitteln.

Größe von Software messen

Wenn wir eine Messmethode für die so definierte Größe von Software entwickeln wollen, dann muss diese unabhängig von der Art der Software oder einer konkreten Technologie sein. Die Anzahl der Zeilen des Programm-Codes (Lines of Code = LOC) taugen deshalb nicht als Messgröße. Wir benötigen vielmehr eine Methode, mit der wir die Größe der Steuerungssoftware einer Maschine, einer Office-Applikation, eines ERP-Systems, eines webbasierten Onlineshops oder einer Mobile-App gleichermaßen bestimmen können. Damit dies gelingt, benötigen wir einen Maßstab, der allen Anwendungen gemeinsam ist.

Alle Software-Anwendungen haben gemeinsam, dass sie ihren Benutzern eine bestimmte Funktionalität bieten. Diese ist zwar unabhängig von der technischen Umsetzung der Anwendung, lässt sich aber auf den ersten Blick schwer quantifizieren. Funktionalität wird z.B. häufig mit sog. User Stories beschrieben. Die Größe einer jeden User Story wird mit sog. Story Points geschätzt. Im Wort "schätzen" liegt jedoch schon das Problem: Die Größe soll nicht geschätzt, sondern gemessen werden.

Hierfür müssen wir die Funktionalität einer Software so weit abstrahieren, dass sie objektiv messbar ist. Ein Lösungsansatz dafür besteht darin, die Funktionalität aus Anwendersicht zu betrachten und sie in drei allgemeine Funktionen zu gliedern:

• Ein Anwender gibt Daten in die Software ein.
• Die Software gibt Daten an den Anwender aus.
• Die Software verwaltet intern Daten.

Dieser für manche vielleicht verwegen klingende Ansatz betrachtet Software als eine Art Kasten, ähnlich einem Spielautomaten, in den man etwas eingibt und der dann wiederum nach einer für den Benutzer nicht erkennbaren Regel etwas ausgibt. Was sich im Inneren des Kastens abspielt, ist für den Anwender letztlich unerheblich.

Bild 1: Die Idee der Function-Point-Analyse: Software als Kasten, in den man etwas eingibt und der etwas ausgibt. Quelle: http://commons.wikimedia.org/wiki/File:Jackpot_6000.jpg

Wenn wir nach diesem Prinzip ein Maß für Software-Anwendungen definieren wollen, dann müssen wir als erstes klären, was alles zur Anwendung gehört. Nur so können wir Datenflüsse in und aus der Anwendung betrachten. Gehört z.B. ein Drucker zur Anwendung, dann werden die Daten intern zum Drucker geschickt und bilden keine zu betrachtende Funktionalität. Gehört der Drucker nicht zur Anwendung, dann hat sie eine Schnittstelle, über die Daten zum Drucker geschickt werden und die deshalb bei der Quantifizierung zu berücksichtigen ist.