Software-Schätzung und -Planung

Software-Schätzung und -Planung prognostizieren den Aufwand, die Kosten, den Zeitplan und die Ressourcen, die ein Softwareprojekt erfordert, und organisieren die Arbeit, um es innerhalb dieser Beschränkungen zu liefern.

Definition

Software-Schätzung ist die Vorhersage des Aufwands, der Dauer und der Kosten, die für die Entwicklung oder Wartung von Software erforderlich sind, und Planung ist die Organisation von Aktivitäten, Meilensteinen und Ressourcen, um Projektziele innerhalb dieser Schätzungen zu erreichen.

Scope

Dieses Thema behandelt Größenmaße wie Codezeilen und Funktionspunkte; algorithmische Kostenmodelle wie COCOMO; Schätzung durch Expertenurteil, Analogie und Planning Poker; Arbeitszerlegungs- und Zeitplanungstechniken einschließlich kritischem Pfad und Burndown; agile Planung mit Velocity und Story Points; sowie den Umgang mit Schätzunsicherheit durch Bereiche und den Cone of Uncertainty.

Core questions

• Wie wird die Größe von Software gemessen, um Schätzungen zu erstellen?
• Wie vergleichen sich algorithmische, Analogie- und Expertenurteilmethoden?
• Wie wird Unsicherheit im Projektverlauf dargestellt und reduziert?
• Wie unterscheidet sich agile Planung mit Velocity von der vorausschauenden Zeitplanung?

Key theories

Algorithmische Kostenmodelle

Modelle wie COCOMO drücken Aufwand und Zeitplan als kalibrierte Funktionen der geschätzten Größe und der Projektkostentreiber aus, was wiederholbare Schätzungen ermöglicht, die mit historischen Daten angepasst werden können.

Funktionspunkt-Größenbestimmung

Die Funktionspunktanalyse bemisst Software durch Zählen und Gewichten ihrer funktionalen Komponenten unabhängig von der Implementierungssprache und liefert so eine technologieneutrale Größenangabe für die Schätzung.

Clinical relevance

Realistische Schätzung und Planung untermauern Zusagen an Stakeholder und Ressourcenentscheidungen; chronische Unterschätzung führt zu den Zeit- und Budgetüberschreitungen, die Softwareprojekte plagen, daher sind disziplinierte Methoden und explizite Unsicherheit unerlässlich.

Evidence & guidelines

Empirische Forschung zur Schätzgenauigkeit und Modelle wie COCOMO II liefern evidenzbasierte Leitlinien, und die Funktionspunktzählung wird durch IFPUG- und ISO/IEC-Standards zur funktionalen Größenmessung geregelt.

History

Funktionspunkte wurden Ende der 1970er Jahre von Albrecht und COCOMO 1981 von Boehm eingeführt, was der Schätzung eine quantitative Grundlage verlieh; nachfolgende Arbeiten verfeinerten Modelle (COCOMO II), untersuchten Schätzverzerrungen und führten leichtgewichtige Methoden zur relativen Größenbestimmung für die agile Planung ein.

Debates

Schätzung versus die No-Estimates-Bewegung

Einige agile Praktiker argumentieren, dass detaillierte Schätzungen Aufwand verschwenden und dass kleine, stetige Lieferungen Prognosen zuverlässiger machen als Schätzungen, während andere behaupten, dass Schätzungen für die Planung und Verpflichtung weiterhin notwendig sind; die Debatte hängt vom Kontext und den Bedürfnissen der Stakeholder ab.

Key figures

• Barry Boehm
• Allan Albrecht
• Steve McConnell

Seminal works

• boehm1981
• albrecht1983
• mcconnell2006

Frequently asked questions

Warum sind Software-Schätzungen so oft falsch?

Schätzungen werden gemacht, wenn am wenigsten bekannt ist, Anforderungen sich ändern und menschliche Voreingenommenheit zum Optimismus neigt; der Cone of Uncertainty zeigt, wie breit frühe Schätzungen unweigerlich sind, weshalb Bereiche und Neuschätzungen einzelnen festen Zahlen vorgezogen werden.

Sind Story Points nur getarnte Stunden?

Nein. Story Points drücken relative Größe und Komplexität aus, nicht absolute Zeit; in Kombination mit der beobachteten Velocity eines Teams ergeben sie Prognosen, aber die Gleichsetzung eines Punktes mit einer festen Anzahl von Stunden untergräbt ihren Zweck, den relativen Aufwand zu erfassen.