Professionelles Projektmanagement in der Praxis

Präsentation zum Thema: "Professionelles Projektmanagement in der Praxis"—  Präsentation transkript:

1 Professionelles Projektmanagement in der Praxis
Veranstaltung 7 – Teil 1 ( ): Besonderheiten von Softwareprojekten SS 2005

2 Agenda Besonderheiten von Softwareprojekten
Anforderungsmanagement (Requirement-Management) Änderungsmanagement (Change-Management) Claimmanagement (Nachforderungs-Management) Projekt-Qualitätsmanagement Abschlusspräsentationen 15:00 Uhr: Team 1 15:25 Uhr: Team 2 15:45 Uhr: Team 3 16:05 Uhr: Pause 16:15 Uhr: Team 4 16:35 Uhr: Team 5 danach Jury-Sitzung ca. 17 Uhr: Preisverleihung Durchsicht der Arbeiten und Prüfung der Applikationen: bis Freitag ( ); ggf. Projekt-Nacharbeiten Abholung der Scheine bei Frau Alt, Sekretariat Informatik III: ab Mittwoch ( ) Projektiade ´05

3 Schlechtes Image von SW-Projekten
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. *) Quelle: CHAOS Report, Standish Group International, Inc

4 Warum diese gewaltigen Probleme in der IT-Branche?
Workshopteil 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

5 Welche Lösungsansätze sehen Sie?
Workshopteil 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

6 Komplexität und Risiken
Kleine Ursachen a dramatische Konsequenzen: DO 3 I = statt DO 3 I = 1,3 a Verlust der Venussonde „Mariner-1“ 1996: Absturz von ARIANE 5 wegen eines Konvertierungsfehlers 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

7 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 Chef Team no bugs gut dokumentiert leicht zu ändern Kunden Software- Wartung/ Weiterentw. kurzfristiger Einsatz benutzerfreundlich viele Funktionen geringe Kosten Boehm; Ross: Theory-W Software Project Management, 1989

8 Vorgehensmodelle Was ist wann zu tun? 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 J. Noack, B. Schienmann: Objektorientierte Vorgehensmodelle im Vergleich; Informatik-Spektrum 22: (1999)

9 Softwareanforderungen
Wasserfall-Modell Systemanforderungen Jede Phase ist zu bearbeiten Rückkoppelung nur 1 Stufe Softwareanforderungen Einfach, leicht erlernbar Langjährig erprobt Schätzmodelle verfügbar Sehr gut strukturiert Analyse Design Änderung von Anfor- derungen – was üblich ist – werden vom Modell nicht berücksichtigt Integration erst gegen Projektende birgt Risiken Lange Projektlaufzeiten zu erwarten Programmierung Test Einführung/Wartung

10 V-Modell mit Testansatz
Aktuelle Version V-Modell XT vgl. Vortrag vom Anforderungs- definition Anwendungsszenarien Abnahmetest Validierung Verifikation Grobentwurf Systemtest Testfälle Feinentwurf Integrationstest Testfälle Modul- Implementierung Modultest Testfälle

11 Spiral-Modell (Boehm)
Kumulative Kosten Projektfortschritt Festlegung von Zielen, Lösungsvarianten, Nebenbedingungen und Einschränkungen Erarbeitung und Beurteilung von Lösungsvarianten, Erkennen und Beseitigen von Risiken Risiko- analyse Risiko- analyse Risiko- analyse RA Proto- Typ 2 Proto- Typ 3 Pilot- system PT 1 Lebens- zyklus- plan Vorgehens- modell Software- anforder- ungen Entwicklungs- plan Integration- und Testplan Software entwurf Detail- entwurf Planung der nächsten Phase Entwicklung und Validierung des Produkts der nächsten Stufe Abnahme

12 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

13 Prototyp spezifizieren
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 Prototyp akzeptiert? ja nein ändern / erweitern

14 OO-Entwicklung Ansatz Vorteile Nachteile
Fokus auf Wiederverwendung auf verschiedenen Ebenen „Architektur zuerst“ Einsatz von objektorientierter Analyse (OOA), Design (OOD) und Implementierungsmethoden und Tools (OOP) Vorgehensweise meist iterativ mit Prototyping 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 eXtreme Programming (XP)