Der Rational Unified Process - Einführung

Präsentation zum Thema: "Der Rational Unified Process - Einführung"—  Präsentation transkript:

1 Der Rational Unified Process - Einführung
Inhalt Prozessmodelle Der Rational Unified Process Phasen Workflows Iterationen Elemente Tailoring Der RUP im V-Modell Der RUP in der Praxis Annäherung an Objekte von a. Erfahrung aus Technik b. Ansätze aus SE c. Ansätze aus Common Sense oder Philosophie Daraus ableiten: Basiseigenschaften von Objekten und Beschreibung durch UML

2 Das sollten Sie heute lernen
Aufgaben von Prozessmodellen bei der Softwarentwicklung Zusammenhang Aufgabe und Prozessmodell Die Grundideen des Rational Unified Process Phasen im RUP Workflows im RUP Schlüsselkonzepte im RUP Iterationen im RUP Tailoring

3 Motivation Komponentenbasierte Softwaresysteme sind komplexe Gebilde, ihre Erstellung erfordert ausgefeiltes Management Einige Gründe sind Software ist meist einzigartig unter unterschiedlichen Randbedingungen zu entwickeln erfordert die Integration von Altlasten muss den schnellen technologischen Wandel berücksichtigen muss auf Änderung der Anforderungen durch Anwender reagieren soll unterschiedliche Fähigkeiten der Mitarbeiter optimal nutzen Prozessmodelle stellen Erfahrungen und Best Practice zur Verfügung

4 Prozessmodelle als Teil des Management-Prozesses
Analyse Konzept- entwicklung Planung Prozessmodell Organisation PM SW QS KM Personal Leitung Kontrolle Durchführung PM Projektmanagement SE Systementwicklung QS Qualitätssicherung KM Konfigurationsmanagement Bei iterativem Vorgehen und bei Einschluss des Betriebes mehrfacher Durchlauf mit KM

5 Was leisten Prozessmodelle - 1
Software Erstellungsprozess wird transparent Vergabe von Zielen, Wegen, Mitteln, Aufgaben, Rollen Software Erstellung wird überprüfbar Erfüllung der Aufgabe Erreichung der Ziele Aufdeckung von Risiken Beurteilung des Projektfortschrittes Management von Ressourcen wird möglich Kosten Zeit Personen Erfahrungen werden gesammelt und wiederverwendbar Tailoring von Workflows Best Practice Effekt

6 Was leisten Prozessmodelle - 2
Prozessmodelle strukturieren den Vorgang der Software Erstellung Definieren Aktivitäten Legen deren Ergebnisse fest Geben Empfehlungen für die Abarbeitung der Aktivitäten Prozessmodelle müssen daher für jedes Projekt für jedes Projektteam ausgewählt und angepasst werden. Das in einem konkreten Projekt verwendete Prozessmodell charakterisiert die Komplexität und den Lösungsansatz im Projekt Die Instanzierung des Prozessmodelles spiegelt die Entwicklungskultur eines Software Unternehmens wieder

7 Aktivitäten des Management-Prozesses 1
Analyse Konzept- entwicklung Planung Prozessmodell Organisation PM SW QS KM Personal Leitung Kontrolle Durchführung Aktivitäten während der Konzeptionalisierung Ziele setzen Strategien und Taktiken entwickeln Termine festlegen Entscheidungen treffen Vorgehensmodell auswählen Risiko abschätzen Finanzen planen

8 Aktivitäten des Management-Prozesses 2
Analyse Konzept- entwicklung Planung Prozessmodell Organisation PM SW QS KM Personal Leitung Kontrolle Durchführung Aktivitäten während des Entwurfes Identifizieren und Gruppieren der zu erledigenden Aufgaben (Rollen) Auswahl und Etablierung organisatorischer Strukturen Festlegen von Verantwortungs-bereichen und disziplinarischen Vollmachten Festlegen von Qualifikationsprofilen für Positionen

9 Aktivitäten des Management-Prozesses 3
Analyse Konzept- entwicklung Planung Prozessmodell Organisation PM SW QS KM Personal Leitung Kontrolle Durchführung Personalaktivitäten Positionen besetzen Neues Personal einstellen und integrieren Aus- und Weiterbildung von Mitarbeitern Personalentwicklung planen

10 Aktivitäten des Management-Prozesses 4
Analyse Konzept- entwicklung Planung Prozessmodell Organisation PM SW QS KM Personal Leitung Kontrolle Durchführung Leitungsaktivitäten Mitarbeiter führen und beaufsichtigen Kompetenzen delegieren Mitarbeiter motivieren Aktivitäten koordinieren Kommunikation unterstützen Konflikte lösen Innovationen einführen

11 Aktivitäten des Management-Prozesses 5
Analyse Konzept- entwicklung Planung Prozessmodell Organisation PM SW QS KM Personal Leitung Kontrolle Durchführung Kontrollaktivitäten Prozess- und Produktstandards entwickeln und festlegen Berichts- und Kontrollwesen etablieren Prozesse und Produkte vermessen Korrekturaktivitäten initiieren Loben und Tadeln

12 Rational Unified Process (RUP) - Definitionen
Dem Rational Unified Process (RUP) liegt ein best practice objektorientiertes Modell zu Grunde. Der RUP definiert sich über Workflows, die parallel und in Phasen ablaufen. Innerhalb jeder Phase sind Iterationen und inkrementelle Verbesserungen möglich. Zur Definition der Workflows stehen im RUP eine Reihe von Hilfsmitteln zur Verfügung (Schlüsselkonzepte), die miteinander wechselwirken. Zum Beispiel werden Aktivitäten von Workers erbracht, die dadurch Artefakte produzieren. Zur Gestaltung der Artefakte werden Guidelines und Templates zur Verfügung gestellt.

13 RUP- Phasen Der RUP kennt 4 Phasen Konzeptionalisierung Entwurf
Konstruktion + Realisierung Einführung und Betrieb Die Definitionen aller verfügbaren Phasen finden Sie über den Index des RUP-Handbuch oder wenn Sie auf der Einführungsseite Phasen aktivieren

14 Ziele und Aufgaben der Konzeptionsphase
Planungs- und Entscheidungsgrundlagen schaffen Aufgaben: Vorstudie zur Machbarkeit erstellen Definition des Projektzieles und Abgrenzung Erarbeitung, Bewertung, Empfehlung und Entscheidung über Realisierungsalternativen Überblick über Problembereich und Anforderungen Grobe Projektplanung (Iterationen etc.) Identifizierung der Projektrisiken

15 Grundlagen der Planung
Fragen: Strategische Rolle des Projektes? Welche Projektrisiken sind durch Forschungsanteile, neue Technologien, neue Benutzeranforderungen, etc. gegeben? Anforderungen und notwendige Tätigkeiten? Welche Technologien und Tools werden verwendet? Anforderungsprofil Welche Mitarbeiter stehen zur Verfügung?

16 Ziele und Aufgaben der Entwurfsphase
Erfassung der wichtigsten funktionalen und nichtfunktionalen Anforderungen Validierte, stabile und ausführbare Software-Architektur Aufgaben: Entwicklung von Systemteilen mit hoher Priorität und hohem Risiko Use Case-Modell vervollständigen(Anforderungsanalyse) Festlegung der Anwendungsarchitektur Feinplanung der jeweiligen Iteration erstellen

17 Ziele und Aufgaben der Realisierungsphase
Stabiles Produkt für die Auslieferung Aufgaben: Inkrementelle Entwicklung der Subsysteme und jeweilige Integration Test aller Komponenten, Schnittstellen, Dienste, ... Dokumentation

18 Ziele und Aufgaben der Einführungs- und Betriebsphase
Produkt in Betrieb nehmen Produkt betreiben Aufgaben: Auslieferung Installation Schulung Wartung

19 RUP- WORKFLOWS Phasenübergreifend existieren Workflows, die sich nicht an der Zeit, sondern an den Inhalten der jeweiligen Phase orientieren. In den Workflows werden Erfahrungen, wie Grundaufgaben der Software Entwicklung am besten gelöst werden können, formalisiert und transparent zur Verfügung gestellt (Best Practice). Wie die Workflows in einem Entwicklerteam umgesetzt werden und welche Schritte in einem konkreten Projekt von Bedeutung sind, muss von Fall zu Fall festgelegt werden (Tailoring). Der RUP bietet zwei Arten von Workflows an: Core Workflows und Core Supporting Workflows. Sie decken wichtige Entwicklungsaufgaben wie Anforderungsmanagement, Analyse und Design, Implementierung, Test oder Einführung und Betrieb ab. Die Definitionen aller verfügbaren Workflows finden Sie über die Startseite des RUP-Handbuchs, wenn Sie dort Workflows aktivieren

20 Phasen und ihre Workflows
Process Workflows Supporting Workflows Management Environment Business Modeling Implementation Test Analysis & Design Preliminary Iteration(s) Iter. #1 Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iter. #m+1 Deployment Configuration Mgmt Requirements Entwurf Einführung/ Betrieb Konzeptionalisierung Konstruktion/ Realisierung Iterationen umfassen jeweils alle Workflows einer Phase

21 RUP-Elemente (Schlüsselkonzepte)
Zur Definition des Workflows stehen Schlüsselkonzepte zur Verfügung. Auf folgende Elemente wird näher eingegangen: Worker Artefakte Aktivitäten Templates Iterationen Die folgende Folie zeigt alle verfügbaren Elemente (Key Concepts) und ihre Zusammenhänge. Die zugehörigen Definitionen finden Sie im Glossary des RUP-Handbuchs und über die Startseite ,wenn Sie unter Getting Started die Option Key Concepts aktivieren.

22 Wechselwirkung der Schlüsselkonzepte des RUP

23 Workers: das Team und seine Rollen im Projekt
Workers sind Personen, die innerhalb eines Projektes eine bestimmte Aktivität durchführen, bzw. eine Rolle übernehmen Zentrale Rollen Fachwissen Architekt Technologie Domänenexperte Anwendungsbereiche Projektleiter Organisation Qualitätsmanager Projektziele Weitere Rollen Fachwissen Systemanalytiker Designer Programmierer ....

24 Das Team Allen Mitgliedern des Teams ist gemeinsam Tester Analyst
Zugang zu den Dokumenten des Systems Der Entwicklungsprozess (z.B.RUP) Das Verständnis wie Software entwickelt werden sollte Die Modellierungswerkzeuge Designer / Developer Analyst Tester Database Administrator Performance Engineer Release Project Leader

25 Besetzung der Rollen Alle als projektnotwendig identifizierte Rollen müssen mit geeignet qualifiziertem Personal besetzt werden Eine Person kann gleichzeitig mehrere Rollen übernehmen Ggf. muss benötigtes Know-How durch Weiterbildung geschaffen oder zugekauft werden Besetzung der Rollen kann Aufwände bis zu einem Faktor 10 variieren lassen oder Projekte sogar ganz zum Scheitern bringen

26 Zuordnung von Mitarbeitern zum benötigten Anforderungsprofil
Wichtigster Aspekt Zuordnung von Mitarbeitern zum benötigten Anforderungsprofil

27 Artefakte Ein Artefakt ist ein Teil an Information, das produziert, modifiziert oder vom Prozess genutzt wird und dem Versionsmanagement unterliegt. Ein Artefakt kann ein Modell, ein Modellelement oder ein Dokument sein. Artefakte sind typisch für Projekte und müssen dafür ausgewählt und konfiguriert werden. Innerhalb des RUP existieren Guidelines zum Erstellen von Artefakten und Beispiele für folgende Bereiche: Geschäftprozessmodellierung Anforderungsmanagement Design Implementierung Verteilung Management Standards und Richtlinien

28 Aktivitäten Eine Aktivität ist eine in sich abgeschlossene Folge von Tätigkeiten, deren Unterbrechung kein sinnvolles Ergebnis liefern würde. Aktivitäten werden von Workern duchgeführt und enden mit der Erstellung eines Artefakts. Beispiel Der Worker Use-Case-Spezifizierer führt die Aktivität Use-Case detaillieren aus. Das Artefakt, das als Ergebnis dieser Aktivität entsteht, ist der Use-Case.

29 Templates Die Erstellung eines Artefakts, bei dem es sich um ein Dokument handelt, sollte projektübergreifend einheitlich sein. Daher existieren im Rational Unified Process für jedes derartige Artefakt Templates. Dabei handelt es sich meist um Dokumentvorlagen für Winword oder HTML, die bei der Einführung des Rational Unified Process individuell angepasst werden können. Im Bereich des Projektmanagement-Workflows existiert ferner ein Template für Microsoft Project. Die Inhalte eines derartigen Templates fangen bei der Integration eines Firmenlogos an und gehen bis zur völligen Umstrukturierung des Inhaltes. Wie schon die Richtlinien geben auch die Templates Orientierung und Beispiele für Neulinge innerhalb des Rational Unified Process.

30 RUP-Iterationen Wesentliches Kennzeichen des RUP ist sein iterativer Ansatz. Das bedeutet, dass innerhalb jeder der vier Phasen diverse Iterationen möglich sind. Jede Iteration entspricht einem kleinen „Wasserfällchen“. Das Konzept sieht dabei vor, dass jede Iteration mit einem ausführbaren und getesteten Release abgeschlossen wird. (Das erfordert ein Tool für das Qre) Jede Iteration legt dabei unterschiedliche Schwerpunkte hinsichtlich des Workflows fest. Dies führt zum sogenannten iterativ-inkrementellen Vorgehen.

31 Anpassung des RUP an ein konkretes Projekt
Der RUP muss an jedes Projekt angepasst werden. Dafür sind zeitaufwendige Maßnahmen nötig. Beispiele sind: Einfügen, Löschen oder Ändern von einzelnen Aktivitäten eines Workflows. Löschen oder Hinzufügen von Workern. Ändern von Tätigkeitsbeschreibungen und Verantwortungsbereichen von Workern. Anpassen aller oder zumindest der meisten im Rational Unified Process vordefinierten Templates. Hinzufügen von Toolmentoren für Werkzeuge, die im Rational Unified Process nicht vorgesehen sind. Ergänzen von eigenen Richtlinien. Anpassung der Prozessterminologie zum Beispiel an Vorgaben des Kunden.

32 Bewährtes Mischmodell
Anforderungsanalyse Grobdesign, Komponentenbildung Iterativ inkrementelle Entwicklung Systemtest und Einführung

33 Anforderungsanalyse Detaillierte Analyse des fachlichen Feinkonzepts
Grobentwurf von Use Cases Workshops mit Fachexperten und Systemanalytikern Detaillierung der Use Cases Akteure identifizieren (wer hat welche Aufgaben, Kompetenzen) Erstellung eines Glossars der Fachbegriffe Priorisierung der Use Cases Ggf. erste Dialogentwürfe Aktivitätsmodellierung Konkretisierung der Anforderungen Übergang zum Design (wie soll das System arbeiten) Identifizierung von Lösungsalternativen, Evaluierung und Empfehlung geeigneter Lösungen Planung des weiteren Vorgehens

34 Grobdesign und Komponentenbildung
Identifikation von Subsystemen und Komponenten Detaillierung der Systemarchitektur Modellierung der fehlenden fachlichen Klassen Entwicklung eines Prototypen zur Verifizierung der Architektur Planung der iterativ inkrementellen Komponentenentwicklung

35 Releaseplanung Releaseplanung Wieviel Iterationen ?
Reihenfolge der Komponenten (-ausbaustufen) riskante Komponenten, hoch priorisierte Komponenten und Basiskomponenten zuerst Richtwert für Iterationsdauer: 6 bis 8 Wochen Bildung von Teilprojekten/Teams

36 Systemtest und Einführung
Teilabnahmen können bereits während der Projektlaufzeit auf Basis von Subsystemen erfolgen, sofern diese unabhängig voneinander getestet und abgenommen werden können Planung und Durchführung des Rollouts Inbetriebnahme des neuen Systems evtl. parallel zu einem Vorgängersystem Test und Abnahme des Gesamtsystems

37 RUP: Aufgaben des Auftraggebers
Grobdesign, Komponentenbildung ___________________ Klärung spezieller Detailfragen Iterativ inkrementelle Entwicklung ___________________ Review von Teilergebnissen Anforderungsanalyse ___________________ Detaillierung Use Cases Verifizierung v. Modellen Systemtest und Einführung ___________________ Test und Abnahme

38 Beispiel: Wasserfallmodell als einfaches Phasenmodell
Voraussetzungen: Stabiles Umfeld (z.B. keine Änderungen der Anforderungen) Bekannte Technologien und Verfahren Analyse Design Kodierung Test Aktivitäten Produkte: Spezifikation Entwurf Programm Abnahmebericht

39 Wasserfallmodell (2) Vorteile: Klare Aufgaben in jeder Phase „relativ einfach“ Genaue Planung bei geringem Overhead Nachteile: Rückkehr in eine frühere Phase ist aufwendig Probleme werden erst spät erkannt Gut geeignet für kleine Projekte und Standardprojekte Ungeeignet für Neuentwicklungen komplexer Systeme

40 Weitere Prozessmodelle - Definitionen
Spiralmodell Eine Softwareentwicklung durchläuft mehrmals einen aus vier Schritten bestehenden Zyklus mit dem Ziel, frühzeitig Risiken zu erkennen und zu vermeiden. Pro Zyklus kann dann ein Prozess-Modell oder eine Kombination von Prozess- Modellen zur Erstellung eines Teilprodukts oder einer Ebene eines Teilprodukts festgelegt werden. Prototypen-Modell Frühzeitige Erstellung ablauffähiger Modelle (Prototypen) des zukünftigen Produkts zur Überprüfung von Ideen oder zum Experimentieren. V-Modell Ein um die Aktivitäten Verifikation und Validation erweitertes Wasserfallmodell, ursprünglich für eingebettete, militärische Entwicklungen vorgesehen. Inzwischen gibt es in Deutschland eine Weiterentwicklung, die auch andere Anwendungsklassen abdeckt (V-Modell 97 erweitert in Richtung Objektorientierung).

41 Weitere Prozessmodelle - Eigenschaften
Prozess- Primäres Antreibendes Benutzer- Characteristika Modell Ziel Moment beteiligung Wasserfall- minimaler Dokumente gering sequentiell, modell Management- volle Breite aufwand Spiralmodell Risiko- Risiko mittel Entscheidung pro minimierung Zyklus über weiteres Vorgehen Prototypen- Risiko- Code hoch nur Teilsysteme Modell minimierung (horizontal oder vertikal) V-Modell maximale Dokumente gering sequentiell, Qualität volle Breite, (safe-to- Validation, market) Verifikation Diesen Prozessmodellen liegt im Wesentlichen das Paradigma der strukturierten Methoden zu Grunde. Die Objektorientierung wird erst durch neuere Modelle adäquat unterstützt. Dazu gehören das V-Modell-97 und der hier weiter vorgestellte Rational Unified Process

42 Iterative-Inkrementelle Vorgehensmodelle (1)
Annahmen: Anforderungen sind unvollständig wichtige Erkenntnisse werden erst im Laufe des Projektes gewonnen Analyse Design Iteration 1 Kodierung Test Iteration 2 Iteration N

43 Iterative-Inkrementelle Vorgehensmodelle (2)
Inkrementell - Verbesserung in Breite iterativ Verbesserung in Tiefe Vorteile: evolutionäre SW-Entwicklung (Iterationsende: Programm) Reaktion auf Änderungen und Unvorhergesehenes einfacher feinere Steuerung möglich Nachteile: scheinbar mehr Aufwand schwierigere Umsetzung Geeignet für Projekte mit Unwägbarkeiten

44 Wasserfall vs. Iterative Modelle
Wasserfallmodell: einfacher Umzusetzen geeignet für Projekte mit bekannten Verfahren in einem stabilen Umfeld Iterative-Inkrementelle Modelle flexibel Probleme werden frühzeitig erkannt nach jeder Iteration steht ein Produkt, das ggf. ausgeliefert werden könnte erlaubt schnelle Reaktion auf Unvorhergesehenes

45 Der RUP als Best Practice Repository
Best Practice bedeutet die Verwendung auch kommerziell erprobter Ansätze zur Software Entwicklung und den Versuch aus Fehlern gescheiterter Projekte zu lernen Anforderungsverwaltung Iterative Entwicklung Qualitäts- kontrolle Komponenten Architekturen Visuelle Modellierung Change/ConfigurationManagement

46 Der RUP im V-Modell V-Modell
Versuch eines generischen Ansatzes für ein flexibel einsetzbares Prozessmodell. Für Bundesbehörden verbindlicher Ansatz, der unabhängig von Herstellern ist. Benötigt Tailoring für konkretes Projekt. Erlaubt Zuschnitt auf Entwicklung objektorientierter und komponentenbasierter Systeme. Benötigt Unterstützung durch aufgabenspezifische Werkzeuge. RUP Versuch der Bereitstellung von Best Practice Ansätzen zur Entwicklung objektorientierter Software-Systeme. Anbindung an Unified Modelling Language. Gute Software-Unterstützung durch die Rational Suite (kommerziell). Konsequenz Für Projekte, die auf Basis von Objekten und Komponenten realisiert werden sollen, sollte das V-Modell so zugeschnitten werden, dass der Einsatz des RUP möglich wird. Dies bedingt zur Zeit Abhängigkeit von Tool Provider.

47 Integration des RUP in das V-Modell
RUP-Werkzeuge müssen durch Skripte an Projekt-Anforderungen angepasst werden. Dokumenttemplates sind so zu gestalten, dass sie den Projektanforderungen genügen. Projektanforderungen sind V-Modell-konform zu gestalten.

48 Komponentenbasierte Systeme aus Sicht des RUP
Teilsystem Komponente 2.1 Komponente 2.2 Untersystem Komponenten sind eigenständig entwickelbare Produkte des SE (Beispiel: konventionelle Komponenten, Web-Seiten, Datenbanktabellen etc.)

49 Modellierung der Komponenten
Modellierung einer Komponente in UML mit den Elementen Use Case Sequenz Diagramm Aktivitätsdiagramm Modellierung eines Use Case als Summe des Use Cases der darunterliegenden Ebene Hierarchisierung des Use Cases Verwaltung des Use Cases über Datenbank (Repository) Anmerkung: Diese Struktur kann auch zur inkrementellen Verbesserung verwendet werden. Die Komponenten 2.1 und 2.2 bedeuten dann zusätzliche Features der Komponente 2.

50 Das zeitliche Modell des RUP
Managementsicht Jede Phase endet mit einem Meilenstein Ziel Problem verstehen Lösung verstehen Lösung vorhanden Lösung akzeptieren Konzeption alisierung Entwurf Konstruktion/ Realisierung Einführung/ Betrieb Phase Vorläufige Iterationen Architektur Iteration 1 Architektur Iteration2. Entwicklung Iteration n+1 Entwicklung Iteration n+2 Einführung Iteration m+1 Einführung Iteration m+2 Ressourcen zum Ressourcen zur Produkt zur Produktstatus Entwurf Realisierung Benutzung bereit+ dokumentiert bereit + dokumentiert fertig + dokumentiert akzeptert/abgenommen Ergebnis Jede Iteration endet mit einem prüfbaren Produkt Technische Sicht

51 Agile Software Entwicklung mit dem RUP
Best Practice bei agiler Softwareentwicklung Key Processes Tailoring Adaptieng the RUP to a specific problem

52 Agile Software Entwicklung
Kunden, Benutzer und Entwickler lernen bei größeren Projekten selber. Das Vergehensmodell Agile SE schafft eine Umgebung, in dem dies möglich wird und auf die daraus resultierenden Änderungen im Projektumfeld reagiert werden kann. Beteiligte und ihre Zusammenarbeit sind wichtiger als Prozess und Werkzeuge. Lauffähige Software ist wichtiger als ausführliche Dokumentation. Zusammenarbeit mit Kunden ist wichtiger als ausgefeilte Verträge. Anforderungen sind zu minimieren. Anforderungsänderungen müssen möglich sein. Versionen sollten nicht erst bei Projekt ende zur Verfügung stehen.

53 Best Practices bei agiler Softwareentwicklung
Entwickle iterativ Modelliere graphisch Überwache Erfüllung der Anforderungen Verfolge Änderungen Schließe jeden Schritt mit Qualitätsprüfung ab Verwende eine komponentenbasierte Version

54 Key Principles Entwickle nur was zur Lösung notwendig
Konzentriere Dich auf die wesentlichen Ergebnisse und weniger darauf,wie sie erzielt werden Vermeide unnötige Dokumente Passe Dich an Entwicklungsstand an Lerne von Fehlern Überprüfe regelmäßig die Risiken des Projektes Entwickle objektivierbare Kriterien zur Messung des Projektfortschrittes Versuche Routinearbeit zu automatisieren Arbeite nach Plan

55 Tailoring eines Prozessmodelles
Wähle für das Projekt relevante Elemente des RUP framework aus Eliminiere unnötige Elemente Ergänze das Vorgehensmodell um projektspezifische Elemente Passe, wo nötig, die ausgewählten Elemente an die Projekterfordernisse an

56 Erstellung einer projektspezifischen Instanz des RUP
Was ist zu entwickeln Welche Artifakte werden dazu benötigt Welche Templates sollten verwendet werden Prüfe ob Artifakte schon verfügbar sind Welche Rollen müssen ausgefüllt werden Welche Aktivitäten sind durchzuführen Welche Richtlinien, Standards und Werkzeuge sind einzusetzen Weitere Informationen zur agilen Softwareentwicklung zu extremeprogramming

57 Wir wünschen viel Erfolg
RUP in der Praxis Zum RUP existiert eine online Version. Mit dieser Version können Sie: direkt aus einem Projekt auf den RUP zugreifen und sich Hilfestellung für die aktuelle Arbeit geben lassen das aufgezeigte Vorgehen in der Praxis erproben weitere Details für ein optimales Tailoring auf Ihr Projekt hin erarbeiten Starten sie den RUP hier. Bitte beachten Sie auch die dort aufgeführten work guidelines Wir wünschen viel Erfolg

58 Danksagung Das Lehrmaterial ist als Einführung in der RUP konzipiert. Im Rahmen von MuSofT wurde eine Lehreinheit „ Durchführung von Softwareprojekten mit dem Unified Process“ entwickelt. Sie diente mit als Grundlage.

59 Begriffsdefinitionen der Gesellschaft für Informatik
Unter finden man eine Übersicht wichtiger Begriffe zu Analise und Modellierung von Anwendungssystemen Grundbegriffe Modellierung Tätigkeiten und Ergebnisse der Analyse Vorgehensmodelle Aktivitäten Entwicklungsprozess Konfigurationsmanagement Projektmanagement Qualitätsmanagement Systementwicklung Vorgehensstrategie

60 Begriffsdefinitionen
Innerhalb des RUP existiert ein englisches Glossar in dem alle Begriffe des RUP erläutert werden. Man findet es unter

61 Literatur Balzert, Helmut: Lehrbuch der Software-Technik; Software-Management, Software-Qualitätssicherung, Unternehmensmodellierung. Spektrum Akademischer Verlag Kruchte, Phillippe: Agility with the RUP; The Rational edge 2002