Inhaltsverzeichnis  I

Inhaltsverzeichnis

Inhaltsverzeichnis.   I

  Abkürzungsverzeichnis.  III

  Abbildungsverzeichnis.  V

  Tabellenverzeichnis.  VI

1.  Die Einführung - ein Kurzüberblick.  1

1.1  Motivation für diese Diplomarbeit.  1

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

1.3  Kurzüberblick über den weiteren Verlauf der Diplomarbeit  3

2.  Der SI Rahmen - eine Begriffsabgrenzung  4

2.1  Begriffsdefinition  4

2.2  Integrationsreichweite.  7

2.3  Integrationsarten.  7

2.4  Enterprise Application Integration  8

2.5  Aufgabengebiet für einen System Integrator.  9

2.6  Schnittstellen zu anderen Bereichen eines Projektes.  12

3.  Der RUP - eine abstrakte Modellbeschreibung  14

3.1  Die Entstehungsgeschichte  15

3.2  Der RUP und die Unified Modelling Language.  15

3.3  Die Struktur des RUP  16

3.3.1  Die dynamische Struktur  17

3.3.2  Die statische Struktur.  19

3.3.3  Die Gesamtprozessstruktur.  22

3.4  Schwachstellen im RUP  23

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

4.1  Die dynamische Prozessstruktur im SUP.  24

4.1.1  Die Phasen im SUP  24

4.1.1.1  Phase 1: Proposal.  26

4.1.1.2  Phase 2: Inception  28

4.1.1.3  Phase 3: Elaboration.  30

4.1.1.4  Phase 4: Construction  31

4.1.1.5  Phase 5: Transition  32

4  1 1 6 Phase 6: Production  33

  Inhaltsverzeichnis  II

4.1.1.7  Phase 7: Retirement  35

4.1.2  Die Iterationen im SUP.  36

4.2  Die statische Prozessstruktur im SUP  36

4.2.1  Business Modelling  37

4.2.2  Requirements  41

4.2.3  Analysis & Design  44

4.2.4  Implementation  47

4.2.5  Test.  49

4.2.6  Deployment.  52

4.2.7  Configuration & Change Management  54

4.2.8  Project Management.  57

4.2.9  Environment.  62

4.2.10  Operations & Support  63

4.3  Die Gesamtprozessstruktur  65

5.  Das Beispiel - eine Anwendung des SUP  67

5.1  Die Ausgangssituation  67

5.2  Die Phasen des Beispiels  68

6.  Das Fazit - eine Ergebnisanalyse  78

6.1  Kurzüberblick über das Modell.  78

6.2  Ergebnisse der RUP-Modifikation.  78

6.3  Fortführende Aufgaben bzgl. der SUP-Entwicklung  79

  Literaturverzeichnis.  80

  Der Anhang  96

Anhang 1:  Die Rollen im SUP.  96

Anhang 2:  Die Artefakte im SUP  100

Abkürzungsverzeichnis III

Abkürzungsverzeichnis

Abkürzung Bedeutung

AG Aktiengesellschaft

bzgl. bezüglich bzw. beziehungsweise

ca. circa CRM Customer Relation Management

EAI Enterprise Application Integration EUP Enterprise Unified Process evtl. eventuell

f. folgende ff. fortfolgende

ggf. gegebenenfalls GmbH Gesellschaft mit beschränkter Haftung GP Geschäftsprozess GU Generalunternehmer

Hrsg. Herausgeber

IOC Initial Operational Capability IT Informationstechnologie

LCA Life-Cycle Architecture LCO Life-Cycle Objective

o.A. ohne Angabe o.ä. oder ähnliches OO Objektorientierung

Abkürzungsverzeichnis IV

PD Project Decision

RfI Request for Information RfP Request for Proposal RUP Rational Unified Process

S. Seite SI System Integration SLP System Landscape Production Stop SLR System Landscape Release SR System Landscape Retirement SUP System Integration Unified Process

u.a. unter anderem UML Unified Modelling Language UP Unified Process usw. und so weiter

vgl. vergleiche

  Abbildungsverzeichnis  

  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 VI   

  Tabellenverzeichnis  

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

Tabelle 2:  Die Rollen im SUP.  96

Tabelle 3:  Die Artefakte im SUP  100

Die Einführung - ein Kurzüberblick 1

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

Die Einführung - ein Kurzüberblick 2

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

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

Die Einführung - ein Kurzüberblick 3

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.

Der SI Rahmen - eine Begriffsabgrenzung 4

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) System Integration ist: „Die technische Zusammenführung von mehreren Komponenten oder Subsystemen zu einem gesamten System“ ³ . (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” ⁴ .

Der Begriff setzt sich aus zwei Teilen zusammen, System und Integration. Ein System ist ein unterteiltes Ganzes, das von seiner Umwelt ⁵ durch klare Grenzen, den so genannten Systemgrenzen, getrennt ist. 6

Systeme bestehen aus Subsystemen die ihrerseits wiederum Systeme sein können. ⁷ Durch die Verknüpfung der Subsysteme dient ein System einem ganz bestimmten Zweck. ⁸ 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. ⁹ Eine Schnittstelle verbindet mindestens zwei (Sub-) Systeme so, dass

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

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

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

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

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

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

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

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

Der SI Rahmen - eine Begriffsabgrenzung 5

verschiedene „Merkmale der Systeme bei der Kommunikation angeglichen werden“ ¹⁰ . Der Systemaufbau wird in Abbildung 1 grafisch verdeutlicht.

Abbildung 1: Aufbau eines Systems

Integration stammt von dem lateinischen Wort integratio ab, was die Wiederherstellung eines Ganzen bedeutet. ¹¹ Auch die „Herstellung einer Einheit oder Eingliederung in ein größeres Ganzes“ ¹² 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.

¹⁰ Schulze, H. H. (2003), S. 797.

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

¹² o.A. (2004), S. 1524.

Der SI Rahmen - eine Begriffsabgrenzung 6

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 Bereich ¹³ , der in einem IT-Projekt ¹⁴ dafür zuständig ist, dass alle benötigten Soft- und Hardwaresysteme zu einer umfangreichen, einheitlichen Gesamtlösung zusammengeführt werden. ¹⁵ 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. ¹⁶ Aber die zunehmende Automatisierung von Unternehmensprozessen verlangt einen immer höheren Grad der Integration der einzelnen Systeme.

¹³ Vgl. Klußmann, N. (2000), S. 725: Mit Bereich ist hier eine Abteilung, ein großes IT-Unternehmen, eine Unternehmensberatung o.ä. gemeint.

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

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

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

Der SI Rahmen - eine Begriffsabgrenzung 7

2.2 Integrationsreichweite

Bei der System Integration kann nach der Reichweite der Integration unterschieden werden. ¹⁷ 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 mehrere ¹⁸ Systeme in eine existierende Systemlandschaft integriert werden.

Abbildung 3: Integration in eine existierende Systemlandschaft

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

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

Der SI Rahmen - eine Begriffsabgrenzung 8

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. ¹⁹ 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 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. ²⁰ Diese werden auch Integrationsserver genannt. ²¹ Grundsätzlich agieren Integrationsserver im EAI-Bereich als Middleware 22

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

²⁰ Vgl. Keller, W. (2002), S. 5.

²¹ Vgl. Keller, W. (2002), S. 5 f.

Der SI Rahmen - eine Begriffsabgrenzung 9

zwischen Softwaresystemen die miteinander verknüpft werden. ²³ Sie sind zuständig für das Routing ²⁴ und Mapping ²⁵ der Informationen, die zwischen den integrierten Systemen ausgetauscht werden. ²⁶ 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. ²⁸ Außerdem erstellt er einen Integrationsplan der beschreibt, in welcher Reihenfolge welche Systeme angepasst und integriert werden. ²⁹ Neben diesen Tätigkeiten gehört das Managen von Budget, Mitarbeitern und Zeitplänen ebenso zum Projektmanagement. 30

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

²³ Vgl. Keller, W. (2002), S. 16 f.

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

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

²⁶ Vgl. Englbrecht, M., Wegelin, M. (2005), S. 325.

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

²⁸ Vgl. Schulze, H. H. (2003), S. 744.

²⁹ Vgl. Kruchten, P. (1999), S. 168.

³⁰ Vgl. auch Mayr, H. (2001), S. 45.

Der SI Rahmen - eine Begriffsabgrenzung 10

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. ³¹ 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äftsprozesse ³² (GP) des Auftraggebers, die im Zusammenhang mit der Integration stehen, zu identifizieren und zu analysieren. ³³ Aus den geschäftsprozesstypischen Sachverhalten eines Unternehmens können bei der Geschäftsprozessmodellierung Modelle ³⁴ entwickelt werden. ³⁵ 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. ³⁷ 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. ³⁸ Diese Anforderungen beziehen sich oft auf die Schnittstellen. Unter die Systemanpassungen fallen aber auch

³¹ Vgl. Mayr, H. (2001), S. 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.

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

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

³⁵ Vgl. Köster, K. (2005), S. 52.

³⁶ Vgl. Köster, K. (2005), S. 52.

³⁷ Vgl. Kruchten, P. (1999), S. 155.

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

Der SI Rahmen - eine Begriffsabgrenzung 11

Ä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. ³⁹ 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. ⁴¹ 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. ⁴² Ein System Integrator kann zwischen zwei möglichen Einführungsstrategien wählen. ⁴³ Er kann zum einen den so genannten Big Bang Ansatz wählen, bei dem alle zu integrierenden Systeme zum gleichen Zeitpunkt integriert werden. ⁴⁴ 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 4 näher erläutert und abgegrenzt.

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

⁴⁰ Vgl. Braude, E. J. (2001), S. 437.

⁴¹ Vgl. auch o.A. (2003), S. 580.

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

⁴³ Vgl. Meier, J. (2000), S. 16.

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

⁴⁵ Vgl. Sommerville, I. (2004), S. 33.

Der SI Rahmen - eine Begriffsabgrenzung 12

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 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 Teil ⁴⁶ eines Unternehmens darstellt, kann der Auftraggeber unternehmensintern, ansonsten auch -extern sein. ⁴⁷ 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. ⁴⁸ Sie bekommen häufig Aufgaben zugetragen, die nicht in das Tätigkeitsfeld eines System Integrators

⁴⁶ Ein Teil kann eine Abteilung o.ä. sein.

⁴⁷ Vgl. Mayr, H. (2001), S. 27.

⁴⁸ Vgl. Saleck, T. (2003), S. 166.

Der SI Rahmen - eine Begriffsabgrenzung 13

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. ⁵⁰ 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“ ⁵² . Innerhalb eines Projektes obliegt dem Generalunternehmer die Gesamtverantwortung. Er agiert als Schnittstelle zwischen dem Auftraggeber und allen weiteren Projektbeteiligten. ⁵³ 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.

⁴⁹ Vgl. Saleck, T. (2003), S. 99.

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

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

⁵² o.A. (2004), S. 1189.

⁵³ Vgl. Rittershofer, W. (2002), S. 926.

Der RUP - eine abstrakte Modellbeschreibung 14

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. ⁵⁴ In der RUP-Beschreibung 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. ⁵⁶ Von IBM ⁵⁷ wird der RUP regelmäßig weiter entwickelt. ⁵⁸ Er durchläuft dabei halbjährliche Releasezyklen. ⁵⁹ 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. ⁶¹ 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

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

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

⁵⁶ Vgl. auch Kruchten, P. (1999), S. 18.

⁵⁷ Mit Beginn des Jahres 2003 hat IBM den eigentlichen RUP-Herstellter Rational Software

übernommen.

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

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

⁶⁰ Vgl. Kruchten, P. (1999), S. 17ff.

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

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

Der RUP - eine abstrakte Modellbeschreibung 15

3.1 Die Entstehungsgeschichte

Der RUP wurde im Jahre 1999 erstmals veröffentlicht. Verantwortlich für seine Entstehung ist das Unternehmen Rational Software ⁶³ mit starken Einflüssen durch die drei Mitarbeiter Grady Booch, Jim Rumbaugh und Ivar Jacobson. ⁶⁴ Wie auch aus Abbildung 6 ersichtlich ist, ist der RUP vom Unified Process (UP) abgeleitet ⁶⁵ . ⁶⁶ 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 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 Jacobsonsind auch hauptverantwortlich für die Modellierungssprache Unified Modelling Language (UML). ⁶⁹ Die UML wurde 1997 von der Object Management Group als offener Industriestandard akzeptiert. ⁷⁰ Sie gilt seitdem als unangefochten bei den Modellierungssprachen für die Objektorientierung (OO). ⁷¹ Diese grafische Sprache stellt dem RUP das Grundgerüst für die Modellierung zur Verfügung. Er „beschreibt,

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

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

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

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

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

⁶⁸ Vgl. Versteegen, G. (2000), S. 46.

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

⁷⁰ Vgl. Erler, T. (2000), S. 40.

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

Der RUP - eine abstrakte Modellbeschreibung 16

welches Modell benötigt wird, warum es benötigt wird und wie es zu erstellen ist“ ⁷² . 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 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

⁷² Kruchten, P. (1999), S. 28.

⁷³ Vgl. Kroll, P., Kruchten, P. (2003), S. 9.