zurück zum Artikel

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 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.

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 [1] 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.

Bislang manuelle Zählung von Function Points

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.

Details des AFP-Standards

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.

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.

Tools und Einsatz

Tools für AFP noch rar gesät

Derzeit gibt es auf dem Markt nur wenige Angebote für die automatisierte Function-Point-Analyse, die die Vorgaben der OMG-Spezifikation vollständig berücksichtigen. Die Application Intelligence Platform (AIP) von CAST Software repliziert beispielsweise das manuelle Zählverfahren von Function Points. Dabei gewichtet das Werkzeug Transaktionen und ihre Komponenten gemäß den IFPUG-Regeln. Das gilt für Data Element Types (DET), File Types Referenced (FTR) und Record Element Types (RET).

Wichtig ist zudem eine weitere Funktion, die im Rahmen des Lebenszyklus einer Software häufig übersehen wird: die Messung des Umfangs von Änderungen an einer Anwendung. Auch bei solchen Anpassungsarbeiten ist eine Ermittlung der Function Points hilfreich. Das setzt jedoch voraus, dass zuvor ein "Baselining", eine Analyse der Software im Release vor erfolgter Änderung, durchgeführt wird.

Einsatzfelder und Vorteile von AFP-Analysen

Zusammenfassend lässt sich sagen, dass eine automatisierte Function-Point-Analyse im Vergleich zu Ansätzen wie dem reinen Zählen von Sourcecode-Zeilen deutliche Vorzüge aufweist. Das betrifft insbesondere die Messung der Produktivität von Zulieferern. Mit Tools lassen sich beispielsweise folgende Auswertungen durchführen:

Vergleich der Leistungen von Vertragspartnern und unterschiedlicher Produktivitätswerte, etwa der Zahl der Function Points, die Zulieferer pro Monat implementieren, im Vergleich zur Produktivität anderer Zulieferer. Eine automatische FPA erlaubt es somit, die Leistungen von Vertragspartnern (externen Software-Entwicklern) zu vergleichen und deren Arbeit besser zu steuern.

• Die Messung der Qualität und Komplexität von Anwendungen: Diese Daten können in die Entwicklung neuer oder Anpassung vorhandener Softwareprodukte einfließen.
• Identifizierung ineffizienter Prozesse: Ein Hinweis auf suboptimale Prozesse ist eine niedrige Produktivität. Die Analyseresultate lassen sich zur Optimierung von Abläufen heranziehen.
• Messung der Effekte, die Optimierungsmaßnahmen haben: Mit AFP-Analysen können Unternehmen prüfen, ob die Verbesserung von Prozessen die erhofften positiven Auswirkungen haben.
• Zielkontrolle: Mit der Function-Point-Analyse können Entwickler abschätzen, ob die angestrebten Projektziele erreicht werden, etwa in Bezug auf das Volumen einer Anwendung.

Fazit

Die automatisierte, rechnergestützte Analyse auf Basis des AFP-Standards gibt Softwareentwicklern und IT-Abteilungen ein leistungsstarkes Werkzeug an die Hand, mit dem sie die Qualität von Anwendungen und die Produktivität im Rahmen von Softwareentwicklungsprojekten messen und optimieren können.

Klassische Fehleinschätzungen, die auf dem Vergleich von "Äpfeln mit Birnen" erfolgten, lassen sich dadurch vermeiden. Denn dem Softwarefachmann stellen verfügbare Tools umfassende und vor allem objektiv vergleichbare Analyseergebnisse zur Verfügung.

Paul Nash
ist Technical Director bei der CAST GmbH in München.

Exkurs

Exkurs: Function Points in der Praxis

Im Rahmen des Function-Point-Modells wird jede Transaktion mit mindestens 3 fp und maximal 7 fp bewertet. Beispiele für solche Transaktionen sind beispielsweise "Neuen Kunden erfassen" mit 6 fp oder "Auswahlliste mit Artikelnummern anzeigen" (3 fp). Nach Angaben von QuantiMetrics, einem Beratungshaus, das Gutachten und Bewertungen über IT-Anwendungen und IT-Projekte erstellt, werden in der Praxis Näherungsverfahren (Rapid) eingesetzt, bei denen pro Transaktion nur 4 oder 5 fp vergeben werden. Weitere Punkte fallen für die Datenbestände (UML-"Classes") an. Allerdings machen diese in der Regel nur 20 Prozent des Gesamtpunktergebnisses aus.

Ein SAP/R3-Modul beispielsweise hat mehrere 1000 fp. Ein CRM-System (Customer Relationship Management) kommt auf etwa 2500 bis 5000 fp. Nach Erfahrungswerten von QuantiMetrics, die sich auf die Auswertung von 500 Projekten bei Großunternehmen stützt, weisen 50 Prozent der Softwareprojekte eine Produktivität von 9 fp/pm auf. Mit pm wird ein Personenmonat (130 Stunden) bezeichnet. An die 10 Prozent der Projekte liegen unter 3 fp/pm, weitere 10 Prozent bei mehr als 33 fp/pm. (ane [2])

URL dieses Artikels:
https://www.heise.de/-2067044

Links in diesem Artikel:
[1] http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=35582
[2] mailto:ane@heise.de

Copyright © 2013 Heise Medien