Rational Unified Process

Präsentation zum Thema: "Rational Unified Process"—  Präsentation transkript:

1 Rational Unified Process
Franz-Josef Herpers 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] seit 1994 laufende Studie

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 sequentielle Projektphasen, am Ende jeder Phase steht Dokument (dokumentengetrieben), top-down-Vorgehen, wenig Management-Aufwand/einfach, Benutzerbeteiligung nur in Definitionsphase Verifikation = Überprüfung der Übereinstimmung zwischen einem Software-Produkt und seiner Spezifikation (Wird ein korrektes Produkt entwickelt?) Validierung = Überprüfung der Eignung bzw. des Werts eines Produkts bezogen auf seinen Einsatzzweck (Wird das richtige Produkt entwickelt?) Rückkopplungen werden auf angrenzende Stufen begrenzt, um teure Überarbeitungen über mehrere Stufen zu vermeiden

7 V-Modell Fügt dem Wasserfallmodell die systematische Qualitätssicherung hinzu Historie Entwickelt von der IABG (Industrieanlagen-Betriebsgesellschaft) i.A. des BMVg

8 Spiralmodell evolutionär, risikogetrieben Barry Boehm '86

9 Was ist der RUP? Methode Prozess Produkt
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 Das Wie im Prozess wird hauptsächlich durch Methode festgelegt(?) Was ist Architektur? (=>Kap. 7 und Kruchten2000a) - Skelettstruktur des Systems - Building Blocks (Subsysteme, Komponenten) und Schnittstellen - Architekturmechanismen wie Garbage Collection, Persistenz, Messaging

10 Historie RUP

11 Die drei Amigos Booch OOSE OMT Grady Booch Ivar Jacobson
James Rumbaugh OMT = Object Modeling Technique OOSE = OO Software Engineering Booch OOSE OMT

12 UML - Entwicklung März 2003: UML 1.5 2001: UML 1.4 UML 2.0 WG UML 1.5
kleinere Veränderungen UML 2.0 WG - erwartet im Sommer 2003 - verbesserter Modellaustausch - verbesserte Unterstützung MDA - verbesserte Unterstützung Echtzeitmodellierung (RT) - verbesserte Unterstützung Geschäftsprozessmodellierung (BPM) z.B. Erweiterung Aktivitätsdiagramme (z.B. mehrere Anfangszustände)

13 Einflüsse und Historie RUP
Der RUP wurde nicht von heute auf morgen eingeführt, sondern hat sich entwickelt Man sieht die Einflüsse auf RUP halbjährlich neue Versionen Objectory Process entwickelt 1987 in Schweden von Jacobson aufgrund seiner Erfahrungen bei Ericsson wurde in Jacobsons Firma Objectory AB zum Produkt 1995 Fusion Objectory und Rational Rational: iterative Entw. u. Architekturbegriff Objectory: Prozessstruktur u. Use Cases

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 Anforderungsmanagement Use-Case-getrieben Vorteil:
a) Mittel zur Kommunikation der Afos mit Kunden b) Projektmitglieder können beim Design, der Implementierung und beim Test sowie dem Schreiben der Handbücher sehr nahe an den Afos arbeiten Use Component Architectures - Funktionale Dekomposition trennt zwar Daten von Funktionen, aber dafür sind in der Regel alle Funktionen betroffen, wenn sich die Art der Datenspeicherung ändert (S. 41 Kroll/Kruchten 2003) - Bei komponentenbasierter Architektur sind Funktionen und Daten in einer Komponente zusammengefasst - Kommunikation zwischen Komponenten erfolgt über die Schnittstellen, nur diese muss man kennen (Wartbarkeit interner Komponentenstruktur!!, Kapselung als Schlagwort) - WebServices als Internet-enabled Komponenten Qualitätsmanagement durch Iteration frühes Testen möglich! Regressionstest (Tests existierender SW, um sicher zu gehen, dass keine neuen Fehler eingebaut wurden) Testen gleich nach der Implementierung Quality by Design => Generieren von Testcode aus dem Design heraus (frühes Nachdenken über Tests) Der Kosten wegen ist Automatisierung nötig insbesondere bei Regressionstests Reviews der Artefakte nach der Erstellung Qualität ist nicht nur eine Aufgabe des Testteams, sondern jedes Projektmitglieds Control Changes Änderungen positiv sehen. Moderne SW-Systeme sind nämlich zu komplex, als dass man sie im ersten Wurf richtig spezifizieren könnte. Die Änderungen müssen aber kontrolliert werden, wenn ein Projekt fertig werden soll. Auch Änderungen in fortgeschrittnen Projektphasen sind problematisch. Ziel muss es sein, die Kosten zu minimieren und die Freiheit Änderungen einzubauen zu maximieren. Es gibt dabei verschiedene Typen von Änderungen, die je nach Projektphase unterschiedliche Kosten verursachen Änderungstypen: - Änderungen an Geschäftsprozessen - Änderungen an Architektur - Änderungen am Design und Implementierung - Änderungen am Projektumfang Manage the changes - Have procedures in place for approving whether to introduce a change (Change Control Boards) - Be able to assess the impact of change (Req-Traceability!!) - Minimize the cost of change (Tools, automatische Synchronisierung zwischen Code und Design)

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 Iteration = Arbeitseinheit, 'Miniprojekt' Focus auf ausführbarer Software! Risiken: 1) Keine Erfahrung in der Entwicklung mit .NET 2) Noch unklar, wie die Integration mit einem Legacy-System funktionieren soll 3) Erfahrung mit Stammkunden, dem immer noch Requirements nach Beta-Release einfallen 4) Schnittstelle zu Legacy-System könnte Performance-Probleme aufwerfen Risikominimierung: (Wegwerf-)Prototyp zum Test Risikovermeidung: Schnittstelle aus Projectscope rausnehmen 5) Projektteam ist unerfahren in der Entwicklung mit RUP 6) Evtl. zieht sich die Entw. in neues Kalenderjahr => Kunde kann sie nicht im alten Jahr abrechnen 7) Eine Entwickler-Position ist nach 2 Wochen immer noch unbesetzt 8) Bestimmte Anforderungen werden in Construction-Phase immer noch nicht erfüllt!

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 Dynamische Struktur - statische Struktur

22 Dynamische Struktur: Phasen
Inception Elaboration Construction Transition LCO LCA IOC PR Phasen = Lebenszyklus des Projekts Struktur = Dimension, Lebenszyklus, zeitliche Dimension LCO = Lifecycle Objective Milestone LCA = Lifecycle Architecture Milestone IOC = Initial Operational Capability Milestone PR = Product Release Milestone 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) Stakeholder = Teilhaber Stakeholder ======== Alle am Projekt Interessierten: - direkt Betroffene (Benutzer) - indirekt Betroffene (Kunden, Öffentlichkeit) - Entwickler - Firmenleitung - Aufsichtsorgane (Datenschutz, Revision) Oft im Projektlenkungssausschuss alle vertreten Die Kriterien für den LCO-Meilenstein ergeben sich aus den Punkten Bsp. für 2 Iterationen in der Inception-Phase: E-Akte => Workflow

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) evtl. auch Wegewerfprototypen um Trade-Offs, Wiederverwendung und Machbarkeit zu testen/demonstrieren (Risikominimierung)

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
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
s. Kap Kroll/Kruchten 2003

33 Alle Artefakte außer der SW selbst sind nur Unterstützung!
Artifact (Artefakt) Modell Modellelement Dokument Source Code Executables Trade-Off zwischen Kosten der Erstellung und Wartung von Artefakten und dem späteren Gewinn daraus. Typischerweise wächst der Gewinn mit zunehmender Komplexität des Projekts Modell => Report Projektkomplexität - komplizierte Stakeholder-Beziehungen - verteiltes Team - Kosten der Qualitätsthemen wachsen - Software ist kritisch für das Geschäft des Kunden Guideline sollte keine Entschuldigung sein, essentielle Artefakte wie Vision, Afo-Doku, Design-Doku usw. nicht zu erstellen. Vielmehr sollte es immer um den ROI gehen. Metapher: RUP als Buffet. Essen sollte man nur die Lieblingsgerichte, alles schafft man eh nicht 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 Requirements Analysis & Design
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 Design The design model consists of design classes structured into design packages and design subsystems with well-defined interfaces, representing what will become components in the implementation. It also contains descriptions of how objects of these design classes collaborate to perform use cases. Design Purpose To transform the requirements into a design of the system to-be. To evolve a robust architecture for the system. To adapt the design to match the implementation environment, designing it for performance Implementation purpose to define the organization of the code, in terms of implementation subsystems organized in layers, to implement classes and objects in terms of components (source files, binaries, executables, and others), to test the developed components as units, and to integrate the results produced by individual implementers (or teams), into an executable system. Testing purpose To verify the interaction between objects. To verify the proper integration of all components of the software. To verify that all requirements have been correctly implemented. To identify and ensure defects are addressed prior to the deployment of the software.

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 Project Management (iteratives Planen!) traditionell: top-down und product breakdown => Produktstruktur und zu erstellende Artefakte müssen zu Beginn des Projekts antizipiert werden, obwohl man fast noch nichts über das Produkt weiss iterativ: process breakdown (Phasen und Iterationen) Cycle-Phase-Iteration-Build-Time-Boxing Projektplan = Phasenplan dazu ein Plan pro Iteration

38 Beispiel Core Workflow

39 Beispiel Detailed Workflow
Activities => Steps

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 - V-Modell gibt es in deutsch und englisch, den RUP nur in englisch - V-Modell ist frei verfügbar

45 RUP und andere Modelle CMM CMMI RUP Process Framework XP Wasserfall
Formalität Agilität RUP Process Framework Wasserfall: Few risks, sequential, late integration and testing Agilität: Little documentation, light process Formalität: Well-documented, Traceability, CCB Iterativ: risk-driven, continous integration and testing CMM und CMMI vgl. Kapitel 3 Light RUP Konfiguration Durchschnittl. RUP Konfiguration Formale RUP Konfiguration Iterativ

46 Das Produkt RUP

47 RUP-Plattform RUP Knowledge Center RUP-Diskussionsforen RUP Exchange
Get Started Guides andere Ressourcen RUP-Diskussionsforen RUP Exchange Plugin-Austausch Rational University Training Consulting Services Rational Process Workbench Eigene Plugins entwickeln Tailoring von RUP Kopplung mit Rational Rose extra zu lizensieren Development Kit RUP-Plugins Small RUP RUP for .NET RUP for J2EE RUP-Builder Installation von Plugins Konfiguration der RUP-Webseite Webbasierte, durchsuchbare Wissensbasis Guidelines Tool mentors Beispiele SoDA-Templates Word-Templates MS-Project-Pläne Die webbasierte anpassbare und leicht wieder publizierbare Form des RUP ist Gold wert und sollte nicht unterschätzt werden. Tailoring des RUP - Konfiguration - Instanziierung - Anpassung Konfiguration des RUP 1. Erstellen der RUP Prozesskonfiguration 2. Erstellen der Prozessviews Konfiguration - RUP Process Component - RUP Library - RUP Base - RUP Plug-In A RUP Plug-In is a set of "precompiled" RUP Process Components, ready to be "linked" into a RUP Base to create one or more RUP Configurations. => RUP Builder, RUP Exchange Process Views werden auch im RUP Builder erstellt weitere Personalisierung auch über MyRUP (that is the Web browser used to browse RUP) Anpassung von RUP-Templates ist auch möglich Instanziierung RUP Development Case Projekt-Webseite (you may want to use the Project Web Template that comes with the RUP product as a starting point, Alternative: Rational ProjectConsole, which is a Rational Suite componentthat will automatically extract information from Rational tools and third-party tools to build a project Web site for you with information about all current artifacts. Anpassung - Thin RUP Plug-Ins (changing content files for existing process elements) => RUP Organizer - Structural RUP Plug-Ins (changing process elements and their relationships) => RUP Modeler RUP Process Workbench - RUP Organizer - RUP Modeler (add-in to Rational XDE and works in conjunction with RUP Organizer

48 Das RUP-Framework

49 Rational Tool Suite Rational RequisitPro Rational ClearQuest
=> Requirements Management Rational ClearQuest => Change Management Rational TestStudio => Automated Testing Rational Rose => Visual Modeling und viele andere..... Testing Tools bei Veerhegen S. 64/65

50 RUP bei Rational/IBM heute
Alles Rational Initiativen Unified Lifecycle Unified Lifecycle tools are delivered through the Rational Suite® product family. The industry's first end-to-end life-cycle management solution provide a comprehensive software development platform for analysts, system architects, software developers, quality assurance engineers, Webmasters, and real-time software developers. Unified Change Management Unified Change Management is Rational's "best practices" process for managing change from requirements to release. Eng mit den Rational Tools Clear Case und Clear Quest Rational Development Accelerators Rational Development Accelerators enable development teams to jumpstart their application development process through reuse standards, reusable frameworks and enhanced automation designed to increase the flexibility and predictability of development projects. Reusable Asset Specification (toolunabhängig) As part of this initiative, we are delivering tools that extend the capabilities of the core Rational solution. These integrated tools focus on helping you manage and apply reusable assets so that you gain maximum leverage from your precious organizational and technical knowledge. Rational Development Accelerators also include sample and reference assets, which provide examples to help make best practices tangible, and provide a path towards systematic reuse of software assets. Finally, Rational Development Accelerators incorporate the standards and process guidance to extend the Rational solution to include reuse and related architecture subjects. By accelerating your adoption and application of Rational tools and process, you will be able to build solutions faster. Quality by design The Quality by Design initiative from Rational makes it easier to continuously detect and repair software problems during the development process, from early design and through every iteration. Several Rational products support this initiative, Rational QualityArchitect, Rational TestManager, Rational PurifyPlus RealTime, Rational PurifyPlus Family and Rational Test RealTime. Rational Unified Software Project Management Unified Software Project Management (USPM) is a Rational-wide initiative to help customers effectively deploy, plan, execute and monitor software engineering projects. - select and deploy best practices (RUP, Rational Workbench) - plan and execute iterative Development (Rational RequisitePro® creates project tasks from your requirements, and Rational ClearQuest ProjectTracker creates To-Do lists (activities) from those same tasks. ) - measure progress and quality (Rational ProjectConsole, available as part of the Rational Suite Team Unifying Platform, enables you to easily quantify current project status with objective metrics, graphically presented.) - collaborate and communicate project information (The USPM initiative enhances team communication with a dynamically-generated project Web site via Rational ProjectConsole.) Rational Suite Extensibility Each application has its own API for retrieving stored information. Until now, customers, Independent Software Vendors (ISVs), and system integrators have needed to use a separate API to gain programming access to each tool in Rational Suite. The vision of Rational Suite Extensibility (RSE) is to provide unified access to Rational Suite through a common API (Application Program Interface).