Sie sind auf Seite 1von 6

Rational Unified Process

Nils Kopal
Universitat Kassel, Angewandte Informationssicherheit,
Pfannkuchstrae 1, 34121 Kassel, Germany
nils.kopal@uni-kassel.de

ZusammenfassungBei dieser Seminarausarbeitung handelt II. B EST PRACTICES


es sich um eine Ausarbeitung, die fur ein Bachelorkolloquium
(Bachelor Angewandte Informatik) an der Universitat Duisburg- Die Entwickler von RUP sehen diesen als eine Sammlung
Essen im Jahr 2011 geschrieben wurde. Ich veroffentliche diese und Umsetzung von best practices (welche ins Deutsche
arXiv:1609.07350v1 [cs.SE] 22 Sep 2016

Ausarbeitung, damit interessierte Studierende oder generell an am besten mit bewahrten Erfolgsmethoden zu ubersetzen
Softwareentwicklung Interessierte sich einen ersten Eindruck sind) der Softwareentwicklung. Diese sind hier nun im Fol-
uber den Rational Unified Process erwerben konnen.
Diese Ausarbeitung bietet eine kurze Einfuhrung und einen
genden kurz zusammengefasst.
groben Uberblick uber den Softwareentwicklungsprozess RUP
(Rational Unified Process). Sie beinhaltet einen Uberblick uber A. Software iterativ entwickeln
den zugrunde liegenden Prozessaufbau in Kapitel III, die Phasen Klassische Softwareentwicklung wurde eher mit sequen-
des Prozesses in Kapitel III-C, seine Workflows in Kapitel III-D
und beschreibt die von den RUP Entwicklern immer postulierten
tiellen Modellen betrieben (wie z.B. das Wasserfallmodell).
best practices der Softwareentwicklung in Kapitel II. Hier gibt es eine Reihe von festgelegten Phasen, mit Start-
und Endzeitpunkten. Jede Phase beschaftigt sich mit einer
I. E INLEITUNG anderen Thematik (z.B. Analyse, Design, Implementierung,
In Zeiten immer komplexer werdender Software und im- Testen). Problematisch an diesen Modellen ist, dass es meist
mer umfangreicheren Projekten ist es mittlerweile nicht mehr keinen Ruckschritt in altere Phasen gibt. So mussen Fehler
moglich, eine Software nur mit einer kleinen Anzahl an Mitar- in der Anforderungsanalyse haufig in der Implementierung
beitern und in kurzer Zeit zu entwickeln. In heutigen Softwa- ausgebadet werden. Um dies zu vermeiden, wurden iterative
refirmen und Projekten ist eine Vielzahl von unterschiedlichem Prozesse (wie RUP) entwickelt. Hier durchlauft man jede
Personal teilweise uber Jahre hinweg mit der Erstellung der Phase des Prozesses in kleinen Schritten (den Iterationen),
Software beschaftigt. Viele Projekte scheitern noch immer um sich so immer naher dem fertigen Produkt zu nahern.
an schlechter Planung, unzureichend oder gar nicht erfassten Hier ist vorteilhaft, dass auf Fehler oder festgestellte Probleme
Anforderungen oder auch an den absolut unterschiedlichen einfacher reagiert werden kann. Diese werden in einer der
Vorstellungen der Projektbeteiligten. Dies fuhrt zu erheblich nachfolgenden Iterationen korrigiert.
gesteigerten Entwicklungskosten und vor allem haufig zu
B. Anforderungen verwalten
frustrierten Mitarbeitern und letztendlich frustrierten Kunden.
Um dieser Entwicklung entgegen zu wirken, entwickelt das Groe Softwareprojekte scheitern haufig an mangelhaften
Software Engineering standardisierte Entwicklungsprozesse. bzw. schlecht aufgestellten Anforderungen. Teilweise sind den
In dieser Ausarbeitung wird versucht, zumindest einen welt- Projektbeteiligten die Anforderungen auch uberhaupt nicht
weit anerkannten, erprobten und standardisierten Softwareent- oder nur unzureichend bekannt. Um dem entgegenzuwirken,
wicklungsprozess im Uberblick zu beschreiben und dem Leser werden Anforderungen an zentraler Stelle verwaltet. So kann
einen Eindruck uber diesen zu vermitteln. sich jeder Projektbeteiligte einen Uberblick uber selbige ma-
chen. Anderungen an den Anforderungen werden haufig durch
A. Einfuhrung sogenannte Anderungsanfragen (engl. Change Request) ange-
Der Rational Unified Process (kurz RUP) ist ein Softwa- fordert und mussen von einem Verantwortlichen zunachst ge-
reentwicklungsprozess, der von der Firma Rational Software pruft werden. So versucht man, alle Anforderungen konsistent,
entwickelt und vertrieben wurde. Seit 2003 wird der Prozess sinnig und vor allem implementierbar zu halten.
von IBM, welche Rational Software aufkaufte, unter den alten
Produkt- und Firmennamen weiterentwickelt und vertrieben. C. Komponentenbasierte Architekturen
Erstmals wurde RUP von Daniel Kruchten im Jahr 1996 Software in Komponenten zu gliedern, bringt erhebliche
vorgestellt. Bei RUP handelt es sich nicht um einen einfachen Vorteile in der Entwicklung. Durch standardisierte Schnittstel-
Prozess, sondern vielmehr um ein Prozessframework, das, je len konnen Komponenten einfach ausgetauscht oder auch wie-
nach einsetzender Firma und eingesetztem Projekt, instantiiert derverwendet werden. Eine einheitliche Komponentenstruktur
und angepasst wird. Im RUP wird die Unified Modeling macht die Software ubersichtlicher, einfacher zu verstehen
Language (kurz UML) als Notationsgrundlage genutzt. IBM und somit auch einfacher anzupassen. Das fuhrt zu geringeren
Rational verkauft RUP als Paket. Entwicklungszeiten und bringt Kostenersparnis mit sich.
D. Visuelle Modellierung
Visuelle Modellierung vereinfacht die Softwareentwicklung,
r ms Activity
indem sie Modelle einfacher erstellbar, anpassbar und auch rfo
pe
Mitarbeitern ohne technischem Hintergrund verstandlicher
Re

out
macht. Mit Hilfe von visueller Modellierung lassen sich De- sp

in
on
Role sib
tails zunachst abstrahieren, um sich auf das Kernproblem zu le
for
konzentrieren. Nach und nach konnen diese Modelle dann Tool
immer weiter verfeinert werden, bis man fast schon Quellcode Mentor
Artifact
erhalt (also Quellcode generiert). RUP macht aus diesem
Grund erheblich Gebrauch von der UML, da diese standar-
disierte Modelle fur Use-Cases, Klassen, Komponenten und
so weiter mit sich bringt.
Checkpoints Template Report
E. Software-Qualitat sicherstellen
Qualitatssicherung tragt zu einer stabileren, sichereren und Abbildung 1: RUP Ubersicht
korrekteren Software bei, kurz - sie fuhrt zu erhohter Qua- entnommen von http://www.ibm.com/developerworks/
litat und somit zu mehr Kundenzufriedenheit. Mit Hilfe von rational/library/oct07/uttangi rizwan/index.html
Komponententests, Integrationstests, Lasttests und kontinuier-
lichem Abgleich der Software mit ihren Anforderungen und
Spezifikation wird versucht, die Qualitat auf einem hohem Desweiteren wird im RUP von Workern gesprochen. Ein
Ma zu halten. Worker ist eine Rolle im RUP. Dies kann z.B. ein Prozess-
Designer, ein Softwarearchitekt und so weiter sein.
F. Anderungen an der Software verwalten Zuletzt wird man haufig von Aktivitaten horen. Aktivitaten
Durch das Anderungsmanagement lassen sich Anderungen sind, wie der Name vermuten lasst, Tatigkeiten, die von
an der zu entwickelnden Software einfach verfolgen. Als einem Worker ausgefuhrt werden und auch immer einem
Hilfe werden hier unter anderem Versionsverwaltungssyste- oder mehrerer Worker zugeordnet sind. Die Workflows des
me, Content-Management-Systeme, Ticketsysteme und der- RUP lassen sich auf einzelne Aktivitaten herunterbrechen. In
gleichen eingesetzt. Durch Sandboxen erhalt jeder Entwickler Abbildung 1 sind die Zusammenhange noch einmal grafisch
seinen eigenen, abgeschotteten Bereich in dem er Anderun- verdeutlicht.
gen an der Software vornehmen kann ohne die Entwicklung
anderer Projektbeteiligter zu beeinflussen oder gar zu storen. B. Struktur von RUP
Sind die Entwickler zufrieden mit ihrer Arbeit, konnen sie die
Anderungen einchecken und so allen anderen verfugbar ma-
chen. Im Anderungsmanagement werden Anderungen haufig
durch sogenannte Anderungsanfragen (engl. Change requests)
begleitet. Diese werden zunachst an einem Punkt gesammelt,
dann bewertet und angenommen oder abgelehnt. Wurde eine
Anderungsanfragen angenommen, wird diese einem Entwick-
ler zugeordnet, der die Anderung an der Software vornimmt.
Im Anderungsmanagement werden Richtlinien bezuglich der
Entwicklungsstruktur und der Nutzung der Anderungsmana-
gementsoftware festgelegt, an die sich jeder Projektbeteiligte
halt. So ergibt sich eine durchgangige Struktur, die jeder
Projektbeteiligte kennt und versteht. So wird die Entwicklung
im Team erleichtert und beschleunigt.

III. P ROZESSAUFBAU
Abbildung 2: The
A. Aktivitaten, Artefakte und Worker Rational Unified Process (RUP) entnommen von http://www.
ibm.com/developerworks/webservices/library/ws-soa-term2/
Im RUP gibt es eine Reihe von Fachtermini, wobei hier
drei der wichtigsten naher beschrieben werden. Zum einen
werden alle Ausgabeprodukte, die in RUP produziert werden, RUP ist ein zweidimensionaler Proze. In der Abbildung
als sogenannte Artefakte bezeichnet. Hierbei kann es sich um 2 lassen sich auf der horizontalen Achse die vier Phasen des
ein Dokument, Sourcecode, ein Diagramm oder ahnliches han- Prozesses erkennen. Auf der vertikalen Achse kann man die
deln. Alles was anfassbar ist, wird als Artefakt bezeichnet. neun im RUP definierten Workflows erkennen.
C. Phasen Die Anforderungen sollten von allen Projektbeteiligten
Es existieren vier grundlegende Phasen im RUP, die se- verstanden sein
quentiell durchgearbeitet werden. Diese werden jedoch wie- Glaubwurdigkeit von Kosten- und Zeitplaneinschatzun-

derum in beliebig viele Iterationen unterteilt (je nach Umfang gen, Prioritaten, Risiken und des Entwicklungsprozesses
des einsetzenden Projekts). Eine jede Iteration beinhaltet die Detaillierungsgrad jedes Architekturprototyps, der ent-

sogenannten Kern-Workflows, grundlegende Tatigkeiten, die wickelt wurde


in jeder Phase durchgefuhrt werden. Zeitlich gliedert sich Die aktuellen Ausgaben im Vergleich zu den vorherge-

RUP in vier benannte Phasen (Konzeptualisierungsphase, sagten


Entwurfsphase, Konstruktionsphase, Ubergangsphase) die [1] meint, dass das Projekt, falls es an diesem Milesto-
in diesem Kapitel naher beschrieben werden. Jede Phase wird ne scheitert entweder abgebrochen oder grundlich uberdacht
in einer bis beliebig vielen Iterationen durchlaufen. Dies ist werden sollte.
von der Art und dem Umfang des Projektes abhangig. In 2) Die Entwurfsphase: Die Entwurfsphase
jeder Iteration werden alle Workflows durchgearbeitet. Je nach (engl. Elaboration-phase) entwickelt die in der
Phase sind die Anteile der Workflows unterschiedlich gro, Konzeptualisierungsphase begonnenen Anwendungsfalle
wie man es auch in Abbildung 2 an der unterschiedlichen weiter und bringt diese auf einen moglichst festen Stand (laut
Dicke der horizontalen Linien je Phase, erkennen kann. Der [2] auf eine Vollstandigkeit von ca 80%). Die Architektur
Abschluss einer jeden Phase bildet das Erreichen eines Mile- sollte am Ende dieser Phase vollstandig beschrieben sein
stones (erkennbar in Abbildung 3). und in einem Architekturprototyp vorliegen. Dieser dient
als Grundlage fur die fortschreitende Entwicklung der
darauffolgenden Phasen.
Als Ausgabe-Artefakte sieht [1] folgende:
Den bereits beschrieben Architekturprototyp nebst Be-
schreibung der Architektur
Ein zu 80% fertiges Use-Case-Modell
Uberarbeitete Projekt- und Entwicklungsplane und Ri-
Abbildung 3: Die vier Phasen und
die Meilensteine des Iterativen Prozesses entnommen von [1] sikenabschatzungen
Am Ende der Entwurfsphase steht der zweite Milestone
LCA (Lifecycle Architecture). Hier werden laut [1] folgende
1) Die Konzeptualisierungsphase: Die Konzeptualisie-
Dinge abgepruft:
rungsphase (engl. Inception-phase) dient laut [1] dazu, alle
Stabilitat der Vision des zu entwickelnden Produkts
Projektbeteiligten auf ein gemeinsames Projektziel einzustim-
Stabilitat der entworfenen Architektur
men.
Hierzu gehoren das Verstehen und Aufstellen der Anfor- Wurden alle wesentlichen Risiken gefunden?

derungen, die an das zu entwickelnde System gestellt wer- Detailgrad der Planung fur die Konstruktionsphase aus-

den. Dazu werden fur jede identifizierte Anforderung Anwen- reichend?


dungsfalle (in Form von Use-Case-Diagrammen mit textueller Erreichbarkeit der Vision mit Hilfe der entwickelten

Beschreibung) aufgestellt. Ein weiteres Ziel ist das Finden Architektur und Plane
einer Architektur, mit eventueller Entwicklung eines oder meh- Akzeptanz der aktuellen Kosten im Vergleich zu geplan-

rerer Prototypen. Am Ende der Phase sollte ein Zeitplan und ten Kosten
eine Kostenabschatzung fur die folgenden Phasen stehen. Zu [1] meint, dass das Projekt, falls es an diesem Milestone
guter Letzt werden in der Konzeptualisierungsphase etwaige scheitert entweder, wie im ersten Milestone, abgebrochen oder
Risiken abgeschatzt, erkannt und dokumentiert. uberdacht werden sollte.
Als Ausgabe-Artefakte sieht [1] folgende Dokumente: 3) Die Konstruktionsphase: Die Konstruktionsphase
Ein Visionsdokument, das die Ideen bezuglich der we- (engl. Construction-phase) dient der vollstandigen
sentlichen Funktionen des Systems beschreibt Entwicklung und dem Testen der Komponenten des Systems.
Ein Uberblicks-Use-Case-Modell, das alle bereits iden- Ziel der Phase ist eine fertige und einsetzbare Sofware.
tifizierten Anwendungsfalle und deren Akteure auflistet
Ein Projektplan, der die geplanten Iterationen darstellt Als Ausgabe-Artefakte sieht [1] mindestens:
Ein erstes Glossar wird wahrend der Phase angelegt und Das fertig entwickelte System
uber alle Phasen hinweg weitergepflegt Eine Releasebeschreibung des aktuellen Releases

Am Ende der Konzeptualisierungsphase steht der Milestone Ein Benutzerhandbuch

LCO (Lifecycle Objectives Milestone). Hier sollte laut [1] Am ende der Konstruktionsphase steht der Milestone IOC
folgendes abgepruft werden: (Initial Operational Capability). Bei diesem dritten Milesto-
Das Projektverstandnis aller Projektbeteiligten sollte auf ne wird folgendes abgepruft:
einer Linie sein (bezuglich Umfangsdefinition, Projekt- Ist die Produktstabilitat ausreichend damit die Software
kosten und Einschatzung des Zeitplans) beim Kunden eingesetzt werden kann?
Sind alle Projektbeteiligten soweit in den Betrieb beim
Kunden uberzugehen? Mobilfunkbetreiber

Akzeptanz der aktuellen Kosten im Vergleich zu geplan-


ten Kosten SMS verschicken

Genau wie in den vorherigen Milestones fuhrt eine Nich-


terreichung des Milestones zu einem Projektabbruch oder zu Fotonachricht verschicken
Sender Empfnger
einer grundlichen Uberdenkung des Projektes.
4) Die Ubergangsphase: Ziel der Ubergangsphase (engl.
Transition-phase) ist die Integration des fertigen Systems
in die Umgebung des Kunden. Hierzu werden Beta-Tests
angesetzt. Das System wird an die bestehenden Systeme des
Kunden angeschlossen (Datenbanksysteme, Netzwerk etc.) -
Abbildung 4: Beispiel eines Use-Cases
also installiert. Gleichzeitig werden Benutzer und Admini-
stratoren auf Seiten des Kunden mit dem Umgang des Sy-
stems geschult. Etwaige Fehler werden korrigiert und in neu
notwendig sei. Ein Beispiel, wo dies notwendig sei, ware
erstellten Releases behoben. Am Ende dieser Phase soll es
z.B. die Entwicklung einer Auftragsverwaltung fur die
dem Kunden moglich sein, das System ohne weitere Hilfe des
Vertriebsmitarbeiter von Telekommunikationsanlagen. Der
Entwicklers selbst betreiben zu konnen. Zusammen mit dem
Vertriebs- und Bestellprozess sei in diesem Kontext sehr
Kunden wird festgehalten, ob und wie das System die an es
komplex, da es sich oft um kundenspezifische Losungen
gestellten Anforderungen erfullt.
und nicht um Fertigprodukte handele. Hier macht eine
Der letzte Milestone Produktrelease steht am Ende dieser
Geschaftsprozessmodellierung auf jeden Fall Sinn.
Phase. Hier wird noch folgendes abgepruft:
An diesem Workflow sind im Wesentlichen zwei Arten von
Ist der Kunde mit dem Ergebnis des Projektes zufrieden?
Worker beteiligt:
Akzeptanz der aktuellen Kosten im Vergleich zu geplan-
ten Kosten Der Geschaftsprozess-Analytiker, der die Organisa-
tionseinheiten des Kunden grob beschreibt und die
D. Workflows Geschafts-Use-Cases, und deren Verbindungen zueinan-
der, identifiziert
Die Workflows sind grundlegende Tatigkeiten, die in je-
Der Geschaftsprozessdesigner, der die Workflows in-
der Phase (und in jeder Iteration) durchgefuhrt werden und
nerhalb der Geschafts-Use-Cases beschreibt und diesen
aus unterschiedlichen Aktivitaten bestehen. Jedem Workflow
Arbeiter zuordnet.
sind bestimmte Worker zugeordnet. Wie bereits beschrieben,
werden die einzelnen Workflows, je nach Phase, in unter- b) Anforderungs-Workflow: Der Anfoderungs-
schiedlich starker Auspragung ausgefuhrt. Im RUP gibt es Worfklow (engl. Requirements workflow) dient dazu,
neun sogenannte Kern Workflows, die wiederum in zwei die Anforderungen an das System aufzustellen.
unterschiedliche Arten eingeteilt sind: [1] beschreibt eine Anforderung, als eine Bedingung oder
Die Engineering Workflows, von denen es sechs gibt
eine Funktionalitat, der das System entsprechen muss. Im
Die Supporting Workflows, von denen es drei gibt
Anforderungs-Workflow wird versucht, die Anforderungen,
die der Kunde an das System hat, aufzustellen. Im RUP werden
Ein Workflow kann ein oder mehrere Artefakte als Ausgabe
diese Anforderungen in einem Use-Case Modell festgehalten.
besitzen (z.B. ein Use-Case-Modell, das die Anforderungen
Weitere Ziele sind, laut [1], die Beschreibung einer Benutzer-
beschreibt beim Anforderungs-Workflow). Die Workflows sind
schnittstelle fur das System und eine Basis zu schaffen, um
in Abbildung 2 als vertikale Achse zu erkennen.
die weiteren Iterationen zu planen und um die benotigte Zeit
1) Engineering Workflows: Die Engineering Workflows
und Kosten abzuschatzen.
sind, wie der Name vermuten lasst, die technischen Work-
Als beteiligte Worker nennt [1]:
flows im RUP. Sie beschaftigen sich mit der Entwicklung und
der Unterstutzung der Entwicklung des Systems. Den Systemanalytiker als Leiter der Anforderungser-
a) Geschaftsprozessmodellierungs-Workflow: Im mittlung
Geschaftsprozessmodellierungs-Workflow (engl. Business Den Use-Case-Spezifizierer, welcher die einzelnen Use-
modeling workflow) wird ein Modell der Organisation Cases genauer definiert
und der Prozesse des Kunden entwickelt. Dies wird in Den Architekten, der die fur die Softwarearchitektur
einem Geschafts-Use-Case-Modell (ein Beispiel fur einen wichtigen Use-Cases identifiziert
Anwendungsfall sieht man in Abbildung 4 ) und einem c) Analyse- und Design-Workflow: Im Analyse- und
Objektmodell festgehalten. [1] meint, dass dies nicht in jedem Design-Workflow (engl. Analysis- and Design-workflow)
Softwareprojekt notwendig sei. Als Beispiel nennt er hier die werden die durch den Anforderungs-Workflow gewonnen An-
Anderung der Funktionalitat einer Telekommunikationsanlage, forderungen in Spezifikationen umgewandelt. Das wichtigste
da hier keine vorherige Geschaftsprozessmodellierung Artefakt, das im Analyse- und Design-Workflow produziert
wird, ist das Designmodell. Es besteht laut [1] aus Kolla- Der System-Tester, der die Durchfuhrung der Tests vor-
borationen von Klassen, die in Paketen und Subsystemen nimmt
zusammengefasst werden. Der Analyse- und Design-Workflow Der Integrations-Tester, der alle Komponenten nach der
bildet den Ubergang von den Anforderungen zu der Im- Integration im Zusammenspiel testet
plementierung. Ziel ist es, ein komponentenbasiertes Design Der Performance-Tester, der, wie sein Name vermuten
zu entwickeln. Komponenten besitzen definierte Schnittstellen lasst, fur das Testen unter Performance-Gesichtspunkten
und hangen nur von den Schnittstellen andere Komponenten verantwortlich ist
ab. Durch die Nutzung von Komponenten lassen sich die f) Verteilungs-Workflow: Der Verteilungs-Workflow
Teile des Systems einzeln entwickeln und unabhangig von (engl. Deployment-workflow) beinhaltet, wie der Name
anderen Teilen austauschen und auch in anderen Systemen sagt, die Verteilung des fertigen Produkts. RUP unterscheidet
wiederverwenden. laut [2] zwischen drei Arten der Verteilung: Zum einen die
Beteiligte Worker sind: Verteilung als Installation beim Kunden, dann die Verteilung
Der Architekt, welcher die Gruppierung aller Elemente als Standardprodukt und die Verteilung speziell uber das
(Klassen) und die Definition der Schnittstellen zwischen Internet. Mit der Verteilung geht das Projekt in den operativen
diesen vornimmt Betrieb uber.
Der Designer ist fur den Entwurf von Klassen und Zu den beteiligten Workern zahlt [2] unter anderem
deren Beziehungen und/oder ganzen Paketen von Klassen Den Deployment Manager, der unter anderem einen
verantwortlich Deployment Plan entwickelt, Release Notes schreibt, das
Ist eine Datenbank erforderlich, wird diese vom Produkt letztendlich frei gibt sowie Beta- und Akzeptanz-
Datenbank-Designer entworfen. tests uberwacht
Fur das Review von Architektur und Datenbankdesign Der Implementierer, der die Installationsroutinen oder
sieht RUP Architektur- und Datenbankgutachter vor -Scripte fur die Installation der Software erstellt
d) Implementierungs-Workflow: Der 2) Supporting-Workflows: Neben den technischen Work-
Implementierungs-Workflow (engl. Implementation flows gibt es im RUP noch drei Supporting-workflows. Diese
workflow) befasst sich mit der konkreten Implementierung produzieren nicht, wie die Engineering Workflows, sondern
der Software, also dem Erstellen von Sourcecode. Dieser dienen als Unterstutzende Workflows allen Projektbeteiligten
wird in Klassen und Komponenten zusammengestellt. bei ihrer Arbeit.
Des Weiteren wird der Sourcecode einer jeden a) Projektmanagement-Workflow: Der
Komponente mittels Integration zusammengebracht. Projektmanagement-Workflow dient, wie auch das
Parallel zu der Implementierung laufen in diesem Projektmanagement im Allgemeinen in anderen Projekten,
Workflow Komponententests der einzelnen Komponenten der Steuerung und Kontrolle des Projektflusses. Hierzu zahlen
ab. Ausgabeartefakte waren zum einen die einzelnen die Planung aller am Projekt beteiligten Ressourcen, der Zeit
Komponenten als auch die zusammengefassten Komponenten sowie Kontrolle der Einhaltung des Projektplans. Laut [2]
in einem sogenannten Implementierungssubsystem. ist hier das Risikomanagement von besonderer Bedeutung.
Beteiligte Worker an diesem Workflow sind: Hierunter fallen die Aufstellung und Bewertung einer Liste
Der Implementierer, der die einzelnen Komponenten von Projektrisiken, um diesen fruh genug entgegenwirken zu
implementiert konnen.
Der Integrierer, der alle Komponenten miteinander ver- Der Wichtigste am Projektmanagement Workflow beteiligte
bindet Worker ist der Projektmanager, der planen, kontrollieren und
gegebenenfalls (fruh genug) in das Projekt eingreifen muss,
e) Test-Workflow: Der Test-Workflow dient im RUP der wenn es zu Problemen kommt. Desweiteren verteilt er die
Qualitatssicherung. Im Test-Workflow wird laut [2] versucht, Aufgaben im Projekt, legt den Grundstein fur das Projekt mit
Fehler aufzudecken und nicht, solche zu beheben oder zu dem Projektstart, berichtet an die Auftraggeber des Projekts
losen. Getestet wird nach den im Anforderungs-Workflow (z.B. die Geschaftsleitung) uber den aktuellen Status, hat einen
erstellten Anforderungen. Hierfur wird ein Testmodell aufge- Uberblick uber die Projektkosten, kontrolliert alle Projektbe-
stellt, das alle Testfalle, Testprozeduren, Testscripte und erwar- teiligten routinemassig und beauftragt Projektmitglieder mit
teten Ergebnisse sowie Beschreibungen der Tests beinhaltet. Reviews.
Ausgabeartefakte des Test-Workflows sind ein Testplan, das
b) Konfigurations- und Anderungsmanagement-
bereits genannte Testmodell, ein Auslastungsmodell, welches
Workflow: Im Konfigurations- und
zum Performance-Testen genutzt wird und naturlich Fehler
Anderungsmanagement-Workflow (engl. Configuration-
(= Fehlgeschlagene Tests), die in Anderungsanfragen (zum
and Changemanagement-workflow)wird versucht, alle
Beheben der Fehler) umgewandelt werden.
im Projekt produzierten Artefakte und ihre Beziehungen
Beteiligte Worker an diesem Workflow sind: zueinander zu sichern. Sichern bedeutet hier, sowohl ihren
Der Test-Designer, welcher fur die Planung und Auswer- aktuellen Zustand als auch alle vorherigen Zustande und
tung der Tests zustandig ist deren Anderungen an einem zentralen Punkt zu speichern. So
ist es allen Projektbeteiligten moglich, Anderungen sowohl ihm sinnvoll erscheinenden Teile und nutzt diese im
selbst einfach zu tatigen und an alle anderen zu propagieren, Projektverlauf
als auch Anderungen anderer einfach nachzuvollziehen. Klare Struktur: RUP bietet eine ubersichtliche, klare
Als wichtige neue Worker findet man in diesem Workflow Struktur, was den Aufbau des Prozesses als auch die
unter anderem Verantwortlichkeiten wahrend der Ausfuhrung des Pro-
Den Konfigurationsmanager, der die Projektstruktur zesses betrifft
innerhalb des Konfigurationsmanagementsystems festlegt
B. Nachteile
und dem Projektmanager uber selbiges berichtet
Alle anderen Projektmitglieder, da sie das Konfigurati- Nicht kostenlos: RUP ist proprietar und kostet Geld
onsmanagementsystem als Werkzeug nutzen Schwierige Einfuhrung: Fur die erfolgreiche
Einfuhrung von RUP sollte man externe Berater
c) Umgebungs-Workflow: Der Umgebungs-Workflow
zwingend als Unterstutzung einsetzen
(engl. Environment workflow) dient dem Bereitstellen einer
Komplexitat: RUP ist ein uberaus machtiges Werk-
Entwicklungsumgebung und Prozessen, um die Entwicklung
zeug, dessen Handhabung Jahre der Erfahrung und
zu unterstutzen. Es werden Standards festgelegt, z.B. welche
Nutzung voraussetzt
Entwicklungsumgebung und Tools genutzt werden. Auerdem
RUP muss gelebt werden: Wie jeder andere Soft-
dient der Workflow dem konkreten Anpassen von RUP selbst
wareentwicklungsprozess muss RUP von jedem Pro-
fur das aktuell laufende Projekt. Als wichtige Workflowbe-
jektbeteiligten verstanden, akzeptiert und durchgefuhrt
teiligte lassen sich Tool-Spezialisten nennen. Diese mussen
werden
Tools auswahlen und auf ihre Eignung fur das Projekt prufen.
C. Zusammenfassung
IV. FAZIT RUP ist ein iterativer, inkrementeller, UML-gestutzter Soft-
Dieses Kapitel gibt einen stichwortartigen Uberblick uber wareentwicklungsprozess. Er ist sogar mehr als das, er ist ein
Vorteile und Nachteile, die der Einsatz von RUP mit sich Prozessframework, dass je nach nutzendem Projekt individu-
bringt. Gegen Ende steht eine kurze Zusammenfassung dieser ell instanziiert werden muss. Grundlegend ist RUP in vier
Ausarbeitung. Phasen aufgebaut (Konzeptualisierungsphase, Entwurfsphase,
Konstruktionsphase, Ubergangsphase). Am Ende einer jeden
A. Vorteile Phase steht ein Milestone der erreicht werden muss.
Bekanntheitsgrad: RUP ist ein weltweit verbreiteter RUP definiert Worker, Artefakte und Aktivitaten. Ein Wor-
Prozess, der schon uber Jahre hinweg eingesetzt und ker ist eine Rolle, die einer oder mehreren Aktivitaten zuge-
weiterentwickelt wird ordnet ist. Aktivitaten sind grundlegende Tatigkeiten, wie z.B.
Literatur: Es gibt unzahlige Literatur, die sich mit RUP Programmieren, Dokumentieren und so weiter. Das Ergebnis
beschaftigt einer Aktivitat sind meistens ein oder mehrere Artefakte. Als
Toolunterstutzung: Der Prozess wird von Haus aus Artefakt wird all jenes, das anfassbar ist bezeichnet. Bei-
mit Tools unterstutzt (die von IBM Rational entwickelt spiele hierfur waren ein Dokument, Sourcecode, Projektplane
werden) und so weiter.
Anpassbarkeit: RUP ist individuell an die Projektstruk- Jede Phase von RUP wird in beliebig viele Iterationen
tur und Organisationsstruktur anpassbar aufgeteilt. Die Anzahl der Iterationen je Phase hangt vom Um-
Iterativer Prozess: Durch iteratives Vorgehen kann sich fang des Projektes ab fur das RUP eingesetzt wird. Wahrend
Schritt fur Schritt an die Problemlosung getastet wer- einer jeder Iteration werden die neun Kern Workflows in
den. Probleme konnen fruhzeitig erkannt und behoben unterschiedlichen Anteilen durchlaufen.
oder von vornherein vermieden werden Ein Workflow ist eine Sammlung von Aktivitaten und wird
Unified Modeling Language: RUP setzt UML als einem oder mehreren Workern zugeordnet. Es gibt sechs Engi-
Notation ein - somit sind Teile von RUP bereits meist neering Workflows, die technisch getrieben sind, und drei Sup-
ohne Kenntnis des eigentlichen Prozesses bekannt. Eine porting Workflows, die den Prozess insgesamt unterstutzen.
Kooperation mit externen Schnittstellen, wie anderen Dank seiner Individualisierbarkeit ist RUP sowohl fur kleine
Unternehmen oder dem Kunden, wird so vereinfacht und mittlere als auch groe Softwareprojekte geeignet.
Weiterentwicklung: IBM Rational entwickelt kontinu- Die sechs best practices der Softwareentwicklung dienten
ierlich am Prozess und versucht diesen so mit aktuellen bei der Entwicklung von RUP als Grundlage.
Neuentwicklungen und dem neuesten Stand der Soft- L ITERATUR
wareentwicklung auszurusten
[1] P. Kruchten, Der rational unified process: Eine Einfuhrung. Pearson
Skalierbarkeit: RUP ist sowohl fur kleine Projekte Deutschland GmbH, 1999.
als auch fur groe Projekte flexibel einsetzbar. Der [2] A. Essigkrug and T. Mey, Rational unified process kompakt. Spektrum
Nutzer wahlt vor der Instanziierung des Prozesses die Akademischer Verlag in Elsevier, 2007.