5. Bayerischer IT-Rechtstag am 26. Oktober 2006 auf der SYSTEMS 2006 in München Übersicht über die verschiedenen Vorgehensmodelle Dr. Sarre & Schmidt EDV-Sachverständige, München Öffentlich bestellter und vereidigter EDV-Sachverständiger für Systeme und Anwendungen der Informationsverarbeitung Folie 1
Inhalt des Vortrags 1. Einführung a) Was ist ein Vorgehensmodell? b) Nutzen eines Vorgehensmodells im Kontext von IT-Projekten c) Qualitätsmerkmale von Vorgehensmodellen d) Allgemeine Ansätze von Vorgehensmodellen e) Verbreitete Vorgehensmodelle 2. Kurze Vorstellung ausgewählter Vorgehensmodelle a) Wasserfall b) XP c) V-Modell XT d) RUP 3. Auswahlverfahren a) Auswahlkriterien b) Bewertungsverfahren und Auswahlprozess 4. Empfehlungen und Fazit Folie 2
Was ist ein Vorgehensmodell? Ein Vorgehensmodell a) ist eine (mehr oder weniger) genaue Anleitung, in welchen Schritten das Projektziel erreicht werden kann b) liefert Festlegungen für: a) Projektphasen mit Meilensteinen b) Rollen und Verantwortlichkeiten c) Aufgaben / Aktivitäten d) Arbeitsergebnisse e) Einheitliche Begriffe f) QS-Maßnahmen g) evtl. Methoden, Techniken, Werkzeuge, Richtlinien / Standards Folie 3
Nutzen eines Vorgehensmodells (Weitgehende) Planbarkeit Kontrollierte und (weitgehend) einheitliche Durchführung des Projekts Verbesserte Kommunikation im Projekt Senkung von Aufwänden durch Rückgriff auf Erfahrungswerte Höhere Qualität der Projektergebnisse Minimierung von Projektrisiken Möglichkeit, Erfahrungen zum Vorgehen zu sammeln und zu verbessern Insgesamt höhere Wahrscheinlichkeit, dass das Projekt innerhalb festgelegter Qualität, verfügbarem Budget und zum Termin fertig wird Folie 4
Qualitätsmerkmale von Vorgehensmodellen Vollständigkeit Einheitliche und verständliche Begriffswelt Erfolgreiche Erprobung in realen IT-Projekten Änderbarkeit und Erweiterbarkeit Anpassbarkeit an verschiedene Projekttypen und Organisationen Skalierbarkeit hinsichtlich unterschiedlicher Projektgrößen Berücksichtigung neuester Standards, Vorschriften und Normen Werkzeugunterstützung Kompatibilität zu einem organisationsspezifischen Verbesserungsprozess für das Vorgehensmodell (CMMI, SPICE, ) Folie 5
Allgemeine Ansätze von Vorgehensmodellen Aufteilung in Phasen (oft auch detaillierte Beschreibung der Phasen) Anleitungen für die Querschnittsthemen PM, QS, KM, ÄM, RM,? Projektmanagement Qualiätssicherung? Analyse + Angebot Spezifikation Implementierung Konstruktion Abnahme Projektauftrag Integration + Test Konfigurationsmanagement Risikomanagement, Änderungsmanagement,... Folie 6
Verbreitete Vorgehensmodelle 1. Grundmodelle (Wasserfall, V-Modell 97, ) 2. Erweiterungen der Grundmodelle (RUP, V-Modell XT, ) 3. Agile Methoden (Crystal, ASD, Scrum, Arte, XP, ) Unternehmensspezifische Prozesse ITPM (BMW) Aladin (HVB Information Services) SE Book + Books (T-Systems) BUP (Bayerische Landesbank) SEP (Audi / VW) Folie 7
Wasserfallmodell Studie 7 typische Projektphasen Merkmale: Jede Phase muss abgeschlossen sein, bevor die nächste Phase beginnt Jede Projektphase hat ein Ergebnis Der Ablauf ist streng sequentiell Integration (Abnahme-) Test Anforderungsanalyse Systemdesign Implementierung Produktivsetzung Folie 8
Kritik am Wasserfallmodell In den einzelnen Projektphasen ist viel Erfahrungen erforderlich Sichtbares Ergebnis kommt erst sehr spät im Entwicklungsprozess Kaum Risikomanagement möglich Wenn die Anforderungen instabil sind oder ständig neue Anforderungen hinzukommen, ist das Modell ungeeignet Insgesamt wenig Flexibilität Folie 9
Wasserfallmodell für komplexe Projekte Projektmanagement / Projektleitung Qualitätssicherung Angebot Auftrag Projekt- Kick-Off Projektdurchführung Projekt- Touch-Down Konfigurationsmanagement 1 Risiko-Management, Change Management, Spezifikation Konstruktion Integration Implementierung Systemtest Einführung 2 Spezifikation Konstruktion Integration Implementierung Systemtest Einführung Spezifikation Konstruktion Implementierung Systemtest Integration... Einführung Folie 10
XP Wesentliche Merkmale von XP (Extreme Programming): Die Funktionalität des Systems wird in Users Stories zusammengefasst (GUI, Funktionalitäten, Testszenarien) Jeweils zwei Entwickler programmieren gemeinsam ( programming in pairs ) Vor der Entwicklung werden (automatisierbare) Tests erstellt Auf unnötige Features wird verzichtet (YAGNI - you aren t gonna need it) Kunde ist bei der gesamten Entwicklung dabei ( on-site customer ) Extrem kurze Zyklen für Anforderungsanalyse, Design, Implementierung und Test. Ergebnis pro Zyklus ist immer ein lauffähiges Programm ( small releases ) Insgesamt entsteht keine oder nur sehr wenig Dokumentation Folie 11
Kritik an XP Nur für sehr kleine Teams geeignet (< 10 Leute) Projektablauf nur sehr schwer nachvollziehbar Austausch des Teams (z.b. Lieferantenwechsel) nur schwer möglich Der Erfolg ist stark personenabhängig Planbarkeit und Kostenkontrolle ist kaum gegeben Folie 12
V-Modell XT Nachfolgemodell zum bekannten V-Modell 97 Nun überarbeitet durch TU Kaiserslautern und TU München Verbindlich vorgeschrieben für öffentliche Auftraggeber Das V-Modell enthält: Beschreibungen für alle Projektergebnisse mit allen Abhängigkeiten untereinander Vorgehensweisen für alle Ergebnisse in allen Projektabschnitten, auch detaillierte Beschreibung von Aktivitäten Verantwortlichkeiten / Rollen aller Beteiligten Folie 13
Kernpunkte der V-Modell XT Philosophie Projektergebnisse sind der Dreh- und Angelpunkt des Modells (hier Produkte genannt) Projektdurchführungsstrategien und Entscheidungspunkte geben die Reihenfolge der Produktfertigstellung und somit die grundlegende Struktur des Projektverlaufs vor Die detaillierte Projektplanung und -steuerung wird auf der Basis der Bearbeitung und Fertigstellung von Produkten durchgeführt. Für jedes Produkt ist eindeutig eine Rolle verantwortlich und im Projekt dann eine der Rolle zugeordnete Person Die Produktqualität ist überprüfbar durch definierte Anforderungen an das Produkt und explizite Beschreibungen der Abhängigkeiten zu anderen Produkten Folie 14
Beispiel einer Projektdurchführungsstrategie Quelle: Prof. Dr. A. Rausch, TU Kaiserslautern Folie 15
Schnittstelle Auftraggeber / Auftragnehmer Quelle: Prof. Dr. A. Rausch, TU Kaiserslautern Auftraggeber Auftragnehmer Folie 16
RUP RUP (Rational Unified Process) = Software Engineering Prozess auf OO Basis Seit 2002 in den Händen von IBM Wesentliche Merkmale: Iterative Vorgehensweise Umfangreiches Angebot an IBM / Rational Tools Die Notation ist UML-basiert Zahlreiche Templates (Vorlagen) Tailoring-Möglichkeiten Neue Versionen über das Internet verfügbar Folie 17
RUP Workflows RUP definiert Workflows für 9 Themenfelder: 1. Geschäftsprozessmodellierung 2. Anforderungsanalyse 3. Analyse & Design 4. Implementierung 5. Test 6. Softwareverteilung 7. Konfigurations- und Änderungsmanagement 8. Projektmanagement 9. Umgebungsmanagement Projektphasen Querschnittsthemen Folie 18
RUP Arbeitsergebnisse (Beispiele) Projektübersicht o Stakeholder o Problemdefinition o Produkteigenschaften o Grobe Anforderungen o Risiken o Glossar Anforderungen / fachliche Spezifikation o Geschäftsprozesse o Anwendungsfälle o Anforderungen Entwicklung o Organisation o Ressourcen o Aktivitäten o Monitoring o Meilensteine o Risikomanagement Folie 19
RUP Iterationen und Phasen Folie 20
Grobe Bewertung von RUP Vorteile: Sehr geeignet für komplexe Softwareentwicklungsprojekte Hervorragende Unterstützung durch zahlreiche IBM-Tools Sehr gut erprobt Sehr verbreitet Nachteile: Initialaufwand für alle Projektbeteiligten sehr hoch Anpassung an ein konkretes Projekt aufwendig Gefahr der Überfrachtung eines Projekts sehr groß Alle IBM-/ Rational-Tools sind mittlerweile kostenpflichtig Folie 21
Auswahl- / Vergleichskriterien Vorgehensmodell Projekteigenschaften Größe Grad der Verteilung Projektphasen Projekttyp Projektbeteiligte Erfahrung Gesetzliche Vorgaben Qualitätsanforderungen Vergaberichtlinien Steuerliche Vorschriften Aufbewahrungsfristen Unternehmenskontext SOA Lebhaftigkeit des Geschäfts Werkzeugunterstützung Flexibilität der Prozesse Dokumentationserfordernisse Qualitätsanforderungen Sourcing Strategie Branchenbezug Prozessoptimierungsstrategie Folie 22
Empfehlung und Fazit Es gibt nicht das Vorgehensmodell - richtige Auswahl und richtiges Tailoring sind daher entscheidend Bei zunehmender Projektgröße wird die Ergebnisqualität zunehmend durch die Prozessqualität bestimmt Entscheidungen, die für ein Projekt getroffen werden müssen, sind nahezu unabhängig von dem verwendeten Vorgehensmodell! Klar definierte Projektergebnisse können die Schnittstelle zwischen Teilprojekten bilden - notfalls könnte jedes Teilprojekt sein eigenes Vorgehensmodell anwenden Eine enge Verzahnung zwischen IT-Projektverträgen und Vorgehensmodellen ist noch wenig durchdrungen, obwohl die Notwendigkeit sehr hoch ist Folie 23