Praktische Anpassung und Einführung des Rational Unified Process in einem E-Business Unternehmen

Inhaltsverzeichnis

Zusammenfassung

1 Einleitung
1.1 Motivation
1.1.1 Bedeutung von Software
1.1.2 Probleme der Softwareentwicklung
1.1.3 Softwareentwicklungsprozesse
1.2 Aufgabe
1.2.1 Rahmen
1.2.2 Ziele
1.3 Aufbau

2 Der Unified Process
2.1 Uberblick
2.1.1 Historie
2.1.2 Der Unified Process als Produkt
2.1.3 Der Unified Process in Ktirze
2.2 Prozesselemente
2.2.1 Rollen (wer)
2.2.2 Aktivitaten (wie)
2.2.3 Artefakte (was)
2.2.4 Workflows (wann)
2.2.5 Weitere Prozesselemente
2.3 Grundkonzepte
2.3.1 anwendungsfallgetrieben
2.3.2 architekturzentriert
2.3.3 iterativ und inkrementell
2.4 Phasen
2.4.1 Inception Phase
2.4.2 Elaboration Phase
2.4.3 Construction Phase
2.4.4 Transistion Phase
2.5 Disziplinen
2.5.1 Business Modeling
2.5.2 Requirements
2.5.3 Analysis and Design
2.5.4 Implementation
2.5.5 Test
2.5.6 Deployment
2.5.7 Configuration and Change Management
2.5.8 Project Management
2.5.9 Environment

3 Die Einfuhrung
3.1 Voriiberlegungen
3.1.1 Inhaltliche Aspekte
3.1.2 Planerische Aspekte
3.1.3 Menschliche Aspekte
3.2 Schlussfolgerungen
3.3 Unternehmensanalyse
3.3.1 Analysefelder
3.3.2 Fragebogenaktion
3.3.3 Ergebnisse
3.4 Schulungen
3.5 Diskussionen

4 Die Anpassung
4.1 Der Development Case
4.1.1 Einordnung
4.1.2 Konfigurationsmoglichkeiten
4.1.3 Bezugsebene
4.2 Das Project Web Template
4.2.1 Probleme
4.2.2 Losungsansatz
4.2.3 Aufbau
4.2.4 Development Case
4.2.5 Artefakte
4.3 Die Disziplinen
4.3.1 Business Modeling
4.3.2 Requirements
4.3.3 Analysis & Design
4.3.4 Implementation
4.3.5 Test
4.3.6 Deployment
4.3.7 Configuration & Change Management
4.3.8 Project Management
4.3.9 Environment

5 Ausblick

Literatur

Danksagung

Erklarung

Zusammenfassung

In Zusammenarbeit mit der Firma Splendid Internet GmbH & Co. KG wurde auf Basis des Rational Unified Process ein abgeleiteter Softwareent- wicklungsprozess entworfen, der zur Einfuhrung 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 Einfuhrung und Anpassung des Prozesses vorge- gangen wurde.

Kapitel 1 Einleitung

1.1 Motivation

1.1.1 Bedeutung von Software

Nach einer Studie im Auftrag des Bundesministeriums fur Bildung und For- schung [GFF00] ist der Softwaremarkt heute schon als einer der Schlusselmarkte in Deutschland zu sehen; die entwickelte Software dient oft als wettbewerbs- entscheidendes Instrument in den sekundaren Softwarebranchen^[1]. Nach den im Oktober 2001 vorgelegten Konjunkturdaten prognostiziert der Bundesverband In- formationswirtschaft, Telekommunikation und neue Medien e.V. (BITKOM) fur die Branchen Informationstechnik und Telekommunikation (ITK) in Deutschland ein Wachstum um 4,6% auf 254 Mrd. DM [Bun01]. In vielen Sekundarbereichen ist bereits der gesamte Umsatz von Software abhangig. Nur beispielhaft sei hier die Automobilindustrie erwahnt. Abgesehen von der betrieblichen Produktions- und Personalplanung konnten die komplexen Steuerfunktionen der Industriero- boter ohne Software nicht realisiert werden. Die Fahrzeuge selbst enthalten heut- zutage schon weit uber tausend elektronische Bauteile, die durch Programmlo- gik verschiedenste Regelfunktionalitaten tibernehmen. Als einer der anerkannte- sten Kopfe im Segment der methodischen Softwareentwicklung formulierte Grady Booch in der Fachpresse:

„Ohne Software wiirde heutzutage kein modernes Unternehmen mehr existieren konnen, keine Regierung der Welt an der Macht sein kon- nen und die Kommunikation innerhalb der Gesellschaft wirde nicht mehr funktionieren. Software ermoglicht uns eine Bereitstellung von Informationen, die fruher kaum denkbar gewesen ware. Global be­trachtet, hat Software das Wirtschaftswachstum herbeigefuhrt. Vom menschlichen Gesichtspunkt betrachtet, haben Softwareprodukte Kran- ken zur Gesundheit verholfen, Stummen zur Sprache und Unbewegli- chen zur Mobilitat. (Inter diesen Gesichtspunkten hat sich Software zu einem unverzichtbaren Bestandteil der modernen Welt entwickelt. “ [Boo98]^[2]

1.1.2 Probleme der Softwareentwicklung

Diese Abhangigkeit fuhrt zu immer grofieren Anforderungen an die Komplexitat der Softwaresysteme. Dies wird beeinflusst durch die immer leistungsfahigeren Hardwaresysteme und den zunehmenden Austausch jeglicher Art von Informati­on, nicht zuletzt motiviert durch das Internet, durch das der schnelle weltweite Transfer von einfachen Textseiten bis hin zu multimedialer Videoubertragung moglich geworden ist. Die Anwender der Systeme identifizieren bei jedem Re­lease weitere Verbesserungsmoglichkeiten, so dass die Produkte immer mehr an die Bedurfnisse und Wunsche angepasst werden. Die Erwartungen an Qualitat und Funktionsumfang nehmen zu und die Stellung des Softwaresystems in seinem Umfeld wird immer signifikanter. Die Industrie fordert von den Softwareentwick- lern qualitativ hochwertige Software, um sich am Markt behaupten zu konnen. Laut der bereits zitierten Studie [GFF00] werden in diesem Zusammenhang Zu- verlassigkeit und Funktionalitat als die wichtigsten wettbewerbsbestimmenden Eigenschaften betrachtet. Weiterhin stehen fur die Unternehmen Performanz, Skalierbarkeit, Benutzerfreundlichkeit und Wiederverwendbarkeit auf der Liste der entscheidenden nicht-funktionalen Anforderungen. Anforderungen, die der Softwareentwickler umsetzen muss. Die Erwartungen an ihn steigen kontinuier- lich. Auch bei dem Versuch, alte Systeme^[3] auf moderne Technologien umzustellen, sind die Softwarefirmen mit einer Reihe von technischen und organisatorischen Problemen konfrontiert, die es zu losen gilt.

Gleichzeitig sollen zu erstellende Softwaresysteme in immer kurzeren Entwick- lungszeiten fertiggestellt werden; der sog. Time-to-market-Faktor wird immer entscheidender. Besonders im schnelllebigen Internetgeschaft spielt die Fertigungs- dauer eine wichtige Rolle. Man spricht hier von Technologiehalbwertszeiten von nur drei bis funf Jahren. Ein Produkt zum richtigen Zeitpunkt auf den Markt zu bringen, kann dabei mafigeblich den Erfolg eines Unternehmens entscheiden. Die Zahl der Insolvenzverfahren vieler Start-Up-Firmen der New Economy un- termauert diese Behauptung.

Fazit: Die Branche der Softwareentwickler sieht sich immer komplexe- ren Aufgaben gegentibergestellt, die in immer kurzeren Zeitabschnit- ten zu ltsen 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. Fur solche Projekte lassen sich gemein- same Kennzeichen identifizieren wie die Unfahigkeit, mit wechselnden Anforde­rungen umzugehen, das spate Erkennen von schwerwiegenden Fehlern oder eine stark differierende Arbeitsweise der einzelnen Teammitglieder^[4]. Das Erkennen der Symptome fuhrt jedoch noch nicht zu einer Losung des Dilemmas. Trotz der Ver- schiedenartigkeit solcher Projekte, ltsst sich der Grund der meisten Misserfolge oft zuruckfuhren auf eine Kombination der folgenden Ursachen:

- ad-hoc-Anforderungsmanagement
- zweideutige und unprazise Kommunikation
- schlechte Systemarchitekturen
- untberschaubare Komplexittt
- unerkannte Widerspriichlichkeiten
- unzureichende Tests
- subjektive Einschatzung des Projektfortschritts
- fehlende Beseitigung von Risiken
- unkontrollierte Handhabung von Anderungen
- unzureichende Routine

1.1.3 Softwareentwicklungsprozesse

Trotz der fortwUhrend anwachsenden Komplexitat kommen heute vielfach noch Entwicklungsmethoden wie vor 25 Jahren zum Einsatz. Um die erkannten Ur- sachen fur unbefriedigende Projektverlaufe zu beseitigen, werden neue Metho- den benUtigt, die den Entwicklern klare Arbeitsrichtlinien an die Hand geben. BenUtigt wird ein Prozess, der alle Facetten der Softwareentwicklung beruck- sichtigt, der die Entwickler durch anstehende Aktivitaten fuhrt, die einzelnen Aufgaben jedes Einzelnen und des Teams beschreibt, zu erstellende Dokumente spezifiziert und Kritierien fur Uberwachung und Kontrolle bietet.

Ein Softwareentwicklungsprozess definiert, wer was, wann und wie zu tun hat, um ein bestimmtes Ziel zu erreichen, nUmlich ein Softwaresystem zu entwickeln. Dabei involviert er sog. Best Practices. Dies sind jahrelang erprobte und bewUhr- te, wirtschaftlich sinnvolle AnsUtze zur Softwareentwicklung, die in einer opti- malen Kombination die zuvor beschriebenen Probleme lUsen [Sof01] [Kru99]. Zu den Best Practices zUhlen die im Folgenden aufgelisteten Punkte, die erst spUter nUahergehend erlUautert werden.

- Iteratives Vorgehen
- Anforderungsmanagement
- Komponentenbasierte Architekturen
- Visuelle Softwaremodellierung
- QualitUtskontrolle
- Kontrolliertes Anderungsmanagement

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

definierten Vorgehensmodell. Besonders bei kleinen und jungen Firmen sei das Vorgehen in der Regel eher als ,,chaotisch“ zu bezeichnen. Generell liege die Ein- haltung der Prozesse sehr im Ermessen einzelner Entwicklungsabteilungen. Die Marktforscher fordern aus diesen Grtinden eine dffentliche Forschungsforderung 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 einfuhrend als Vergleichskonzept genannt sei. Als Notationsspra- che bietet sie ein hilfreiches Werkzeug bei der Durchfuhrung von Softwarepro- jekten. Ihr Einsatz allein reicht fur die erfolgreiche Fertigstellung eines Software- systems jedoch nicht aus [ME99]. Es wird ein Prozessmodell (auch: Vorgehens­modell ) benotigt, welches eine detaillierte Beschreibung durchzufuhrender Akti- vitaten liefert, die unter Zuhilfenahme von objektorientierten Technologien und Methoden bestimmte Ergebnisse implizieren. Zu solchen Methoden zahlt neben vielen anderen auch die UML, deren Einsatz sich in diesem Sinne rechtfertigen lasst. Im Gegensatz zu einer standardisierten Notation sind sich jedoch viele Ex- perten einig, dass es ein standardisiertes Prozessmodell zumindest in absehbarer Zeit nicht geben wird. Fur die Praxis benotigt man einen auf das Unternehmen zugeschnittenen Prozessleitfaden, der die jeweiligen Belange der Firma und des Projektes beritcksichtigt und konkrete Vorgehensstrategien vermittelt [Oes99]. Die auf dem Markt befindlichen Prozessmodelle sind jedoch eher als Universal- baukasten zu verstehen, die fur 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 anschliefiende Einfuhrung eines Softwareentwicklungsprozesses geplant hatte. Die Firma Splendid ist ein Entwicklungsunternehmen aus Kiel mit einer ge- genwartigen Mitarbeiterzahl von ca. 30 Angestellten. Splendid [Spl] ist eine Toch- terfirma der freetnet.de AG [fre01], welche zur MobilCom AG [Mob01] gehort. Im Wesentlichen entwickelt Splendid internetbasierte KommunikationslOsungen fur Unternehmen. Die Produkte gestalten sich als Individuallosungen fur den Kunden.

Splendid entschied sich fur den Rational Unified Process (RUP), der von seiner Form her dem Unified Software Development Process entspringt, der von den ,,drei Amigos“^[5] im Jahre 1999 vorgestellt wurde [JBR99]. Ebenfalls angelehnt an diesen Rahmenprozess ist der unter Leitung von Bernd Oestereich erarbeitete Ob­ject 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. Fur den praktischen Einsatz in einem Unterneh­men muss die Komplexitat dieses Rahmenwerks auf ein akzeptables Mafi herun- tergebrochen werden, um eine verstandliche Einfuhrung der Konzepte und Metho- diken zu ermoglichen. 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 vorzuneh- men, die fur Splendid einen geeigneten Einstieg bildet. Das Tailoring^[6] zielt dabei auf eine Version, die nur die Elemente des Prozesses enthalt, die dem Unterneh­men in der Einfuhrungsphase den meisten Nutzen bringen. Neben der dadurch notwendigen Unternehmensanalyse gehoart auch die Einfuahrung des Prozesses in Form von Mitarbeiterschulungen, Interviews und Diskussionen zu meinem Auf- gabenbereich. Wahrend der Zeit bei Splendid bin ich Ansprechpartner fur 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 Kurzeinfuhrung in das komplexe Thema zu verstehen. Angesprochen werden die Historie des Prozesses und der Aufbau durch die verschiedenen Prozesselemente. Abschnitt 2.3 beleuchtet etwas ausfuhrlicher die herausragenden Eigenschaften des Unified Process, waahrend die nachfolgenden beiden Abschnitte sich mit der zeitlichen und inhaltlichen Gliederung in Phasen und Disziplinen beschaftigen.

Kapitel 3 (Die Einfuhrung) erlautert verschiedene Aspekte zur Einfuhrung des Prozesses bei Splendid. Zunachst werden einige der Voruberlegungen erwahnt, die zu Beginn des Projektes gemacht wurden. Die daraus resultierenden Schlussfol- gerungen begriinden 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 Prozess- konfiguration maoglich wird.

Die eigentliche Prozessanpassung wird ausfuhrlich in Kaptitel 4 (Die Anpas­sung ) erortert. Nach einer kurzen theoretischen Einordnung folgt die Vorstellung des Project Web Template, ein Konzept, das zur Darstellung der Anpassung hilf- reich scheint. Abschnitt 4.3 stellt jede einzelne der Disziplinen des Prozesses in seiner angepassten Form vor und begriindet die Streichung von Prozesselementen entsprechend.

Die Arbeit schliefit mit einem kurzen Ausblick in Kapitel 5.

Es sei darauf hingewiesen, dass die Firma Splendid aus verstandlichen Grunden einer Veroffentlichung aller Analysen und Ergebnisse nicht zustimmen kann. Ich bin daher gezwungen, einzelne Bereiche nur oberflachlich darzustellen und konkrete Schritte und Resultate auBen vor zu lassen. Die einzelnen Ausfiihrungen seien daher als Anregungen zu verstehen. Vielen Dank fur Ihr Verstandnis.

Kapitel 2 Der Unified Process

In diesem Kapitel wird der Unified Process vorgestellt. Die Beschreibungen be- rufen sich im Wesentlichen auf den ursprunglich 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 Pro­cess.

2.1 Uberblick

Zur Einfuhrung sei zunachst hingewiesen auf die geschichtliche Entwicklung des Prozesses und auf die bereits erwahnte Auspragung als konkretes Produkt der Firma Rational. Im Anschluss wird ein grober Uberblick des Unified Process ge- geben, um mit diesen grundlegenden Basiskenntnissen in die detaillierten Erlaute- rungen der nachfolgenden Abschnitte einsteigen zu kaonnen.

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 Architektur- beschreibung und erste Ansaatze komponentenbasierter Entwicklung finden. Ivar Jacobson war Erfinder dieser Entwicklungsmethode und verfeinerte sie liber viele Jahre hinweg zu einem Softwareentwicklungsprozess, bis er 1987 Ericsson verliefi und in Stockholm die Firma Objectory AB grundete. Zwischenzeitlich wurde im Jahre 1976 von der CCITT^[7] 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 verdrangt 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^[8] Konferenz 1987 erstmals namentlich vorgestellt, Diagrammtechniken wurden entwickelt, und die Use Cases wurden integraler Be- standteil des Objectory Process.

Im Fruhjahr 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 Ra­tional entwickelt worden waren. Zur gleichen Zeit etwa entstand die Unified Mo­deling Language. Grady Booch war schon seit den fruhen Anfangen bei Rational beschaftigt und hatte Anfang der 90er Jahre die Booch-Methode entwickelt. Ja­mes 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^[9] als Quasi-Standard veroffentlicht wurde. Im Ratio­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 unterstutzte. Viele Beitrage, Konzep- te 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 Namensanderung und wurde im Juni 1998 als der Rational Unified Process 5.0 veroffentlicht. Das Wort ’unified’ sollte die Vereinheitlichung von Ansatzen, Methoden und Konzep- ten ausdruacken, 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 Aktenschranken, 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 weiterent- wickelt wird, erhalten Lizenznehmer regelmafiige Updates und Erweiterun- gen. 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 konnen somit mit jedem Internetbrowser betrachtet wer- den. Fur die Navigation durch die Seiten existiert weiterhin ein Java-Applet, welches am linken Rand der Dokumente einen Navigationsbaum bereitstellt (siehe Abb 2.1).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Der Rational Unified Process prasentiert sich als Web-Dokument

- Durch die Webtechnologie lassen sich in den Navigationsbaum oder in die Dokumente selbst weitere Links einfugen, die auch zu externen Dateien oder Programmen verweisen konnen. Der Prozess lasst sich somit an die Bedurf- nisse des Unternehmens anpassen. Die Flexibilitat einer solchen Online- Version ist mit einer Dokumentation in Papierform nur schwer zu erreichen.
- In dem Prozess versprechen Tool-Mentoren Unterstutzung bei der Erstel- lung der geforderten Artefakte^[10]. Naturlich werden hier vorwiegend die Pro- dukte aus dem Hause Rational mit einbezogen.
- Vorlagen (Templates) fur Artefakte sind auch fur Microsoft-Applikationen wie Word, FrontPage und MS Project verfugbar, wodurch die Windows- Plattform als Ursprung erkennbar wird. Rational entwickelt jedoch seit ei- niger Zeit auch fur die Unix- bzw. Linux-Plattform.
- Nicht unerwahnt soll bleiben, dass fur dieses Produkt naturlich eine Lizenz- gebuhr erhoben wird. Da es keinerlei Funktionalitaten beherrscht, die mit einem Softwareprogramm vergleichbar waren, sind die Ausgaben — vergli- chen mit einem Satz herkommlicher Fachbucher — relativ hoch, zumal fur

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Ein Softwareentwicklungsprozess

jede Arbeitsstation eine extra Lizenz benotigt wird.

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

2.1.3 Der Unified Process in Kurze

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

Merkmale

Zunachst einmal ist der Unified Process ein Softwareentwicklungsprozess. Solch ein Prozess beschreibt die Menge aller Aktivitaten, die notwendig sind, um die Anforderungen des Anwenders in ein Softwaresystem zu transformieren (siehe Abb. 2.2). Der Unified Process geht jedoch dariiber hinaus. Er bildet ein generi- sches Rahmenwerk, das in vielfaltiger Art und Weise angepasst werden kann. Je nach Art des zu entwickelnden Softwaresystems, Unternehmenstyp, Kompe- tenzbasis oder Projektgrobe lassen sich unterschiedliche Auspragungen des Pro­zesses instanziieren. Er ist komponentenbasiert und verwendet die Unified Mo­deling Language (UML) als integralen Bestandteil zur visuellen Modellierung. Sei­ne 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.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3: Die zweidimensionale Strukur des Unified Process

Struktur

Vom Start bis zum Ende eines Projektes durchlauft der Unified Process einen Zy- klus, 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 abschliefien, der eine bestimmte Menge von Artefakten in einem vorher festgelegten Zustand definiert. Jede Phase ist wie- derum aufgeteilt in einzelne Iterationen, in der jeweils alle Disziplinen (siehe Abschnitt 2.5) durchlaufen werden. Diese bilden die zweite Dimension der Pro- zessstruktur und gruppieren zusammengehorige Aktivitaten. 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 verkoarpert somit eine Stellenbeschreibung innerhalb des Prozesses.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.4: Personen und Rollen

Personen schlupfen in eine bestimmte Rolle und sind damit verantwortlich fur eine Menge von Artefakten, die durch entsprechende Aktivitaten erzeugt oder modi- fiziert werden. Der Begriff umschreibt also den ,,Hut“, den eine Person wahrend bestimmter Aktivitaten tragt. Dabei kann eine Person im Projektverlauf auch mehrere Hute tragen; es herrscht gewissermafien 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 ausubt^[11].

2.2.2 Aktivitaten (wie)

Aktivitaten (engl. activity) sind Rollen zugeordnet und umschreiben die Tatig- keit, die eine Person in dieser Rolle ausfuhren soll, um ein fur das Projekt sinn- volles Ergebnis zu erhalten. Das Resultat einer Aktivitat ist ublicherweise die Erstellung oder Uberarbeitung eines Artefaktes, wobei in der Regel andere Ar- tefakte als Input verwendet werden. Somit verfolgt eine Aktivitat immer eine klar definierte Zielsetzung. Die Bearbeitungsdauer liegt dabei zwischen einigen Stunden und mehreren Tagen. Oft sind Aktivitaten in einzelne Schritte (steps)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.5: Eine Aktivitatsbeschreibung mit ihren Schritten (steps)

aufgeteilt, um die Ubersichtlichkeit und Klarheit zu erhohen. Man differenziert hierbei zwischen drei Kategorien:

- Denkschritte: Die Rolle sammelt die benOtigten Eingangsartefakte und ent- zieht daraus Informationen, um das Ausgangsartefakt zu formulieren.
- Durchfuhrungsschritte: Die Rolle erzeugt oder andert Artefakte.
- Review-Schritte: Die Rolle evaluliert die Ergebnisse anhand von zuvor de- finierten Kriterien.

Das Beispiel in Abbildung 2.5 zeigt die Beschreibung der Aktivitat ’Finde Akteure und Anwendungsfalle’ aus der Requirements-Disziplin. Man sieht hier, dass der Systemanalytiker diese Aufgabe in insgesamt sieben Schritten vollziehen kann. Dabei sind nicht zwingend alle Schritte bei jedem Ausftihren der Aktivitat zu durchlaufen; sie verstehen sich eher als Hilfen, den Arbeitsablauf innerhalb der Aktivitaat zu strukturieren.

2.2.3 Artefakte (was)

Artefakte (engl. artifact) dienen Aktivitaten als Input und entstehen als Out­put von Aktivitaten. Im objektorientierten Jargon sind Artefakte Parameter und Rtickgabewerte der Methoden (Aktivitaten) aktiver Objekte (Rollen). Artefakte werden wahrend des gesamten Projektes genutzt und spater zum Grofiteil an den Kunden ausgeliefert. Der eigentliche Programmcode bzw. das fertige Programm ist dabei nur ein Bestandteil. Viele Diagramme, Modelle und Dokumente zahlen ebenso dazu. Artefakte sind somit die Arbeitsprodukte des Prozesses^[12]. Rollen verwenden sie, um ihre Aktivitaten auszufuhren, woraus wieder andere Artefakte erzeugt oder verandert werden. Die Verantwortlichkeit eines Artefakts ist einer Rolle eindeutig zugeordnet. Dadurch wird deutlich, dass jeder Teil des Prozesses bezuglich seiner Zustandikeit klar definiert ist. Obwohl das Artefakt einer Person zugeordnet ist, durfen andere es modifizieren, wenn sie dazu speziell berechtigt sind.

Artefakte konnen in verschiedenen Formen auftreten. Ein Modell wie das De- signmodell enthalt noch andere Modellelemente wie z.B. Designklassen oder Teilsysteme. Viele Artefakte treten aber auch in Form einfacher Dokumente auf, die bspw. den Business Case definieren oder die Softwarearchitektur be- schreiben. Auch Auspragungen dieses Artefakttyps konnen sich aus mehreren Artefakten zusammensetzen. So besteht der Softwareentwicklungsplan aus einer Reihe weiterer Plane, die jeder fur sich ein Artefakt darstellen.

Artefakte sind nicht typischerweise Dokumente. Im Gegensatz zu vielen anderen Prozessen^[13] versucht der Rational Unified Process eine systematische Produktion von Papierdokumenten zu unterbinden. Dieses Konzept funktioniert jedoch erst bei Verwendung entsprechender Werkzeuge^[14]. Sofern mbglich, sollten alle Doku­mente mit dem Tool gewartet werden, mit dem sie auch erstellt werden. Papier- ausdrucke sind dann nur in Form von ’Schnappschdssen’ nbtig, die durch das

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.6: Workflow Requirements und Workflow Detail Analyze the Problem Programm automatisch generiert werden. Die Tools sollten so beschaffen sein, dass ein Informationsaustausch nicht zwingend liber Papier erfolgen muss. Somit sind die Dokumente stets aktuell, und es entsteht kein zusatzlicher Aufwand fur die Informationsweitergabe.

2.2.4 Workflows (wann)

Erst die Workflows erwecken den Prozess zum Leben, indem sie beschreiben, wie die einzelnen Aktivitaten zu sinnvollen Artefakten fuhren und wie die Rollen dabei interagieren. Ein Workflow ist genau einer Disziplin (siehe Abschnitt 2.5) zugeordnet und wird im Unified Process mit Hilfe der Aktivitatsdiagramme aus der UML dargestellt (siehe Abb. 2.6 links). Die farbig dargestellten Aktivitaten^[15] dieses Diagramms werden als Workflow Details bezeichnet. Sie gruppieren je- weils Aktivitaten^[16], die in engem Zusammenhang stehen, gemeinsam ausgefuhrt werden oder ein relevantes Zwischenergebnis liefern (siehe Abb. 2.6 rechts). Hier konnen auch Beziehungen zu anderen Disziplinen verdeutlicht werden. Eine so
feine Detailstufe wiirde in dem Workflow selbst nur verwirren. Die Workflow De­tails bilden daher eine sinnvolle Verfeinerungsebene zu den Workflows. Sie sind die entscheidenden Informationsquellen des Prozesses.

2.2.5 Weitere Prozesselemente

Berichte

Zu einem Modell oder einem Modellelement kann ein Bericht (engl. report) geha- ren, der bestimmte Informationen enthalt, die durch ein Tool extrahiert wurden. Im Gegensatz zu Artefakten unterliegen Berichte nicht der Versionskontrolle. Sie konnen jederzeit neu generiert werden.

Richtlinien

Wahrend die Beschreibungen der Aktivitaten (s. Abb. 2.5, S. 17) kurz und konkret gehalten sind, um einen schnellen Uberblick zu geben, unterstutzen die Richtlinien (guidelines) das Verstandnis, indem sie detaillierte Regeln, Empfehlungen oder methodische Anleitungen bereitstellen. Im Folgenden sind verschiedene Gruppen von Richtlinien aufgefuhrt. Um die Wiedererkennung im RUP zu erleichtern, werden die englischen Begriffe verwendet.

- Modeling Guidelines legen fest, wie bestimmte Modellierungselemente wie Use Cases, Klassen oder Testfalle zu beschreiben sind.
- Programming Guidelines beschreiben Konventionen, die bei der Pro- grammierung eingehalten werden sollen. Die Richtlinien beziehen sich dabei meist auf spezielle Sprachen wie Java oder C++.
- User-Interface Guidelines spezifizieren, wie Benutzerschnittstellen zu erstellen sind.
- Work Guidelines beschreiben Techniken, die beim Ausfuhren bestimmter Aktivitaten in einer Gruppe nutzlich sein kannen. Neben Techniken wie Brainstorming und verschiedenen Diagrammtechniken werden auch diverse Workshop-Typen erlautert.
- Tool Guidelines helfen bei der Verwendung von Tools, indem sie deren Bedienung und Funktionalitat beschreiben.
- Checklisten fur Artefakte helfen, wichtige Details nicht zu tibersehen.

Manche Richtlinien mussen an das Unternehmen oder sogar fur jedes Projekt neu angepasst werden. Besonders trifft dies zu bei Richtlinien, die das aufiere Erscheinungsbild des Systems betreffen, wie die User-Interface Guidelines oder Richtlinien fur die Erstellung des Benutzerhandbuchs (Manual Styleguide). Oft fallen aber auch Programmierrichtlinien darunter, die vom Kunden vorgegeben werden.

Vorlagen

Unter Vorlagen (templates) werden Prototypen von Artefakten verstanden, die zur Erstellung der Artefakte verwendet werden. Die im RUP verfugbaren Vor­lagen sind in HTML verfugbar oder fur die Windows-Applikationen Microsoft Word, Microsoft Project, Adobe Framemaker und Rational SoDA. Die Vorlagen sind jedoch fur ein Unternehmen so kaum verwendbar, sondern mussen sowohl layout-technisch als auch inhaltlich an die Beduurfnisse des Unternehmens ange- passt werden.

Tool-Mentoren

Fuur die Ausfuuhrung der einzelnen Aktivituaten geben die Tool-Mentoren uner- fahrenen Anwendern Anleitungen zur Verwendung der entsprechenden (Ratio­nal -)Programme. Jedes Unternehmen kann die Unterstutzung fur weitere Pro­gramme nach ihren Bedurfnissen erweitern. Es sei zu beachten, dass auch die Tool-Mentoren nur eine textuelle Hilfe bieten, obwohl der Name vielleicht eine interaktive Unterstutzung vermuten liefie.

Konzepte

Spezielle Terme und Konzepte (engl. concept) wie Iteration, Risiko, Anforderung, Traceability und weitere sind in separaten Abschnitten erortert und den entspre­chenden Disziplinen zugeordnet.

[...]

---

^[1] Die Unternehmen der primaren Softwarebranche wie DV-Dienstleister und Hersteller von Datenverarbeitungsgeraten und -einrichtungen finden eine Abgrenzung zu den Anwendungs- branchen, die als sekundare Softwarebranchen bezeichnet werden. Dazu zahlen Unternehmen aus den Bereichen Maschinenbau, Elektrotechnik, Fahrzeugbau, Telekommunikation und Fi- nanzdienstleistungen. Software entsteht somit als eigenstandiges Produkt (Primarbranche) oder eingebettet in Produkte oder Dienstleistungen (Sekundarbranche).

^[2] Ubersetzung ins Deutsche von Cornelia Versteegen aus [Kru99]

^[3] Man redet hier von Legacy-Software.

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

^[5] So werden weitlaufig die Urvater des Prozesses betitelt. Namentlich sind dies Ivar Jacobson, Grady Booch und James Rumbaugh. Die Spezifikation der Unified Modeling Language ist ihnen ebenfalls zuzuschreiben.

^[6] Als Tailoring bezeichnet man die Streichung bestimmter Prozesselemente zur Erlangung eines erhohten Schlankheitsgrades.

^[7] Das Consultative Committee for International Telegraph and Telephone war bis Juni 1994 ein Untergremium der International Telecommunication Union (ITU), speziell fur das Fern- meldewesen, das verschiedene Empfehlungen und Schnittstellen zur Dateniibertragung uber offentliche Netze verabschiedet hat. Die CCITT-Empfehlungen werden heute mit ITU-T be- zeichnet.

^[8] Die OOPSLA ist seit 1986 eine der wichtigsten Konferenzen im Bereich Objektorientierung und steht fur object-oriented programming, systems, languages, and applications.

^[9] Die Object Management Group (OMG) ist ein nicht-kommerzielles Konsortium verschie- denster grofier und kleinerer Firmen, das sich zur Aufgabe gestellt hat, auf Kompatibilitat und Vereinheitlichung zielende Industriespezifikationen fur den Softwarebereich herauszugeben. Ne- ben der UML zahlt hierzu auch die von der OMG selbst entwickelte CORBA-Architektur.

^[10] Dokumente, Modelle und andere Ergebnisse von Aktivitaten werden als Artefakte bezeich- net. Sie werden in Abschnitt 2.2.3 nahergehend beschrieben.

^[11] Bis RUP 2001 v3.0 hiefien 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.

^[12] Der Begriff Artefakt wird im RUP verwendet. In anderen Prozessen findet man Terme wie work produkt oder work unit zur Beschreibung desselben Sachverhalts.

^[13] vgl. bspw. das V-Modell

^[14] Natiirlich bietet Rational Programme fur jegliche Bereiche des Unified Process an, die den Prozess optimal unterstutzen sollen. Hier gibt es bspw. das bekannte Rational Rose fur die Erstellung und Verwaltung von Modellen nach der UML oder Rational Requisite Pro, welches das Management der Anforderungen ubernimmt.

^[15] hier verstanden als UML-Elemente der Aktivitatsdiagramme

^[16] hier wieder im Sinne der activities des Prozesses