Software Praktikum

1. Software Praktikum Lektion Projektplanung

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

3. Projektplanung Unser Fokus

4. Literatur Folien von heute: www.ifi.unizh.ch/~stoyan/lectures/SopraLektionProjektplanung.pptwww.ifi.unizh.ch/~stoyan/lectures/SopraLektionProjektplanung.pdf 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 / 20-30 / 30-40 / 40-50 / 50-60 / 60-70 / 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:

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 Unser Fokus Praxisrelevant überall Praxisrelevant nur mit (viel) Vorbereitung Verschiedene Methoden • Analogieschätzung:1-2 grob vergleichbare Projekte • Expertenschätzung • Kennzahlmethoden • CoCoMo • Function Point • Object Point • ... • Tabellen für Routineprojekte

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 Unser Fokus

14. Projektplan Unfertig: Namen nennen Besser wäre: Ergebnisse nennen Beispiel Projektplan: Dieser Projektplan war für eine grobe Terminabstimmung mit dem Kunden – nicht für die Terminplanung! 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: 30.3. Anna Usability-Test Funktionstest 30.3. Hannes Lasttest 30.3. Peter 28.3. Beate, Axel, Beat Fehlerbehebung 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: 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 istalles 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