Professionelles Projektmanagement in der Praxis

of 16/16
Professionelles Projektmanagement in der Praxis © 2008 Dr. Harald Wehnes, kubus IT Universität Würzburg, FB Informatik, Prof. Dr. P.Tran-Gia 1 Professionelles Projektmanagement in der Praxis Veranstaltung 7 – Teil 3 (30.06.2008): Besonderheiten von Softwareprojekten SS 2008
  • date post

    22-Jan-2016
  • Category

    Documents

  • view

    39
  • download

    0

Embed Size (px)

description

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. - PowerPoint PPT Presentation

Transcript of Professionelles Projektmanagement in der Praxis

Vorlesung Professionelles PM in der Praxis*
Besonderheiten von Softwareprojekten
SS 2008
*
Succeeded: Projekt wurde inner-
Budgetrahmens abgeschlossen.
und erfüllt alle Anforderungen.
Challanged: Projekt ist abge-
schlossen. Das Projektergebnis ist
nen Umfang erreicht worden.
Failed: Projekt wurde vorzeitig
abgebrochen oder das Projekt-
ergebnis wurde nie eingesetzt.
Im Jahr 1995 wurde von der Standish Group der „Chaos-Report“ veröffentlicht.
Er greift die Problematik von Softwareprojekten auf und gilt auch heute noch nicht als überholt.
Der Report kann als umfassend bezeichnet werden:
365 Befragte gaben Auskunft zu 8380 Software-Projekten.
Ergebnis: siehe Grafik
American Airlines scheute sich nicht preiszugebne, dass das 165-Millionen-Dollar-projekt „Confirm“, ein Mietauto- und Hotelreservierungssystem, im Chaos und in einer gerichtlichen Auseinandersetzung mit Budget-Rent-A-Car, der Marriot Corp. Und den Hilton Hotels endete.
Seither hat sich wenig geändert.
Diagramm1
1994
1994
1994
1996
1996
1996
1998
1998
1998
2000
2000
2000
Succeeded
Challanged
Failed
16
53
31
27
33
40
26
46
28
28
49
23
Tabelle1
1994
1996
1998
2000
Succeeded
16
27
26
28
Challanged
53
33
46
49
Failed
31
40
28
23
Tabelle1
0
0
0
0
0
0
0
0
0
0
0
0
Succeeded
Challanged
Failed
0
0
0
0
0
0
0
0
0
0
0
0
Tabelle2
Tabelle3
*
Aufwand lässt sich nur sehr schwer schätzen
Rasante technische Entwicklungen überholen das Projekt
Schlechte OOA und OOD
Technische Probleme bei der Programmierung
Schlechte Planbarkeit
Fachfremde Führung, die den Aufwand nicht richtig einschätzen kann
Fehlende Erfahrung
Schlechte Abbildung der Geschäftsprozesse
Mögliche Ursachen? (SS 04)
Wechsel / Ausfall von Mitarbeitern
*
Klare Zielbestimmungen
Lösungsansätze SS 06
Agiles Projektmanagement
Klare Verantwortlichkeiten
geringe Pufferzeiten
Frühzeitige, intensive Einbeziehung der User
Möglichst viele kleine Teams
Einstellung als Dienstleister
Intensives Einbeziehen der Kunden
*
Viele Schnittstellen zu bereits vorhandenen Systemen
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
Das Problem ist, daß Software „unstetig“ ist:
Fehlt an einer Brücke eine Schraube, so stürzt sie nicht ein.
Stimmt in einem Programm ein Bit nicht, so kann dies unweigerlich zur Katastrophe führen.
Beispiele hierfür gibt es genug:
. statt ,
Erwartungen der Auftrageber ....
Schon bei der Einordnung der SW-Entwickler tun sich viele schwer:
Softwaretechnik ist keine Naturwissenschaft (Balzert)
Software-Entwickler sind Künstler, keine Ingenieure.
Wir wollen uns mit einigen Besonderheiten von SW-Projekten beschäftigen:
Hierzu zählen insbesondere:
Konfigurationsmanagement
Change-Management
*
Boehm; Ross: Theory-W Software Project Management, 1989
*
Unternehmensweite Gültigkeit
Zielen und Voraussetzungen
Ergebnissen und Abschlusskriterien
Für die Realisierung von SW-Projekten setzt man sog. Vorgehensmodelle (= Prozessmodelle) ein.
Ein Vorgehensmodell beschreibt den Rahmen einer Softwareentwicklung
Welche Aktivitäten in
Welcher Reihenfolge von
Mit welchen Ergebnissen (=Artefakte)
In der Regel hat jedes Softwareunternehmen ein spezifisches Vorgehensmodell, das i.w. von der Art der Software, die für das Unternehmen entwickelt wird, und den eingesetzten Tools bestimmt wird.
Im Laufe der Jahre wurden viele Vorgehensmodelle entwickelt.
Man unterscheidet klassische Modelle und moderne Ansätze
*
Rückkoppelung nur eine Stufe
Design
Von den Klassischen Modellen sind das Wasserfall-Modell und das V-Modell die bekanntesten Vertreter.
Zunächst das Wasserfallmodell:
Jede Phase ist zu bearbeiten
Die Ergebnisse einer Phase fließen in die nächste
Rückkopplung zwischen benachbarten Phasen o.k und z.T. auch notwendig
Am Ende einer Phase müssen genau spezifizierte Dokumente vorliegen.
Klarer Top-Down-Ansatz
Schätzmodelle verfügbar
Fehlentwicklungen werden dann oft zu spät erkannt.
*
Darstellung des V-Modells mit Testansatz
Einführung der Begriffe:
„Haben wir das Produkt richtig hinbekommen?“
Validierung:
„Haben wir das richtige Produkt entwickelt?“
*
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
Prototyp spezifizieren
Prototyp erstellen
Machbarkeitsprototyp zeigt die grundlegende Umsetzbarkeit auf
Pilotsystem: Kern des zu erstellenden Produktes
*
„Architektur zuerst“
Einsatz von objektorientierter Analyse (OOA), Design (OOD), Implementierungsmethoden und Tools (OOP)
Vorteile
Nachteile
Sehr hoher Schulungsaufwand
Bei der OO-Vorgehensweise wird der Fokus auf Wiederverwendung gelegt.
Ansatz
Einsatz von objektorientierter Analyse, Design und Implementierungsmethoden und Tools
Vorgehensweise meist iterativ mit Prototyping
Vorteile
Gute Ergänzung für Prototyping und iterative Entwicklung
Nachteile
Sehr hoher Schulungsaufwand
Skepsis/Zurückhaltung in der Praxis für den Einsatz bei großen SW-Projekten
Unterschiedliche Modelle haben alle Vor- und Nachteile, aber keines ist schlechter als gar keine Vorgehensmodell. Wichtig ist, dass alle Projektmitarbeiter die Vorgehensweise akzeptieren und leben.
*
Das Spiralmodell gibt die fest vorgegebenen Phasen des Wasserfallmodells auf.
Es ist ein Modell mit 4 Zyklen:
Zielbestimmung
Entwicklung und Anwendertest
Auswertung und Planung der nächsten Phase/Iteration.
Hohe Bedeutung hat die Risikoanalyse, die ein Scheitern des Projektes frühzeitig vorbeugen bzw. ein aussichtsloses Projekt möglichst schnell beenden soll.
Das Spiral-Modell beschreibt einen iterativ-inkrementellen SW-Entwicklungsprozess.
Jeder Umlauf entspricht einem Entwicklungszyklus in den Phasen des Wasserfallmodells.
*
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
Falls wesentliche Anforderungen fehlen oder die Systemarchitektur überarbeitet werden muss, kann dies extrem teuer werden
Nur für firmeninterne Projekte geeignet
Sehr flexibel durch die Betrachtung von Alternativen
*
Agiles Vorgehensmodell
*
Agiles Vorgehensmodell
*
1994
1996
1998
2000
SucceededChallangedFailed