Lektion Projektplanung Software Praktikum Lektion Projektplanung Ablauf (so wie tatsächlich passiert am 11.4.2005): 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

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

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

Literatur Folien von heute: www.ifi.unizh.ch/~stoyan/lectures/SopraLektionProjektplanung.ppt www.ifi.unizh.ch/~stoyan/lectures/SopraLektionProjektplanung.pdf Detaillierte Erläuterungen: (3 Exempl. In IFI-Bibliothek)

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

Aufwandsschätzung Wer hat offene Fragen an den Kunden? Wer hat 0-20 / 20-30 / 30-40 / 40-50 / 50-60 / 60-70 / 70++ PT?

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

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

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

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

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

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

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

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!)

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.

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:

Tools Langjährige Industriestandards: Schätzung: Excel Projektplan: MS-Project. Download: www.codezone.ch 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

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