nach oben
Meine Merkliste
Ihre Merklisteneinträge speichern
Wenn Sie weitere Inhalte zu Ihrer Merkliste hinzufügen möchten, melden Sie sich bitte an. Wenn Sie noch kein Benutzerkonto haben, registrieren Sie sich bitte im Hanser Kundencenter.

» Sie haben schon ein Benutzerkonto? Melden Sie sich bitte hier an.
» Noch kein Benutzerkonto? Registrieren Sie sich bitte hier.
Ihre Merklisten
Wenn Sie Ihre Merklisten bei Ihrem nächsten Besuch wieder verwenden möchten, melden Sie sich bitte an oder registrieren Sie sich im Hanser Kundencenter.
» Sie haben schon ein Benutzerkonto? Melden Sie sich bitte hier an.
» Noch kein Benutzerkonto? Registrieren Sie sich bitte hier.

« Zurück

Ihre Vorteile im Überblick

  • Ein Login für alle Hanser Fachportale
  • Individuelle Startseite und damit schneller Zugriff auf bevorzugte Inhalte
  • Exklusiver Zugriff auf ausgewählte Inhalte
  • Persönliche Merklisten über alle Hanser Fachportale
  • Zentrale Verwaltung Ihrer persönlichen Daten und Newsletter-Abonnements

Jetzt registrieren
Merken Gemerkt
Messen und Prüfen - Software

Den Aufwand von Softwareprojekten schätzen

Drei Methoden im Überblick und Vergleich

© Konstantin Li - Fotolia.com

© Konstantin Li - Fotolia.com

Beim Berechnen des Aufwandes für ein neues Softwareprojekt bleiben trotz guter Berechnungsmethoden oft noch viele Unbekannte übrig. Diese müssen, je nach Projektfortschritt, immer wieder neu angepasst werden. Deshalb gilt generell: Besser bestehende Systeme weiter zu entwickeln, als völlig neue ungenau zu schätzen. Bleibt die Software-Neuentwicklung dennoch nicht aus, stehen drei Methoden zur Aufwandsabschätzung zur Verfügung.

Die Function-Point Methode

Bei Anwendung der Function-Point-Zählung ist besonders darauf zu achten, die Zählobjekte zum Zeitpunkt der Anforderungsspezifikation auch tatsächlich zu erkennen. Dies sind Eingaben, Ausgaben, Datenobjekte und Import/Export Schnittstellen. Das heißt, der Aufwandschätzer muss sie bereits im Anforderungsdokument erkennen. Bestenfalls sind die Ein- und Ausgaben in dem Dokument explizit ausgewiesen.

Zu den Ein- und Ausgaben zählen Benutzeroberflächen, aber auch Bewegungsdateien und Nachrichten müssen mitgezählt werden. Gerade diese sind im Fachkonzept nicht immer erkennbar. Deshalb sollte der Schätzer selbst ein grobes Funktionsmodell aus den Anforderungen ableiten, an dem er erkennen kann, was Ein- und Ausgaben sind.

Beispiel einer Function-Point Zählung

Für die Zuordnung des Punktwerts zu Transaktionen und Datenbeständen gibt es ausführliche Regeln im Standard, die sogenannten "Komplexitätsregeln". Konnten die Functions-Points ermittelt werden, müssen sie auf Personentage umgerechnet werden. Hier kommt nun die anfangs erwähnte Produktivität des Projektteams ins Spiel. Weiß das Software-Entwicklungsunternehmen, wie viele Function-Points es pro Personenmonat in den bisherigen Projekten der vergleichbaren Größenordnung produziert hat, lässt sich die Rechnung leicht aufmachen.

Stärken der Function-Point Methode: Die Stärke der Function-Point Methode ist der Grad ihrer Verbreitung. Es sind weltweit schon tausende Projekte nach der Function-Point-Methode geschätzt worden. Dies hat zu einer großen Erfahrungsdatenbank geführt, auf die Function-Point-Schätzer zurückgreifen können. Die Function-Point-Methode hat auch den höchsten Normierungsgrad. Es gibt gleich zwei Normen – IFPUG Function-Points und COSMOS Function-Points. Hinter beiden Normen stehen große internationale Organisationen, die ständig neue Daten sammeln. Wer mit Function-Points schätzt, befindet sich in guter Gesellschaft.

Schwächen der Function-Point Methode: Die Function-Point-Methode setzt ziemlich spät an und einen recht detaillierten Entwurf des Zielsystems voraus. Auch dann ist es nicht einfach, Function-Points zu zählen. Der Schätzer braucht eine spezielle Ausbildung. Die Umsetzung von Function Points in Aufwand ist ebenfalls nicht unproblematisch. Jeder Entwicklungsbetrieb muss eine eigene Produktivitätskurve ermitteln.

Die Use-Case-Point Methode

Der Schwede Gustav Karner implementierte die Use-Case-Point Methode zusammen mit der Firma Objectory im Rahmen seiner Diplomarbeit 1993. Dabei ging es auch um Aufwandschätzung von Software-Entwicklung, namentlich um objektorientierte Entwicklung. Karner ging von der Nutzung der Objekte aus. Das heißt, er stellte die Nutzung in Form von Anwendungsfällen (use cases) und die Nutzer in Form der Systemakteure in den Vordergrund. Auch die Schnittstellen der Anwendungsfälle bzw. der Systemakteure spielen eine Rolle. Wenn ein Anwendungsfall einen anderen benutzt oder erweitert, gibt es eine Schnittstelle dazwischen.

In Anlehnung an die Function-Point Methode hat Karner zudem zwei Einflussfaktoren eingeführt: den Produkteinflussfaktor und den Projekteinflussfaktor. Und wie bei den Function-Points können diese Einflussfaktoren die Zahl der Use-Case Punkte um +/- 35 Prozent justieren [Kusomoto04]. Im frühen Projektstadium von Softwareentwicklungen können Anwendungsfälle, Systemakteure und Einflussfaktoren dem Anforderungsdokument entnommen werden, ohne sie zu modellieren.

Beispiel einer Use-Case-Point Zählung

Stärken der Use-Case-Point Methode: Die Hauptstärke der Use-Case-Point Methode ist die Leichtigkeit, mit der die Use-Case-Points gezählt werden können. Systemakteure, Anwendungsfälle und Schritte sind leicht erkennbar. Die Regeln, sie zu gewichten, sind auch leicht zu lernen. Use-Cases werden immer mehr verwendet, um IT-Systeme zu spezifizieren, so dass ein Schätzer sie eher vorfindet als ein detailliertes Funktionsmodell.

Schwächen der Use-Case-Point Methode: Die größte Schwäche der Use-Case-Point Methode ist die Abwesenheit einer großen Erfahrungsdatenbank. Die Methode ist noch zu jung und hat keine Normierungsorganisationen hinter sich wie die Function-Point Methode. Einzelne Entwicklungsbetriebe haben erst begonnen, Produktivitätsdatenbanken aufzubauen. Ohne genügend Erfahrungswerte ist die Umsetzung von Use-Case-Points hinsichtlich des Aufwands ein riskantes Spiel. Es gibt Versuche, die Function-Point Produktivität auf Use-Case-Points zu übertragen, aber das ist noch Forschungsarbeit.

Die Story-Point Methode

Die Story-Point Schätzung ist eine Methode, die sich in der agilen Software Entwicklung durchgesetzt hat. Dabei wird zu Beginn des Projektes kein großes Lastenheft geschätzt. Die Anforderungen an die zu entwickelnde Software werden viel mehr in kleine Stories zerlegt. Diese beschreibt der Produktinhaber bzw. der Benutzervertreter dem Entwicklungsteam meist verbal. Jede Story beschreibt eine Anforderung, die für das Projekt einen Mehrwert darstellt. Als Maßeinheit dienen Story-Points.

Story-Points

Ein Story-Point bezieht sich – im Gegensatz zu Function-Points und Use-Case-Points – nicht auf die Eigenschaften des Produktes. Er bezieht sich auf die relative Produktivität des Teams [Schwaber03]. Aufgrund bisheriger Erfahrung weiß das Team, wieviel Aufwand es braucht, um eine Story umzusetzen. Es gibt keine feste Regel, wie ein Story-Point zu definieren ist, dies wird von Team zu Team variieren. Das Team entscheidet, was hinter einem Story-Point steckt. Der Story-Point wird durch das Vergleichen verschiedener Storys vergeben. Zudem hat ein Story-Point nur Relevanz innerhalb eines Projekts, weil er von der Produktivität dieses Projekts abhängig ist.

Beispiel für eine Story-Point Zählung

Vor allem bei agilen Softwareprojekten sollte das ganze Team in die Schätzung einbezogen werden. Zudem ist die Story-Point Methode darauf ausgerichtet, den Aufwand nach jedem Release neu zu schätzen. Bei der Function- und Use-Case-Point-Methode muss die Schätzung erfahrungsbedingt kalibriert werden.

Stärken der Story-Point Methode: Die Stärke von Story-Points ist ihre flexible Auslegbarkeit. Jedes Team kann sie selbst definieren und ihrem Projekt nach Bedarf anpassen. Sie stellen einen Versuch dar, die Erfahrung des Teams mit früheren Projekten auf das neue Projekt in systematischer Weise zu übertragen. Sie setzen nichts anderes voraus als die Geschichten des Produkt-Owners (Produktauftraggebers) und die Erfahrung des Teams.

Schwächen: Die Hauptschwäche der Story-Point Methode ist die fehlende Vergleichbarkeit. Da Story-Points projektspezifisch sind, lassen sie sich nicht ohne Weiteres auf andere Projekte übertragen. Eine projektübergreifende Erfahrungsdatenbank kann nicht zustande kommen. Die Story-Point Zählung ist zwar erlernbar, setzt aber gute Programmierkenntnisse und Entwicklungserfahrung voraus. Die Methode ist für externe, spezialisierte Schätzer nicht gedacht.

Flexiblere Festpreisverträge

Tatsache ist, dass es bei einer Neuentwicklung mit einer neuen Mannschaft viel zu viele Unbekannte gibt, um den Aufwand auf Anhieb genau zu schätzen. Es wird daher eine Brandbreite von +/- 50 Prozent geben [Jantzen08]. Es ist bereits als Erfolg zu verbuchen, wenn die Brandbreite sich darauf beschränkt.

Jedenfalls sollten Festpreisverträge flexibler gestaltet werden. Die Vertragspartner könnten einen Höchstbetrag festlegen. Sollte der Auftragnehmer mit weniger Aufwand auskommen, bekommt er einen Bonus für jeden Personenmonat, den er weniger abrechnet [Gloger12].

Bestehende Software weiterentwickeln

Trotz hilfreicher Methoden bleibt Software-Entwicklung ein aufwendiges und unsicheres Vorhaben. Daher müsste das Ziel lauten, möglichst wenig neue Software in die Welt zu versetzen. Die Evolution bestehender Systeme ist leichter abschätzbar, weil die bestehende Software messbar und die bisherige Produktivität bekannt ist [Sneed13]. Die Preise gekaufter oder gemieteter Services stehen fest. Die Kosten, sie zu integrieren und zu testen, lassen sich anhand der Anzahl der erforderlichen Testfälle ermitteln.


Inhaltsverzeichnis

Autor

Harry M. Sneed ist Software Engineer und zählt zu den Wegbereitern der Software-Testtechnologie. 1940 in Mississippi/USA geboren, schloss er sein Studium in Informationswissenschaften und Public Administration an der Universität in Maryland ab. Er hat zahlreiche Softwareprojekte in den USA und Europa geleitet darunter mehr als ein Dutzend Reengineering Projekte und über 60 Softwarewerkzeuge entwickelt. Als Autor veröffentlichte er über 400 Fachberichte in englischer und deutscher Sprache, seine Bücher erschienen im unter anderen im Carl Hanser Verlag. Neben seiner freiberuflichen Tätigkeit als QA Berater und Toolentwickler lehrt an Universitäten wie Regensburg, der Universität Sannio in Italien oder in Szeged, Ungarn. Auch an anderen deutschsprachigen Universitäten wie etwa in Dresden ist er immer wieder als Gastdozent tätig. In Deutschland ist Harry Sneed Mitglied in der Gesellschaft für Informatik und in den USA wurde in den Technischen Ausschuss des IEEE (Institute of Electrical and Electronics Engineers) der Computer Society berufen.

Literaturhinweis

[Chen05] Chen, Z./ Menzies,T./Port, D./Boehm, B.: „Finding the right Data for Software Cost Modelling“, IEEE Software, Nov. 2005, S. 38

[Kusomoto04] Kusomoto, S./ Fumikazu, M./ Katsuro, I.: „Estimating Effort by Use Case Points“, Proc. of IEEE Symposium on Software Metrics, Chicago, Sept. 2004, S. 292

[Schwaber03] Schwaber, K.: Agile Project Management with Scrum, MicroSoft Verlag, Redmond, 2003, S. 110

[Jantzen08] Jantzen, K.: „Verfahren der Aufwandsschätzung für komplexe Softwareprojekte von heute“, Informatikspektrum, Band 31, Nr. 1, 2008, S. 35

[Gloger12] Gloger, B. u.a.: Der agile Festpreis, Hanser Verlag, München-Wien, 2012, S. 101

[Sneed13] Sneed, H.: Softwareevolution, dPunkt Verlag, Heidelberg, S. 109

Weitere Literaturempfehlungen:

Baumgartner, M. ua.: Agile Testing, Hanser Verlag, München-Wien, 2013

Mario Winter, Mohsen Ekssir-Monfared, Harry M. Sneed, Richard Seidl, Lars Borner, Der Integrationstest,Von Entwurf und Architektur zur Komponenten- und Systemintegration, Carl Hanser Verlag, November 2012

Gloger, B.: Scrum – Produkte zuverlässig und schnell entwickeln, Hanser Verlag, München-Wien, 2011

Harry M. Sneed, Richard Seidl, Manfred Baumgartner: Software in Zahlen - Die Vermessung von Applikationen, Carl Hanser Verlag, September 2010

Harry M. Sneed, Manfred Baumgartner, Richard Seidl, Der Systemtest, Von den Anforderungen zum Qualitätsnachweis, Carl Hanser Verlag Auflage: 2., aktualisierte und erweiterte Auflage (4. Dezember 2008)

Sneed, H.: Software Projektkalkulation–Praxiserprobte Methoden der Aufwandsschätzung für verschiedene Projektarten, Hanser Verlag, München, 2005

Rupp, C.: Requirements Engineering und –Management, Hanser Verlag, München, 2001

Software-Qualität - Software-Test, Testen von Software

Ribu, K.: Estimating Object-oriented Software Projects with Use Cases“ Masters Thesis, University of Oslo, Norway, Nov. 2001

Frohnhoff, S./ Jung, V./ Engels, G.: „Use Case Points in der industriellen Praxis“ Proc. oft IWSM/Metrikon 2006, Shaker Verlag, Potsdam, Nov. 2006.

Symons, C.: „Software Industry Performance – What you measure is what you get“ IEEE Software, Nov. 2010

Sneed, H.: „Schätzung der Entwicklungskosten objektorientierter Software“ Informatikspektrum, Band 19, Nr. 3, Juni 1996

Karner, G.: Metrics for Objectory, Master’s Thesis, University oft Linköping, Sweden, Nr. Lith-IDA-Ex-9344:21, Dez. 1993

Sneed, H.: „Vergleich zweier Aufwandsschäztungen nach Function-Point und Use Case Point“, DASMA Metrikon 2010, Shaker Verlag, Kaiserslautern, Nov. 2010

Ernst Tiemeyer (Hrsg.): Handbuch IT-Projektmanagement , Vorgehensmodelle, Managementinstrumente, Good Practices; 2., überarbeitete und erweiterte Auflage 2014; Carl Hanser Verlag München

Weiterführende Information
  • Software-Qualität - Software-Qualität

    Der übliche Software-Qualitätsbegriff greift zu kurz

    Funktionalität allein bringt keinen dauerhaften Erfolg

    Die Praxis zeigt, dass bei der Entwicklung von Software Qualität flexibel einstellbar sein sollte. Gefragt ist eine ganzheitliche Sicht auf Qualität, die Zeit und Kosten spart.   mehr

DIN EN ISO 9001:2015

Zum ISO 9001:2015 Special

Prozesswelt

Serie zum Thema Prozesse, veröffentlicht von QM-Experten deutscher Unternehmen gemeinsam mit der N5 GmbH und der Fachzeitschrift QZ

Zur Prozesswelt