Untersuchung der Traceability Vorgaben in ausgewählten Prozessen der Softwareentwicklung

Transkript

1 Friedrich Alexander Universität Erlangen Nürnberg Institut für Informatik Lehrstuhl für Programmiersysteme Untersuchung der Traceability Vorgaben in ausgewählten Prozessen der Softwareentwicklung Studienarbeit im Fach Informatik vorgelegt von Chuanru Ma Prüfer: Prof. Dr. Michael Philippsen Betreuer: Dipl. Inf. (FH) Josef Adersberger Beginn der Arbeit: Abgabe der Arbeit:

2 Erklärung Ich erkläre hiermit, die vorliegende Studienarbeit selbständig verfasst zu haben. Die verwendeten Quellen und Hilfsmittel sind im Text kenntlich gemacht und im Literaturverzeichnis vollständig aufgeführt. Erlangen, den Unterschrift 2

3 Inhaltsverzeichnis 1 Einleitung 1.1 Motivation Ziel der Arbeit Aufbau der Arbeit Grundlagen 2.1 Vorgehensmodelle in der Softwareentwicklung Warum Rational Unified Process? Verfolgbarkeit von Arbeitsergebnissen Traceability Extraktion der Traceability Vorgaben 3.1 Vorgehensbeschreibung der Extraktion Arten von Traceability Vorgaben in Vorgehensmodellen Geforderte Artefakte aus RUP Artefakt Verbindungen (Traceability Links) Konsistenzregeln (Traceability Rules) Modellierung der Traceability Vorgaben 4.1 Modellierung von Softwareentwickungsprozessen SPEM 2.0 Standard Erweiterung des SPEMs espem Ergebnisse des RUP Traceability Modells Produkt Artefakt Diagramme Prozess Artefakt Diagramme

4 5 Zusammenfassung und Ausblick 5.1 Zusammenfassung der Arbeit Hauptprobleme der Arbeit Ausblick Abbildungsverzeichnis Literaturverzeichnis 4

5 Kapitel 1 Einleitung 1.1 Motivation Business Software Systeme sind hoch komplex und werden schnell verändert. Änderungen führen dazu, dass das Softwareprodukt ein großes Risiko trägt, wie z.b. fehlende Abhängigkeiten zwischen Produktelementen oder unvollständige Implementierung des Programmcodes. Die Entwicklungsprozesse bzw. modelle müssen im ganzen Software Lebenszyklus nach und nach berücksichtigt und ständig verändert werden. Viele Prozess und Reifegradmodelle enthalten Aussagen und Forderungen in Bezug auf die Verfolgbarkeit von Arbeitsergebnissen im Entwicklungsprozess. Diese Verfolgbarkeit wird als Traceability bezeichnet. Die meisten Entwicklungsprozesse wie z.b. Rational Unified Process unterstützen die Verfolgbarkeit. Aber diese Traceability Vorgaben sind oft querschneidend im Modell verteilt und nur wenig formal beschrieben. Dazu ist eine formale und grafisch übersichtliche Verfolgbarkeit erwünscht. 1.2 Ziel der Arbeit Ziel der Arbeit ist es, die Vorgaben in Bezug auf die Verfolgbarkeit in ausgewählten Prozessen der Softwareentwicklung zu untersuchen, eine Evaluierung vorhandener Vorgehensmodelle zur Softwareentwicklung durchzuführen und abschließend ein konkretes Traceability-Modell des RUP zu modellieren. Dabei soll die Modellierung der Traceability mit Hilfe des, vom Lehrstuhl für Programmiersysteme entwickelten, PME-Werkzeuges in Artefakt Diagrammen dargestellt werden. 1.3 Aufbau der Arbeit Diese Arbeit gliedert sich im Wesentlichen in vier Teile. Grundlagen allgemeiner Vorgehensmodelle in der Softwareentwicklung und betroffene Begriffe werden im ersten Teil dieser Arbeit erläutert. In diesem Abschnitt wird auch auf die Begründung, warum schließlich in dieser Arbeit der Rational Unified Process ausgewählt wurde, eingegangen. Darüberhinaus werden das Schlüsselwort Traceability und weitere verwendete Begriffe in den Grundlagen erläutert. Teil zwei behandelt eine Vorgehensbeschreibung, um mit Hilfe eines Vorgehensmodells die Extraktion der Traceability-Vorgaben durchzuführen. Fokus dabei sind die drei Arten von Traceability Vorgaben: geforderte Artefakte, Artefakt Verbindungen und Konsistenzregeln. 5

6 Die Modellierung der Traceability Vorgaben wird im dritten Teil der Arbeit vorgestellt. Dabei soll die Modellierung mit Hilfe des SPEM 2.0 Standards und der Erweiterung des SPEM erfolgen. Die Ergebnisse des RUP Traceability Modells werden in diesem Teil formal in Artefakt Diagrammen dargestellt. Abschließend werden die Ergebnisse dieser Arbeit noch einmal zusammengefasst und ein Resümee gezogen. Dabei wird unter anderem auf Probleme eingegangen, welche während der Interpretation der Extraktions-Arbeitsergebnisse und der nachfolgenden Modellierung auftraten. Ein Ausblick über die nötige Weiterentwicklung weiterer Prozesse und Vorgehensmodelle der Softwareentwicklung schließt die Arbeit ab. 6

7 Kapitel 2 Grundlagen 2.1 Vorgehensmodelle in der Softwareentwicklung In der Softwareindustrie versucht der Entwickler die Software Produktqualität und Prozessqualität im ganzen Lebenszyklus ständig zu verbessern. Dabei spielen die Vorgehensmodelle in der Softwareentwicklung eine wichtige Rolle. In der Praxis existieren verschiedene Ausprägungen von Vorgehensmodellen, wie z.b. das Wasserfallmodell und das V Modell. Als Untersuchungsgegenstand in dieser Arbeit werden Softwareentwicklungsprozesse untersucht. Ausgewählte Prozesse werden nachfolgend vorgestellt. Rational Unified Process Der Rational Unified Process ist ein Softwareentwicklungsprozess, der aus dem Rational Objectory Process abgeleitet wurde. Das Ziel des RUP ist es hohe Softwarequalität zu garantieren und Software-Projektmanagement-Belange, wie Planung und Budgetkalkulation, zu berücksichtigen. Abbildung 1 stellt die Architektur des Rational Unified Processes dar. Der RUP wird durch drei wesentliche Strukturelemente beschrieben: Phases Iterations Workflows Abbildung 1: Architektur des RUP (Quelle: RUP, 2002) 7

8 Die iterative Entwicklung prägt die zeitliche Struktur des RUP. Ein Projekt wird im RUP in vier Phasen eingeteilt, welche aus einer oder mehreren Iterationen bestehen. Die Phasen geben Auskunft über den Reifegrad des Projekts und werden jeweils mit einem Meilenstein abgeschlossen. Die vier Phasen sind im Einzelnen : Inception: Die Konzeption Phase fokussiert auf die Ziele des Projekts. In der Phase wird die Projektvision zusammen mit einer ersten Risikoabschätzung erarbeitet. Und es soll eine Abschätzung von Kosten und Nutzen des Projekts sowie eine grobe Planung geben. Elaboration: Die Ausarbeitung Phase hat in der Hauptsache das Ziel, die Anforderungen des Projekts zu stabilisieren, eine Architektur zu definieren und die höchsten Risiken zu minimieren. Construction: Im Mittelpunkt der Konstruktion Phase steht das Entwickeln und Testen der Systemkomponenten. Das System wird basierend auf der Architektur komplettiert. Transition: Ziel der Übergang Phase ist der Übergang des Produkts zum Kunden. Neben dem Test des Produkts beim Anwender, Fertigstellung von Begleitmaterial und Datenkonvertierung aus Altsystemen im Vordergrund. [Kompakt] Das Strukturelement des Workflows wird in neun Aspekte untergliedert, die jeweils zusammengehörige Rollen, Aufgaben und Arbeitsergebnisse umfassen. In dieser Arbeit wird auf die Workflows fokussiert und diese Schritt für Schritt untersucht. Danach werden die Traceability Vorgaben extrahiert und zusammengefasst. Die einzelnen Workflows werden später in Kapitel 4.2 explizit beschrieben. SCRUM Scrum ist eine agile Methode zur Softwareentwicklung. Agilität bedeutet dabei ein iteratives Vorgehen und Feedback auf allen Ebenen im Entwicklungsprozess. Scrum ist klar strukturiert und durch definierte Rollen lässt sich der Prozess schnell einsetzen und ein schneller Softwareprodukt-Zyklus wird gewährleistet. Das Prozessablauf ermöglicht es, dass alle betroffenen Projektteams sich so oft wie möglich treffen und gleichzeitig Feedback bekommen. Der Scrum Prozess besteht aus sechs Rollen, sechs Meetings und neun Artefakten. Es beginnt mit der Person, die eine Idee für ein Produkt hat. Die Idee nennt man in Scrum ein Product Backlog Item. Alle Product Backlog Items von allen Personen werden in eine Liste geschrieben: Das ist das Product Backlog. Als Nächstes muss jedes Product Backlog Item auf seine Größe geschätzt werden. Die Schätzung wird von den Teammitgliedern durchgeführt, damit haben alle Teammitglieder eine Vorstellung davon, wie das gewünschte Produkt aussehen soll. 8

9 Oft schließt sich nun in Organisationen eine Genehmigungsphase an, woraufhin das Projekt genehmigt ist und das Projekt-Team die Arbeit aufnehmen kann. Das Team entwickelt erste Vorstellungen davon, wie sie die Anforderungen umsetzen wollen. Allen Beteiligten wird somit verdeutlicht, was zu tun ist. Daraus entsteht eine Liste von Aufgaben: Das Sprint Backlog. Das Sprint Backlog ist also eine Liste aller Aufgaben, die das Team ausführen muss, um die geforderten Backlog Items umzusetzen. Als Nächstes beginnt die Umsetzung, also das Entwickeln des Produktes. Die Teammitglieder stimmen täglich ihre Aufgaben untereinander in einem sogenannten Every 24h Meeting ab. In diesem Meeting bestimmen die Teammitglieder selbst, welche Aufgaben des Sprint Backlog, sie abarbeiten wollen. Im Scrum wird in klar abgegrenzten zeitlichen Intervallen gearbeitet. Dieses zeitliche Intervall nennt man im Scrum 30 days Sprint. Während des Sprints bereiten die Teammitglieder die nächsten Sprints vor. Das Product Backlog wird aktualisiert und es werden für neue Backlog Items neue Schätzungen erstellt und gegebenenfalls aktualisiert. Am Ende des Sprints wird die vom Team fertig gestellte Funktionalität und der Fortschritt des Projektes anhand von lieferbarer Software demonstriert. Die Demonstration führt in der Regel zu neuen Ideen und zeigt deutlich, wo die Produkt Entwicklung steht. Der Scrum Prozess wird graphisch in Abbildung 2 dargestellt. Nach [Scrum] Abbildung 2: Scrum-Prozess (Quelle: 9

10 Extreme Programming (XP) Kent Beck hat Mitte der 90 er erstmals XP formuliert. Er bezeichnet Kommunikation, Einfachheit, Feedback und Mut als die vier Grundprinzipien von XP. XP beinhaltet eine Reihe von Regeln und Aufgaben (Practices). Die 12 Practices werden in der Abbildung 3 explizit dargestellt. Extreme Programming ist ein leichtgewichtiger Prozess und somit für kleine bis mittelgroße Teams gut geeignet. Das Team kann in der Praxis zwischen zwei bis etwa 15 Entwicklern variieren. Weil nur wenige Beteiligte benötigt werden, wirkt sich dies positiv auf das Personal- und Zeitmanagement aus. Mit Hilfe von XP lassen sich auch Projekte, die unklare oder sich stark ändernde Anforderungen haben, durch Verwendung von Kommunikation und Feedback, zügig abschließen. Extreme Programming lässt sich den leichtgewichtigen Prozessen zuordnen, weil die Zahl der Arbeitsergebnisse, die außer dem Code entstehen, sehr gering ist. Das Team kann sich mehrheitlich auf die Codierung konzentrieren, weil formalen Entwicklungsschritten ein geringerer Stellenwert eingeräumt wird. Abbildung 3: XP Prozess (Quelle : ) 10

11 Feature Driven Development (FDD) FDD ist eine agile Methode, die sich deutlich von Scrum und XP unterscheidet und deshalb in vielen Organisationen eine gute Alternative darstellt. Im Mittelpunkt von FDD steht der Feature Begriff: Jedes einzelne Feature stellt einen Mehrwert für den Kunden dar, und die Softwareentwicklung wird durch die Features gesteuert. In FDD Projekten sind die folgenden fünf Prozesse vorgesehen: 1. Entwicklung eines Gesamtmodells Fachexperten und Entwickler definieren unter Leitung des Chefarchitekten Inhalt und Umfang des zu entwickelnden Systems. In Kleingruppen, die jeweils aus einem Fachexperten und zwei bis drei Entwicklern bestehen, werden Fachmodelle für die einzelnen Bereiche des Systems erstellt, in der Gesamtgruppe vorgestellt, ggf. überarbeitet und schließlich integriert. Das Ziel dieser ersten Phase ist es, einen Konsens über Inhalt und Umfang des zu entwickelnden Systems herzustellen sowie das fachliche Kernmodell zu erarbeiten. Für die Modellierung wird meistens Color Modeling verwendet. 2. Erstellung eine Feature Liste Die Chefprogrammierer detaillieren die im Gesamtmodell festgelegten Fachgebiete in Features. Dazu wird ein dreistufiges Schema verwendet: Fachgebiete bestehen aus Geschäftstätigkeiten, die durch Schritte ausgeführt werden. Die Schritte entsprechen den Features. Features werden sehr prägnant nach dem einfachen Schema <Aktion> <Ergebnis> <Objekt> beschrieben, z.b. Berechne Gesamtsumme der Verkäufe. Die Realisierung eines Features darf maximal zwei Wochen benötigen. Die meisten Features dauern jedoch nur wenige Stunden oder Tage. Das Ergebnis dieses Prozesses ist eine kategorisierte Feature Liste. 3. Planung der Feature-Realisierung Der Projektleiter, der Entwicklungsleiter und die Chefprogrammierer planen die Reihenfolge, in der Features realisiert werden sollen. Dabei richten sie sich nach den Abhängigkeiten zwischen den Features, der Auslastung der Programmierteams sowie der Komplexität der Features. Auf Basis dieses Plans werden die Fertigstellungstermine je Geschäftsaktivität festgelegt. Jede Geschäftsaktivität bekommt einen Chefprogrammierer als Besitzer zugeordnet. Außerdem werden für die bekannten Kernklassen Entwickler als Besitzer festgelegt. Auf dieser Basis werden Feature Pakete geschnürt und durch temporäre Feature Teams realisiert. 4. Entwurf der Features Die Chefprogrammierer weisen die anstehenden Features den Entwicklerteams auf Basis des Klassenbesitztums zu. Die Entwicklerteams ergeben sich also dynamisch je Feature aus den Klassenbesitzern der zugehörigen Klassen. Diese Feature Teams erstellen gemeinsam ein oder mehrere Sequenzdiagramme für die Features, und die Chefprogrammierer verfeinern die Klassenmodelle auf Basis der Sequenzdiagramme. 11

12 Die Entwickler schreiben dann erste Klassen und Methodenrümpfe. Schließlich werden die erstellten Ergebnisse gemeinsam zur Qualitätssicherung systematisch inspiziert. Bei fachlichen Unklarheiten können die Fachexperten hinzugezogen werden. 5. Konstruktion der Features Die Entwickler programmieren die im vorigen Prozess entworfenen Features. Bei der Programmierung werden Codeinspektionen und Komponententests zur Qualitätssicherung eingesetzt.»entwirf«und»konstruiere«werden je Feature nacheinander durchlaufen, sodass sie in der Praxis ineinander übergehen. Damit laufen in einem Projekt in der Regel viele dieser Prozesse gleichzeitig, weil Features parallel abgearbeitet werden. Im Gegensatz zu anderen agilen Methoden fällt auf, dass es für Entwurf und Konstruktion der Features kein Iterationskonzept gibt. Das ist der vorlagerten Modellierung und einer Vorstellung von Festpreisprojekten geschuldet. Eine kundengetriebene Umplanung der Inhalte zur Projektlaufzeit ist nur in sehr geringem Maße möglich. Eine inkrementelle Auslieferung ist bei passender zeitlicher Planung der Einzelfeatures jedoch problemlos machbar und auch erwünscht. [FDD] Abbildung 4: Feature Driven Development 12

13 2.2 Warum Rational Unified Process? Die vier oben genannten Vorgehensmodelle RUP, SCRUM, XP und FDD wurden als mögliche Modelle in Betracht gezogen. Die Entscheidung fiel auf RUP, welcher in dieser Arbeit Verwendung findet. Entscheidungskriterien für RUP werden im Folgenden beschrieben. Der Rational Unified Process weist eine hohe und rasch anwachsende Verbreitung in den letzten Jahren auf. So wird er nicht nur durch IBM Rational Software bei ihrer großen Kundenbasis eingesetzt, sondern ist auch bei vielen Consultingunternehmen und Dienstleistern beliebt. Diese große Verbreitung macht den RUP zum Quasi Standard, sodass viele Mitarbeiter mit dem eingesetzten Prozess bereits vertraut sind. [Kompakt] Eine von mir durchgeführte Untersuchung der Vorgehensmodelle zeigte, dass RUP der am detailliertesten und klarsten beschriebene Softwareentwicklunsprozess ist. Einerseits erschließen sich beim RUP die einzelnen Schritte des Gesamtprozesses detaillierter aus der der entsprechenden Literatur und der Prozessdokumentation. Andererseits sind die neun Workflows klar strukturiert, womit sich leicht ein Traceability Model erzeugen lässt, was im Zuge dieser Arbeit erfolgte. Dies macht den Rational Unified Process zu einer geeigneten und effektiven Basis, auf deren Grundlage die Traceability Vorgaben ermittelt und modelliert werden. Im Vergleich zu RUP sind die agilen Prozesse deutlich weniger dokumentiert. Das hängt natürlich auch mit der Haupteigenschaft der Agilität zusammen: Die Schnelligkeit und Flexibilität der Prozesse. Beispielsweise bietet Scrum nur neun geforderte Artefakte. Im Vergleich dazu werden im RUP umfangreiche 142 Artefakte angeboten. Die geforderten Artefakte in RUP werden später in Kapitel explizit erläutert. 13

14 2.3 Verfolgbarkeit von Arbeitsergebnissen Traceability Traceability is the ability to follow and recover the development steps of a system based on the connection between inputs or stimuli of every development step with its products. These products, later called artefacts, are the inputs of next development steps. This leads to a graph of dependencies, which shows the realization of the systems requirements within the developed system. [Link] Das Schlüsselwort Traceability wird in dieser Arbeit als Verfolgbarkeit in Deutsch übersetzt. Verfolgbarkeit ist eine Fähigkeit, mit welcher man die Software im Laufe des gesamten Entwicklungsprozesses verwalten kann. Das Ziel der Verwaltung ist es, die Abhängigkeiten oder Beziehungen zwischen den Modulen bzw. Produkten formal und zentral darzustellen, damit der Entwickler bzw. Benutzer mehr Übersicht und Verständnis über den gesamten Entwicklungsprozess erhält. Die Verfolgbarkeit von Arbeitsergebnissen ist als ein Traceability Modell in Artefakt Diagrammen Schritt für Schritt in dieser Arbeit dargestellt. Das Traceablity Modell ist eine formale Beschreibung der im Rahmen der Traceability berücksichtigten Artefakte und ihren Beziehungen (Traceability Links) zueinander. Abbildung 5 ist eine informelle Darstellung eines solchen Traceability Modells. Die Formalisierung des Traceability Modells erfolgt im Rahmen des Forschungsprojekts über die Definition einer Modellinfrastruktur auf Basis der UML (Unified Modeling Language, [OMG2007]). [Softwareleitstand] Abbildung 5: Informelles Traceability Modell 14

15 Die Modellinfrastruktur besteht aus einer Reihe von vordefinierten und mit einer klaren Semantik hinterlegten Link Typen. Abbildung 6 zeigt eine Übersicht über das Traceability Schema mit den verwendeten Traceability Link Typen in dieser Arbeit: Abhängigkeiten (Dependency): Damit werden zeitbezogene, ausführungsbezogene oder informationsbezogene Abhängigkeiten zwischen Artefakten beschrieben. Verfeinerungen (Refinement): Damit werden logische und technische Verfeinerungsbeziehungen zwischen Artefakten beschrieben. Assoziationen (Association): Damit werden logische Zusammenhänge zwischen Artefakten beschrieben. Containment: Damit werden Kapselungen und Eltern Kind Zusammenhänge zwischen Artefakten beschrieben. [Softwareleitstand] Abbildung 6: Traceability Link Typen 15

16 Kapitel 3 Extraktion der Traceability Vorgaben 3.1 Vorgehensbeschreibung der Extraktion Das Vorgehensmodell in dieser Arbeit wurde übersichtlich in der Abbildung 7 graphisch dargestellt. Im folgenden werden die drei Schritte Extraktion, Interpretation und Modellierung des Vorgehensmodells beschrieben. 1. Extraktion Als Ausgangspunkt ist eine detaillierte und klare Beschreibung des ausgewählten RUP Prozesses in dieser Arbeit wichtig. Nach einer umfangreichen Literaturrecherche unter Berücksichtigung wissenschaftlicher Veröffentlichungen wurden hier zwei Bücher als Grundlage festgelegt (Rational Unified Process Kompakt von Andreas Essigkrug & Thomas Mey [Kompakt] und The Rational Unified Process: An Introduction von Philippe Kruchten [Introduction]). Diese Quellen wurden schrittweise durchgearbeitet und nach geeigneten Passagen gesucht. Passende Passagen und geforderte Artefakte wurden zunächst in einer Excel Tabelle, mit der Bezeichnung Artefakt XLS (siehe Abbildung 7), eingetragen. Des Weiteren wurden die Artefakt Verbindungen (Traceability Links) und Konsistenzregeln (Traceability Rules oder Constraints) jeweils in die Tabellen Link XLS und Constraint XLS eingetragen. 2. Interpretation Als Eingaben dieses Schrittes dienen die Arbeitsergebnisse aus der Extraktion, d.h. die drei Tabellen Artefakt XLS, Link XLS und Constraint XLS. Dabei ist vor allem die Tabelle Link XLS in der Interpretation von Bedeutung. In dieser Tabelle werden die Beziehungen zwischen den Artefakten dargestellt, diese Beziehungen werden als Artefakt-Verbindungen (Traceability Links) bezeichnet. Dies ist die Voraussetzung für die anschließende Modellierung. Es muss geklärt werden, welche Beziehungen zwischen den Artefakten bestehen. Dazu wird ein Traceability Schema mit vordefinierten Link Typen verwendet, um die Artefakt-Verbindungen zu kategorisieren. Jede Beziehung wird durch die Definition des Link Typs (siehe Abbildung 6) festgelegt und in Link XLS eingetragen. Artefakte und Artefakt-Verbindungen müssen Konsistenzregeln (Traceability Rules) erfüllen, welche in der Constraint XLS Tabelle erfasst werden. 3. Modellierung Basierend auf der Interpretation werden nun alle Artefakt-Verbindungen und Konsistenzregeln mit Hilfe des Enactable Software and Systems Process Engineering Meta-Model (espem) modelliert. Darüberhinaus werden die Artefakte und ihre Beziehungen in die einzelnen Workflows des RUP eingebracht, indem die Artefakte nach Workflows sortiert und zugeordnet werden. Manche Artefakte und Artefakt-Verbindungen können dabei mehreren Workflows zugewiesen werden. Des 16

17 Weiteren werden die Beziehungen zwischen den einzelnen Workflows beschrieben und mit espem modelliert. Als Ergebnis der Modellierung wird das Traceability Modell als einzelne Artefakt Diagramme oder ein zusammengefasstes Diagramm dargestellt. Abbildung 7: Vorgehensmodell in dieser Arbeit 3.2 Arten von Traceability Vorgaben in Vorgehensmodellen In diesem Abschnitt werden die drei Arten von Traceability Vorgaben genauer definiert und jeweils mit Beispielen interpretiert. Folgende Definitionen und Beispiele basieren auf der Literatur [Kompakt] und [Introduction] Geforderte Artefakte aus RUP Zunächst eine genauere Einführung, was Artefakte sind. Das Wort deutsche Wort 'Artefakt' stammt aus dem englischen 'artifact'. Nachfolgend sind ein paar Definitionen aus der englischen und deutschen RUP Praxis-Literatur dargestellt. artifact A piece of information that is produced, modified, or used by a process, defines an area of responsibility, and is subject to version control. An artifact can be a model, a model element, or a document. [Introduction] Artefakte sind definierte Arbeitsergebnisse einzelner Aufgaben z.b. Quellcode, Modelle etc. und auch Dokumente, wobei diese nicht im Vordergrund stehen. [Kompakt] 17

18 Artefakt Ein Artefakt ist Grundlage oder Ergebnis einer Aktivität. Üblicherweise liegen Artefakte in Dateiform vor und können unter Versionsverwaltung gestellt werden. Beispiele sind: Sourcecode, ausführbarer Code, Modelle, Dokumente. [Kompakt] In dieser Arbeit wurde Artefakt wie folgend definiert: Artefakt Ein Artefakt ist ein Arbeitsergebnis des Softwareentwicklungsprozesses z.b. Dokumentation in Dateiform, Quellcode, Modell, Modellelement usw. Gemäß der obiger Definition ergibt sich, dass ein Artefakt nicht nur ein Dokument sein muss, sondern auch ein Arbeitsergebnis wie Quellcode, Modell und Modellelement sein kann. Auf Basis dieser Definition wurde die Prozessbeschreibung des RUP untersucht. Insgesamt wurden in den untersuchten Passagen 142 Artefakte gefunden. Nachfolgend sind ein paar Beispiele gelistet, welche die Schritte der Extraktion zeigen, um die Artefakte zu ermitteln. Beispiel 1 The key artifacts of business modeling are as follows: The business vision document: defines the objectives and goals of the business modeling effort. A business use case model: a model of the business s intended functions, used as an essential input to identify roles and deliverables in the organization. A business object model: an object model that describes the realization of business use cases. [Introduction, Seite 145] Dies ist ein nachvollziehbares und klares Beispiel. Das Schlüsselwort artifact kann rasch erkannt werden und die nachfolgend benannten Dokumente und Modelle können als Artefakte identifiziert werden. Folglich sind hier drei Artefakte dargestellt: Business Vision Document, Business Use case Model und Business Object Model. Diese drei Artefakte werden in die Artefakt XLS Excel Tabelle eingetragen. Beispiel 2 Auf die Erstellung eines kompletten Software Development Plan (SDP) wird in diesem Projekt verzichtet. Lediglich Teile daraus werden verwendet, konkret der Development Case und der Projektplan, der weiter unten beschrieben wird. Der Development Case beschreibt, welche Arbeitsergebnisse bis wann, wie weit fertig gestellt, werden sollen. Er ist deshalb so wichtig, weil er für ein bestimmtes Projekt die Auswahl der Arbeitsergebnisse beschreibt, die zusätzlich zum eigentlichen System erstellt werden sollen. Er ist also die konkrete Form der Anpassung des RUP zu einem Projekt und ermöglicht es, Soll und Istzustand des Projekts zu vergleichen. [Kompakt, Seite 76] 18

19 Das ist auch eine geeignete Passage, um Artefakte zu ermitteln. Im genaueren sind dies der Software Development Plan (SDP), der Projektplan und das Arbeitsergebnis Development Case. Die geforderten Artefakte werden weiter in Artefakt XLS eingetragen. Beispiel 3 Das nun folgende Beispiel unterscheidet sich von den obigen zwei Beispielen insofern, dass die zu ermittelnden Artefakte nicht mehr in Text-Passagen beschrieben wurden, sondern aus einem Workflow des RUP extrahiert wurden. Als Basis dient die in Abbildung 8 dargestellte RUP-Elementesammlung für den Business Modeling Workflow. Abbildung 8: Business Modeling Elemente (Quelle: [Introduction]) Aus der Elementesammlung lassen sich Artefakte identifizieren, welche als Dokumente in Dateiform dargestellt sind, wie z.b. Business Glossary, Business Vision usw. Darüberhinaus muss beachtet werden, dass manche Elemente nicht in Dateiform dargestellt werden, aber trotzdem Artefakte sein können. Beispiele hierfür sind Business Use Case Model und Business Use Case. Nach Überprüfung der Definition dieser beiden Artefakte im RUP können sie als Artefakte bestimmt werden. Die Definition lautet folgend: 19

20 A business use case model consists of business actors and business use cases. The actors represent roles external to the business (for example, customers), and the business use cases are processes. A business object model includes business use case realizations, which show how the business use cases are performed in terms of interacting business workers and business entities. [Introduction, Seite 146] Im Prinzip zeigen die obig genannten drei Beispiele, dass ein Konzept zur Ermittlung geforderter Artefakte in dieser Arbeit gefunden wurde. Durch ähnliches Vorgehen wurden insgesamt 142 Artefakte in der Extraktion ermittelt Artefakt Verbindungen (Traceability Links) Die Artefakt Verbindung basiert auf den geforderten Artefakten und der Excel Tabelle Artefakt XLS. Zur Unterstützung ist das Traceability Schema in diesem Abschnitt notwendig (siehe Abbildung 6 und 7). Mit jeder dargestellten Beziehung wird hier ein passender Link-Typ bestimmt und der entsprechende Link-Name eingesetzt. Der so ermittelte Link-Typ wird danach in die Excel Tabelle Link XLS eingetragen. Nach diesem Vorgehensmuster wurden insgesamt 81 Verbindungen in der Arbeit gefunden. Im Folgenden sind ein paar Beispiele hierfür genannt: Beispiel 1 The software development plan (SDP), which contains several artifacts: Product acceptance plan Risk management plan (and risk list) Problem resolution plan Measurement plan Other plans are part of the SDP, but they are developed by other workers. Here are two examples: 1. Configuration management plan, developed by the Worker: Configuration Manager 2. Development case (the process used for the project), developed by the Worker: Process engineer [Introduction, Seite ] Das Schlüsselwort contains beschreibt eine Beziehung zwischen dem Artefakt SDP und weiteren Plänen, welche auch wieder Artefakte darstellen. Gemäß den Link Definitionen in Kapitel 2.3 findet man den passenden Link Typ Containment heraus. Die Definition lautet: Containment: Damit werden Kapselungen und Eltern Kind Zusammenhänge zwischen Artefakten beschrieben. [Softwareleitstand] 20

21 Nun wird der Link Typ: Containment in die Excel Tabelle eingetragen und somit die Verbindung zwischen den betroffenen Artefakten dargelegt. Beispiel 2 Integration Build Plan This document defines the order in which the components and subsystems should be implemented and specifies the builds to be created when the system is integrated. [Introduction, Seite 189] Dieses Beispiel ist komplizierter zu bewerten. Eine Beziehung existiert zwischen den Artefakten Integration Build Plan und Components & Subsystems. Das Schlüsselwort um diese Beziehung zu definieren ist defines the order. Nach der Link Definition findet man den passenden Link Typ Informational Dependency heraus. Die Definition des Types lautet: Abhängigkeiten (Dependency): Damit werden zeitbezogene, ausführungsbezogene oder informationsbezogene Abhängigkeiten zwischen Artefakten beschrieben. [Softwareleitstand] Nun ist in dem Fall die Beziehung nicht nur durch eine allgemeine Abhängigkeit definiert, sondern zusätzlich auch durch den speziellen Fall in der informationsbezogenen Abhängigkeit definiert. Die Herausforderung dieses Beispiels ist das Verständnis der Formulierung der natürlichen Sprache. Diese Verständnis kann personenspezifisch ausfallen und zu unterschiedlichen Interpretationen führen. Des Weiteren kann auch die Übersetzung vom Englischen ins Deutsche zu andersartige Lösungen erzeugen. Also gibt es hier im Prinzip keine eindeutige Lösung, sondern mehrere alternative Lösungen stehen zur Auswahl. Das Problem liegt nicht nur am Leser des Dokumentes, sondern auch an der Beschreibung des Dokumentes selbst. Beispiel 3 zeigt eine weitere Schwierigkeit auf. Beispiel 3 A business object model: an object model that describes the realization of business use cases. [Introduction, Seite 145] Target organization assessment: describes the current status of the organization in which a system is to be deployed. [Introduction, Seite 145] In erster Aussage findet man das Schlüsselwort describes the realization. Nach der Definition wird hier eine Beziehung vom Link-Typ Realization eingesetzt. Aber in der zweiten Aussage ist das alleinige Schlüsselwort describes nicht sehr aussagekräftig, um den Link-Typ zwischen Target organization Assessment und Organization zu bestimmen. Es stellt sich die Frage, ob Organization überhaupt einem Artefakt zugeordnet ist. Da Organization nicht in der Artefakt XLS vorkommt, ist dies nicht der 21

22 Fall. Aber in der Abbildung 8: Business Modeling Elemente findet man eine Dateiform, mit der Bezeichnung Organization Unit, was ein Artefakt repräsentiert. Somit ergibt sich eine alternative Lösung: Eine Beziehung zwischen den Artefakten Target organization Assessment und Organization Unit. Eine zweite Frage ist, wie diese Beziehung definiert wird. Das Wort describes ist zu grob und unspezifisch, um einen Link-Typ zu ermitteln. Man kann nach der Definition keine eindeutige Lösung finden. Aber gemäß der Eliminieren Methode bestimmt man hier die alternative Lösung als eine Assoziation. Die Definition der Assoziation lautet: Assoziationen (Association): Damit werden logische Zusammenhänge zwischen Artefakten beschrieben. [Softwareleitstand] Probleme dieser Art existieren im Laufe der Interpretation dieser Arbeit relativ häufig. Oft bleibt es unklar, ob eine Beziehung ausreichend eindeutig bestimmt wurde und oft muss ein Kompromiss als Lösung gewählt werden. Das machte eine große Menge Arbeit allein in diesem Teil Konsistenzregeln (Traceability Rules) Als Erstes soll hier informiert werden, was unter Konsistenzregeln verstanden wird. Das Wort stammt aus dem englischen Bezeichnung Traceability Rules, ein anderes Wort aus dem Englischen, in diesem Kontext, ist Constraint. Constraint bedeutet in dieser Arbeit eine Bedingung, unter welcher eine Beziehung zwischen den Artefakten zustande kommt. Insgesamt sind 71 solcher Bedingungen in dieser Arbeit festgelegt worden. Ein paar Beispiele werden hier erklärt. Beispiel 1 The key needs and features are specified in the Vision document. [Introduction, Seite 167] Als eine Voraussetzung der Konsistenzregeln müssen die vorherigen Informationen über Artefakte und Links schon vorhanden sein, also eine Traceability Verbindung Containment zwischen den Artefakten Vision Document und Need & Feature existieren. Nun stellt sich die Frage, wie die Artefakt Namen Needs und Features, bewertet werden müssen. Formal sollten Artefakte immer im Singular vorliegen, was hier nicht der Fall ist. Um diese Frage zu beantworten, werden hier die Konsistenzregeln benötigt. Die Artefakte werden im Singular in die Artefakt XLS eingetragen und die Beziehung mit einem Constraint 1..n erweitert, um den ursprünglichen Plural semantisch zu erhalten. 22

23 Beispiel 2 The software development plan (SDP), which contains several artifacts: Product acceptance plan Risk management plan (and risk list) Problem resolution plan Measurement plan Other plans are part of the SDP, but they are developed by other workers. Here are two examples: 1. Configuration management plan, developed by the Worker: Configuration Manager 2. Development case (the process used for the project), developed by the Worker: Process engineer [Introduction, Seite ] Die gleiche Passage wie im Abschnitt zeigt einen Sonderfall auf, dass die zwei Artefakte Configuration Management Plan und Development Case zwar zum Artefakt SDP gehören, aber unter einer Bedingung, nämlich dass die zwei in anderen Workflows entwickelt worden sind. Dieser Sonderfall wird in der Arbeit als ein Constraint dargestellt. Die so ermittelten Bedingungen werden in die Excel Tabelle Constraint XLS eingetragen. Beispiel 3 The design model consists of collaborations of classes, which may be aggregated into packages and subsystems to help organize the model and to provide compositional building blocks within the model. [Introduction, Seite 175] Dieses Beispiel ähnelt Beispiel 1 und Beispiel 2, im Sinne dass sich eine Bedingung an die Artefakt Beziehung aus dem Text ergibt. Das Schlüsselwort may be beschränkt die Beziehung zwischen Class und Package. Es bedeutet, dass entweder eine Beziehung zwischen den Artefakten existiert, oder auch nicht. Diese Situation bezeichne ich als 0..n -Constraint. Die verwendeten Bezeichnungen für die Constraints in der Constraint XLS wurden in dieser Arbeit selbständig definiert, da vorher noch keine Bezeichnungen in der Praxis dafür existierten. In einer weiteren Modellierung im Kapitel 4 wurden solche Konsistenzregeln wie 0..1, 1..n und 0..n in PME als Kommentare dargestellt. Eine zusätzliche Bezeichnung 1 im Kommentar bedeutet dort, dass keine Bedingungen an die Beziehung der Artefakte gestellt werden musste. 23

24 Kapitel 4 Modellierung der Traceability Vorgaben 4.1 Modellierung von Softwareentwicklungsprozessen Die Traceability Vorgaben werden in diesem Kapitel mit Hilfe des SPEM und des entwickelten espem modelliert. Als Grundlage der Modellierung in dieser Arbeit werden hier zunächst die beiden Modellierungsansätze vorgestellt SPEM 2.0 Standard SPEM 2.0 ist die Abkürzung für das Software Process Engineering Metamodel Version 2.0. Es wird verwendet, um die Software zu definieren und den Entwicklungsprozess zu beschreiben. Ein Metamodell definiert, wie ein Prozessmodell strukturiert ist. Die SPEM 2.0 Struktur besteht aus 7 Paketen (Abbildung 9). Die Struktur gliedert das Metamodell in verschiedene Einheiten. Der Merge Mechanismus aus UML 2.0 unterstützt dabei die Pakete zu realisieren und tiefere Ebenen mit höheren Ebenen zu verbinden. Abbildung 9: Struktur des SPEM 2.0 (Quelle: [SPEM 2008]) Innerhalb der IBM gibt es allerdings viele verschiedene Vorgehensmodelle, die auch über die reine Softwareentwicklung hinausgehen. Mit dem Ziel einer einheitlichen Beschreibungsform für unterschiedlichste Vorgehensmodelle und höchstmöglicher Flexibilität wurde 2005 ein neues Metamodell, die Unified Method Architecture (UMA), als Grundlage des RUP eingeführt. Dieses Metamodell wurde mit Partnerunternehmen der OMG als Vorschlag zur Standardisierung in SPEM 2.0 eingereicht. 24

25 Grundprinzip der UMA ist eine deutliche Trennung von Methodeninhalten und ihrer Verwendung im zeitlichen Ablauf eines Prozesses. Methodeninhalte beschreiben Arbeitsergebnisse, was detailliert getan werden muss, um zu diesen Arbeitsergebnissen zu gelangen (unabhängig von zeitlichen Abhängigkeiten) und das erforderliche Know how. Die Prozessabläufe geben den Methodeninhalten eine zeitliche Abfolge und lassen eine Anpassung an unterschiedliche Projekttypen zu. Der folgende Punkt stellt die wesentlichen Prozesselemente und Methodeninhalte kurz vor. Weitere Punkte werden in der Abbildung 10: Method Framework dargestellt. Methodeninhalte: Rollen: Wer tut etwas? Arbeitsergebnisse: Was soll das Ergebnis sein? Aufgaben: Wie wird etwas getan? Prozesselemente: Aktivitäten: Sind die grundlegende Einheit, aus der Prozesse zusammengesetzt werden. Aktivitäten können hierarchisch gegliedert sein und andere Aktivitäten, Aufgaben, Rollen und Arbeitsergebnisse referenzieren. Prozessmuster: Beschreibt eine Gruppierung von Aktivitäten zu einer Prozesskomponente. Stellt aber noch keinen vollständigen Prozess dar. Bereitgestellter Prozess: Beschreibt einen konkreten Prozess, der in einem Projekt verwendet wird. [Kompakt] Abbildung 10: Method Framework (Quelle: [SPEM 2008]) 25

26 4.1.2 Erweiterung des SPEM espem Das espem Metamodel erweitert das SPEM Metamodel durch zusätzliche Pakete. Es unterstützt weiter das Softwaremodel und den Entwicklungsprozess. Und als eine Erweiterung des SPEM, fokussiert espem auf der Modellierung des Lebenszyklus. [espem] Abbildung 11: Struktur des espem (Quelle: [espem]) Die Struktur des espem mit zusätzlichen Paketen wird in der Abbildung 11 grafisch vorgestellt. espem basiert sowohl auf SPEM 2.0 wie auf UML 2.2. espem verwendet UML 2 zum Modellieren und wurde in Eclipse realisiert. Unter Eclipse wurde ein Modellierungsansatz Process Modelling Environment (PME) beim Lehrstuhl für Programmiersysteme in der Forschungsgruppe Praktische Softwaretechnik entwickelt. Das Werkzeug PME unterstützt espem und stellt sowohl einen Diagramm Editor zur Verfügung, als auch einen espem Model Editor für die Artefakte. [PME] Die Modellierung in dieser Arbeit verwendet das PME als eine Arbeitsoberfläche. Und zwar wird durch den Artefakt Diagramm Editor ein Artefakt Diagramm in jedem Workflow modelliert. Danach werden alle Artefakt Diagramme zusammengefasst. Schließlich wird das Ergebnis in dieser Arbeit als ein Traceability Modell dargestellt. 26

27 4.2 Ergebnisse des RUP Traceability Modells Mit der Hilfe des PME erzeugt man ein neues Projekt für RUP. Unter dem RUP liegen zwei vordefinierte Pakete, genannt RUP.espem und Trace.espem. Diese Pakete basieren auf espem Paketen und bieten alle Funktionen an, die in dieser Arbeit gebraucht werden, wie z.b. Traceability Link Typen. Nach der Konfiguration kann man mit dem Artefakt Diagramm Editor ein Artefakt Diagramm initiieren, darauf ein Work Product für ein Artefakt erzeugen und abschließend eine Beziehung als Traceability Verbindung definieren. Die Arbeitsoberfläche und das erzeugte Diagramm sehen folgendermaßen aus: Abbildung 12: Arbeitsoberfläche des PME Im nächsten Abschnitt werden die Traceability Vorgaben in Kapitel 3.2 extrahiert, um die einzelnen Artefakt Diagramme Schritt für Schritt zu modellieren. Die Diagramme werden in zwei Teile gegliedert. Ein Teil für Produkt Artefakt Diagramme sorgt dafür, dass die fünf Workflows in RUP jeweils als ein Modul modelliert werden. Und ein zweiter Teil für Prozess Artefakt Diagramme, welcher dann die übrigen Artefakte aufsammelt, welche den ganzen Prozess durchlaufen konnten. Die Darstellung von Klassen in UML Klassen Diagrammen ähnelt der Artefaktdarstellung im PME. Die Artefakt Verbindung wird als eine gerade Linie mit Pfeil, also eine definierte Link Richtung dargestellt. Für Konsistenzregeln existiert momentan noch keine explizite Darstellung oder Zeichnung, so dass hier auf Kommentarboxen zur Darstellung von Constraints zurückgegriffen wurde. 27

28 4.2.1 Produkt Artefakt Diagramme Der RUP gliedert sich im Methodeninhalt in neun Workflows, die jeweils zusammen gehörige Rollen, Aufgaben und Arbeitsergebnisse umfassen. In dieser Arbeit werden auf die Arbeitsergebnisse bzw. Artefakte der ersten fünf Workflows fokussiert, damit die Verfolgbarkeit ermöglicht wird. 1. Business Modeling Der erste Workflow des RUP ist die Geschäftsprozessmodellierung. Auch wenn dieser Workflow für manche Projekte als optional anzusehen ist, so sollte die Bedeutung nicht unterschätzt werden. Gerade im Sinne geschäftsorientierter Entwicklung ist Geschäftsprozessmodellierung ein wichtiges Bindeglied zur wirtschaftlichen Betrachtung des Nutzens von Softwareentwicklung. Wichtig ist dieser Workflow in erster Linie für Anwendungen, die auch wirklich Geschäftsprozesse automatisieren, wie z.b. im Bankenwesen oder in der Versicherungsindustrie. Bei mancher Software macht dieses Workflow allerdings reichlich wenig Sinn. So ist z.b. bei einem Autoradio kein bemerkenswerter Geschäftsprozess zu modellieren. [Kompakt] Die Abbildung 13 zeigt das Ergebnis aus PME im Artefakt Diagramm wie folgt: Abbildung 13: Business Modeling 28

29 2. Requirements Anforderungsmanagement ist ein systematischer Ansatz zum Erfassen, Dokumentieren, Organisieren und Verfolgen der sich ändernden Anforderungen eines Systems. Dem Workflow kommt eine wichtige Rolle innerhalb des RUP zu, da sie die treibende Kraft für die Entwicklung ist. Dabei geht es nicht nur darum, einmalig Anforderungen zu erfassen. Da Anforderungen oft erst spät entdeckt bzw. artikuliert werden, weil der Umfang eines Systems (definiert durch die Anforderungen) häufig geändert werden muss, reicht das nicht aus. Änderungen müssen eingearbeitet werden, möglichst an zentraler Stelle, damit das, was das System wirklich leisten soll, für alle Stakeholder verständlich ist. Die Anforderungen spielen dabei die Rolle eines Stellvertreters für die eigentlichen Stakeholder, die nicht immer verfügbar sind. Die Herausforderung des Workflows Requirements liegt nicht darin, sich am Anfang einmal um das Thema Anforderungen zu kümmern, sondern darin, dies bis zum Ende durchzuhalten. [Kompakt] Das Artefakt Diagramm für Requirements wird in der Abbildung 14 aufgezeigt. Bei Artefakt Glossary und Glossary Item wurde entschieden, sie schließlich in diesem Workflow zu modellieren. Sie werden in vielen Situationen auch in den ersten Workflow eingesetzt. Das kommt darauf an, wie relevant die Begriffe mit der Geschäfts Bedeutung zusammenhängen. Abbildung 14: Requirements 3. Analysis & Design Da sie den entscheidenden Übergang von den Anforderungen hin zum technischen Design der künftigen Applikation beschreibt, ist die Workflow Analyse & Design von enormer Bedeutung. Es ist auch der Workflow, bei dem die visuelle Modellierung mit 29

30 UML am intensivsten genutzt wird. Im Vordergrund steht hier das grafische Erarbeiten des Applikation Designs aufgrund von Anforderungen, bevor die letzten Details codiert werden. Das Workflow des RUP geht von einer objektorientierten Vorgehensweise aus und wäre im Gegensatz zu anderen Workflows für eine strukturierte Vorgehensweise stark anzupassen. [Kompakt] Abbildung 15 stellt dies grafisch dar. Abbildung 15: Analysis & Design 4. Implementation Inhalt der Implementation Workflow ist das Implementieren der einzelnen Komponenten oder Services und die Integration sukzessiver größerer Teilsysteme (Subsystem und Systemintegration). Auch der Entwicklertest, das Bugfixing und Code Reviews gehören hierher. [Kompakt] Abbildung 16 drückt das Artefakt Diagramm in diesem Teil aus. Weil es in der Implementation Phase deutlich mehr Codierungsaufwand gibt, existieren hier nicht viele Artefakte. 30

31 Abbildung 16: Implementation 5. Test Der Test Workflow ist ein wesentlicher Teil der Qualitätssicherung, da hier die ausführbare Software auf Erfüllung der Anforderungen geprüft wird. Gängige Untersuchungen ergeben für den Test zwischen 30% und 50% des Gesamtaufwandes. Dennoch wirkt die fertige Software für den Benutzer meist wie ungetestet. Ich fühle mich wie der Beta Tester ist eine viel gebrauchte Klage der Anwender. Die Gründe sind in der Komplexität der möglichen Testabläufe zu suchen ein vollständiger Test aller möglichen Softwareabläufe wird als unmöglich angesehen, aber auch in fehlender Methodik und Automatisierung. Das Testen profitiert besonders von der iterativen Vorgehensweise. Die Testergebnisse können in den Entwicklungsprozess eingehen, ehe es zu spät ist, und die Tests fallen nicht dem Zeitverzug gegen über dem Projektplan, bei dem am Ende des Projekts kaum Zeit für Tests übrig bleibt, zum Opfer. [Kompakt] (siehe Abbildung 17: Test) 31

32 Abbildung 17: Test Zusammenführung Bisher wurden die fünf Workflows jeweils in einem Artefakt Diagramm dargestellt. Als erster Teil des Traceability Models ist das Produkt Artefakt Diagramm einfach eine Zusammenführung der fünf vorherigen Ergebnisse. Die Frage ist, wie die Referenzen zwischen den Workflows zu finden sind. Auf dieses Thema wird in der Dokumentation des RUP nur ungenügend eingegangen. Viele Beziehungen zwischen den Workflows wurden in dieser Arbeit semantisch festgelegt und gemäß den vordefinierten Link Typen eingesetzt. Die Abbildung 18 stellt eine Übersicht für die Architektur des Produkts dar. 32

33 Abbildung 18: Produkt Artefakte Nachfolgend ein paar Erklärungen zur Architektur, die in der Abbildung 18 dargestellt ist: 1. Glossary als Artefakt definiert die allerwichtigsten fachlichen Begriffe von Anfang bis Ende des RUP. Glossary ist durch den ganzen Prozess gelaufen und könnte in allen Workflows existieren. Daher wurde ermittelt, dass Glossary in allen Workflows relevant ist. 2. Das Artefakt wie Business Use Case Model, Business Use Case und Business Vision Document wurde vor allem im ersten Workflow Business Modeling beschrieben. Sie sind aber auch als Use Case Model, Use Case und Vision Document im zweiten Workflow Requirements beschrieben. Im ersten Workflow Business Modeling wurde bloß die Geschäftssicht spezifiziert, dazu definiere ich hier die Referenz zwischen den beiden Workflows als Refinement. Analog ist die Referenz Refinement zwischen Requirements und Analyse & Design zu sehen. 3. Component als ein Artefakt existiert sowohl in Workflow Analyse & Design als in Workflow Implementation, sowie im Test. Es existieren zwar viele unterschiedliche Komponenten in dem RUP Prozess, aber eines ist sicher, dass die betroffenen Komponenten voneinander abhängig sind und eine Komponente kann die andere technisch realisieren, damit definiere ich die Referenz als Realization. 4. Workflow Test spielt eine wichtige Rolle im gesamten RUP Prozess. Man überprüft von Anfang bis Ende, ob alle Anforderungen und Planungen eingehalten wurden. Dabei werden alle Entwicklungsphasen untersucht und es handelt sich um querschneidende Belange. Diese werden im Diagramm als Assoziation beschrieben. 33

34 4.2.2 Prozess Artefakt Diagramme Es gibt noch vier weitere Workflows in RUP, dies sind Deployment, Configuration Management, Projekt Management und Environment. Das Deployment sorgt für eine reibungslose Auslieferung des Produkts. In dem Workflow werden drei Arten der Auslieferung angesprochen: Die kundenspezifische Installation, die Auslieferung als Standardprodukt und der Zugang zum Produkt über das Internet. Wegen entstehender Produktions bzw. Verteilungskosten ist mit den Aufgaben in diesem Workflow eine hohe Verantwortung verbunden. Der Workflow stellt zugleich den Übergang in den operativen Betrieb dar. Beim Konfigurationsmanagement (Configuration Management) handelt es sich um eine Unterstützung in RUP, da es die Daten und Änderungsverwaltung für die anderen Workflows zur Verfügung stellt und jede Weiterentwicklung von Arbeitsergebnissen im Team steuert und synchronisiert. Es verspricht eine schnell zu erreichende und klar nachweisbare Rentabilität einer Investition, zumal sie viele Probleme in der Softwareentwicklung unmittelbar und unabhängig von anderen Workflows bekämpft. Das Projektmanagement ist als planender und steuernder Workflow von zentraler Bedeutung für alle anderen Workflows und für die Prozessausführung als Gesamtes. Besonders erwähnenswert ist das Workflow Requirements, da die ermittelten Anforderungen eine wichtige Grundlage für die Planung und die Aufwandsabschätzung im Projektmanagement darstellen. [Kompakt] Nun wird hier in dieser Arbeit nicht streng in die oben vorgestellten vier Workflows unterteilt, sondern einfach in ein Project Model und Guideline gegliedert. Weil die Dokumentation für diesen Teil leider nicht so detailliert ist, wurden die Konsistenzregeln und die Referenz hier nicht weiter behandelt. 1. Project Model In diesem Teil werden einige Pläne, wie Software Development Plan (SDP) und Change Request bzw. Release als Artefakte dargestellt. Die Abbildung 19 zeigt das Ergebnis. 34

35 Abbildung 19: Project Model 2. Guideline Guideline ist im RUP wie ein Handbuch, und erklärt den Weg, wie man welche Workflows ausführen kann. Sie spielen auch eine wichtige Rolle im Laufe des gesamten Prozesses. Aber leider wurden die Guidelines in der Literatur nur unzureichend behandelt. Meist wurden nur Bezeichnungen genannt und diese nicht weiter ausformuliert. Nachfolgend ist das Ergebnis der Guidelines dargestellt (siehe Abbilung 20). Abbildung 20: Guideline 35