Professionelles Projekt-Management in der Praxis Veranstaltung 7 – Teil 1 (30.06.2003): Prof. Dr. Phuoc Tran-Gia, FB Informatik, Universität Würzburg Prof. Dr. Margit Meyer, FB Wirtschaftswissenschaften, Universität Würzburg Dr. Harald Wehnes, AOK Bayern Besonderheiten von Software-Projekten
Agenda (30.06.2003) Sonderthemen des Projektmanagements Faktor „Mensch“ (16.06.2003) Projektkommunikation (16.06.2003) Risiko-Management (16.06.2003) Besonderheiten von Software-Projekten Projekt-Qualitätsmanagement Projekt-Marketing Konflikt- und Krisenmanagement Verhandlungsmanagement (nach Harvard) Claimmanagement Erfolgreiches Projektmanagement 7 Abschlusspräsentationen und Abgabe der Abschlußberichte mit Projekt-CD
Schlechtes Image von SW-Projekten Schlechtes Image von Softwareprojekten vgl. „Chaos-Report“ der Standish Group von 1995*: *) Quelle: IT Management, 3/2000 http://standishgroup.com Schätzung (nur USA 1995): 59 Mrd. $ für Kosten- überschreitungen 81 Mrd. $ für abgebro- chene SW-Projekte
Warum diese gewaltigen Probleme in der IT-Branche? Workshopteil Programmierer als Projektmanager ohne Erfahrungen und Kenntnisse Softwareentwicklung ist sehr abstrakt und dem Auftraggeber sind Einzelheiten schwer vermittelbar Software ist sehr komplex und schwer testbar auf Fehlerfreiheit Software verhält sich in anderen Umgebungen anders Softwarebranche ist noch sehr jung Akzeptanz kann sich im Projektverlauf verändern Die Anforderungen sind dem Anwender am Anfang noch nicht ausreichend klar Schnelllebigkeit der Umgebung Mögliche Ursachen
Welche Lösungsansätze sehen Sie? Workshopteil Informatiker-Meinung Lasten- und Pflichtenheft Rapid Prototyping um vom Anwender ein Feedback zu bekommen Definiertes Vorgehensmodell mit Testverfahren Software anpassungsfähig gestallten Gute Praxis Starke Einbindung des Kunden / Anwenders in den Entwicklungsprozess Dem Anwender bei der Festlegung der Anforderung helfen Dem Kunden aufzeigen, welche Funktionalität wie viel kostet
Komplexität und Risiken Kleine Ursachen a dramatische Konsequenzen: DO 3 I = 1.3 statt DO 3 I = 1,3 a Verlust der Venussonde „Mariner-1“ 1996: Absturz von ARIANE 5 wegen eines Konvertierungsfehlers Ursachen für das Scheitern von SW-Projekten Hohe Erwartungen der Auftraggeber/Anwender Instabile Anforderungen und Ziele Dynamischer Markt Funktionalitäten nicht eindeutig definiert Neue Technologien, z.B. neue Versionen (Betriebssystem, Tools u.ä.), während der Projektlaufzeit Viele Schnittstellen zu bereits vorhandenen Systemen
Der Software-Projektleiter ... und seine Probleme schnelle Karriere Präferenz für Design Vernachlässigung Dokumentation Ehrgeizige Ziele Keine Zeit-/Kosten- überschreitungen Keine „Überraschungen“ Team Chef no bugs gut dokumentiert leicht zu ändern Kunden Software- Wartung/ Weiterentw. kurzfristiger Einsatz geringe Kosten viele Funktionen benutzerfreundlich Boehm; Ross: Theory-W Software Project Management, 1989
Vorgehensmodelle Definition: Ein Vorgehensmodell ist eine standardisierte Vorgehensweise in definierten Phasen für die Softwareentwicklung Unternehmensweite Gültigkeit Vorgehensmodelle definieren viele Aktivitäten und bilden damit einen „generischen“ Projektstrukturplan mit Zielen und Voraussetzungen Erforderliche Inputs und ihre Anforderungen Ergebnissen und Abschlusskriterien Klassische Modelle: Wasserfall-Modell, V-Modell Moderne Ansätze: Iterative Entwicklung, OO-Entwicklung, RUP, eXtreme Programming, EOS J. Noack, B. Schienmann: Objektorientierte Vorgehensmodelle im Vergleich; Informatik-Spektrum 22: 166-180 (1999)
Softwareanforderungen Wasserfall-Modell Jede Phase ist zu bearbeiten Rückkoppelung nur 1 Stufe Systemanforderungen 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
V-Modell mit Testansatz Anforderungs- definition Anwendungsszenarien Abnahmetest Validierung Verifikation Grobentwurf Systemtest Testfälle Feinentwurf Integrationstest Testfälle verbindliches Vorgehensmodell für Bundeswehr und Behörden in Deutschland Modul- Implementierung Modultest Testfälle
V-Modell: Vor- und Nachteile Vorteile Umfassende Betrachtung aller Komponenten des Softwareerstellungsprozesses (inkl. Qualitäts-sicherung und Wartung) Ausgefeilte, detaillierte Vorgaben, Ergebnismuster, Rollendefinitionen und -zuordnungen Gut geeignet für sehr große SW-Projekte mit hohem Qualitätsanspruch Nachteile Aufwendiges Projektmanagement (Bürokratie) Hoher Schulungsaufwand erforderlich Für kleinere SW-Projekte nur bedingt geeignet
Iterative Entwicklung: Ansatz Pragmatische Vorgehensweise Erfassung der Anforderungen (ganz oder teilweise) Definition und Realisierung eines Kernssystems Auslieferung und Einsatz des Kernsystems Auftraggeber sammelt Erfahrungen Auftraggeber ermittelt neue Anforderungen bzw. modifiziert alte Anforderungen Realisierung des erweiterten Kernsystems (weiter mit 4.) Iterative Komplettierung des Produktes Wartung ist Teil der Neuentwicklung
Iterative Entwicklung: Bewertung Vorteile Verkürzung der Entwicklungszeit bis zum ersten Produkt Erfahrungen über den praktischen Einsatz des Systems können bei der Weiterentwicklung berücksichtigt werden Mehr Erfolgserlebnisse durch neue Releases 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
OO-Entwicklung Ansatz Vorteile Nachteile Sehr gute Zukunftsperspektive OO-Entwicklung Ansatz Fokus auf Wiederverwendung auf verschiedenen Ebenen „Architektur zuerst“ Einsatz von objektorientierter Analyse, Design und Implementierungsmethoden und Tools 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
Change-Management Problem: Ziele, Technologien, Eigentumsverhältnisse usw. ändern sich während der Projektlaufzeit oder es gibt neue Erkenntnisse Ziel: professionelle Organisation, Verwaltung und Abwicklung von Änderungsanforderungen während des Projektverlaufs Vorgehen Definition eines Prozesses für den Umgang und die Dokumentation von Änderungen Entscheidungswege Entscheidungskompetenzen Dokumentation mit möglichen Auswirkungen, Termine, Kosten