Professionelles Projektmanagement in der Praxis Veranstaltung 7 – Teil 1 (17.07.2006): Besonderheiten von Softwareprojekten SS 2006 Die bisherigen Ausführungen waren i.w. allgemeingültig für alle Arten von Projekten. Wir wollen uns heute mit einigen Besonderheiten von Software-Projekten beschäftigen.

Agenda Ablauf 17.7.2006 PM-Preis Projekta 2006 Besonderheiten von Softwareprojekten Reifegradmodelle im Projektmanagement Konfigurations- und Änderungsmanagement (Change-Management) Vertrags- und Claimmanagement (Nachforderungsmanagement) Anforderungsmanagement (Requirementsmanagement) Projekterfolgsfaktoren 13:30 7. Vorlesungsblock 14:45 Pause PM-Preis Projekta 2006 15: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

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)

Zertifizierung von Vorlesungsteilnehmern Information an alle Vorlesungsteilnehmer, sobald Zertifizierung der Vorlesung vorliegt 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 €) Ggf. auch Information mittels Web-Konferenz (e-RING) 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)

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. Im Jahr 1994 wurde von der Standish Group erstmals 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 Sogar an praktischen Beispielen fehlte es den Analysten nicht: 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 leider wenig geändert. *) Quelle: CHAOS Report, Standish Group International, Inc http://standishgroup.com

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

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

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 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 Das Hauptproblem 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 , Fehler bei der Konvertierung einer 64-Bit-Gleitkommazahl nach 16-Bit-Integer Es gibt bestimmte Grundprobleme, die sehr häufig auftreten 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: Spezifische Vorgehensmodelle Anforderungsmanagement (Requirementsmanagement) Lasten-/Pflichtenheft Aufwandsschätzung für Softwareprojekte Konfigurationsmanagement Changemanagement

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

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 Für die Realisierung von SW-Projekten setzt man sog. Vorgehensmodelle (= Prozessmodelle) ein. Ein Vorgehensmodell beschreibt den Rahmen einer Softwareentwicklung Aktivitäten Reihenfolge Personen Ergebnisse (=Artefakte) In der Regel hat jedes Unternehmen 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 Zeit wurden viele Vorgehensmodelle entwickelt. Man unterscheidet klassische Modelle und moderne Ansätze. J. Noack, B. Schienmann: Objektorientierte Vorgehensmodelle im Vergleich; Informatik-Spektrum 22: 166-180 (1999)

Softwareanforderungen 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 Von den Klassischen Modellen sind das Wasserfall-Modell und das V-Modell die bekanntesten Vertreter. Zunächst das Wasserfallmodell: Die Reihenfolge der einzelnen Phasen ist vorgeschrieben 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 Vorteile des Wasserfall-Modells Langjährig erprobt Einfach, verständlich (da sequentiell); kein großer Schulungsaufwand erforderlich Schätzmodelle verfügbar Nachteile Braucht man wirklich alle Steps? Problem, wenn sich Anforderungen ändern Fehlentwicklungen werden dann oft zu spät erkannt. Test Einführung/Wartung

V-Modell mit Testansatz Anforderungs- definition Anwendungsszenarien Abnahmetest Validierung Verifikation Grobentwurf Systemtest Testfälle Feinentwurf Integrationstest Testfälle Ursprünglich: Erweiterung des Wasserfallmodells um Fragen der QS Darstellung des V-Modells mit Testansatz Einführung der Begriffe: Verifikation: Überprüfung der Übereinstimmung zwischen dem SW-Produkt und seiner Spezifikation „Haben wir das Produkt richtig hinbekommen?“ Validierung: Überprüfung des SW-Produkts hinsichtlich seiner Eignung und seines Wertes bezüglich des Einsatzzwecks „Haben wir das richtige Produkt entwickelt?“ Modul- Implementierung Modultest Testfälle

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 Anwendungsarten: Demonstrations-Prototyp: dient der Auftragsakquisition Machbarkeitsprototyp zeigt die grundlegende Umsetzbarkeit auf Pilotsystem: Kern des zu erstellenden Produktes nein ändern / erweitern

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 Bei der OO-Vorgehensweise wird der Fokus auf Wiederverwendung gelegt. Ansatz Fokus auf Wiederverwendung Starker Fokus auf „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 (geringerer Aufwand, bessere Tests möglich) Gute Ergänzung für Prototyping und iterative Entwicklung Nachteile „Wiederverwendungskultur“ muss von den Entwicklern erst erlernt und akzeptiert werden 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 Vorgehensweise. Wichtig ist, dass die Projektmitarbeiter die Vorgehensweise akzeptieren und leben.

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 Das Spiralmodell gibt die fest vorgegebenen Phasen des Wasserfallmodells auf. Es ist ein Modell mit 4 Zyklen: Zielbestimmung Risikoanalyse (RA) und –reduktion und Erstellung eines Prototypen (PT) 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. Entwicklungs- plan Integration- und Testplan Software entwurf Detail- entwurf Planung der nächsten Phase Entwicklung und Validierung des Produkts der nächsten Stufe Abnahme

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 Sehr flexibel durch die Betrachtung von Alternativen

V-Model XT (eXtreme Tailoring) Vergleiche: Vortrag V-Modell XT vom 12.06.2006

eXtreme Programming (XP) Vorbereitung Iterationen Stories / Anforderungen Neue Stories Story Verfeinerung Entwicklung Test Planning Game Architektur, Technologien Prototypen Spike Solution Story Schätzung Systemtest / Produktion Kunde Entwicklung Agiles Vorgehensmodell Vergleiche: Vortrag „eXtreme Programming (XP)“ vom 12.06.2006