PM

-    Expertenschätzungen
-    Analogieschätzungen und Prozentsatzmethode
-    Modellbasierte Schätzungen

-    Nicht zu 100% einem Experten vertrauen, mehrere einholen
-    Schätzt den Aufwand auf Basis der Aufgabenbeschreibung und seiner Erfahrung

Vorteile

-    Einfaches Verfahren
-    Schnell, kein Rechenaufwand

Nachteile

-    Hohe Subjektivität
-    Große Schätz-Unsicherheit
-    Keine Transparenz des Schätzprozesses

Mehrfachbefragung

-    Mehrere Schätzer möglichst aus unterschiedlichen organisatorischen Bereichen
-    Mittelwert bilden oder Konsens suchen

Delphi-Schätztechnik

-    Formalisierte, schriftliche Befragung mehrerer Experten
-    Zwei oder mehr Befragungsrunden

Schätz-Sitzung

-    Übertragung des Delphi-Prinzips auf eine Sitzung
-    Teilnehmer
o    Projektleiter, Moderator, Protokollant
o    Mehrere Kostenschätzer (50% projektfremd)
-    Unterlagen
o    Projektzieldefinition
o    Produkt-/Projektstrukturplan und Arbeitspaketbeschreibungen
o    Projektrandbedingungen

-    Vergleich des zu schätzenden Projekts mit einem oder mehreren bereits abgeschlossenen, ähnlichen Projekten
-    Unterschiede in Aufgabenstellung und Realisierungsbedingungen werden vom Schätzer aufgrund seiner Erfahrung angepasst
-    Vorteile
o    Schätzung in sehr frühen Projektstadien
o    Aufwand aus tatsächlichen Ist-Werten
o    Schätzungen sowohl auf Gesamtprojekt- als auch Subsystemebene
-    Probleme
o    Schwierige Beurteilung der Repräsentativität der Analogieprojekte

-    Aus früheren Projekten ermitteln, wie sich Aufwand und Projektzeit prozentual auf die einzelnen Projektphasen verteilen
-    Voraussetzung: einheitliches Vorgehensmodell
-    Bei Folgeprojekten: Top-Down Schätzung des Aufwands in den Phasen

Zwei Varianten für Bottom-Up Schätzung:

-    Eine oder mehrere Projektphasen abschließen und deren Ist-Aufwand prozentual als Soll für restlichen Phasen hochrechnen (insbesondere für Systemtest und Einführungsphase)
-    Für eine Phase (Programmierung) eine detaillierte Mikroschätzung durchführen und aufs gesamte Projekt schließen

Zu Projektbeginn schlecht da hohes Fehlerrisiko bei Hochrechnung aus niedrigen Anfangswerten

Bild

Bild

Geschätzter Projektumfang: 50 KDSI
Tatsächlicher Aufwand der Analyse: 8,75 PM

Gesamtaufwand zurückgerechnet aus Aufwand der Anforderungsanalyse:

6% = 8,75 PM -> 100 % = 8,75 PM * (100/6) = 145,9 PM

Geschätzter Aufwand der Realisierung: 62 % von 145,9 PM = 90,2 PM

Vorteile: einfach, leicht anpassbar, früh einsetzbar

Nachteile: 

-    Sehr grob
-    Projektspezifische Einflussfaktoren nicht berücksichtigt
-    Konkrete Projektaufgabe geht nicht in Schätzung ein
-    Verzögerungen in den ersten Phasen werden fortgeschrieben

Sollte eher in stabilem Umfeld eingesetzt werden mit guten Projekten, nicht geeignet bei neuen Projekte

Aufwandsschätzung anhand Work Breakdown Structure

-    Projekt anhand des Vorgehensmodells auf elementare Arbeitsschritte runterbrechen
-    Schätzung des Aufwands einzelner Schritte

Vorteile:

-    Einfach anzuwenden
-    Fördert Strukturierung des Projekts
-    Macht Abhängigkeiten deutlich
-    Gut mit Prozentsatzmethode kombinierbar

Nachteile

-    Berücksichtigt die Komplexität der Software nur indirekt
-    Zu Beginn nur grobe Schätzung
-    Verzögerungen in den ersten Phasen werden fortgeschrieben
-    Nur wenn man den eigenen Projektstand kennt

Function-Point

CoCoMo

Function-Point: Projektumfang bzw. Produktkomplexität

CoCoMo: Entwicklungszeit

-    Schätzung anhand von Kenngrößen der zu liefernden Funktionalität
-    Allein der Aufwand wird verglichen ohne auf den Inhalt einzugehen

1.    Ermittlung von Roh-Function-Points durch Bewertung von 5 Funktionskategorien
a.    Eingaben (EI, external inputs)
b.    Ausgaben (EO, external outputs)
c.    Anwendungsdaten (ILF, internal logical files)
d.    Schnittstellen (EIF, external interface files)
e.    Externe Abfragen (EQ, external queries)
2.    Bewertung der System-Infrastruktur (SI)
a.    Netzwerk/Kommunikation
b.    Hostleistung/belastung
c.    Verarbeitungslogik
3.    Gewichtung der FP mit SI-Bewertung
4.    Umsetzung der FP in Aufwand (PM oder LOC)

-    Relevante Funktionskategorien der Komponenten identifizieren (Eingaben, Ausgaben...)
-    Komponentenweise Zuordnung der Funktionskategorien zu Komplexitätsklassen
-    Zuordnung der Bewertungszahl = Anzahl der RPFs
-    Summation der RPFs

Kat Eingaben:

-    Benutzereingaben
-    Dateien
-    Scanner

Kat Ausgaben:

-    Bildschirm
-    Drucker

Kat Anwendungsdaten

-    Externe Datenbestände, Dateien, Datenbanken, die von der Anwendung erzeugt, gelesen, modifiziert, gelöscht werden

Kat externe Abfragen

-    Benutzerdefinierte Abfragen an externe Datenbanken
-    Keine Datenänderungen

Kat Schnittstellen

-    Schnittstellen zu Fremdsystemen und read-only Dateien
-    Auch Netzwerkverbindungen

-    Ermittlung der RFP
-    Bewertung der SI (Summe der 14 Faktoren zw. 0 und 70)
-    Berechnung der FP mit Formel (FP = Summe RFP * (0,65 + (0,01 * Summe SI))
-    Berechnung der PM = 0,0136 * (FP)^1,308 (Erfahrungsformel, 200 Tage im Jahr, 20 Personentage/Monat)

Vorteile:

-    Sehr gut ausgearbeitet
-    Durch verschiedene Stufen einsetzbar
-    Individuelle Anpassungen
-    Basiert auf Funktionalität, nicht Programmumfang
-    Leicht anwendbar

Nachteile

-    Einfluss von Rahmenbedingungen unterbewertet
-    Individuelle Anpassung notwendig

Bild

Bild

Output/Zeiteinheit, z.B. Artikel/Zeitstunde

Erfahrungswert: 350 LOC / PM (2,3 LOC / h)

Output / geleistete Stunden

-    Algorithmisches Schätzmodell
-    Basis der Zeitschätzung: KDSI (kilo delivered source instructions)
o    Vorher KDSI über FPA schätzen
-    CoCoMo Basismodell ergibt Projektaufwand in PM
-    Formel: PM = 2,4 * (KDSI)^1,05
-    Daraus: optimale Projektdauer in Kalendermonaten TDEV = 2,5 * (PM)^0,38

-    Aufwand in Mannmonate
-    Projektdauer
-    Personaleinsatz (Output)
Problem:
-    Aufwand und Dauer verteilen sich nicht zu gleichen Prozenten auf Projektphasen

-    Zusätzliche Parameter (Produkt-Merkmale, Computer-Merkmale, Personal-Merkmale)
-    Schätzung auf Komponentenebene

Einordnung

-    Gute Hilfen zur Schätzung einzelner Parameter
-    Unterschiedliche Multiplikatoren für verschiedene Komponenten
-    Schätzung des Wartungsaufwands
-    Anpassung von Gleichungen und Multiplikatoren an individuelle Gegebenheiten

Erweiterungen

-    Berücksichtigung der Parameter nach Hierarchiestufen
o    Modul (Qualifikation und Erfahrung der Programmierer)
o    Subsysteme (Zeit und Speicherbeschränkungen)
o    System (Programmiermethoden)
-    Aufwandsmultiplikatoren je nach Phasenaufwand

Parameter

-    Erfahrung mit ähnlichen Projekten (PREC)
-    Einfluss des Kunden auf Entwicklungsprozess (FLEX)
-    Kompetenzen im Bereich des Architekturentwurfs (RESL)
-    Stabilität des Entwicklerteams (TEAM)
-    Einstufen des Entwicklungsprozesses (PMAT)

-    Vorteile
o    Sehr gut ausgearbeitet
o    In verschiedenen Stufen anwendbar
o    Diverse Analysen
o    Individuelle Anpassungen
-    Nachteile
o    Basisschätzung der LDSI problematisch
o    Programmiersprache nicht berücksichtigt
o    Individuelle Anpassung notwendig

unangenehmer Sachverhalt, der eventuell eintreten kann (entgangener Gewinn, zusätzliche Kosten)

Projekte ohne Risiken lohnen nicht (kein Gewinn)

-    Risiko ist Problem das eventuell eintreten kann (entgangener Gewinn, zusätzliche Kosten)
-    Projekte ohne Risiko lohnen nicht (kein Gewinn)
-    Teamorientierte Präventivmethode zur periodischen Bewertung von Produkten, Prozessen
-    Listet mögliche und denkbare Probleme in Projekten auf
-    Bewertet Auftretenswahrscheinlichkeit, Entdeckungswahrscheinlichkeit und Auswirkung auf Projekterfolg -> Risikoprioritätszahl (RPZ)
-    Geeignete Gegenmaßnahmen verringern RPZ
-    Je früher ein Problem erkannt wird, desto größer der Nutzen

-    Priorisierte Risikoliste
-    Vorsichts- und Korrekturmaßnahmen
-    Stetige Verbesserungsmaßnahmen

-    Experten einzelner Gebiete, die am besten über das Produkt Bescheid wissen

-    Mensch, Maschine, Material, Methode, Milieu, Medien <= Probleme

-    Abschätzen des Gesamtrisikos einer möglichen Problemursache mit RPZ
o    Auftrittswahrsch. * Folgen * Wahrsch. der Problementdeckung
-    Wert zw. 1 und 1000
-    Reihung der Probleme nach RPZ (Rangfolge für Beseitigung)
-    Hohe RPZ müssen zuerst behandelt werden

-    Maßnahmen ermitteln, welche die Auftrittswahrsch. der Problemursachen oder Höhe der Folgekosten senken

- RPZ gibt Reihenfolge der Bearbeitung vor

- vier Arten von Maßnahmen:

-    Risikovermeidung (Projektstop)
-    Risikominderung (technische Maßnahmen)
-    Risikoabwälzung (Vertragsgestaltung)
-    Risiko eingehen (Selbstbehalte)

-    Erneute Bewertung des Risikos jeder Problemursache nach Treffen der Maßnahmen
-    Neue RPZ als Restrisiko
-    Beurteilung ob Maßnahmen erfolgreich waren
-    Top 10