Function Points statt Codezeilen

Benjamin Poensgen favorisiert deshalb Function ­Points als Maßeinheit. Diese basieren auf Elemen­tar­pro­zessen. Darunter versteht der Autor eines Fach­buches zur Function-Point-Analyse »die kleinste sinnvolle Funktion, die man mit der Software ausführen kann«. Als Beispiel nennt er das Anlegen eines Termins im Outlook-Kalender oder das Ausdrucken eines ­Datensatzes. »Ein Elementarprozess hat im Mittel vier bis fünf Function Points«, erläutert Poensgen. Deren Aussagekraft entspricht in seiner eingangs erwähnten Hausbau-Analogie der bewohnbaren Fläche des Gebäudes. Function Points bilden somit aus seiner Sicht eine funktionale Metrik, die Aussagen über den ­Nutzen erlauben. Die Aufteilung der Elementarprozesse in Function ­Points erfolgt keineswegs willkürlich; der ISO-Standard 20926 definiert hier einen schlüssigen Maßstab. Die Analyse dieser Function Points (FPA) ist eng mit dem Anforderungsmanagement in der Softwareentwicklung verzahnt: Am Anfang steht die Anforderungsbeschreibung der Lösung, aus der ein Planwert des Funktionsumfangs erstellt wird. Am Ende des Projekts wird dann abgeglichen, ob die geplanten Funktionspunkte auch umgesetzt wurden.