Aufwandsschätzung von Software

Aufwandsschätzung von Software

Die Basis jedes industrialisierten Softwareprojekts ist die initiale Aufwandsschätzung. Ressourcen müssen geplant, Kosten geschätzt und die Meilensteine bis zum Projektende festgelegt werden. Seit Beginn der Softwareentwicklung wurde Programmierleistung von Software mit Metriken bewertet. Zum Einsatz kamen Personentage (PT), Lines of Code (LOC), Story Points (SP) oder Preis der Dienstleistung pro Programmierstunde (€). Alle diese Metriken lassen nur einen beschränkten Rückschluss auf die objektive Programmier-Performance oder den tatsächlichen Umfang von eingekaufter oder programmierter Software zu. Heutige Produktivitätsfaktoren sind meist subjektiv und speziell bei zugekauften Programmierleistungen lassen sich die Anbieter schwer vergleichen. Es bedarf einfacher und standardisierter Metriken zur Abschätzung der Entwicklungsperformance.

Speziell die initiale Aufwandsschätzung bei agile Softwareentwicklungsprojekten stellt die Manager vor neue Herausforderungen. Die Praxis zeigt, dass bei einem Großteil der agilen Projekte zu Beginn der vollständige Projektumfang noch nicht abschließend definiert wurde. In diesen Situationen werden dann vergleichende Schätzungen durchgeführt: „Vermutlich hat dieses Projekt eine vergleichbare Größe wie Projekt XY und wird somit ca. 2 Million Euro kosten“. Hierbei handelt es sich um eine valide Schätzmethode und man kann damit einen groben Budgetrahmen festlegen. In der nächsten Projektphase muss diese Abschätzung konkretisiert werden. Als Vorarbeit muss der tatsächliche fachliche, funktionale Projektumfang mit allen High-Level-Anwendungsfällen (Epics) definiert werden. Nur so kann eine verlässliche Aufwandsschätzung durchgeführt werden.

Für die Aufwandsschätzung existieren unterschiedliche Methoden, die je nach Projektsituation ausgewählt und kombiniert werden. Bei der korrekten Aufwandsschätzung ist zu beachten, dass der Zahlenwert immer mit einer Ungenauigkeit (Varianz) angegeben wird. Die langjährige Schätzerfahrung hat gezeigt, dass Schätzungen selten nach unten hin abweichen. Der tatsächliche Umsetzungsaufwand liegt beim Großteil der Softwareprojekte signifikant über dem initial geschätzten Wert. Bei der Grobschätzung eines Projekts kann die Abweichung bis zu 40 Prozent des geschätzten Wertes liegen. Die Korrektheit der Feinschätzung (Bottom-Up-Schätzung) eines Softwareprojekts sollte sich im 20 Prozent-Korridor zum tatsächlichen Umsetzungsaufwand bewegen.

Experten-Schätzungen

Je nach Komplexität, Priorität und Größe eines Projekts kommen unterschiedliche Methoden der Expertenschätzung zum Einsatz. Die einfachste Schätzmethodik ist die Schätzung durch einen außergewöhnlich erfahrenen Senior Projektmanager. Auf Grund der zahlreichen absolvierten Softwareprojekten ist es diesem Experten sehr einfach möglich, den konkreten Aufwand für die unterschiedlichen Projektteilnehmer abzuschätzen. Je größer die Projekte werden, umso wichtiger werden multiple Expertenschätzungen. Abhängig vom Bedarfsfall empfiehlt sich eine der folgenden Schätzmethoden: Mehrfachbefragung, Delphi-Methode oder die Durchführung einer Schätzklausur.

Die parametrisierte Schätzung von gesamten Softwareprojekten oder Softwarekomponenten erfolgt idealerweise mit einer organisationsinternen historischen Projektdatenbank oder mit einer öffentlichen Projektdatenbank. Dabei werden die Schätzparameter durch die Fach- oder technischen Experten ermittelt und mit der historischen Projektdatenbank abgeglichen. Diese Methode und eine umfangreiche historische Projektdatenbank lieferten die besten Schätzergebnisse. Beispiele sind die ISBSG-Projektdatenbank und der ReqPOOL Estimation Manger.

Parametrisierte Schätzungen

Komplexitäts-Schätzungen

Moderne Softwareentwicklungsteams tendieren zur Bewertung der technischen Umsetzungskomplexität der Anforderungen. Als Ergebnis erhält man die Komplexitätsbewertung in Form von Story Points, T-Shirt-Größen oder Function Points. Aufgrund von historischen Erfahrungswerten kann von dieser Komplexitätseinschätzung auf den tatsächlichen Umsetzungsaufwand geschlossen werden. Generell sollte auf komplexe Mathematische Modelle zur Umrechnung auf den Aufwand verzichtet werden, da sie eine trügerische Sicherheit vermitteln. Eine einfache Umrechnung (z. B.: 1 Function Point kann mit 2 Personentagen Aufwand umgesetzt werden) ist erfahrungsgemäß die kosteneffizienteste und objektivste Methode, um von der Komplexität auf den Umsetzungsaufwand zu kommen.

Funktionale Softwaregröße als objektive Metri

Allgemein können Güter durch Metriken definiert und vergleichbar gemacht werden. Beispielsweise werden Wohngrößen in Quadratmetern und Motoren in Pferdestärken (neuerdings KWh) gemessen und verglichen. Um diese Messbarkeit auch in der Informationstechnologie zu ermöglichen, wurde das System der Function Points entwickelt. Die Function-Point-Analyse ist eine Methodik, welche zur Bewertung des fachlich-funktionalen Umfangs eines Softwaresystems dient.
Das Function-Point-Verfahren rief Ende der Siebzigerjahre Allen J. Albrecht, im Rahmen seiner Tätigkeit bei dem US-amerikanischen Unternehmen IBM, ins Leben. Das Bewertungsergebnis, die Functional Size, wird in der Maßeinheit Function-Points angegeben.
In der Softwareentwicklung werden die Function Points als Grundlage für Aufwandsschätzungen verwendet. Die mit Function Points errechneten Kennzahlen können Unternehmen zum Vergleich von Angeboten oder Spezifikationen von IT-Projekten nutzen.
Der Vorteil besteht in der Ermittlung von Kennzahlen ohne eine Verbindung zu technischen Details, wie verwendete Programmiersprachen oder Systembedingungen. Die ermittelten Function Points (FP) können dadurch transparent als Grundlage zur Aufwandsschätzung oder Benchmarking verwendet werden und unterstützen das Controlling bei Kennzahlenanalysen.

Die Basis: Counting Practices Manual

Die FPA wird auf Basis des Regelwerks des Counting Practices Manual (CPM, Release 4.3.1) der International Function Point User Group (IFPUG) durchgeführt. Dieses Manual basiert auf den Standards der „ISO/ IEC 20926:2009“ bzw. „ISO/IEC 14134-1:2007“ und enthält zahlreiche Definitionen, Regeln und Beispiele.

Das Bewertungsschema

Für die Bestimmung der funktionalen Größe ist die Anwendersicht („User View“) ein zentrales Paradigma. Zur Bewertung werden demnach nur diejenigen Funktionen der Software berücksichtigt, die in den jeweiligen Geschäftsprozessen genutzt werden und für den User einen wahrnehmbaren Optimierungseffekt mit sich bringen.

Der Begriff des Anwenders in der FPA ist konzeptionell dem Akteur gleichzusetzen. Ein Anwender muss nicht notwendig eine natürliche Person sein, sondern kann auch ein anderes System (z.B. eine Maschine) sein.

Der Begriff der Anwendersicht ist deshalb keinesfalls wörtlich zu nehmen. Die Anwendersicht fokussiert sich darauf, dass bei der Bewertung nur diejenigen Funktionen der Software zu berücksichtigen sind, die der Unterstützung der jeweiligen Geschäftsprozesse dienen. Die Sicht des Anwenders kann dabei durch den Anwender verbal dargestellt werden oder in verschiedenen Formen (Anforderungsdokument, Detailspezifikation, Anwenderhandbuch) vorliegen.

aufwandschaetzung

Die Basis: Counting Practices Manual

Die FPA wird auf Basis des Regelwerks des Counting Practices Manual (CPM, Release 4.3.1) der International Function Point User Group (IFPUG) durchgeführt. Dieses Manual basiert auf den Standards der „ISO/ IEC 20926:2009“ bzw. „ISO/IEC 14134-1:2007“ und enthält zahlreiche Definitionen, Regeln und Beispiele.

Das Bewertungsschema

Für die Bestimmung der funktionalen Größe ist die Anwendersicht („User View“) ein zentrales Paradigma. Zur Bewertung werden demnach nur diejenigen Funktionen der Software berücksichtigt, die in den jeweiligen Geschäftsprozessen genutzt werden und für den User einen wahrnehmbaren Optimierungseffekt mit sich bringen.

Der Begriff des Anwenders in der FPA ist konzeptionell dem Akteur gleichzusetzen. Ein Anwender muss nicht notwendig eine natürliche Person sein, sondern kann auch ein anderes System (z.B. eine Maschine) sein.

Der Begriff der Anwendersicht ist deshalb keinesfalls wörtlich zu nehmen. Die Anwendersicht fokussiert sich darauf, dass bei der Bewertung nur diejenigen Funktionen der Software zu berücksichtigen sind, die der Unterstützung der jeweiligen Geschäftsprozesse dienen. Die Sicht des Anwenders kann dabei durch den Anwender verbal dargestellt werden oder in verschiedenen Formen (Anforderungsdokument, Detailspezifikation, Anwenderhandbuch) vorliegen.

Leistungsorientierung durch Function Points

Durch Analyse der bestehenden Entwicklungsleistungen – irrelevant ob extern beauftragt oder durch interne Ressourcen erbrachte Entwicklungsleistung – ist eine Bestimmung der Performance der Entwicklung über mehrere Releases messbar. Diese analysierten, historischen Werte dienen der Kalibrierung dieser Methodik und ermöglichen die Bestimmung der Stückkosten für einen implementierten Function-Point. Hierzu müssen zusätzlich zum Quellcode die historischen Werte der Entwicklung und die Dokumentation der entwickelten Funktionalitäten zur Verfügung gestellt werden.

Für die Entwicklungsperformance von Software gibt es Referenzwerte mit Bezug auf Function-Points. Abhängig von der eingesetzten Technologie belaufen sich die Stückkosten für einen implementierten Function-Point auf durchschnittlich 1,5 bis 3 Personentage.

Die Einführung von regelmäßigen Aufwandsschätzungen und die Messung der funktionalen Größe von Software kann Einsparungen bei der Softwarebeschaffung von bis zu 35 Prozent realisieren. Der Einsparungseffekt ergibt sich durch die verbesserte Planung während der Softwareentwicklung, transparenterer Nachverfolgung von Änderungen und der vollständigeren Spezifikation vor der Übergabe.

Die nachfolgende Grafik zeigt die Performance eines Entwicklerteams. Es sind die durchschnittlich benötigten Personentage pro Function Point dargestellt. Für jeden Release-Container lassen sich neutrale Stückkosten berechnen und somit die Performance des Teams objektiv messen.

Performance Softwareentwicklung

Automatisierte Schätzung – ReqPOOL Estimation Manager

Der erste Prozessschritt in einem Beschaffungsprozess ist die Aufwandsschätzung. Mit dem Estimation Manager ermitteln Sie einfach und schnell den Umfang Ihres Projektes und reduzieren die Komplexität auf aussagekräftige Parameter. So erhalten Sie und Ihre Projektbeteiligten eine schnelle und komfortable Erstabschätzung und Kostenkalkulation Ihres Projektes.

Der ReqPOOL Estimation Manager steht Ihnen als Cloud & On-Premise Weblösung und als Excel-Front-End mit zentraler Schätz-Engine zur Verfügung.
Um das volle Potenzial des Estimation Managers auszuschöpfen, müssen Sie lediglich acht Projektparameter eingeben:

Projektparameter für die Berechnung:

  • Masken: Anzahl der Benutzerinteraktionen
  • Anwendungsfälle: Anzahl der Funktionalitäten
  • Datenobjekte: Anzahl der Geschäftsobjekte
  • Schnittstellen: Anzahl der verbundenen Systeme
  • Batches: Anzahl an zeitgesteuerten Funktionalitäten
  • Sprachen: Unterschiedliche Sprach- und Kulturkreise
  • Rollen: Anzahl der Rollen im Softwaresystem
  • Anzahl der Benutzer

Die Berechnung der Umsetzungsaufwände erfolgt durch zwei wissenschaftlich belegte sowie mehrfach ausgezeichnete Algorithmen, dem Experten- und Lernalgorithmus. Dokumentiert werden die Algorithmen und die wissenschaftliche Herleitung in der IEEE Xplore® Digital Library.

Weitere Fachbeiträge ansehen

Vereinbaren Sie ein unverbindliches Erstgespräch