modul software komponenten 04 – projektplanung i · 1. repetition projektplanung (kontextmodul)...
TRANSCRIPT
Modul Software Komponenten
04 – Projektplanung I
Martin Jud
© HTA Luzern, 22.09.2008 Modul SWK - 04-Projektplanung I - Martin Jud 2
Inhalt
1. Repetition Projektplanung (Kontextmodul)
2. Repetition SW Entwicklungsprozess (PRG II)
3. Projektplanung im HTAgil
4. Risiken
1. Repetition
Projektplanung (Kontextmodul)
© HTA Luzern, 22.09.2008 Modul SWK - 04-Projektplanung I - Martin Jud 4
Regelkreis der Projektabwicklung
Kernelemente der Projektabwicklung
Projektführung(Prozess)
– Projektplanung
– Steuerung
– Kontrolle
Projektdurchführung(Produkt)
– Phasenmodell
– Vorgehensmodelle
Quelle: Jenny; Projektmanagement; vdf-Verlag, Zürich 2005
© HTA Luzern, 22.09.2008 Modul SWK - 04-Projektplanung I - Martin Jud 5
Phasenmodell
Generisches Phasenmodell (nach Jenny)
– Phasenweises Vorgehen hilft den Überblick zu behalten
– Risiko einer Fehlentwicklung wird verringert
– Periodische Stellungnahmen und Entscheide an den Meilensteinen M1 . . M4
– Lieferobjekte am Ende jeder Phase sind klar
Projekt-Impuls
NutzungInitialisierungs-
PhaseKonzeptions-
PhaseRealisierungs-
PhaseEinführungs-
Phase
M1 M2 M3 M4
© HTA Luzern, 22.09.2008 Modul SWK - 04-Projektplanung I - Martin Jud 6
Phasenmodell
Initialisierungs-Phase – Was wollen wir tun?
– Projektauftrag / Projektdefinition / Problemanalyse / Ziel-und Anforderungsdefinition / Definition der Arbeitspakete
Konzeptions-Phase – Wie wollen wir es tun?
– Konzept- und Lösungssuche
Realisierungs-Phase – Wir realisieren unsere Lösungen.
– Fertigung, Programmierung etc.
Einführungs-Phase – Sind die Projektziele erfüllt?
– Das neue Produkt wird für den Gebrauch, Verkauf freigegeben
© HTA Luzern, 22.09.2008 Modul SWK - 04-Projektplanung I - Martin Jud 7
Gestaltungsprinzipien
Top-Down-Prinzip
– Vom Groben zum Detail
– Konzept auf oberer Ebene gilt als Orientierungshilfe
– Es liegen nicht sofortkonkrete Lösungen vor
Bottom-Up-Prinzip
– Verbesserung vorhandener Lösungen
– Es liegen schnell Lösungen vor
© HTA Luzern, 22.09.2008 Modul SWK - 04-Projektplanung I - Martin Jud 8
Gestaltungsprinzipien
80/20-Prinzip (Pareto-Prinzip nach ital. OekonomVilfredo Pareto 1897)
– Eine Minderheit von Ursachen führen zu einer Mehrheit von Ergebnissen
– Aufwand Ertrag
– Ursache Wirkung
– Anstrengung Ergebnis
– Teile Kosten
– Funktionen Anwendung
2. Repetition
Software Entwicklungsprozess (PRG II)
© HTA Luzern, 22.09.2008 Modul SWK - 04-Projektplanung I - Martin Jud 10
Aufwandverteilung
Ziele einer methodischen Entwicklung:- Verlängerung der Lebensdauer- Reduktion der Kosten der Wartungsphase
evtl. grössere Anfangskosten!
Adaptiert von den Software Engineering Unterlagen von Jörg Hofstetter (HTA Luzern , 2002)
Aufwand
Zeit
Einführungszeitpunkt
Ersatzzeitpunkt
typischerVerlauf
Verlauf beimethodischer Entwicklung
© HTA Luzern, 22.09.2008 Modul SWK - 04-Projektplanung I - Martin Jud 11
Frühe Phasenmodelle
Wasserfallmodelle
– Sequentielles Vorgehen
– Phasen = Aktivitäten
– Kontrolle der Aktivitäten-ergebnisse und Tests.
V-Modelle
– Sequentielles Vorgehen
– Phasen haben Bezug zum „aufsteigenden Ast“
– Unterscheidung von Review, Verifikation und Validierung
Kunden-anforder-
ungen
Abnahmeplan
Review
SystemSpezifikation
Testplan
Review
Detail-design
UnitTestsplanen
Implementation
Unit-Tests
validieren
verifizieren
Verteilung &Abnahme
(und debug)
Integrationund Systemtest
(und debug)
Kundenanforderungen
Review
Systemspezifikation
Review
Detaildesign
Implementation
Verteilung & Abnahme
(und debug)
Integ. & Sys.Test
(und debug)
© HTA Luzern, 22.09.2008 Modul SWK - 04-Projektplanung I - Martin Jud 12
Probleme des sequentiellen Vorgehens
Fehler werden spät erkannt:
Folgen bei vermeintlich „seriösem Vorgehen“ (jede Phase muss abgeschlossen sein, bevor mit der nächsten angefangen wird):
– späte Entdeckung von Anforderungs- Analyse- und Designfehlern erst im Integrations- bzw. Abnahmetest
– Risiken werden zu lange mitgeschleppt, weil „jetzt noch nicht codiert werden darf“
Aufwandzur Fehler-behebung
Phase der Fehlerentdeckung
Risiko
Zeit
Ausarbeitung
Konstruktion
sequentiell
Übergang
Vorbereitung
iterativ
© HTA Luzern, 22.09.2008 Modul SWK - 04-Projektplanung I - Martin Jud 13
Neuere Phasenmodelle
Iterativ
Die Aktivitäten des Entwicklungszyklus werden mehrmals durchlaufen
bereits in frühen Itera-tionen werden lauffähige Programmteile geschaf-fen (Prototypen)
Inkrementell
Die Releases erhalten mit jeder Iteration einen grösseren Funktions-umfangZeit
Funktionsumfang des Systems
ZeitIteration 1 Iteration 2 Iteration 3
Milestone1 Milestone2 Milestone3
KA
SS
SE
T
VA KA
SS
SE
T
VA KA
SS
SE
T
VA
3. Projektplanung im HTAgil
© HTA Luzern, 22.09.2008 Modul SWK - 04-Projektplanung I - Martin Jud 15
Plans are nothing –
Planning is everything
Dwight D. Eisenhower
© HTA Luzern, 22.09.2008 Modul SWK - 04-Projektplanung I - Martin Jud 16
HTAgil Projekt-Plan
1. Einleitung
1.1 Projektübersicht
1.2 Evolution dieses Dokumentes
1.3 Begriffe, Abkürzungen und Referenzen
2. Projektorganisation
2.1 Projektstruktur
2.2 Rollen & Zuständigkeiten
2.3 Untervergaben & Schnittstellen
3. Projektführung
3.1 Rahmenplan
3.2 Arbeitspläne
3.3 Projektkontrolle
3.4 Risikomanagement
3.5 Projektabschluss
4. Technischer Prozess
4.1 Vorgehensmodell
4.2 Methoden & Werkzeuge
4.3 Infrastruktur
4.4 Abnahmeplanung
5. Projektunterstützung
Konfigurationsmanagement,
Dokumentationsplanung,
Reviewplanung,
QS & Prozessverbesserung
Anhänge
© HTA Luzern, 22.09.2008 Modul SWK - 04-Projektplanung I - Martin Jud 17
Proj.Mgmt Road Map
1. Understand project content, scope, & time frame
2. Identify development process(methods, tools, languages, documentation and support)
3. Determine organizational structure(organizational elements involved)
4. Identify managerial process(responsibilities of the participants)
5. Develop schedule
6. Develop staffing plan
7. Begin risk management
8. Identify documents to beproduced
9. Begin process itself
1. Einleitung
1.1 Projektübersicht
1.2 Evolution dieses Dokumentes
1.3 Begriffe, Abkürzungen und Referenzen
2. Projektorganisation
2.1 Projektstruktur
2.2 Rollen & Zuständigkeiten
2.3 Untervergaben & Schnittstellen
3. Projektführung
3.1 Rahmenplan
3.2 Arbeitspläne
3.3 Projektkontrolle
3.4 Risikomanagement
3.5 Projektabschluss
4. Technischer Prozess
4.1 Vorgehensmodell
4.2 Methoden & Werkzeuge
4.3 Infrastruktur
4.4 Abnahmeplanung
5. Projektunterstützung
Konfigurationsmanagement,
Dokumentationsplanung,
Reviewplanung,
QS & Prozessverbesserung,
Anhänge
Roadmap taken from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001)
© HTA Luzern, 22.09.2008 Modul SWK - 04-Projektplanung I - Martin Jud 18
Grobterminplanung
1. die wichtigsten Meilensteine des Projektes benennen
2. Meilensteine vom Ausliefertermin her rückwärts verteilen
3. Deliverables der ersten Iteration benennen(besser wenige, dafür möglichst früh)
4. Punkte im Projektverlauf aufzeigen, wo Risiken beurteilt werden
5. Reserve für Unvorhergesehenes einplanen
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
© HTA Luzern, 22.09.2008 Modul SWK - 04-Projektplanung I - Martin Jud 19
Rahmenplan: "big-picture"
Die groben Iterationsschritte und die dazugehörigen Meilensteine können in einem ersten Schritt aus den HTAgil Phasen abgeleitet werden.
Insbesondere die Konstruktionsphase wird oft durch weitere Meilensteine (Auslieferung unterschiedlicher Software Releases) weiter strukturiert.
Der Rahmenplan sollte möglichst stabil sein.
© HTA Luzern, 22.09.2008 Modul SWK - 04-Projektplanung I - Martin Jud 20
The Cone of Uncertainty
The cone defines statistically predictable levels of project estimate uncertainty at each stage of the project. Estimates created at initial concept time can be inaccurate by a factor of 4x on the high side, or /4 on the low side.
– The Cone of Uncertainty represents the best-case accuracy. It isn’t possible to be more accurate; it’s only possible to be more lucky.
– Furthermore, the cone doesn't narrow itself. If you don't actively work to reduce the variability of your project, the cone of uncertainty quickly becomes a cloud of uncertainty.
http://www.codinghorror.com/blog/archives/000623.html
© HTA Luzern, 22.09.2008 Modul SWK - 04-Projektplanung I - Martin Jud 21
Arbeitsplanung und Schätzgenauigkeit
Die Arbeitsplanung erfolgt rollend, d.h. innerhalb des Rahmenplanes werden die nächstfolgenden Iterationen geplant. Mögliche Ansätze:
– Zeitorientiert (Timeboxing): Fixe Zeitabschnitte, in der rollenden Planung werden die Ziele für eine Iteration entsprechend festgelegt.
– Artefaktorientiert: Für jede Iteration werden Deliverables definiert. Die Iterationsdauer wird entsprechend geplant.
Arbeitsplanung bei Abweichungen nachführen.
Graphic Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
1 €Ausarbeitungs-Phase
Bereich ist nicht linearsymmetrischzum Schätzwert von 1 €sondern z.B. x4 und /4
1 €
25 c
4 €
Vorbereitungs-Phase
1 €Konstruktions-Phase
1 ۆbergangs-Phase
© HTA Luzern, 22.09.2008 Modul SWK - 04-Projektplanung I - Martin Jud 22
Bottom-Up Terminplanung
1. Aufteilung des zu entwickelnden (Software-) Systems in eine überschaubare Anzahl (<50) von intuitiv abgrenzbaren Einheiten (Subsysteme, Komponenten, ...).
2. Hauptaufgaben: Für jede Einheit wird im nächsten Schritt bestimmt, welche Art von Aufgaben für die jeweilige Komponente im Vordergrund stehen.
3. Menschen & Prozesse: Formalisierungsgrad, Art und Anzahl der beteiligten Personen und Organisationen bestimmen wesentlich denAufwand für PM, Doku, Schulung etc.
4. Aufwandschätzung (iterativ) Für alle Hauptaufgaben und unterstützenden Aktivitäten wird eine Grobschätzung des erwarteten Aufwands und der erwarteten Dauer vorgenommen.
© HTA Luzern, 22.09.2008 Modul SWK - 04-Projektplanung I - Martin Jud 23
1 – Aufteilung
– Hardware Strukturierung: Technische Systeme lassen sich meist entlang von Hardware-Grenzen in Subsysteme und Komponenten gliedern.
– Fachliche Strukturierung: Business-Anwendungen lassen sich typisch funktional und / oder Datenorientiert strukturieren.
– Technologische Strukturierung: Oft lassen sich Software-systeme meist in (G)UI, Kommunikation, Datenverarbeitung, Persistenz etc. gliedern.
– Topologische Strukturierung: Verteilte Systeme bestehen häufig aus Client und Server mit Middleware und Services.
Ziel ist eine überschaubare Anzahl (<50) von Komponenten.
© HTA Luzern, 22.09.2008 Modul SWK - 04-Projektplanung I - Martin Jud 24
2 – Haupttätigkeiten
Welche Art von Aufgaben steht für die eine Komponente im Vordergrund, z.B.:
– Neu zu entwickelnde (Teil-)Systeme verlangen nach Analyse und System- und Architekturentwurf. Für sie ist auch eine passende Integrationsstrategie zu finden.
– Neu zu entwickelnde Komponenten erfordern I/F Design Programmentwurf, Implementation und Test
– Vorbestehende Komponenten bzw. Teilsysteme müssen verstanden, adaptiert und integriert werden
– (G)UI Komponenten müssen designed und ihre Usability muss sichergestellt werden
– COTS müssen evaluiert, adaptiert und integriert werden
© HTA Luzern, 22.09.2008 Modul SWK - 04-Projektplanung I - Martin Jud 25
3 – Menschen und Prozesse
Auf Grund der Menge und Art der Aufgaben kann eine geeignete Projektstruktur bestimmt werden.
Es zeigt sich
– ob und welche Teilprojekte gebildet werden können,
– welchen Charakter (Neuentwicklung, Weiterentwicklung, Integration, ...) das Projekt hat und
– welche fachlichen und persönlichen Skills benötigt werden.
Prozessmodell, Formalisierungsgrad, Art und Anzahl der beteiligten Personen und Organisationen bestimmen wesentlich den Aufwand für die unterstützenden Aktivitäten wie PM, Doku, Schulung etc.
© HTA Luzern, 22.09.2008 Modul SWK - 04-Projektplanung I - Martin Jud 26
4 – Aufwandschätzung I
Für alle Projektaufgaben (Haupttätigkeiten und die unterstützenden Aktivitäten) wird eine Grobschätzung des erwarteten Aufwands – und falls dies eine unabhängige Dimension ist – der erwarteten Dauervorgenommen.
Am besten ist es, wenn die designierten Stakeholders eine Schätzung für ihren Zuständigkeitsbereich vornehmen, d.h.
– Testing Verantwortlich für Test und Integration,
– SW-EntwicklerInnen für Detailentwurf, Implementation und Unittest,
– SystemdesignerInnen für System- und Architekturentwurf,
– (Teil-) ProjektleiterInnen für Vorbereitungsphase, unterstützende Aktivitäten und Übergangsphase.
Es ist anzustreben, dass jedes Element von wenigstens drei Personen geschätzt wird.
© HTA Luzern, 22.09.2008 Modul SWK - 04-Projektplanung I - Martin Jud 27
Aufwandschätzung II
Die entsprechenden Zahlen werden zusammengetragen und signifikante Unterschiede diskutiert.
Hinter grösseren Differenzen stehen immer Missverständnisse und / oder unterschiedliche Basisannahmen.
Aus der Diskussion werden sich Anpassungen bezüglich unterstützender Aktivitäten und Prozess ergeben.
Nach dieser Iteration liegen die individuellen Schätzwerte für die einzelnen Projektaufgaben weniger als 15% auseinander.
Diese Zahlen können nun z.B. nach der 3-Punkt Methode aus PERT die Mittelwerte gebildet werden. Der so ermittelte Aufwand ist bei bekannter Umgebung (Applikation, Technologien, Personen) auf 5 bis 10% genau.
© HTA Luzern, 22.09.2008 Modul SWK - 04-Projektplanung I - Martin Jud 28
Rollende Planung I (Makrozyklen)
Die Projektaufgaben aus der Aufwandschätzung werden auf den Rahmenplan abgebildet (parallel / zeitversetzt / sequentiell) und zwar so, dass etwa zur Halbzeit ein Prototyp mit allen wesentlichen bzw. kritischen Elementen steht. (80-20-Regel)
© HTA Luzern, 22.09.2008 Modul SWK - 04-Projektplanung I - Martin Jud 29
Rollende Planung II (Mikrozyklen)
Die aktuell anstehende Projektphase bzw. der aktuelle Makrozyklus wird in Mikrozyklen von beispielsweise jeweils zwei Wochen Dauer eingeteilt.
Für diese Mikrozyklen macht man sich eine Tasklist und zwar wieder so, dass etwa zur Halbzeit (also im Beispiel nach einer Woche) allenwesentlichen bzw. kritischen Elementen stehen. (80-20-Regel)
http://osiris.fhz.ch/pubwiki/index.php/HTAgil_Prozessrahmen
4. Risiken
© HTA Luzern, 22.09.2008 Modul SWK - 04-Projektplanung I - Martin Jud 31
Risiken identifizieren
– Systematik zur Risikoidentifikationder "Jäger und Sammler-Ansatz" liefert gerade aktuelle, nicht aber unbedingt die wichtigen Risiken. Projekte in gegebenem Umfeld haben immer ähnliche Risikoprofile.
Risk Sources by Importance.
– Bezug zu den ErfolgsfaktorenRisikoidentifikation soll einen klaren strategischen Bezug habenund sich auf die zentraler Erfolgsfaktoren - wie beispielsweise die Kernkompetenzen konzentrieren.
– Einsatz von FachexpertenEine fundierte und objektive Risikoidentifikation erfordert möglicherweise den Einsatz von Fachleute die unabhängig vom zu identifizierenden Risikobereich sind, aber das entsprechende Fach-KnowHow haben.
sinngemäss aus: http://www.krisennavigator.dec
© HTA Luzern, 22.09.2008 Modul SWK - 04-Projektplanung I - Martin Jud 32
Die wichtigsten Risiken
1. Fehlendes Commitment des an oberen Managements
2. Fehlendes Commitment beim Auftraggeber / Nutzer
3. Missverständnisse bei den Anforderungen
4. Unzureichender Einbezug von Auftraggeber bzw. Nutzer
5. Fehlendes Management der Endbenutzererwartungen
6. Fehlendes Change- & Scope-Management
7. ...
nach: Keil, Cule, Lyytinen, Schmidt
© HTA Luzern, 22.09.2008 Modul SWK - 04-Projektplanung I - Martin Jud 33
Risiken analysieren
Einheitliches Mass zur Bewertung eines Risikos verwenden.
Objektive Daten verwenden, subjektiven Daten ohne nachvollziehbare Herleitung oder Begründung sind für Dritte nicht prüfbar.
Sicher erwartete Entwicklungen stellen kein Risiko dar planen.
Einmalige Schadenwirkung und anhaltende Wirkung unterscheiden.
Schadenhöhe x Eintrittswahrscheinlichkeit ist nicht immer geeignet: z.B. können Absatzmengenrisiken - mit unterschiedlicher Wahrscheinlichkeit - einen Umfang von 1, 2, 3% usw. haben und sind besser durch eine Normalverteilung zu beschreiben.
Risiken nicht überschneidend identifizieren „Doppelzählung".
“Kleinvieh macht auch Mist“: nicht auf katastrophenartigen fixieren.
Korrelationen und Wechselwirkungen im Gesamtkontext bewerten.
sinngemäss aus: http://www.krisennavigator.dec
© HTA Luzern, 22.09.2008 Modul SWK - 04-Projektplanung I - Martin Jud 34
Risikoanalyse
Vorgehen:
1. Beschreibung der Risiken und der nötigen Massnahmen zur Vermeidung/Eliminierung des Risikos erstellen.
2. Diese Risiken bewerten: Risiko [R = ExS]: klein=1 mittel=2 gross=3Eintretenswahrscheinlichkeit [E] gross Risiko wird gross Auswirkung/Schaden [S] gross Risiko wird gross
3. Vermeidungskosten [V] beurteilen: (was kostet es, ein Risiko zu vermeiden, zu eliminieren?) Kosten [V]: klein=1 mittel=2 gross=3
4. Berechnen der Umsetzungs-Priorität: Gewicht [G] = R / V ExS/VMassnahmen mit grösserem Gewicht werden zuerst umgesetzt.
Ziel: mittels geeigneter Massnahmen auf Risiken rechtzeitig reagieren.
© HTA Luzern, 22.09.2008 Modul SWK - 04-Projektplanung I - Martin Jud 35
Risken bei ProjektstartUmfang bei Projektstart
Projektplan überarbeiten• Kosten• Termine• Umfang / Änderungen
Iteration N planen• Kosten• Termine
Iteration N auswerten
Eliminierte RisikenRisikoliste überarbeiten• neu priorisieren
Iteration N durchführen• Kosten und Metriken
erfassen
Vorgehen zur Vermeidung bzw. Elimination der höchst priorisierten Risiken festlegen
Iteration N
Risiko-Management und iteratives Vorgehen
In jedem iterativen Durchgang werden die jeweils grössten Risiken durch gezielte Massnahmen adressiert und systematisch eliminiert.
sinngemäss nach: RUP
© HTA Luzern, 22.09.2008 Modul SWK - 04-Projektplanung I - Martin Jud 36
Risiko-Profilsinngemäss nach: RUP
Vorbereitung
Ausarbeitung
Konstruktion
sequenziellesVorgehen (Wasserfall)
Risiko
PreliminaryIteration
Architect.Iteration
Architect.Iteration
Devel. Iteration
Devel. Iteration
Devel. Iteration
TransitionIteration
TransitionIteration
Post-deployment
Zeit
iteratives Vorgehen
Übergang