Function-Point-Analyse – die Methode und ihre Anwendung

Teil 2:
Kennzahlen, Effizienznachweis, Aufwandsschätzung
Die Function-Point-Analyse (FPA) liefert eine objektive Messgröße für den Leistungsumfang einer Software. Im zweiten Teil dieses Artikels beschreiben Dorian Gloski und Eva-Maria Schielein typische Anwendungen von Function Points: Die Ermittlung von Leistungskennzahlen, Benchmarking, Aufwandsschätzung mit COCOMO und Angebotsvergleiche. Vor dem Hintergrund dieser Einsatzgebiete gehen sie auf häufige Kritikpunkte ein und geben Empfehlungen für die praktische Arbeit.

Function-Point-Analyse – die Methode und ihre Anwendung

Teil 2:
Kennzahlen, Effizienznachweis, Aufwandsschätzung
Die Function-Point-Analyse (FPA) liefert eine objektive Messgröße für den Leistungsumfang einer Software. Im zweiten Teil dieses Artikels beschreiben Dorian Gloski und Eva-Maria Schielein typische Anwendungen von Function Points: Die Ermittlung von Leistungskennzahlen, Benchmarking, Aufwandsschätzung mit COCOMO und Angebotsvergleiche. Vor dem Hintergrund dieser Einsatzgebiete gehen sie auf häufige Kritikpunkte ein und geben Empfehlungen für die praktische Arbeit.

Im ersten Teil dieses Artikels stellten wir die Grundprinzipien der FPA vor und erklärten anhand eines einfachen Beispiels, wie man mit ihrer Hilfe die Größe einer Software misst. Zweck einer solchen Messung ist es, eine objektive und reproduzierbare Referenzgröße für den Leistungsumfang einer Software zu erstellen, die von technischen Faktoren (Programmiersprache, Laufzeitumgebung usw.) unabhängig ist.

Software-Größe als Maßstab für aussagekräftige Kennzahlen

So wie Sie z.B. bei der Wohnungssuche verschiedene Objekte nur vergleichen können, wenn Sie den Mietpreis pro Quadratmeter betrachten, so können Sie die Leistungsfähigkeit von Entwicklungsabteilungen, Angebote verschiedener Dienstleister oder unterschiedliche Lösungsansätze für ein Software-Projekt erst dann standardisiert miteinander vergleichen, wenn Sie die entsprechenden Projektdaten auf die in Function Points gemessene Software-Größe beziehen.

Angebote für Software-Entwicklungen miteinander vergleichen

Wenn Sie für die Entwicklung einer neuen Software, z.B. für die Programmierung eines unternehmensweiten Data Warehouse, den günstigsten Dienstleister suchen, schicken Sie Ihre Anforderungen an mehrere Software-Entwicklungsfirmen. Die Anbieter erstellen dann Angebote, in denen sie im Wesentlichen jeweils einen Preis und einen Fertigstellungstermin nennen.

Sehr wahrscheinlich werden Sie sich als Auftraggeber für das Angebot mit dem niedrigsten Preis entscheiden, solange der Fertigstellungstermin akzeptabel ist und Sie den Anbieter für seriös und kompetent halten.

Leider stellt es sich häufig heraus, dass die Preise der Anbieter sich deshalb unterscheiden, weil sie den Auftrag unterschiedlich interpretierten. Der billigste Anbieter wird zwar nominell die geforderten Funktionen liefern, diese werden jedoch wahrscheinlich nicht Ihre Vorstellungen von einer funktionierenden Software erfüllen, sodass es beständig Auseinandersetzungen über den zu realisierenden Leistungsumfang geben wird.

Wenn Sie hingegen von den Anbietern fordern, dass sie auf Basis der Anforderungen die Function Points ermitteln und diese in ihren Angeboten mit angeben, dann sind Sie in der Lage, nicht nur den billigsten, sondern auch den tatsächlich günstigsten Anbieter herauszufinden.

Mit Angabe der Function Points treffen die Anbieter nämlich eine klare Aussage über den Leistungsumfang, den sie anbieten. Gibt es in diesem Punkt signifikante Unterschiede zwischen den Angeboten, so haben die Anbieter die fachlichen Anforderungen offenbar verschieden interpretiert und Sie als Auftraggeber müssen diese genauer spezifizieren. Ohne Function Points würden sich die Angebote auf den ersten Blick nur im Preis unterscheiden. Wenn Sie als Auftraggeber den billigsten Anbieter auswählen, ist dieser eventuell gar nicht in der Lage, die Anforderungen im geforderten Rahmen von Zeit und Qualität umzusetzen.

Beispiel: Angebotsvergleich für verschiedene Projekte

Bild 1: Angebote verschiedener Dienstleister.

In Bild 1 sind für drei Projekte (Adressverwaltung, ERP-HR und Billing-Anwendung) die angebotenen Preise von vier Dienstleistern je Liefereinheit, d.h. Euro pro Function Point, angegeben. Die Daten entsprechen in ihrer Höhe und Varianz unseren Erfahrungen bei Ausschreibungen für Software-Entwicklungen. Es ist durchaus üblich, dass für verschiedene Projekte jeweils andere Anbieter das beste Preis-Leistungs-Verhältnis bieten, so ist in Bild 1 für die Adressverwaltung Anbieter B, für das ERP-HR-Projekt Anbieter C und für die Billing-Anwendung Anbieter A der preislich günstigste.

Selbstverständlich sollten in eine Entscheidung auch noch andere Aspekte, wie z.B. die Zusage verbindlicher Lieferzeiten oder die Gewährleistung bestimmter Qualitätsstandards, mit einfließen.

Objektive Leistungsmessung für Verbesserungen

Wenn ein Unternehmen eine eigene Abteilung für interne Software-Entwicklungen hat, so gibt es beständig die Frage, ob sie tatsächlich kostengünstiger entwickelt als ein externer Dienstleister. Zudem gilt es, ihre Effizienz zu beurteilen und nach Möglichkeit kontinuierlich zu verbessern.

Bewertungen und Kommentare

(nur angemeldete Benutzer)

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
Gesamt
Bewertungen 2
Kommentare 1

Fortsetzungen des Fachartikels

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 Benchmarking für Software-Systeme durchzuführen. Function Points, so Dorian Gloski und Eva-Maria Schielein, sind bei …

Alle Kommentare

Hans-Heinz
Maier
Zu Function Point und Cocomo ist folgendes zu sagen: - Eine Aufwandsschätzung benötigt man vor Beginn des Projektes, das läßt sich mit beiden Methoden nicht machen, da zu diesem Zeitpunkt weder FunktionPoints noch lines-of-code bekannt sind. Zudem besitzen die Firmen keinerlei statistische Zahlen über abgelaufene Projekte, um Vergleiche anstellen zu können. Sie wollen die Zahlen auch nicht kennen und verhindern ihre Ermittlung, sie wollen es einfach nicht wissen, verständlich. - In der DIN 69901 ist beschrieben, wie man eine Aufwandsschätzung macht: Man erstelle vor Projektbeginn so gut wie möglich einen Projektstrukturplan und lasse die Arbeitspakete von Experten schätzen, besser geht es nicht. - Der Vorteil von Arbeitspaketen ist, dass diese ins Projekt integriert sind, also bei der Aufwandserfassung, beim Netzplan, bei dem Auftrag an die Programmierer. Bei FunctionPoint und Cocomo ist das nicht der Fall, das sind diesbezüglich reine Fremdkörper im Projekt. - Bei ERP-Einführungen ist es geradezu hoffnungslos, mit diesen beiden Methoden zu arbeiten. Das sind aber die meisten Projekte, die jetzt noch gemacht werden, es programmiert ja heute kaum noch jemand, das ist vorbei. -Es ist bis heute nicht möglich zu sagen, was denn eine "Funktion" ist oder sein soll. Nicht ganz so schlimm ist es mit lines of code, aber auch da hat man Probleme, die selbst am Projektende zu zählen, man möge das nur einmal probieren: Es ist schon unklar, ob eine Zeile Code auch 1 Befehlt ist, das kann man nur genau sagen, wenn man ein Tool einsetzt, das die Befehle nach einem einheitlichen Schema zählt, sonst weiß man es nicht so genau; dann kommt das Problem, wann man zählt und was: Den Programmzustand/Umfang von heute, von gestern oder von morgen, welche Version bitte, mit oder ohne eingebundene Teile, usw., das wird uferlos, wenn man es genau nimmt.Der Umfang in lines of code ist praktisch jeden Tag anders. - Das Hauptproblem beider Methoden ist, dass so getan wird, als müßte man kein know how besitzen, um den Aufwand zu schätzen. Es ist aber so, wenn man keine 10 Jahre Erfahrung in der Projektarbeit in einer bestimmten IT-Umgebung hat, braucht man eine Schätzung erst gar nicht beginnen. - Interessant ist auch folgendes Phänomen: Eigentlich bekommt man keinen Auftrag zur Schätzung, sondern es heißt: "Wir machen das Projekt XY, das kostet etwa 1,5 Mill. €, prüfen Sie doch nach, ob wir damit auskommen". D. h., eine gutes IT-Management weiß sowieso schon schon in etwa, was das Projekt kostet, also das Budget, sie wollen es nur ein bisschen genauer haben und sich etwas absichern durch eine detaillierte Schätzung. So sehe ich das. Maier
Alle anzeigen