Zusammenfassung

In Zusammenarbeit mit der Firma Splendid Internet GmbH & Co. KG wurde auf Basis des Rational Unified Process ein abgeleiteter Softwareentwicklungsprozess entworfen, der zur Einf¨ uhrung im Unternehmen eine erste Konkretisierungsstufe darstellt. Das vorliegende Dokument beschreibt die involvierten Konzepte und Techniken des Unified Process und zeigt, mit welchen Mitteln bei der Einf¨ uhrung und Anpassung des Prozesses vorgegangen wurde.

iii

Inhaltsverzeichnis

Zusammenfassung   iii

Inhaltsverzeichnis   v

1  Einleitung  3

1.1  Motivation  3

1.1.1  Bedeutung von Software  3

1.1.2  Probleme der Softwareentwicklung  4

1.1.3  Softwareentwicklungsprozesse  6

1.2  Aufgabe  7

1.2.1  Rahmen  7

1.2.2  Ziele  8

1.3  Aufbau  9

2  Der Unified Process  10

2.1   

Uberblick   10

2.1.1  Historie  10

2.1.2  Der Unified Process als Produkt  12

2.1.3  Der Unified Process in K urze  14

2.2  Prozesselemente  15

v

2.2.1  Rollen (wer)  15

2.2.2  Aktivit aten (wie)  16

2.2.3  Artefakte (was)  18

2.2.4  Workflows (wann)  19

2.2.5  Weitere Prozesselemente  20

2.3  Grundkonzepte  22

2.3.1  anwendungsfallgetrieben  22

2.3.2  architekturzentriert  27

2.3.3  iterativ und inkrementell  33

2.4  Phasen  37

2.4.1  Inception Phase  37

2.4.2  Elaboration Phase  37

2.4.3  Construction Phase  38

2.4.4  Transistion Phase  38

2.5  Disziplinen  38

2.5.1  Business Modeling  39

2.5.2  Requirements  40

2.5.3  Analysis and Design  40

2.5.4  Implementation  41

2.5.5  Test  42

2.5.6  Deployment  43

2.5.7  Configuration and Change Management  43

2.5.8  Project Management  44

2.5.9  Environment  45

vi

3  Die Einf uhrung  46

3.1  Vor uberlegungen  46

3.1.1  Inhaltliche Aspekte  46

3.1.2  Planerische Aspekte  47

3.1.3  Menschliche Aspekte  48

3.2  Schlussfolgerungen  49

3.3  Unternehmensanalyse  50

3.3.1  Analysefelder  51

3.3.2  Fragebogenaktion  55

3.3.3  Ergebnisse  56

3.4  Schulungen  57

3.5  Diskussionen  57

4  Die Anpassung  59

4.1  Der Development Case  59

4.1.1  Einordnung  60

4.1.2  Konfigurationsm oglichkeiten  60

4.1.3  Bezugsebene  62

4.2  Das Project Web Template  63

4.2.1  Probleme  63

4.2.2  L osungsansatz  64

4.2.3  Aufbau  64

4.2.4  Development Case  66

4.2.5  Artefakte  69

4.3  Die Disziplinen  69

4.3.1  Business Modeling  70

vii

4.3.2  Requirements  74

4.3.3  Analysis Design  81

4.3.4  Implementation  86

4.3.5  Test  90

4.3.6  Deployment  93

4.3.7  Configuration Change Management  96

4.3.8  Project Management  100

4.3.9  Environment  108

5  Ausblick  109

Literatur   111

Danksagung   115

Erkl  arung  117

viii

Kapitel 1

Einleitung

1.1 Motivation

1.1.1 Bedeutung von Software

Nach einer Studie im Auftrag des Bundesministeriums f¨ ur Bildung und Forschung [GFF00] ist der Softwaremarkt heute schon als einer der Schl¨ usselm¨ arkte in Deutschland zu sehen; die entwickelte Software dient oft als wettbewerbsentscheidendes Instrument in den sekund¨ aren Softwarebranchen ¹ . Nach den im Oktober 2001 vorgelegten Konjunkturdaten prognostiziert der Bundesverband In-formationswirtschaft, Telekommunikation und neue Medien e.V. (BITKOM) f¨ ur die Branchen Informationstechnik und Telekommunikation (ITK) in Deutschland ein Wachstum um 4,6% auf 254 Mrd. DM [Bun01]. In vielen Sekund¨ arbereichen ist bereits der gesamte Umsatz von Software abh¨ angig. Nur beispielhaft sei hier die Automobilindustrie erw¨ ahnt. Abgesehen von der betrieblichen Produktions-und Personalplanung k¨ onnten die komplexen Steuerfunktionen der Industrieroboter ohne Software nicht realisiert werden. Die Fahrzeuge selbst enthalten heutzutage schon weit ¨ uber tausend elektronische Bauteile, die durch Programmlo- ¹ DieUnternehmen der prim¨ aren Softwarebranche wie DV-Dienstleister und Hersteller von Datenverarbeitungsger¨ aten und -einrichtungen finden eine Abgrenzung zu den Anwendungsbranchen, die als sekund¨ are Softwarebranchen bezeichnet werden. Dazu z¨ ahlen Unternehmen aus den Bereichen Maschinenbau, Elektrotechnik, Fahrzeugbau, Telekommunikation und Finanzdienstleistungen. Software entsteht somit als eigenst¨ andiges Produkt (Prim¨ arbranche) oder eingebettet in Produkte oder Dienstleistungen (Sekund¨ arbranche).

3

4 KAPITEL 1. EINLEITUNG

gik verschiedenste Regelfunktionalit¨ aten ¨ ubernehmen. Als einer der anerkanntesten K¨ opfe im Segment der methodischen Softwareentwicklung formulierte Grady Booch in der Fachpresse:

Ohne Software w¨ urde heutzutage kein modernes Unternehmen mehr

”

existieren k¨ onnen, keine Regierung der Welt an der Macht sein k¨ onnen und die Kommunikation innerhalb der Gesellschaft w¨ urde nicht mehr funktionieren. Software erm¨ oglicht uns eine Bereitstellung von Informationen, die fr¨ uher kaum denkbar gewesen w¨ are. Global betrachtet, hat Software das Wirtschaftswachstum herbeigef¨ uhrt. Vom menschlichen Gesichtspunkt betrachtet, haben Softwareprodukte Kranken zur Gesundheit verholfen, Stummen zur Sprache und Unbeweglichen zur Mobilit¨ at. Unter diesen Gesichtspunkten hat sich Software zu einem unverzichtbaren Bestandteil der modernen Welt entwickelt.“ [Boo98] 2

1.1.2 Probleme der Softwareentwicklung

Diese Abh¨ angigkeit f¨ uhrt zu immer gr¨ oßeren Anforderungen an die Komplexit¨ at der Softwaresysteme. Dies wird beeinflusst durch die immer leistungsf¨ ahigeren Hardwaresysteme und den zunehmenden Austausch jeglicher Art von Information, nicht zuletzt motiviert durch das Internet, durch das der schnelle weltweite Transfer von einfachen Textseiten bis hin zu multimedialer Video¨ ubertragung m¨ oglich geworden ist. Die Anwender der Systeme identifizieren bei jedem Release weitere Verbesserungsm¨ oglichkeiten, so dass die Produkte immer mehr an die Bed¨ urfnisse und W¨ unsche angepasst werden. Die Erwartungen an Qualit¨ at und Funktionsumfang nehmen zu und die Stellung des Softwaresystems in seinem Umfeld wird immer signifikanter. Die Industrie fordert von den Softwareentwicklern qualitativ hochwertige Software, um sich am Markt behaupten zu k¨ onnen. Laut der bereits zitierten Studie [GFF00] werden in diesem Zusammenhang Zuverl¨ assigkeit und Funktionalit¨ at als die wichtigsten wettbewerbsbestimmenden Eigenschaften betrachtet. Weiterhin stehen f¨ ur die Unternehmen Performanz, Skalierbarkeit, Benutzerfreundlichkeit und Wiederverwendbarkeit auf der Liste der entscheidenden nicht-funktionalen Anforderungen. Anforderungen, die der

² ¨ Ubersetzung ins Deutsche von Cornelia Versteegen aus [Kru99]

1.1. MOTIVATION 5

Softwareentwickler umsetzen muss. Die Erwartungen an ihn steigen kontinuierlich. Auch bei dem Versuch, alte Systeme ³ auf moderne Technologien umzustellen, sind die Softwarefirmen mit einer Reihe von technischen und organisatorischen Problemen konfrontiert, die es zu l¨ osen gilt.

Gleichzeitig sollen zu erstellende Softwaresysteme in immer k¨ urzeren Entwicklungszeiten fertiggestellt werden; der sog. Time-to-market-Faktor wird immer entscheidender. Besonders im schnelllebigen Internetgesch¨ aft spielt die Fertigungsdauer eine wichtige Rolle. Man spricht hier von Technologiehalbwertszeiten von nur drei bis f¨ unf Jahren. Ein Produkt zum richtigen Zeitpunkt auf den Markt zu bringen, kann dabei maßgeblich den Erfolg eines Unternehmens entscheiden. Die Zahl der Insolvenzverfahren vieler Start-Up-Firmen der New Economy untermauert diese Behauptung.

Fazit: Die Branche der Softwareentwickler sieht sich immer komplexeren Aufgaben gegen¨ ubergestellt, die in immer k¨ urzeren Zeitabschnitten zu l¨ osen sind.

Das Know-how der Softwarefirmen kann diesen wachsenden Anforderungen nur schwer folgen. Die Erstellung und Pflege von Software wird immer schwieriger. Viele Softwareprojekte scheitern daher. F¨ ur solche Projekte lassen sich gemeinsame Kennzeichen identifizieren wie die Unf¨ ahigkeit, mit wechselnden Anforderungen umzugehen, das sp¨ ate Erkennen von schwerwiegenden Fehlern oder eine stark differierende Arbeitsweise der einzelnen Teammitglieder ⁴ . Das Erkennen der Symptome f¨ uhrt jedoch noch nicht zu einer L¨ osung des Dilemmas. Trotz der Verschiedenartigkeit solcher Projekte, l¨ asst sich der Grund der meisten Misserfolge oft zur¨ uckf¨ uhren auf eine Kombination der folgenden Ursachen:

ad-hoc-Anforderungsmanagement

zweideutige und unpr¨ azise Kommunikation schlechte Systemarchitekturen un¨ uberschaubare Komplexit¨ at unerkannte Widerspr¨ uchlichkeiten

³ Man redet hier von Legacy-Software.

⁴ In [Jon96] und [You97] findet man eine Reihe weiterer solcher Anzeichen.

6 KAPITEL 1. EINLEITUNG

unzureichende Tests

subjektive Einsch¨ atzung des Projektfortschritts

fehlende Beseitigung von Risiken

unkontrollierte Handhabung von ¨ Anderungen

unzureichende Routine

1.1.3 Softwareentwicklungsprozesse

Trotz der fortw¨ ahrend anwachsenden Komplexit¨ at kommen heute vielfach noch Entwicklungsmethoden wie vor 25 Jahren zum Einsatz. Um die erkannten Ursachen f¨ ur unbefriedigende Projektverl¨ aufe zu beseitigen, werden neue Methoden ben¨ otigt, die den Entwicklern klare Arbeitsrichtlinien an die Hand geben. Ben¨ otigt wird ein Prozess, der alle Facetten der Softwareentwicklung ber¨ ucksichtigt, der die Entwickler durch anstehende Aktivit¨ aten f¨ uhrt, die einzelnen Aufgaben jedes Einzelnen und des Teams beschreibt, zu erstellende Dokumente spezifiziert und Kritierien f¨ ur ¨ Uberwachung und Kontrolle bietet.

Ein Softwareentwicklungsprozess definiert, wer was, wann und wie zu tun hat, um ein bestimmtes Ziel zu erreichen, n¨ amlich ein Softwaresystem zu entwickeln. Dabei involviert er sog. Best Practices. Dies sind jahrelang erprobte und bew¨ ahrte, wirtschaftlich sinnvolle Ans¨ atze zur Softwareentwicklung, die in einer optimalen Kombination die zuvor beschriebenen Probleme l¨ osen [Sof01] [Kru99]. Zu den Best Practices z¨ ahlen die im Folgenden aufgelisteten Punkte, die erst sp¨ ater n¨ ahergehend erl¨ autert werden.

Iteratives Vorgehen

Anforderungsmanagement

Komponentenbasierte Architekturen

Visuelle Softwaremodellierung

Qualit¨ atskontrolle

Kontrolliertes ¨ Anderungsmanagement

Nach [GFF00] ist ein Trend zu iterativen Entwicklungsprozessen festzustellen. Al- lerdings entwickeln derzeit nur knapp die H¨ alfte aller Unternehmen nach einem

1.2. AUFGABE 7

definierten Vorgehensmodell. Besonders bei kleinen und jungen Firmen sei das Vorgehen in der Regel eher als ” chaotisch“ zu bezeichnen. Generell liege die Einhaltung der Prozesse sehr im Ermessen einzelner Entwicklungsabteilungen. Die Marktforscher fordern aus diesen Gr¨ unden eine ¨ offentliche Forschungsf¨ orderung im Bereich der Softwaretechnik. Besondere Aufgabenfelder liegen dabei besonders in der Verbesserung von Prozessen, Methoden und Werkzeugen. Derzeit betreiben nur etwa 22% der deutschen Entwicklungsfirmen Forschung in diesen Bereichen.

1.2 Aufgabe

In der objektorientierten Szene hat sich die Unified Modeling Language (UML) inzwischen zu einem anerkannten Standard etabliert und ist hinreichend bekannt, weshalb sie hier einf¨ uhrend als Vergleichskonzept genannt sei. Als Notationssprache bietet sie ein hilfreiches Werkzeug bei der Durchf¨ uhrung von Softwareprojekten. Ihr Einsatz allein reicht f¨ ur die erfolgreiche Fertigstellung eines Softwaresystems jedoch nicht aus [ME99]. Es wird ein Prozessmodell (auch: Vorgehensmodell ) ben¨ otigt, welches eine detaillierte Beschreibung durchzuf¨ uhrender Aktivit¨ aten liefert, die unter Zuhilfenahme von objektorientierten Technologien und Methoden bestimmte Ergebnisse implizieren. Zu solchen Methoden z¨ ahlt neben vielen anderen auch die UML, deren Einsatz sich in diesem Sinne rechtfertigen l¨ asst. Im Gegensatz zu einer standardisierten Notation sind sich jedoch viele Experten einig, dass es ein standardisiertes Prozessmodell zumindest in absehbarer Zeit nicht geben wird. F¨ ur die Praxis ben¨ otigt man einen auf das Unternehmen zugeschnittenen Prozessleitfaden, der die jeweiligen Belange der Firma und des Projektes ber¨ ucksichtigt und konkrete Vorgehensstrategien vermittelt [Oes99]. Die auf dem Markt befindlichen Prozessmodelle sind jedoch eher als Universalbauk¨ asten zu verstehen, die f¨ ur die konkrete Anwendung ungeeignet sind. Man bezeichnet sie daher auch als generische Prozessmodelle.

1.2.1 Rahmen

Die Diplomarbeit wurde in Zusammenarbeit mit der Splendid Internet GmbH & Co. KG (im Folgenden kurz ” Splendid“) angegangen, die eine solche Anpas-

sung und anschließende Einf¨ uhrung eines Softwareentwicklungsprozesses geplant

8 KAPITEL 1. EINLEITUNG

hatte. Die Firma Splendid ist ein Entwicklungsunternehmen aus Kiel mit einer gegenw¨ artigen Mitarbeiterzahl von ca. 30 Angestellten. Splendid [Spl] ist eine Tochterfirma der freetnet.de AG [fre01], welche zur MobilCom AG [Mob01] geh¨ ort. Im Wesentlichen entwickelt Splendid internetbasierte Kommunikationsl¨ osungen f¨ ur Unternehmen. Die Produkte gestalten sich als Individuall¨ osungen f¨ ur den Kunden.

Splendid entschied sich f¨ ur den Rational Unified Process (RUP), der von seiner Form her dem Unified Software Development Process entspringt, der von den drei Amigos“ ⁵ im Jahre 1999 vorgestellt wurde [JBR99]. Ebenfalls angelehnt an

”

diesen Rahmenprozess ist der unter Leitung von Bernd Oestereich erarbeitete Object Engineering Process (OEP). Vor allem im Bereich des ¨ offentlichen Dienstes findet man noch das V-Modell 97, welches zum ersten Mal 1992 als ” Software-entwicklungsstandard der Bundeswehr“ auftrat. Ein Vergleich der verschiedenen Prozessmodelle soll an dieser Stelle nicht erfolgen, da der RUP als Vorgabe bereits feststand.

1.2.2 Ziele

Der Rational Unified Process ist ein Prozessmodell, welches durch ¨ uber 2.000

HTML-Seiten beschrieben ist. F¨ ur den praktischen Einsatz in einem Unternehmen muss die Komplexit¨ at dieses Rahmenwerks auf ein akzeptables Maß heruntergebrochen werden, um eine verst¨ andliche Einf¨ uhrung der Konzepte und Methodiken zu erm¨ oglichen. Diesen Vorgang bezeichnet man als Prozesskonfiguration oder -anpassung. Das Ziel meiner Diplomarbeit besteht somit in der Analyse des Rational Unified Process in all seinen Einzelheiten, um eine Anpassung vorzunehmen, die f¨ ur Splendid einen geeigneten Einstieg bildet. Das Tailoring ⁶ zielt dabei auf eine Version, die nur die Elemente des Prozesses enth¨ alt, die dem Unternehmen in der Einf¨ uhrungsphase den meisten Nutzen bringen. Neben der dadurch notwendigen Unternehmensanalyse geh¨ ort auch die Einf¨ uhrung des Prozesses in

⁵ So werden weitl¨ aufig die Urv¨ ater des Prozesses betitelt. Namentlich sind dies Ivar Jacobson, Grady Booch und James Rumbaugh. Die Spezifikation der Unified Modeling Language ist ihnen ebenfalls zuzuschreiben.

⁶ Als Tailoring bezeichnet man die Streichung bestimmter Prozesselemente zur Erlangung eines erh¨ ohten Schlankheitsgrades.

1.3. AUFBAU 9

Form von Mitarbeiterschulungen, Interviews und Diskussionen zu meinem Aufgabenbereich. W¨ ahrend der Zeit bei Splendid bin ich Ansprechpartner f¨ ur alle Belange des neuen Softwareentwicklungsprozesses.

1.3 Aufbau

Der weitere Aufbau der vorliegenden Arbeit gliedert sich im Wesentlichen in drei Teile. In Kapitel 2 (Der Unified Process) werden die grundlegendsten Elemente und Konzepte des Unified Process verdeutlicht. Die Abschnitte sind lediglich als Kurzeinf¨ uhrung in das komplexe Thema zu verstehen. Angesprochen werden die Historie des Prozesses und der Aufbau durch die verschiedenen Prozesselemente. Abschnitt 2.3 beleuchtet etwas ausf¨ uhrlicher die herausragenden Eigenschaften des Unified Process, w¨ ahrend die nachfolgenden beiden Abschnitte sich mit der zeitlichen und inhaltlichen Gliederung in Phasen und Disziplinen besch¨ aftigen.

Kapitel 3 (Die Einf¨ uhrung) erl¨ autert verschiedene Aspekte zur Einf¨ uhrung des Prozesses bei Splendid. Zun¨ achst werden einige der Vor¨ uberlegungen erw¨ ahnt, die zu Beginn des Projektes gemacht wurden. Die daraus resultierenden Schlussfolgerungen begr¨ unden eine Unternehmensanalyse (Abschnitt 3.3), auf deren Basis die Anpassung des Prozesses erfolgen kann. Die letzten Abschnitte des Kapitels veranschaulichen, wie eine sinnvolle Einbeziehung der Mitarbeiter in die Prozesskonfiguration m¨ oglich wird.

Die eigentliche Prozessanpassung wird ausf¨ uhrlich in Kaptitel 4 (Die Anpassung) er¨ ortert. Nach einer kurzen theoretischen Einordnung folgt die Vorstellung des Project Web Template, ein Konzept, das zur Darstellung der Anpassung hilfreich scheint. Abschnitt 4.3 stellt jede einzelne der Disziplinen des Prozesses in seiner angepassten Form vor und begr¨ undet die Streichung von Prozesselementen entsprechend.

Die Arbeit schließt mit einem kurzen Ausblick in Kapitel 5.

Kapitel 2

Der Unified Process

In diesem Kapitel wird der Unified Process vorgestellt. Die Beschreibungen berufen sich im Wesentlichen auf den urspr¨ unglich entwickelten Prozess der drei Amigos, der heute durch die Firma Rational als Produkt vertrieben wird. Wenn also im Folgenden vom Unified Process gesprochen wird, beziehen sich neuere Erkenntnisse durchaus auf die aktuelle Produktversion des Rational Unified Process.

2.1 ¨ Uberblick

Zur Einf¨ uhrung sei zun¨ achst hingewiesen auf die geschichtliche Entwicklung des Prozesses und auf die bereits erw¨ ahnte Auspr¨ agung als konkretes Produkt der Firma Rational. Im Anschluss wird ein grober ¨ Uberblick des Unified Process gegeben, um mit diesen grundlegenden Basiskenntnissen in die detaillierten Erl¨ auterungen der nachfolgenden Abschnitte einsteigen zu k¨ onnen.

2.1.1 Historie

Die Wurzeln des Prozesses sind im Jahre 1967 in Schweden zu finden. Die Firma Ericsson modellierte ihre Systeme bereits mit Konzepten, die ihre Entsprechung in der heutigen Unified Modelling Langage (UML) finden. Neben den Vorreitern der Use Cases und diversen Diagrammtypen konnte man auch eine Architekturbeschreibung und erste Ans¨ atze komponentenbasierter Entwicklung finden. Ivar

10

2.1. ¨ UBERBLICK 11

Jacobson war Erfinder dieser Entwicklungsmethode und verfeinerte sie ¨ uber viele

Jahre hinweg zu einem Softwareentwicklungsprozess, bis er 1987 Ericsson verließ und in Stockholm die Firma Objectory AB gr¨ undete. Zwischenzeitlich wurde im Jahre 1976 von der CCITT ¹ die Specification and Description Language (SDL) herausgegeben, eine Sprache zur Beschreibung des funktionalen Verhaltens von Telekommunikationssystemen. Die SDL war ihrer Zeit bereits weit voraus, jedoch zu einer Phase, da die objektorientierte Modellierung noch nicht ausgereift war, so dass sie heute zunehmend von der UML verdr¨ angt wird.

Ivar Jacobson brachte 1988 die erste Version des Objectory Process heraus, ein Softwareentwicklungsprozess, der als Produkt vertrieben und weiterentwickelt wurde. Obwohl das Konzept bei Ericsson bereits zur Anwendung kam, wurden die Use Cases auf der OOPSLA ² Konferenz 1987 erstmals namentlich vorgestellt, Diagrammtechniken wurden entwickelt, und die Use Cases wurden integraler Be-standteil des Objectory Process.

Im Fr¨ uhjahr 1995 wurde Objectory AB von der Rational Software Corporation ubernommen, und in den Objectory Process, der nun in Rational Objectory Pro- ¨

cess umbenannt wurde, flossen viele weitere Softwaretechniken ein, die bei Rational entwickelt worden waren. Zur gleichen Zeit etwa entstand die Unified Modeling Language. Grady Booch war schon seit den fr¨ uhen Anf¨ angen bei Rational besch¨ aftigt und hatte Anfang der 90er Jahre die Booch-Methode entwickelt. James Rumbaugh ist der Autor der Object Modeling Technique (OMT), und als er 1994 zu Rational wechselte, begannen die zwei ihre Methoden zu vereinheitlichen, so dass im Oktober 1995 die Unified Method entstand, in etwa zu der Zeit, als Ivar Jacobson sich Rational anschloss. Die drei brachten dann die nachfolgende Version 0.9 als die Unified Modeling Language heraus, bis im November 1997 die Version 1.1 von der OMG ³ als Quasi-Standard ver¨ offentlicht wurde. Im Ratio-

¹ Das ConsultativeCommittee for International Telegraph and Telephone war bis Juni 1994 ein Untergremium der International Telecommunication Union (ITU), speziell f¨ ur das Fernmeldewesen, das verschiedene Empfehlungen und Schnittstellen zur Daten¨ ubertragung ¨ uber

¨ offentliche Netze verabschiedet hat. Die CCITT-Empfehlungen werden heute mit ITU-T bezeichnet.

² Die OOPSLA ist seit 1986 eine der wichtigsten Konferenzen im Bereich Objektorientierung und steht f¨ ur object-oriented programming, systems, languages, and applications.

³ Die Object Management Group (OMG) ist ein nicht-kommerzielles Konsortium verschie- denster großer und kleinerer Firmen, das sich zur Aufgabe gestellt hat, auf Kompatibilit¨ at und

12 KAPITEL 2. DER UNIFIED PROCESS

nal Objectory Process wurde die UML von Anfang an als Modellierungssprache verwendet.

Rational ¨ ubernahm in der kommenden Zeit einige weitere Firmen, die ihr Know-How mit in den Prozess einbrachten. 1998 war der Rational Objectory Process zu einem ausgereiften Softwareentwicklungsprozess herangereift, der den kompletten Entwicklungszyklus eines Softwareprojektes unterst¨ utzte. Viele Beitr¨ age, Konzepte und Methoden wurden in ihm vereinigt, die nicht nur von Jacobson, Booch und Rumbaugh kamen, sondern Autoren und Firmen weltweit als Ursprung hatten. Unter diesem Gesichtspunkt erfuhr der Prozess eine weitere Namens¨ anderung und wurde im Juni 1998 als der Rational Unified Process 5.0 ver¨ offentlicht. Das Wort ’unified’ sollte die Vereinheitlichung von Ans¨ atzen, Methoden und Konzepten ausdr¨ ucken, an der auch Hunderte von Rationalkunden mitwirkten.

2.1.2 Der Unified Process als Produkt

Der Unified Process wird seitdem von der Firma Rational als Produkt vermarktet. Erfahrungen, Methoden und Konzepte finden damit einen Container, in dem sie zur Geltung kommen. Entwickeltes Know-how veraltet nicht in irgendwelchen Ordnern und Aktenschr¨ anken, ohne dass es jemals zum Einsatz kommt, so die Argumente von Rational. In der Tat bringt der Ansatz der Vermarktung des Prozesses als Produkt eine Reihe von Vorteilen, aber auch einige Nachteile. Im Folgenden seien die Eigenschaften des Produktes ’Rational Unified Process’ kurz skizziert:

Dadurch, dass der Prozess wie ein Softwareprodukt gewartet und weiterentwickelt wird, erhalten Lizenznehmer regelm¨ aßige Updates und Erweiterungen. Neueste Erfahrungen und Erkenntnisse werden somit relativ aktuell an die Kunden weitergegeben.

Der Rational Unified Process besteht aus rund 2.000 HTML-Dokumenten. Diese Webseiten k¨ onnen somit mit jedem Internetbrowser betrachtet werden. F¨ ur die Navigation durch die Seiten existiert weiterhin ein Java-Applet, welches am linken Rand der Dokumente einen Navigationsbaum bereitstellt (siehe Abb 2.1).

Vereinheitlichung zielende Industriespezifikationen f¨ ur den Softwarebereich herauszugeben. Ne- ben der UML z¨ ahlt hierzu auch die von der OMG selbst entwickelte CORBA-Architektur.

2.1. ¨ UBERBLICK 13

Abbildung 2.1: Der Rational Unified Process pr¨ asentiert sich als Web-Dokument

Durch die Webtechnologie lassen sich in den Navigationsbaum oder in die Dokumente selbst weitere Links einf¨ ugen, die auch zu externen Dateien oder Programmen verweisen k¨ onnen. Der Prozess l¨ asst sich somit an die Bed¨ urfnisse des Unternehmens anpassen. Die Flexibilit¨ at einer solchen Online-Version ist mit einer Dokumentation in Papierform nur schwer zu erreichen.

In dem Prozess versprechen Tool-Mentoren Unterst¨ utzung bei der Erstellung der geforderten Artefakte ⁴ . Nat¨ urlich werden hier vorwiegend die Produkte aus dem Hause Rational mit einbezogen.

Vorlagen (Templates) f¨ ur Artefakte sind auch f¨ ur Microsoft-Applikationen wie Word, FrontPage und MS Project verf¨ ugbar, wodurch die Windows-Plattform als Ursprung erkennbar wird. Rational entwickelt jedoch seit einiger Zeit auch f¨ ur die Unix- bzw. Linux-Plattform.

Nicht unerw¨ ahnt soll bleiben, dass f¨ ur dieses Produkt nat¨ urlich eine Lizenzgeb¨ uhr erhoben wird. Da es keinerlei Funktionalit¨ aten beherrscht, die mit einem Softwareprogramm vergleichbar w¨ aren, sind die Ausgaben — verglichen mit einem Satz herk¨ ommlicher Fachb¨ ucher — relativ hoch, zumal f¨ ur

⁴ Dokumente, Modelle und andere Ergebnisse von Aktivit¨ aten werden als Artefakte bezeich- net. Sie werden in Abschnitt 2.2.3 n¨ ahergehend beschrieben.

14 KAPITEL 2. DER UNIFIED PROCESS

jede Arbeitsstation eine extra Lizenz ben¨ otigt wird.

Im Gegensatz zu Open Source-Projekten liegt die Verantwortung und Pflege des Prozesses allein bei der Firma Rational. Marketingtechnisch weiß Rational diese Position recht gut auszunutzen.

2.1.3 Der Unified Process in K¨ urze

Um einen besseren Einstieg in die Abschnitte ab Seite 15 zu erm¨ oglichen, sei im Folgenden kurz angerissen, was den Unified Process ausmacht und wie er in seiner Grundstruktur beschaffen ist.

Merkmale

Zun¨ achst einmal ist der Unified Process ein Softwareentwicklungsprozess. Solch ein Prozess beschreibt die Menge aller Aktivit¨ aten, die notwendig sind, um die Anforderungen des Anwenders in ein Softwaresystem zu transformieren (siehe Abb. 2.2). Der Unified Process geht jedoch dar¨ uber hinaus. Er bildet ein generisches Rahmenwerk, das in vielf¨ altiger Art und Weise angepasst werden kann. Je nach Art des zu entwickelnden Softwaresystems, Unternehmenstyp, Kompetenzbasis oder Projektgr¨ oße lassen sich unterschiedliche Auspr¨ agungen des Prozesses instanziieren. Er ist komponentenbasiert und verwendet die Unified Modeling Language (UML) als integralen Bestandteil zur visuellen Modellierung. Seine wichtigsten Merkmale sind jedoch, dass er anwendungsfallgetrieben (siehe Abschnitt 2.3.1), architekturzentriert (siehe Abschnitt 2.3.2) und iterativ- inkrementell (siehe Abschnitt 2.3.3) vorgeht.

2.2. PROZESSELEMENTE 15

Abbildung 2.3: Die zweidimensionale Strukur des Unified Process

Struktur

Vom Start bis zum Ende eines Projektes durchl¨ auft der Unified Process einen Zyklus, der als Ergebnis eine neue Version eines auslieferbaren Produktes (Release) liefert. Ein Zyklus gliedert sich zeitlich in vier Phasen (siehe Abschnitt 2.4), die jeweils mit einem Meilenstein abschließen, der eine bestimmte Menge von Artefakten in einem vorher festgelegten Zustand definiert. Jede Phase ist wiederum aufgeteilt in einzelne Iterationen, in der jeweils alle Disziplinen (siehe Abschnitt 2.5) durchlaufen werden. Diese bilden die zweite Dimension der Prozessstruktur und gruppieren zusammengeh¨ orige Aktivit¨ aten. Der Unified Process ist somit organisiert bzgl. Zeit und Inhalt (siehe Abb. 2.3).

2.2 Prozesselemente

2.2.1 Rollen (wer)

Eine Rolle (engl. role) defininert das Verhalten und die Verantwortlichkeiten einer einzelnen Person oder einer Gruppe von Personen, die als Team zusammenarbei- ten. Eine Rolle verk¨ orpert somit eine Stellenbeschreibung innerhalb des Prozesses.

16 KAPITEL 2. DER UNIFIED PROCESS

Personen schl¨ upfen in eine bestimmte Rolle und sind damit verantwortlich f¨ ur eine Menge von Artefakten, die durch entsprechende Aktivit¨ aten erzeugt oder modifiziert werden. Der Begriff umschreibt also den ” Hut“, den eine Person w¨ ahrend

bestimmter Aktivit¨ aten tr¨ agt. Dabei kann eine Person im Projektverlauf auch mehrere H¨ ute tragen; es herrscht gewissermaßen eine m:n-Beziehung zwischen Personen und Rollen. Abbildung 2.4 verdeutlicht diesen Zusammenhang.

Wenn im Folgenden von dem Begriff Rolle Gebrauch gemacht wird, sei aus dem Kontext zu entnehmen, ob wirklich die Rollenbeschreibung gemeint ist oder die Person, die die Rolle aus¨ ubt ⁵ .

2.2.2 Aktivit¨ aten (wie)

Aktivit¨ aten (engl. activity) sind Rollen zugeordnet und umschreiben die T¨ atigkeit, die eine Person in dieser Rolle ausf¨ uhren soll, um ein f¨ ur das Projekt sinnvolles Ergebnis zu erhalten. Das Resultat einer Aktivit¨ at ist ¨ ublicherweise die Erstellung oder ¨ Uberarbeitung eines Artefaktes, wobei in der Regel andere Artefakte als Input verwendet werden. Somit verfolgt eine Aktivit¨ at immer eine klar definierte Zielsetzung. Die Bearbeitungsdauer liegt dabei zwischen einigen Stunden und mehreren Tagen. Oft sind Aktivit¨ aten in einzelne Schritte (steps)

⁵ Bis RUP 2001 v3.0 hießen die heutigen Roles noch Worker, wodurch eine Personalisierung in der deutschen Sprache noch anschaulicher war: Der Worker tut dies und das. Der Begriff Rolle wird der sprachlichen Vereinfachung halber im Folgenden genauso verwendet.