Rational Unified Process - PowerPoint PPT Presentation

1 / 50
About This Presentation
Title:

Rational Unified Process

Description:

Rational Unified Process Einf hrung Projekte mit Dilbert Software-Projekte in der Realit t 16% aller Projekte scheitern 53% aller Projekte sind nicht in Time bzw. – PowerPoint PPT presentation

Number of Views:112
Avg rating:3.0/5.0
Slides: 51
Provided by: Franz60
Category:

less

Transcript and Presenter's Notes

Title: Rational Unified Process


1
Rational Unified Process
  • Einführung

2
Projekte mit Dilbert
3
Software-Projekte in der Realität
  • 16 aller Projekte scheitern
  • 53 aller Projekte sind nicht in Time bzw. Budget
  • 31 aller Projekte sind erfolgreich
  • Quelle Chaos Report der Standish Group

4
Warum scheitern Software-Projekte?
  • Anforderungsmanagement als Ad-Hoc-Angelegenheit
  • Unpräzise Kommunikation
  • Schwache Architektur
  • Unkontrollierbare Komplexität
  • Inkonsistenzen zwischen Anforderungen, Design und
    Implementierung
  • Unzureichende Tests
  • Subjektive, nicht messbare Projektstatus
  • Kein Fokus auf Projektrisiken
  • Unkontrollierte Änderungsmechanismen
  • Unzureichende Automatisierung

5
Prozessmodelle gegen das Scheitern
  • Wasserfallmodell
  • Spiralmodell
  • V-Modell
  • Rational Unified Process (RUP)

6
Wasserfallmodell
7
V-Modell
8
Spiralmodell
9
Was ist der RUP?
  • Methode
  • iterativ
  • risikogetrieben
  • architekturzentriert
  • Use-Case-getrieben
  • Prozess
  • klar definiert (wer, was, wie, wann)
  • klar strukturiert (Lebenszyklus, Meilensteine)
  • Produkt
  • stellt anpassbares Prozess-Framework zur
    Verfügung
  • zur Unterstützung der Softwareentwicklung

10
Historie RUP
11
Die drei Amigos
Grady Booch
James Rumbaugh
Ivar Jacobson
Booch
OMT
OOSE
12
UML - Entwicklung
März 2003 UML 1.5
2001 UML 1.4
UML 2.0 WG
13
Einflüsse und Historie RUP
RUP 2000
RUP 2002
14
Rational und RUP
  • Aufkauf aller Amigos
  • Aufkauf ergänzender Firmen
  • UML-Entwicklung
  • Entwicklung RUP
  • Kauf von Rational durch IBM (2002)

15
Die Methode RUP
16
Best Practices
17
Iterativ-inkrementelles Vorgehen
  • Ergebnis einer Iteration ein Stück aus-führbare
    Software (Inkrement)
  • Jede Iteration ist zielorientiert(Funktionen,
    Risiko)
  • Jede Iteration setzt auf der vor-hergehenden auf
    (Evolution,Verfeinerung)
  • Frühe Iteration legen den Fo-kus stärker auf
    Anforderungen,spätere auf das Testen

18
Warum Iterationen I?
19
Warum Iterationen II?
  • Leichtere Anpassung an sich ändernde
    Anforderungen
  • Integration ist kein "Big Bang" am Ende des
    Projekts
  • Risiken lassen sich durch früheres Erkennen
    minimieren
  • Mittel für das Management taktische Änderungen am
    Produkt vorzunehmen
  • Wiederverwendung wird erleichtert
  • Fehler können über mehrere Iterationen gefunden
    werden
  • Bessere Verwendung des Projektpersonals
  • Teammitglieder lernen im Projektverlauf
  • Der Entwicklungsprozess selbst wird im
    Projektverlauf verbessert und verfeinert

20
Der Prozess RUP
21
The Big Picture
22
Dynamische Struktur Phasen
Inception
Elaboration
Construction
Transition
LCO
LCA
IOC
PR
Vision
Basis-Architektur
Funktionalität
Freigabe
Meilensteine
23
Inception
  • Abstecken des Projektumfangs (mit Stakeholdern)
  • Vision erstellen
  • Akzeptanzkriterien festlegen
  • Systemumfang festlegen
  • Identifikation der kritischen Use-Cases
  • Architekturskizze evtl. Prototyp (Proof of
    Concept)
  • Kostenschätzung und Planung
  • Einschätzung und Minimierung der Geschäftsrisiken
  • Projektumgebung festlegen (Prozess, Tools)
  • Meilenstein Lifecycle Objective Milestone (LCO)

24
Elaboration
  • Verfeinerung der Anforderungen und der Vision
  • Basis-Architektur (Verfeinerung Skizze)
  • Design
  • Implementierung (evolutionärer Prototyp)
  • Validierung (v.a. gegen Anforderungen)
  • Minimierung v.a. der technischen Risiken
  • Konfiguration der Softwareentwicklungstools
  • Planung der Entwicklungsphase (Iterationen!)
  • Lifecycle Architecture Milestone (LCA)

25
Construction
  • Minimierung der Entwicklungskosten
  • Parallelisierung der Entwicklungsarbeiten (CM!)
  • Iterative Entwicklung eines auslieferbaren
    Release
  • fehlende Use Cases/Afos ermitteln und beschreiben
  • Vervollständigung Analyse/Design
  • Implementierung
  • Integration und Testen (gegen Anforderungen)
  • Initial Operational Capability Milestone (IOC)

26
Transition
  • Erstellen der finalen Version der Software
  • Auslieferung der Software an den Kunden
  • Product Release Milestone (PR)

27
Phasen und Iterationen
  • Phasen
  • enden mit einem Meilenstein
  • enden mit einem Release (da Iterationsende
    Phasenende)
  • Ziele durch feste Meilensteine vorgegeben
  • Iterationen
  • enden mit einem ausführbaren Release
  • zielorientiert (Risiken minimieren, Use Case(s)
    realisieren)
  • Iterationsziele werden NICHT vom Prozess
    vorgegeben, sondern projekt-individuell
  • sind in die Phasen eingebunden (0...N
    Iterationen/Phase)
  • sind relativ kurz

28
Wie viele Iterationen?
29
Statische Struktur Schlüsselelemente
  • Workers (Das Wer?)
  • Activities (Das Wie?)
  • Artifacts (Das Was?)
  • Workflows (Das Wann?)

30
Übersicht Schlüsselelemente
31
Workers and Activities
32
Typen von Workers
  • Analyst
  • Developer
  • Tester
  • Manager

33
Artifact (Artefakt)
  • Modell
  • Modellelement
  • Dokument
  • Source Code
  • Executables

Alle Artefakte außer der SW selbst sind nur
Unterstützung!
Sind Sie im Zweifel, ob Sie ein Artefakt
erstellen sollen, erstellen Sie es nicht!
34
Artefakte und Phasen
35
Workflows
  • Core Workflows
  • Core Supporting Workflows
  • Detailed Workflows

36
Core Workflows
  • Business Modeling
  • Verbindung zw. Business und System (Business Use
    Cases, Business Object Model)
  • Requirements
  • Das Was des Systems (UC, Actors, UC-Beschreibung)
  • Analysis Design
  • Das Wie des Systems (Design Analysis Model)
  • Implementation
  • Das System selbst
  • Test
  • Die Qualität des Systems
  • Deployment
  • Die Auslieferung/Abnahme des Systems

37
Core Supporting Workflows
  • Project Management
  • Framework für das Management von SW-Projekten
  • Praktische Leitfäden für Planung, Staffing,
    Ausführung und Monitoring
  • Framework für Risikomanagement
  • Configuration and Change Management
  • Kontrolle über zahlreichen Prozessartefakte
  • Environment
  • Konfiguration des Prozesses und der Tools

38
Beispiel Core Workflow
39
Beispiel Detailed Workflow
40
Workflows und Phasen
41
Weitere Prozesselemente
  • Guidelines
  • Templates
  • Tool mentors
  • Reports
  • Checkpoints
  • Concepts
  • Roadmaps

42
Übersicht aller Elemente
43
RUP im Vergleich
44
V-Modell und RUP
45
RUP und andere Modelle
Wasserfall
Formalität
Agilität
RUP Process Framework
LightRUPKonfiguration
Durchschnittl.RUPKonfiguration
FormaleRUPKonfiguration
Iterativ
46
Das Produkt RUP
47
RUP-Plattform
  • Webbasierte, durchsuchbare Wissensbasis
  • Guidelines
  • Tool mentors
  • Beispiele
  • SoDA-Templates
  • Word-Templates
  • MS-Project-Pläne
  • Development Kit
  • RUP-Plugins
  • Small RUP
  • RUP for .NET
  • RUP for J2EE
  • RUP-Builder
  • Installation von Plugins
  • Konfiguration der RUP-Webseite
  • Rational Process Workbench
  • Eigene Plugins entwickeln
  • Tailoring von RUP
  • Kopplung mit Rational Rose
  • extra zu lizensieren
  • RUP Knowledge Center
  • Get Started Guides
  • andere Ressourcen
  • RUP-Diskussionsforen
  • RUP Exchange
  • Plugin-Austausch
  • Rational University
  • Training
  • Consulting Services

48
Das RUP-Framework
49
Rational Tool Suite
  • Rational RequisitPro
  • gt Requirements Management
  • Rational ClearQuest
  • gt Change Management
  • Rational TestStudio
  • gt Automated Testing
  • Rational Rose
  • gt Visual Modeling
  • und viele andere.....

50
RUP bei Rational/IBM heute
Write a Comment
User Comments (0)
About PowerShow.com