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

Agenda Besonderheiten von Softwareprojekten Qualitätsmanagement A6: Berichte der Projektleiter der Teams 2 und 6 Verhandlungsmanagement nach dem Harvard-Konzept Konfigurations- und Änderungsmanagement (Change-Management) Vertrags- und Claimmanagement (Nachforderungsmanagement) Anforderungsmanagement (Requirementsmanagement) A6: Berichte der Projektleiter der Teams 1 und 7 Projektportfoliomanagement Reifegradmodelle im Projektmanagement Projekterfolgsfaktoren

Organisatorisches: Termine Vorträge können auch auf Englisch gehalten werden Organisatorisches: Termine V2 Lösung Aufgabe 1 V3 2 V4 3 V5 4 V6 5 MS 1: Abnahme „Planung und Aufgaben- Verteilung“ MS 2: Prototyp Abschluss- Präsen- tation Abgabe CD-ROM 30.04. 7.5. 21.5. 4.6 18.6. 16.7. 14.5. 11.6. V1 16.04. V7 Lösung A 6 Projekt- bericht 9.7 Projektdokumentation x: Präsentation PL V: Vortrag aktuelles PM-Thema

Projektbericht Abgabedatum für gedruckte Papierversion: 9.7.2007 Für Teilnehmer mit benotetem Schein Erstellte Kapitel in Farbschrift kennzeichnen Name in gleicher Farbe auf dem Titelblatt Anlagen: Pflicht Jour fixe Wochenprotokolle 1 – 6 Unterschriebene Arbeitszeitprotokolle (Mai - Juli 2007) aller Teammitglieder

Abschlussveranstaltung: Agenda Projektiade´07 13:30 Begrüßung 13:35 Hr. Markus Wolf; Projektleiter Businessplan Netzwerk Nordbayern 13:50 Teams 1, 2, 3 und 4 15:10 Pause 15:20 Teams 5, 6 und 7 16:00 Hr. Jörg Kaiser: „Kaiserschmarrn“ (Fränkisches Kabarett) anschließend Jury-Bewertung 16:40 Preisverleihung „Projekta 2007“ 17:00 Ende

Abschlusspräsentation Projektiade´07 Folienteil (im Sinne eines Elevator Pitches) Produktbeschreibung mit den wichtigsten Businessplandaten (Motivation, Nutzen, Zielgruppen etc.) Projektnachbetrachtung (aus letzter jour fixe-Sitzung) Vergleich: geschätzter Aufwand – tatsächlicher Aufwand der Teammitglieder (Tabellenform) Erfahrungen: Teamarbeit & MS Project (jeweils die 3 wichtigsten) „Lessons learned“ für Folgeprojekte Dauer: Ca. 5 Minuten Produktvorführung – live Vorstellung der wichtigsten Funktionalitäten Technische Anmerkungen / Besonderheiten Dauer: Ca. 10 Minuten Hinweise: Präsentation durch zwei TeammitgliederInnen Gesamtdauer von max. 15 Minuten einhalten!

Preisverleihung „Projekta 2007“ Projektiade´07 Die besten Projektarbeiten zur Gründung eines „neuen innovativen Internet-Unternehmens“ werden von der Jury mit der „Projekta 2007“ prämiert   Kategorien: Innovativstes Produkt Beste Produktpräsentation Beste Projektdurchführung Projekta 2007

CD-ROM Abgabe: 16.07.2007 (vor der Abschlussveranstaltung) Inhalte Projektbericht Produkt

Vorlesungsscheine Scheine Durchsicht der Projektberichte und Prüfung der SW-Produkte: bis 20.07.2007 (Freitag); ggf. Nacharbeiten erforderlich! Abholung der Scheine bei Frau Förster, Sekretariat Informatik III: ab 25.07.2007 (Mittwoch) Scheine Informatiker: Kleines Projektpraktikum (alternativ: Seminarschein) BWL: Fachübung Sonstige Fachbereiche: Seminarschein Benotete Scheine: Name mit Team-Nummer (prüfen) Bebber (6) J. Brand (6) Brucker (5) Hofmann (4) Krauß (7) Krupp (2) Mlodawska (1) Patala (5) Reschke (1) Wenzel (5) Wozniak (2)

Zertifizierung von Projektpersonal (Qualitäts-nachweis Zertifizierung von Projektpersonal (Qualitäts-nachweis!) hat wachsende Bedeutung International anerkannte Kompetenzzertifikate im Projektmanagement Zertifizierung nach IPMA (International Project Management Association) Umsetzung durch die nationalen Projektmanagement-Institutionen; in D: Deutsche Gesellschaft für Projektmanagement e.V. (GPM) Nutzen einer Zertifizierung Objektive, neutrale Bestätigung der Projektmanagement-Kompetenz Führen eines anerkannten Titels Berufliche und persönliche Anerkennung Verbesserung der Chancen am Markt (vgl. Vortrag 1) 4-L-C (4-Level-Certification-System der IPMA) Die Zertifizierung durch eine nationale oder internationale PM-Institution gewinnt zunehmend an Attraktivität. Sie trägt dazu bei, dass PM als eigene Qualifikation wahrgenommen wird und definiert allgemein anerkannte Qualitätsstufen. Die bekannteste ist die Zertifizierung nach IPMA (international project management association) IPMA Level D: Zertifizierter Projektmanagementfachmann (GPM) IPMA Level C: Zertifizierter Projektmanager (GPM) IPMA Level B: Zertifizierter Senior Projektmanager (GPM) IPMA Level A: Zertifizierter Projektdirektor (GPM)

Vorlesung hat CoE-Zertifikat: Nutzen für Vorlesungsteilnehmer Vorlesung wurde Anfang 2007 mit dem CoE (Certificate of Excellence) der GPM ausgezeichnet Ziele (CoE) 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 Vorteile für StudentInnen IPMA-Level D Zertifizierungsgebühr: 350 €* bzw. 400 €* (statt: 650 €) Fachbuch ProjektManager (GPM): 69 € (statt: 169 €) Die Zertifizierung durch eine nationale oder internationale PM-Institution gewinnt zunehmend an Attraktivität. Sie trägt dazu bei, dass PM als eigene Qualifikation wahrgenommen wird und definiert allgemein anerkannte Qualitätsstufen. Die bekannteste ist die Zertifizierung nach IPMA (international project management association) 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) *) plus 50 € Verwaltungsgebühren

PM-Zertifizierung: Ablauf und Termine Ablauf (Details siehe Vorlesungswebsite: PM-Zertifizierung) Transferprojekt (Projektbericht) einreichen; eigenen Part farblich kennzeichnen Voraussetzung zur Zulassung zur Prüfung: mind. 30 von 60 Punkten Zertifizierungsworkshop 2-stündige schriftliche Prüfung (bestanden bei > 50% der zu erreichenden Punkte) 30-minütiges Prüfungsgespräch Prüfung für Teilnehmer SS 06 und SS07 geplant für: 8. Oktober 2007 in Würzburg (Uni Würzburg) (sofern hinreichend viele BewerberInnen) Verbindliche Anmeldung per Mail an Dozenten bis zum 16.07.2007 mit folgenden Angaben: Name, Vorname, Anschrift, Mail, Tel. Falls genügend Interessenten: Vorbereitungsworkshop vor dem 8.10.07

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 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 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 wenig geändert. *) Quelle: CHAOS Report, Standish Group International, Inc http://standishgroup.com

Warum diese gewaltigen Probleme in der IT-Branche? Workshopteil Schwierigkeiten in der Kommunikation Nicht-ITler - ITler Kostenexplosion durch falsche Einschätzung/ falsche Planung Aufwand lässt sich nur sehr schwer schätzen Rasante technische Entwicklungen überholen das Projekt Schlechte OOA und OOD Hohes Abstraktionsniveau Mögliche Ursachen? (SS 05) 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 Mögliche Ursachen? (SS 04) Fachfremde Führung Zu wenig Erfahrung Schlechte Schätzungen Dynamik wird häufig unterschätzt Koordinationsprobleme Wechsel / Ausfall von Mitarbeitern Mögliche Ursachen? (SS 06) Unterschiedliche Fachbereiche Zeitabschätzung für Programmierung Unklare Kundenwünsche Unterschiede zwischen Kundenanforderung und technischer Machbarkeit Technische Probleme bei der Programmierung Schlechte Planbarkeit Technische Umwelt verändert sich

Welche Lösungsansätze sehen Sie? Workshopteil Erfahrene Personen für Aufwandschätzung einsetzen Puffer einplanen und ständig justieren Klare Zielbestimmungen Wirtschaftsinformatiker zur Kommunikation mit den Non-ITlern einsetzen Lösungsansätze SS 06 Intensive Briefings in der Startphase mit den Fachbereichen Agiles Projektmanagement Klare Verantwortlichkeiten geringe Pufferzeiten Feste Vorgaben für Prozessvorgänge Lösungsansätze SS 05 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 Lösungsansätze SS 04 Bessere Kommunikation Manager, die sowohl betriebswirtschaftliche, technische und soziale Kompetenz haben, als Projektmanager Einstellung als Dienstleister Verstärktes Risikomanagement Intensives Einbeziehen der Kunden

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 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 , 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 (Requirements-Management) Pflichtenheft Aufwandsschätzung für Softwareprojekte Konfigurationsmanagement Change-Management

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

Was ist wann von wem zu tun? Vorgehensmodelle Was ist wann von wem 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 Welche Aktivitäten in Welcher Reihenfolge von Welchen Personen/Rollen 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 Quelle: 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 Vorgehensmodell. Wichtig ist, dass alle 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) Agiles Vorgehensmodell 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

eXtreme Programming (XP)