Function-Point-Analyse – die Methode und ihre Anwendung

Teil 1:
Die Größe einer Software ermitteln
Erst objektive Messgrößen wie Function-Point-Werte ermöglichen es, vergleichbare Aufwandsschätzungen und aussagekräftiges BenchmarkingBenchmarking"Benchmark" ist ursprünglich ein Begriff aus dem Vermessungswesen und bezeichnet die Höhenmarke im Gelände. Übertragen bedeutet es die Orientierungsgröße (Kennzahl) bzw. die Gesamtheit der Vergleichsgrößen für eine relative Bewertung eines Produkts, einer Dienstleistung oder einer Organisationseinheit im wettbewerblichen Vergleich. für Software-Systeme durchzuführen. Function Points, so Dorian Gloski und Eva-Maria Schielein, sind bei Software-Entwicklungsprojekten ein genauso objektives Maß für den LeistungsumfangLeistungsumfangLeistungsumfang ist die Menge aller Leistungen, die für die Abnahme eines Projekts verpflichtend zu erbringen sind. der erstellten Software wie es bei Bauprojekten die Quadratmeter Bruttogeschoßfläche für die Gebäudegröße sind. Die Function-Point-AnalyseFunction-Point-AnalyseDie Function-Point-Analyse (FPA) ist eine Methode, um die Größe einer Software objektiv und unabhängig von technischen Randbedingungen zu messen. "Größe einer Software" bedeutet in diesem Zusammenhang den Leistungsumfang, d.h. die Menge an Funktionen, die eine Software dem Anwender bietet. ist die weltweit am weitesten verbreitete Methode, um die Größe einer Software unabhängig von technischen Rahmenbedingungen, wie z.B. der verwendeten Programmiersprache, zu messen. Dorian Gloski und Eva-Maria Schielein erklären im ersten Teil ihres Artikels die Prinzipien der Function-Point-Analyse und demonstrieren an einem einfachen Beispiel ihren Ablauf.

 

Function-Point-Analyse – die Methode und ihre Anwendung

Teil 1:
Die Größe einer Software ermitteln
Erst objektive Messgrößen wie Function-Point-Werte ermöglichen es, vergleichbare Aufwandsschätzungen und aussagekräftiges BenchmarkingBenchmarking"Benchmark" ist ursprünglich ein Begriff aus dem Vermessungswesen und bezeichnet die Höhenmarke im Gelände. Übertragen bedeutet es die Orientierungsgröße (Kennzahl) bzw. die Gesamtheit der Vergleichsgrößen für eine relative Bewertung eines Produkts, einer Dienstleistung oder einer Organisationseinheit im wettbewerblichen Vergleich. für Software-Systeme durchzuführen. Function Points, so Dorian Gloski und Eva-Maria Schielein, sind bei Software-Entwicklungsprojekten ein genauso objektives Maß für den LeistungsumfangLeistungsumfangLeistungsumfang ist die Menge aller Leistungen, die für die Abnahme eines Projekts verpflichtend zu erbringen sind. der erstellten Software wie es bei Bauprojekten die Quadratmeter Bruttogeschoßfläche für die Gebäudegröße sind. Die Function-Point-AnalyseFunction-Point-AnalyseDie Function-Point-Analyse (FPA) ist eine Methode, um die Größe einer Software objektiv und unabhängig von technischen Randbedingungen zu messen. "Größe einer Software" bedeutet in diesem Zusammenhang den Leistungsumfang, d.h. die Menge an Funktionen, die eine Software dem Anwender bietet. ist die weltweit am weitesten verbreitete Methode, um die Größe einer Software unabhängig von technischen Rahmenbedingungen, wie z.B. der verwendeten Programmiersprache, zu messen. Dorian Gloski und Eva-Maria Schielein erklären im ersten Teil ihres Artikels die Prinzipien der Function-Point-Analyse und demonstrieren an einem einfachen Beispiel ihren Ablauf.

 

Wir empfehlen zum Thema Kennzahlen
OKR Business Coach Foundation (OCF)

Fit für die OKR-Einführung: Lassen Sie sich in unserem Ein-Tages-Workshop zum OKR Business Coach – Foundation Level (OCF) zertifizieren! Mehr Infos

Wenn ein Malermeister für das Streichen eines kleinen Raums zwei Wochen Arbeitszeit berechnet und der AuftraggeberAuftraggeberDer Auftraggeber eines Projekts ist der wichtigste Projektbeteiligte (Stakeholder). Er erteilt den Auftrag und ist der Vertragspartner, der über den Erfolg des Projekts endgültig entscheidet. 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 LeistungLeistungLeistung im allgemeinen Sprachgebrauch des Projektmanagements ist der den vereinbarten Anforderungen genügende und monetär bewertete Output eines Projektprozesses. 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 AufwandAufwandAufwand (Projektmanagement) ist die Menge aller monetär quantifizierbaren Eingangsgrößen in ein Projekt, in ein Programm, in ein Projektportfolio oder in einen Teil eines Projekts. akzeptiert. Welcher Leistungsumfang tatsächlich erbracht wurde, ist jedoch in der Regel unbekannt. Der Auftraggeber kann nur vermuten, ob der ArbeitsaufwandArbeitsaufwand" Arbeitsaufwand " ist der in Einheiten von Arbeitszeit (Arbeitsstunden, Personentagen usw.) bemessene Personaleinsatz zur Durchführung eines Vorgangs, Arbeitspakets oder Projekts. 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 StoryUser StoryEine User Story ist eine aus Anwendersicht umgangssprachlich und umsetzungsneutral formulierte Anforderung an eine Software. wird mit sog. Story Points geschätztGeschätztAttribut für alle messbaren Größen im Projekt, insbesondere Zeit- und Kostengrößen, das den Wert der Größe als Prognose kennzeichnet. Bei der Projektplanung sind die geschätzten Werte Basis für die Projektkalkulation und die Terminplanung. Aus ihnen entstehen dann die geplanten Werte, die im Basisplan die Vorgabe für die Projektabwicklung bilden.. 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 SchnittstelleSchnittstelleSchnittstellen sind definierte Projektmanagementprozesse zur Übergabe von Informationen und Produkten zwischen Elementen des Projekts., über die Daten zum Drucker geschickt werden und die deshalb bei der Quantifizierung zu berücksichtigen ist.

Gleich kostenlos weiterlesen!

  • Zum Newsletter anmelden und diesen Artikel freischalten
  • Jede Woche neue Inhalte, Tipps und Tools per E-Mail
Gratis Newsletter bestellen & sofort weiterlesen

 

Hiermit melde ich mich zum Newsletter an. Ich habe die Datenschutzrichtlinien gelesen und akzeptiere diese. Ihre Daten nutzen wir ausschließlich zum Newsletter-Versand. Sie können sich jederzeit abmelden, indem Sie auf den Link in der Fußzeile unserer E-Mails klicken. Informationen zu unserem Datenschutz finden Sie hier.
DownloadDownload

Jetzt Feedback geben und mitdiskutieren!

Wir würden uns über Ihre Bewertung und/oder einen Kommentar freuen ‒ nur so können wir Ihnen in Zukunft noch bessere Inhalte liefern.

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung.
0 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 1
Kommentare 0

Fortsetzungen des Fachartikels

Teil 2:
Kennzahlen, Effizienznachweis, Aufwandsschätzung
Die Function-Point-Analyse (FPA) liefert eine objektive Messgröße für den Leistungsumfang einer Software.