Modul Software Komponenten 04 – Projektplanung I · 1. Repetition Projektplanung (Kontextmodul)...

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)


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


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


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


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


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)


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


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)


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


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


Plans are nothing –

Planning is everything

Dwight D. Eisenhower


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


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)


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.


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.


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


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


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.


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.


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


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.


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.


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.


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)


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


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


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


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


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.


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


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

Modul Software Komponenten 04 – Projektplanung I · 1. Repetition Projektplanung (Kontextmodul)...

Documents

Transcript of Modul Software Komponenten 04 – Projektplanung I · 1. Repetition Projektplanung (Kontextmodul)...