1 / 16

Professionelles Projektmanagement in der Praxis

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 – Teil 3 (30.06.2008): Besonderheiten von Softwareprojekten SS 2008. Schlechtes Image von SW-Projekten. Succeeded: Projekt wurde inner- halb des vorgesehenen Zeit- und Budgetrahmens abgeschlossen.

brinda
Télécharger la présentation

Professionelles Projektmanagement in der Praxis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Professionelles Projektmanagement in der Praxis Veranstaltung 7 – Teil 3 (30.06.2008): Besonderheiten von Softwareprojekten SS 2008

  2. 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 http://standishgroup.com

  3. Warum diese gewaltigen Probleme in der IT-Branche? Workshopteil

  4. Welche Lösungsansätze sehen Sie? Workshopteil

  5. 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 a dramatische Konsequenzen: DO 3 I = 1.3 statt DO 3 I = 1,3a Verlust der Venussonde „Mariner-1“ 1996: Absturz von ARIANE 5 wegen eines Konvertierungsfehlers

  6. 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

  7. Vorgehensmodelle Was ist wann von wem zu tun? • Ein Vorgehensmodell ist eine standardisierte Vorgehens-weisein 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 Quelle: J. Noack, B. Schienmann: Objektorientierte Vorgehensmodelle im Vergleich; Informatik-Spektrum 22: 166-180 (1999)

  8. Wasserfall-Modell Systemanforderungen • Jede Phase ist zu bearbeiten • Rückkoppelung nur eine 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

  9. V-Modell mit Testansatz Anwendungsszenarien Anforderungs- definition Abnahmetest Validierung Verifikation Grobentwurf Systemtest Testfälle Feinentwurf Integrationstest Testfälle Modul- Implementierung Modultest Testfälle

  10. 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

  11. 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

  12. 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 Pilot- system Proto- Typ 2 Proto- Typ 3 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

  13. 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

  14. V-Model XT (eXtreme Tailoring)

  15. Stories / Anforderungen Neue Stories Story Verfeinerung Systemtest / Produktion Kunde Planning Game Entwicklung Test Entwicklung Architektur, Technologien Story Schätzung Prototypen Spike Solution Vorbereitung Iterationen eXtreme Programming (XP)

  16. eXtreme Programming (XP)

More Related