Requirements Engineering and Cost Estimation - Cost Estimation

Cost Estimation

In vielen Standardwerken zu Requirements Engineering spielen Schätzungen gar keine Rolle, was insofern überraschend ist, da zu den ersten Fragen an Projekt­verantwortliche immer jene nach zeitlichem Aufwand und Kosten gehören. Als einige der wenigen räumen Ebert und Bergsmann dem Thema jeweils einige Seiten ein . Nichtsdestotrotz macht das sichtbar, dass Schätzung immer noch in der allgemeinen Literatur vernachlässigt wird. Dies wiederum erklärt, warum nach wie vor zahlreiche Witze über die Dauer bzw. Kosten von Softwareprojekten kursieren bzw. der Alltag viel zu viele IT-Projekte mit sich bringt, deren geschätzter Aufwand wenig bis nichts mit der Realität zu tun hat. Sehr häufig muss ab der Projektmitte zusätzlicher Bedarf angemeldet werden, obwohl das Team bereits mit vollem Einsatz und bis in die Nachtstunden hinein werkt, um den versprochenen Termin halten zu können. Dabei sei hier das Zitat berücksichtigt, das u.a. Karl Valentin, Mark Twain, Winston Churchill oder Niels Bohr zugeschrieben wird: ‚Prognosen sind schwierig, besonders wenn sie die Zukunft betreffen.‘

Spätestens in der Phase Anforderungen prüfen und abstimmen sind grobe Schätzungen des Projektaufwand gefordert, auch um die Auswirkungen der einzelnen Requirements zu bewerten.

Was ist Cost Estimation?

McConnell definiert Aufwandsschätzung im Umfeld der Softwareentwicklung wie folgt: „Eine Schätzung ist eine Vorhersage darüber, wie lange ein Projekt dauert und wie hoch dessen Kosten sind“ . Das heißt, es handelt sich um eine Kalkulation bzw. Evaluierung des geplanten Resultats eines messbaren Projektteils, bevor dieses bekannt ist. Das Ergebnis einer Schätzung ist also weder etwas Endgültiges noch Fixes. Die Qualität einer Schätzung steigt, wenn sie während eines Projekts zu unterschiedlichen Zeitpunkten immer wieder erhoben wird. Je später im Projekt eine Schätzung durchgeführt wird, desto höher sind der Wahrheitsgehalt und die Aussagekraft, da immer mehr Informationen vorhanden sind und Unsicherheiten überschaubarer werden. Die vorliegenden Informationen, auf denen eine Schätzung beruht, prägen diese enorm.

In der Praxis sind Aufwandsschätzungen für IT-Projekte ein heißes Thema und die Definition muss durch Einflüsse des Unternehmens oder durch unterschiedliche Stakeholder erweitert werden. So wünschen sich Vertriebsmitarbeiter meist für ihre Kunden ein ‚gutes‘ Angebot und Führungskräfte erwarten eine verbindliche Aussage oder einen aussagekräftigen Plan, mit dem das Ziel erreicht wird. Die Schätzung darf aber auch nicht zu niedrig ausfallen, um das Projekt nicht zum Verlust zu machen. Der Requirements Engineer soll all diesen Wünschen Genüge tun und betriebs­wirtschaftlich interessante, konkurrenzfähige Aufwände nennen. Häufig sichert er sich mit einem ‚Managementpuffer‘ ab, da es immer wieder üblich ist, wie am Basar um Kosten bzw. Ressourcen zu feilschen. Trotz aller Ungewissheiten, wie diffuse Spezifikationen, Stakeholder mit widersprüchlichen Vorstellungen, technische Risiken, Ressourcenknappheit usw., eine sinnvolle Prognose abzugeben, auf deren Basis u.a. ein verbindliches Angebot erstellt werden kann, ist die Kunst der Aufwands­schätzung. Andernfalls enden Projekte aber meist desaströs.

Spätestens nach dem Angebot sind Liefertermin und Projektbudget eines IT-Projekts meist fixiert und der Kunde kümmert sich wie beim Autokauf nicht darum, wie der Prozess der Softwareentwicklung genau abläuft. Ihn interessieren nur die wichtigsten Funktionen, die Qualität und die Anwenderfreundlichkeit des gewünschten Systems. Dies ergibt ein magisches Dreieck mit den Eckpunkten Budget, Termin und Kernfunktionalität. Innerhalb diesem muss die Softwareentwicklung mit allen ihren unbestimmten Parametern Platz finden. Variabel bleiben dabei die Detailfunktionen, die Organisation des Projektteams und der Umgang mit Risiken und Unvorher­gesehenem. Im Gegensatz zur Kundenperspektive gibt es aus Entwicklersicht in der Praxis nie genug Budget oder Zeit. Die Schätzung muss da Balance schaffen und sicherstellen, dass zwischen den Eckpunkten genug, aber auch nicht zu viel Raum für das Projekt ist. Sonst kollabiert es womöglich und lässt sich bestenfalls durch zusätzliche Ressourcen wie Zeit, Geld oder Personal bewältigen, wenn es nicht gänzlich scheitert.

Wenn die zeitlichen und/oder finanziellen Wünsche der Stakeholder von vornherein für bare Münze genommen werden, kommt es zu einer Verwechslung von Aufwands­schätzung und Zielsetzung. Das Streben nach diesem Ziel ist vergebens, es erzeugt nur jede Menge Druck und Unzufriedenheit und bleibt immer unerreichbar. Eine Schätzung, die auf ein bestimmtes Ergebnis hin getrimmt ist, ist wertlos. Vielmehr handelt es sich bei einer gewissenhaft durchgeführten Schätzung um den Versuch, eine möglichst hohe Genauigkeit zu erreichen, um eine solide Basis für die Projektplanung zu liefern. Im Idealfall sollte diese daher vor der Projektplanung oder den Zielen erstellt werden. Dadurch minimiert sich das Risiko, dass diese Einfluss auf die Schätzung nehmen.

Wie schon besprochen handelt es sich bei Schätzungen im Softwarekontext eher um ‚Kunst‘ als um Wissenschaft. Von letzterem ist in der Regel dann die Rede, wenn mit höherer Mathematik versucht wird, die Abweichung von Schätzungen von ± 10 % auf ± 5 % zu reduzieren. In der Praxis der Softwareentwicklung gilt es Abweichungen von 100 % und mehr zu vermeiden, weshalb diese kaum im Bereich der Wissenschaft von Schätzungen angesiedelt sind.

Schätzungen als Aussagen zur Wahrscheinlichkeit

Häufig sind in Projekten Feststellungen wie ‚Das Projekt dauert 6 Monate‘ zu hören. Die Praxis zeigt, dass diese selten tatsächlich eintreten bzw. ist es auch nicht wahrscheinlich, dass eine solche Prognose hält. Es stellt sich also die Frage nach der Wahrscheinlichkeit. Die getätigte Aussage fällt in die Kategorie der Einpunkt­schätzungen, da sie einen einzigen Punkt als Ergebnis offeriert. Zudem finden derartige Schätzungen meist einmalig statt und geben keine zusätzlichen Informationen über deren Hintergrund, Annahmen und Hypothesen. Sie suggerieren mit voller Überzeugung eine 100 % Wahrscheinlichkeit, die allerdings unrealistisch ist. Unbedingt ist daher zu hinterfragen, ob es sich um eine Schätzung oder ein Ziel handelt. Einpunktschätzungen eignen sich dementsprechend in der Praxis nicht, um ein Projekt zu planen oder Aussagen über dessen Aufwand zu tätigen.

Entwicklungsprojekte sind voller nichtplanbarer Unsicherheiten. Eine seriöse Schätzung kalkuliert diese mit ein und versieht ein Projektresultat daher mit der wertvollen Information der Wahrscheinlichkeit. Die Grafik zeigt, dass in der Realität die Wahrscheinlichkeitsverteilung nicht einer regelmäßigen Glockenkurve gleicht, sondern, dass sie durch Beschränkungen, wie effektiv ein Projekt umgesetzt werden kann, verzerrt wird.

Abb. 18: Reale Verteilung der Wahrscheinlichkeit von IT-Projekten

Die strichlierte Linie repräsentiert das Normalergebnis, auch Median genannt. An dieser Stelle ist die Wahrscheinlichkeit jeweils 50%, dass das Projekt besser bzw. schlechter funktioniert. Auf der linken Seite der Grafik ist die minimale Aufwands­grenze ersichtlich, da einzelne Schritte nur bis zu einer gewissen Untergrenze optimiert und dann unabhängig von den eingesetzten personellen Ressourcen nicht mehr effektiver abgearbeitet werden können. Eine Obergrenze für den Aufwand ist nicht vorhanden, weshalb die Kurve auf der rechten Seite unendlich weiterläuft. Dies bedeutet, dass das Projekt eventuell nie abgeschlossen wird, was aber der Definition eines Projekts widerspricht, da dies einen definierten Beginn und ein ebensolches Ende haben muss.

Eine weitere Darstellungsmöglichkeit der Wahrscheinlichkeitsverteilung illustriert die folgende Grafik. Sie gibt die Wahrscheinlichkeit an, dass ein Projekt an einem bestimmten oder früheren Zeitpunkt bzw. mit einem bestimmten oder geringeren Aufwand abgeschlossen werden kann.

Abb. 19: Wahrscheinlichkeit der Fertigstellung eines IT-Projekts zu einem bestimmten Zeitpunkt

Diese Grafik illustriert, dass eine Behauptung wie ‚Das Projekt dauert 6 Monate.‘ wenig aussagekräftig und damit überflüssig ist. Prognosen wie ‚Das Projekt kann zu 80 % in 6 Monaten abgeschlossen werden.‘ oder ‚Das Projekt dauert voraussichtlich zwischen 8 und 12 Monaten.‘ sind hingegen viel informativer und machen deutlich, dass immer noch keine 100 % Garantie für das tatsächliche Eintreten des Projekt­abschluss in diesem Zeitraum möglich ist.

Eine ‚gute‘ Aufwandsschätzung erfordert die Investition von ausreichend Zeit in die Analyse und Requirements sowie ein umfassendes Verständnis des zu schätzenden Sachverhalts. Es ist für Balance zu sorgen, denn zu wenig Aufmerksamkeit führt zu mehr Ungewissheit und hohem Risiko. Bei einer zu intensiven Analyse wird die Projektzeit für die Schätzung und nicht das Liefern des zu entwickelnden Systems verbraucht. So gesehen ist eine Schätzung dann hilfreich, wenn die Entscheidungs­träger dadurch ausreichend Informationen erhalten, um das Projekt erfolgreich zu steuern und die Ziele zu erreichen.

Aufwandsschätzungen erfolgen kontinuierlich über den gesamten Projektzeitraum, wobei sich ihre Zielsetzung sowie Genauigkeit je nach Phase verändern. Je weiter ein Projekt fortgeschritten ist, umso mehr Informationen und umso weniger Unsicher­heitsfaktoren sind vorhanden, weshalb die Annahmen, auf denen die Prognosen für die Zukunft basieren, immer präziser werden sollten. In der Startphase sind Schätzungen wichtig, um ein grobes Verständnis für das Projekt zu erhalten. Allerdings muss dabei berücksichtigt werden, dass diese noch eine große Schwankungsbreite aufweisen können. Im Projektverlauf gilt es die ermittelten Richtgrößen zu beobachten und anzupassen. Entscheidend ist darum, den Aufwand nicht nur bei der Initialisierung zu schätzen, sondern diese Aktivität für eine fundierte Planung regelmäßig zu wiederholen.

Einflüsse auf die Aufwandsschätzung

Zahlreiche Einflussfaktoren spielen in der Aufwandsschätzung von Softwareprojekten eine Rolle und beeinflussen die Qualität und Aussagekraft einer Schätzung sowohl positiv als auch negativ. Relevante Faktoren sind unter anderem:

• Größe des zu entwickelnden Systems bzw. Projektgröße

Je größer ein IT-Projekt ist, desto mehr Personen sind meist daran beteiligt und desto höher ist der damit verbundene Kommunikationsaufwand. Die Anzahl der Kommunikationspfade steigt exponentiell, so dass ein 10 Personenteam bereits 45 Kommunikationspfade, also 4,5-mal so viele wie bei einem Team aus 5 Personen aufweist. Allerdings ist der Kommunikations­aufwand auch von der Organisationsform der Projektteams und des durchführenden Unternehmens abhängig, da meist nicht jeder mit jedem kommuniziert und im Idealfall auch strukturierte Kommunikationswege vorhanden sind, was die negativen Folgen des Größennachteils lindert. Nichtsdestotrotz muss bei Großprojekten der höhere Aufwand einkalkuliert werden, was häufig verabsäumt wird.

• Art des zu entwickelnden Systems

Je nachdem was für eine Projektart im Fokus des Vorhabens steht, z.B. Neuentwicklung oder Instandhaltung, lässt sich der potentielle Aufwand kategorisieren. Ebenso verursacht die Erstellung lebenswichtiger Systeme tendenziell einen höheren Aufwand als das hundertste Unternehmens­verwaltungssystem. Wenn hohe Anforderungen im Bereich der Sicherheit gegeben sind, steigt der zu erwartende Aufwand ebenfalls an.

• Persönliche Faktoren

Dazu zählen neben anderen Aspekten die Erfahrung und Qualifikation der Beteiligten, die Personalfluktuation, das projektrelevante Knowhow, die Fähigkeit zur Zusammenarbeit im Team, die Mitarbeiterproduktivität sowie ihre nicht fassbare Motivation.

• Eingesetzte Technik

Bei den im Requirements Engineering eingesetzten Techniken bestehen, wie schon an verschiedenen Stellen erwähnt, große Unterschiede in der Komplexität und damit im Aufwand. Dies gilt ebenso für Design, Implementierung oder Testing.

• Qualität

Besonders im Bereich der Qualität können unterschiedliche Forderungen zu gänzlich divergierenden Schätzungen führen, vor allem auch bei nicht-funktionalen Anforderungen wie Zuverlässigkeit, Performanz usw.

• Prozessreife des Unternehmens

• Systemkomplexität

• Einsatz von Werkzeugen

  1. == Überschätzung versus Unterschätzung ==

Grundsätzlich entstehen Schätzfehler bei jeder Schätzung und sind auf folgende Ursachen zurückzuführen:

• Unklarheit über das zu schätzende Projekt oder Objekt
• Unklarheit über die Fähigkeit des Unternehmens, das Projekt zu bewältigen
• Chaos im Projekt, d.h. ständige unstrukturierte Veränderung
• Ungenauigkeit aufgrund des gewählten Schätzverfahrens

Aufwand kann entweder zu hoch oder zu niedrig bemessen sein, wobei in der Praxis meist die Unterschätzung schwerwiegendere Konsequenzen nach sich zieht. Bei einer Fehlschätzung mit zu geringem Ergebnis steigen die negativen Folgen exponentiell. Hingegen verhalten sie sich beim Überschätzen linear und unterliegen zudem der Einschränkung, dass nur die möglicherweise einzusparende Differenz als Verlust eingestuft werden kann. Unterschätzung führt neben den ohnehin bereits zu knapp bemessenen Ressourcen zu ungeplanten Aktivitäten und Mängeln, die die Prognose weiter steigen lassen. Diese Effekte können sich wechselseitig hoch­schaukeln und ein Projekt schlimmstenfalls zum ‚Kentern‘ bringen.

Dementsprechend kann die Überschätzung meistens als das ‚geringere Übel‘ bezeichnet werden, da die Konsequenzen weniger gravierend sind. Wenn allerdings in Unternehmen oder Projekten kontinuierlich unterschätzt wird, scheitern auch diese.

Überschätzung

Ein Klassiker der Überschätzung ist das sogenannte Scotty-Prinzip, benannt nach dem Chefingenieur von Star Trek. Dieser schlägt, um seinen Ruf als ‚Miracle Worker‘ zu bewahren, auf seine Schätzungen hohe Reserven auf, dass diese selbst unter widrigsten Umständen eingehalten werden können. Diese an Kunden kommunizierten ‚Fantasieschätzungen‘ erlauben jede Menge Verhandlungsspielraum und machen ihn zum Helden, weil das Projekt nahezu immer schneller bzw. günstiger fertiggestellt werden kann. Allerdings sollte man sich nicht erwischen lassen oder zumindest eine geistesgegenwärtige Reaktion a la Star Trek auf Lager haben.

Wenn der Aufwand eines IT-Projekts überschätzt wird, besteht das Risiko, dass Zeit und Geld verschwendet werden. Studien zeigen, dass vorhandene Ressourcen immer aufgebraucht werden, unabhängig davon, ob es möglich gewesen wäre, die Aktivitäten auch mit weniger Zeit oder Kosten zu realisieren. „Work expands so as to fill the time available for its completion.” Dies nennt sich Parkinsonsches Gesetz und ist einer der wichtigsten Gründe, warum Projekte äußerst selten vor dem geplanten Zeitpunkt abgeschlossen werden. Zu entwickelnde Systeme werden also durch Überschätzen teurer, als sie eigentlich sein müssten. Zudem führt das Überschätzen der Kosten in der Regel zu einem im Vergleich zur Konkurrenz höheren Angebot, weshalb der Kunde das zu gewünschte System wahrscheinlich beim Mitbewerber bestellt. Sich zu sehr absichern wollen bzw. zu hohe Prognosen schaden somit der eigenen Auftragslage.

Unterschätzung

Aufgrund unzähliger Ursachen werden Projekte unterschätzt, einige Beispiele sind:

• Um dem Parkinsonschen Gesetz zu entgehen, steigern Kunden oder Ent­scheidungsträger den Druck im Projekt und fordern mehr Leistung von den Projektbeteiligten.
• Mit Vorsatz werden im Projektplan zu frühe Meilensteine eingerichtet, die den Eindruck von Dringlichkeit und Wichtigkeit erzeugen sollen.
• In der Praxis kommt Unterschätzung sehr häufig als Konsequenz von individuellen Expertenschätzungen auf der Basis ‚informeller Analogien‘ vor. Damit ist gemeint, dass die Prognose lediglich auf dem Vergleich mit der persönlich erinnerten Vergangenheit beruht. Üblich ist auch der Einsatz von Intuition und Raten, die beide eine Tendenz zu zu niedrigen Schätzungen aufweisen. Es halten sich in menschlichen Köpfen hartnäckig Vorstellungen wie ‚Diesmal sind wir sicher schneller.‘ oder ‚Da wissen wir, was auf uns zukommt‘.

Eine Konsequenz des Unterschätzens ist die verminderte Effektivität von Projekt­plänen, die so meist zu falschen Entscheidungen führen sowie den gewünschten Prozess des Projekts stören, wenn zwischen einzelnen Arbeitsschritten Wartezeiten entstehen. In zu gering geschätzten Projekten herrscht zudem häufig ein höherer Druck und es steigt die Fehleranfälligkeit, was statistisch die Wahrscheinlichkeit reduziert, dass das Projekt zeitgerecht abgeschlossen wird. Entscheidungsträger reagieren in solchen Situationen meist wenig hilfreich, in dem sie kurz vor Projektabschluss noch zusätzliche personelle Ressourcen hinzufügen. In einem bereits verspäteten Projekt verschlimmert eine Vergrößerung des Teams die Lage und führt zu weiteren Verzögerungen. Dieses Phänomen wird als Brooks‘ Law bezeichnet. Eine weitere Folge von Unterschätzung ist, dass die aufgrund der zu knapp bemessenen Ressourcen ungenügende technische Vorbereitung zu schlechten Resultaten führt. In späteren Phasen müssen dann Anforderungen bzw. bereits entwickelte Komponenten überarbeitet werden, was die Aufwände zusätzlich erhöht. In verzögerten Projekten herrscht meist aufgrund des Drucks eine unangenehme Atmosphäre und diese schädliche Dynamik verschlechtert einerseits die Produktivität bzw. erzeugt zusätzliche Diskussionen und Aktivitäten.

Schätzverfahren

„Der Prozess heißt Schätzung nicht Exaktifizierung“ , aber auch nicht Raten. Auf der Basis von Fakten und fundierten Informationen stehen zahlreiche gängige Schätzverfahren für eine seriöse Schätzung zur Verfügung. Der Unterschied besteht in erster Linie in der Art der Quelldaten sowie der Form der Generierung der Zieldaten. Die Techniken lassen sich in folgende Kategorien gliedern:

Top-Down

Bei der sogenannten Daumen * Pi-Schätzung überlegt sich der Schätzer grob die wichtigsten Schritte des zu erstellenden Projekts bzw. seiner Teile, wie Analyse, Design, Codierung und Test. Ohne die innere Struktur der Funktionalitäten zu kennen, trifft er aufgrund von Erfahrung und Intuition Annahmen für das zu entwickelnde System, einzelne Funktionen oder den jeweiligen Entwicklungsschritt. Die Festlegung von Größenordnungen ohne entsprechende Erfahrungswerte ist meist gänzlich aus der Luft gegriffen. Da sich diese Form der Expertenschätzung meist am einfachsten organisieren lässt, ist dieser Ansatz sehr verbreitet. Ebenso kommt die Top-Down-Methode zum Überprüfen von Resultaten anderer Vorgehensweisen zum Einsatz und unterstützt durch die Vogelperspektive, den Blick für das Ganze zu bewahren.

Analogieverfahren ziehen Zahlen von vergleichbaren IT-Vorhaben bzw. Komponenten der Vergangenheit heran, um Schätzungen für aktuelle Sachverhalte abzuleiten. Auf diese Weise kann in einem stabilen Umfeld häufig mit relativ geringem Aufwand eine stimmige Größenordnung erhoben werden. Alternativ ist die Ablage und Pflege der Schätzinformationen in einer Erfahrungsdatenbank möglich, wobei dieser Zugang mit wesentlich größerem Aufwand verbunden ist und meist die Ressourcen von kleinen und mittelständischen Unternehmen sprengt. Gleichzeitig kann eine solche Sammlung von Daten als Dokumentation für die Schätzungen des aktuellen Projekts dienen. Sollten keine direkt vergleichbaren Projekte oder Aktivitäten zur Verfügung stehen, können Teilaspekte im Prozess, in den Inhalten der Aufgabenstellungen oder in ähnlich gelagerten Projekten am Markt herangezogen werden. Zu berücksichtigen ist dabei, dass die entsprechenden Grundlagendaten für eine Schätzung vorliegen bzw. die wesentlichen Unterscheidungsmerkmale ebenso einbezogen werden müssen. Vergangene Werte sollten niemals blind 1:1 übernommen werden. Analogieschätzungen können bereits ermittelte Aussagen zu Aufwänden untermauern, weshalb sie für den Gegencheck der Ergebnisse anderer Techniken geeignet sind.

Bottom-Up

Im Vergleich zum Top-down-Zugang ist das Bottom-up-Verfahren wesentlich aufwendiger, bei gewissenhafter Durchführung aber auch um einiges präziser. Auf der Grundlage der jeweiligen Anforderungen bzw. der Detailplanung des Projekts werden alle Einzelteile bewertet. Für jeden Arbeitsschritt ist festzuhalten, wie hoch der Aufwand für dessen Erledigung ist bzw. wann welche Ressourcen dafür zur Verfügung stehen. Im besten Fall werden dabei schon Einschränkungen, in Bezug auf Personal z.B. Feiertage, Ferien, Krankenstände, einbezogen. Bei größeren Projekten erfordert ein solcher Detaillierungsgrad die Unterstützung durch ein Tool bzw. muss gut abgewogen werden, wann sich dieser Ansatz überhaupt rechnet. Da auch die Verantwortlichen für die einzelnen Arbeitsschritte in das Schätzverfahren eingebunden sind, erweist es sich als umfangreich und zeitintensiv. Um im möglichen Verhandlungspoker sicher zu sein, planen viele Experten zudem Reserven ein, weshalb der Umgang mit Puffern vorher geklärt sein muss bzw. die jeweiligen Schätzungen zu hinterfragen sind. Statistisch gesehen gleichen sich die üblichen Abweichungen der einzelnen Aufwandsschätzungen aus und liefern so ein brauchbares Ergebnis. Trotz der Bandbreite und Subjektivität sind Bottom-Up-Techniken substanziell, weil die Prognose auf fachlicher Diskussion und Präzisierung der einzelnen Anforderungen und/oder Arbeitsschritte beruht.

Mit dem Delphi-Verfahren wird eine systematische, mehrstufige Befragungstechnik mit Rückkopplung bezeichnet. Es handelt sich dabei um eine Expertenbefragung, in der mehrere Wissensträger auf der Grundlage der geplanten Arbeitsschritte oder Systemteile gemeinsam schätzen. Die erste Prognose wird ohne Diskussion verdeckt abgegeben, um unterschiedliche Sichtweisen zu erhalten und dadurch die Qualität des Resultats zu erhöhen. Nach der Zusammenfassung und Auswertung der Ergebnisse werden diese bei großen Unterschieden bzw. einzelnen Ausreißern diskutiert. Im besten Fall führt dies zu bisher unbedachten, eventuell sogar weniger aufwändigen Varianten. Nach dem Austausch kommt es zu einer erneuten Expertenbewertung. Es folgt eine Wiederholung dieses Ablaufs, in der Praxis selten mehr als zwei bis drei Runden, bis ein Konsens erreicht ist. Die Genauigkeit dieser Schätzungen ist erheblich höher als bei individuellen Prognosen, wenn die richtigen Personen einbezogen sind, und es können zudem alternative Lösungsansätze entstehen. Der Aufwand für dieses Verfahren multipliziert sich aufgrund der höheren Anzahl an Personen ebenso.

Die Drei-Punkt-Schätzung, auch PERT (Program Evaluation and Review Technique) genannt, berücksichtigt neben dem realistisch prognostizierten Aufwand für einen Arbeitsschritt eine optimistische (Best Case) und pessimistische Kennzahl (Worst Case). Nach deren Ermittlung werden sie gewichtet mit Hilfe von Funktionen der Wahrscheinlichkeitsrechnung miteinander in Relation gesetzt. Mit einer 50%igen Wahrscheinlichkeit liegt die kalkulierte Zahl, der sogenannte Erwartungswert, unter bzw. über dem zu erwartenden Aufwand. Der mathematische Zugang erhöht die Treffergenauigkeit der Prognose und erlaubt in der Kommunikation der Stakeholder das Beleuchten der Ungewissheiten und Aufwandstreiber.

Das vor allem in der agilen Herangehensweise beliebte Planning Poker ist ein effektives Verfahren zur relativen Aufwandsschätzung von User Storys in Teams. Die Komplexität einzelner Backlog-Items wird mithilfe einer vereinbarten Referenzgröße relativ zueinander in Bezug gesetzt. Das Fachwissen der einzelnen, im Idealfall möglichst heterogenen Personen wird verwendet, um einen Sachverhalt aus verschiedenen Blickwinkeln, Hintergründen und im Mehr-Augen-Prinzip zu bewerten. Es handelt sich um eine Expertenschätzung mit Konsensbildung unter den Teilnehmenden, d.h., Zweifel müssen dementsprechend ausgeräumt werden. Vorteile dieses Verfahrens sind das einfache Setup, das auch in verteilten Teams (z.B.: via Videokonferenz) eingesetzt werden kann, die Stärkung der Identifikation der Teilnehmenden mit den Requirements sowie die verschiedenen Perspektiven, die in der Schätzung berücksichtigt werden. Da die Schätzungsergebnisse abstrakte Einheiten sind, müssen sie für die Verwendung in der Kosten-, Zeit- und Risikoplanung umgerechnet werden. Diese Methode ist auch nur für die ideale Teamgröße, zwischen fünf und neun Personen, sinnvoll verwendbar. Zudem kann die Schätzung ohne ein entsprechendes fachliches Knowhow der Teammitglieder spekulativ werden.

Algorithmische Modelle

Mit Unterstützung von mathematischen Formeln kalkulieren algorithmische Techniken die Aufwände, in dem sie Relationen zwischen allen relevanten Einflussparametern erstellen. Die bekannteste Methode ist das COCOMO (COnstructive COst MOdel), das unter anderem verschiedene Softwaremetriken, z.B. der Anteil des wieder verwendbaren Programmcodes, bzw. die Erfahrung der beteiligten Personen einbezieht. Je nach Unternehmen können spezifische Faktoren in die zentrale Projektdatenbank aufgenommen und angepasst werden, damit sie in die Aufwandsschätzung einfließen. Aufgrund der vielen berücksichtigten Parameter sind sehr genaue Schätzungen möglich, allerdings hängt das Resultat wie bei allen Herangehensweisen von den eingegebenen Daten und der vorgenommenen Gewichtung ab. Das Vorhandensein vieler Stellschrauben erhöht durchaus die Komplexität und macht das Erreichen eines Ergebnisses nicht notwendigerweise einfacher. Dementsprechend erfordert das COCOMO mehr Aufwand in der Verwendung und eignet sich eher für große Projekte.

Mischformen

Das Function Point-Verfahren kombiniert die algorithmische Herangehensweise und die Analogieschätzung. Zuerst wird die Komplexität des zu entwickelnden Systems bzw. seiner Teile ermittelt, wobei Anforderungen und Arbeitsschritte in kleinste, aus der Anwenderperspektive sinnvolle Teile, die sogenannten Elementarprozesse, zerlegt und auf Grundlage vergleichbarer Elemente bzw. Komponenten bewertet werden. Dafür müssen wie bei allen Bottom-up-Techniken die Funktionalitäten des Systems bereits ausreichend bekannt sein. Das Ergebnis sind Function Points, eine abstrakte Messgröße. Um diese in Projektplänen einzusetzen, ist eine Umrechnung in betriebswirtschaftliche Kennzahlen notwendig.

Die Schätzung mit Story-Points erfreut sich aufgrund der Ausbreitung agiler Kontexte in den letzten Jahren immer größerer Beliebtheit. Dabei wird in Teams die Komplexität einzelner Anforderungen im Verhältnis zueinander bewertet. Da die dabei entstehende Messgröße eine ausschließlich teaminterne und dementsprechend nicht neutrale ist, lassen sich die Werte von verschiedenen Teams nicht miteinander vergleichen. Innerhalb eines eingespielten Teams können die Beteiligten Story Points meist recht treffend schätzen, für Außenstehende ist der jeweilige Basiswert sowie das Knowhow und die Erfahrungen des Teams, die zum Ergebnis führen, häufig nicht nachvollziehbar. Die Umrechnung in für Projektpläne verwertbare Kenngrößen gestaltet sich schwierig. Es empfiehlt sich für die Veranschaulichung des Projektfortschritts mit Burn-Down-Charts zu arbeiten.

Je nachdem wie Schätzverfahren eingesetzt werden, liefern sie gute oder schlechte Ergebnisse. Entscheidend ist als Requirements Engineer, die individuell passenden Verfahren zu nutzen, die im Idealfall auch im Unternehmen anerkannt und erprobt sind. Für ein qualitativ hochwertiges Resultat empfiehlt es sich, verschiedene Techniken miteinander zu kombinieren. Das unterstützt auch bei der Überzeugung von Stakeholdern, da eine Argumentation aus mehreren Perspektiven eher akzeptiert wird. Wichtig ist es, das Schätzverfahren an die Größe des ausführenden Unternehmens bzw. des jeweiligen Projekts anzupassen, um nicht unnötig Zeit und Ressourcen mit zu aufwendigen Techniken zu vergeuden oder eine der Komplexität des Projekts nicht angemessene Herangehensweise zu wählen. Mit einem systematischen Zugang und konsequentem Verhalten gelingt es, Licht in die Ungewissheit der Zukunft zu bringen und das Projekt zum Erfolg zu steuern. Regelmäßige Aufwandsschätzungen schaffen nicht nur beim Eintreten von Veränderungen ein aussichtsreiches, gut planbares Projekt.