Prozessmodell „Rational Unified Process“ - Software Engineering

Übung
Software Engineering
Wintersemester 2003 / 2004
Prozessmodell
„Rational Unified Process“
– Überblick und Beschreibung –
LVA – Nr.
246.538
LVA – Leiter
Dr. Reinhold Plösch
Institut
Institut für Wirtschaftsinformatik(WIN)
Software Engineering
Gruppe 1 – Team 5:
Kainzbauer Michael, 0055617
Kern Michael, 9457030
Razocher Bernhard, 0055583

Inhaltsverzeichnis
1. Motivation .............................................................................................................................. 3
2. Ziele und Zielgruppen ............................................................................................................ 3
3. Charakteristische Merkmale................................................................................................... 4
4. Eigenschaften des RUP .......................................................................................................... 4
5. Zeitliche Dimension des RUP: Phasen................................................................................... 5
5.1. Einführungsphase ........................................................................................................... 6
5.2. Entwurfsphase ................................................................................................................. 6
5.3. Konstruktionsphase ......................................................................................................... 6
5.4. Übergangsphase .............................................................................................................. 6
6. Inhaltliche Dimension des RUP: Workflows ......................................................................... 7
7. Anwendung der 6 Best Practices............................................................................................ 7
7.1. Software iterativ entwickeln............................................................................................ 8
7.2. Managen der Anforderungen .......................................................................................... 8
7.3. Verwenden Komponentenbasierter Architekturen.......................................................... 8
7.4. Software visuell modellieren........................................................................................... 8
7.5. Softwarequalität verifizieren.......................................................................................... 8
7.6. Softwareänderung kontrollieren...................................................................................... 8
8. Vorteile des RUP.................................................................................................................... 9
9. Nachteile des RUP ................................................................................................................. 9
10. Zusammenfassung.............................................................................................................. 10
11. Abbildungsverzeichnis....................................................................................................... 11
12. Quellenverzeichnis............................................................................................................. 12

Übung Software Engineering Gruppe 1 – Team 5
Kainzbauer, Kern, Razocher
1. Motivation 1
Der Unified Process wurde 1998 von Ivar Jacobson, James Rumbaugh und Grady Booch
veröffentlicht. Seine Entwicklung beruht auf dem Rational Objectory Process, der das
Objectory Vorgehensmodell erweitert. Der Rational Objectory Process kombiniert den
Use-Case-getriebenen Ansatz des Objectory Vorgehensmodells mit der architekturzentrierten
Entwicklung und dem iterativen und inkrementellen Vorgehen des Booch-Vorgehensmodells.
Schwerpunkte des Rational Objectory Process sind Use-Case Modellierung, Analyse und Entwurf.
Der Unified Process ergänzt den Rational Objectory Process hinsichtlich fehlender oder
unzureichend unterstützter Tätigkeiten wie Implementierung, Test, Anforderungs- und
Konfigurationsmanagement.
2. Ziele und Zielgruppen
Ein Prozess legt fest, wer was auf welche Art und Weise macht, um ein Ziel zu erreichen.
Daher schreibt der Softwareentwicklungs-Prozess Richtlinien vor, welche eine effiziente
Entwicklung qualitativ hochwertiger Software ermöglichen. Weiters sollen durch dessen
Einsatz Risiken minimiert und Vorhersagen vereinfacht werden. 2
Die Steigerung sowohl der Produktivität als auch der Erfolgsrate stellen zusätzliche Ziele dar.
Der höhere Output wird auch durch die Standardisierung des Entwicklungsprozesses
ermöglicht. Zusätzlich sollen mit Hilfe dieses Modells die Benutzbarkeit, Wartung und
Änderbarkeit der Software verbessert werden. 3
Ein unternehmensweites Ziel des Prozesseinsatzes ist die Etablierung einheitlicher
Vorstellung und Kultur des Software Engineering innerhalb des Unternehmens. 4
Unter den am weitesten verbreiteten Prozessmodellen befinden sich - neben dem hier
vorgestellten Rational Unified Process (RUP) – der OOSP (Object-Oriented Software
Process) und der OPEN Process. 5
Zielgruppe
Grundsätzlich kann jeder Softwareentwickler den Unified Process einsetzen bzw. seine
Aktivitäten nach dem Modell ausrichten. Dennoch ist der Prozess vorrangig für jene Personen
vorgesehen, welche sich mit Aufgabenbereichen aus den vier Hauptphasen beschäftigen.
Darunter fallen unter anderem Systemanalysten, Softwareentwickler, Programmierer,
„Systemtester“ und Projektmanager. 6
1 s. [VOR01] S 75
2 s. [BOO99] S. xviii
3 s. [EUP02]
4 s. [BOO99] S. xviii
5 s. [EUP02]
6 s. [BOO99] S. xix f
Seite - 3 -

Übung Software Engineering Gruppe 1 – Team 5
Kainzbauer, Kern, Razocher
3. Charakteristische Merkmale
Use-Case-gesteuert
Ein Use Case ist eine Funktion eines Systems, welche dem Benutzer ein Ergebnis bringt. Die
Gesamtheit aller Use Cases des Systems bildet das Use-Case-Modell, welches die ganze
Funktionalität des Systems beschreibt. Die Verwendung der Use Cases zur Beschreibung des
Systems bewirkt eine Orientierung am Benutzer des Softwareprodukts, ganz im Gegensatz zu
der traditionellen funktionalen Sichtweise. Basierend auf dem Use-Case-Modell werden
Design und Implementierungsmodelle entwickelt. 7
architekturorientierter Prozess
Die Architektur eines Softwaresystems, welche von Faktoren wie der Plattform, auf der die
Software läuft, beeinflusst wird, wird als die Summe der Sichten auf das System beschrieben.
Weitere Einflussfaktoren sind die Verfügbarkeit von wieder verwendbaren Softwareteilen und
nichtfunktionale Anforderungen. 8
Der Rational Unified Process zielt vor allem auf das Zusammenspiel der einzelnen
Komponenten der Architektur ab. 9
Iterativ und inkrementell
Im klassischen Wasserfallmodell werden die einzelnen Phasen des
Softwareentwicklungsprozesses sequentiell durchlaufen. Im Gegensatz dazu arbeitet man im
Unified Process einzelne Phasen iterativ, also wiederholt, ab. Dadurch werden Fehler
möglichst bald identifiziert. Die iterative Abhandlung der Phasen lässt aus dem gesamten
Projekt mehrere kleine Projekte entstehen. Der inkrementelle Charakter des Unified Process
besteht darin, dass das Produkt schrittweise, also inkrementell, wächst. Somit wird die
teilweise parallele Behandlung der einzelnen Aktivitäten möglich. 10
4. Eigenschaften des RUP
Der Rational Unified Process ist ein iteratives, Use-Case-getriebenes und archtitekturzentriertes
Prozessmodell. Er gliedert sich in eine zeitliche und inhaltliche Dimension(siehe
Abb. 1).
7 s. [BOO99] S. 5
8 s. [BOO99] S. 6
9 s. [THE00] S. 4
10 s. [THE00], S. 1
Seite - 4 -

Übung Software Engineering Gruppe 1 – Team 5
Kainzbauer, Kern, Razocher
Abb. 1: Rational Unified Process
Die vier Phasen – Inception, Elaboration, Construction, Transition - ermöglichen dabei eine
Einteilung des Projektes enstprechend des zeitlichen Ablaufs, wogegen die neun Workflows
eine Organisation des Projektes hinsichtlich der verschiedenen Aufgaben erlauben. Die
Phasen des RUP werden dabei in zumindest einer oder mehrerer Iterationen abgearbeitet. Die
Workflows durchziehen sich durch jede Phase, haben aber Schwerpunkte, d.h., sie sind in den
einzelnen Phasen unterschiedlich gewichtet 11 .
Die Phasen bzw. die Workflows des RUP sollen in den beiden folgenden Abschnitten nun ein
wenig näher erläutert werden.
5. Zeitliche Dimension des RUP: Phasen 12
Während des gesamten Lebenszyklus eines Software-Produktes, wird der RUP in mehreren
Zyklen durchgeführt. Jeder dieser Zyklen ist in vier Phasen eingeteilt und führt letztendlich zu
einem Produkt-Release. Diese Phasen geben Auskunft über den Reifegrad des Projektes und
jede schliesst mit einem sogenannten Meilenstein ab(siehe Abb. 2). Im Gegensatz zu den
Workflows, erlauben sie eine Organisation des Projektes entsprechend des zeitlichen Ablaufs.
Inception Elaboration Contruction Transition
Zeit
Lifecycle
Objective
Milestone
Lifecycle Initial Operational
Architecture Capability
Milestone
Lifecycle
Abb. 2: Die vier Phasen des RUP
Product
Release
Milestone
11 s. [RAT03] S. 14 f.
12 s. [RAT03] S. 15 f und [VOR02] S. 76 f
Seite - 5 -

Übung Software Engineering Gruppe 1 – Team 5
Kainzbauer, Kern, Razocher
5.1. Einführungsphase 13
Die Einführungs- oder auch Vorbereitungsphase(engl. Inception phase) bildet sozusagen den
Einstiegspunkt in ein neues Projekt. Es werden die Hauptanforderungen an das zu
entwickelnde System erarbeitet. Das Ziel ist festzustellen, ob das Produkt realisiert werden
kann oder nicht. Dafür werden erste Anwendungsfälle(Uses Cases) entwickelt, um einen
ersten Eindruck von der Funktionalität des Systems zu bekommen. Weitere Aktivitäten in
dieser Phase 14 sind z.B.
• Definition der Grenzen des Systems(project scope)
• Beschreibung einer möglichen Systemarchitektur
• Erarbeitung einer ersten Risikoabschätzung bzw. Identifikation möglicher Risiken,
welche die Realisierbarkeit gefährden könnten
• Präsentation des vorgeschlagenen Systems vor Kunden; dafür könnte schon ein
Prototyp sinnvoll sein
Der Lifecycle Objective Milestone als Ergebnis dieser Phase definiert die Ziele für den
Lebenszyklus des Projektes.
5.2. Entwurfsphase 15
Die Aufgabe der Entwurfsphase(engl. Elaboration phase) ist quasi die Vorbereitung für die
Konstruktionsphase. Das Use-Case-Modell sowie funktionelle und nicht funktionelle
Anforderungen sollten weitgehend(in etwa zu 80 %) komplett sein. Die für das Projekt
notwendigen Werkzeuge und Ressourcen werden festgelegt. Desweiteren werden
Problembereiche(Domains) analysiert und eine stabile Architektur entwickelt. Ebenso erfolgt
eine Aufstellung von identifizierbaren Hauptrisiken und eine Festlegung von
Qualitätsattributen, die vom System erreicht werden sollen, wie z.B. minimale Antwortzeiten.
Das Ergebnis dieser Phase ist der Lifecycle Architecture Milestone: Die Architektur soll
beschrieben sein und in Form eines Architektur-Prototypen vorliegen. Dieser Prototyp ist aber
kein „Wegwerf-Prototyp“, sondern die Basis für die weitere Systementwicklung.
5.3. Konstruktionsphase 16
Die Hauptaufgabe der Konstruktionsphase(engl. Construction phase) ist die Implementierung
und das Testen der Systemkomponenten. Basis für die Entwicklung ist der in der Elaboration
Phase entstandene Architektur-Prototyp. Die Analyse des Systems sollte beendet sein,
identifizierte Hauptrisiken kontrolliert und eventuelle Gegenmassnahmen eingeleitet werden.
Zusätzlich wird eine System- und Benutzerdokumentation erstellt.
Das Ergebnis ist der Initial Operational Capability Milestone, ein lauffähiges und für den
Kunden einsetzbares Produkt.
5.4. Übergangsphase 17
In dieser Phase(engl. Transition phase) erfolgt der Übergang des Systems aus der
Entwicklungsumgebung zum Kunden. Zunächst wird das Produkt an eine ausgewählte
Gruppe von Kunden(Betakunden) ausgeliefert, dessen Zweck es ist, das Produkt in
Benutzerumgebung ausführlich zu testen und noch auftrende Fehler zu beseitigen. Daneben
steht vor allem die Schulung der Anwender im Vordergrund, weiters die Fertigstellung von
13 s. [VOR02] S. 77 und [RAT03] S. 15
14 s. [VOR02] S. 78
15 s. [VOR02] S. 78 und [RAT03] S. 15
16 s. [VOR02] S. 78f und [RAT03] S. 15f
17 s. [VOR02] S. 79 und [RAT03] S. 16
Seite - 6 -

Übung Software Engineering Gruppe 1 – Team 5
Kainzbauer, Kern, Razocher
Begleitdokumenten wie Benutzerhandbücher oder eine eventuelle Konvertierung von Daten
aus älteren Systemen.
Das Ergebnis ist das Product Release, mit dem das Projekt abgeschlossen und übergeben
wird.
6. Inhaltliche Dimension des RUP: Workflows
Neben der zeitlichen Dimension gibt es im RUP auch noch eine inhaltliche oder besser
aufgabenbezogene Dimension. Erfolgt die Projektsteuerung anhand der vier Phasen, so läuft
die technische Realisierung des Produktes anhand von neun Workflows ab. In jeder Phase
werden eine oder mehrere Iterationen dieser Workflows durchlaufen, welche wiederum in
Core Process Workflows(Kernprozesse) und Core Supporting Workflows(Hilfsprozesse)
aufgeteilt sind 18 :
Die Core Process Workflows sind
• Geschäftsprozessmodellierung(Business Modeling)
• Anforderungsdefinition (Requirements)
• Analyse & Design
• Implementierung
• Test
• Betrieb
Die Core Supporting Workflows sind
• Konfigurations- und Change Management
• Projektmanagement
• Umwelt
Diese Workflows erlauben eine Organisation des Projektes entsprechend der verschiedenen
Aufgaben. Sie werden in jeder Phase des RUP durchlaufen. Wichtig dabei ist, dass sich
lediglich die Schwerpunkte der Workflows verschieben und nicht ein Workflow vor dem
anderen abgeschlossen wird. Zum Beispiel, während in den ersten beiden Phasen eher
Anforderungsermittlungen, Analyse und Designtätigkeiten im Vordergrund stehen, sind dies
in den anderen Phasen eher Implementierungsaufgaben und das Testen.
7. Anwendung der 6 Best Practices 19
Der Rational Unified Process beschreibt, wie man bereits industriell erprobte
Vorgehensweisen auf Softwareentwicklungsteams anwendet. Diese Vorgehensweisen nennt
man „Best Practices“, von denen man festgestellt hat, dass sie in der Wirtschaft verbreitet
erfolgreich angewendet werden. Der RUP sieht dabei für jedes Teammitglied Richtlinien,
Vorschriften, Werkzeuge und Schablonen vor, die für den Erfolg im Team einen
entscheidenden Beitrag leisten sollen. Diese „Best Practices“ werden im Folgenden
dargestellt:
18 s. [VOR03] S. 4 und [RUP01] S. 10f
19 s. [RAT03] S. 7f und [RUP01] S. 1f
Seite - 7 -

Übung Software Engineering Gruppe 1 – Team 5
Kainzbauer, Kern, Razocher
7.1. Software iterativ entwickeln
In der modernen Softwareentwicklung ist es nicht mehr möglich, ein Produkt als ganzes zu
definieren, planen, implementieren und am Schluss das fertige Produkt zu testen. Es ist
notwendig, die Sache in kleineren Zyklen anzugehen, an deren Ende immer eine lauffähige
Version steht. In jeder Iteration kommt es zu einem besseren Verstehen und zu
Verfeinerungen des Produktes. Am Ende der Iterationen steht das Produkt. Der RUP
unterstützt diese iterative Vorgehensweise, zeigt in jeder Phase Risiken auf und und hilft diese
so zu minimieren. Durch die lauffähigen Zwischenversionen ist es leichter, den Endbenutzer
in den Prozess einzubinden und früh auf Probleme zu reagieren.
7.2. Managen der Anforderungen
Dadurch, dass es nicht möglich ist, vorab alle Anforderungen an ein System zu planen, ändern
sich diese während des Entwicklungsprozesses. Bedingt durch die in jeder Iteration
steigenden Anforderungen ist es dringend vonnöten, diese adäquat zu verwalten. In jeder
Iteration sind die Veränderungen und die damit verbundenen Auswirkungen der
Anforderungen festzustellen und zu dokumentieren, auch die anstehenden Entscheidungen
und andere Randbedingungen müssen festgehalten werden.
7.3. Verwenden Komponentenbasierter Architekturen
Der RUP unterstützt Komponentenbasierte Softwareentwicklung. Komponenten sind
nichttriviale Teile oder Teilsysteme, die eine definierte Funktion erfüllen. Der RUP bietet hier
eine systematische Vorgehensweise zur Erstellung einer Architektur, die es ermöglicht,
sowohl neue als auch vorhandene Komponenten zu verwenden. Diese werden dann entweder
selbstständig zusammengefügt oder in eine Infrastuktur wie WWW, CORBA oder COM
eingefügt.
7.4. Software visuell modellieren
Der RUP zeigt wie man Software visuell modellieren kann und ermöglicht die Darstellung der
Struktur und des Verhaltens der Architektur und der Komponenten. Durch die Möglichkeit,
den Abstraktionsgrad zu verändern ist es leichter möglich Zusammenhänge zu erkennen und
zu verstehen. Grundlage ist UML, die von Rational Software entwickelte „Unified Modeling
Language“.
7.5. Softwarequalität verifizieren
Schlechte Performance und eine geringe Zuverlässigkeit sind Faktoren, die bei einer Software
unbedingt zu vermeiden sind. Die Qualität der Software muss deshalb einer Prüfung
unterzogen werden. Der RUP hilft hier in der Planung, beim Design, Implementierung,
Ausführung und Evaluierung der notwendigen Tests. Die Beurteilung der Qualität ist im
Prozess integriert, fließt in alle Aktivitäten ein und bezieht alle Teilnehmer unter Verwendung
objektiver Messungen und Kriterien ein.
7.6. Softwareänderung kontrollieren
In einem System in dem Änderungen unvermeidlich sind, ist die Fähigkeit, Änderungen zu
handhaben, notwendig, um sicherzustellen, dass jede Änderung annehmbar und
zurückverfolgbar ist. Der RUP beschreibt wie man Änderungen kontrolliert, verfolgt und
überwacht, um eine iterative Entwicklung zu ermöglichen. Es wird möglich, Änderungen
isoliert von anderen Beschäftigungsfeldern durchzuführen und so gesicherte Felder für den
einzelnen Entwickler zu schaffen.
Seite - 8 -

Übung Software Engineering Gruppe 1 – Team 5
Kainzbauer, Kern, Razocher
8. Vorteile des RUP 20
• Risikofaktoren können schnell erkannt werden
Durch iteratives Vorgehen wird risikobasierte Vorgehensweise gut unterstützt. Dadurch, dass
teilweise parallel vorgegangen wird, werden Fehler schnell erkannt und können ausgebessert
werden.
• Aktualität
RUP wird von Rational Software ständig aktualisiert, die neuesten Erkenntnisse werden
berücksichtigt.
• Abstimmung der Komponenten zur Entwicklungszeit
Schon frühzeitig werden die Komponenten aufeinander abgestimmt und dadurch kann das
Risiko und die Fehlerquote gesenkt werden.
• Use Cases
Durch die Berücksichtigung von Use Cases können die Funktionen anwenderorientiert
implementiert werden.
• UML als Basis
RUP basiert auf UML, damit ist sichergestellt, dass durch die weltweite Eindeutigkeit eine
Kooperationsfähigkeit mit anderen Schnittstellen wie Unternehmen und Kunden gewährleistet
ist.
• Support
Handbücher von Rational Software sind online verfügbar, in User Foren sind Anfragen an
andere User und Experten möglich.
• Der RUP basiert auf mehreren Vorgehensweisen
Die 6 "Best Practices" sind ein Destillat, aus den Erfahrungen vieler Projekte. Der RUP ist
also in der Praxis verwurzelt.
9. Nachteile des RUP
• Phasenorientierung
Phasen- und Meilensteinkonzepte lassen sich für komponentenorientierte Softwareentwicklung
nur schwer umsetzen. Für Entwicklungsformen wie Prototyping reicht dies nicht
aus.
• Komplexität 21
Der RUP ist ein komplexes Vorgehensmodell, zudem ist er immer noch starken Veränderungen
ausgesetzt
20 s. [VOR02] S. 3
21 s. [SWE01] S. 5
Seite - 9 -

Übung Software Engineering Gruppe 1 – Team 5
Kainzbauer, Kern, Razocher
• Qualitätssicherung 22
Im RUP ist keine Qualitätssicherung integriert.
• Iterationen
Zwar sind im RUP Iterationen vorgesehen, aber an die einzelnen Phasen und nicht an die
Bausteine geknüpft. Hier ist wenig Platz im Entwicklungsprozess, da nur Phasen oder ganze
Zyklen wiederholt werden können.
• Zentrierung der Architektur
Der RUP gilt als „architektur-zentriert“, nimmt aber zuwenig Rücksicht auf die Baustein- und
Ergebnisstruktur. Ein tatsächlich architekturzentrierter Ansatz müsste die Systemstruktur mit
ihren Bausteinen sichtbar machen und Aktivitäten und Arbeitsergebnisse an deren jeweiligen
Entwicklungsstand knüpfen, was in weiterer Folge zu einer stärkeren Verknüpfung mit einer
ergebnis- und dokumentenorientierten Arbeitsweise führen würde.
10. Zusammenfassung
Der RUP ist zu einem "de facto" Industriestandard der westlichen Softwareindustrie mit
zunehmender Relevanz geworden: Die Gründe hierfür sind vielfältig. Insbesondere zwei
Aspekte sorgen für eine zunehmende Popularität des RUP. Dies ist zum einen die in
zahlreichen Projekten nachgewiesene Praxisnähe, zum anderen die Tatsache, dass die Object
Management Group (OMG), die ja schon UML als Standard für die Modellierung von
informationstechnischen Systemen verabschiedete, seit Juni 2001 einen Entwurf zur
Standardisierung eines Software Process Engineering Meta Models (SPEM) vorgelegt hat, der
von Rational Software und anderen Unternehmen auf Basis des RUP entwickelt worden ist. 23
Weiters hat Rational Software Kooperationen mit Branchen-Riesen IBM, Microsoft und Sun
getroffen und bietet für diese Plug-Ins an, welche es ermöglichen den RUP in die
Entwicklungsumgebung zu integrieren und den Kunden den RUP an ihr Unternehmen
anzupassen. Trotz allem verwenden die meisten Unternehmen den standardisierten RUP, da
dieser ja bereits an den Entwicklungsprozess im Unternehmen angepasst ist. 24
Die Entwicklung des Unified Process macht nicht halt. Der RUP wurde um zwei neue Phasen
Production und Retirement und um zwei neue Disziplinen Enterprisemanagement und
Operation & Support erweitert. Dies Erweiterung des Prozesses sind in der Literatur unter den
Namen EUP, Enterprise-RUP oder einfach unter E-RUP zu finden. 25
22 s. [SWE01] S. 5
23 s. [PRO02]
24 s. [PRE02]
25 s. [EUP02]
Seite - 10 -

Übung Software Engineering Gruppe 1 – Team 5
Kainzbauer, Kern, Razocher
11. Abbildungsverzeichnis
Abb. 1: Rational Unified Process............................................................................................... 5
Abb. 2: Die vier Phasen des RUP .............................................................................................. 5
Seite - 11 -

Übung Software Engineering Gruppe 1 – Team 5
Kainzbauer, Kern, Razocher
12. Quellenverzeichnis
[VOR02]
Bunse, Christian; von Knethen, Antje: Vorgehensmodelle kompakt,
Spektrum Akademischer Verlag, 2002
[RAT03]
Essigkrug, Andreas; Mey, Thomas: Rational Unified Process kompakt,
Spektrum Akademischer Verlag, 2003
[RUP01]
White Paper - Rational Unified Process, Best Practices for Software Development
Teams, Rational Software Group, 2001,
http://www-140.ibm.com/content/03July/1000/1251 / 1251_bestpractices_TP026B.
pdf, [19.10.2003]
[VOR03]
Scholz, Michael: Vorgehensmodell für die Entwicklung und Einführung von
Wissensmanagementsystemen, Martin-Luther-Universität, Fachbereich
Wirtschaftswissenschaften, 2003,
http://www.infogeneration.de/download/vorgehensmodell_wms.pdf, [18.10.2003]
[SWE01]
Klarner Martin: Software Engineering, Web Site Engineering in der Theorie,
Friedrich Alexander University of Erlangen-Nürnberg, Fachbereich Informatik, 2002
http://www8.informatik.uni-erlangen.de/IMMD8/Lectures/WEB/vorlesung/ sources/
27112002/Vorlesung7.6.pdf, [19.10.2003]
[BOO99]
Booch, G.; Jacobson, I.; Rumbaugh, J.: The unified software development process,
Addison-Wesley, Reading, Mass., 1999
[EUP02]
Enterprise Unified Process (EUP) Home Page:
http://www.enterpriseunifiedprocess.info/, Dec 20, 2002 [20.10.2003]
[PRE02]
Pressemitteilung der Rational Software Group, Dr. Haffa und Partner, 19.02.2002,
http://www.haffapartner.de/kunden/rat/190202rat.htm, [20.10.2003]
[PRO02]
Process Improvement and Software Development with Rational Unified Process,
Rational Software Corporation, 2002,
http://www-3.ibm.com/software/awdtools/rup/, [20.10.2003]
Seite - 12 -