Standard für automatisierte Function-Point-Analyse

In Softwareprojekten gelten Function Points als Maßstab, um sinnvoll den Umfang von Sourcecode zu ermitteln. Allerdings fehlte bislang ein Verfahren, mit dem sie sich automatisiert erfassen lassen. Das behebt die Spezifikation der Automated Function Points.

In Pocket speichern vorlesen Druckansicht 4 Kommentare lesen
Lesezeit: 9 Min.
Von
  • Paul Nash
Inhaltsverzeichnis

In Softwareentwicklungsprojekten gelten Function Points als Maßstab, um sinnvoll den Umfang von Sourcecode zu ermitteln. Allerdings fehlte bislang ein Verfahren, mit dem sie sich automatisiert erfassen lassen. Das behebt die Spezifikation Automated Function Points (AFP) der Object Management Group (OMG) und des Consortium for IT Software Quality (CISQ).

Viele Softwareentwicklungsprojekte weisen Mängel auf: Das Zeit- und Finanzbudget wird überschritten, und die Qualität der Anwendungen und des Sourcecodes ist unbefriedigend. Ein Grund für solche Fehlentwicklungen ist oftmals, dass sich Teams darauf beschränken, prozessorientierte Faktoren in den Vordergrund zu stellen, etwa die Termintreue und Konformität mit Spezifikationen und Vorgehensmodellen. Punkte, die unmittelbar mit dem eigentlichen Produkt, dem Sourcecode, in Verbindung stehen, bleiben außen vor. Dazu zählen Menge und Qualität des Codes und somit die Produktivität, also das Verhältnis zwischen Ergebnis und Aufwand bei der Entwicklung einer Software.

Traditionelle Analyseverfahren im Rahmen von Softwareentwicklungsprojekten räumen dem eigentlichen Endprodukt, dem Sourcecode, zu wenig Raum ein.

Eine detaillierte und objektive Erfassung dieser Größen ist jedoch ein wertvolles Instrument, um die Kosten eines Entwicklungsvorhabens plausibel beurteilen zu können. Beispielsweise ist es möglich, das Volumen von Code mit einer Function Point Analysis (FPA) festzustellen. Sie ermittelt die "Größe" einer Anwendung anhand der Funktionen, die sie dem Anwender zur Verfügung stellt. Als Maßzahl dienen bei einer solchen Bewertung sogenannte Function Points. Sie sind ein Maß für die "Schwere" beziehungsweise Komplexität eines elementaren Prozesses (Funktion) einer Anwendung. Ein solcher Prozess entspricht grob einem Systemanwendungsfall in der Unified Modeling Language (UML).

Function-Point-Analysen wurden für transaktionsorientierte, interaktive Systeme konzipiert. Eine FPA des Sourcecodes ermittelt die funktionale Größe, also den fachlich-funktionalen Umfang eines Softwaresystems, und zwar unabhängig von der verwendeten Technik. Functions Points dienen als Maßstab für die Zahl und den Umfang der fachlichen Funktionen der IT-Anwendung. Die FPA gemäß ISO 20926 gliedert eine Anwendung in sogenannte "Elementary Processes" auf. Dasgeschieht auf Grundlage folgender Regeln:

  • Die Bewertung erfolgt aus Sicht des Nutzers eines Softwaresystems beziehungsweise der Geschäftsprozesse. "Anwender" sind in diesem Fall nicht nur menschliche Nutzer einer Software, sondern auch andere IT-Systeme, die auf das Programm zugreifen.
  • Jeder Elementary Process wird nur einmal gewertet, unabhängig davon, wie häufig er innerhalb einer Applikation zum Einsatz kommt.
  • Ein solcher Elementarprozess ist die aus Sicht eines Anwenders kleinste in sich abgeschlossene Aktion, die sich auf einem System durchführen lässt.

In der Spezifikation IFPUG-CPM 4.3.1, die die International Function Point User Group (IFPUG) erarbeitet hat und als De-facto-Standard im FPA-Bereich gilt, sind folgende Elementarprozesse definiert:

  • Eingaben (External Input, EI): Daten gelangen von außen (über die Systemgrenze hinweg) in die Anwendung.
  • Ausgaben (External Output, EO): Ein System stellt zuvor verarbeitete Daten zur Verfügung.
  • Abfragen (External Inquirey, EQ): Ein System liefert zuvor nicht verarbeitete Daten.
  • Interne Datenbestände (Internal Logical File, ILF): logisch zusammenhängende Informationen innerhalb des Systems, die sich bearbeiten und verändern lassen.
  • Referenzdaten (External Interface File, EIF): Daten, die ein externes System bereitstellt.

Im Rahmen einer automatischen Function-Point-Analyse ist der Sourcecode von entscheidender Bedeutung, weil dessen Umfang und Qualität die Eigenschaften eines Systems fast vollständig bestimmen und dies das eigentliche "Deliverable" darstellt. Das Resultat einer "Vermessung" des Programmcodes sollte sinnvollerweise der funktionale Nutzen der Anwendung bei gleichzeitiger Erfüllung der technischen Anforderungen sein.

In der Regel werden die Function Points manuell erfasst. Dabei konzentrieren sich die Fachleute auf die Funktionen einer Anwendung; eine Codeanalyse findet nicht statt. Das Verfahren hat mehrere Nachteile: Es kostet viel Zeit und hat daher jedes Mal Kosten für den Nutzer zur Folge, das gilt insbesondere für komplexe Anwendungen. Und die Resultate sind nur eingeschränkt vergleichbar, weil sie durchaus auch von der Erfahrung des jeweiligen Zählers abhängen.

Diese Nachteile lassen sich durch eine Automatisierung der Function-Point-Analyse beseitigen. Die Grundlage der Automatisierung des FPA-Verfahrens ist die Vergleichbarkeit der funktionalen Elementarprozesse und der Transaktionen (im Sinne von Call-Beziehungen) durch das Anwendungssystem.

Im Februar 2013 veröffentlichten die Object Management Group (OMG) und das Consortium for IT Software Quality (CISQ) den ersten Entwurf einer Spezifikation für Automated Function Points (AFP). An der Entwicklung der Norm wirkten zudem zwei Unternehmen mit: Die David Consulting Group, ein Dienstleister mit Erfahrung im Bereich FPA, und CAST, ein Softwarehersteller, der sich auf die automatisierte Messung von Qualität, Größe und Architekturkonformität von Unternehmensanwendungen spezialisiert hat.

Die AFP-Norm ist mit IFPUG-CPM 4.3.1 konform. Dabei ist der Standard objektiv und konsistent in Bezug auf die Wiederholbarkeit und die Anwendung auf unterschiedliche Techniken, Architekturen und Applikationsgrößen.

Eine Automated-Function-Point-Analyse muss jede Transaktion gemäß den IFPUG-Regeln gewichten.

Die relevante Messgröße ist der Sourcecode. Andere Faktoren wie das Fachwissen oder die Absichten eines Entwicklers werden naturgemäß nicht berücksichtigt. Laut dem AFP-Standard sind im Rahmen einer automatischen FP-Analyse diverse Artefakte zu identifizieren. Dazu gehören Anwendungsdaten und die Logik der Applikation über alle Schichten hinweg.