Lektion Projektplanung

Präsentation zum Thema: "Lektion Projektplanung"—  Präsentation transkript:

1 Lektion Projektplanung
Software Praktikum Lektion Projektplanung Ablauf (so wie tatsächlich passiert am ): 16:15-16:27 Vortrag 16:27-16:37 Einzelschätzung: Jeder Teilnehmer macht die Schätzaufgabe selber aufgrund von Beispiel und der Liste was bei der Schätzung herauskommen soll 16:37-16:42 Abfrage der Ergebnisse (Hand hoch wer unter 25PT liegt, 25-50, 50-100 16:42-16:55 Paarweise die Schätzung überarbeiten 16:55-17:25 die ganzen Prinzipien bis Prinzip 5 die Leute machen lassen und dann immer abfragen, wie viele etwas gefunden haben (z.B. eine Tätigkeit, die in ein Ergebnis umformuliert werden konnte) und dann fragen, dass einer ein solches Beispiel öffentlich nennt 17:25-17:40 Vortrag bis Ende Schätzung 17:40-17:52 Vortrag bis Folie „Tools“. Ende des Vortrages

2 Projektplanung Projektplanung = Aufwandsschätzung +
Erstellung Projektplan Kostenschätzung

3 Projektplanung Was Ergebnis Verantwortlich Aufwandsschätzung
PT (= Personentage) Entwickler & Projektleiter Erstellung Projektplan Dauer & Personalbedarf Projektleiter Kostenschätzung CHF Sales (= Vertrieb) Unser Fokus

4 Literatur Folien von heute: Detaillierte Erläuterungen: (3 Exempl. In IFI-Bibliothek)

5 Aufwandsschätzung Musterbeispiel Aufwandsschätzung
Erstellt eine Schätzung mit: Aufwandspunkte (in PT = 8Std) Besondere Risiken Mitwirkungen Kunde Ausschlüsse Besondere Sachkosten Offene Fragen

6 Aufwandsschätzung Wer hat offene Fragen an den Kunden?
Wer hat 0-20 / / / / / / 70++ PT?

7 Fehlerursachen Checkliste – häufig vergessene Aufwände: Einarbeitung
Installation von Softwareprodukten Projektplanung (insbesondere Updates der Schätzung und des Projektplans) Abstimmungen, Meetings Ausfälle (Mitarbeiter, Rechner, Software) Usability Maßnahmen und Tests bezüglich Ausfallsicherheit Zeit für Korrektur nach Tests Oberfläche zur Administration und Konfiguration Installationssoftware, Probeinstallation Konfigurationsmanagement und Probleme damit Probleme mit den eingesetzten Technologien, insbesondere weniger vertrauten Hilfefunktion Dokumentation der Software Wartung

8 Prinzipien Schätzung Prinzipien
Erste alleine schätzen, dann im Team (Nicht wer hat recht, sondern wer kann welche Ideen & Erkenntnisse einbringen!) Ergebnisse benennen (z.B. anstelle „Test“ besser: „Testanweisung“, „Testprotokoll“, „verbesserte Software“) Einheitliche Granularität der Aufwände Schnell abschließbare Aufgaben Frei von Erwartungen schätzen, dann Leistung gem. Aufwandserwartungen kürzen -> 40PT Aufgliederung: Use Cases Arbeitsablauf im Projekt SW-Struktur Funktional Multiplikativ

9 Prinzipien Schätzung Prinzipien
Keine großen Risiken – »Min-mid-max-Methode«  Einschränkungen & Voraussetzungen definieren oder Aufwandspunkt untergliedern »Murphy’s Law« – es wird tendenziell unterschätzt Beispiel für Umsetzung von Prinzip 6. und 7.: Erklärung min-mid-max: min = so schnell geht es, wenn alles glatt geht mid so lange dauert es in einem durchschnittlichen Fall (gemäß früherer Projekterfahrung) max so viel Aufwand kostet es »maximal«, d. h. in 90% aller Fälle sollte es innerhalb dieser Anzahl von PT fertig werden

10 Prinzipien Schätzung Faustregeln:
In kleinen und mittleren Projekten: ca. 1/3 Konzeption, 1/3 Implementierung, 1/3 Test & Verbesserung. (!) Bei Anwendungen mit speziellen Sicherheits- oder Verfügbarkeitsanforderungen, beispielsweise Internetbanking, kann der Testaufwand sehr viel höher ausfallen, bei Prototypen niedriger. Bei großen Projekten Konzeption > Summe von Implementierung, Test und Verbesserung Proportional zum Gesamtaufwand der Projektdurchführung: Unvollständigkeit der Schätzung: 10-20% Projektleitung: Bis Spezifikation 25%, nachher 20% Gewährleistung des Dienstleisters an den Kunden: 15% für 12 Monate

11 Schätzmethoden Verschiedene Methoden
Analogieschätzung: 1-2 grob vergleichbare Projekte Expertenschätzung Kennzahlmethoden CoCoMo Function Point Object Point ... Tabellen für Routineprojekte Praxisrelevant nur mit (viel) Vorbereitung Unser Fokus Praxisrelevant überall

12 Schätzmethoden Kjetil Moløkken and Magne Jørgensen: „A Review of Surveys on Software Effort Estimation“ Main findings were that: (1) Most projects (60-80%) encounter effort and/or schedule overruns. The overruns, however, seem to be lower than the overruns reported by some consultancy companies. For example, Standish Group’s ‘Chaos Report’ describes an average cost overrun of 89%, which is much higher than the average overruns found in other surveys, i.e., 30-40%. (2) The estimation methods in most frequent use are expert judgment-based. A possible reason for the frequent use of expert judgment is that there is no evidence that formal estimation models lead to more accurate estimates. Fazit: Projektmanagement ist ein entstehendes wissenschaftliches Forschungsgebiet, mit vielen offenen Fragen und Chancen

13 Projektplanung Was Ergebnis Verantwortlich Aufwandsschätzung
PT (= Personentage) Entwickler & Projektleiter Erstellung Projektplan Dauer & Personalbedarf Projektleiter Kostenschätzung CHF Sales (= Vertrieb) Unser Fokus

14 Unfertig: Namen nennen Besser wäre: Ergebnisse nennen
Projektplan Beispiel Projektplan: Unfertig: Namen nennen Dieser Projektplan war für eine grobe Terminabstimmung mit dem Kunden – nicht für die Terminplanung! Besser wäre: Ergebnisse nennen Wer entdeckt Fehler in dem Musterbeispiel? Konkret dafür tun: -> Personennamen -> Abhängigkeitspfeile -> Kritischer Pfad -> Meilensteine -> Beprechungen -> Liefertermine -> Ergebnisse (wenig Tätigkeiten!)

15 Detaillierter Projektplan
Detail-Projektplan zwecks Terminplanung und Arbeitszuteilung „Ergebnisse benennen“ am Beispiel eines Integrationstest: Usability-Test 30.3. Anna Funktionstest 30.3. Hannes Lasttest 30.3. Peter Wer entdeckt Fehler in dem Musterbeispiel? Fehlerbehebung 28.3. Beate, Axel, Beat 30.3. Fertige, getestete Software + Testberichte Praktischer Tipp: Da es hier missverständlich wäre, die Balken mit „Fehlermeldungen & Testbericht“ zu beschriften, erfolgt die Nennung der Ergebnisse beim Meilenstein.

16 Projektplan Definition: Kritischer Pfad
„Die Abfolge derjenigen aufeinander folgenden Tätigkeiten, welche beginnend beim Projektstart und endend bei Projektende die Dauer des Projekts bestimmen, werden als kritischer Pfad bezeichnet.“ Den kritischen Pfad hervorheben:

17 Tools Langjährige Industriestandards: Schätzung: Excel
Projektplan: MS-Project Download: Kunden erwarten einen Projektplan, der in MS-Project erstellt ist (oder so aussieht) Vorgehen: Schätzung in Excel fertigstellen Punkte in den Projektplan übertragen Abhängigkeiten festlegen und kritischen Pfad hervorheben  Detail-Projektplan für Terminbestimmung und Teamarbeit Hervorheben, was für Kunde & Besprechungen wichtig ist alles andere weglassen  Grob-Projektplan für Abstimmung mit Kunde

18 Ausflug: Grenzen der Planbarkeit
Allgemeine Botschaft (für SW-Projekte): Nach dem Pflichtenheft: Grössenordnung des Aufwandes „Anzahl der Nullen“ Nach dem Grobkonzept: +- 30% Nach dem Feinkonzept: sehr genau Dies gilt so bei einer bestimmten genaueren Auslegung der Begriffe „Pflichtenheft“ und „Grobkonzept“. Fazit: Planbarkeit hat Grenzen Fixpreisverträge für das ganze Projekt bereits nach dem Pflichtenheft unterschreiben ist extrem riskant! Aufwandsschätzung und Projektplan überarbeiten im Projektverlauf