Thought Leadership
Die Function Point-Analyse ist als Werkzeug in der Aufwandsschätzung von Software-Entwicklungsprojekten nicht mehr wegzudenken. Oft wird dabei die These vertreten, man müsste einfach nur die Function Points zählen und diese dann mit einem Eurowert X multiplizieren und – voilà! –man weiß, wie teuer das Projekt wird.
Immer wieder bekommt man die Frage gestellt, was so ein Function Point eigentlich wert ist und ob wir nicht ‚mal eben schnell‘ sagen könnten, wie viel Euro ein Function Point zum Beispiel in der Java-Entwicklung kostet. Aber was ist daran so schwierig und was ist von solchen Preislisten zu halten?
Am Anfang war der Function Point
Beschäftigt man sich in der Softwareentwicklung mit dem Thema Aufwandsschätzung und Kostenkalkulation, so landet man fast unweigerlich bei der Function Point-Analyse. Die Function Point-Analyse nach ISO 20926 misst die funktionale Größe eines Softwareentwicklungsprojektes und nicht, wie manchmal angenommen, den Aufwand. Auch wenn die Function Point-Analyse selber damit allein kein Werkzeug zur Aufwandsschätzung ist, so können auf der Basis von Function Points doch mit dem nötigen Fachwissen Aufwand, Kosten und Laufzeiten für ein Projekt ermittelt werden.
„Realistische Preise lassen sich nur aufeinem Weg erzielen: Das Sammeln eigenerErfahrungsdaten sowie die EtablierungDaniel Hoffmann, Geschäftsführer aestimat GmbH
Schnell wird jedem klar: Function Points korrespondieren mit Kosten. Doch woher erfährtman, was ein Function Point kostet, nachdem man mit mehr oder weniger viel Mühe die Function Points ermittelt hat?
Der sicherste Weg führt über das Nachvermessen eigener abgeschlossener Projekte und den Aufbau einer Erfahrungsdatenbank. Diese liefert Kennzahlen wie Kosten, Aufwand und Laufzeit je Function Point, die die eigenen Leistungen widerspiegeln und auf die eigenen Applikationen und Projekte zugeschnitten sind. Doch was, wenn dafür die Menge der zur Verfügung stehenden Projekte nicht ausreicht oder, schlimmer noch, keine Zeit zur Verfügung steht?
Eine nominale Preisliste
Nehmen wir an, Sie hätten ein Projekt von 400 FP Größe und würden mit einem durchschnittlichen Stundensatz von 80 Euro kalkulieren. Haben Sie keine eigenen Erfahrungswerte zur Hand, so können Sie die Stückkosten zum Beispiel mit einem Software-Schätztool ermitteln. Dabei erhalten Sie abhängig von der eingesetzten Programmiersprache etwa die folgenden Werte für die Stückkosten (Stand 2000, hier beispielhaft eingesetztes Software-Schätztool: Constructive Cost Model der University of Southern California in der Kalibrierung von 2000, USC COCOMO II.2000).
| Programmiersprache | Stückkosten |
| Access | 1.782 €/FP |
| C | 6.775 €/FP |
| C++ | 2.676 €/FP |
| Cobol (ANSI 85) | 4.655 €/FP |
| Java | 2.569 €/FP |
| Powerbuilder | 688 €/FP |
| Visual Basic 5.0 | 1.324 €/FP |
| Visual C++ | 1.577 €/FP |
Diese nominale Preisliste zeigt, dass schon allein die Wahl der Entwicklungsumgebung sich signifikant auf die Entwicklungskosten auswirkt.
Handelt es sich bei dem betrachteten Projekt um eine Java-Entwicklung, so kann jetzt sehr leicht ein erster Preis kalkuliert werden:
400 FP x 2.569 €/FP = 1.027.600 €
Geschätzte Laufzeit: 15 Monate
Aber: Werden diese Werte direkt zur Aufwandsschätzung herangezogen, so bleiben sämtliche Besonderheiten des Projektes unberücksichtigt, die sich positiv oder negativ auf den Aufwand auswirken können. Außerdem stellt sich die Frage, welche Leistungen durch den Preis berücksichtigt sind und was eventuell zusätzlich kalkuliert werden muss.
Was beeinflusst die Kosten?
Tatsächlich beeinflussen viele verschiedene Faktoren in nicht unerheblichem Maße die Kosten eines Projektes. Einige davon wollen wir uns exemplarisch ansehen. Keine Software gleicht der anderen – weder hinsichtlich der Menge noch der Komplexität der gebotenen Funktionalitäten. Entsprechend ist zu erwarten, dass sich die Komplexität wesentlich auf den zu erwartenden Aufwand auswirkt. Der Function Point Wert repräsentiert die Menge der Funktionalitäten und damit die fachliche Komplexität. Darüber hinaus wirkt sich aber auch die technische Komplexität des Systems auf den Aufwand aus.
So gibt es zum Beispiel Unterschiede in der Anforderung an die Ausfallsicherheit der Software. Kann ein Systemausfall zu hohen finanziellen Verlusten führen, so steigert dieser Umstand den Entwicklungsaufwand um 10%. Ist bei einem Systemausfall eher mit niedrigen, wiederherstellbaren Verlusten zu rechnen, kann dies auf der anderen Seite den Aufwand um 8% senken. Einfache Managementinformationssysteme verfügen häufig über eine sehr niedrige Komplexität sowohl in der Verarbeitung, bei Datenbank Operationen als auch auf der Benutzeroberfläche, was den zu erwartenden Entwicklungsaufwand um 26% senkt.
Gehen wir davon aus, dass es sich bei dem von uns zu entwickelnden System um ein einfaches Managementinformationssystem handelt und die Verluste bei einem eventuellen Systemausfall niedrig sind, so wird dies zu einer Einsparung von 34% oder 349.400 Euro gegenüber den nominalen Kosten führen. Die Dokumentation verschlingt über den Produktlebenszyklus hinweg einen nicht unwesentlichen Teil des Aufwandes, weshalb diese gerne (auch im Nachhinein) radikal reduziert wird, um Aufwand und Laufzeit zu minimieren.
Die Einsparpotentiale liegen in der Regel bei 10 bis 20%, wobei die daraus entstehenden Risiken und Folgekosten deutlich höher liegen. Trotzdem wird an dieser Stelle gerne gespart, reduziert dies doch die direkten Projektkosten – wenn auch zu Lasten folgender Projekte oder des Betriebs.
Die personellen Faktoren wirken sich sehr stark auf die Kosten für ein Projekt aus. Nominale Stückkosten gehen davon aus, dass das Projektteam über durchschnittliche fachliche und programmiertechnische Fähigkeiten verfügt. Sind die Fähigkeiten des Projektteams in der Business Analyse und der Programmierung überdurchschnittlich, kann dies den Aufwand durchaus um 25% senken. Auch die Erfahrung des Projektteams spielt eine wesentliche Rolle. Die oben genannten nominalen Kosten gehen von einer durchschnittlichen Erfahrung des Projektteams von einem Jahr aus. Liegt etwa die durchschnittliche Erfahrung des Projektteams auf der Entwicklungsplattform und mit den gewählten Sprachen und Werkzeugen bei drei Jahren, so kann alleine dies den Aufwand um 18% senken.
Werden in unserem Projekt zum Beispiel vorrangig Seniorberater und erfahrene Entwickler zu einem 25% höheren Tagessatz von 100 Euro eingesetzt, kann man erwarten, dass diese auch über einen höheren Skill verfügen sowie eine mehrjährige Erfahrung nachweisen können. Entsprechend ist zu erwarten, dass das Projekt wesentlich zügiger durchgeführt wird, was insgesamt trotz des höheren Tagessatzes zu einer Einsparung von fast 30% oder über 295.000 Euro führt.
Der Einfluss des Zeitdrucks
Zu den kritischstenAufgaben in der Projektplanung gehört die Festlegung der idealen Projektlaufzeit. Wird die Laufzeit zu kurz gewählt, steigert dies den Aufwand überproportional. Eine zu lang gewählte Laufzeit bindet unnötig lange wichtige Ressourcen. Unserem Projekt liegt eine geschätzte Laufzeit von 15 Monaten zugrunde.Was nun aber, wenn das Projekt schneller fertig gestellt werden soll, zum Beispiel in 12 Monaten?
Tatsächlich wird der Aufwand überproportional zur Verkürzung der Laufzeit ansteigen, da zum Beispiel durch die Vergrößerung des Projektteams der Kommunikationsaufwand ansteigt. Eine Verkürzung der Projektlaufzeit um nur 15% wird erfahrungsgemäß den Aufwand schon um etwa 14% steigern. Unser Projekt wird in diesem Fall 145.000 € mehr kosten. Verkürzt man das Projekt um 25%, wird der Aufwand sogar um 43% steigen. Der ehrgeizige Zeitplan verursacht also Mehrkosten von über 440.000 Euro.
Übrigens lässt sich die Laufzeit eines Projektes nicht beliebig komprimieren. Deshalb ist es wichtig, den kritischen Punkt bestimmen zu können, ab dem das Projektergebnis hinsichtlich Kosten, Termin und Qualität nichtmehr garantiert werden kann.
Was beinhalten die Kosten?
Jedes Projekt besteht aus verschiedenen Phasen, Aktivitäten und Rollen. Eine konkrete Aufwandsschätzung muss detaillierte Aussagen liefern, welche Aufgaben durch die genannten Kosten abgedeckt sind und welche nicht. Liegt das Fachkonzept zum Beispiel bereits vor, dürfen die Kosten nicht nochmal Aufwände zu seiner Erstellung beinhalten.
Gesamtaufwand (Vollkosten)
Die nominalen Kosten und Laufzeiten in unserem Beispiel berücksichtigen keinen Aufwand für Anforderungsanalyse und Grobplanung, sehr wohl aber zur Fachkonzeption und Feinplanung. Wollen wir zum Beispiel die Gesamtkosten und -laufzeit für unser Projekt inklusive der dazugehörenden Leistungen des Anforderungsmanagements ermitteln, so können wir erfahrungsgemäß 7% auf den Aufwand und 19% auf die Laufzeit aufschlagen:
Gesamtkosten = 1.099.500 €
Gesamtlaufzeit = 18 Monate
Häufig ist es so, dass Unternehmen die Erstellung des Fachkonzeptes selber übernehmen, die Realisierung aber extern – eventuell sogar im Offshoring – vergeben. Wie viel der kalkulierten Leistung wird dann aber selbst erbracht und wie viel eingekauft? Ist das Fachkonzept bereits erstellt und soll lediglich die Realisierung von der Erstellung des technischen Designs bis zur Abnahme bei einem Dienstleister beauftragt werden, so können wir von den nominalen Kosten 17% und von der nominalen Laufzeit 26% abziehen:
Realisierungskosten = 852.900 €
Realisierungszeitraum= 11 Monate
Wie finde ich den richtigen Preis?
Nachdem wir unsere Aufwandsschätzung abgeschlossen haben, halten wir einen ersten Anhaltspunkt in den Händen, wie hoch die Kosten für das Projekt ausfallen werden. Doch wie belastbar ist ein solcher Wert und wie kann er bei Vertragsverhandlungen eingesetzt und bewertet werden?
Die Aufwandsschätzung darf zunächst einmal nicht mit einer Preisverhandlung verwechselt werden, obwohl dies heute gängige Praxis in vielen Unternehmen ist. Jedem sollte klar sein, dass es den unverrückbaren Zielwert nicht gibt: Das berühmte Dreieck des Qualitätsmanagements lehrt uns, dass Kosten, Termine und Ergebnisqualität sich gegenseitig beeinflussen. Da sich zum Beispiel Anforderungen über den Projektlebenszyklus naturgemäß verändern und diese zu Anfang in der Regel noch nicht vollständig vorliegen, ist damit automatisch auch eine Abweichung des Zielwertes zu erwarten. Solche Abweichungen lassen sich glücklicherweise statistisch konkret eingrenzen und liegt erfahrungsgemäß etwa zum Zeitpunkt des Fachkonzeptes bei +/- 20-25%.
Die Kenntnis der möglichen Preisspanne ist wichtig, um auf der einen Seite die eigene Planung nicht zu überreizen und auf der anderen Seite konkrete Angebote bewerten zu können. Ein zu hoher Preis ist wirtschaftlich nicht akzeptabel, während ein zu niedriger Preis unkalkulierbare Risiken für die Projektziele mit sich bringt.
Benchmarks sind vergleichbar mit dem Mietpreisspiegel oder der berühmten Schwacke-Liste zur Bewertung von Gebrauchtfahrzeugen: Sie liefern eine wertvolle Positionierung gegenüber vergleichbarer Projekte, können eine detaillierte Einzelbewertung aber nie ersetzen. Die Verwendung von Benchmarkdaten zur Aufwandsschätzung ist nicht zielführend, da die Rahmenbedingungen des einzelnen Projektes die Menge der Referenzprojekte stark einschränken würden. Die entsprechende Stichprobe ist dann in der Regel nicht mehr repräsentativ für die Grundgesamtheit des Marktes.
Realistische Preise
Realistische Preise lassen sich nur auf einem Weg erzielen: Das Sammeln eigener Erfahrungsdaten sowie die Etablierung standardisierter Prozesse zur Aufwandsschätzung und Kostenkalkulation.
Auch muss die Function Point basierte Leistungsverrechnung mit Kunden und Lieferanten abgestimmt werden. Auf diese Weise werden vergleichbare und belastbare Aufwandsschätzungen ermöglicht. Gleichzeitig wird mehr Transparenz über den eigentlichen Liefergegenstand geschaffen und die Steuerbarkeit der Aufwandstreiber im eigenen Unternehmen deutlich gesteigert.
Wenn eine standardisierte Messgröße wie die Function Point-Analyse als Standardwerkzeug zwischen Kunden und Dienstleistern vereinbart wird und dann gemeinsam konsequent Erfahrungsdaten gesammelt werden, können diese auf Dauer als Grundlage für die Leistungsverrechnung verwendet werden.
Dies liefert dann tatsächlich eine realistische Preisliste – vereinbart zwischen Kunden und Dienstleister – an der über die Zeit auch effektive Performancesteigerungen abgelesen werden können.
Unsere langjährige Erfahrung bei der Einführung solcher Prozesse zeigen, dass es lohnenswerter ist, eigenes Know-how zur Aufwandsschätzung im Unternehmen aufzubauen und eigene Erfahrungsdaten zu sammeln, anstatt diese Aufgabe extern zu vergeben.
In der Regel amortisieren sich die Investitionen für eine effiziente Einführung schon nach kurzer Zeit, setzt dies doch das Risiko für fehlgeplante und damit gescheiterte Projekte herab und stärkt die Verhandlungsposition gegenüber Kunden und Dienstleistern.
DANIEL HOFFMANN
Diesen Artikel finden Sie auch in der Ausgabe September 2010 des it management.
