Methoden der Aufwandsschätzung im Überblick

In den nachfolgenden Abschnitten werden die wichtigsten Methoden  zur Aufwandschätzung von Projekten beschrieben.

Algorithmische Methoden

Der Projektaufwand wird mit Hilfe einer Formel auf der Basis von bereits abgeschlossenen Projekten oder mathematischen Modellen berechnet. In diesem Zusammenhang ist die Genauigkeit der Berechnung auf die Exaktheit der Einflussfaktoren zurückzuführen. Es wird ein mathematischer Zusammenhang zwischen messbaren Ergebnisgrößen und Einflussfaktoren unterstellt. Algorithmische Ansätze unterteilen sich in parametrische Methoden und Faktoren- bzw. Gewichtungsmethoden:

• Methode der Parametrischen Schätzgleichung: Der Aufwand wird anhand problemspezifischer Gleichungen berechnet: Y=f(X). Hierbei werden zuerst die Einflussfaktoren ermittelt, die eine große Auswirkung auf die Projektkosten und eine hohe Korrelation mit diesen haben. Diese unterteilen sich in abhängige (Y) und unabhängigen Variablen (X). Die abhängigen Variablen sind beispielsweise die benötigte Zeit und die dabei entstehenden Kosten für ein Projekt. Die unabhängigen Variablen sind u.a. die eingesetzte Programmiersprache und die Anzahl der Unterprojekte.
• Faktoren- bzw. Gewichtungsmethode: Bei der Faktoren- bzw. Gewichtungsmethode werden die ermittelten Einflussfaktoren in objektive (z. B. Programmiersprache) und subjektive (z. B. Personalqualifikationen) unterteilt und mit einem bestimmten Gewicht versehen. Die Höhe des Gewichts bestimmt den Einfluss des Faktors. Der Gesamtaufwand ergibt sich aus der Summe der Bewertungen.

Vergleichsmethoden

Diese Methode basiert auf dem direkten Vergleich des Aufwandes des aktuellen Projektes mit dem Aufwand aus bereits abgeschlossenen Projekten. Eine wichtige Voraussetzung ist die Ähnlichkeit der Projekte bezüglich der o.g. Einflussfaktoren (wie Umfang und Qualität). Bei den Vergleichsmethoden unterscheidet man zwischen der Analogie- und der Relationsmethode.

• Analogiemethode: Die Kosten werden nach bestimmten Kriterien mit denen von bereits abgeschlossenen Projekten verglichen. Unter Kriterien ist hier der Leistungsumfang hinsichtlich der Anzahl der Programme oder Anweisungen gemeint. Tatsächlich erfolgt die Bestimmung des Deltas im Aufwand zwischen abgeschlossenem und neuem Projekt. Durch Bewertung des Unterschieds ist die Ermittlung der Projektkosten möglich. Diese Methode ist nur für einander ähnliche Projekte geeignet. Eine Anwendung zur Aufwandsschätzung für Teilprojekte oder Projektphasen ist denkbar.
• Relationsmethode: Die Relationsmethode stellt eine Verbesserung der Analogiemethode dar. Der Vergleich wird mit Hilfe von Indizes durchgeführt. Diese Werte zeigen an, wie die einzelnen Faktoren den Aufwand beeinflussen. Aktuelle Listen mit Faktoren werden von Software-Unternehmensberatungen erarbeitet und sind käuflich zu erwerben. Anhand dieser Listen ist eine Ableitung des individuellen Projektaufwandes möglich.

Multiplikatormethode

Diese Methode ist durch die Zerlegung des zu entwickelnden Systems in Teilsysteme/ Teilprodukte und der entsprechende Zuordnung des Aufwandes gekennzeichnet. Die Zerlegung in Teilprodukte erfolgt solange, bis jedem Teilprodukt ein bereits feststehender Aufwand zugeordnet werden kann. Der Aufwand für ein Teilprodukt wird aus der Analyse von abgeschlossenen Projekten übernommen und mit der geschätzten Anzahl der Einheiten (derartiger Teilprojekte) – die für das neue Projekt notwendig sind – multipliziert.

Prozentsatzmethode

Anhand dieser Methode lässt sich für bereits abgeschlossene Projekte die durchschnittliche prozentuelle Aufwandsverteilung je Projektphase ermitteln. Bild 1 zeigt das Prinzip dieser Methode. Es wird die Kostenaufteilung in den Entwicklungsphasen eines Softwareprojektes dargestellt. Die Abschätzung des Gesamtaufwandes ist entweder nach dem Abschluss der ersten Phase durch die Ableitung des Soll-Aufwandes aus dem Ist-Aufwand oder nach einer detaillierten Schätzung des Teilaufwandes einer Phase mit einer sich anschließenden Hochrechnung möglich.

Produktivitätsmethode

Ausgangspunkt bei dieser Methode ist die Produktivität je Ergebniseinheit, die sich aus der Division der erbrachten Ergebnisse durch den dafür notwendiger Aufwand ergibt. Die Zahlen sind Durchschnittswerte aus den Daten abgeschlossener Entwicklungsvorhaben. Bei gleicher Entwicklungsmethodik und Entwicklerqualifikation wird von einer unveränderten Produktivität ausgegangen. Eine Anpassung ist jedoch bei dem Einsatz von neuen Methoden und Werkzeuge notwendig.

Die zuvor vorgestellten Methoden haben primär Ansätze zur Schätzung des Aufwands – zunächst auf theoretischer Ebene – beschrieben. Für die konkrete Aufwandsschätzung in einem Projekt sind diese Methoden zu praxistauglichen Verfahren weiter zu entwickeln und zu integrieren. In diesem Artikel stellen wir das COCOMO-Verfahren (COnstruktiv COst MOdell) und das Function-Point-Verfahren vor. Beide haben entsprechende Relevanz in Theorie und Praxis.

COCOMO-Verfahren (COnstruktiv COst MOdell)

Das Cocomo-Verfahren wurde 1981 von  Barry W entwickelt. Er  studierte Mathematik an der Harvard Universität und hat später an der California Universität von Los Angeles zum PhD in Mathematik promoviert. COCOMO basiert auf einem algorithmischen Kostenmodell. Durch den Einsatz von mathematischen Funktionen entsteht ein Zusammenhang zwischen Softwaremetriken (Anzahl der Codenzeilen) und Kosten eines Projektes. Firmenspezifische Parameter und Einflussfaktoren werden bei der Berechnung berücksichtigt. Dadurch ist die Abschätzung des Aufwandes (Personenmonate oder Personenjahre), welcher für die Realisierung eines Projektes notwendig ist, möglich. Mit fortschreitender Projektentwicklung erhöht sich die Genauigkeit der Schätzungen und die damit verbundene Schwankungsbreite wird geringer. Das COCOMO-Verfahren hält sich an folgenden Annahmen:

• Delivered Source Instructions (DSI) sind die primären Kostenfaktoren (Cost Drive) für das Modell.
• Spezifikationen werden nicht nach der Anforderungsphase geändert.
• Staff Month (COCOMO Personenmonat) besteht aus 152 Arbeitsstunden
• Projektrahmen umfasst den Start des Produktdesigns bis zum Abschluss der Produktintegration und der Durchführung von Akzeptanztest.
• Unproduktive Zeiten müssen möglichst gering gehalten werden.

Heutzutage ist das von Barry W. Boehm entwickelte Modell als COCOMO I (COCOMO’81) bekannt. Revolutionäre Veränderungen in der Softwareentwicklung in der letzten Jahren führten zur Entstehung von COCOMO II (COCOMO 2000). Schon bei COCOMO’81 wurden unterschiedliche Schwierigkeitsgrade, d.h. einfach (basic), mittel (intermediate)  und detailliert (detailed) bei der Entwicklung berücksichtigt. Ausgangspunkt ist die Projektgröße, welche in der Anzahl der Codezeilen gemessen und in Projektkosten (Personenmonate) umgerechnet wird. Im Vergleich zur früheren Version wurden bei der Entwicklung von COCOMO II folgende Punkte berücksichtigt:

• neue Software-Prozesse
• veränderte Projektgrößen
• Entscheidungsfindung auf der Grundlage unvollständiger Informationen
• Erhöhung der Kostendrucks.

COCOMO II unterteilt sich – je nach Bezug – auf das gesamte Projekt oder auf Teilprojekte zu verschiedenen Zeitpunkten. Dabei werden drei Modelle unterschieden:

• Das „Applikation Composition“-Modell (frühe Prototypenstufe): Hierbei geht es um die erste Grobschätzung, die auf der Methode der Object Points basiert. Dieses Modell ist für stark risikobehafteten Problemlösungen geeignet.
• Das „Early Design“-Modell (frühe Entwurfsphase): Dient der Aufwandsschätzung, basiert auf Funktion Points und wird in frühen Projektphasen eingesetzt.
• Das „Post Architecture“-Modell (nach dem Architekturentwurf): Zum Einsatz kommt eine Vielzahl von Multiplikatoren zur Feinabstimmung der Schätzung.

Function-Point Verfahren

Das Function-Point Verfahren kombiniert die Relationen- und Gewichtungsmethoden. Dieses Verfahren wurde ursprünglich zur Verbesserung der Aufwandschätzung entwickelt. Heutzutage findet das Verfahren jedoch in allen Phasen des Lebenszyklus von Softwareprojekten Anwendung. Das Function-Point-Verfahren, welches auch als Albrecht Metrik bezeichnet wird, wurde 1979 von Alan J. Albrecht (IBM) entwickelt. Die Publikation der so genannten IBM-Kurve (1985), die den Zusammenhang von Aufwand und Function Points von 54 Softwareprojekten darstellte, legte den Grundstein. Im Gegensatz zu den anderen derzeit vorhandenen Verfahren, erfolgte eine Betrachtung des Softwaresystems aus Benutzersicht. Jedoch hatte dieses Verfahren in den ersten Jahren der Anwendung keinen Erfolg. Die Ursachen waren:

• die Unerfahrenheit der Anwender mit der neuen Methode
• die unrealistisch hohe Erwartungen an diese Methode
• Lücken in der Definierung der fachlichen Anforderungen
• fehlende differenzierte Erfahrungsdaten.

Ab etwa Mitte der1990er Jahre änderte sich dieses. Ein anderes Motiv führte zum Einsatz des Function-Points-Verfahrens: Bislang wurde der Leistungsumfang von Softwareprojekten am Umfang des im Projekt erzeugten Quellcodes festgemacht. Entwicklungen der neuen Programmiersprachen der 4. Generation haben das geändert. Dieses führte dazu, dass Function-Point zum Vergleich zwischen verschiedenen Programmiersprachen und Technologien geeignet war. Heutzutage nimmt die Bedeutung dieser Analyse weiter zu. Der Name „Function-Point“ ist als historisch zu betrachten. Er hat nichts mit dem Begriff „funktional“ oder „Funktion“ im Sinne eines Unterprogramms zu tun. In Albrechts Technologien wurde dieser Begriff für die Konstrukte „Eingaben“, „Ausgaben“ und „Datenbestände“ verwendet. Wie bereits erwähnt, wird die Function-Point-Analyse im gesamten Lebenszyklus eines Projektes eingesetzt:

• Anforderungsanalyse
• Aufwandsschätzung
• Auftragsvergabe
• Controlling
• Benchmarking

Auf die Anwendung des Verfahrens bei der Aufwandsschätzung wird noch genauer eingegangen. Das Verfahren ist als sehr übersichtlich und anpassungsfähig bekannt. Für eine Verwendung müssen der Aufwand und die Dauer vorangegangener Projekte bekannt sein. Dieses ermöglicht die Berechnung der Function-Points (FPs) und daraus die Zahl X mit:
X = Aufwand/ FPs.

Aus den FPs lässt sich also der Aufwand ermitteln, d.h.:
Aufwand=X * FPs.

Dieses Verfahren beinhaltet algorithmische und vergleichende Schätzmethoden und wird aus Benutzersicht durchgeführt. Anderes ausgedrückt, es geht um die Schätzung des Arbeitsaufwandes anhand der vom Kunden gewünschten Funktionen. Das Vorgehen erfolgt in folgenden Schritten:

• Entscheidung darüber, ob es sich um eine Neu- oder Weiterentwicklung handelt.
• Festlegung der Systemgrenzen.
• Identifizierung der Funktionstypen und Komponenten. Hierbei werden alle Anforderungen klassifiziert. Diese Klassen sind: Eingaben, Ausgaben, Abfragen, Datenbestände und Referenzdaten des Systems
• Bewertung der Komplexität der Funktionstypen/ Komponenten bezüglich der Skalenwerte einfach, mittel oder komplex und Bildung der gewichteten Summe der Function-Points.

Der Gesamtwert (Total Unadjusted Function Points = UFP) wird weiterhin durch Einflussfaktoren korrigiert, welche den Wert um bis zu 30 Prozent nach oben oder unten ändern können. Nach der Korrektur entsteht aus dem UFP der AFP (Adjusted Funktion Points) unter Anwendung der folgenden Formel:
AFP = UFP *Adjustment Faktor

Die Durchführung dieses Verfahren ist unter Vorliegen von folgenden Voraussetzungen möglich:

• Betrachtung des Gesamtproduktes
• Betrachtung aus der Sicht der Auftraggeber
• Vorliegen eines Lastenhefts
• Durchführung einer unternehmensspezifischen Schulung für einheitliche Einschätzungen.
• Möglichkeit der Ermittlung des Ist-Aufwandes zur Aktualisierung der Funktionskurve.

Literatur und Links

[1] Tiemeyer, E. (Hrg.): Handbuch IT-Projektmanagement, Hanser Verlag, 2010.

[2] Burghardt , M.: Projektmanagement: Leitfaden für die Planung, Überwachung und Steuerung von Projekten, Publicis-Verlag.

[3] Kelter, U.: Aufwandsschätzung, verfügbar unter https://pi.informatik.uni-siegen.de/lehre/2010w/LM/lm_aws_20010118_a5.pdf

[4] Sommerville, I.: Software Engineering, PearsonStudium, München, 2001.

[5] http://de.wikipedia.org/wiki/Barry_W._Boehm