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.

Problematiken der Aufwandschätzung

Muss Software zwingend neu entwickelt werden, erwarten die Kunden eine Vorschau über die Entwicklungskosten- und dauer. Sofort steckt der Projektaufwandschätzer in dem Dilemma, dass genaue Vorhersagen zu einem frühen Projektzeitpunkt schwer möglich sind, da entsprechende Informationen fehlen. Zudem ist die Zeit knapp. Schon aus Zeitgründen bieten sich daher nur anforderungsbasierte Schätzmethoden an. Schätzmethoden, die ein Modell voraussetzen, das erst entwickelt werden muss, scheiden aus.

Kundenanforderungen und eigene Produktivität

Dem Aufwandschätzer bleibt also keine andere Möglichkeit, als auf den Text zu den Software-Anforderungen und/oder eine Reihe von User Stories zurückzugreifen. Beides liegt im frühen Projektstadium meist vor. Ein entscheidender Faktor für die Aufwandschätzung der Softwareentwicklung ist neben den Kunden- bzw. Auftragsinformationen, die Produktivität des Software-Entwicklungsteams. Obwohl diese Produktivität sehr oft ein Tabuthema in Unternehmen darstellt, sollte jeder Software-Entwicklungsbetrieb eigene Untersuchungen zur Produktivität durchführen. Dazu bietet sich beispielsweise an, eine Projekterfahrungsdatenbank aufzubauen.

Hauptmerkmale – key features - eines IT-Systems

Abgesehen von den Daten, die der Software-Projektschätzer von Kundenseite erhält, haben IT-Systeme einige Hauptmerkmale, die beachtet werden müssen. Nach den bisherigen Schätzmethoden sind die ausschlaggebenden Eigenschaften, um die Größe eines IT-Systems zu bestimmen, folgende:

  • Vorgänge; Geschäftsvorfälle bzw. Anwendungsfälle
  • benutzte Geschäftsobjekte
  • geltende Geschäftsregeln
  • vorgesehene Geschäftsschnittstellen
  • nicht-funktionale, qualitative Anforderungen bzw. Einschränkungen [Chen05].

Hier gilt: je ungenauer die vorliegenden Informationen, desto ungenauer die Aufwandsschätzung.

Drei Schätzungsmethoden

Mithilfe der Hauptmerkmale eines IT-Systems und den Informationen von Kundenseite – wie Anforderungsdokumente und/oder Anwendervorgaben (User Stories) – leitet der Projektschätzer Produktgrößen ab und setzt sie in Aufwand um. Dazu kann er eine der drei anforderungsbasierten Schätzmethoden verwenden:

  • Function-Point Methode
  • Use-Case-Point Methode
  • Story-Point Methode

Welche Methode am besten zu verwenden ist, hängt von der Information ab, die der Schätzer zum Zeitpunkt der Schätzung hat. Die Function-Point Methode setzt ein detailliertes Funktionsmodell voraus, aus dem die Datenflüsse in und aus dem Zielsystem hervorgehen. Ein Datenmodell ist auch erforderlich, um die Datenbanktabellen zu erkennen. Function-Points können erst richtig gezählt werden, wenn die Systemarchitektur steht.

Die Use-Case-Point Methode setzt nicht ganz so viele Informationen voraus, aber fast. Um sie anzuwenden, braucht der Schätzer die Use-Case Diagramme mit den Systemakteuren und den Use-Case Beschreibungen. Die Beschreibungen müssen so detailliert sein, dass zumindest die einzelnen Schritte zu erkennen sind. Wer Use-Cases verwendet, um seine Systeme zu beschreiben, ist gut beraten nach Use-Case-Points zu schätzen, da er die nötige Information bereits zur Verfügung hat.

Die Story-Point Methode setzt am wenigsten Informationen über das geplante System voraus. Dafür benötigt sie Erfahrungen mit früheren ähnlichen Systemen, da sie auf der Analogie basiert. Wer also nur unzulängliche Information über das geplante System zur Zeit der Schätzung hat, wie das in agilen Projekten der Fall ist, ist gut beraten Story-Points zu verwenden.


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