Professionelles Projektmanagement in der Praxis, © 2006 Dr. Harald Wehnes Universität Würzburg, FB Informatik, Prof. Dr. P.Tran-Gia 1 Professionelles Projektmanagement

Professionelles Projektmanagement in der Praxis, © 2006 Dr. Harald WehnesUniversität Würzburg, FB Informatik, Prof. Dr. P.Tran-Gia

1

Professionelles Projektmanagement in der Praxis

Veranstaltung 7 – Teil 1 (17.07.2006):

Besonderheiten von Softwareprojekten

SS 2006


2

Agenda

Ablauf 17.7.2006

13:30 7. Vorlesungsblock

14:45 Pause

PM-Preis Projekta 2006PM-Preis Projekta 200615:00 Begrüßung 15:05 Teams 1, 2 und 3

15:50 Pause

16:05 Teams 4, 5 und 6

16:50 Pause

17:05 Teams 7 und 8

17:35 Jury-Bewertung/Pause

17:50 Preisverleihung

1. Besonderheiten von Softwareprojekten

2. Reifegradmodelle im Projektmanagement

3. Konfigurations- und Änderungsmanagement(Change-Management)

4. Vertrags- und Claimmanagement (Nachforderungsmanagement)

5. Anforderungsmanagement (Requirementsmanagement)

6. Projekterfolgsfaktoren


3

Scheine

Durchsicht der Arbeiten und Prüfung der SW-Produkte: bis Freitag (21.07.2006)ggf. Projekt-Nacharbeiten erforderlich

Abholung der Scheine bei Frau Alt, Sekretariat Informatik

III: ab Mittwoch (26.07.2006)


4

Zertifizierung von Vorlesungsteilnehmern

GPM pilotiert CoE (Certificate of Excellence) Ziele

Auszeichnung der Qualität des Lehrangebots Projektmanagement einer Einrichtung mit öffentlich-rechtlichem Bildungsauftrag (z.B. Uni)

Etablierung eines Erfahrungsaustauschs der Lehrenden Studierende können die Zertifizierung und das Fachbuch

ProjektManager kostengünstiger erwerben Kosten

CoE-Zertifizierung: 2.100 € + MwSt. (Laufzeit: 3 Jahre), Re-Z. (450 €) IPMA-Level D Zertifizierungsgebühr: 350 € bzw. 400 € (statt: 650 €) Fachbuch ProjektManager (GPM): 69 € (statt: 169 €)

IPMA Level D: Zertifizierter Projektmanagement-Fachmann (GPM)IPMA Level C: Zertifizierter Projektmanager (GPM)

IPMA Level B: Zertifizierter Senior Projektmanager (GPM)IPMA Level A: Zertifizierter Projektdirektor (GPM)


5

Schlechtes Image von SW-Projekten

*) Quelle: CHAOS Report, Standish Group International, Inc

16 53 31

27 33 40

26 46 28

28 49 23

0% 20% 40% 60% 80% 100%

1994

1996

1998

2000

Succeeded Challanged Failed

Succeeded: Projekt wurde inner-halb des vorgesehenen Zeit- und Budgetrahmens abgeschlossen. Das Projektergebnis ist im Einsatz und erfüllt alle Anforderungen.

Challanged: Projekt ist abge-schlossen. Das Projektergebnis ist im Einsatz. Zeit, Budget oder Leistung sind nicht im vorgesehe-nen Umfang erreicht worden.

Failed: Projekt wurde vorzeitig abgebrochen oder das Projekt-ergebnis wurde nie eingesetzt.


6

Warum diese gewaltigen Problemein der IT-Branche?

Fehleinschätzung des Aufwands Schlechte Schnittstellendefinitionen Fehlende Kommunikation Unvorhergesehene Probleme während der

Implementierung Fachfremde Führung, die den Aufwand nicht richtig

einschätzen kann Fehlende Erfahrung Fehlende intensive Einbeziehung des Kunden Schlechte Abbildung der Geschäftsprozesse

Workshopteil


7

Welche Lösungsansätze sehen Sie?

Puffer für unvorhergesehene Probleme Standards für Kommunikation Kommunikationsplan Fachspezifische Projektleiter Bisherige Projekte als Wissensbasis für neue Projekte

verwenden Frühzeitige, intensive Einbeziehung der User Möglichst viele kleine Teams

Workshopteil


8

Komplexität und Risiken

Hohe Erwartungen der Auftraggeber/Anwender Instabile Anforderungen und Ziele Dynamischer Markt Funktionalitäten nicht eindeutig definiert Neue Technologien, z.B. neue Versionen (Betriebssystem,

Tools), während der Projektlaufzeit Viele Schnittstellen zu bereits vorhandenen Systemen

Kleine Ursachen dramatische Konsequenzen:Kleine Ursachen dramatische Konsequenzen:

DO 3 I = 1.3 statt DO 3 I = 1,3 Verlust der Venussonde „Mariner-1“

1996: Absturz von ARIANE 5 wegen eines Konvertierungsfehlers


9

Der Software-Projektleiter... und seine Probleme

• ehrgeizige Ziele• keine Zeit-/Kosten- überschreitungen• keine „Überraschungen“

• schnelle Karriere• Präferenz für Design & Technik• Vernachlässigung Dokumentation

• kurzfristiger Einsatz• benutzerfreundlich• viele Funktionen• geringe Kosten

• no bugs• gut dokumentiert• leicht zu ändern

Boehm; Ross: Theory-W Software Project Management, 1989


10

Vorgehensmodelle

Ein Vorgehensmodell ist eine standardisierte Vorgehens-weise in definierten Phasen für die Softwareentwicklung

Unternehmensweite Gültigkeit Vorgehensmodelle definieren viele Aktivitäten und bilden

damit einen „generischen“ PSP mit Zielen und Voraussetzungen Erforderliche Inputs und ihre Anforderungen Ergebnissen und Abschlusskriterien

Klassische Modelle: Wasserfall-Modell, V-Modell Moderne Ansätze: Spiral-Modell, OO-Entwicklung,

V-Modell XT, Rational Unified Process (RUP), eXtreme Programming


11

Wasserfall-Modell

Systemanforderungen

Softwareanforderungen

Analyse

Programmierung

Test

Einführung/Wartung

+ Einfach, leicht erlernbar+ Langjährig erprobt+ Schätzmodelle verfügbar+ Sehr gut strukturiert

- Änderung von Anfor- derungen – was üblich ist – werden vom Modell nicht berücksichtigt- Integration erst gegen Projektende birgt Risiken- Lange Projektlaufzeiten zu erwarten

• Jede Phase ist zu bearbeiten• Rückkoppelung nur eine Stufe

Design


12

V-Modell mit Testansatz

Anforderungs-definition Abnahmetest

Grobentwurf Systemtest

Feinentwurf Integrationstest

Modul-Implementierung Modultest

Anwendungsszenarien

Testfälle

Testfälle

Testfälle

Validierung

Verifikation


13

Prototypen-Modell

Reduktion des Entwicklungs-risikos: Sicherstellung der Realisierbarkeit

Schnelles Erstellen einer lauffähigen Anwendung, die ausgewählte Eigenschaften des Zielproduktes besitzt

Einbeziehung der späteren Anwender bei der Gestaltung der Benutzerschnittstelle

Praktischer Testeinsatz Anwendungsarten

Demonstrationsprototyp Machbarkeitsprototyp Exploratives Prototyping bei

kritischen Teilproblemen

Prototyp spezifizieren

Prototyp erstellen

experimentieren

ändern / erweitern

Prototypakzeptiert?

ja

nein


14

Objekt-orientiertes Modell

Ansatz Fokus auf Wiederverwendung auf verschiedenen Ebenen „Architektur zuerst“ Vorgehensweise meist iterativ mit Prototyping Einsatz von objektorientierter Analyse (OOA), Design (OOD),

Implementierungsmethoden und Tools (OOP)

Vorteile Verbesserte Produktivität und Qualität Späte Änderungen und Erweiterungen sind einfacher machbar

Nachteile „Wiederverwendungskultur“ muss erlernt und akzeptiert werden Sehr hoher Schulungsaufwand Noch gewisse Skepsis/Zurückhaltung in der Praxis


15

Integration- und

Testplan

PT 1

Softwareentwurf

Festlegung von Zielen,Lösungsvarianten,Nebenbedingungen und Einschränkungen

Erarbeitung und Beurteilungvon Lösungsvarianten,

Erkennen und Beseitigen von Risiken

Proto-Typ 2

Proto-Typ 3

Risiko-analyse

Risiko-analyse

Vorgehens-modell

Entwicklungs-plan

Planungder nächstenPhase

Entwicklungund Validierung des

Produkts der nächsten Stufe

Pilot-system

Software-anforder-ungen

Detail-entwurf

Abnahme

Spiral-Modell (Boehm)

Lebens-zyklus-

plan

Risiko-analyse

Kumulative Kosten

Projektfortschritt

RA


16

Spiral-Modell: Vor- und Nachteile

Vorteile Hohe Flexibilität: Fehlende Funktionen und Fehler werden früh

erkannt Gemeinschaftliche iterative Entwicklung mit den

Endanwendern auf der Basis von Prototypen Verkürzung der Entwicklungszeit bis zum ersten Produkt Erfahrungen über den praktischen Einsatz des Systems

können bei der Weiterentwicklung berücksichtigt werden Nachteile

Erstes Produkt noch unvollständig; Gefahr eines dauerhaften, schlechten Images

Falls wesentliche Anforderungen fehlen oder die Systemarchitektur überarbeitet werden muss, kann dies extrem teuer werden

Nur für firmeninterne Projekte geeignet


17

V-Model XT (eXtreme Tailoring)

Vergleiche: Vortrag V-Modell XT vom 12.06.2006


18

eXtreme Programming (XP)

Vorbereitung Iterationen

Stories / Anforderungen

Neue Stories Story Verfeinerung

Entwicklung Test

Planning Game

Architektur,Technologien

PrototypenSpike Solution

StorySchätzung

Systemtest /Produktion

Kun

deE

ntw

ickl

ung

Vergleiche: Vortrag „eXtreme Programming (XP)“ vom 12.06.2006

Documents

Professionelles Projektmanagement in der Praxis, © 2006 Dr. Harald Wehnes Universität Würzburg, FB Informatik, Prof. Dr. P.Tran-Gia 1 Professionelles Projektmanagement