System Integration Unified Process - Eine Modifikation des Rational Unified Process für die System Integration


Diplomarbeit, 2005
115 Seiten, Note: 2,0

Leseprobe

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1. Die Einführung - ein Kurzüberblick
1.1 Motivation für diese Diplomarbeit
1.2 Motivation für die Verwendung des RUP als SUP-Basis
1.3 Kurzüberblick über den weiteren Verlauf der Diplomarbeit

2. Der SI Rahmen - eine Begriffsabgrenzung
2.1 Begriffsdefinition
2.2 Integrationsreichweite
2.3 Integrationsarten
2.4 Enterprise Application Integration
2.5 Aufgabengebiet für einen System Integrator
2.6 Schnittstellen zu anderen Bereichen eines Projektes

3. Der RUP - eine abstrakte Modellbeschreibung
3.1 Die Entstehungsgeschichte
3.2 Der RUP und die Unified Modelling Language
3.3 Die Struktur des RUP
3.3.1 Die dynamische Struktur
3.3.2 Die statische Struktur
3.3.3 Die Gesamtprozessstruktur
3.4 Schwachstellen im RUP

4. Der SUP - ein Prozessmodell für die SI
4.1 Die dynamische Prozessstruktur im SUP
4.1.1 Die Phasen im SUP
4.1.1.1 Phase 1: Proposal
4.1.1.2 Phase 2: Inception
4.1.1.3 Phase 3: Elaboration
4.1.1.4 Phase 4: Construction
4.1.1.5 Phase 5: Transition
4.1.1.6 Phase 6: Production
4.1.1.7 Phase 7: Retirement
4.1.2 Die Iterationen im SUP
4.2 Die statische Prozessstruktur im SUP
4.2.1 Business Modelling
4.2.2 Requirements
4.2.3 Analysis & Design
4.2.4 Implementation
4.2.5 Test
4.2.6 Deployment
4.2.7 Configuration & Change Management
4.2.8 Project Management
4.2.9 Environment
4.2.10 Operations & Support
4.3 Die Gesamtprozessstruktur

5. Das Beispiel - eine Anwendung des SUP
5.1 Die Ausgangssituation
5.2 Die Phasen des Beispiels

6. Das Fazit - eine Ergebnisanalyse
6.1 Kurzüberblick über das Modell
6.2 Ergebnisse der RUP-Modifikation
6.3 Fortführende Aufgaben bzgl. der SUP-Entwicklung

Literaturverzeichnis

Der Anhang
Anhang 1: Die Rollen im SUP
Anhang 2: Die Artefakte im SUP

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1: Aufbau eines Systems

Abbildung 2: Interne und externe Integration

Abbildung 3: Integration in eine existierende Systemlandschaft

Abbildung 4: Integration einer zu bildende Systemlandschaft

Abbildung 5: Die externen Projektbeteiligten in einem SI-Projekt

Abbildung 6: Der RUP als Ableitung des UP

Abbildung 7: Die Gesamtprozessübersicht des RUP-Hump Chart

Abbildung 8: Der Zusammenhang der statischen RUP-Konzepte

Abbildung 9: Die Phasen und Meilensteine des SUP

Abbildung 10: Eine SUP-Iteration mit Abstimmung zu einer externen Iteration

Abbildung 11: Der Workflow der Business Modeling-Disziplin

Abbildung 12: Der Workflow der Requirements-Disziplin

Abbildung 13: Der Workflow der Analysis & Design-Disziplin

Abbildung 14: Der Workflow der Implementation-Disziplin

Abbildung 15: Der Workflow der Test-Disziplin

Abbildung 16: Der Workflow der Deployment-Disziplin

Abbildung 17: Der Workflow der Configuration & Change Management-Disziplin

Abbildung 18: Der Workflow der Project Management-Disziplin

Abbildung 19: Der Workflow der Environment-Disziplin

Abbildung 20: Der Workflow der Operations & Support-Disziplin

Abbildung 21: Das Zusammenspiel der Phasen und Disziplinen im SUP

Abbildung 22: Der grobe Projektplan für das Beispielprojekt

Abbildung 23: Die Beteiligten in den Proposal-Phase des Beispielprojektes

Abbildung 24: Die Proposal-Phase im Beispielprojekt

Abbildung 25: Die Inception-Phase im Beispielprojekt

Abbildung 26: Die Elaboration-Phase im Beispielprojekt

Abbildung 27: Die Construction-Phase im Beispielprojekt

Abbildung 28: Die Transition-Phase im Beispielprojekt

Abbildung 29: Die Production-Phase im Beispielprojekt

Abbildung 30: Die Retirement-Phase im Beispielprojekt

Tabellenverzeichnis

Tabelle 1: Die Aufwände für das Beispielprojekt

Tabelle 2: Die Rollen im SUP

Tabelle 3: Die Artefakte im SUP

1. Die Einführung - ein Kurzüberblick

Die Einführung soll einen Überblick über die Motivation zu der vorliegenden Diplomarbeit und den im Diplomarbeitsverlauf zu beantwortenden Fragen geben.

1.1 Motivation für diese Diplomarbeit

Die System Integration (SI) ist ein breites Feld im Bereich der Informationstechnologie (IT). Viele durchgeführte SI-Projekte, weisen einen ähnlichen Ablauf auf. Für die System Integration existiert aber bislang kein allgemeingültiges Vorgehensmodell, welches den SI-Prozess unterstützt. Damit aber nicht für jedes Projekt ein neuer Vorgehensplan erstellt werden muss, ist ein allgemeingültiges, strukturiertes und flexibles Prozessmodell sinnvoll. Dieses sollte Erfahrungen aus der Praxis beinhalten, die bei der Durchführung eines SI-Projektes von Bedeutung sind. Darüber hinaus soll der gesamte Lebenszyklus einer Systemlandschaft betrachtet werden. Durch die Anwendung eines Standardprozesses ergeben sich viele Vorteile, die sich hauptsächlich durch Zeit- und Kosteneinsparungen sowie Qualitätssteigerungen erkennen lassen. Zusätzlich wird mit einem Vorgehensmodell die Möglichkeit geschaffen einen bestimmten Prozess wiederholbar und vorhersehbar zu machen. Und man bringt allen Beteiligten das gleiche Verständnis für den durchzuführenden Prozess bei.

Ziel dieser Arbeit ist die Entwicklung eines Prozessmodells für die System Integration auf Basis des Rational Unified Process (RUP). Es soll gezeigt werden, dass der RUP, als ein in der Praxis bewährtes Modell, eine gute Basis für das zu entwickelnde Prozessmodell darstellt. Der Name des SI-Standardprozesses baut auf dem des RUP auf. Er ist System Integration Unified Process (SUP).

Neben der Hauptaufgabe, der Entwicklung eines Prozesses für die System Integration, sollen mit dieser Diplomarbeit die Problemstellungen erläutert und zu lösen versucht werden:

- Existieren Schwachstellen im RUP bei der praktischen Anwendung? Der RUP ist zwar ein Vorgehensmodell, welches auf Erfahrungen aus der Praxis, den so genannten Best Practises basiert, aber aufgrund von Unterschieden in Ausgangssituationen und Projektbedingungen, können sich Schwachstellen ergeben. Für identifizierte Schwachstellen die auch im SUP relevant sind, wird versucht ein Lösungsansatz zu finden.
- Wie hoch ist der Grad der RUP-Modifikation, so dass SI-Projekte damit abgebildet werden können? Unter die Modifikation fallen Anpassungen und Erweiterungen. Anpassungen können bei der Konfiguration des RUP vorgenommen werden und sind somit RUP-intern. Erweiterungen stellen dagegen ein Vorgehen außerhalb der RUP-Grenzen dar. Ziel ist es herauszufinden, ob es ausreicht lediglich Anpassungen für die Durchführung eines SI-Projektes vorzunehmen.

1.2 Motivation für die Verwendung des RUP als SUP-Basis

Die Entwicklung eines neuen Prozessmodells ist bei der Vielzahl der vorhandenen nicht sinnvoll. Vielmehr sollte ein bestehendes Modell auf die Bedürfnisse und Anforderungen der System Integration angepasst werden. Der RUP bietet sich dafür an. Er ist ein erfolgreiches Prozessmodel zur Entwicklung von objektorientierter Software. Seine Entwicklung fand auf der Basis von so genannten Best Practises statt, die aus der Praxis entstanden sind, und somit Praxisanforderungen in das Model einbringen.1 Die Vorteile des RUP gegenüber anderen Prozessmodellen besteht unter anderem in der iterativen Vorgehensweise, seiner detaillierten Beschreibung, wer wann was zu tun hat und in seiner Flexibilität.

1.3 Kurzüberblick über den weiteren Verlauf der Diplomarbeit

Die Einführung in das Thema dieser Diplomarbeit beginnt im 2. Kapitel. Dort wird der Begriff der System Integration detailliert eingeführt und abgegrenzt. Dieses Kapitel bildet die Basis für die Inhalte des Hauptteils in Kapitel 4. Im folgenden Kapitel 3 wird dann eine Übersicht darüber gegeben, wie der RUP entstanden ist, auf welchem Gebiet der Informatik er angewendet wird und was seine abstrakten Hauptkonzepte sind. Nach diesen beiden einführenden Kapiteln beginnt mit Kapitel 4 der Hauptteil. Dort wird der SUP entwickelt und beschrieben. Dabei werden die bereits vom RUP bekannten Hauptkonzepte mit Inhalten für die System Integration gefüllt. Der in Kapitel 4 entstandenen Ansatz liefert anschließend die Basis für das Beispiel in Kapitel 5, das die Anpassung des SUP für einen konkreten Fall beinhaltet. In dem abschließenden Kapitel 6 werden die im Hauptteil gewonnenen Erkenntnisse zusammengefasst und zu bewerten versucht. Es folgt als Abschlusspunkt ein Überblick über weitere Aufgaben die bezüglich der SUP-Entwicklung vorgenommen werden müssten, um den Prozess zu vervollständigen.

2. Der SI Rahmen - eine Begriffsabgrenzung

System Integration ist ein in der Informatik häufig verwendetes Schlagwort, wobei es in der Literatur unterschiedliche Ansätze in der Ausdehnung und der Abgrenzungen gibt. Die folgenden Unterkapitel schaffen einen Rahmen, der den Begriff der System Integration für diese Diplomarbeit abgrenzt.

2.1 Begriffsdefinition

In der Literatur findet man unter anderem folgende Definitionen:

(1) System Integration ist: „die Einbettung von bestehenden und neuen IT- Systemen in eine bestehende IT-Landschaft“2.
(2) System Integration ist: „Die technische Zusammenführung von mehreren Komponenten oder Subsystemen zu einem gesamten System“3.
(3) „Because applications are complex, they must be built of parts which are first developed separately and then assembled. “Integration” refers to this assembly process”4.

Der Begriff setzt sich aus zwei Teilen zusammen, System und Integration.

Ein System ist ein unterteiltes Ganzes, das von seiner Umwelt5 durch klare Grenzen, den so genannten Systemgrenzen, getrennt ist.6

Systeme bestehen aus Subsystemen die ihrerseits wiederum Systeme sein können.7 Durch die Verknüpfung der Subsysteme dient ein System einem ganz bestimmten Zweck.8 Das bedeutet, dass seine Existenz durch diesen Zweck begründet ist. Willkürlich angeordnete Subsysteme bilden also noch kein System. Damit (Sub-) Systeme miteinander kommunizieren können, muss es Schnittstellen geben.9 Eine Schnittstelle verbindet mindestens zwei (Sub-) Systeme so, dass verschiedene „Merkmale der Systeme bei der Kommunikation angeglichen werden“10. Der Systemaufbau wird in Abbildung 1 grafisch verdeutlicht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Aufbau eines Systems

Integration stammt von dem lateinischen Wort integratio ab, was die Wiederherstellung eines Ganzen bedeutet.11 Auch die „Herstellung einer Einheit oder Eingliederung in ein größeres Ganzes“12 ist unter dem Integrationsbegriff zu verstehen.

In Anlehnung an die beiden Begriffserklärungen und an die oben unter (2) verwendete Beschreibung ergibt sich für diese Diplomarbeit folgende SI-Definition: System Integration ist der Bereich in der Informatik, der sich damit beschäftigt, (Sub-) Systeme über Schnittstellen miteinander zu verknüpfen, um somit ein zweckgebundenes Ganzes zu schaffen. Diese Systeme können sowohl Soft- als auch Hardwaresysteme sein. Die Hauptaufgabe liegt dabei in der Bearbeitung der Schnittstellen, um die Systeme sinnvoll miteinander verknüpfen zu können.

Systeme können innerhalb ihrer Grenzen integriert werden (intern) oder mit Systemen, die sich in ihrer Umwelt befinden (extern). Dieser Aspekt wird durch die Abbildung 2 grafisch verdeutlicht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Interne und externe Integration

Die System Integration wird von einem System Integrator vorgenommen.

In dieser Diplomarbeit wird der Begriff dafür wie folgt abgegrenzt: Ein System Integrator ist ein Bereich13, der in einem IT-Projekt14 dafür zuständig ist, dass alle benötigten Soft- und Hardwaresysteme zu einer umfangreichen, einheitlichen Gesamtlösung zusammengeführt werden.15 Die einzelnen Systeme werden nach einem genauen Plan verknüpft, oder in eine bestehende Systemlandschaft eingebunden. Zusätzlich kann die erstellte Systemlandschaft während ihrer Laufzeit vom System Integrator gewartet und bei der Stilllegung betreut werden. Alles was zur Erfüllung dieser Ziele erforderlich ist, wird vom System Integrator selbst, oder in seinem Auftrag vorgenommen Die System Integration spielt eine immer wichtigere Rolle im IT-Bereich. Insbesondere darum, weil innerhalb eines Unternehmens eine steigende Anzahl an Systemen existieren, die isoliert voneinander eingesetzt werden.16 Aber die zunehmende Automatisierung von Unternehmensprozessen verlangt einen immer höheren Grad der Integration der einzelnen Systeme.

2.2 Integrationsreichweite

Bei der System Integration kann nach der Reichweite der Integration unterschieden werden.17 Auf Unternehmensebene existieren die interne und die externe Integration. Intern ist die Integration von verschiedenen Systemen innerhalb eines Unternehmens. Extern ist die Integration von unternehmensinternen Systemen mit Unternehmensgrenzen überschreitenden Systemen. Als Beispiel für eine externe Integration kann eine Verknüpfung eines unternehmensinternen Artikelverwaltungssystems mit einem Bestellsystem für Kunden über das Internet genannt werden.

2.3 Integrationsarten

In der Praxis können sich für einen System Integrator je nach Aufgabenstellung zwei verschiedene Arten der Integration ergeben. Zum einen die Integration eines Systems in eine bestehende Systemlandschaft und zum anderen die Bildung einer Systemlandschaft.

Eine Systemlandschaft besteht aus mindestens zwei Systemen, die bereits miteinander verknüpft sind.

Integration in eine bestehende Systemlandschaft:

Bei dieser Integrationsart sollen ein oder auch mehrere18 Systeme in eine existierende Systemlandschaft integriert werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Integration in eine existierende Systemlandschaft

Diese Art der Integration bedeutet, dass nur das zu integrierende System mit den anderen Systemen verknüpft werden muss, aber nicht die anderen Systeme miteinander. Für die Integration sind Schnittstellen an die Systemlandschaft an dem zu integrierenden System anzupassen oder ggf. neu zu entwickeln. Die Schnittstellen an den anderen Systemen bleiben unverändert, damit die Systemlandschaft stabil bleibt.19 Je nach Aufgabenstellung ist es nötig, dass die Subsysteme nicht nur an den Schnittstellen, sondern innerhalb des zu integrierenden Systems angepasst werden.

Integration einer zu ermittelnden Systemlandschaft:

Diese Integrationsart geht nicht von einer bestehenden Systemlandschaft aus. Es ist hierbei vielmehr das Ziel die Systemlandschaft zu bilden, um damit einen bestimmten Zweck zu erfüllen. Dafür müssen die benötigten Systeme erst ermittelt und dann integriert werden. Die Ermittlung kann durch den System Integrator selbst, oder zum Beispiel durch seinen Auftraggeber erfolgen. Wenn nötig, müssen die Systeme vor der Integration jeweils angepasst werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Integration einer zu bildende Systemlandschaft

2.4 Enterprise Application Integration

Enterprise Application Integration, im Folgenden mit EAI abgekürzt, ist der Oberbegriff für Produkte, die Softwaresysteme integrieren.20 Diese werden auch Integrationsserver genannt.21 Grundsätzlich agieren Integrationsserver im EAI-Bereich als Middleware22 zwischen Softwaresystemen die miteinander verknüpft werden.23 Sie sind zuständig für das Routing24 und Mapping25 der Informationen, die zwischen den integrierten Systemen ausgetauscht werden.26 Die Middleware stellt dabei die nicht vom Betriebssystem angebotenen Dienste zur Verfügung.27

Weitere Details zum Thema EAI werden in dieser Diplomarbeit nicht betrachtet. Dieses Kapitel soll lediglich einen Einblick darüber geben, dass Schnittstellen über bestimmte Produkte realisiert werden können. Wie ein System Integrator dann tatsächlich vorgeht ist nicht Thema der vorliegenden Diplomarbeit.

2.5 Aufgabengebiet für einen System Integrator

Das Hauptaufgabengebiet für einen System Integrator besteht, wie die Definition besagt, in der Verknüpfung von unterschiedlichen (Sub-) Systemen. In der Praxis werden aber nicht nur beim Auftraggeber bestehende Systeme verknüpft, es werden vielmehr neue Systeme in das Unternehmen gebracht und mit den bestehenden Systemen integriert. Üblicherweise ist der System Integrator ein Spezialist für diese neuen Systeme, ansonsten muss er sich das Wissen darüber „einkaufen“.

Für den System Integrator fallen bei der Verknüpfung der Systeme eine Vielzahl von verschiedenen Tätigkeiten an, deren Schwerpunkte in den folgenden Bereichen liegen:

Projektmanagement:

Ein System Integrator muss die gesamten bei der System Integration anfallenden Aufgaben planen, kontrollieren und überwachen.28 Außerdem erstellt er einen Integrationsplan der beschreibt, in welcher Reihenfolge welche Systeme angepasst und integriert werden.29 Neben diesen Tätigkeiten gehört das Managen von Budget, Mitarbeitern und Zeitplänen ebenso zum Projektmanagement.30

Angebotserstellung:

Um ein Projekt überhaupt zu starten, muss ein System Integrator den Auftrag dazu erst erhalten. Dafür teilt der potentielle Auftraggeber den möglichen Auftragnehmern seine Anforderungen an die zu erstellende Systemlandschaft mit. Diese Anforderungen können in schriftlicher Form, wie zum Beispiel einem Request for Proposal (RfP), übergeben werden, oder in verbaler Form, beispielsweise durch eine Präsentation.31 In der Zeit der Angebotserstellung muss sich der System Integrator einen Überblick über die Anforderungen und den Umfang der zu erstellenden Systemlandschaft verschaffen. Mit diesen Informationen muss er dann eine Analyse der Machbarkeit und des Aufwandes erstellen.

Geschäftsprozessmodellierung und -analyse:

Bei der Geschäftsprozessanalyse hat ein System Integrator die Aufgabe, die bestehende Systemlandschaft und die Geschäftsprozesse32 (GP) des Auftraggebers, die im Zusammenhang mit der Integration stehen, zu identifizieren und zu analysieren.33 Aus den geschäftsprozesstypischen Sachverhalten eines Unternehmens können bei der Geschäftsprozessmodellierung Modelle34 entwickelt werden.35 Abhängig davon, ob es sich um eine Ist- oder eine Sollanalyse handelt, liefert die Modellierung den Input für die Analyse oder umgekehrt.36

Analyse und Design:

Ein System Integrator muss die Anforderungen an die vorzunehmende Integration verstehen und analysieren.37 Auf Basis dieser Anforderungen muss ein Design für die Schnittstellen und die systeminternen Anpassungen entwickelt werden.

Systemanpassung:

Bei der Systemanpassung werden Änderungen an einem System vorgenommen, so dass die Anforderungen an das System erfüllt werden.38 Diese Anforderungen beziehen sich oft auf die Schnittstellen. Unter die Systemanpassungen fallen aber auch

Änderungen, die nichts mit den Schnittstellen zu tun haben, die aber wichtig für die Integration sind.

Integrationstest:

Der Integrationstest hat einen hohen Stellenwert bei der System Integration. Hierbei werden integrierte Soft- und Hardwaresysteme getestet und ihre Wechselwirkung bewertet.39 Mit dem Integrationstest kann ein System Integrator feststellen, ob das System so funktioniert wie es geplant wurde.40

Migration:

Bei der Migration werden Daten von einem auf ein anderes System umgestellt.41 Dies wird zum Beispiel bei der Ablösung eines alten Systems notwendig. Für die Migration werden häufig eigene Systeme entwickelt, die die Konvertierung der Daten des alten auf das neue System vornehmen.

Inbetriebnahme:

Bei der Inbetriebnahme wird ein neu erstelltes System erstmals unter realen Bedingungen eingesetzt.42 Ein System Integrator kann zwischen zwei möglichen Einführungsstrategien wählen.43 Er kann zum einen den so genannten Big Bang Ansatz wählen, bei dem alle zu integrierenden Systeme zum gleichen Zeitpunkt integriert werden.44 Zum anderen kann er die inkrementelle Strategie wählen. Dabei wird ein System nach dem anderen integriert und in Betrieb genommen.45

Je nach Ausgangssituation sind die beschriebenen Tätigkeiten unterschiedlich stark ausgeprägt auszuführen.

Alle beschriebenen Aufgaben werden im Hauptkapitel abgegrenzt.

2.6 Schnittstellen zu anderen Bereichen eines Projektes

In einem SI-Projekt existieren viele Schnittstellen zum System Integrator. Diese Schnittstellen verbinden ihn mit verschiedenen Projektbeteiligten, die sich, wie in Abbildung 5 dargestellt, grob in Auftraggeber, Lieferanten, Berater und externe Spezialisten einteilen lassen. Die Schnittstellen werden durch Medien wie zum Beispiel E-Mails, Briefe, Telefone usw. realisiert. Die beschriebenen Projektbeteiligen sind alle extern was bedeutet, dass sie nicht zum System Integrator gehören, sondern eigene Bereiche sind.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Die externen Projektbeteiligten in einem SI-Projekt

Im Folgenden werden die externen Projektbeteiligten kurz erläutert.

Auftraggeber:

Ein Auftraggeber stellt die Anforderungen und die Mittel für ein Projekt und ggf. für die spätere Wartung und Stilllegung. Wenn der Bereich SI ein Teil46 eines Unternehmens darstellt, kann der Auftraggeber unternehmensintern, ansonsten auch -extern sein.47 Intern kann zum Beispiel die Unternehmensleitung sein, extern könnte eine Versicherung sein, die einzelne Systeme (zum Beispiel Kundenmanagement und Auftragsverwaltung) miteinander verknüpfen will.

Lieferanten:

Das sind externe Dienstleiter, die für den System Integrator arbeiten.48 Sie bekommen häufig Aufgaben zugetragen, die nicht in das Tätigkeitsfeld eines System Integrators passen, aber dennoch bearbeitet werden müssen. Ein Lieferant kann zum Beispiel ein Softwarehersteller sein, der bestimmte Schnittstellen entwickelt.

Berater:

Berater können bei grundlegenden Untersuchungen unterstützen, wie zum Beispiel bei der Geschäftsprozessmodellierung.49

Externe Spezialisten:

Das sind Experten, die durch Fachwissen und Erfahrung unterstützen.50 Sie arbeiten direkt vor Ort und sind in das Projektteam des System Integrators eingebunden. Es fehlt ihnen an bedeutender Entscheidungsgewalt innerhalb des Projektes, und sie sind dem Projektleiter unterstellt.51

Ein System Integrator kann in einem Projekt die Rolle eines Generalunternehmers (GU) einnehmen. Dann ist der Grad der Verantwortung sehr hoch. Ein Generalunternehmer ist der „von einem Auftraggeber mit der Ausführung eines Auftrages … betraute Unternehmer, der sich zur Erfüllung Auftrages anderer Unternehmer … bedient“52. Innerhalb eines Projektes obliegt dem Generalunternehmer die Gesamtverantwortung. Er agiert als Schnittstelle zwischen dem Auftraggeber und allen weiteren Projektbeteiligten.53 Des Weiteren ist er zuständig für die Angebotserstellung und die gesamte Vertragsabwicklung des Projektes.

Ob ein System Integrator die Rolle eines Generalunternehmers einnimmt, hängt in der Praxis häufig von seiner Kompetenz ab. Zusätzlich kann die Beziehung zwischen dem Projektauftraggeber, der schließlich über die Auftragsvergabe entscheidet, und dem System Integrator ausschlaggebend sein.

3. Der RUP - eine abstrakte Modellbeschreibung

Der RUP ist ein Prozessmodell für die strukturierte Entwicklung und Instandhaltung von objektorientierter Software. Er gilt als ein anerkannter Industriestandard.54 In der RUPBeschreibung werden die bei einem Softwareentwicklungsprozess anfallenden Hauptfragen beantwortet:55

- Welche Personen sind an dem Prozess beteiligt (Wer)?
- Welche Aufgaben fallen während des Prozesses an (Wie)?
- Welche Ergebnisse fallen während des Prozesses an (Was)?
- Zu welchen Zeitpunkten und in welcher Reihenfolge sind die Prozessaktivitäten zu tätigen (Wann)?

Insbesondere wird eine logische Verknüpfung zwischen dem Wer, Wie, Was und dem Wann hergestellt.

Der RUP ist aber nicht nur ein abstraktes Prozessmodell, sondern auch ein konkretes Produkt.56 Von IBM57 wird der RUP regelmäßig weiter entwickelt.58 Er durchläuft dabei halbjährliche Releasezyklen.59 Die zurzeit aktuelle Version ist die Version 6.13. Das Produkt ist als CD-ROM oder online erhältlich. Zudem wird ein Satz Handbücher angeboten.60

Da jedes Unternehmen und jedes Projekt spezifische Anforderungen haben, muss der RUP vor seiner Verwendung für diese Anforderungen angepasst werden.61 In der Objektorientierung würde man von einer Instantiierung des RUP sprechen.

Die Möglichkeit der Anpassung auf eigene Bedürfnisse, sowie seine Vollständigkeit, machen den RUP zu einem besonderen Prozessmodell.62

3.1 Die Entstehungsgeschichte

Der RUP wurde im Jahre 1999 erstmals veröffentlicht. Verantwortlich für seine Entstehung ist das Unternehmen Rational Software63 mit starken Einflüssen durch die drei Mitarbeiter Grady Booch, Jim Rumbaugh und Ivar Jacobson.64 Wie auch aus Abbildung 6 ersichtlich ist, ist der RUP vom Unified Process (UP) abgeleitet65.66 Das bedeutet, dass der Rational UP alle Eigenschaften des UP geerbt hat (die für den RUP angepasst sein können), darüber hinaus besitzt er aber noch eigene Eigenschaften, die der UP nicht hat.67

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Der RUP als Ableitung des UP

Eine Neuentstehung ist der RUP also nicht, sondern vielmehr eine Erweiterung eines aus jahrelanger Erfahrung entstandenen Softwareentwicklungsprozesses.68

3.2 Der RUP und die Unified Modelling Language

Die drei RUP Verantwortlichen - Grady Booch, Jim Rumbaugh und Ivar Jacobson - sind auch hauptverantwortlich für die Modellierungssprache Unified Modelling Language (UML).69 Die UML wurde 1997 von der Object Management Group als offener Industriestandard akzeptiert.70 Sie gilt seitdem als unangefochten bei den Modellierungssprachen für die Objektorientierung (OO).71 Diese grafische Sprache stellt dem RUP das Grundgerüst für die Modellierung zur Verfügung. Er „beschreibt, welches Modell benötigt wird, warum es benötigt wird und wie es zu erstellen ist“72. Das Prozessmodell RUP könnte für jede Art der Softwareentwicklung verwendet werden. Aufgrund der Nutzung der UML gilt er aber als Standard für die objektorientierte Softwareentwicklung.

3.3 Die Struktur des RUP

Der RUP besteht aus einer Vielzahl von verschiedenen Konzepten, die in einem logischen Zusammenhang stehen. Durch diese Konzepte wird er definiert und von anderen Prozessmodellen abgegrenzt. Die RUP-Struktur besteht aus zwei Dimensionen, der dynamischen und der statischen.73

Quelle: In Anlehnung an Kroll, P., Kruchten, P. (2003), S. 10.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Die Gesamtprozessübersicht des RUP-Hump Chart

Die Abbildung 7 skizziert die Gesamtprozessübersicht des RUP aus der auch die dynamische und die statische Struktur ersichtlich werden. Die horizontale Ebene, die Zeitebene, repräsentiert dabei die dynamischen Konzepte, und über die vertikale Ebene werden die statischen RUP Konzepte abgebildet.74

Im Folgenden werden diese Konzepte näher beschrieben. Die Beschreibung geht aber nicht auf inhaltliches ein, sondern bleibt auf einer allgemeinen und abstrakten Ebene.

3.3.1 Die dynamische Struktur

Die dynamische Struktur beschreibt die zeitliche Dimension des RUP.75 Darunter fallen das Phasenkonzept, die Meilensteine, die Iterationen und das Konzept der inkrementellen Entwicklung.76

Phasen und Meilensteine:

Der RUP ist in vier Phasen aufgeteilt, deren Reihenfolge immer fest ist. Über diese Phasen wird der Fortschritt des Projektes im Verlaufe der Zeit definiert.77 Alle vier Phasen haben bestimmte Ziele und Aktivitäten die jeweils erreicht bzw. durchgeführt werden müssen.78 Durch einen Meilenstein wird jede Phase abgeschlossen.79 Diese stellen jeweils wesentliche Ziele dar, die projektspezifisch definiert werden müssen.80 Bei Erreichung eines Meilensteins muss entschieden werden, wie die weitere Vorgehensweise ist: Soll das Projekt fortgeführt, abgebrochen, oder der Projektverlauf geändert werden.81 Damit dienen Meilensteine auch der Qualitätssicherung.82 Die Länge einer Phase hängt somit vom Passieren eines Meilensteins ab und ist jeweils projektspezifisch.83

Iterationen und inkrementelle Entwicklung:

Softwareentwicklungsprozesse, wie zum Beispiel das Wasserfallmodell, gehen im Bezug auf die Aktivitäten von einem linearen und sequentiellen Ablauf aus.84 Beim Wasserfallmodell werden alle dort vorhandenen Phasen nacheinander abgearbeitet. Das bedeutet, dass zuerst alles geplant, dann entwickelt und dann getestet wird. Bei dieser Vorgehensweise werden Fehler erst sehr spät erkannt, und der Auftraggeber bekommt erst gegen Ende des Projektes einen Einblick in die entstehende Software.85 Der RUP arbeitet anders, er geht iterativ vor. Bei der Iterativen Entwicklung werden die Disziplinen86, die im RUP durchzuführen sind, jeweils mehrmals in einer Phase zyklisch durchgeführt.87 Jedes einzelne Durchlaufen ist eine Iteration in der jede Disziplin einmal ausgeführt werden kann (welche Disziplinen tatsächlich durchlaufen werden, hängt von dem durchzuführenden Projekt ab).88 Das bedeutet, dass es pro Phase mindestens eine Iteration gibt. Die genaue Anzahl ist projektspezifisch und hängt von der Komplexität eines Projektes ab: Je komplexer, desto mehr Iterationen existieren pro Phase.89 Nicht in jeder Phase ist die gleiche Anzahl an Iterationen durchzuführen. Eine Iteration stellt grundsätzlich die Basis für ihren Nachfolger dar.90 Dennoch kann eine Iteration bereits gegen Ende der Vorgängeriteration begonnen werden.91

Das Ergebnis nach jeder Iteration ist ein ausführbares internes oder externes Release92.93 Ein internes Release wird nicht an den Auftraggeber ausgeliefert, sondern dient nur internen Zwecken. Ein externes hingegen wird an den Auftraggeber ausgeliefert. Durch die vielen Releases wächst das gesamte zu entwickelnde Softwaresystem inkrementell, was bedeutet, dass Umfang und Qualität nach jeder Iteration zunehmen.94 Die Differenz zwischen den Ergebnissen zweier aufeinander folgender Iterationen wird Inkrement genannt.95 Iterationen können in Zeit gemessen werden.96 Ein Inkrement kann dagegen an der Quantität von zum Beispiel Quellcodezeilen oder umgesetzten Anforderungen gemessen werden.97 Die Verwendung des iterativen und inkrementellen Konzepts beinhaltet für den RUP viele Vorteile gegenüber dem rein sequentiellen Konzept.

Beispielhaft folgen einige Vorteile des Iterativen Vorgehens:

- Kritische Projektrisiken können frühzeitig erkannt werden.98
- Sich im Projektverlauf ändernde oder neue Anforderungen können gut eingebracht werden.99
- Missverständnisse und Widersprüchlichkeiten können bereits relativ früh aufgedeckt, und somit darauf reagiert werden.100
- Die Belastungen an die Projektmitarbeiter werden auf die gesamte Projektlaufzeit verteilt.101

3.3.2 Die statische Struktur

Die Prozesselemente, die die statische Struktur beschreiben, orientieren sich nicht an der Zeit sondern an den Inhalten des RUP.102 Sie beantworten die eingangs erwähnten Fragen: Wer tut Was, Wann und Wie. Das Wer wird durch das Konzept der Rollen103, das Was durch die Artefakte, das Wann durch das Workflowkonzept und das Wie durch die Aktivitäten beantwortet.104 Neben diesen vier Schlüsselkonzepten werden zusätzlich die Konzepte Disziplinen105, Workflow-Details, Templates und Guidelines beschrieben. Die Abbildung 8 beschreibt die wichtigsten statischen Konzepte und ihre Zusammenhänge, auf die auch im Hauptteil dieser Diplomarbeit eingegangen wird.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Der Zusammenhang der statischen RUP-Konzepte

Rollen:

Rollen sind Hüllen für Personen, also Mitarbeiter eines Projektes. Eine Hülle definiert Aufgaben, Kompetenzen und Verantwortlichkeiten innerhalb von Aktivitäten.106 Eine Rolle kann für eine oder mehrere Aktivitäten zuständig sein. Mehrere Personen können eine Rolle einnehmen, und jede dieser Personen kann mehrere Rollen „spielen“.107 Diese Zusammenhänge werden auch durch Abbildung 8 dargestellt.

Artefakte:

Artefakte sind jede Art von greifbaren Informationen die in einem Projekt von einer Rolle in einer Aktivitäten erzeugt, geändert oder einfach nur verwendet werden.108 Sie können in verschiedenster Form auftauchen:109

- Als Modell, wie zum Beispiel ein Klassendiagramm in der UML
- Als Element eines solchen Modells
- Als ein Dokument, wie zum Beispiel der Iterationsplan für die Koordination der Iterationen in einem Projekt.
- Als Quellcode110
- Als ausführbare Datei111

Wie die Abbildung 8 verdeutlicht, können Artefakte zum einen als Eingabe von Aktivitäten verwendet werden und zum anderen die Ausgabe von Aktivitäten sein.112 Artefakte sollten der ständigen Versions- und Konfigurationskontrolle unterliegen.113 Es gibt verschiedene Kategorien in die Artefakte eingeteilt werden können:114

- Management - Alles was zum Software-Geschäft und zum Projektmanagement gehört.
- Anforderungen - Alles was zu den Anforderungen des zukünftigen Softwaresystems gehört.
- Design - Alles was zur Beschreibung des Systemaufbaus gehört.
- Implementierung - Alles was zu dem entwickelten System gehört.
- Verteilung - Alles was zur Auslieferung des entwickelten Systems gehört.

Aktivitäten:

Aktivitäten sind auszuführende Tätigkeiten die immer einem klar definierten Ziel dienen.115 Sie beschreiben wie etwas gemacht werden soll. Aktivitäten werden von einer bestimmten Rolle ausgeführt (siehe auch Abbildung 8).116 Häufig werden bei ihrer Durchführung Artefakte erstellt oder modifiziert.117 Die Dauer der Durchführung einer Aktivität sollte einigen Stunden bis einige Tagen betragen.118

Durch so genannte Schritte werden die Aktivitäten unterteilt.119 Es existieren drei Schritt-Kategorien:120

- Denkschritte - Hierbei werden die Artefakte bestimmt die Eingang / Ausgang einer Aktivität sind. Außerdem soll der Sinn dieser Aktivität erkannt werden.
- Durchführungsschritte - Hierbei wird eine Aktivität tatsächlich ausgeführt.
- Reviewschritte - Hierbei werden die Aktivitätsergebnisse ausgewertet. Nicht in jeder Aktivität müssen alle Schritte durchlaufen werden.

Disziplinen:

Der RUP besteht aus neun unterschiedlichen Disziplinen. Eine Disziplin ist ein Container für eine Vielzahl von Aktivitäten, Artefakten und Rollen. Diese drei statischen Konzepte sind zuständig für die logische Aufteilung der Disziplinen nach Aufgabenbereichen.121 Daraus folgt, dass eine Disziplin einen bestimmten Aufgabenbereich darstellt. Im RUP werden zwei verschiedene Kategorien für die Disziplinen unterschieden, die im Hauptteil näher beschrieben werden:122

- Die Engineering Disziplinen
- Die Supporting Disziplinen

Workflows:

„Ein Workflow stellt die zeitliche Abfolge von Aktivitäten in einer Disziplin … dar“123. Dies wird häufig durch UML-Modelle wie Sequenz- oder Aktivitätsdiagramm realisiert.124 Jede Disziplin besitzt einen Workflow und ein Workflow besteht aus vielen

Workflow-Details.125 Pro Iteration wird ein Workflow genau einmal durchlaufen, allerdings mit unterschiedlichen Schwerpunkten.

Workflow-Details:

Workflows bestehen aus Einheiten in Form von Workflow-Details. Sie gruppieren zusammenhängende Aktivitäten, die diese ausführenden Rollen sowie Ein- und Ausgangsartefakte der Aktivitäten.126 Durch die Workflow-Details wird die Komplexität von Workflows verringert.

Template:

Ein Template ist eine Vorlage für ein Artefakt.127 Im RUP wird eine Vielzahl an Vorlagen für den Benutzer angeboten.128

Guideline:

Zu allen Aktivitäten und Schritten sind Guidelines (Richtlinien) hinzugefügt.129 „Dabei handelt es sich um Regeln, Empfehlungen oder methodische Anleitungen, die die Aktivitäten und Schritte unterstützen“130.

3.3.3 Die Gesamtprozessstruktur

Durch die Graphik - Hump Chart genannt - des RUP, die in Abbildung 7 dargestellt ist, wird die Gesamtprozessstruktur verdeutlicht. Die Hügel jeder Disziplin zeigen, wie stark ausgeprägt diese jeweils in einer Phase durchgeführt werden müssen. Grundsätzlich gibt es Engineering Disziplinen, die in den ersten Phasen stärker ausgeprägt sind, und einige die ihren Schwerpunkt in den späteren Phasen haben. Die Ausprägungen der Supporting Disziplinen hingegen, sind eher gleichmäßig. Über die Disziplinen werden die statischen Konzepte Rollen, Artefakte und Aktivitäten auch auf die Phasen aufgeteilt. Durch die Aktivitäten in den Phasen lassen sich auch Workflows zu jeder Phase aufstellen.

Für den RUP existieren sechs so genannte Best Practises, die auf jahrelangen Erfahrungen aus zahlreichen Projekten basieren.131 Durch diese Faustregeln werden die Qualität und die Vorhersagbarkeit in Projekten, die den RUP als Prozessmodell verwenden, erhöht.132

3.4 Schwachstellen im RUP

Der RUP als bewährtes Vorgehensmodell, basiert auf den oben erwähnten Best Practises, die aus praktischen Erfahrungen hervorgegangen sind. Durch diese wird versucht, möglichst viele praxisorientierte Ansätze im RUP zu beachten. Dennoch können durch die Beschaffenheit eines Projektes Situationen auftreten, die durch die Theorie des RUP nicht abgedeckt werden können. Vor der Entwicklung des SUP können bereits RUP-Schwachstellen identifiziert werden. Inwieweit diese SUP relevant sind, geht aus der SUP-Entwicklung im Kapitel 4 hervor. Es folgt eine Übersicht über bereits identifizierte Schwachstellen:

- Im RUP werden Aktivitäten, die im weiteren Sinne mit Verträgen zu tun haben, nicht beachtet. Hier drunter fällt zum Beispiel das Führen von Verhandlungen mit den externen Projektbeteiligten.
- Nach der Durchführung des Softwareentwicklungsprojektes ist die Prozessbetrachtung im RUP abgeschlossen. Die sich anschließenden Aktivitäten wie die Durchführung und Unterstützung des Betriebes der erstellten Software sind im RUP gar nicht beschrieben.
- Die Vorgehensweise bei Problematiken mit Sublieferanten wird nicht beschrieben. Das folgende Beispiel soll eine solche Problematik verdeutlichen: Wird entschieden, dass ein Lieferant B eine bestimmte Aufgabe von einem Lieferanten A übernehmen soll, will A die Kosten nur um einen geringen Betrag senken. B hingegen möchte sich die Aufgabe teuer bezahlen lassen. Es handelt sich hierbei also um ein Bewertungsproblem.

Weitere Schwachstellen die erst im Verlauf der Prozessmodellentwicklung im Hauptteil in Kapitel 4 identifiziert werden, werden auch dort erläutert und zu lösen versucht.

4. Der SUP - ein Prozessmodell für die SI

Während der RUP ein Prozessmodell für die strukturierte Entwicklung von Software ist, soll der SUP den Prozess für den gesamten Lebenszyklus einer Systemlandschaft darstellen. Mit seiner Hilfe soll ein System Integrator alle Aufgaben vom Schaffen einer Systemlandschaft bis zu ihrer Stilllegung abwickeln. Dabei sind die Tätigkeiten, Rollen, Artefakte sowie ein grober Zeitablauf vorgegeben. Der SUP baut strukturell auf dem RUP auf. Die in Kapitel 3 beschriebenen Konzepte werden auch im SUP verwendet, wobei sie aber inhaltlich für die System Integration angepasst bzw. erweitert sein können.

4.1 Die dynamische Prozessstruktur im SUP

Im Folgenden werden die Phasen, deren Meilensteine und die Iterationen für den SUP hergeleitet und beschrieben. Für jede Phase werden die Fragen „Was soll in dieser Phase geschehen“ und „Was sind die Ziele dieser Phase“ beantwortet. Des Weiteren werden die die Phasen abschließenden Meilensteine bestimmt und erläutert. Auf die Artefakte, Aktivitäten und Rollen die in jeder Phase durch die Disziplinen vorhanden sind, wird nicht eingegangen. Die Beschreibung der SUP-Iterationen, die auf die der Phasen folgt, soll die allgemeine Struktur aller SUP-Iterationen darstellen.

4.1.1 Die Phasen im SUP

Viele Prozessmodelle, wie auch der RUP, beginnen mit einer Inception-Phase133. Dabei wird die Ausgangssituation vor Beginn des Prozesses so charakterisiert, dass nur einfache Informationen bekannt sind, die in den Prozessphasen präzisiert und umgesetzt werden.134 In der Praxis hingegen steht vor dem Projektbeginn in der Regel eine Angebotsphase. In dieser werden Anfragen bzgl. eines Projektes des potentiellen Auftraggebers beantwortet. Der SUP geht darauf ein und stellt der Inception- die Proposal-Phase voran.

[...]


1 Vgl. Essigkrug, A., Mey, T. (2003), S. 3.

2 Grässle, P., Baumann, H., Baumann, P. (2004), S. 223.

3 Zuser, W., Grechenig, T., Köhle, M. (2004), S. 317.

4 Braude, E. J. (2001), S. 433.

5 Die Umwelt eines Systems kann durch weitere Systeme dargestellt werden, aber auch durch Menschen, die mit dem System arbeiten.

6 Vgl. Klußmann, N. (2000), S. 724.

7 Vgl. Klußmann, N. (2000), S. 724.

8 Vgl. Schmidt, M. E. C. (2000), S. 112.

9 Vgl. Grässle, P., Baumann, H., Baumann, P. (2004), S. 224.

10 Schulze, H. H. (2003), S. 797.

11 Vgl. o.A. (1999), S. 1959.

12 o.A. (2004), S. 1524.

13 Vgl. Klußmann, N. (2000), S. 725: Mit Bereich ist hier eine Abteilung, ein großes ITUnternehmen, eine Unternehmensberatung o.ä. gemeint.

14 Vgl. Koreimann, D. S. (2002), S. 13: Ein Vorhaben wird Projekt genannt, wenn u.a. die folgenden Punkte auf es zutreffen: Es handelt sich um ein zeitlich und finanziell begrenztes Vorhaben, das einmalig ist, und nicht zum Routinerepertoir gehört. Für dieses Vorhaben muss es eine genaue Zielvorgabe geben.

15 Vgl. Klußmann, N. (2000), S. 725.

16 Vgl. Disterer, G., Fels, F., Hausotter, A. (2004), S. 688.

17 Vgl. Abts, D., Mülder, W. (2002), S. 162.

18 Die weiteren Ausführungen beziehen sich auf ein System, wobei dieses beispielhaft für n- Systeme steht

19 Dies ist sehr theoretisch betrachtet, da von optimalen Bedingungen ausgegangen wird. In der Praxis ist dieser Ansatz aber aus unterschiedlichsten Gründen selten möglich.

20 Vgl. Keller, W. (2002), S. 5.

21 Vgl. Keller, W. (2002), S. 5 f.

22 Vgl. Klußmann, N. (2000), S. 486: Als Middleware wird grob ausgedrückt Software definiert, die Informationen zwischen unterschiedlichen Systemen austauscht und diesen Austausch koordiniert.

23 Vgl. Keller, W. (2002), S. 16 f.

24 Vgl. Steinmetz, R. Mühlhäuser, M. (2002), S. 402: Das Routing dient dazu, dass der günstigste Weg einer Information die vom Sender zum Empfänger gelangen soll erkannt wird. Das Routing wird auch Wegeleitverfahren genannt.

25 Vgl. auch o.A. (2003), S. 562: Unter Mapping wird das Abbilden von etwas auf etwas anderes verstanden. Ein Beispiel dafür ist das Abbilden einer virtuellen Adresse auf eine physikalische Adresse in einem Haputspeicher.

26 Vgl. Englbrecht, M., Wegelin, M. (2005), S. 325.

27 Vgl. Disterer, G., Fels, F., Hausotter, A. (2004), S. 689.

28 Vgl. Schulze, H. H. (2003), S. 744.

29 Vgl. Kruchten, P. (1999), S. 168.

30 Vgl. auch Mayr, H. (2001), S. 45.

31 Vgl. Mayr, H. (2001), S. 32.

32 Vgl. o.A. (2004), S. 1222: Ein Geschäftsprozess ist eine Folge von Aktivitäten die der Wertschöpfung in einem Unternehmen dienen. Sie können eine oder mehrere Eingaben sowie eine Nutzen stiftende Ausgabe besitzen.

33 Vgl. auch Ambler, S. W., Constantine L. L. (2000a), S. 12.

34 Vgl. Rautenstrauch, C., Schulze, T. (2003), S. 225: Ein Modell ist ein Abbild der Realität.

35 Vgl. Köster, K. (2005), S. 52.

36 Vgl. Köster, K. (2005), S. 52.

37 Vgl. Kruchten, P. (1999), S. 155.

38 Vgl. Klußmann, N. (2000), S. 163.

39 Vgl. Schmidt, M. E. C. (2000), S. 103.

40 Vgl. Braude, E. J. (2001), S. 437.

41 Vgl. auch o.A. (2003), S. 580.

42 Vgl. Vogel-Heuser, B. (2003), S. 40.

43 Vgl. Meier, J. (2000), S. 16.

44 Vgl. Sommerville, I. (2004), S. 33.

45 Vgl. Sommerville, I. (2004), S. 33.

46 Ein Teil kann eine Abteilung o.ä. sein.

47 Vgl. Mayr, H. (2001), S. 27.

48 Vgl. Saleck, T. (2003), S. 166.

49 Vgl. Saleck, T. (2003), S. 99.

50 Vgl. Keßler, H., Winkelhofer, G. (2004), S. 76.

51 Vgl. Keßler, H., Winkelhofer, G. (2004), S. 76.

52 o.A. (2004), S. 1189.

53 Vgl. Rittershofer, W. (2002), S. 926.

54 Vgl. Versteegen, G., Salomon K., Heinold, R. (2001), S. 133.

55 Vgl. auch Essigkrug A., Mey T. (2003), S. 22.

56 Vgl. auch Kruchten, P. (1999), S. 18.

57 Mit Beginn des Jahres 2003 hat IBM den eigentlichen RUP-Herstellter Rational Software übernommen.

58 Vgl. Essigkrug A., Mey T. (2003), S. 4.

59 Vgl. Essigkrug A., Mey T. (2003), S. 4.

60 Vgl. Kruchten, P. (1999), S. 17ff.

61 Vgl. Bergström, S., Råberg, L. (2004), S. 29.

62 Vgl. Bergström, S., Råberg, L. (2004), S. 36.

63 Rational Software wurde im ersten Quartal 2003 von IBM übernommen.

64 Vgl. Zuser, W., Grechenig, T. Köhle, M. (2004), S. 79; Versteegen, G., Salomon, K., Heinold, R. (2001), S. 95: Diese drei werden in der Literatur auch die drei Amigos genannt.

65 „abgeleitet“ ist hier im Sinne der Objektorientierung zu verstehen.

66 Vgl. Zuser, W., Grechenig, T., Köhle, M. (2004), S. 80.

67 Vgl. Arlow, J., Neustadt, I. (2002), S. 27.

68 Vgl. Versteegen, G. (2000), S. 46.

69 Vgl. auch Erler, T. (2000), S. 39 f.

70 Vgl. Erler, T. (2000), S. 40.

71 Vgl. Arlow, J., Neustadt, I. (2002), S. 6.

72 Kruchten, P. (1999), S. 28.

73 Vgl. Kroll, P., Kruchten, P. (2003), S. 9.

74 Vgl. Kruchten, P. (1999), S. 22 f.

75 Vgl. Kroll, P., Kruchten, P. (2003), S. 9.

76 Vgl. Kruchten, P. (1999), S. 51.

77 Vgl. Essigkrug, A., Mey, T. (2003), S. 14.

78 Vgl. auch Royce, W. (1998), S. 76 f.

79 Vgl. Essigkrug, A., Mey, T. (2003), S. 14.

80 Vgl. Kruchten, P. (1999), S. 60.

81 Vgl. Kruchten, P. (1999), S. 60.

82 Vgl. Koreimann, D. S. (2002), S. 31.

83 Vgl. Bergström, S., Råberg, L. (2004), S. 27.

84 Vgl. Vogel-Heuser, B. (2003), S. 23 f.

85 Vgl. Zöller-Greer, P. (2002), S. 14.

86 Mit Disziplinen sind die RUP-Disziplinen gemeint, die nachfolgend in der Beschreibung der statischen Struktur erläutert werden.

87 Vgl. auch Essigkrug Essigkrug, A., Mey, T. (2003), S. 8.

88 Vgl. Kroll, P., Kruchten, P. (2003), S. 6.

89 Vgl. Kroll, P., Kruchten, P. (2003), S. 232 f.

90 Vgl. Jacobson, I., Booch, G., Rumbaugh, J. (1999), S. 101.

91 Vgl. Jacobson, I., Booch, G., Rumbaugh, J. (1999), S. 101.

92 Vgl. Versteegen, G. (2000), S. 283: Ein Release ist ein Bestandteil des Produktes was an den Auftraggeber ausgeliefert wird.

93 Vgl. Scott, K. (2002), S. 7.

94 Vgl. Zuser, W., Grechenig, T., Köhle, M. (2004), S. 81.

95 Vgl. Bergström, S., Råberg, L. (2004), S. 37.

96 Vgl. Bergström, S., Råberg, L. (2004), S. 37.

97 Vgl. Bergström, S., Råberg, L. (2004), S. 37.

98 Vgl. Scott, K. (2002), S. 9.

99 Vgl. auch Sommerville, I. (2004), S. 71.

100 Vgl. Kruchten, P. (1999), S. 7 f.

101 Vgl. Kruchten, P. (1999), S. 8.

102 Vgl. Versteegen, G. (2000), S. 53.

103 Vgl. Versteegen, G., Weischedel, G. (2003), S. 43: In älteren RUP-Versionen bzw. Literatur wird statt von Rollen von Workern gesprochen.

104 Vgl. Essigkrug, A., Mey, T. (2003), S. 22.

105 Vgl. auch Versteegen, G., Weischedel, G. (2003), S. 41: In älteren RUP-Versionen bzw. Literatur wird statt von Disziplinen von Workflows gesprochen. Der Begriff Workflow umfasste dabei neben den heutigen Disziplinen noch weitere Komponenten.

106 Vgl. Kroll, P., Kruchten, P. (2003), S. 14 f.

107 Vgl. Versteegen, G. (2002), S. 130.

108 Vgl. Jacobson, I., Booch, G., Rumbaugh, J. (1999), S. 21.

109 Vgl. Kruchten, P. (1999), S. 40.

110 Vgl. auch Winkler, P. (2004), S. 758: Als Quellcode wird ein Programm bezeichnet, das in einer höheren Programmiersprache geschrieben, und noch nicht in ein ausführbares Programm übersetzt wurde.

111 Vgl. auch Winkler, P. (2004), S. 181: Eine ausführbare Datei ist der übersetzte Quellcode. Für einen Außenstehenden ist nach der Übersetzung nicht mehr zu erkennen, wie der eigentliche Quellcode aussieht. Aus diesem Grund erhält ein Auftraggeber meistens nur die ausführbaren Dateien.

112 Vgl. Kruchten, P. (1999), S. 40.

113 Vgl. Kruchten, P. (1999), S. 40.

114 Vgl. Kruchten, P. (1999), S. 42 f.

115 Vgl. Essigkrug, A., Mey, T. (2003), S. 22.

116 Vgl. Essigkrug, A., Mey, T. (2003), S. 22.

117 Vgl. Kroll, P., Kruchten, P. (2003), S. 14.

118 Vgl. Essigkrug, A., Mey, T. (2003), S. 22.

119 Vgl. Kruchten, P. (1999), S. 39.

120 Vgl. Kruchten, P. (1999), S. 39.

121 Vgl. auch Zuser, W., Grechenig, T., Köhle, M. (2004), S. 91.

122 Vgl. Kruchten, P. (1999), S. 45.

123 Essigkrug, A., Mey, T. (2003), S. 23.

124 Vgl. Kroll, P., Kruchten, P. (2003), S. 16.

125 Vgl. Kroll, P., Kruchten, P. (2003), S. 16.

126 Vgl. Essigkrug, A., Mey, T. (2003), S. 23.

127 Vgl. Essigkrug, A., Mey, T. (2003), S. 23.

128 Vgl. Essigkrug, A., Mey, T. (2003), S. 23.

129 Vgl. Kruchten, P. (1999), S. 48.

130 Kruchten, P. (1999), S. 48.

131 Vgl. Ambler, S. W., Nolbone, J., Vizdos, M.J. (2005), S. 25.

132 Vgl. auch Essigkrug, A., Mey, T. (2003), S. 7.

133 Vgl. Essigkrug, A., Mey, T. (2003), S. 15: Inception-Phase wird im deutschen mit Vorbereitungsphase übersetzt.

134 Vgl. auch Jacobson, I., Booch, G., Rumbaugh, J. (1999), S. 341.

Ende der Leseprobe aus 115 Seiten

Details

Titel
System Integration Unified Process - Eine Modifikation des Rational Unified Process für die System Integration
Hochschule
FOM Essen, Hochschule für Oekonomie & Management gemeinnützige GmbH, Hochschulleitung Essen früher Fachhochschule
Note
2,0
Autor
Jahr
2005
Seiten
115
Katalognummer
V56348
ISBN (eBook)
9783638510479
Dateigröße
1431 KB
Sprache
Deutsch
Schlagworte
System, Integration, Unified, Process, Eine, Modifikation, Rational
Arbeit zitieren
Surya Hengel (Autor), 2005, System Integration Unified Process - Eine Modifikation des Rational Unified Process für die System Integration, München, GRIN Verlag, https://www.grin.com/document/56348

Kommentare

  • Noch keine Kommentare.
Im eBook lesen
Titel: System Integration Unified Process - Eine Modifikation des Rational Unified Process für die System Integration


Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden