Schätzungen mit Use Case Points

A-Faktor	x	TC-Faktor	x	M-Faktor	=	Use Case Punkte	x	Stunden/UCP	=	Aufwand (Std.)
	x		x		=		x		=

A-Faktor

TC-Faktor

M-Faktor

Use Cases und Aktoren

	Use Case	Komplexität	+	Aktor	Typ	Gewicht	=	Summe
A-Faktor (Summe):
		hoch mittel einfach	+			hoch mittel einfach	=
		hoch mittel einfach	+			hoch mittel einfach	=
		hoch mittel einfach	+			hoch mittel einfach	=

Technischer Komplexitäts-Faktor

Technischer Faktor	Bewertung (M)	Gewicht (W)	M x W
Technischer Faktor (Summe):
Technischer Komplexitäts-Faktor (0.6 + (0.01 * T-Faktor)):
Verteiltes System
Performance
Effiziente Benutzeroberfläche
Komplexe Berechnungen / interne Prozesse
Wiederverwendbarkeit
Einfache Installation
Einfach zu bedienen
Plattformunabhängigkeit
Einfach anpassbar
Nebenläufigkeit
Spezielle Sicherheitsfunktionen
Schnittstellen
Spezielle Anwenderschulung

Management-Faktor

Kostenfaktor Bewertung (M) Gewicht (W) 1 + 0.1 x W x (3 - M) M-Faktor (Multiplikation aller Teilfaktoren): Leistung/Fähigkeit Chefdesigner 0 - unerfahren 3 - erfahren 5 - sehr erfahren Zusammenarbeit 0 - schlecht 3 - gut 5 - sehr gut Kontinuität Mitarbeiter 0 - mehr als 50 % 3 - 10% - 50% 5 - bis 10 % Qualität der Grobspezifikation und der Techn. Architektur 0 - gering 3 - mittel 5 - hoch Prozess-Overhead 0 - komplex 3 - normal 5 - schlank Termindruck 0 - weniger als 80% 3 - 80% - 100% 5 - 100% Stabile Anforderungen 0 - hoch 3 - normal 5 - quasi null Anzahl Entscheidungsträger 0 - mehr als 15 3 - 6 bis 15 5 - bis 6 Integrationsabhängigkeit 0 - mehr als 12 3 - 4 bis 12 5 - bis 4

Leistung/Fähigkeit Chefdesigner: Wie erfahren sind der technische und fachliche Chefdesigner hinsichtlich Aufgabe und Fachlichkeit bzw. Technik?   Zusammenarbeit: Wie gut funktioniert die Zusammenarbeit im gesamten Projekt-Team (Lieferant, Kunde und Dritte incl. Sublieferanten und Dienstleister des Kunden). Bewerte das Verständnis für Prozesse, die Leistungsfähigkeit der Zusammenarbeit und die gemeinsamen Ziele. Die genannten Punkte funktionieren...   Kontinuität Mitarbeiter: Wie hoch ist die Kontinuität der Mitarbeiter im Projekt? Gibt es Reibungsverluste durch den Wechsel von Mitarbeitern in Teilprojekten? Wieviel Prozent der Mitarbeiter kündigen/wechseln pro Jahr aus dem Projekt heraus?   Qualität der Grobspezifikation und der Techn. Architektur: Wie nachvollziehbar und detailliert ist die Grobspezifikation, und wie gut sind Risiken bekannt? Ist die Qualität ... gering (Spezifikation enthält Widersprüche, zahlreiche offene Punkte, Risikoanalyse fehlt, Techn. Architektur muss erarbeitet werden) mittel (einige offene Punkte, Risiken existieren, Techn. Architektur ist weitestgehend bekannt) hoch (nur sehr wenige offene Punkte, keine Risiken nach Analyse, Techn. Architektur existiert)?   Prozess-Overhead: Ist der Entwicklungsprozess komplex (sehr formales Vorgehen und Prozesse, hohe Abstimmungs- und QuerschnittsAufwende, alle Querschnittsrollen besetzt; typisch für Großprojekt mit mehr als 40 Mitarbeitern), normal (mit durchschnittlichen QuerschnittsAufwenden; typisch für mittelgroßes Projekt, aber auch für kleine Projekte mit entsprechend formalen Anforderungen des Kunden) oder schlank (pragmatisches Vorgehen, wenig Dokumentation, keine formalen Reviews oder Abnahmen, niedrige QuerschnittsAufwende; typisch für kleines Projekt mit max. fünf Mitarbeitern) einzustufen?   Termindruck: Die optimale Projektlaufzeit wird mit 100 % angesetzt. Wie viel Zeit gesteht uns der Kunde zu?   Stabile Anforderungen: Wie nachvollziehbar und detailliert ist die Grobspezifikation, und wie gut sind Risiken bekannt? Wie hoch ist die Änderungsrate? Anzahl Entscheidungsträger: Wie viele IT- und fachliche Ansprechpartner (=Entscheidungsträger) des Kunden sind involviert, die koordiniert werden müssen? Es sind ggf. auch externe Dienstleister mitzuzählen, die vom Kunden beauftragt wurden. Integrationsabhängigkeit: Wie viele Abhängigkeiten von oder zu Schnittstellen bestehen, die aktiv gemanagt werden oder neu aufgesetzt werden müssen?

Im Informatik Spektrum Volume 31, Number 6 / Dezember 2008 wurde ein Artikel zur Aufwandsschätzung von Software-Entwicklungsprojekten für Individual-Software veröffentlicht (Seiten 566 bis 575). Der Autor war Stephan Frohnhoff von (mittlerweile) Capgemini, ehemals SD&M.

Die dort vorgestellte Methode hat mich sehr interessiert. Da ich allerdings zu faul war, für eigene Projekte jedesmal von Hand die Formeln anzugeben, hab ich mir dieses Formular zusammengezimmert, um mal eben schnell eine eigene oder fremde Schätzung zu validieren.

Erläuterungen zu den einzelnen Funktionen und Begriffen gebe ich keine, dazu soll entweder der oben genannte Artikel herhalten, oder die mittlerweile erschienene Doktorarbeit von Stephan Frohnhoff. Bei Capgemini gibt es im Bereich Publikationen etc. weitere Präsentationen und Beiträge.