SNAP! Die Function-Point-Analyse wird vervollständigt
Um den Umfang von Projekten zu schätzen, wird oft und gerne die Function-Point-Analyse (FPA) eingesetzt. Sie misst den Umfang anhand ihrer Funktionspunkte, hat jedoch den entscheidenden Nachteil, Varianzen im Umfang des Entwicklungsaufwandes außer Acht zu lassen, die beispielsweise durch nicht funktionale Anforderungen (NFA) entstehen. Hier setzt eine neue Methode an: SNAP!
Die IFPUG-Function-Point-Analyse (IFPUG-FPA) ist die älteste Methode zur Bestimmung der Function-Points. Dementsprechend existieren in Beratungsunternehmen, Anwenderunternehmen und Non-Profit-Organisationen die meisten Benchmarkdaten für die IFPUG-FPA. Diskussionen über ihre Unzulänglichkeiten führten nun zu einer Weiterentwicklung der verwendeten Methoden. Die IFPUG (International Function Point Users Group) griff das Thema auf und entwickelte einen neuen Standard. Zum Verständnis ist es notwendig, kurz die Grundlagen der IFPUG-Function-Point-Analyse zu erläutern.
Die Function-Point-Analyse (FPA) ist eine gängige Methode, um die funktionale Größe oder die Menge der funktionalen Änderungen einer Anwendung zu bestimmen. Das Ergebnis ist die funktionale Größe (Functional Size), die in Function-Points (fp) gemessen wird. Die FPA ist die älteste und aktuell deutlich verbreitetste Verfahrensweise.
Grundlagen der IFPUG-Function-Point-Analyse (FPA)
Der IFPUG-FPA liegt ein strenger Blick aus der Benutzersicht zugrunde. Er wird aus den fixierten funktionalen Anforderungen an ein System abgeleitet. Als Metrik dient dabei der fachliche Prozess, der ein aus Benutzersicht sinnvolles und einzigartiges Ergebnis bringt. Der Begriff Prozess ist hier nicht im gleichen Sinne wie in der Geschäftsprozessmodellierung zu verstehen. Die FPA nimmt vielmehr den kleinsten, nicht mehr teilbaren – sogenannten Elementarprozess – ins Visier.
Meist interviewt der Analyst den Personenkreis, der die fachlichen Anforderungen beschreiben kann: Mitarbeiter der Fachabteilungen, aber auch Systemanalytiker. Teilweise werden auch Dokumente genutzt. So gibt es durchaus die Variante, dass der FP-Experte eine Analyse aufgrund von Dokumenten durchführt und das Ergebnis in Workshops abstimmt.
Die FPA ermittelt eine Maßzahl für die fachliche Größe der Anforderungen. Mit dieser Maßzahl wird der Aufwand für die Realisierung geschätzt. Für die Schätzung stehen verschiedene Methoden bereit. Das älteste Verfahren ist die in der ursprünglichen FPA definierte methodische Erweiterung zur Aufwandsschätzung. Das heute bekannteste Verfahren ist das Constructive Cost Model (COCOMO). Die Schätzverfahren brauchen Daten vergangener Projekte, die in einer Erfahrungsdatenbank erfasst werden. Das führt nicht zwangsläufig zu genauen Schätzungen. Fehler oder Ungenauigkeiten in den historischen Daten beeinflussen die Treffsicherheit der Schätzung.
Nun könnte man vermuten, dass sich aufgrund bekannter, objektiv messbarer Kennzahlen aus dem Software-Engineering eine Korrelation zu den gemessenen FP finden ließe. Diese sind aber nach Wissenstand des Autors bisher nicht zweifelsfrei belegt. Die FPA ist eine Außensicht: Sie stellt keine der Software intrinsischen Größen auf.
SNAP: Die Initialzündung des neuen Standards
Der ein und der gleiche Fachprozess lässt sich nicht eindeutig mit einem Aufwand korrelieren. Zu Schwankungen führen zum einen die nicht funktionalen, technischen Anforderungen, zum andern die nicht funktionalen Anforderungen (NFA) an die Qualität einer Software, sowie die Rahmenbedingungen aus dem Umfeld des Projektes bzw. des Unternehmens. Alle genannten Faktoren erhöhen die Komplexität einer Software. Beide Arten der nicht funktionalen Anforderungen ändern aber nichts an der Größe des fachlichen, funktionalen Prozesses. Somit muss die FPA eine Außensicht bleiben. Der Anwender kann nur mit Gruppierungen aus ähnlichen Projekten in den Erfahrungsdaten eine reproduzierbare Korrelation zu den Aufwänden finden.
Diesem Fakt begegnet die IFPUG mit einem neuen Standard: dem SNAP-Standard. Das Akronym bedeutet "Software Non-functional Assessment Process". Der Standard ist im "Software Non-functional Assessment Process (SNAP) – Assessment Practices Manual" [1] beschrieben.
Im Assessment-Prozess wird folgendermaßen vorgegangen:
- Der Analyst nimmt wie in der FPA die Benutzersicht auf die nicht funktionalen Anforderungen ein.
- Die funktionale Sicht wird mit der Sichtweise der Entwickler in Bereiche (Partitions) weiter unterteilt.
- In den Partitions werden die technischen Zähleinheiten (SNAP Counting Units – SCU) definiert.
- Eine Zähleinheit kann funktionale und nicht funktionale Anforderungen erfüllen. Die funktionalen werden wie gewohnt mit der FPA vermessen, die nicht funktionalen werden mit den SNAP-Kategorien gezählt bzw. gewichtet. Ich benutze den Begriff Gewichtung für den englischen Begriff "assessed".
- Das Ergebnis ist eine Zahl für die technische Größe der Anwendung unter Betrachtung.
Daraus resultieren zwei Metriken: eine funktionale und eine technische. Schwankungen lassen sich so besser korrelieren.
Eine funktionale Anforderung legt fest, was das Produkt tun soll. Ein Beispiel: "Das Produkt soll Verkehrsdichtedaten speichern und Informationen zu Staus liefern."
Nicht-funktionale Anforderungen (NFAs) gehen über die reine Funktion hinaus. Dazu zählen:
- Benutzbarkeit: Wie verständlich und einfach bedienbar muss das System sein?
- Aussehen und Handhabung: Wie ist das Look-and-Feel?
- Korrektheit: Wie fehlerfrei müssen die Ergebnisse sein?
- Flexibilität: Wie anpassungsfähig ist das System?
- Skalierbarkeit: Wie werden mehr Anwender bedient oder höhere Datenmengen verarbeitet?
- Zuverlässigkeit: Wie ausfallsicher muss das System sein? Welche Ausfallzeiten und welcher Datenverlust ist akzeptabel? Welche Anforderungen gelten für Datenintegrität und Verfügbarkeit?
- Leistung und Effizienz: Welche Antwortzeiten sind akzeptabel?
- Betrieb und Wartbarkeit: Welche Randbedingungen gelten für den Betrieb?
- Portierbarkeit: Muss das System portable sein?
- Sicherheitsanforderungen: Welche Stufe der Vertraulichkeit und Informationssicherheit ist erforderlich?
- Weitere Randbedingungen
SNAP-Assessments: Vorbereitungen
Der SNAP-Prozess orientiert sich am Prozess der FPA (s. Abb.1).
Jeder, der mit dem Prozess der FPA vertraut ist oder sogar eine IFPUG-Zertifizierung hat, findet sich schnell wieder und kann sich auf die eigentlichen Fragen konzentrieren.
Die ersten Schritte des SNAP-Prozesses dienen im Wesentlichen dazu, das Umfeld abzustecken. Der Assessment Purpose legt zum einen den Typ des Assessment – Neu- oder Weiterentwicklung oder Betrachtung einer Applikation – und zum zweiten den Scope fest. Der Scope bestimmt die Menge der NFA, die betrachtet werden. Die Boundary legt die Applikationsgrenzen fest, die zu untersuchen sind. Diese Schritte sind identisch zur FPA.
Damit nun die nicht funktionalen Anforderungen betrachtet werden können sind gemeinsam mit den Entwicklern die Partitions festzulegen. Eine Partition ist eine Gruppierung von Techniken, die eine Gemeinsamkeit bezüglich des wesentlichen Analyseinstrumentariums – den Kategorien – aufweisen. Es ist keine Gruppierung nach technischen Kriterien, sondern nach den realisierten nicht funktionalen Anforderungen.
Ein klassisches Beispiel ist die Aufteilung der Partitions nach Komponenten (s. Abb.2).
Das Festlegen der Partitions ist spezifisch für den jeweiligen Anaylsezusammenhang. Es soll sich an der Benutzersicht auf die nicht funktionalen Anforderungen wie Wartbarkeit, Portabilität oder Zuverlässigkeit orientieren. Partitions zu definieren ist wichtig, da damit auch die systeminternen Datenflüsse bestimmt werden. Denn genau die werden in der FPA klassischerweise nicht betrachtet. Im Laufe der Anwendung in den Unternehmen entstehen sicherlich Analysemuster. Manche davon werden sich an gängigen Layer-Tier-Modellen orientieren.
Das eigentliche Assessment findet in den nächsten drei Schritten statt. Der erste davon nutzt das wesentliche Analyseelement des SNAP-Standards: Kategorien und Unterkategorien. Eine Kategorie ist eine Gruppe von Komponenten, Prozessen oder Aktivitäten, die benutzt werden, um ein nichtfunktionales Requirement umzusetzen. Eine Kategorie wird wiederum in Subkategorien unterteilt [1].
Die Kategorien sind nicht aus der Luft gegriffen. Sie orientieren sich an gängigen ISO-Standards wie der ISO/IEC 9126-1 oder der ISO/IEC 25010. Gleichzeitig sind sie abstrakt und generisch genug definiert, um von sich verändernden Implementierungsmodellen und -techniken unabhängig zu sein. So bleibt das Analyseinstrumentarium konstant und hat die Verbindung zu der Anwendersicht auf die nichtfunktionalen Anforderungen.
Liste der Kategorien:
- Data Operations
- Data Entry Validations
- Logical and Mathematical Operations
- Data Formatting
- Internal Data Movements
- Delivering Added Value to Users by Data Configuration - Interface Design
- User Interfaces
- Help Methods
- Multiple Input Methods
- Multiple Output Methods - Technical Environment
- Multiple Platforms
- Database Technology
- Batch Processes - Architecture
- Component Based Software
- Multiple Input / Output Interfaces.
SNAP-Assessments: Elementare Analyseschritte
Der erste elementare Anlayseschritt besteht darin, die nichtfunktionalen Requiremnets (NFA) den Kategorien zuzuordnen. Eine NFA kann dabei auch in mehreren Kategorien auftauchen.
Veränderungen in der Technik spiegeln sich nun in dem folgenden, zweiten elementaren Analyseschritt wider. Die eigentlichen Zähleinheiten müssen gefunden werden. Sie orientieren sich an der funktionalen Analyse, die mit der FPA erstellt worden ist. Varianzen in technischen Implementierungen sieht man an zwei Dingen:
- Partitions sind in verschiedenen technischen Implementierungen unterschiedlich.
- Die Zähleinheiten liegen in den Partitions. Eine Zähleineinheit ist eindeutig einer Unterkategorie zugeordnet. Da ein funktionaler Elementarprozess mehrere Partitions betreffen kann, finden sich für eine funktionale Zähleinheit unterschiedlich viele SNAP-Zähleinheiten (Snap Counting Units = SCU).
Somit kann für ein und denselben funktionalen Elementarprozess aus unterschiedlichen Implementierungen heraus eine unterschiedliche Zahl an technischen Zähleinheiten resultieren.
SNAP Assessments: Vervollständigung des Assessments
Die folgenden Schritte sind aus den funktionalen Messmethoden bekannt. Hier macht keine der "Point-Methoden" eine Ausnahme.
Komplexität der Zähleinheit
Nachdem in den vorhergehenden Schritten die Zähleinheiten definiert wurden, muss die Komplexität der Zähleinheit bestimmt werden. Eine Zähleinheit ist eindeutig einer Kategorie zugeordnet. Jede Kategorie definiert spezifische Komplexitätsparameter mit spezifischen Gewichtungen und Punkten. Aus diesen ergibt sich die SNAP-Größe der Zähleinheit.
Ein Beispiel:
Kategorie 2 – Interface Design: Die Zähleinheit ist der Satz an Windows, die dem Elementarprozess zugeordnet sind. Die Komplexitätsparameter sind: Die Summe aller Eigenschaften eines UI-Elements innerhalb einer Zähleinheit, die von einer Änderung betroffen sind. Wenn das Element mehrfach verwendet wird, wird es nur einmal gezählt.
In einer Anwendung muss das fest codierte Literal "Kunde" durch "Geschäftspartner" ersetzt werden. Dies muss in folgenden Elementen geschehen:
- SCU 1: Werben eines neuen Geschäftspartners: Header, labels, radio button, drop-down list
- SCU 2: Ändern der Eingeschaften des Geschäftspartners: Header, labels
- SCU 3: Senden einer Nachricht zum Geschäftspartner: Header, labels,
- SCU 4: Abbestellungen des Geschäftspartner: Header, labels
Das Verändern des Literals wird als das Verändern einer Eigenschaft angesehen.
Bestimmen der SNAP-Points
Wenn die Komplexität der SCU festgelegt ist, können die SNAP-Points gemäß der Tabelle kalkuliert werden. Die IFPUG folgt den Erfahrungen mit der FPA und definiert für eine Subkategorie eine dreistufige Komplexitätsmatrix. Aus dieser lassen sich dann die SNAP-Points für diese Zähleinheit ablesen:
Aus dem vorherigen Beispiel ergibt sich bei einer angenommen User-Interface-Komplexität von Low:
SNAP-Points = 2 * Anzahl der unique UI elements – für jede SCU also:
SP = SCU 1 + SCU 2 + SCU 3 + SCU 4 – also:
SP = 2*(4 + 2 + 2 + 2) = 20 SP
Ermitteln der SNAP-Größe des Betrachtungsgegenstandes
Zunächst werden die Punkte aller Zähleinheiten zu einer Gesamtsumme zusammengefasst. Das ist nichts weiter als Addition aller Subkategorien gruppiert nach den Kategorien zu einer Gesamtsumme. In den ersten Schritten des SNAP Assessments wurde neben dem Scope auch der Zweck des Assessments definiert. Aus diesem ergibt sich die SNAP-Größe des Entwicklungs-, des Weiterentwicklungsprojektes oder Anwendung unter Betrachtung. Der prinzipielle Zusammenhang ist in Abb.4 zu sehen.
Die Formeln sind den mit der FPA vertrauten Analysten bekannt:
Neuentwicklungsprojekt
DSP = ADD
DSP = Neuentwicklungsprojekt (Development project) Snap Points (SP) = alle hinzugefügten NFR: diese bestehen aus:
[Σ of SP for Data Operations] + [Σ of SP for Interface Design] + [Σ of SP for Technical Environment] + [Σ of SP for Architecture]
Weiterentwicklungsprojekt
ESP = ADD+ CHGA + DEL
ESP = Weiterentwicklungsprojekt (enhancement project) SP = alle NFA die hinzugefügt, verändert oder gelöscht werden:
ADD = [Σ of SP for added Data Operations] + [Σ of SP for added Interface Design] + [Σ of SP for added Technical Environment] + [Σ of SP for added Architecture]
CHGA = [Σ of SP for changed Data Operations] + [Σ of SP for changed Interface Design] + [Σ of SP for changed Technical Environment] + [Σ of SP for changed Architecture]
DEL = [Σ of SP for deleted Data Operations] + [Σ of SP for deleted Interface Design] + [Σ of SP for deleted Technical Environment] + [Σ of SP for deleted Architecture]
Applikation – Größe
Die Gesamtgröße einer Applikation nach dem Weiterentwicklungsprojekt ist dann:
ASPA = ASPB + (ADD + CHGA) - (CHGB + DEL)
ASPA = Applikation Snap Points (SP) nach dem Weiterentwicklungsprojekt
ASPB = Applikation Snap Points (SP) vor dem Weiterentwicklungsprojekt
ADD = Snap Points (SP) der durch das Weiterentwicklungsprojekt hinzugefügten NFR
CHGA = Snap Points (SP) der durch das Weiterentwicklungsprojekt geänderten NFR nach dem Projekt
CHGB = Snap Points (SP) der durch das Weiterentwicklungsprojekt geänderten NFR vor dem Projekt
DEL = Snap Points (SP) der durch das Weiterentwicklungsprojekt gelöschten NFR
SNAP: Ein komplexeres Beispiel
Das Beispiel ist aus dem SNAP Manual der IFPUG entnommen [1].
Nicht funktionale Anforderung:
Es soll die Compliance mit dem W3C Web Content Accessibility Guidelines (WCAG) 2.0 hergestellt werden. Es sollen Accessibility Options hinzugefügt werden, so dass Personen mit Hör- oder Sehbeeinträchtigungen gut mit dem System arbeiten Können. Das vorgeschlagene Design ist:
- Hinzufügen von PopUp-Icons wenn ein Sound generiert wird (es gibt vier verschiedene Sounds)
- Hinzufügen von Fonts mit mindestens 14 pt auf allen Screens
- Eine spezielle Farbe anstelle von Font Options.
Der SNAP Counting-Prozess ist nun folgender:
- Das Verändern der Fontgröße von 10 pt zu 14 pt und das Ändern der Fontfarbe werden als technische Anforderungen gesehen. Da keine fachlichen Prozesse hinzugefügt oder verändert werden, würden also keine Function-Points vermessen dürfen. Wir nehmen an, dass die Icons keinerlei Verarbeitung brauchen (no animation).
- Das Design umfasst eine SNAP Subkategorie ("User Interfaces")
- SCU ist der Elementarprozess
- Die neuen Icons und der Fontchange betreffen 5 Elementarprozesse (die nicht überlappen)
- In zwei Elementarprozessen wird die Veränderung als einfach; in 2 Prozessen als Mittel und in einem Prozess als komplex betrachtet
- Daraus ergibt sich:
- < 10 GUI Properties added/changed als einfach, 10 - 15 Properties added/changed als Mittel und mehr als 15 Properties added/changed als complex
- Zu jedem Elementarprozess gehört eine definierte Menge von UI-Elementen
- Anmerkung: Vier Icons, die Sound abspielen werden als ein Unique UI-Element betrachtet
- 8 weitere Properties: name, type, resolution, size, orientation, open width, location (x), location (y)
- Fonts sind in den folgenden Unique UI-Elementen betroffen: menus, icons, up to 11 types of controls, tabs
- Ergebnis:
Elementarprozess (EP) 1 – 5 Unique UI-Elemente betroffen.
EP 2 – 10 Unique UI-Elemente betroffen.
EP 3 – 5 Unique UI-Elemente betroffen.
EP 4 – 13 Unique UI-Elemente betroffen.
EP 5 – 7 Unique UI-Elemente betroffen.
Daraus ergeben sich die gesamten Snap Points (SP) für das Projekt als
Σ SP für alle SCU der Subkategorie = 10+20+15+39+28 = 112 SP [1]
Es ist ebenfalls ein Beispiel für einen Batch-Prozess vorhanden, der mit der FPA gar nicht bewertet werden könnte, da keinerlei Daten des Batches an die Benutzer übermittelt werden, also keine Daten die Anwendungsgrenzen verlassen [1].
SNAP: Vorteile des neuen Standards
Der methodische Kniff – die Stärke von SNAP – liegt nach Meinung des Autors in der Vorbereitung für ein Assessment. Oft steht man vor der Schwierigkeit, technisch orientierte Prozesse zu vermessen und/oder mit technisch orientierten Interviewpartnern zu reden. Dann ist es manchmal schwierig, die Benutzersicht zu extrahieren. Hier wird der SNAP-Standard eine große Hilfe sein. Mit der Bildung der Partitions bewegt sich das Analysefeld in die technische Welt, die auch von der Entwicklung getragen wird. Komplexitätsunterschiede, die in der strengen fachlichen Benutzersicht nicht sichtbar sind, werden so sichtbar. Die Entwicklung wird gleichberechtigt. Es steht wie für die fachlich funktionale Größe ein Maß für die nichtfunktionale Größe zur Verfügung.
Die zweite wesentliche Stärke ist die viele zu viele Beziehung der nichtfunktionalen Anforderungen zu den gefundenen Snap Counting Units. Auch hier blendet die strenge fachliche Sicht genau diese Tatsache aus. Der fachliche Benutzerprozess kann mehr oder weniger Snap Counting Units umfassen, er hat trotzdem immer die gleiche Größe. Deswegen mussten die FP-Analytiker Gruppierungen finden, um Aufwandsunterschiede zu erklären. Mit der Tatsache, dass ein nichtfunktionales Requirement in mehreren Snap Counting Units auftaucht, und mit der Tatsache, dass eine SNAP Counting Unit auch mehrer NFR umsetzen kann, steigert sich die Komplexität und damit die Korrelation zum Aufwand.
Eine weitere Stärke liegt in den Kategorien des Standards. Diese haben eine Überdeckung zu manchen klassischen Metriken. Anders als der Function-Point entsprechen manche Kategorien messbaren, physikalische Dingen. Damit fällt der Brückenschlag zu Metriken des IT-Betriebes leichter. Dies sieht man deutlich an dem Beispiel aus dem SNAP Manual: Die Unterkategorie Data Entry Validation hat eine große Nähe zu der klassischen Komplexitätsmetrik:
"The number of conditional validations (If-Else combo/"While" loop/"For" loop or any other validation blocks) in the longest chain of validation"[1].
So ist die zyklomatische Komplexität nach McCabe-Metrik [2] ganz ähnlich definiert als: Das Komplexitätsmaß kann durch die Anzahl der Knoten und Kanten im Kontrollflussgraph berechnet werden. In diesem Fall ist die McCabe-Zahl definiert als
M = e - n + 2p
(wobei e = Anzahl Kanten im Graphen, n = Anzahl Knoten im Graphen und P = Anzahl der Knoten ohne ausgehende Kanten im Graphen (Sprung aus dem Programm heraus)).
Dies ist nur ein Beispiel und soll nicht bedeuten, dass die zyklomatische Komplexität nach McCabe favorisiert wird. Dem Autor sind die Diskussionen um diese Metrik bekannt.
Aber es gibt auch andere, abstraktere Kategorien, bei denen sich ein Bezug zu verschiedenen Metriken herstellen ließe:
Kategorie Data Interface Design – Subkategorie Multiple Input Methods: Die Subkategorie beschreibt die Fähigkeit der Applikation über verschiedene Input-Methoden Daten zu empfangen. Nahe liegen gemäß der Kategorie Metriken zu dem Thema Interface. Aber in diesem Bereich gibt es mehrere mögliche Kandidaten:
- Fan-In, Fan-Out
- Kopplungsmetriken
- Interfacekomplexität
Eine weitere Erläuterung würde den Rahmen des Artikels sprengen. Prinzipielle Schwierigkeiten sind beispielsweise die Fragen,
- die richtige Metrik für die jeweilige Applikation zu finden (prozedural versus objektorientiert entwickelt),
- die richtige Metrik für den gewünschten Vergleich zu finden (Inhouse oder externer Vergleich), denn für die genannten Metriken gibt es durchaus unterschiedliche Definitionen,
- die Metrik zu finden, für die im jeweiligen Hause Messdaten vorhanden sind.
Nachteile des Standards
Die Auswahl der Kategorien ist nach Meinung des Autors nicht so umfassend wie sie sein könnte. Weiterhin sollte sich die Auswahl der Subkategorien auch stärker an bekannten Metriken orientieren. Auf diese Weise ließe sich leichter eine Korrelation mit den Metriken der Softwaremessung finden.
Das SNAP Assessment ist ebenso wie die FPA ein manueller Prozess. Somit spielen die analytischen Fähigkeiten und gemäß dem Standard auch die technischen Fähigkeiten des Analytikers eine Rolle. Dieser Punkt wird in der Praxis sehr stark diskutiert. Die Literatur berichtet von Unterschieden um 5-10 Prozent [3, 4].
Nach Erfahrungen des Autors spielt eine wesentliche Rolle, welche Ausbildung und welchen Review-Prozess der Analytiker "durchgangen" ist. Die Erfahrung hat gezeigt, dass selbst von ihrer Denk- und Arbeitsweise unterschiedliche Analytiker zu Ergebnissen kamen, die in dem berichteten Korridor von 5 Prozent Abweichung lagen. Gemeinsam war eine tiefe Beschäftigung mit dem abstrakteren IFPUG-Material oder abstrakteren Fragestellungen beim Vergleich von Analysen, eine Anwendung von gewissen Analysemustern und viele diskussionsfreudige, vom Einnehmen anderer Standpunkte geprägte Reviewkultur.
SNAP und die Umsetzung in der Industrie
Methodisch sieht der Autor zwei Dinge, die sich mit dem SNAP-Standard einstellen könnten:
Der SNAP-Standard könnte der angesprochenen Ungleichheit der Analysen gegensteuern. Da es ein Betrachtungsinstrument zu den technischen Gegebenheiten gibt, fällt die Abgrenzung des fachlichen Prozesse vielleicht leichter. Es könnte sich eine stärkere Standardisierung in Form von Analysemustern in den Betrieben entwickeln. Hier sind die weiteren Entwicklungen und die Analysen von SNAP-Daten abzuwarten.
In den Ländern, in denen die FPA stärker verbreitet ist, sind mehrere Unternehmen dabei, SNAP-Benchmarkdaten aufzubauen. So wurde der Betatest des SNAP-Standards auf einer Basis von 48 Projekten, die von verschiedensten, namhaften Firmen beigesteuert worden sind, durchgeführt. Die IFPUG berichtet eine signifikante statistische Korrelation zwischen dem Aufwand und SNAP-Größe [5].
In den Vereinigten Staaten ist beispielsweise die David Consulting Group aktiv an dem Aufbau von SNAP Datenbanken beteiligt [6]. Die IFPUG kooperiert mit der ISBSG [7] beim Aufbau einer SNAP-Benchmarkdatenbank.
Ausblick
Der Function-Point-Standard und auch alle davon abgeleiteten Weiterentwicklungen bzw. Anpassungen arbeiten mit einer von Experten vorgenommenen Prozessanalyse. Sie erfolgt in einem Interview bei dem mehrere Personen beteiligt sind: der FP-Experte, Projektleiter, Fachabteilungsexperten, Entwickler, Systemanalytiker, dies ist in der Praxis von Unternehmen zu Unternehmen unterschiedlich. Der SNAP-Standard setzt auf dieses bewährte Verfahren.
In der Industrie ist der Zeitaufwand für die FPA eines der hauptsächlichen Gegenargumente.
Dieses wird in Anwendertreffen verschiedener Organisationen und Vereinen wie der defpag.org (Deutsprachige Function-Point Anwendergruppe e.V.) oft berichtet. Aktuell sind mehrere Hersteller im Markt, die automatisierte FP-Analysen anbieten. Diese sind nach Wissen des Autors nicht von der IFPUG zertifiziert. Maschinelle Analysen bringen zwangsläufig ein anderes Ergebnis, da der klassische User View der FPA nicht maschinell extrahiert werden kann.
"To do the measurement in a correct way, the software should have enough intelligence to make this judgment. That is, this software has the skill to read the program and interpret the user´s requirements. However, there is no software with this artificial intelligence."[8]
Nach Meinung des Autors ist die Diskussion und die zu beobachtende Wellenbewegung in den Unternehmen bezüglich der unternommenen Aktivitäten für die Einführung der Function-Point-Analyse ein grundsätzliches Thema. In wirtschaftlich schwierigen Zeiten suchen Unternehmen nach Möglichkeiten, den Aufwand für ihre Kennzahlbeschaffung zu reduzieren. Die größte Chance des SNAP-Standards besteht vielleicht darin, das fehlende Element zu liefern, um Zahlen aus automatischen Messungen und Zahlen aus FP-Analysen und SNAP-Assessments gemeinsam statistisch zu untersuchen.
Es ist zu wünschen, dass neben dem verständlichen Streben von Beratungsunternehmen, mit den Benchmarkdaten Geld zu verdienen und dem verständlichen Schutz von Unternehmensdaten bei den Anwendern, ein solches Bemühen stattfinden wird. Unabhängige Organisationen wie die ISBSG, die ebenfalls Benchmarkdatenbanken pflegen, die DASMA e.V. wie auch die defpag.org sind ein Forum für einen solchen Prozess.
Die defpag.org ist ein "junger" Verein. Auch hat er nicht die Größe und Infrastruktur der ISBSG oder der DASMA e.V. Im deutschen Sprachraum bietet die defpag.org aber ein Forum, um einen solchen Erfahrungsaustausch zu führen. Themen mit praktischem Nutzen sind das Kerninteresse der defpag.org. Es wäre schön, wenn der Erfahrungsaustausch intensiviert werden könnte. Öffentlich verfügbare Benchmarkdaten sind ein Gewinn. Der Vorstand der defpag.org freut sich über Kontaktanfragen.
- Software Non-functional Assessment Process (SNAP) Assessment Practices Manual
- Wikipedia: McCabe-Metrik
- Aufwandschätzungen in der Software- und Systementwicklung; Hummel, Oliver; Spektrum Akademischer Verlag, Heidelberg 2011
- B. Poensgen: Function-Point-Analyse; dpunkt.verlag, 2012
- Snap in the Box; Präsentation der IFPUG
- David Consulting Group
- International Software Benchmarking Group
- Ten Fundamental Questions about Function Point Analysis; Zeitschrift Metrik Views, IFPUG, August 2015 S. 4-7