The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert

Größe: px

Ab Seite anzeigen:

Download "The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert"

Angela Böhmer
vor 8 Jahren
Abrufe

1 The Rational Unified Process Eine Einführung von T. Langer und A. Nitert

2 Übersicht Einleitung Probleme der SW-Entwicklung, Best Practices, Aufgaben Was ist der Rational Unified Process? Struktur des Prozesses 1. und 2. Dimension (dynamischer, statischer Aspekt), Architektur zentriert, Use Case getrieben Kern-Workflows Requirements, Analysis and Design, Implementation,Test

Dimension (dynamischer, statischer Aspekt), Architektur zentriert, Use Case

3 Probleme der SW-Entwicklung - Hauptursachen ad hoc Anforderungssammlung mehrdeutige unpräzise Kommunikation zerbrechliche Architekturen überwältigende Komplexität unentdeckte Inkonsistenzen subjektive Einschätzung des Projektstatus Versagen bei der Bekämpfung von Risiken unkontrollierte Verbreitung von Änderungen unzureichende Automatisierung

unentdeckte Inkonsistenzen subjektive Einschätzung des Projektstatus Versagen bei der

4 Software Best Practices ❶ Software iterativ entwickeln (Spiralmodell von Boehm) ❷ Anforderungen verwalten (Dokumentation der Funktionen, Veränderungen verwalten, Dokumentation von Entscheidungen) ❸ Komponentenbasierte Architekturen verwenden (verschiedene Sichtweisen berücksichtigen, kommerzielle Komponenten) ❹ Software visuell modellieren (UML, eindeutige Kommunikation) ❺ Qualität der Software verifizieren (fortlaufende Einschätzung der Qualität durch iteratives Testen) ❻ Veränderungen an der Software kontrollieren (Koordination von Tätigkeiten und Teilprodukten mittels Workflows)

berücksichtigen, kommerzielle Komponenten) ❹ Software visuell modellieren (UML, eindeutige Kommunikation) ❺ Qualität der Software verifizieren

5 Rollen eines SW-Entwicklungsprozesses Anleitung über die Ordnung der Team-Aktivitäten liefern Spezifizieren von Art und Zeitpunkt der Erstellung von Teilprodukten Aufgaben einzelner Entwickler und des gesamten Teams lenken Kriterien für die Überwachung und Messung der Projektprodukte und -aktivitäten anbieten Ziel qualitativ hochwertige Software in einer vorhersagbaren und wiederholbaren Art und Weise entwickeln

des gesamten Teams lenken Kriterien für die Überwachung und Messung der Projektprodukte und

6 Was ist der Rational Unified Process? (I) RUP ist ein Software Engineering Prozeß regelt Aufgaben und Verantwortlichkeiten innerhalb einer Entwicklungsorganisation mit dem zuvor beschriebenen Ziel RUP ist ein Prozeßprodukt bestehend aus einer Online Version (HTML-basierend) Werkzeug-Ratgeber (tool mentors), die zusätzliche Prozeßunterstützung bieten Vorlagen für alle größeren Prozeß-Teilprodukte (artifacts, u.a. für Rational SoDA, RequisitePro, Word, Project, FrontPage) und einem Satz von Handbüchern

mit dem zuvor beschriebenen Ziel RUP ist ein Prozeßprodukt bestehend aus einer Online Version (HTML-basierend)

7 Was ist der Rational Unified Process? (II) Kennzeichen des Prozeßprodukts regelmäßige Upgrades werden veröffentlicht online verfügbar über Web-Technologie kann maßgeschneidert werden integriert in viele SW-Entwicklungswerkzeuge des Rational Suite Vorteile des Prozeßprodukts Verteilung der aktuellen Version an alle Projekt-Mitglieder via Intranet Direkte Verfügbarkeit von Schlüsselinformationen über Index und Suchmaschine Navigation zwischen Teilen des Prozesses (Verzweigung zu Tools) Einfache Einbindung von projektspezifischen Prozeßverbesserungen Versionskontrolle und Verwaltung von Varianten des Prozesses in verschiedenen Projekten

viele SW-Entwicklungswerkzeuge des Rational Suite Vorteile des Prozeßprodukts Verteilung der aktuellen Version an alle Projekt-Mitglieder via Intranet Direkte

8 Was ist der Rational Unified Process? (III) RUP hat einen Prozeß-Framework kann an die speziellen Bedürfnisse der Organisation angepaßt und erweitert werden RUP deckt die sechs zuvor beschriebenen Software Best Practices ab

9 Die Prozeßstruktur Organisation bzgl. Zeit (1. Dimension) Organisation bzgl. Inhalt (2. Dimension)

10 Die dynamische Struktur Best Practice Iterative Softwareentwicklung Jede Iteration enthält Anforderungsanalyse Design Implementierung Meilensteine

11 Iterative Softwareentwicklung Phasen und Meilensteine des iterativen Prozesses:

12 Iterative Softwareentwicklung Vorteile zum klassischen Wasserfallmodell Verminderte Risiken Änderungen sind besser handhabbar Höherer Wiederverwendungsgrad Bessere Gesamtqualität des Produkts

13 Die statische Struktur Statische Prozeßbeschreibung mit Komponenten Worker (wer) Aktivitäten (wie) Workflows (wann) Artefakte (was)

14 Worker, Aktivitäten, Artefakte

15 Ein Architektur-Zentrierter Prozeß Definition der Architektur Sichtweisen auf eine Architektur Architekturzentrierung im Prozeß Zweck einer Architektur

16 Definition der Architektur Umfaßt Entscheidungen über die Organisation des Software-Systems die Auswahl der Strukturelemente und Schnittstellen die Zusammensetzung der o.g. Elemente den Architekturstil Best Practice Verwendung komponentenbasierter Architekturen

Strukturelemente und Schnittstellen die Zusammensetzung

17 Sichtweisen auf eine Architektur Unterschiedliche Sichtweisen Die 4+1 Sicht des R.U.P.

18 Architekturzentrierung im Prozeß Artefakte im Zusammenhang mit der Architektur Software-Architektur-Beschreibung Architekturprototyp Verantwortung für die Architektur Der Worker Architekt Andere Mitglieder des Projektteams

Software-Architektur-Beschreibung Architekturprototyp

19 Zweck einer Architektur Intellektuelle Kontrolle Wiederverwendbarkeit Entwicklungsbasis

20 Use-Case-gesteuerter Prozeß Allgemeines zu Use-Cases Beispiel eines Use-Cases Das Use-Case-Modell Use-Cases im Entwicklungsprozeß

21 Allgemeines zu Use-Cases Bringen das Verhalten des Systems zum Ausdruck Werden von fast allen Stakeholdern verstanden Verbinden Systemanforderungen und andere Artefakte Grundlage des R.U.P.

22 Beispiel eines Use-Cases

23 Das Use-Case-Modell Modell der Systemfunktionen und deren Umgebung Erfaßt die gesamte Funktionalität des Systems Ist eine Art Vertrag zwischen Kunden und Entwicklern Enthält Use-Cases und nichtfunktionale Beschreibungen

24 Use-Cases im Entwicklungsprozeß Grundlage für den gesamten Entwicklungsprozeß

25 Kern-Workflows Die Kern-Workflows sind Requirements, Analysis and Design, Implementation und Test. Beschreibung Zweck Worker und Artefakte Workflow

26 Requirements Workflow (Zweck) Übereinstimmung mit dem Kunden und Benutzer darüber, was das System leisten soll Systementwickler erhalten ein besseres Verständnis über die Anforderungen des Systems Funktionalität des Systems definieren Grundlage für die Planung der techn. Inhalte der Iterationen Grundlage für Kosten- und Zeitabschätzung Benutzerschnittstelle definieren Der Requirements Workflow beschreibt wie eine Vision des Systems definiert und in ein Use-Case-Modell umgewandelt wird.

27 Requirements Workflow (Worker und Artefakte)

28 Requirements Workflow

29 Analyse und Design Workflow (Zweck) Übertragung der gesammelten Anforderungen in ein Dokument, das die Implementierung beschreibt Analyse erstellt ein nahezu ideales Bild des Systems Design optimiert den Entwurf des Systems und stellt die Einhaltung sämtlicher Anforderungen sicher

30 Analyse und Design Workflow (Worker und Artefakte)

31 Analyse und Design Workflow

32 Der Implementierungs-Workflow Ziele Definiert die Organisation des Quellcodes Implementierung von Klassen und Objekten in Form von Komponenten Testen einzelner Einheiten Integration der Ergebnisse in ein Subsystem

33 Der Implementierungs-Workflow (Worker und Artefakte)

34 Ein Implementierungs-Workflow

35 Der Test-Workflow Zweck des Test-Workflows Bewertung und Beschreibung der Testlaufergebnisse Prüfen der erreichten Qualität Best Practice Prüfung der Softwarequalität

36 Das Testmodell (Beispiel)

37 Der Test-Workflow (Worker und Artefakte)

38 Ein Test-Workflow

Ähnliche Dokumente

Grundlagen Software Engineering

Grundlagen Software Engineering Rational Unified Process () GSE: Prof. Dr. Liggesmeyer, 1 Rational Unified Process () Software Entwicklungsprozess Anpassbares und erweiterbares Grundgerüst Sprache der