Kostenmanagement in Projekten

Das plangesteuerte Projektmanagement kennt innerhalb der Unternehmens- und IT-Entwicklung unterschiedliche Methoden zur Kostenschätzung. Auf folgende Methoden wird in den nachfolgenden Abschnitten näher eingegangen:

• Ziel & Aktivitäten des Kostenmanagements
• Kostenvorhersage
• Ansätze zur Kostenvorhersage
• Algorithmische Kostenmodellierung
• Konstruktive Kostenmodellierung (COCOMO Constructive Cost Modeling)
• Kostenvorhersage

Sicherstellen, dass das Projekt im Rahmen des Budgets abgeschlossen wird.

Aktivitäten zum Kostenmanagement: 

• Planung des Kostenmanagements
• Schätzung der Kosten
• Festlegen des Budgets
• Kontrolle der Kosten

Die wichtigsten Kosten für ein Softwareentwicklungsprojekt: 

• Effort Costs, d.h.
  • Gehälter von Consultants, Solution Managern, Entwickeln .. etc. und
  • organisatorische Gemeinkosten (z.B. Büroräume, Verwaltung)
• Hardware- und Softwarekosten, einschließlich Hardware-Wartung und Software-Support
• Reise- und Schulungskosten

Diese Arte von Schätzung ist immer nur eine probabilistische Aussage, d.h. eine Aussage mit einer bestimmten Wahrscheinlichkeit.

• Erfahrungsbasierte Techniken, wie Intervall- und Konfidenzniveau-Schätzungen (Soll-Ist-Abweichung der Schätzung)
• 3-Punkte-Schätzung auf der Grundlage der Methode des kritischen Pfades (PERT-Diagramm): bester Fall, schlimmster Fall, wahrscheinlichster Fall
• Top-Down- oder Dekompositionsansatz: leichtere Schätzung der Kosten für kleine Aufgaben
• Formale algorithmische Modelle, wie z.B. COCOMO II, erfordern eine Anpassung und Kalibrierung an die lokale Umgebung

• Schätzungen (z.B. der Komplexität von angeforderten Funktionalitäten) sind in den frühen Phasen des Projekts meist ungenau. Es ist praktisch unmöglich, die Aufwände im Projekt korrekt zu schätzen. Ansätze, die sich an Anwendungsbereich oder Erfahrungswerte orientieren sind einfacher, aber in der Regel immer noch ungenau.
• Zudem sind Schätzungen häufig subjektiv.
• Daher müssen Schätzungen, in einem zweiten Schritt über eigene Schätzaktivitäten vor den Ausführungsaktivitäten durch Entwickler, bzw. Solution Manager erfolgen.
• Somit sind Modelle, wie die nachfolgend aufgeführten konstruktiven Kostenmodellierungen regelbasierte Ansätze, die von Schätzung zu Schätzung genauer werden, aber niemals eine Schätzung der Umsetzung konkreter Aufgaben ersetzen können (= Grenzen erzwungener Plansteuerung).

Erstellen Sie Schätzungen der Softwareentwicklungskosten:

Beispielhafte mathematische Formel:

• Effort = A * Size ^B * M (Aufwand = A – Größe ^ B * M)

Notation:

• A: konstanter Faktor, der von den lokalen Organisationspraktiken abhängt
• Size (Größe): Schätzung der Größe des Softwarecodes oder der Funktionalität (in Funktions-/Anwendungspunkten)
• B: Komplexität der Software (normalerweise zwischen 1 und 1,5)
• M: Faktor zur Berücksichtigung von Prozess-, Produkt- und Entwicklungsattributen, wie z.B. Anforderungen an die Zuverlässigkeit oder Erfahrung des Entwicklungsteams 
  

Zur Bestimmung des Faktors Size wird meist die Number Line of Source Code (SLOC), d.h. die Anzahl der Quellcodezeilen zur Bereitstellung der Funktionalität verwendet.

COCOMO (Constructive Cost Modeling) II Modell:

• ist ein empirisches Modell, das anhand von Daten aus einer großen Anzahl von Softwareprojekten unterschiedlicher Größe abgeleitet wurde

COCOMO II Submodels:

• Application composition model (Modell der Anwendungszusammensetzung)
  • Estimate based on (Schätzung basiert auf): Anzahl der Anwendungspunkte (number of application points – NAP)
  • Application (Anwendung): Mit dynamic languages (dynamischen Sprachen) entwickelte Systeme, Datenbankprogrammierung
    
  • Kosten für das Modell der Anwendungszusammensetzung:
  • PM = (NAP * (1 – &reuse / 100)) / PROD
  • Notation:
    • PM: Aufwandsschätzung in Personenmonaten
    • NAP: Gesamtzahl der Anwendungspunkte im neuen System
    • %reuse: Schätzung des Anteils wiederverwendeten Codes in der Entwicklung
    • PROD: Produktivität der Anwendungspunkte {NAP/Monat)
      
  • NAP ergibt sich aus der Anzahl der angezeigten Bildschirme oder Webseiten, der erstellten Berichte und der Module / Codezeilen

• Early design model (Modell des frühen Entwurfs)
  • Estimate based on (Schätzung basiert auf): Anzahl der Funktionspunkte
  • Application (Anwendung): Anfängliche Aufwandsabschätzung auf der Grundlage der Systemanforderungen und Designoptionen
  • Die Größe wird in KSLOC (Tausend SLOC) ausgedrückt
  • Funktionspunkte werden anhand von Tabellen in Codezeilen umgewandelt.
  • M wird durch sieben Projekt- und Prozessattribute ausgedrückt. 
    
• Reuse model (Modell der Wiederverwendung)
  • Estimate based on (Schätzung basiert auf): Anzahl der wiederverwendeten oder generierten  Zeilen
  • Application (Anwendung): Code Aufwand für die Integration wiederverwendbarer Komponenten oder automatisch generierten Codes
  • Die Größe wird durch ESLOC (equivalent number of lines of new code) ausgedrückt, die sich aus neuem Code und dem Aufwand für die Wiederverwendung und Integration von bestehendem Code zusammensetzt 

• Post-architecture model
  • Estimate based on (Schätzung basiert auf): Anzahl der Codezeilen
  • Application (Anwendung): Entwicklungsaufwand basierend auf der Spezifikation des Systemdesigns
  • Die Größe wird durch die Gesamtgröße des Codes ausgedrückt (Summe aus SLOC, ESLOC und Anzahl der neuen Zeilen, die geändert werden können) 

• Die Kosten für die Modelle Early Design, Reuse und Post-Architecture basieren auf der Gleichung: Effort = A * Size ^B * M (Aufwand = A – Größe ^ B * M)

Praktische Empfehlungen zur Verbesserung von Schätzungen:

• Datenbasiert
  erfordert historische Daten aus früheren Projekten
• Sensitivitätsanalyse
  wird in der Regel nicht verwendet, kann aber bei Unsicherheiten helfen
• Mehrere Techniken
  Mindestens zwei Techniken verwenden zur gegenseitigen Validierung und Gewichtung
• Gruppenschätzungen
  Aufwand durch eine Gruppe von Personen schätzen lassen und Gruppenmitglieder bitten, ihre Schätzung zu erläutern (z.B. Planning Poker)
• Training und Reflexion
  Schätzfehler reflektieren, dies bedeutet die Schätzung mit dem Ergebnis abgleichen (Soll- Ist-Abweichungsanalyse)
• Schätzung und Vertrauen
  Sich bewusst sein, dass eine Schätzung immer auch Vertrauen erfordert