V-Methode, RUP, Waterfall oder was?

Größe: px

Ab Seite anzeigen:

Download "V-Methode, RUP, Waterfall oder was?"

Nelly Schmidt
vor 8 Jahren
Abrufe

1 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

2 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

Allgemeine Ansätze von Vorgehensmodellen e) Verbreitete Vorgehensmodelle 2.

3 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

Projektziel erreicht werden kann b) liefert Festlegungen für: a) Projektphasen mit Meilensteinen b)

4 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

Projektergebnisse Minimierung von Projektrisiken Möglichkeit, Erfahrungen zum Vorgehen zu sammeln und zu verbessern

5 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

Skalierbarkeit hinsichtlich unterschiedlicher Projektgrößen Berücksichtigung neuester Standards, Vorschriften und Normen

6 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

7 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

Agile Methoden (Crystal, ASD, Scrum, Arte, XP, ) Unternehmensspezifische Prozesse

8 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

ein Ergebnis Der Ablauf ist streng sequentiell Integration (Abnahme-) Test

9 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

Risikomanagement möglich Wenn die Anforderungen instabil sind oder ständig neue

10 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

Spezifikation Konstruktion Integration Implementierung Systemtest Einführung 2 Spezifikation Konstruktion Integration

11 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

verzichtet (YAGNI - you aren t gonna need it) Kunde ist bei der gesamten Entwicklung dabei ( on-site customer ) Extrem kurze Zyklen für Anforderungsanalyse,

12 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

(z.b. Lieferantenwechsel) nur schwer möglich Der Erfolg ist stark

13 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

Projektergebnisse mit allen Abhängigkeiten untereinander Vorgehensweisen für alle Ergebnisse in allen

14 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

-steuerung wird auf der Basis der Bearbeitung und Fertigstellung von Produkten durchgeführt.

15 Beispiel einer Projektdurchführungsstrategie Quelle: Prof. Dr. A. Rausch, TU Kaiserslautern Folie 15

16 Schnittstelle Auftraggeber / Auftragnehmer Quelle: Prof. Dr. A. Rausch, TU Kaiserslautern Auftraggeber Auftragnehmer Folie 16

17 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

Umfangreiches Angebot an IBM / Rational Tools Die Notation ist UML-basiert

18 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

Implementierung 5. Test 6. Softwareverteilung 7.

19 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

Spezifikation o Geschäftsprozesse o Anwendungsfälle o Anforderungen Entwicklung o

20 RUP Iterationen und Phasen Folie 20

21 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

22 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

23 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

Ähnliche Dokumente

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.1 Wie kommt es zu einem Projektauftrag? Auftraggeber Projekt-Idee / Ziele [Anforderungen/Spezifikation/