Aufwands- und Wiederverwendungsbeurteilung von Softwarekomponenten mittles Use Cases am Beispiel der Volkswagen Bank

Aufwands- und Wiederverwendungsbeurteilung

2

von Softwarekomponenten mittels Use Cases

am Beispiel der Volkswagen Bank

Abstrakt

Die folgende Ausarbeitung präsentiert ein Modell, das eine Aufwandsabschät- zung für zukünftig zu implementierende Funktionen eines SW Systems ermögli- chen soll. Die Aufwandsabschätzung bestimmter SW-Komponenten findet auf der Grundlage von so genannten "Use Cases" statt, die aus der Requirement- sanalyse des SW Engineering Prozesses entstammen. Hierbei werden nicht Use Case Modelle, die eher über den Umfang eines kompletten Systems Auskunft geben, sondern die in natürlicher Sprache beschriebenen Funktionalitäten ei- nes Systems, betrachtet. Die Bewertung eines einzelnen Use Case soll in An- lehnung an die von Gustav Karner im Jahre 1993 entwickelte UCP-Methode erfolgen. Diese wurde in der Vergangenheit bereits mehrmals zur Abschätzung des Umfanges von SW Projekten erfolgreich eingesetzt [2]. Des Weiteren wer- den zur Abschätzung des Aufwands Aspekte der Ähnlichkeit von SW- Komponenten berücksichtigt, sofern diese im Rahmen einer Requirementsana- lyse definiert werden können. Darüber hinaus wird eine Simulation und Beur- teilung der Methodik den Auswahl- und Beurteilungsmechanismus verdeutli- chen und auf Schwachpunkte der Systematik hinweisen. Abschließend liefert eine vorgestellte Idee einen Vorschlag, wie dieses Konzept toolbasiert umzuset- zen ist.

Aufwands- und Wiederverwendungsbeurteilung

3

von Softwarekomponenten mittels Use Cases am Beispiel der Volkswagen Bank

Eidesstattliche Erklärung

Ich erkläre an Eides statt, dass ich die vorliegende Bachelorarbeit selbständig und ohne fremde Hilfe verfasst habe. Andere als die angegebenen Quellen und Hilfsmittel wurden nicht benutzt.

Braunschweig, im Mai 2004

Aufwands- und Wiederverwendungsbeurteilung

4

von Softwarekomponenten mittels Use Cases am Beispiel der Volkswagen Bank

Danksagung

Mit dieser Arbeit möchte ich mich bei meinen Eltern bedanken, die es mir er- möglicht haben, bis an diesen Punkt meiner Ausbildung zu gelangen. Des Wei- teren gilt Dank den Herren Prof. Dr. Ralph Bergmann und Dipl. Wirtsch.- Inf. Ingo Grimm für die reibungslose Betreuung dieser Arbeit. Außerdem möchte ich an dieser Stelle Nadine Stefan und Mathias erwähnen, die mit ihrer kon- struktiven Kritik den Entwicklungsprozess dieser Ausarbeitung erheblich be- einflusst haben.

  Aufwands und Wiederverwendungsbeurteilung  5

  von Softwarekomponenten mittels Use Cases  

  am Beispiel der Volkswagen Bank  

  Inhaltsverzeichnis  

  Abkürzungsverzeichnis  9

  Abbildungsverzeichnis  10

Tabellenverzeichnis   11

1  Einleitung  12

1.1  Motivation  12

1.2  Anforderungen an den Leser  13

1.3  Aufbau der Arbeit  13

2  Wiederverwendung von SW-Komponenten  16

2.1  Begriffsklärungen  16

2.1.1  Begriff der SW-Komponente  16

2.1.2  Begriff der Wiederverwendung  18

2.2  Ziele der Wiederverwendung  18

2.3  Facetten der Wiederverwendung  19

2.4  Arten der Wiederverwendung  20

2.4.1  Ad Hoc-Wiederverwendung  20

2.4.2  Geplante Wiederverwendung  21

2.4.2.1  Generative Wiederverwendung  21

2.4.2.2  Kompositionelle Wiederverwendung  22

3  Use Cases  23

3.1  Einordnung von Use Cases in den SW Engineering Prozess  23

3.2  Zweck und Aufgaben von Use Cases  24

3.3  Aufbau von Use Cases  25

3.3.1  Allgemeines  25

3.3.2  Akteure und Ziele  26

3.3.3  Standardablauf  26

3.3.4  Alternativablauf  27

3.3.5  Beziehungen zwischen Use Cases  27

3.3.6  Aufbau von Use Cases bei VW  28

3.4  Use Cases und UML  30

  Aufwands und Wiederverwendungsbeurteilung  6

  von Softwarekomponenten mittels Use Cases  

  am Beispiel der Volkswagen Bank  

3.4.1  Allgemeines  30

3.4.2  Grafischer Aufbau eines Use Case Model  31

3.4.3  Generalisierung Spezialisierung  31

3.5  Ein Use Case Problem liegt im Detail  32

4  Aufwandsabschätzung bei SW Projekten  33

4.1  Überblick über vorhandene Modelle  33

4.2  Abschätzung von Projektaufwand mittels UCP-Methode  34

4.3  Beurteilung der UCP-Methode  39

5  Use Case basierte Wiederverwendung von SW-Komponenten  

  bei der Volkswagen Bank  41

5.1  Analyse der Ausgangssituation  41

5.1.1  Beschreibung von SEP (VW Richtlinie zur SW Entwicklung)  41

5.1.1.1  SEP als Konzernstrategie  41

5.1.1.2  Modellbeschreibung  42

5.1.2  SW-Entwicklung auf der Grundlage von Use Cases  45

5.1.2.1  Beschreibung des Ist-Zustands  45

5.1.2.2  Vorzunehmende Veränderungen  47

5.1.3  Beschreibung der Produkte der Volkswagen-Bank I-SEP  48

5.2  Generelles zur Beschreibung der Systematik zur Aufwands und  

  Wiederverwendungsabschätzung von SW-Komponenten  49

5.2.1  Vorstellung des Konzepts als Metaprozess  49

5.2.2  Einordnung des Konzepts anhand bereits vorhandener Ansätze  50

5.2.3  Durchführung von Entwicklerinterviews  51

5.3  Vorstellung des Konzepts im Detail  51

5.3.1  Idee  51

5.3.2  Vorbedingungen  52

5.3.3  Entscheidungsgrundlage  53

5.3.4  Bewertung der Elemente eines Use Case  53

5.3.5  Suche nach einem ähnlichen Use Case  58

5.3.6  Bewertung und Korrektur durchzuführender Tätigkeiten  58

5.3.7  Festlegung der Skalierung  61

5.3.8  Die Korrekturfaktoren  64

  Aufwands und Wiederverwendungsbeurteilung  7

  von Softwarekomponenten mittels Use Cases  

  am Beispiel der Volkswagen Bank  

5.3.8.1  Zweck der Tätigkeitskorrekturfaktoren  64

5.3.8.2  Zweck des zweiten Korrekturfaktors  64

5.3.9  Umwandlung des gemessenen Aufwands in Zeiteinheiten  64

5.3.9.1  Vorgehen und Ergebnisse  64

5.3.9.2  Probleme während des Vorgangs  66

5.3.9.3  Änderungsvorschläge  66

5.4  Simulation eines Auswahlvorganges zur Wiederverwendung  

  von SW-Komponenten  67

5.4.1  Analyse der Simulationsumgebung und Bewertung der  

  neuen Anforderungen  67

5.4.1.1  Allgemeines  67

5.4.1.2  Beschreibung des neuen Use Case (UC A)  67

5.4.1.3  Ermittlung der Komplexität für UC A  68

5.4.1.4  Beschreibung von UC B  70

5.4.1.5  Beschreibung von UC C  71

5.4.2  Suche nach dem ähnlichen Use Case  72

5.4.3  Aufwandsermittlung bei einer Wiederverwendung  73

5.4.3.1  Ermittlung des Aufwands im Vergleich zu UC B  73

5.4.3.2  Ermittlung des Risikofaktors für UC B  75

5.4.3.3  Ermittlung des Gesamtaufwands für UC B  75

5.4.3.4  Ermittlung des Aufwands im Vergleich zu UC C  75

5.4.3.5  Ermittlung des Risikofaktors für UC C  77

5.4.3.6  Ermittlung des Gesamtaufwands für UC C  77

5.4.4  Berechnung des Wiederverwendungsquotienten  77

5.4.4.1  Wiederverwendungsquotient für UC B  77

5.4.4.2  Wiederverwendungsquotient für UC C  77

5.4.5  Auswahl der Komponente  78

5.5  Beurteilung des Konzepts  78

6  Vorschlag für eine toolbasierte Unterstützung des Konzepts  81

7  Fazit Ausblick  84

8  Anhang  86

  Glossar  96

Aufwands- und Wiederverwendungsbeurteilung

8

von Softwarekomponenten mittels Use Cases

am Beispiel der Volkswagen Bank

Literaturverzeichnis .......................................................................................... 98

  Aufwands- und Wiederverwendungsbeurteilung 9  

  von Softwarekomponenten mittels Use Cases  

  am Beispiel der Volkswagen Bank  

  Abkürzungsverzeichnis  

  ACW = Alternative Course Weights  

  ASP = Active Server Pages  

  AW = Actor Weights  

  DMZ = Demilitarized Zone  

  DBMS = Datenbank-Managementsystem  

  EXW = Extension Weights  

  GUI = Graphical User Interface  

  HTML = Hypertext Markup Language  

  HTTPS = Hypertext transfer protocol secure  

  MW = Merged Weights  

  PT = Personentage  

  PW = Plausibility Weights  

  SEP = System-Entwicklungs-Prozess  

  SQL = Structured query language  

  SEP = Systementwicklungsprozess  

  SW = Software  

  TW = Transaction Weights  

  UML = Unified Modeling Language  

  UCP = Use Case Point  

  URW = Uses Relation Weights  

  VAP = Verkäuferarbeitsplatz  

  VW = Volkswagen  

  XML = Extensible Markup Language  

  Aufwands und Wiederverwendungsbeurteilung  10

  von Softwarekomponenten mittels Use Cases  

  am Beispiel der Volkswagen Bank  

  Abbildungsverzeichnis  

  Abbildung 2 1: Generative Wiederverwendung  21

  Abbildung 2 2: Kompositionelle Wiederverwendung  21

  Abbildung 3 1: Aktivitäten der Systementwicklung  22

  Abbildung 3 2 The Hub and Spoke model of requirements  24

  Abbildung 3 3: Grafische Darstellung eines Use Case Model  30

  Abbildung 3 4: Darstellung einer Spezialisierung  31

  Abbildung 5 1: SEP-Modell objektorientiert  43

  Abbildung 5 2: SEP-Modell Detailansicht Phase 2  44

  Abbildung 5 3: ER-Modell Auftragsvergabe VW  45

  Abbildung 5 4 : Architektur der Web-Applikationen der VW-Bank  48

  Abbildung 5 5: Killerkriterien  59

  Abbildung 5 6: Bewertung Anpassung  59

  Abbildung 5 7: Bewertung Übernahme  60

  Abbildung 5 8: The estimating dilemma  65

  Abbildung 6 1: Architekturvorschlag  81

  Aufwands und Wiederverwendungsbeurteilung  11

  von Softwarekomponenten mittels Use Cases  

  am Beispiel der Volkswagen Bank  

  Tabellenverzeichnis  

Tabelle 2 1:  Facetten der Wiederverwendung  18

Tabelle 4 1:  Gewichtung der Akteure nach Karner mit Rechenbeispiel  35

Tabelle 4 2:  Gewichtung der UC Typisierungen mit Rechenbeispiel  36

Tabelle 4 3:  Übersicht und Gewichtung der technischen Faktoren  37

Tabelle 4 4:  Gewichtung der Umgebungsfaktoren  38

Tabelle 5 1:  Umrechnung UCPs in Aufwand nach Karner  62

Tabelle 5 2:  Durchschnittlicher Aufwand pro Schritt intervallbezogen  62

Tabelle 5 3:  Übersicht über die neue Bewertung  62

Tabelle 5 4:  Neuverteilung des Aufwands für die Akteure  63

Tabelle 5 5:  Berechnung der Aufwandspunkte  68

Tabelle 5 6:  Aufschlüsselung der GUI  68

Tabelle 5 7:  Aufschlüsselung der Extended Use Cases  69

Tabelle 5 8  Vergleich zwischen UC B und UC A  73

Tabelle 5 9:  Vergleich der Transaktionen zwischen UC C und UC A  75

Aufwands- und Wiederverwendungsbeurteilung

12

von Softwarekomponenten mittels Use Cases

am Beispiel der Volkswagen Bank

1 Einleitung

„Handle stets so, daß weitere Möglichkeiten entstehen.“

Heinz von Foerster

1.1 Motivation

Aufwandsabschätzungen für komplette SW-Projekte oder auch nur Fragmente eines einzelnen SW-Projektes sind für Unternehmen ein wichtiges Planungs- und Steuerungsinstrument. Hierdurch sollen Überschreitungen von Budget- und Zeitvorgaben vermieden werden. Eine termingerechte Auslieferung der SW-Produkte ist ein wesentliches Merkmal, um weiterhin im Wettbewerb zu bleiben und das Unternehmen zu stärken [8]. Zur Verkürzung von Budget- und Zeitvorgaben ist es von Vorteil, mögliche Potenziale von wieder zu verwen- denden SW-Bestandteilen zu erkennen und einzusetzen. Die Entwicklungszei- ten und die Kosten eines Projekts können hiermit erheblich verkürzt werden [1]. Die Entscheidung, ob ein bereits implementiertes SW-Artefakt noch ein- mal in einem neuen System zum Einsatz kommt, ist einerseits von der Ähn- lichkeit des alten Artefakts zu den neuen Anforderungen abhängig, andererseits wird eine Entscheidung aber auch von den Kosten beeinflusst [1]. Oftmals wird die Entscheidung über eine Wiederverwendung von bereits implementierten Artefakten auf Code-Ebene getroffen [8]. Aus diesem Grund findet eine Beur- teilung erst spät innerhalb des SW-Engineering Prozesses statt. Wünschenswert ist es für das Unternehmen jedoch, bereits innerhalb der Anforderungsanalyse zu einer Entscheidung über eine mögliche Wiederverwendung von SW- Bestandteilen zu gelangen. Für Zeit- und Kosteneinsparungspotentiale gilt es, diese so früh wie möglich zu entdecken, um vorzeitig den Umfang des Auf- wands für ein Projekt planen zu können [8].

Auf Grund dieser Annahmen wird der Versuch unternommen ein Konzept zu modellieren, dass eine Aussage über die Wiederverwendung von SW- Artefakten auf der Grundlage von textuellen Use Case Beschreibungen ermög- licht. Das Modell soll dabei die Funktion erfüllen, den Aufwand für ein Frag-

Aufwands- und Wiederverwendungsbeurteilung

13

von Softwarekomponenten mittels Use Cases

am Beispiel der Volkswagen Bank

ment absolut in Aufwandskennzahlen zu darzustellen und über die Berechnung eines Wiederverwendungsquotienten eine Aussage über die Effizienz der Wie- derverwendung der SW-Komponente zu liefern.

Um einen Umsetzungsvorschlag für die Praxis zu erlangen, soll abschließend in dieser Ausarbeitung eine Idee umschrieben werden, die eine Wiederverwen- dung von SW-Komponenten auf der Grundlage von Use Cases toolunterstützt ermöglicht. Hierzu soll ein Use Case Repository gebildet werden, welches dem gesamten Unternehmen zur Verfügung stehen soll.

1.2 Anforderungen an den Leser

In der folgenden Ausarbeitung wird eine Möglichkeit vorgestellt, mit der ohne besondere fachliche Vorkenntnisse eine Aufwandsabschätzung des Program- mierumfangs auf der textuellen Ausprägung von Use Cases getroffen werden kann. Dem Leser werden zum Verständnis für dieses Konzept die angrenzen- den Themengebiete aufgezeigt. Diese werden innerhalb der Ausarbeitung dis- kutiert und in Konzeptrichtung angepasst. Somit sind keine besonderen Fach- kenntnisse zu den einzelnen Themengebieten erforderlich.

1.3 Aufbau der Arbeit

Über die unter Punkt 1.1 genannten Aspekte hinaus enthält diese Ausarbeitung folgende Inhalte:

In Punkt 2 dieser Ausarbeitung werden die Beweggründe für eine SW- Wiederverwendung genauer im Detail beschrieben. Es werden verschiedene Arten der Wiederverwendung von SW-Komponenten dargestellt und in wel- cher Weise eine Anwendung dieser innerhalb von Unternehmen zum Tragen kommt. Außerdem findet eine Einordnung des entwickelten Konzepts in die verschiedenen Arten der Wiederverwendung von SW-Komponenten statt. Im Mittelpunkt von Gliederungspunkt 3 stehen Use Cases. Hier wird beschrie- ben, aus welcher Phase des SW Engineering Prozesses Use Cases resultieren, in welcher Ausprägung sie vorkommen und welchem Zweck sie dienen. Des Weiteren wird die UML-Notation von Use Cases vorgestellt. Unter Gliede-

Aufwands- und Wiederverwendungsbeurteilung

14

von Softwarekomponenten mittels Use Cases

am Beispiel der Volkswagen Bank

rungspunkt 3.3 werden die Eigenschaften von Use Cases im Detail erläutert, damit eine spätere Bewertung dieser Kriterien möglich ist. Beendet wird das Kapitel 3 mit der Betrachtung des Detailliertheitsgrades, der beim Verfassen von Use Cases stark vom Autor abhängt und somit unterschiedlich sein kann. Dieses Problemfeld bringt Schwierigkeiten bei der späteren Bewertung mit sich.

Punkt 4 dieser Ausarbeitung beinhaltet die Thematik der Aufwandsabschät- zung für zukünftige SW-Projekte. Zu Beginn wird ein Überblick über bereits vorhandene Methoden und Ansätze der Aufwandsvorhersage gegeben. Im An- schluss daran wird eine Methode vorgestellt, die vor einigen Jahren in dem Unternehmen "Rational" erfunden wurde, um Aufwandsabschätzungen für SW-Projekte auf der Grundlage von Use Cases zu treffen. Diese "Use Case Point-Methode" bedient sich leider, trotz ihrer Einfachheit, einer nicht sehr großen Popularität. Das Kapitel wird mit der Bewertung dieser Methodik auf Grundlage von Forschungsberichten beendet.

Der Fokus des Gliederungspunktes 5 der Ausarbeitung liegt auf der Vorstel- lung des entworfenen Konzepts zur Aufwandsermittlung einzeln zu implemen- tierender Use Cases auf der Grundlage von textuellen Beschreibungen. Zu- nächst werden die VW Bank internen Spezifikationen erläutert. Hierzu wird der "Systementwicklungsprozess (SEP)" von der VW Bank erörtert, der sehr stark einem traditionellen SW Engineering Prozess gleicht, jedoch um einzelne Volkswagen spezifische Dokumentationen ergänzt wurde. Des Weiteren wird eine mögliche Systemarchitektur beschrieben, die von der VW Bank für die Erstellung von internetbasierten Verkäuferarbeitsplätzen benutzt werden könn- te. Anschließend wird das Konzept zur Aufwandsabschätzung von wieder zu verwendenden SW-Komponenten als Metaprozess erklärt und in vorhandene Systematiken zur Abschätzung von Wiederverwendungspotentialen eingeglie- dert. Nachdem im Gliederungspunkt 5.3 das Konzept im Detail erklärt wurde, findet unter dem darauf folgenden Punkt 5.4 eine Simulation des Konzepts statt. Hier wird davon ausgegangen, dass zwei bereits bewertete und implemen- tierte Use Cases zur Auswahl für eine Wiederverwendung stehen. Die Requi- rements einer Funktionalität des neuen Systems soll anhand einer geschätzten

Aufwands- und Wiederverwendungsbeurteilung

15

von Softwarekomponenten mittels Use Cases am Beispiel der Volkswagen Bank

Aufwandsberechnung darüber entscheiden, welche SW-Komponente für eine Wiederverwendung ausgewählt werden soll. Kapitel 5 wird mit einer detaillier- ten Evaluierung des Konzepts geschlossen.

Da diese Ausarbeitung rein theoretischer Natur ist und eine Ergebnisbetrach- tung der Praxis nicht stattfinden kann, wird im Kapitel 6 eine Idee für die Um- setzung eines toolbasierten Ansatzes der Methodik unterbreitet. Die Ausarbeitung endet mit einem Fazit und einem Ausblick bezüglich des entworfenen Konzepts.

Aufwands- und Wiederverwendungsbeurteilung

16

von Softwarekomponenten mittels Use Cases

am Beispiel der Volkswagen Bank

2 Wiederverwendung von SW-Komponenten

"Systematic software reuse and the reuse of components influence almost the whole software engineering process (independent of what a component is)." Johannes Sametinger

2.1 Begriffsklärungen

2.1.1 Begriff der SW-Komponente

In der Literatur existieren mehrere unterschiedliche Definitionen über den Um- fang und den Inhalt einer SW-Komponente. Eichinger et al. spricht davon, dass eine Komponente ein speziell zur Wiederverwendung geschaffener Baustein ist [8]. Bei dem Unternehmen Texas Instruments ist die Bedeutung eine andere [[33] nach [32]]:

„Eine Software Komponente ist ein Code-Modul, das ein oder mehrere klar definierte Dienste implementiert, die durch einen Satz von öffentlichen Schnittstellen festgelegt sind.“ Im Rahmen einer Vorlesung an der Universität Stuttgart ist eine Komponente jegliche Beschreibung von Zusammenhängen, aus der Code generiert werden kann. Darüber hinaus werden auch alle wesentlichen Ergebnisse des SW- Engineering Prozesses als Komponenten betrachtet, somit auch der resultieren- de Programmcode [34].

Sametinger, der in Komponenten die gleichen Aspekte sieht wie [33], be- schreibt in seinem Buch „Software Engineering with Reusable Components “ einzelne Eigenschaften, die eine Komponente erfüllen sollte [28]:

1. Self-containedness:

"Components should be self-contained, i.e., reusable without the need to include other components for reuse. In this sense, a function is re- garded as a component if it can be used on its own, i.e., without the need of any other functions […]."

Aufwands- und Wiederverwendungsbeurteilung

17

von Softwarekomponenten mittels Use Cases

am Beispiel der Volkswagen Bank

2. Identification:

"Components have to be clearly identifiable, e.g., contained in a file ra- ther than being spread over many locations and intermixed with other artefacts of software or documentation […]."

3. Functionality:

"Components describe and/or perform specific functions; i.e., compo- nents have a clearly specified functionality which they perform or de- scribe […]."

4. Interfaces:

"Components have to have clear interfaces and hide details that are not needed for reuse […]."

5. Documentation:

"Documentation is indispensable for reuse. The most useful component is rendered useless for reuse purposes when appropriate documentation is not available […]."

6. Reuse status:

"Components must be maintained to support systematic reuse. The re- use status contains information about who is the owner of a component, who maintains it, who can be contacted in case of problems arise, and what is the quality status of a component […]." Innerhalb dieser Ausarbeitung soll die Definition nach [32] ihren Geltungsbe- reich haben. Eine Komponente sollte eine bestimmte Funktionalität besitzen und mit anderen Komponenten über Schnittstellen kommunizieren. Aus diesem Grund sind Methoden, Module oder auch ein Sortieralgorithmus innerhalb ei- ner Methode, als Komponenten zu betrachten. Bei der Entwicklung auf der Grundlage von Use Cases ist es häufig der Fall, dass die funktionalen Anforde- rungen nicht zwingender maßen etwas über die Struktur oder den resultieren- den Code des folgenden Programms oder deren Komponenten aussagen [14]. Insofern wird für diese Ausarbeitung eine "weichere" Betrachtung einer Kom- ponente gewählt, die nicht unbedingt an den o.g. Eigenschaften festgemacht werden kann.

Aufwands- und Wiederverwendungsbeurteilung

18

von Softwarekomponenten mittels Use Cases

am Beispiel der Volkswagen Bank

2.1.2 Begriff der Wiederverwendung

Wird die Begrifflichkeit der SW-Wiederverwendung genauer betrachtet, so kann zwischen zwei verschiedenen Ausprägungen unterschieden werden. Die

SW Wiederverwendung (Reuse) beschreibt den aktiven Prozess des erneuten

Einsatzes von Objekten in veränderten Umgebungen. Die Wiederverwendbar- keit (Reusability) hingegen beurteilt, ob ein Objekt wieder verwendet werden kann [14].

In den folgenden Ausführungen wird ein Konzept vorgestellt, mit dem eine Feststellung der Wiederverwendbarkeit von SW-Komponenten beurteilt wird. Diese Beurteilung findet auf der Grundlage des aufzubringenden Aufwands für die Anpassung der Komponente statt. Insofern wird versucht, auf eine klare Zuweisung der Begrifflichkeit zu achten, wobei die Grenzen nicht immer ein- deutig zu ziehen sind [14].

2.2 Ziele der Wiederverwendung

Der Drang zu einer Wiederverwendung von SW hat seinen Ursprung in oft- mals knapp geplanten Zeit- und Kostenkorridoren einzelner Projekte. Durch knappe Ressourcen wächst der Drang, bereits entwickelte SW-Komponenten wieder einzusetzen. Hierdurch sollen eine Erhöhung der Produktivität, eine Verbesserung der Qualität und eine Reduktion der Wartungskosten erreicht werden [8, 10]. Die Produktivität stellt das Verhältnis vom Output zum Input dar [23]. Eine Steigerung kann durch eine Verkleinerung des Inputs oder durch eine effizientere Produktionsmethode erzielt werden. Somit folgt eine Erhö- hung der Produktivität aus einer Reduktion des Wartungsaufwandes oder/und durch eine Verkleinerung des Entwicklungsaufwandes. Im Folgenden findet eine nähere Erläuterung der Sachverhalte statt.

• Reduzierung des Entwicklungsaufwands:

Durch die Wiederverwendung von SW werden redundante Arbeiten vermieden. Somit kann die Entwicklungszeit verkürzt werden. Dies hat zur Folge, dass kürzere Time to Market Zeiträume erreicht werden können. Sametinger berichtet von einer Verkürzung der Entwicklungs- zeit von bis zu 42% [[16] zitiert nach [28]].

Aufwands- und Wiederverwendungsbeurteilung

19

von Softwarekomponenten mittels Use Cases

am Beispiel der Volkswagen Bank

• Reduzierung des Wartungsaufwands:

Wenn geprüfte und bereits korrigierte Codefragmente erneut eingesetzt werden, wird davon ausgegangen, dass diese Fragmente einen geringen Wartungsaufwand verursachen [28]. Sollten dennoch Fehler auftreten, wird es leichter sein, diese zu finden. Defekte in bereits bekannten und überarbeiteten Komponenten sind leicht zu lokalisieren. Somit wird die Suche nach Fehlern verkürzt. Ebenfalls werden Einarbeitungszeiten verringert [32].

• Erhöhung der SW-Qualität:

Damit eine SW-Komponente wieder verwendbar ist, muss sie bestimm- ten Anforderungen gerecht werden. Sind die Kriterien für eine Wieder- verwendbarkeit erfüllt, so ist auch gleichzeitig die Qualität der SW hoch einzuschätzen. Demzufolge wird durch eine angestrebte Wieder- verwendung von SW die Qualität steigen [14].

2.3 Facetten der Wiederverwendung Bei näherer Betrachtung der Wiederverwendung von SW-Komponenten gibt es eine Vielzahl von Blickwinkeln, die zu berücksichtigen sind. Küffmann liefert hierzu folgende Aufgliederungen der verschiedenen Facetten der Wiederver- wendung [14]:

Tabelle 2-1: Facetten der Wiederverwendung [14].

Aufwands- und Wiederverwendungsbeurteilung

20

von Softwarekomponenten mittels Use Cases

am Beispiel der Volkswagen Bank

Die Abbildung zeigt, dass eine Wiederverwendung aus vielen verschiedenen Perspektiven zu betrachten ist. Die obere Zeile der Tabelle zeigt unterschiedli- che Charakterisierungsmöglichkeiten für eine Wiederverwendung. Die Aus- prägung der einzelnen Eigenschaften listet jeweils eine Möglichkeit auf, eine Wiederverwendung durchzuführen. So bringt die Betrachtungsweise "By Sco- pe" beispielsweise die Möglichkeiten einer entwurfsstufenfremden, domänen- internen (horizontal) oder einer domänenfremden (vertikal) Wiederverwendung an.

Die Facette "By Intention" bietet folgende Varianten:

Wird sich für eine „Black-Box" Wiederverwendung entschieden, so wird das wieder zu verwendende Objekt ohne Veränderungen eingebaut. Die "White- Box" Variante hingegen bietet eine Modifikation der Komponente an. Wäh- rend die erstgenannten beispielhaft erläuterten Facetten keine Überschnei- dungspunkte haben, besitzt die Kategorie "By Mode" teilweise Eigenschaften der "By Intention"-Kategorie. Beispielsweise werden bei einer „Ad-hoc“ Wie- derverwendung SW-Bestandteile ungeplant übernommen und modifiziert in die neue Umgebung eingesetzt [14]. Eine ähnliche Eigenschaft bietet der „White-Box“ Ansatz [28]. Die vorgestellten Techniken der Wiederverwendung schließen sich nicht zwingend voneinander aus. Je nach Unternehmen und Art der Wiederverwendung sind Mischformen möglich. Somit wird beispielsweise in der VW Bank eine „Ad-hoc“ Wiederverwendung und eine kompositionelle Wiederverwendung genutzt. Im nächsten Kapitel werden deshalb die Bereiche „By Mode“ und „By Technique“ näher betrachtet.

2.4 Arten der Wiederverwendung

2.4.1 Ad Hoc-Wiederverwendung

Ein Charakteristika der "Ad hoc" Wiederverwendung ist das ungeplante und nicht systematische Verwenden von SW-Bestandteilen auf Code Ebene. Der Prozess beschreibt das Wiederfinden von bestehenden Entwicklungsprodukten über das Erinnerungsvermögen des Entwicklers. Hierbei kommen nach Küff- mann vor Allem drei Tätigkeiten zum Zuge: "Copy, Paste and Modify" [14].