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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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?

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

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

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

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

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

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.

Wechselwirkung der Schlüsselkonzepte des RUP

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 ....

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

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

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

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

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.

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.

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.

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.

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

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

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

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

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

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

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

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

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).

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

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

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

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

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

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.

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.

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.)

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.

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

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

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.

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

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

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

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 www.agilemanifesto.org zu extremeprogramming www.xprogramming.com

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

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.

Begriffsdefinitionen der Gesellschaft für Informatik Unter http://www.vorgehensmodelle.de/Giak/index.htm 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

Begriffsdefinitionen Innerhalb des RUP existiert ein englisches Glossar in dem alle Begriffe des RUP erläutert werden. Man findet es unter http:\\Lehre\wn-lehre\musoft\rup-manual\index.htm

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