Document [original]

Effiziente Erfassung und Pflege von

Traceability-Modellen zur Entwicklung

technischer Systeme

vorgelegt von

Asmus Figge

Dipl.-Ing.

aus Kiel

von der Fakultät V – Verkehrs- und Maschinensysteme

der Technischen Universität Berlin

zur Erlangung des akademischen Grades

Doktor der Ingenieurwissenschaften

- Dr.-Ing. -

genehmigte Dissertation

Promotionsausschuss:

Vorsitzender: Prof. Dr.-Ing. Roland Jochem

1. Gutachter: Prof. Dr.-Ing. Rainer Stark

2. Gutachter: Prof. Dr.-Ing. habil. Ralph Stelzer

Tag der wissenschaftlichen Aussprache: 4. Februar 2014

Berlin 2014

D 83

GELEITWORT DER HERAUSGEBER

Die Schriftenreihe „Berichte aus dem Produktionstechnischen Zentrum Berlin“ wird

von den Professoren der im Produktionstechnischen Zentrum Berlin dauerhaft ange-

legten Fach- und Forschungsgebiete der TU Berlin gemeinsam herausgegeben.

Zweck der Schriftenreihe ist es, die auf den Gebieten der Produktentstehung, Produk-

tionstechnik und Informationstechnik erarbeiteten Forschungsergebnisse einer brei-

ten Fachöffentlichkeit zugänglich zu machen. In der Schriftenreihe erscheinen in ers-

ter Linie die an den Fachgebieten des Instituts für Werkzeugmaschinen und Fabrikbe-

trieb (IWF) der TU Berlin und am Fraunhofer-Institut für Produktionsanlagen und Kon-

struktionstechnik entstandenen Dissertationen. Daneben werden aber auch andere

Forschungsberichte, die in den thematischen Rahmen passen und vom allgemeinen

Interesse sind, in die Schriftenreihe aufgenommen. Die Herausgeber wünschen sich

ein reges Interesse an der Schriftenreihe und würden sich freuen, wenn hieraus

fruchtbare Dialoge mit Praktikern und Forschern entstünden.

Die vorliegende Dissertationsarbeit von Herrn Dr. Figge beschäftigt sich mit der Erfor-

schung und der Evaluierung der nächsten Generation von Methoden und Werkzeu-

gen des „Traceability Engineering“ (Effiziente Erfassung und Pflege von Traceability-

Modellen zur Entwicklung technischer Systeme), einer grundlegenden Arbeitsdisziplin

des Systems Engineering und somit Wegbereiter der modernen disziplinenübergrei-

fenden Produktentwicklung. In der vorliegenden Arbeit werden drei neuartige Me-

thoden zur Erfassung und Pflege von Traceability-Informationen entwickelt und eva-

luiert. Ziel der Arbeit ist es, das Traceability Engineering im Sinne der expliziten Auf-

nahme von Verlinkungen zwischen digitalen Modellen als moderne und durchgän-

gig nutzbare Entwicklungsmethode zu etablieren, so dass dem derzeit misslichen Um-

stand, dass nur die Branchen konsistent Traceability Dokumentationsmethoden nut-

zen, die hierzu gesetzlich verpflichtet sind, gekonnt entgegen getreten werden kann.

Der Verfasser der vorliegenden Dissertationsschrift hat eindeutig bewiesen, dass er

mit wissenschaftlich fundierten Vorgehensweisen bestens vertraut ist und diese ge-

winnbringend zur Erforschung von neuen Konzepten und Werkzeugen der Traceabili-

ty-basierten Entwicklung von technischen Systemen einsetzen kann. Insbesondere

hervorzuheben ist die gewählte wissenschaftliche Vorgehensweise, welche sich aus-

gehend von dem Erkennen der Probleme in der Praxis, über daraus abgeleitete kon-

krete Anforderungen an verbesserte Modellierungsumgebungen, dem Stand der

Technik sowie der sich anschließenden Hypothesenbildung, der gezielten Ent-

wicklung von neuen Methoden für die durchgängige Verknüpfung, der proto-

typischen Implementierung dieser Methoden in Softwaresysteme bis hin zur Evaluie-

rung im Rahmen von mehreren wissenschaftlichen Nutzerstudien erstreckt.

Berlin, Februar 2014

Rainer Stark

iii

ABSTRACT

In the past, the development process for technical products primarily focused on the

detailed development of mainly mechanical working principles. Today, research

and development challenges have shifted towards the orchestration of different

technical disciplines. In this complex context it is often impossible for developers to

fully apprehend all dependencies of the systems under consideration.

Traceability is a method that allows for the explicit documentation of these depend-

encies, for instance in order to assess the impact of changes across disciplines. How-

ever, traceability is usually only applied when required by law, as it requires consid-

erable effort for recording and maintenance. Hence, this thesis addresses three re-

search questions aimed at supporting the use of traceability.

To assist in the efficient modeling of traceability-models, the method EcoTracing is

designed. To reduce the modeling effort, EcoTracing utilizes the hierarchical structure

of the models describing the systems under development. Its performance was eval-

uated in a user study, showing that arithmetically averaged savings of about 60 %

are possible.

Traceability-models have to be evaluated and updated continuously to maintain

their quality. In this thesis, TraceEvaluation is proposed as a new approach to support

this quality management. It applies crowdsourcing methods to enable developers to

easily document mistakes in traceability-models that they identify during their daily

business. In doing so, the feedback of many users can be aggregated rapidly and

analyzed centrally. The effectiveness of TraceEvaluation was verified in a user study

in which all planted mistakes were precisely identified.

In addition to the recognition of mistakes it is important to identify dependencies

missing from the traceability-model. To address this issue, TraceLegacy is presented in

this thesis. It makes use of development knowledge of legacy projects to identify de-

pendencies in current projects. The viability of TraceLegacy was proved in an evalu-

ation with an example in which several dependencies could be detected.

The contribution of this thesis is the development and evaluation of three innovative

methods for the recording and maintenance of traceability-models. It significantly

contributes to the state of traceability-research, especially as the effectiveness of the

methods was proved using realistic examples of technical systems as well as in user

studies.

ZUSAMMENFASSUNG

Lag früher der Fokus bei der Entwicklung technischer Produkte auf der Detaillierung

meist mechanischer Wirkprinzipien, finden sich die Herausforderungen heute eher im

Bereich der Orchestrierung unterschiedlicher Entwicklungsdisziplinen. In diesem kom-

plexen Kontext ist es Entwicklern vielfach unmöglich, alle Abhängigkeiten der zu

entwickelnden Systeme vollständig zu erfassen.

Traceability ist eine Methode, um diese Abhängigkeiten explizit zu dokumentieren

und so bspw. die Auswirkungen von Änderungen über Disziplingrenzen hinweg ab-

schätzbar zu machen. Jedoch beschränkt sich die Anwendung der Traceability

hauptsächlich auf Bereiche, in denen sie explizit durch den Gesetzgeber gefordert

wird. Gründe hierfür sind u. a. der große Aufwand für die Erfassung und Pflege der

Traceability. Der Bedarf nach einer Reduktion dieses Aufwands stellt den Ausgangs-

punkt für die drei in dieser Arbeit behandelten Forschungsfragen dar.

Dazu wird zunächst die effiziente Modellierung von Traceability-Modellen betrachtet

und die Methode EcoTracing konzipiert. EcoTracing nutzt die hierarchische Struktur

systembeschreibender Modelle, um Aufwände bei der Modellierung zu reduzieren.

Bei der Evaluation der Methode im Rahmen einer Studie konnte im arithmetischen

Mittel eine Aufwandsersparnis von ca. 60 % erreicht werden.

Einmal erstellt, müssen die Traceability-Modelle kontinuierlich gepflegt werden, um ih-

re Qualität dauerhaft zu erhalten. Als neuen Ansatz, dies zu unterstützen, wird die auf

Crowdsourcing basierende Methode TraceEvaluation entwickelt. Sie ermöglicht es

Entwicklern, Fehler in Traceability-Modellen, die sie während der Bearbeitung ihrer

Aufgaben im Tagesgeschäft automatisch entdecken, einfach zu dokumentieren.

Durch dieses Verfahren gelingt es, das Feedback vieler Nutzer schnell zu aggregieren

und zentral auszuwerten. In einer Studie konnten mit TraceEvaluation alle Fehler prä-

zise identifiziert und damit die Wirksamkeit der Methode nachgewiesen werden. Um

neben falschen auch fehlende Tracelinks identifizieren zu können, wird zusätzlich die

Methode TraceLegacy in dieser Arbeit beschrieben. Sie nutzt das Entwicklungswissen

vergangener Projekte, um Abhängigkeiten in aktuellen Projekten zu identifizieren. Im

Rahmen der Evaluation konnten so zahlreiche fehlende Tracelinks erkannt und damit

die Funktionsfähigkeit der Methode nachgewiesen werden.

Der Forschungsbeitrag dieser Arbeit liegt in der Entwicklung und Evaluation dreier

neuartiger Methoden zur Erfassung und Pflege von Traceability-Modellen. Die Me-

thoden stellen einen signifikanten Beitrag zum Stand der Wissenschaft im Bereich der

Traceability-Forschung dar, zumal ihre jeweilige Wirksamkeit durch Nutzerstudien so-

wie anhand vergleichender Beispiele belegt werden konnte.

vii

DANKSAGUNG

Die Erstellung dieser Dissertation war mit einem eingangs nicht für möglich gehalte-

nen Aufwand verbunden, dessen Bewältigung mir ohne die Unterstützung zahlreicher

Personen in meinem privaten und beruflichen Umfeld nicht möglich gewesen wäre.

Zunächst möchte ich meinem Doktorvater Prof. Dr.-Ing. Rainer Stark für die Betreuung

dieser Arbeit danken. Seine berechtigten Fragen und geäußerte Kritik haben das vor-

liegende Ergebnis wesentlich beeinflusst. Prof. Dr.-Ing. habil. Ralph Stelzer danke ich

für die Begutachtung der Arbeit und Prof. Dr.-Ing. Roland Jochem für die Übernahme

des Promotionsausschuss-Vorsitzes.

Grischa Beier, der seine Dissertation zeitgleich erstellt hat, danke ich für fünf Jahre

außerordentliche Zusammenarbeit. Die täglichen Diskussionen über Traceability-

Grundlagen, den Stand der Technik, entwickelte Methoden, deren Evaluation und

der gemeinsame Konsum hunderter Liter Kaffee haben diese Arbeit erst möglich

gemacht. Michel Bornath und Robert Müller, die als studentische Mitarbeiter die pro-

totypische Implementierung meiner Methoden durchgeführt haben, danke ich für ih-

re hervorragende Arbeit, ihr stetiges Mitdenken und die Tatsache, dass sie meine

maschinenbäuerlichen Fragen ertragen haben. Johann Habakuk Israel und Elisabeth

Brandenburg danke ich für die Unterstützung bei der Konzeption der durchgeführten

Studien und Simon Königs für die stundenlangen Diskussionen über die Grundlagen

der Traceability. Konrad Wernicke und Tobias Lange danke ich für die Korrektur mei-

ner Dissertation und entschuldige mich nachträglich für deren Umfang.

Allen Kollegen im Geschäftsfeld Virtuelle Produktentstehung des Fraunhofer IPK und

im Fachgebiet Industrielle Informationstechnik der TU Berlin danke ich für eine ausge-

sprochen angenehme Arbeitsatmosphäre, den freundschaftlichen Umgang im Ar-

beitsalltag und zahlreiche Gespräche insbesondere abseits der Virtuellen Produktent-

stehung.

Ein besonderer Dank gilt meinen Eltern Hanna und Norbert. Ohne ihre große Unter-

stützung in jeder Hinsicht wären weder Abitur noch Studium möglich gewesen, was

wahrscheinlich bei Begutachtung, spätestens jedoch bei Einreichung der Arbeit auf-

gefallen wäre. Auch Opa Siegfried, Jonas, Kadl, meinen Schwiegereltern Hanne und

Werner sowie Dirk, Esther, Jan und Christin Schönzart danke ich für ihre Unterstützung.

Mein größter Dank gilt jedoch meiner kleinen Familie. Lena, vielen Dank, dass du im-

mer für mich da warst und unsere Wochenendbeschäftigung der letzten anderthalb

Jahre ertragen hast. Ohne dich wäre diese Arbeit nicht möglich gewesen. Lotta, vie-

len Dank, dass du die stressige letzte Phase der Promotion entschleunigt und durch

jedes Lächeln so viel schöner gemacht hast.

INHALTSVERZEICHNIS

INHALTSVERZEICHNIS ................................................................................................................ IX

ABKÜRZUNGSVERZEICHNIS ........................................................................................................ XV

ABBILDUNGSVERZEICHNIS ....................................................................................................... XVII

TABELLENVERZEICHNIS ............................................................................................................ XXIII

1 EINLEITUNG UND ZIELSETZUNG ............................................................................................... 1

1.1 Ausgangssituation und Zielsetzung der Arbeit ...................................................... 1

1.2 Forschungsfragen ...................................................................................................... 3

1.3 Vorgehen und Aufbau der Arbeit ........................................................................... 4

2 ENTWICKLUNG MECHATRONISCHER SYSTEME ........................................................................... 7

2.1 Vorgehensmodelle zur Entwicklung mechatronischer Systeme ......................... 7

2.1.1 VDI 2206 – Entwicklungsmethodik für mechatronische Systeme ............ 8

2.1.2 Systems Engineering .................................................................................... 10

2.1.3 ISO 26262 – Road vehicles – Functional Safety ....................................... 13

2.1.4 Industrielle Vorgehensweise am Beispiel der Automobilindustrie ......... 15

2.1.5 V-Modell des Fraunhofer IPK ...................................................................... 18

2.1.6 Vergleich der Vorgehensmodelle ............................................................. 21

2.2 Artefakte zur Entwicklung mechatronischer Systeme ........................................ 23

2.2.1 Anforderungsartefakte ............................................................................... 23

2.2.2 Funktionsartefakte ....................................................................................... 24

2.2.3 Verhaltensartefakte..................................................................................... 26

2.2.4 Produktstrukturartefakte ............................................................................. 28

2.2.5 Abhängigkeiten zwischen Artefakten ...................................................... 28

2.3 Zusammenfassung und Diskussion ........................................................................ 30

3 DURCHGÄNGIGE NACHVERFOLGBARKEIT ............................................................................. 31

3.1 Bedarf nach durchgängiger Nachverfolgbarkeit .............................................. 32

3.2 Ursprung und Verbreitung durchgängiger Nachverfolgbarkeit ....................... 35

3.3 Grundbegriffe durchgängiger Nachverfolgbarkeit ........................................... 36

3.4 Phasen der durchgängigen Nachverfolgbarkeit ............................................... 42

Inhaltsverzeichnis

3.4.1 Erfassung von Tracelinks ............................................................................. 42

3.4.2 Verwendung von Tracelinks ...................................................................... 44

3.4.3 Pflege von Tracelink-Modellen .................................................................. 44

3.4.4 Planung durchgängiger Nachverfolgbarkeit ......................................... 45

3.5 Einordnung der durchgängigen Nachverfolgbarkeit in den strategischen

Unternehmenskontext ............................................................................................ 48

3.6 Software zur Erfassung, Pflege und Verwendung von Tracelinks ..................... 50

3.6.1 Anforderungsmanagement-Software...................................................... 50

3.6.2 PLM-Systeme ................................................................................................ 54

3.6.3 Analyse-Software ........................................................................................ 57

3.6.4 Integrationssoftware ................................................................................... 61

3.7 Herausforderungen der durchgängigen Nachverfolgbarkeit ......................... 68

3.7.1 Allgemeine Darstellung der Herausforderungen .................................... 69

3.7.2 Darstellung der Herausforderungen am Beispiel der Entwicklung

des mechatronischen Außenspiegels ...................................................... 71

3.8 Zusammenfassung und Diskussion ........................................................................ 74

4 FORSCHUNGSFRAGEN UND HYPOTHESEN .............................................................................. 77

4.1 Methodische Unterstützung zur effizienten Modellierung von Tracelinks ........ 78

4.2 Methodische Unterstützung zur verteilten Qualitätssicherung ......................... 79

4.3 Verwendung des Wissens vergangener Projekte zur Qualitätssicherung ....... 80

5 METHODEN ZUR EFFIZIENTEN MODELLIERUNG VON TRACELINKS ................................................. 81

5.1 Stand der Technik und Forschung ........................................................................ 82

5.2 Grundlagen zur Konzeption und Bewertung der Methoden ............................ 84

5.2.1 Strukturanalyse der Artefakte der Entwicklung mechatronischer

Systeme ........................................................................................................ 85

5.2.2 Granularität im Kontext der Traceability ................................................ 100

5.2.3 Ermittlung des Aufwands bei der manuellen Erfassung von

Tracelinks .................................................................................................... 105

5.2.4 Zusammenfassung und Schlussfolgerungen ......................................... 107

5.3 Evaluation der Hypothese 1* im Kontext der Systementwicklung ................. 108

5.3.1 Aufbau und Durchführung der Studie .................................................... 108

Inhaltsverzeichnis

5.3.2 Auswertung und Diskussion der Ergebnisse ............................................ 113

5.4 EcoTracing – Methode zur effizienten Modellierung von Tracelinks .............. 118

5.4.1 Funktionsprinzip der Methode EcoTracing ............................................. 118

5.4.2 Algorithmus der Methode EcoTracing .................................................... 119

5.4.3 Prototypische Implementierung der Methode EcoTracing ................. 123

5.4.4 Ermittlung des Aufwands bei der Erfassung von Tracelinks mit

EcoTracing .................................................................................................. 126

5.4.5 Evaluation der Methode EcoTracing ...................................................... 128

5.5 Zusammenfassung und Diskussion ...................................................................... 137

6 METHODEN ZUR PFLEGE VON TRACELINK-MODELLEN ............................................................ 141

6.1 Stand der Technik und Forschung ....................................................................... 142

6.1.1 Regelbasierte Methoden ......................................................................... 143

6.1.2 Linguistische und IR-Methoden ................................................................ 145

6.1.3 Zusammenfassung und Diskussion ........................................................... 147

6.2 Grundlagen zur Konzeption und Bewertung der Methoden .......................... 149

6.2.1 Crowdsourcing ........................................................................................... 149

6.2.2 Trefferquote und Präzision ........................................................................ 152

6.3 TraceEvaluation – Methode zur verteilten Bewertung von Tracelinks ........... 154

6.3.1 Funktionsprinzip der Methode TraceEvaluation .................................... 154

6.3.2 Prototypische Implementierung der Methode TraceEvaluation ........ 157

6.3.3 Evaluation der Methode TraceEvaluation ............................................. 160

6.3.4 Zusammenfassung und Diskussion ........................................................... 165

6.4 TraceLegacy – Methode zur Identifikation fehlender Tracelinks .................... 166

6.4.1 Funktionsprinzip der Methode TraceLegacy ......................................... 167

6.4.2 Algorithmus der Methode TraceLegacy ................................................ 168

6.4.3 Prototypische Implementierung der Methode TraceLegacy ............. 171

6.4.4 Evaluation der Methode TraceLegacy .................................................. 173

6.4.5 Zusammenfassung und Diskussion ........................................................... 179

6.5 Zusammenfassung und Diskussion ...................................................................... 181

7 ANWENDUNG DER METHODEN ZUR ENTWICKLUNG EINES TECHNISCHEN SYSTEMS ...................... 183

7.1 Verortung der Methoden im V-Modell ............................................................... 184

Inhaltsverzeichnis

xii

7.2 Demonstration der Methoden am Beispiel der Entwicklung eines

mechatronischen Außenspiegels ....................................................................... 185

7.2.1 Anforderungen .......................................................................................... 187

7.2.2 Anforderungskaskade .............................................................................. 187

7.2.3 Vorentwurf der Funktionen und Eigenschaften .................................... 189

7.2.4 Erfassung von Tracelinks zwischen Anforderungen und Funktionen .. 190

7.2.5 Vorentwurf des Systemmodells ............................................................... 193

7.2.6 Erfassung von Tracelinks zwischen Funktionen und

Verhaltensmodell ...................................................................................... 194

7.2.7 Integrierte Absicherung ............................................................................ 195

7.2.8 Entwicklung mechanischer Komponenten ........................................... 196

7.2.9 Erfassung von Tracelinks zwischen Produktstruktur und

Verhaltensmodell sowie Anforderungen ............................................... 196

7.2.10 Durchführung einer Auswirkungsanalyse aufgrund einer

geänderten Anforderung ........................................................................ 198

7.2.11 Durchführung einer Qualitätskontrolle des Tracelink-Modells ............ 199

7.3 Zusammenfassung ................................................................................................ 201

8 ZUSAMMENFASSUNG UND AUSBLICK .................................................................................. 203

8.1 Zusammenfassung der Ergebnisse dieser Arbeit .............................................. 204

8.1.1 EcoTracing ................................................................................................. 204

8.1.2 TraceEvaluation ......................................................................................... 205

8.1.3 TraceLegacy .............................................................................................. 206

8.1.4 Fazit ............................................................................................................. 207

8.2 Einsatzmöglichkeiten der Methoden und deren Auswirkungen auf die

IT-Architektur .......................................................................................................... 208

8.3 Ausblick .................................................................................................................. 210

LITERATURVERZEICHNIS ........................................................................................................... 213

GLOSSAR ............................................................................................................................. 223

ANHANG ............................................................................................................................. 231

A. Material zur Studie „Evaluation der Hypothese 1* im Kontext der

Systementwicklung“ ............................................................................................. 232

Inhaltsverzeichnis

xiii

B. Material zur Studie „Evaluation der Methoden EcoTracing und

TraceEvaluation“ ................................................................................................... 244

C. Material zur Evaluation der Methode TraceLegacy ......................................... 254

ABKÜRZUNGSVERZEICHNIS

ASIL

Automotive Safety Integrity Level

BMBF

Bundesministerium für Bildung und Forschung

CAD

Computer Aided Design

COTS

Commercial off-the-shelf: Standardsoftware

DIN

Deutsches Institut für Normung

DMM

Domain Mapping Matrix

DMU

Digital Mock-Up

DRM

Design Research Methodology

DSM

Design Structure Matrix

E/E

Elektrik/Elektronik

FEM

Finite Elemente Methode

FMEA

Fehlermöglichkeits- und Einfluss-Analyse (engl.: Failure Mode and Effects

Analysis)

GUI

Graphical User Interface: grafische Benutzeroberfläche

HiL

Hardware in the Loop

Identifikationsnummer

IEC

International Electrotechnical Commission

IEEE

Institute of Electrical and Electronics Engineers

INCOSE

International Council on Systems Engineering

Information Retrieval: Informationsrückgewinnung

ISO

International Organization for Standardization

Informationstechnik

LED

Leuchtdiode

MBE

Modellbasierte Entwicklung

MDM

Multiple-Domain Matrix

MKS

Mehrkörpersimulation

OSLC

Open Services for Lifecycle Collaboration

PDM

Produktdatenmanagement

PSE

Produktstruktur-Editor

QFD

Quality-Function-Deployment

Abkürzungsverzeichnis

xvi

ReqIF

Requirements Interchange Format

ROI

Return on Investment

Systems Engineering

SiL

Software in the Loop

SysML

Systems Modeling Language

UID

Unique ID: Eindeutige Identifikationsnummer

VDI

Verein Deutscher Ingenieure

XML

Extensible Markup Language: erweiterbare Auszeichnungssprache

xvii

ABBILDUNGSVERZEICHNIS

Abbildung 1: Vorgehen zur Bearbeitung der Forschungsfragen .................................. 4

Abbildung 2: Aufbau der Arbeit (Kapitelnummern in Kreisen) ...................................... 5

Abbildung 3: V-Modell als Makrozyklus [VDI-Richtlinie 2206] ......................................... 9

Abbildung 4: Systems Engineering und die darin beinhalteten Methoden und

Vorgehensmodelle [NASA STI 2007, S. 4] ................................................. 11

Abbildung 5: Der Systems Engineering Prozess nach [Department of Defense

2001, S. 31] ................................................................................................... 12

Abbildung 6: V-Modell nach ISO 26262 [ISO 26262-2] .................................................. 14

Abbildung 7: Matrixorganisation in der Automobilindustrie [Königs et al. 2012,

S. 925] ........................................................................................................... 16

Abbildung 8: Übergreifende Vorgehensweise in der Automobilindustrie [Weber

2009, S. 12] ................................................................................................... 17

Abbildung 9: V-Modell des Fraunhofer IPK ..................................................................... 19

Abbildung 10: Vergleich der Vorgehensmodelle ............................................................ 21

Abbildung 11: Simulationsumgebungen auf Basis von Modelica [Otter 2011, S. 6] ... 27

Abbildung 12: Darstellung der LEDs des Toter-Winkel-Assistenten im

Geometriemodell des Außenspiegels (vgl. [Amin et al. 2012]) ........... 29

Abbildung 13: Schematische Darstellung des Objekts „Tracelink“ ............................... 38

Abbildung 14: Quantitative Traceability am Beispiel des mechatronischen

Außenspiegels ............................................................................................. 40

Abbildung 15: Darstellungsform von Tracelinks in DOORS im Textmodus .................... 51

Abbildung 16: Theoretisches Traceability-Schema in Teamcenter [Siemens

PLM Software 2011] .................................................................................... 56

Abbildung 17: Die METUS-Methode für das Systemdesign [ID-Systems GmbH

2013] ............................................................................................................. 58

Abbildung 18: Matizen als Kernelement der Software LOOMEO [Teseon GmbH

2012] ............................................................................................................. 59

Abbildung 19: Tracelinks in ToolNet (in Anlehnung an [Rosenauer 2008, S. 100]) ....... 62

Abbildung 20: Darstellung der Suchergebnisse von ConWeaver (strukturiert

nach Ergebnislisten) [Abbildung mit freundlicher Genehmigung

zur Publikation von der ConWeaver GmbH (www.conweaver.de)

bereitgestellt] .............................................................................................. 63

Abbildung 21: Anlegen eines Tracelinks im ModelTracer ............................................... 65

Abbildung 22: Datenmodell des ModelTracers ............................................................... 66

Abbildung 23: Ariadne's Eye zur Visualisierung der Artefakte und Tracelinks .............. 67

Abbildungsverzeichnis

xviii

Abbildung 24: Methode "Distributed Modeling of Component DSM" zur

Verringerung des Aufwands bei der Modellierung von Tracelinks

(in Anlehnung an [Tilstra et al. 2009, S. 245]) .......................................... 83

Abbildung 25: Beispiel einer Inklusionshierarchie [Grobstein 1973, S. 32] .................... 87

Abbildung 26: Kategorisierung der Tierwelt mit Hilfe einer subsumtiven

Inklusionshierarchie .................................................................................... 87

Abbildung 27: Ableitung von Tracelinks durch Ausnutzung der Transitivität ............... 88

Abbildung 28: Schematische Darstellung der Zusammensetzung von

Eigenschaften (visualisiert durch farbige Quadrate) in

kompositionellen (links) und subsumtiven Inklusionshierarchien

(rechts) ........................................................................................................ 90

Abbildung 29: Strukturierung des Anforderungsartefakts mit Hilfe der

Konkretisierung ........................................................................................... 92

Abbildung 30: Strukturierung des Anforderungsartefakts mit Hilfe der

Partitionierung ............................................................................................ 92

Abbildung 31: Strukturierung des Anforderungsartefakts mit Hilfe der Projektion ...... 93

Abbildung 32: Strukturierung des Funktionsartefakts mit Hilfe einer Hierarchie .......... 94

Abbildung 33: Dreidimensionale Blockdarstellung einer Funktionsstruktur [Pahl et

al. 2007, S. 45] ............................................................................................. 95

Abbildung 34: Strukturierung des Funktionsartefakts mit Hilfe einer

Funktionsstruktur ......................................................................................... 95

Abbildung 35: Strukturierung eines Verhaltensartefakts ................................................. 96

Abbildung 36: Ausschnitt einer beispielhaften Strukturierung eines Außenspiegels

a) unter Berücksichtigung von Montagegesichtspunkten und b)

entsprechend der Funktionen .................................................................. 98

Abbildung 37: Schematischer Aufbau einer Produktstruktur ......................................... 98

Abbildung 38: Aufbau von Artefakten im Systems Engineering und Einordnung

der Begriffe "Granularität", "Detaillierungsgrad" und "hierarchische

Ebene" ....................................................................................................... 100

Abbildung 39: Granularitätsebenen bei der Modellierung von Tracelinks................ 101

Abbildung 40: Auszug aus dem Anforderungs- und Funktionsartefakt des

mechatronischen Außenspiegels .......................................................... 102

Abbildung 41: Folgen der Reduktion der Granularität auf die Auswertung von

Tracelinks: a) durch eine niedrige Granularität werden viele

Tracelinks zwischen Elementen vererbt, bei denen keine

Abhängigkeit besteht. b) durch die Wahl einer höheren

Granularität werden nur tatsächlich Abhängige Elemente

verknüpft. .................................................................................................. 104

Abbildung 42: Vorgehensweise zur Erfassung von Abhängigkeiten am Beispiel

einer DSM (in Anlehnung an [Maurer 2007, S. 98]) .............................. 105

Abbildungsverzeichnis

xix

Abbildung 43: Abstraktes Beispiel zur Ermittlung des Aufwands .................................. 106

Abbildung 44: Bei der Auswertung wird überprüft, ob auf höchster

hierarchischer Ebene ein Tracelink vorhanden ist (dargestellt

durch die graue gestrichelte Linie), wenn deren Kinderelemente

einen Tracelink aufweisen (dargestellt durch die rote

durchgängige Linie). Ist dem nicht so, wird ein Widerspruch

registriert. .................................................................................................... 109

Abbildung 45: Beispieldarstellung einer in der Studie verwendeten

Abhängigkeitsmatrix ................................................................................ 110

Abbildung 46: Schematische Darstellung des Kaffeevollautomaten (links:

Übersicht, rechts: Darstellung der Baugruppe Auffangeinheit mit

beschrifteten Einzelteilen) ....................................................................... 111

Abbildung 47: Schematische Darstellung des Fahrrads (links: Übersicht, rechts:

Darstellung der Antriebssystems mit beschrifteten Einzelteilen) ........ 111

Abbildung 48: Korrelation zwischen der Selbsteinschätzung und der Anzahl der

Widersprüche ............................................................................................ 115

Abbildung 49: Funktionsprinzip der Methode EcoTracing ............................................ 119

Abbildung 50: Untersuchung der Artefakte auf Abhängigkeiten zwischen den

Elementen ................................................................................................. 119

Abbildung 51: Markierung von Elementkombinationen bei nicht vorhandener

Abhängigkeit ............................................................................................ 120

Abbildung 52: Modellierung von Tracelinks und Markierung der Kinder-Elemente

für eine spätere Untersuchung ............................................................... 121

Abbildung 53: Algorithmus der EcoTracing Methode (zunächst Erfassung der

Tracelinks auf hoher hierarchischer Ebene und folgend

schrittweise Erhöhung der Granularität)................................................ 122

Abbildung 54: Vergleich der Online- mit der Offline-Erfassung von Tracelinks:

kontinuierliche, jedoch unvollständige Online-Analyse gegenüber

einer vollständigen Offline-Analyse zu bestimmten Zeitpunkten im

Entwicklungsprozess (hier dargestellt: zum Ende der jeweiligen

Phase) ........................................................................................................ 123

Abbildung 55: Graphical User Interface (GUI) des EcoTracers ................................... 125

Abbildung 56: Notwendige Parameter zur Bestimmung des Aufwands unter

Verwendung von EcoTracing ................................................................. 127

Abbildung 57: Beispiel zur Erläuterung der Ermittlung der Anzahl der

Entscheidungen unter Verwendung von EcoTracing

(Elementkombinationen, bei denen eine Entscheidung getroffen

werden muss, sind schraffiert dargestellt) ............................................. 128

Abbildung 58: Übersicht der Artefakte des Fahrradbeispiels ....................................... 129

Abbildungsverzeichnis

Abbildung 59: Häufigkeit in der unterschiedliche Anzahlen von Probanden

übereinstimmen und somit einen bzw. keinen Tracelink modelliert

haben ........................................................................................................ 136

Abbildung 60: Ersparte Entscheidungen durch EcoTracing im Vergleich zur

manuellen Methode (in %) ..................................................................... 136

Abbildung 61: Regeln zur Ableitung von Abhängigkeiten nach [Maurer 2007,

S. 95] ........................................................................................................... 144

Abbildung 62: Verwendung eines Glossars, um wichtige Begriffe in textuellen

Beschreibungen identifizieren zu können [Cerbah und Euzenat

2001, S. 33] ................................................................................................. 146

Abbildung 63: Typisches Crowdsourcing System [Geiger et al. 2011, S. 2] ............... 150

Abbildung 64: Taxonomie zur Beschreibung der Eigenschaften von

Crowdsourcing-Systemen [Geiger et al. 2011, S. 6] ............................ 151

Abbildung 65: Ablauf der Methode TraceEvaluation .................................................. 155

Abbildung 66: TraceEvaluation als Crowdsourcing-System in Anlehnung an

[Geiger et al. 2011, S. 2] .......................................................................... 157

Abbildung 67: Melden eines falschen Tracelinks in Ariadne's Eye.............................. 158

Abbildung 68: Auswertungsmodul zur Analyse der gemeldeten falschen

Tracelinks ................................................................................................... 159

Abbildung 69: Algorithmus zur Zusammenstellung angezweifelter Tracelinks .......... 160

Abbildung 70: Funktionsprinzip der Methode TraceLegacy ........................................ 168

Abbildung 71: Schematische Darstellung der Verwaltung der Ähnlichkeitswerte

in Form von Matrizen ............................................................................... 170

Abbildung 72: Algorithmus der Abhängigkeitsanalyse mit TraceLegacy ................. 171

Abbildung 73: GUI des Prototyps der Methode TraceLegacy .................................... 172

Abbildung 74: Verwaltung der beiden Projekte im ModelTracer (Artefakte des

Vorgängerprojekts „Fahrrad“ wurden mit dem Präfix „__“

versehen). ................................................................................................. 175

Abbildung 75: Ergebnisliste der prototypischen Implementierung der Methode

TraceLegacy anhand der Beispiele „Fahrrad“ und „Pedelec“ ........ 176

Abbildung 76: Verortung der Methoden im V-Modell des Fraunhofer IPK ................ 184

Abbildung 77: Darstellung der durchgeführten Prozessschritte während der

Entwicklung des mechatronischen Außenspiegels ............................. 186

Abbildung 78: Darstellung eines Ausschnitts der Anforderungshierarchie (links)

sowie Eigenschaften der Anforderung „Maximum Angle“ (rechts)

in CATIA V6 (vgl. [Amin et al. 2012]) ...................................................... 188

Abbildung 79: Funktionsstruktur des mechatronischen Außenspiegels [Amin et

al. 2012] ..................................................................................................... 189

Abbildungsverzeichnis

xxi

Abbildung 80: Anlegen einer Implementierungsbeziehung zwischen einer

Anforderung und einer Funktion (vgl. [Amin et al. 2012]) ................... 191

Abbildung 81: Anwendung der Methode EcoTracing zur Abhängigkeitsanalyse

zwischen Anforderungen und Funktionen des Außenspiegels .......... 192

Abbildung 82: Modelica-Modell zur Simulation des Verhaltens der

Spiegelglasbeheizung (vgl. [Amin et al. 2012]) .................................... 194

Abbildung 83: Impact Analyse in Ariadne's Eye & Anwendung der Methode

TraceEvaluation ........................................................................................ 199

Abbildung 84: Auswertungsmodul der Methode TraceEvaluation ............................. 199

Abbildung 85: Ergebnis der Analyse mittels TraceLegacy ........................................... 200

Abbildung 86: Übersicht der erstellten Artefakte, modellierter Tracelinks (rote

Pfeile) sowie der erreichten Ersparnis durch EcoTracing (wenn

angewendet) ............................................................................................ 201

Abbildung 87: Einordnung der Methoden EcoTracing, TraceEvaluation und

TraceLegacy in einem beispielhaften vierstufigen IT-

Architekturkonzept (in Anlehnung an [Eigner und Stelzer 2009,

S. 43]) .......................................................................................................... 209

xxiii

TABELLENVERZEICHNIS

Tabelle 1: Traceability-Eigenschaften von DOORS (eine Erläuterung der

Kategorien sowie Eigenschaften ist in den Kapiteln 3.3 und 3.4 zu

finden) .......................................................................................................... 52

Tabelle 2: Traceability-Eigenschaften von Reqtify (eine Erläuterung der

Kategorien sowie Eigenschaften ist in den Kapiteln 3.3 und 3.4 zu

finden) .......................................................................................................... 54

Tabelle 3: Traceability-Eigenschaften der V6-Suite (eine Erläuterung der

Kategorien sowie Eigenschaften ist in den Kapiteln 3.3 und 3.4 zu

finden) .......................................................................................................... 55

Tabelle 4: Traceability-Eigenschaften von Teamcenter (eine Erläuterung der

Kategorien sowie Eigenschaften ist in den Kapiteln 3.3 und 3.4 zu

finden) .......................................................................................................... 57

Tabelle 5: Traceability-Eigenschaften von METUS (eine Erläuterung der

Kategorien sowie Eigenschaften ist in den Kapiteln 3.3 und 3.4 zu

finden) .......................................................................................................... 59

Tabelle 6: Traceability-Eigenschaften von LOOMEO (eine Erläuterung der

Kategorien sowie Eigenschaften ist in den Kapiteln 3.3 und 3.4 zu

finden) .......................................................................................................... 60

Tabelle 7: Traceability-Eigenschaften von ToolNet (eine Erläuterung der

Kategorien sowie Eigenschaften ist in den Kapiteln 3.3 und 3.4 zu

finden) .......................................................................................................... 62

Tabelle 8: Traceability-Eigenschaften von ConWeaver (eine Erläuterung der

Kategorien sowie Eigenschaften ist in den Kapiteln 3.3 und 3.4 zu

finden) .......................................................................................................... 64

Tabelle 9: Traceability-Eigenschaften des ModelTracers (eine Erläuterung

der Kategorien sowie Eigenschaften ist in den Kapiteln 3.3 und

3.4 zu finden) ............................................................................................... 68

Tabelle 10: Traceability-Eigenschaften der betrachteten Software-Tools (D –

DOORS, R – Reqtify, V – V6-Suite, T – Teamcenter, M – Metus, L –

Loomeo. N – ToolNet, C – ConWeaver, MT – ModelTracer) ................. 76

Tabelle 11: Zuordnung von verwendeten Artefakten zur Art der Hierarchie ......... 99

Tabelle 12: Eigenschaften der Studie zur Überprüfung der Hypothese 1* ........... 113

Tabelle 13: Ergebnis der Studie zur Überprüfung der Hypothese 1*

(Erläuterung, was als Widerspruch gezählt wird, in Abbildung 44) ... 114

Tabelle 14: Kumulierte Widersprüche des Fahrrad-Beispiels ................................... 116

Tabelle 15: Kumulierte Widersprüche des Kaffeevollautomaten-Beispiels .......... 117

Tabelle 16: Eigenschaften der Studie zur Überprüfung der Hypothese 1 ............. 131

Tabellenverzeichnis

xxiv

Tabelle 17: Darstellung der durch Proband 1 modellierten Tracelinks für die

Artefaktkombination (Anforderungen «» Funktionen) ........................ 131

Tabelle 18: Studienergebnisse für die Anzahl der Entscheidungen und die

Ersparnis an Entscheidungen durch Anwendung von EcoTracing

pro Proband zwischen Anforderungen (A), Funktionen (F) und

Produktelementen (P) ............................................................................. 132

Tabelle 19: Aggregierte Anzahl modellierter Tracelinks zwischen

Anforderungen und Funktionen (fette Zahlen markieren eine Zelle

in der ein Tracelink durch den Autor modelliert wurde)..................... 134

Tabelle 20: Kategorisierung der Methoden des Stands der Technik .................... 147

Tabelle 21: Bewertung der Größen Präzision (Precision) und Trefferquote

(Recall) [Hayes et al. 2006, S. 11] ........................................................... 153

Tabelle 22: Elementepaare, zwischen denen im Vorfeld der Studie falsche

Tracelinks modelliert wurden .................................................................. 161

Tabelle 23: Eigenschaften der Studie zur Überprüfung der Hypothese 2 ............ 162

Tabelle 24: Meldung von Tracelinks pro Proband ................................................... 163

Tabelle 25: Übersicht der Elementepaare, die von den Probanden als falsch

gemeldet wurden .................................................................................... 164

Tabelle 26: Charakterisierung des Vorgängerprojekts Fahrrad ............................. 173

Tabelle 27: Charakterisierung des aktuellen Projekts Pedelec .............................. 174

Tabelle 28: Evaluationsergebnis ohne Stammformrückführung (Auszug) ........... 176

Tabelle 29: Evaluationsergebnis mit Stammformrückführung (Auszug) ............... 178

Tabelle 30: Eigenschaften der initialen Anforderungsspezifikation ....................... 187

Tabelle 31: Eigenschaften der Anforderungsspezifikation des

mechatronischen Außenspiegels .......................................................... 188

Tabelle 32: Eigenschaften der Funktionsstruktur des mechatronischen

Außenspiegels .......................................................................................... 190

Tabelle 33: Eigenschaften des Verhaltensmodells des mechatronischen

Außenspiegels .......................................................................................... 194

Tabelle 34: Eigenschaften der Produktstruktur des mechatronischen

Außenspiegels .......................................................................................... 196

1 EINLEITUNG UND ZIELSETZUNG

Die im Titel erwähnte Traceability ist ein aus der Informatik stammender Ansatz, des-

sen Anwendung im Kontext der Systementwicklung eine Antwort auf die Herausfor-

derungen heterogener Entwicklungslandschaften bietet. Die vorliegende Arbeit

widmet sich diesem Thema aus Sicht der Entwicklung von Methoden zur effizienten

Modellierung und Pflege von Tracelinks, die für eine stärkere industrielle Verbreitung

der durchgängigen Nachverfolgbarkeit unabdingbar ist. In Kapitel 1.1 wird zunächst

die Ausgangssituation und Zielsetzung der Forschungen auf diesem Gebiet erläutert,

bevor anschließend in Kapitel 1.2 die Formulierung der Forschungsfragen erfolgt. Die

für die Beantwortung dieser Fragen gewählte Vorgehensweise sowie die Verortung

der Ergebnisse in der Struktur der vorliegenden Arbeit wird abschließend in Kapitel 1.3

erläutert.

1.1 AUSGANGSSITUATION UND ZIELSETZUNG DER ARBEIT

Die Entwicklung von Produkten hat sich in den vergangenen Jahrzehnten stark ver-

ändert. Lag früher der Fokus auf der Detaillierung meist mechanischer Wirkprinzipien,

finden sich die Herausforderungen heute im Bereich der Orchestrierung der unter-

schiedlichen Entwicklungsdisziplinen, um ein optimales mechatronisches Produkt zu

entwickeln [VDI-Richtlinie 2206, S. 4].

Zahlreiche Vorgehensmodelle befassen sich mit dieser Herausforderung, indem das

Produkt bspw. zunächst unter funktions- oder systemorientierten Gesichtspunkten

konzipiert wird, um einen gemeinsamen Ausgangspunkt für die weitere Entwicklung

Einleitung und Zielsetzung

zu etablieren. In der Praxis haben diese jedoch einen geringen Verbreitungsgrad, da

die hohen aufzubringenden Aufwände einem, in der industriellen Anwendung als

zweifelhaft angesehenen, Nutzen gegenüberstehen. Vor diesem Hintergrund ist es

den Entwicklern komplexer Systeme unmöglich, Abhängigkeiten der Subsysteme voll-

ständig zu erfassen und die Auswirkungen von Änderungen in ihrem Entwicklungsbe-

reich umfassend abzuschätzen.

Die Etablierung durchgängiger Nachverfolgbarkeit (engl.: Traceability) ist in diesem

Zusammenhang eine Methode, die Antworten auf diese Herausforderungen bereit-

stellt. Dabei werden die Abhängigkeiten zwischen den unterschiedlichen Modellen,

die während der Produktentwicklung entstehen, mit Hilfe sog. Tracelinks explizit do-

kumentiert, um bspw. die Umsetzung der vom Kunden definierten Anforderungen

verfolgen zu können. Jedoch beschränkt sich die Anwendung aktuell hauptsächlich

auf Bereiche, in denen sie durch den Gesetzgeber explizit gefordert wird. Die Poten-

ziale, die Tracelinks über den reinen Dokumentationszweck hinaus zu nutzen, werden

bisher in der Praxis noch nicht erkannt. Ferner gibt es eine Reihe von technologi-

schen, methodischen und sozialen Herausforderungen, die neben dem Aufwand für

die Erfassung der Abhängigkeiten sowie der Pflege der modellierten Tracelinks eine

sehr große Hürde für die industrielle Nutzung dieser Methode darstellen.

Diesen Aufwand gilt es zu reduzieren, um eine stärkere Verbreitung der Traceability

zu erreichen. Dabei wird es hinsichtlich der (teil-)automatisierten Unterstützung in ab-

sehbarer Zeit wohl keinen Goldstandard geben, der für alle denkbaren Situationen

während der Systementwicklung eine optimale Hilfe bei der Modellierung und Pflege

von Tracelinks darstellt. Dies liegt u. a. an den unterschiedlichen Ausprägungen der in

der Entwicklung verwendeten Modelle sowie deren informellen Notation. Somit ist

momentan eine Kombination unterschiedlicher unterstützender Methoden anzustre-

ben. Aizenbud-Reshef et al. sprechen in diesem Zusammenhang von einem Puzzle

[Aizenbud-Reshef et al. 2006, S. 523], bei dem die Methoden einzelne Puzzle-Teile

sind. Diese werden situationsgerecht und zielgerichtet während der Entwicklung ein-

gesetzt, um in Kombination eine möglichst umfassende Unterstützung zur Reduzie-

rung des Aufwands bei der Erstellung und Pflege von Tracelink-Modellen zu bilden.

Vor diesem Hintergrund besteht die Zielsetzung der vorliegenden Arbeit darin, Me-

thoden für die Vervollständigung dieses Puzzles bereitzustellen. Konkret handelt es

sich um die drei Methoden EcoTracing, TraceEvaluation sowie TraceLegacy, die der

effizienten Modellierung von Tracelinks und der Pflege von Tracelink-Modellen die-

nen. Alle drei Methoden bauen auf dem aktuellen Stand der Technik auf und gehen

jeweils in Teilaspekten über diesen hinaus. Dabei liegt der Forschungsbeitrag, den

diese Arbeit leistet, neben der grundlegenden konzeptionellen Entwicklung der Me-

Einleitung und Zielsetzung

thoden, in deren Evaluation, die anhand dreier Studien sowie einem vergleichenden

Beispiel durchgeführt wurde.

1.2 FORSCHUNGSFRAGEN

Die Forschungsfragen, die in diesem Zusammenhang untersucht werden, sind hin-

sichtlich ihrer Ausrichtung den Bereichen Modellierung von Tracelinks sowie Pflege

von Tracelink-Modellen zuzuordnen. Der erste Bereich adressiert dabei methodische

Vorgehensweisen für die Reduktion des Aufwands zur Erfassung von Tracelinks:

Kann methodische Unterstützung helfen, den Aufwand bei der Modellie-

rung von Tracelinks zu reduzieren? Wie muss diese ausgeprägt sein?

Die Forschungsfrage adressiert den Aspekt, dass bislang zu wenige Methoden zur Er-

fassung von Tracelinks existieren und eher unstrukturierte Vorgehensweisen, bei de-

nen leicht Abhängigkeiten übersehen werden können, verbreitet sind. Darüber hin-

aus besteht die Frage, ob eine Methode zur strukturierten Modellierung von Tracelinks

ebenfalls die dafür notwendigen Aufwände reduzieren kann.

Der zweite zu erforschende Bereich betrifft die Pflege von Tracelink-Modellen, die

aufgrund sich dynamisch ändernder Modelle zwingend notwendig ist. Es wurden

dabei zwei unterschiedliche Forschungsrichtungen verfolgt. Zum einen, ob die Nutzer

der Tracelinks in die Qualitätssicherung des Tracelink-Modells mit einbezogen werden

können:

Können Methoden des Crowdsourcings zur Steigerung der Qualität des

Tracelink-Modells genutzt werden?

Das Crowdsourcing (deutsch: Schwarmauslagerung) ist eine relativ neuer Ansatz, der

vor allen Dingen bei einer Vielzahl von Diensten im Internet zu finden ist [Estelles-

Arolas und Gonzalez-Ladron-de-Guevara 2012], bislang noch keine Berücksichtigung

im Kontext der durchgängigen Nachverfolgbarkeit findet, sich aber potenziell für die

Steigerung der Qualität des Tracelink-Modells eignen könnte.

Die zweite Forschungsfrage im Bereich der Pflege von Tracelink-Modellen befasst sich

hingegen mit einer speziellen Art der Wiederverwendung von Traceability-

Informationen:

Kann das Wissen, welches mithilfe von Tracelinks in vergangenen Projekten

dokumentiert wurde, in aktuellen Projekten zur Steigerung der Qualität des

Tracelink-Modells genutzt werden?

Einleitung und Zielsetzung

In diesem Kontext wurde erforscht, ob Wissen über Abhängigkeiten zwischen Elemen-

ten, welches in vergangenen Projekten aufwändig mit Hilfe von Tracelinks dokumen-

tiert wurde, wiederverwendet und somit zur Generierung von Vorschlägen für feh-

lende Tracelinks in aktuellen Projekten herangezogen werden kann.

Grundsätzlich ist anzumerken, dass die im Rahmen dieser Arbeit vorgestellten Soft-

wareprototypen primär dem Zweck dienen, die entwickelten Methoden zu evaluie-

ren, weshalb der wissenschaftliche Fokus der Ausführungen jeweils auf der Entwick-

lung und Bewertung der Methoden und nicht auf der entsprechenden Software-

Implementierung liegt.

1.3 VORGEHEN UND AUFBAU DER ARBEIT

Das methodische Vorgehen zur Beantwortung der im vorangehenden Kapitel 1.2 zu-

sammengestellten Forschungsfragen wurde an die Design Research Methodology

(DRM) von Blessing und Chakrabarti angelehnt [Blessing und Chakrabarti 2009]. Diese

umfasst vier grundlegende Untersuchungen, die je nach Forschungsaufgabe unter-

schiedlich ausgeprägt und unterschiedlich oft durchlaufen werden können. Im vor-

liegenden Fall wurden die ersten beiden Phasen (Klärung der Forschung und deskrip-

tive Untersuchung I) zusammengefasst und anschließend die präskriptive Untersu-

chung sowie die deskriptive Untersuchung II für jede der drei identifizierten For-

schungsfragen durchgeführt (Abbildung 1).

Abbildung 1: Vorgehen zur Bearbeitung der Forschungsfragen

Einleitung und Zielsetzung

Die erste deskriptive Untersuchung umfasste eine Literaturanalyse und die Durchfüh-

rung zweier Anwender-Studien, um den Stand der Technik im Bereich der Vorge-

hensmodelle und der durchgängigen Nachverfolgbarkeit zu erfassen und auf dieser

Basis Defizite der aktuellen Methoden zu identifizieren. Aus diesen wurden im Folgen-

den drei Forschungsfragen und zugehörige Hypothesen entwickelt, welche die For-

schungsrichtungen für die präskriptiven Untersuchungen A-C vorgegeben haben. In

diesen Untersuchungen wurden Methoden durch den Autor dieser Arbeit entwickelt

und prototypisch implementiert. Konkret handelt es sich um Methoden zur effizienten

Modellierung von Tracelinks, zur Bewertung von Tracelinks sowie zur Verwendung von

Abhängigkeits-Informationen aus vergangenen Projekten, die in den anschließenden

deskriptiven Untersuchungen II mit Hilfe von Studien und Evaluationen überprüft wur-

den.

Abbildung 2: Aufbau der Arbeit (Kapitelnummern in Kreisen)

Einleitung und Zielsetzung

Auch der Aufbau der Arbeit orientiert sich folglich an der DRM und ist in Abbildung 2

inkl. einer Unterteilung der Kapitel nach Stand der Technik (hellgrau hinterlegt) und

Methodenentwicklung

(dunkelgrau hinterlegt) festgehalten. Die Ergebnisse der Ana-

lyse des Standes der Technik (deskriptive Studie I) und damit auch eine Einführung in

Grundbegriffe durchgängiger Nachverfolgbarkeit sind in den Kapiteln 2 und 3 do-

kumentiert. Die detaillierte Beschreibung der Methode zur effizienten Modellierung

von Tracelinks (EcoTracing) ist in Kapitel 5 zu finden. Die Methoden zur Bewertung

von Tracelinks (TraceEvaluation) und Verwendung von Wissen über Abhängigkeiten

in vergangenen Projekten (TraceLegacy), die thematisch der Pflege von Traceability-

Informationen zugerechnet werden, sind in Kapitel 6 dokumentiert.

Um die Anwendung und Funktionsweisen der entwickelten Methoden in einem realis-

tischen Umfeld anschaulich darzustellen, wird zusätzlich auf die Ergebnisse der Lehr-

veranstaltung „Virtual Engineering in Industry“ des Wintersemesters 2011/12 zurück-

gegriffen. Im Rahmen dieser Veranstaltung wurde in Gruppenarbeit ein mechatroni-

scher Außenspiegel durch die Studenten Aroon Amin, Mohamad Said al-Dahabi,

Fabian Friedrich und Justus Thiele entwickelt [Amin et al. 2012]. Dieses Beispiel wird im

Rahmen dieser Arbeit analysiert und die Ergebnisse dieser Analyse, zugehörig zu den

einzelnen behandelten Aspekten, in den unterschiedlichen Kapiteln dargestellt. So

wird die Vorgehensweise der Studenten in Kapitel 2.1 im Kontext anderer Vorge-

hensmodelle erläutert und diskutiert. Zusätzlich wird der Einsatz der im Rahmen dieser

Arbeit entwickelten Methoden anhand des Außenspiegel-Beispiels in Kapitel 7 be-

schrieben, um deren Anwendung bei der Entwicklung eines mechatronischen Pro-

dukts zu verdeutlichen.

Bei der Entwicklung und Evaluation der Methoden (EcoTracing, TraceEvaluation und

TraceLegacy) sowie der Demonstration ihrer Anwendung handelt es sich um die eigentli-

che Forschungsleistung des Autors dieser Arbeit.

2 ENTWICKLUNG MECHATRONISCHER SYSTEME

Vor dem Hintergrund durchgängiger Nachverfolgbarkeit ist eine genauere Untersu-

chung des Vorgehens bei der Entwicklung mechatronischer Systeme notwendig.

Dieses wird in Kapitel 2.1 beschrieben, unterschiedliche Vorgehensweisen verglichen

und Unterschiede sowie Gemeinsamkeiten herausgestellt. Eine dieser Gemeinsam-

keiten ist, dass während der Entwicklung verschiedene Artefakte

zur Beschreibung

des Entwicklungsgegenstands ausgearbeitet werden. Diese Artefakte werden in Ka-

pitel 2.2 vorgestellt und hinsichtlich ihrer Abhängigkeiten zueinander analysiert. Ab-

schließend werden die wichtigsten Aspekte der Vorgehensmodelle und Artefakte in

Kapitel 2.3 zusammengefasst, die Abhängigkeiten zwischen diesen noch einmal her-

ausgestellt und somit die Überleitung zur durchgängigen Nachverfolgbarkeit, die im

Detail in Kapitel 3 vorgestellt wird, geschaffen.

2.1 VORGEHENSMODELLE ZUR ENTWICKLUNG MECHATRONISCHER SYSTEME

Zur Entwicklung mechatronischer Systeme wurden von unterschiedlichen Institutionen

Vorgehensmodelle entwickelt, die helfen sollen, disziplinspezifische Vorgehensweisen

zusammenzuführen und die Entwicklung zu koordinieren. So hat der Verein Deutscher

Ingenieure (VDI) ergänzend zu seinen Richtlinien 2221 und 2422 die Richtlinie 2206 zu

deren Integration herausgegeben (siehe Kapitel 2.1.1). Aus dem Bereich der Luft-

Als Artefakt werden zusammenfassend jegliche Art von produktbeschreibenden Informati-

onen (Spezifikationen, Funktionsstrukturen, Produktstrukturen etc.) bezeichnet [Cleland-

Huang et al. 2003, S. 797].

Entwicklung mechatronischer Systeme

und Raumfahrt heraus hat sich das Systems Engineering entwickelt und gilt heute als

wichtiges Vorgehensmodell für die disziplinübergreifende und vor allen Dingen sys-

temübergreifende Entwicklung mechatronischer Systeme (siehe Kapitel 2.1.2). Die

von der Internationalen Organisation für Normung (ISO) herausgebrachte Norm ISO

26262 adressiert hingegen die Automobilbranche und in diesem Kontext insbesonde-

re die Entwicklung sicherheitsrelevanter E/E-Systeme (siehe Kapitel 2.1.3). Da diese

Vorgehensmodelle in der Industrie nur punktuell und selten ohne Änderungen einge-

setzt werden, wird in Kapitel 2.1.4 zusätzlich exemplarisch auf industrielle Vorgehens-

weisen eingegangen. Darüber hinaus wird das am Fraunhofer IPK entwickelte V-

Modell in Kapitel 2.1.5 beschrieben. Dieses Vorgehensmodell ist insbesondere vor

dem Hintergrund relevant, da es von einer Studentengruppe zur Entwicklung eines

mechatronischen Außenspiegels verwendet wurde, welcher im weiteren Verlauf der

Arbeit als durchgängiges Beispiel fungiert. Abschließend werden die unterschiedli-

chen Vorgehensmodelle in Kapitel 2.1.6 verglichen und Unterschiede diskutiert.

Das Ziel dieses Kapitels ist es, darzustellen wie unterschiedliche Entwicklungsdisziplinen

für die Entwicklung mechatronischer Systeme zusammenwirken müssen und welche

unterschiedlichen Schritte dafür notwendig sind. Diese Grundlagen helfen im weite-

ren Verlauf der Arbeit bei der Identifikation der unterschiedlichen Artefakte und im

Folgenden bei der Ableitung des Bedarfs nach einer durchgängigen Nachverfolg-

barkeit bei der Entwicklung mechatronischer Systeme.

2.1.1 VDI 2206 – ENTWICKLUNGSMETHODIK FÜR MECHATRONISCHE SYSTEME

Die VDI 2206 ist eine vom Verein Deutscher Ingenieure herausgegebene Richtlinie in

der eine Entwicklungsmethodik für mechatronische Systeme beschrieben wird [VDI-

Richtlinie 2206]. Sie zielt auf die Bereitstellung von Methoden und Werkzeugen für die

frühen Phasen des Entwickelns mit dem Schwerpunkt des Systementwurfs. Dabei liegt

besonderes Augenmerk auf Kommunikation und Kooperation zwischen den unter-

schiedlichen, an der Entwicklung beteiligten Disziplinen. Sie ergänzt damit die Richtli-

nien VDI 2221 und VDI 2422 und stellt einen übergreifenden Integrationsansatz für de-

ren domänenspezifische Entwicklungsvorgehensweisen dar.

Die Richtlinie umfasst drei grundsätzliche Elemente, von denen im Folgenden jedoch

vor allen Dingen das V-Modell als Makrozyklus sowie die Prozessbausteine für wieder-

kehrende Arbeitsschritte, die die Prozessschritte im V-Modell darstellen, näher erläu-

tert werden. Der Problemlösungszyklus auf Mikroebene, der als Hilfestellungen für

Produktentwickler dienen soll, ist vor dem Hintergrund der vorliegenden Arbeit weni-

ger relevant und wird deshalb nicht beschrieben.

Entwicklung mechatronischer Systeme

Das V-Modell als Makrozyklus beschreibt eine Vorgehensempfehlung für die Entwick-

lung mechatronischer Systeme. Es besteht aus den Tätigkeiten Systementwurf, do-

mänenspezifischer

Entwurf, Modellbildung und -analyse, Systemintegration und Ei-

genschaftsabsicherung, um von den definierten Anforderungen zum fertigen Produkt

zu gelangen (siehe Abbildung 3). Dabei kann das V-Modell mehrfach durchlaufen

und so bspw. zunächst Labormuster entwickelt werden, um sich dann sukzessive zum

finalen Produkt zu iterieren.

Abbildung 3: V-Modell als Makrozyklus [VDI-Richtlinie 2206]

In jedem Fall beginnt der Zyklus mit der Definition von Anforderungen, die die Aufga-

benstellung und damit die Basis für den Systementwurf darstellen. Dieser Entwurf be-

inhaltet zunächst die Entwicklung einer Funktionsstruktur, die aus den Teilfunktionen

des Produkts aufgebaut wird. Deren Ziel ist es, das Verhalten zu beschreiben, Inkonsis-

tenzen zu identifizieren und Wirkprinzipien bzw. Lösungselemente für die einzelnen

Funktionen zu finden. Diese so definierten Wirkstrukturen werden weiter zu prinzipiel-

len Lösungsvarianten detailliert, die bewertet werden. Ergebnis des Systementwurfs ist

ein Lösungskonzept, welches die grundsätzlichen Funktionsprinzipien und Zusammen-

hänge des Systems disziplinübergreifend definiert.

Dieses Lösungskonzept, in dem die Funktionen auf die Disziplinen partitioniert werden,

bildet die Grundlage für den folgenden disziplinspezifischen Entwurf. Dieser soll laut

VDI nach etablierten Vorgehensweisen ablaufen (z. B. VDI 2221) und wird im Rahmen

der Richtlinie nicht weiter spezifiziert. Das Ergebnis dieses detaillierten Designs sind

mehrere Lösungsvarianten, die im Rahmen der anschließenden Systemintegration zu

Im Rahmen dieser Arbeit wird der Begriff „disziplinspezifisch“ verwendet.

Entwicklung mechatronischer Systeme

mehreren Gesamtsystemvarianten zusammengeführt und auf mögliche Inkompatibi-

litäten untersucht werden. Die Integration wird dabei durch die Eigenschaftsabsiche-

rung begleitet, in der die integrierten Gesamtsystemvarianten gegenüber dem Sys-

tementwurf bzw. der Anforderungsliste verifiziert und validiert werden. Mit Hilfe dieser

Bewertungen können die unterschiedlichen Varianten verglichen, nicht umsetzbare

ausgeschlossen und eine optimale ausgewählt werden.

Sowohl der Systementwurf, der domänenspezifische Entwurf als auch die Systemin-

tegration werden dabei von der Modellbildung und -analyse begleitet, um bspw.

das Systemverhalten abzubilden oder die Feindimensionierung durchzuführen. Auch

bei der Eigenschaftsabsicherung spielen Modelle im Rahmen von zunehmend virtuel-

len Versuchen eine große Rolle. Die Modelle, die hierbei entwickelt werden, bauen

laut Richtlinie idealerweise aufeinander auf. In diesem Zusammenhang wird zwar

nicht von Traceability, jedoch von Durchgängigkeit gesprochen, die über alle Ent-

wicklungsphasen angestrebt werden sollte.

2.1.2 SYSTEMS ENGINEERING

Die INCOSE (International Council on Systems Engineering) definiert Systems Enginee-

ring als eine Vorgehensweise und Hilfsmittel für die Realisierung erfolgreicher Systeme

[Haskins 2006, S. 2.01]. Etwas spezifischer ist die Definition des US amerikanischen Ver-

teidigungsministeriums (Department of Defense), welches Systems Engineering als in-

terdisziplinären Managementprozess für Entwicklungen sieht, mit dessen Hilfe Syste-

me, die Kundenbedürfnisse befriedigen, entwickelt und verifiziert werden können

[Department of Defense 2001, S. 3].

Das zu entwickelnde System wird dabei als Zusammenstellung unterschiedlicher, mit-

einander interagierender Systemelemente definiert, die ein gemeinsames oder meh-

rere Ziele verfolgen [Department of Defense 2001, S. 3; Haskins 2006, S. 1.5]. Dabei

wird der Mehrwert des Systems gegenüber den einzelnen Elementen durch deren Zu-

sammenwirken, und damit deren Abhängigkeiten untereinander, definiert. Unter-

scheidungsmerkmal im Vergleich zu anderen Vorgehensmodellen ist beim Systems

Engineering, dass diese Systemelemente nicht ausschließlich technischer Natur sein

müssen, sondern, je nach Festlegung der Systemgrenze, neben Bauteilen oder Soft-

ware auch Personen, Einrichtungen, Dokumente oder Richtlinien sein können

[NASA STI 2007, S. 3].

Zur Entwicklung dieser Systeme stellt das Systems Engineering zahlreiche technische

und nicht-technische Vorgehensweisen und Methoden bereit, die neben der eigent-

lichen Entwicklung auch auf deren Management zielen (siehe Abbildung 4)

[NASA STI 2007, S. 4]. Besonderer Fokus liegt dabei auch auf der Reduzierung von Risi-

Entwicklung mechatronischer Systeme

ken, die mit der Neuentwicklung bzw. Anpassung bestehender komplexer Systeme

verbunden sind [Haskins 2006, S. 2.05].

Abbildung 4: Systems Engineering und die darin beinhalteten Methoden und Vorgehens-

modelle [NASA STI 2007, S. 4]

Grundsätzlich ist anzumerken, dass zum Thema Systems Engineering unterschiedliche

Institutionen Handbücher mit Beschreibungen der Vorgehensweisen und Methoden

sowie Hinweisen für deren Anwendung herausgebracht haben, welche sich im Detail

leicht unterscheiden (vgl. bspw. [Department of Defense 2001; Haskins 2006; NASA STI

2007]). Diese Unterschiede liegen vor allen Dingen in der Wahl unterschiedlicher Be-

zeichnungen für inhaltlich gleiche Abläufe und Methoden. Aufgrund der übersichtli-

chen Darstellung wird im Folgenden der sog. Systems Engineering Prozess, anhand

der Ausführungen des US amerikanischen Verteidigungsministeriums beschrieben

[Department of Defense 2001] (siehe Abbildung 5).

Als Input für den Systems Engineering Prozess wirken dabei Anforderungen bzw. Wün-

sche der Kunden sowie anderer Stakeholder. Stakeholder können in diesem Zusam-

menhang alle Individuen oder Organisationen sein, die ein Interesse an dem zu ent-

wickelnden System aufweisen, somit auch Gesetzgeber, die bspw. Anforderungen

bzgl. der Sicherheit des zu entwickelnden Systems haben. In der darauf folgenden

Anforderungsanalyse werden alle erfassten Anforderungen überprüft, untereinander

abgeglichen und aufbereitet. Das Ergebnis sind funktionale und nicht-funktionale An-

forderungen, die präzise und validierbar beschreiben, was das System in welchen

Grenzen zu leisten hat.

Im Rahmen der anschließenden funktionalen Analyse dienen die technischen Anfor-

derungen als Grundlage für die Identifikation der Gesamtfunktion(en), über die das

System verfügen muss. Diese werden anschließend weiter in die zugehörigen Teilfunk-

tionen heruntergebrochen und den funktionalen und nicht-funktionalen Anforderun-

Entwicklung mechatronischer Systeme

gen zugeordnet. Zusätzlich werden die Abhängigkeiten dieser Funktionen unterei-

nander identifiziert sowie dokumentiert und somit die funktionale bzw. logische Archi-

tektur des Systems entwickelt. Die sog. Anforderungsschleife (Requirements Loop)

sorgt dafür, dass das durch die Architekturentwicklung gewonnene Systemverständ-

nis für die erneute Überarbeitung der Anforderungen genutzt wird und somit zu deren

Detaillierung und Verbesserung beiträgt. In der anschließenden Synthese wird eine

Partitionierung der Funktionen auf die Systemelemente unterschiedlicher Disziplinen,

und somit die Definition des Systems im Sinne seiner physikalisch und softwaretech-

nisch umzusetzenden Elemente, durchgeführt. Das Ergebnis ist die physikalische Ar-

chitektur des Systems, die als Grundlage der Detailentwicklungen der unterschiedli-

chen Disziplinen wirkt. Die sog. Designschleife sichert dabei, ähnlich der bereits be-

schriebenen Anforderungsschleife, die Umsetzbarkeit der entwickelten Architektur ab

bzw. sorgt für Anpassungen und Detaillierungen der funktionalen Architektur, falls ei-

ne Umsetzung gemäß der ursprünglichen Planung nicht möglich ist. Der Abgleich der

Systemarchitektur mit den Anforderungen erfolgt abschließend in der Verifikations-

phase (siehe Abbildung 5).

Abbildung 5: Der Systems Engineering Prozess nach [Department of Defense 2001, S. 31]

Zusätzlich zu den beschriebenen Prozessen läuft parallel die Systemanalyse

und -kontrolle, in der bspw. Fortschrittskontrollen, die Dokumentation von Entschei-

dungen oder die Evaluation und Auswahl mehrerer Alternativen während der Syste-

Entwicklung mechatronischer Systeme

mentwicklung durchgeführt werden. Darüber hinaus ist es Ziel dieses Prozesses, eine

durchgängige Nachverfolgbarkeit zwischen Anforderungen und Systemarchitektur

zu etablieren und zu pflegen [Department of Defense 2001, S. 31-33].

2.1.3 ISO 26262 – ROAD VEHICLES – FUNCTIONAL SAFETY

Die ISO 26262 „Road vehicles – Functional Safety“ ist ein internationaler Standard der

die funktionale Sicherheit von Elektronik/Elektrik-Systemen (E/E-Systemen) in Straßen-

fahrzeugen bis 3,5 Tonnen adressiert. Er stellt eine branchenspezifische Ableitung des

Standards IEC 61508 dar und besteht aus zehn Teilen.

Der Standard zielt darauf, funktionale Sicherheit für sicherheitsrelevante E/E-Systeme

zu gewährleisten. Funktionale Sicherheit ist erreicht, wenn ein System so ausgelegt ist,

dass Gefahrensituationen erkannt und ein Unfall verhindert oder zumindest das Aus-

maß des Schadens verringert wird [Horstkötter et al. 2010]. Da Einzelmaßnahmen bei

der Entwicklung komplexer Systeme zur Erreichung funktionaler Sicherheit nicht aus-

reichen, stellt der Standard ein umfassendes Rahmenwerk für die Entwicklung von

E/E-Systemen bereit, welches durch die Anwendung unterschiedlicher Maßnahmen

funktionale Sicherheit gewährleisten soll. Darüber hinaus wird ausdrücklich betont,

dass alle sicherheitskritischen Systeme, unabhängig von den entwickelnden Bran-

chen, nach diesem Vorgehensmodell entwickelt werden können.

Die Norm orientiert sich am Aufbau eines V-Modells und ist in separate Teile für die

Konzeptentwicklung, die Entwicklungen auf System-, Hardware- und Softwareebene

sowie Produktion und Betrieb gegliedert (siehe Abbildung 6).

Die Besonderheit der ISO 26262 ist im Vergleich zu den anderen in dieser Arbeit be-

schriebenen Normen, dass in jedem der Prozessschritte großer Wert auf die Abschät-

zung von Risiken sowie Gegenmaßnahmen gelegt wird. Dies spiegelt sich auch in

dem großen Stellenwert, der dem Automotive Safety Integrity Level (ASIL)

zugerech-

net wird, wider (ISO 26262 Part 9: Automotive Safety Integrity Level (ASIL)-oriented

and safety-oriented analyses [ISO 26262-9]).

Die zu entwickelnden Systeme werden mit dem Automotive Safety Integrity Level (ASIL) im

Rahmen einer Gefahren- und Risikoanalyse bewertet und, je nach Einstufung von A (ge-

ringes Risiko) bis D (hohes Risiko), Empfehlungen für Maßnahmen ausgegeben.

Entwicklung mechatronischer Systeme

Abbildung 6: V-Modell nach ISO 26262 [ISO 26262-2]

Im Rahmen der Konzeptphase (ISO 26262 Part 3: Concept Phase [ISO 26262-3]) er-

folgt zunächst die Beschreibung des Entwicklungsgegenstandes anhand von not-

wendigen Funktionen, Schnittstellen, Umgebungsgegebenheiten, gesetzlichen An-

forderungen usw. Ziel ist es, ein allgemeingültiges Verständnis zu erlangen und auf

dieser Basis den sog. Sicherheitslebenszyklus zu initiieren. Dabei wird zwischen Anpas-

sungs- und Neuentwicklungen unterschieden. Im erstgenannten Fall reicht eine Aus-

wirkungsanalyse bzgl. der durchzuführenden Änderungen aus, während in letzterem

eine umfassende Gefahrenanalyse und Risikobewertung durchgeführt werden muss,

wobei der ASIL bestimmt wird. Das Ergebnis der Konzeptphase sind Sicherheitsanfor-

derungen bzw. -ziele. Um diese während der Entwicklung zu verfolgen, wird anschlie-

ßend ein Sicherheitskonzept mit unterschiedlichen Sicherheitsmechanismen entwor-

fen und den Anforderungen und Zielen zugeordnet.

Nach der Konzeptphase beginnt die eigentliche Entwicklung auf System-, Hardware-

und Softwareebene. Jede dieser Entwicklungsphasen läuft wiederum als V-Modell

ab, sodass sowohl Spezifikations- und Designtätigkeiten (auf dem linken Ast des V-

Modells), als auch Test-, Verifikations- und Validierungsaufgaben (auf dem rechten

Ast des V-Modells) durchzuführen sind. In der Entwicklung auf Systemebene wird zu-

Entwicklung mechatronischer Systeme

nächst eine vorläufige grobe Systemarchitektur erstellt, auf deren Basis die techni-

schen Sicherheitsanforderungen als Verfeinerung des Sicherheitskonzepts detailliert

und der erfüllenden Hard- und Software zugewiesen werden (ISO 26262 Part 4: Pro-

duct development at the system level [ISO 26262-4]). Ferner werden Schnittstellen

spezifiziert, unterstützende Prozesse festgelegt (vgl. ISO 26262 Part 8: Supporting pro-

cesses [ISO 26262-8]) und abschließend das Systemdesign finalisiert. Dieses Design

stellt die Voraussetzung für die Hard- und Softwareentwicklungen dar, die beide

nach ähnlichen Vorgehensmodellen ablaufen (ISO 26262 Part 5: Product develop-

ment at the hardware level [ISO 26262-5] und Part 6: Product development at the

software level [ISO 26262-6]): zunächst werden Anforderungen an die Hard- bzw.

Software spezifiziert (inkl. der Sicherheitsanforderungen) und das Hardware Design

bzw. die Softwarearchitektur erstellt, welche im Anschluss implementiert werden. Da-

bei wird durch die Norm gefordert, dass die Umsetzung der Sicherheitsanforderungen

in der Implementierung nachverfolgbar dokumentiert wird und somit nachgewiesen

werden kann. Im Anschluss an Integration, Tests sowie Verifikationen auf Hardware-

und Softwareebene werden die Ergebnisse der domänenspezifischen Entwicklungen

auf Systemebene integriert und im Systemverbund gegenüber den Sicherheitsanfor-

derungen verifiziert und validiert.

Da sowohl Produktion, als auch der eigentliche Betrieb der Entwicklungsgegenstän-

de von großer Bedeutung für die funktionale Sicherheit sind, werden diese parallel

zur Entwicklung auf Systemebene ebenfalls betrachtet (ISO 26262 Part 7: Production

and operation [ISO 26262-7]). Dabei werden Sicherheitsanforderungen an die Pro-

duktion und den Betrieb detailliert und bspw. Instruktionen für den Zusammenbau

oder die Reparatur der Systeme definiert.

In den restlichen fünf Teilen der Norm werden genutzte Fachwörter (ISO 26262 Part 1:

Vocabulary [ISO 26262-1]) erläutert und unterstützende Prozesse und Methoden be-

schrieben. So definiert ISO 26262 Part 2: Management of functional safety [ISO 26262-

2] Sicherheitsmanagement-Rollen und -Verantwortlichkeiten sowie Anforderungen

an Organisationen, die nach ISO 26262 entwickeln wollen. In Part 8 Supporting pro-

cesses [ISO 26262-8] werden Hinweise für die Spezifikation und Verwaltung von Si-

cherheitsanforderungen gegeben und explizit Nachverfolgbarkeit für diese gefor-

dert. Darüber hinaus werden u. a. Methoden für das Konfigurationsmanagement

und das Änderungsmanagement empfohlen.

2.1.4 INDUSTRIELLE VORGEHENSWEISE AM BEISPIEL DER AUTOMOBILINDUSTRIE

Die in den Kapiteln 2.1.1 bis 2.1.3 beschriebenen Vorgehensmodelle zur Entwicklung

mechatronischer Systeme sind von ihren Autoren für den direkten Einsatz in der in-

dustriellen Anwendung vorgesehen. Dort herrschen jedoch eher Mischformen bzw.

Entwicklung mechatronischer Systeme

an die jeweilige Situation angepasste Formen der genannten Vorgehensmodelle vor

[Königs et al. 2012, S. 925]. Um Unterschiede und Ähnlichkeiten zwischen industrieller

und von Richtlinien und Normen empfohlener Anwendung darzustellen, wird im Fol-

genden beispielhaft die Vorgehensweise in der Automobilindustrie beschrieben

Abbildung 7: Matrixorganisation in der Automobilindustrie [Königs et al. 2012, S. 925]

Der Aufbau der Organisationen ist in der Automobilbranche vielfach als Matrix aus-

gelegt, die sich an den vorhandenen Produktlinien (vertikale Linien) und den inte-

grierten Systemen (horizontale Linien) orientiert (siehe Abbildung 7).

Während die in den vertikalen Linien strukturierten Organisationseinheiten für die In-

tegration der Systeme in die spezifischen Produktlinien zuständig sind, werden die Sys-

teme in den Organisationseinheiten der horizontalen Linien entwickelt [Königs et al.

2012, S. 925-926]. Laut Weber lassen sich dabei sechs gängige Systeme oder Entwick-

lungsbereiche unterscheiden [Weber 2009, S. 9]:

- Antriebsstrang: Motor, Getriebe, Differentiale, Kühlungssystem, Auspuff usw.

- Fahrwerk: Achsen, Federung, Lenkung, Räder, Reifen usw.

- Karosserie: Karosseriestruktur, Türen, Motorhaube, Heckklappe usw.

- Exterieur: Stoßstangen, Fenster, Türsystem usw.

- Interieur: Cockpit, Verkleidungen, Teppich, Sitze usw.

- E/E: Sensoren, Aktuatoren, Verkabelung, Steuergeräte usw.

Die Organisation von Entwicklungen erfolgt in Projekten, die sich, in Abhängigkeit der

Komplexität des Entwicklungsvorhabens, des Neuheitsgrads (Anpassungs- oder Neu-

Obwohl die Automobilhersteller unterschiedliche Prozesse nutzen, ist deren grundsätzlicher

Ablauf auf der betrachteten Ebene durchaus vergleichbar [Weber 2009, S. 1]. Aus diesem

Grund werden nicht spezifische Ausprägungen, sondern ein verallgemeinerter Prozess be-

schrieben.

Entwicklung mechatronischer Systeme

entwicklung) und des Umfangs der Entwicklung, unterscheiden [Weber 2009, S. 1].

Die Projekte überspannen dabei je nach Ausrichtung eine oder mehrere horizontale

und vertikale Linien der Matrix [Königs et al. 2012, S. 926; Königs 2012, S. 14].

Abbildung 8: Übergreifende Vorgehensweise in der Automobilindustrie [Weber 2009, S. 12]

Das übergeordnete Vorgehen innerhalb der Projekte orientiert sich am V-Modell (sie-

he Abbildung 8), welches ähnlich ausgeprägt ist, wie in Kapitel 2.1.1 beschrieben.

Ausgehend von der Spezifikation des Gesamtfahrzeugs werden die Anforderungen

auf die zuvor genannten Systeme und weiter auf die beinhalteten Bauteile herunter-

gebrochen [Weber 2009, S. 11]. Da die grundsätzliche Architektur des Gesamtfahr-

zeugs überwiegend bekannt ist, erfolgt jedoch im Unterschied zu V-Modell nach

VDI 2206 (siehe Kapitel 2.1.1) keine lösungsneutrale Beschreibung auf funktionaler

Ebene, sondern eine direkte Weitergabe der Spezifikationen an die unterschiedli-

chen System-Entwicklungsbereiche (und damit die unterschiedlichen Entwicklungs-

disziplinen). Innerhalb dieser Bereiche haben sich unterschiedliche Vorgehensweisen

etabliert, die sich an den Bedarfen der jeweiligen Disziplin orientieren: So arbeiten

bauteilorientierte Bereiche auf einem von Beginn an vergleichsweise detaillierten Ni-

veau mit CAD-Modellen, MKS-, FEM- und zahlreichen weiteren spezialisierten IT-

Werkzeugen zur Auslegung der Bauteile und Baugruppen und sichern diese mit Hilfe

von DMUs (später mit realen Prototypen) ab [Weber 2009, S. 41-52]. Im Bereich der

E/E-Entwicklung wird hingegen aufgrund der starken Vernetzung der einzelnen

Komponenten und Systeme eine abstraktere Sichtweise benötigt, weshalb laut We-

ber domänenintern in Anlehnung an das Systems-Engineering-Vorgehensmodell ver-

fahren wird: aus den meist textuellen Anforderungen wird eine Systemarchitektur ab-

geleitet bzw. eine bestehende angepasst [Weber 2009, S. 53-78]. Diese umfasst eine

Funktionsstruktur, welche die für den Fahrer erlebbaren Funktionen beschreibt, weiter

detailliert und deren Abhängigkeiten abbildet. Darüber hinaus wird die Partitionie-

Entwicklung mechatronischer Systeme

rung auf Funktionsträger (z. B. Steuergeräte) ebenfalls zur Systemarchitektur (auch

technische Systemarchitektur genannt) hinzugerechnet. Erst im Anschluss werden

Steuergeräte, Embedded Software und Anwendungssoftware entwickelt. Dies kann

zum Teil auf Basis der Funktionsstruktur geschehen, indem diese weiter detailliert und

abschließend mit Hilfe von Codegeneratoren (z. B. TargetLink) in Programmcode für

Steuergeräte umgewandelt wird [Conrad et al. 2005, S. 6]. Die Absicherung erfolgt

hierarchisch von Bauteil bis Gesamtfahrzeug. Zunächst werden Komponenten wie

Steuergeräte inkl. Software in sog. Hardware-in-the-Loop (HiL) Tests getestet. Dabei

werden Schnittstellen-Parameter (von Sensoren und Aktuatoren) durch eine HiL-

Simulationsumgebung emuliert und somit schnelle Tests ermöglicht. Im Folgenden

werden die E/E-Subsysteme und Systeme integriert, getestet und gegenüber den An-

forderungen abgesichert [Weber 2009, S. 67-69]. Die Integration des Gesamtfahr-

zeugs erfolgt dann wieder in den vertikalen Linien (siehe Abbildung 7) und dient der

Absicherung und der Evaluierung der Gesamtfahrzeugeigenschaften. Dabei kom-

men u. a. folgende Integrations- und Absicherungsmethoden zum Einsatz [Weber

2009, S. 45-49; 70-71]: Die geometrische Integration und Absicherung dient der Vertei-

lung und Überwachung des Bauraums. Zum Einsatz kommen bspw. DMUs, mit deren

Hilfe Kollisionen und Spiel analysiert werden. Die funktionale Integration und Absiche-

rung dient der Überprüfung der funktionalen Eigenschaften des Gesamtfahrzeugs

(z. B. passive Sicherheit). Die Systemintegration dient der Integration und Absicherung

des vollständigen E/E-Systems auf Fahrzeugebene.

2.1.5 V-MODELL DES FRAUNHOFER IPK

Das im Folgenden beschriebene V-Modell wurde am Fraunhofer IPK entwickelt [Beier

et al. 2012, S. 14-17] und orientiert sich an dem V-Modell der VDI 2206 (siehe Kapitel

2.1.1), welches jedoch insbesondere in den frühen Phasen erweitert wurde (siehe

Abbildung 9).

Ausgangspunkt des V-Modells ist eine übergeordnete Produktplanung, bei der zu-

nächst das zu entwickelnde Produkt in seinen Grundzügen (vom Management) spe-

zifiziert wird. Darauf folgt die Architekturreflexion, bei der Vorgängerprodukte hin-

sichtlich ihrer Architektur analysiert und ggf. neue Systeme auf abstrakter Ebene inte-

griert werden. Ergebnis dieser beiden Schritte ist ein initiales Set an Anforderungen,

welches als Ausgangspunkt für die eigentliche Entwicklung dient.

Die Anforderungen werden im nächsten Schritt in der Anforderungskaskade herun-

tergebrochen, bis die zu realisierenden Funktionen sowie deren Eigenschaften identi-

fiziert werden können.

Entwicklung mechatronischer Systeme

Abbildung 9: V-Modell des Fraunhofer IPK

Die Funktionen werden im folgenden Schritt, dem Vorentwurf der Funktionen und Ei-

genschaften, modelliert und deren Abhängigkeiten abgebildet. Dieser funktionale

Vorentwurf wird anschließend zum Vorentwurf des Systemmodells weiterentwickelt,

indem die Funktionen hinsichtlich ihrer Wirk- und Lösungsprinzipien spezifiziert werden

und deren logisches Verhalten modelliert wird. Dieses Systemmodell sowie das Funk-

tionsmodell und die Anforderungen, die in den vorangegangenen Schritten entwi-

ckelt wurden, unterliegen dabei einer ständigen Iteration, um eine integrierte Funkti-

ons- und Eigenschaftsabsicherung zu erreichen. Ziel ist es die Eigenschaften des zu

entwickelnden Produkts so weit wie möglich abzusichern bevor die detaillierte Ent-

wicklung, getrennt nach Entwicklungsdisziplinen, erfolgt. Als Abschluss der Phase der

durchgängigen Systemauslegung und des neutralen Entwurfs werden die zuvor kas-

kadierten Anforderungen, detaillierten Funktionen und des Systemmodells partitio-

niert und somit den Disziplinen Mechanik, Elektronik/Elektrik und Software sowie

Dienstleistungsentwicklung und Produktionsplanung zugeordnet.

Die abschließende Integration wird von einer stetigen Überprüfung der Eigenschaf-

ten gegenüber dem Systementwurf begleitet. Aufgrund umfassender Simulationen

auf dem linken Ast des Vs sollte diese allerdings eher einer Bestätigung denn einer

Absicherung (siehe V-Modell nach VDI 2206 in Kapitel 2.1.1) gleich kommen.

Begleitet werden die zuvor genannten Prozessschritte von einem kontinuierlichen For-

schungsprozess aus dem insbesondere zu Beginn der Entwicklung Innovationen in

den eigentlichen Ablauf des V-Modells eingesteuert werden können.

Entwicklung mechatronischer Systeme

Das beschriebene V-Modell stellte die Grundlage für die Entwicklung des eingangs

erwähnten mechatronischen Außenspiegels, der in dieser Arbeit als durchgängiges

Beispiel verwendet wird, dar. Er wurde im Rahmen der Lehrveranstaltung „Virtual En-

gineering in Industry“ mit der Tool-Landschaft V6 von Dassault Systèmes (siehe auch

Kapitel 3.6.2.1) entwickelt [Amin et al. 2012; Dassault Systèmes 2013]. Die Projektar-

beit, welche im Wintersemester 2011/12 durchgeführt wurde, gliederte sich aufgrund

vorgegebener Design Reviews in vier Phasen, von denen die ersten drei die Entwick-

lung des Außenspiegels und die letzte die Dokumentation des Projekts behandelten

[Amin et al. 2012, S. 7]. In Phase 1 wurden zunächst vorgegebene Anforderungen

aufgenommen und auf dieser Basis unterschiedliche Konzepte entwickelt. Die grobe

Evaluation dieser Konzepte hinsichtlich ihrer Kosten, Gewichte und grundsätzlichen

Machbarkeit führte zur Auswahl eines weiterzuverfolgenden Konzepts. Die bereits

aufgenommenen Anforderungen wurden ergänzt, strukturiert und in ENOVIA doku-

mentiert. Hinsichtlich des V-Modells handelt es sich hierbei um die Anforderungs-

kaskade. Ebenfalls in Phase 1 wurden anschließend alle notwendigen Funktionen des

mechatronischen Außenspiegels identifiziert und daraus eine Funktionsstruktur in

CATIA aufgebaut. Es handelt sich um den Vorentwurf der Funktionen, bei dem sog.

„Building Blocks“ genutzt werden, um die Funktionen zu modellieren. In Projektpha-

se 2 schloss sich die Wahl der Wirkprinzipien und die Modellierung des Verhaltensmo-

dells mit Hilfe des in CATIA integrierten DYMOLA Editors an. In Bezug auf das V-Modell

handelt es sich dabei um die Entwicklung des Systemmodells, bei dem mit Hilfe der

Sprache Modelica das Verhalten des Systems modelliert wird. Ebenfalls parallel bzw.

leicht zeitversetzt begann die Detailkonstruktion der Bauteile und Baugruppen in

CATIA. Dieser Prozessschritt entspricht der mechanischen Entwicklung im V-Modell.

Aspekte wie die Entwicklung der Steuergeräte (E/E-Entwicklung im V-Modell) oder

der zugehörigen Software (Softwareentwicklung im V-Modell) wurden aufgrund zeit-

licher und kapazitiver Restriktionen nicht behandelt. In Phase 3 der Projektarbeit wur-

den abschließend Anpassungen an den System- und geometrischen Modellen

durchgeführt, die aufgrund entsprechenden Feedbacks in den Design Reviews not-

wendig wurden. Zusätzlich wurde die Erfüllung der Anforderungen mit Hilfe der zuvor

erstellten Modelle nachgewiesen. Weitere Schritte wie bspw. Prototypenbau oder

die Absicherung der Produktion mit Methoden der Digitalen Fabrik waren nicht im

Umfang der Lehrveranstaltung vorgesehen und wurden daher nicht weiter betrach-

tet.

Entwicklung mechatronischer Systeme

2.1.6 VERGLEICH DER VORGEHENSMODELLE

Die in den Kapiteln 2.1.1 bis 2.1.5 beschriebenen Vorgehensmodelle haben einen

grundsätzlich ähnlichen Ablauf, der sich in die Phasen „Planung“, „Entwurf“, „Detail-

entwicklung“, „Integration“ und „Nutzung“ unterteilen lässt. Dabei werden jedoch

nicht alle Phasen von allen Vorgehensmodellen abgedeckt (siehe Abbildung 10).

Ähnlichkeiten bestehen zudem auch bei der detaillierteren Betrachtung, bei der sich

innerhalb der Phasen ähnliche, wiederkehrende Prozessschritte offenbaren. So findet

sich die Abfolge „Anforderungsanalyse“ – „Funktionsdefinition“ – „Synthese“, wenn-

gleich unter unterschiedlichen Bezeichnungen und in unterschiedlichen Umfängen,

in der VDI 2206 [VDI-Richtlinie 2206], dem Systems Engineering [Department of De-

fense 2001], der ISO 26262 [ISO 26262-4; ISO 26262-3] sowie im Fraunhofer IPK Vorge-

hensmodell [Beier et al. 2012]. Lediglich in der industriellen Anwendung wird anders

vorgegangen, da eine lösungsneutrale Beschreibung des zu entwickelnden Systems

im Tagesgeschäft als zu aufwändig und nicht zielführend wird.

Abbildung 10: Vergleich der Vorgehensmodelle

Die Vorgehensmodelle sind sich somit dahin gehend ähnlich, dass basierend auf An-

forderungen eine Art Systembeschreibung entwickelt wird bzw. bereits vorhanden ist.

Diese kann sich im Detail unterscheiden, jedoch überwiegt der Ansatz, die Funktio-

nen des Systems zu definieren und diese dann schrittweise in Richtung Umsetzung zu

konkretisieren. Im Anschluss folgt bei allen Vorgehensmodellen die Detailentwicklung,

Entwicklung mechatronischer Systeme

die getrennt nach Entwicklungsdisziplinen durchgeführt wird. Abschließend ist eine In-

tegration erforderlich, bei der das Zusammenspiel der Systeme gegenüber den An-

forderungen getestet wird.

Neben diesen Ähnlichkeiten gibt es jedoch auch Unterschiede, sowohl auf abstrak-

ter Betrachtungsebene (so adressiert bspw. das Systems Engineering und das Fraun-

hofer IPK Vorgehensmodell als einzige der betrachteten Vorgehensmodelle die Pha-

se der Planung) als auch im Detail. Diese Unterschiede ergeben sich u. a. aus der

Herkunft und den Zielen der Vorgehensmodelle. So geht das Systems Engineering

von einer umfassenden Gesamtsystembetrachtung aus. Unterscheidungsmerkmal im

Vergleich zu anderen Vorgehensmodellen ist dabei, dass Systemelemente nicht aus-

schließlich technischer Natur sein müssen sondern, je nach Festlegung der System-

grenze, neben Bauteilen oder Software auch Personen, Einrichtungen, Dokumente

oder Richtlinien sein können [NASA STI 2007, S. 3].

Die VDI 2206 wurde hingegen entwickelt, um bereits bestehende domänenspezifi-

sche Vorgehensmodelle (VDI 2221 & VDI 2422) zu integrieren und damit die Entwick-

lung mechatronischer Systeme zu ermöglichen. Daher wird ein großer Wert auf den

lösungsneutralen Systementwurf gelegt und die domänenspezifischen Entwicklungs-

vorgehensweisen nicht näher betrachtet. Auch Tätigkeiten wie Projektmanagement,

die integraler Bestandteil des Systems Engineerings sind, werden nicht berücksichtigt.

Die ISO 26262 richtet sich zunächst an die Entwicklung sicherheitskritischer E/E-

Systeme, jedoch wird ausdrücklich darauf hingewiesen, dass sie auch für die Entwick-

lung sicherheitskritischer Funktionen anderer Entwicklungsdisziplinen anwendbar ist.

Vor diesem Hintergrund ist nicht verwunderlich, dass der größte Unterschied zu den

anderen Vorgehensmodellen der Fokus auf die Abschätzung von Risiken sowie der

Entwicklung von Gegenmaßnahmen ist.

In der industriellen Vorgehensweise, die anhand des Beispiels der Automobilindustrie

beschrieben wurde, unterscheidet sich die Vorgehensweise von den anderen Vor-

gehensmodellen. Es wird auf die lösungsneutrale Beschreibung der Systeme verzich-

tet, da die überwiegende Anzahl der Entwicklungen evolutionäre Weiterentwicklun-

gen und keine Neukonstruktionen sind. Das bedeutet, dass der grundsätzliche Auf-

bau des Produkts bekannt ist und anhand diesem Entwicklungsbereiche unterschie-

den werden, die das Fahrzeug auf den Ebenen Gesamtfahrzeug, System und Bauteil

entwickeln. Innerhalb dieser Bereiche haben sich unterschiedliche Vorgehensweisen

durchgesetzt, die sich an den Bedarfen der Disziplinen orientieren.

Unabhängig vom genutzten Vorgehensmodell werden in jedem Fall verschiedene

Modelle und Dokumente genutzt, um den Systementwurf und die Detailentwicklung

durchzuführen und zu dokumentieren. Diese sog. Artefakte stellen damit eine wichti-

Entwicklung mechatronischer Systeme

ge Beschreibungsform während der Systementwicklung dar. Die Beschreibung aus-

gewählter Artefakte erfolgt im folgenden Kapitel 2.2.

2.2 ARTEFAKTE ZUR ENTWICKLUNG MECHATRONISCHER SYSTEME

Dokumente, Modelle, Code und weitere digitale Beschreibungsformen, die während

des Entwicklungsprozesses erstellt werden, können zusammenfassend als Artefakte

bezeichnet werden [Cleland-Huang et al. 2003, S. 797]. Im Fokus dieser Arbeit stehen

dabei strukturierte Artefakte, bei denen sich einzelne Elemente identifizieren lassen.

Das können bspw. einzelne Anforderungen in der objektorientierten Software DOORS

oder Bauteile einer Baugruppe in einem CAD-System sein. Genauso lassen sich die

folgenden Erläuterungen jedoch bspw. auch auf strukturierte, in Word verfasste An-

forderungsspezifikationen, bei denen Überschriften genutzt werden, um die Anforde-

rungen eindeutig identifizierbar zu machen, anwenden.

In den folgenden Kapiteln wird auf die Artefakte „Anforderungsartefakt“ (Kapi-

tel 2.2.1), „Funktionsartefakt“ (Kapitel 2.2.2), „Verhaltensartefakt“ (Kapitel 2.2.3) und

„Produktstrukturartefakt“ (Kapitel 2.2.4) eingegangen. Das Ziel des Kapitels ist es, die

wichtigsten Artefakte zur Entwicklung technischer Systeme kurz vorzustellen und zu

vermitteln, dass Abhängigkeiten zwischen diesen Artefakten bestehen, die während

der Entwicklung berücksichtigt werden müssen (Kapitel 2.2.5).

2.2.1 ANFORDERUNGSARTEFAKTE

Die IEEE definiert den Begriff der Anforderung als [IEEE 610.12-1990, S. 62]:

1. Eine Bedingung oder Eigenschaft, die ein System oder eine Person benö-

tigt, um ein Problem zu lösen oder ein Ziel zu erreichen.

2. Eine Bedingung oder Eigenschaft, die ein System oder eine Systemkompo-

nente aufweisen muss, um einen Vertrag zu erfüllen oder einem Standard,

einer Spezifikation oder einem anderen formell auferlegten Dokument zu

genügen.

3. Eine dokumentierte Repräsentation einer Bedingung oder Eigenschaft wie

in 1. oder 2. definiert.

Zielsetzung der Formulierung von Anforderungen ist somit die lösungsneutrale

Spezifi-

kation eines Systems im Hinblick auf seine später auszuführenden Funktionen und zu

In der Realität sind die Anforderungen häufig lösungsspezifisch formuliert, da es sich bei

den meisten Entwicklungen um Anpassungen eines Vorgängersystems handelt und somit

auf dem vorhergehenden Wissensstand aufgebaut wird [Almefelt et al. 2006, S. 121; Wras-

se 2011, S. 22-23].

Entwicklung mechatronischer Systeme

erfüllenden Eigenschaften [Weilkiens 2006, S. 38-44; Pahl et al. 2007, S. 215]. Sie spie-

len damit eine zentrale Rolle in der Produktentwicklung, wobei sich ihre genaue Aus-

prägung in Abhängigkeit des Charakters des Entwicklungsprojekts unterscheiden

kann: während Anforderungen in kleinen unabhängigen Projekten ausschließlich zur

bereits erwähnten Spezifikation verwendet werden, dienen sie in großen Entwick-

lungsprojekten zusätzlich der Aufgabenverteilung [Almefelt et al. 2006, S. 119].

Für die eindeutige Dokumentation von Anforderungen sind je nach Literaturquelle

unterschiedliche Informationen notwendig. Übereinstimmend sind jedoch mindes-

tens eine eindeutige Identifikationsnummer sowie ein beschreibender Text erforder-

lich [Weilkiens 2006, S. 40; NASA STI 2007, S. 48; Pahl et al. 2007, S. 216]. Darüber hinaus

sind die Angabe der oder des Verantwortlichen, Datum der Aufnahme der Anforde-

rung und der letzten Änderung, Quelle der Anforderung sowie erläuternde Informati-

onen möglich [Pahl et al. 2007, S. 217].

Anforderungen lassen sich dabei in Abhängigkeit ihrer Ausprägung in verschiedene

Arten unterscheiden. Während bspw. funktionale Anforderungen die Funktionen, die

ein System oder eine Komponente ausführen können soll, beschreiben, dienen Leis-

tungsanforderungen (nicht-funktionale Anforderungen) der Spezifikation, wie gut

diese ausgeführt werden sollen [NASA STI 2007, S. 41]. Zusätzlich gibt es je nach kon-

sultierter Literaturquelle die Unterscheidung zahlreicher weiterer Kategorien: Schnitt-

stellen-Anforderungen, Design-Anforderungen, operationelle Anforderungen, Anfor-

derungen an Ressourcen, Verifikationsanforderungen usw. [Department of Defense

2001, S. 35-36; Hood und Wiebel 2005, S. 102; NASA STI 2007, S. 41-45; Wrasse 2011,

S. 27].

Anforderungen bilden somit eine abstrakte Sicht auf das zu entwickelnde System, in

der beschreiben wird, was entwickelt werden soll. Sie definieren damit die Ausprä-

gung der im Folgenden entwickelten Artefakte (siehe Kapitel 2.2.2 bis 2.2.4) und stel-

len den Ausgangspunkt der weiteren Entwicklungsaktivitäten dar. Sie dienen zudem

der Kommunikation unter Stakeholdern, der Validierung des Systems sowie der Steue-

rung der Entwicklung [Yeh und Zave 1980].

2.2.2 FUNKTIONSARTEFAKTE

Mit Hilfe von Funktionsartefakten lassen sich bei der Entwicklung mechatronischer

Systeme die Funktionen des zu entwickelnden Systems beschreiben. Es gibt in diesem

Zusammenhang sehr viele unterschiedliche Vorgehensweisen und Definitionen, so-

wohl in der Forschung, als auch in der industriellen Anwendung, die aus unterschied-

lichen Anwendungsszenarien motiviert und nicht immer miteinander kompatibel sind

Entwicklung mechatronischer Systeme

[Vermaas 2009, S. 113]. Eine gute Übersicht über unterschiedliche Ansätze findet sich

in [Erden et al. 2008].

Im Kontext dieser Arbeit wird die Definition der Funktion nach Ponn und Lindemann

verwendet [Ponn und Lindemann 2008, S. 56], die in ähnlicher Form auch bei Pahl et

al. und der VDI-Richtlinie 2206 zum Einsatz kommt [VDI-Richtlinie 2206, S. 32-33; Pahl et

al. 2007, S. 243]:

Funktionen stellen im Kontext der Systementwicklung „eine am Zweck ori-

entierte, lösungsneutrale, als Operation beschriebene Beziehung zwischen

Eingangs- und Ausgangsgrößen eines Systems“ dar [Ponn und Lindemann

2008, S. 56].

Trotz ihrer großen Verbreitung (insbesondere im deutschsprachigen Raum) ist auch

diese Definition in der Wissenschaft nicht frei von Kritik. So weisen van Beek und

Tomiyama auf das sog. „ontology problem“ hin, welches in einigen Fällen auch auf

die vorliegende Definition zutrifft [van Beek und Tomiyama 2008, S. 4]. Unter diesem

Problem verstehen sie einen zu eng (oder auch zu weit) gesteckten Rahmen an un-

terschiedlichen Funktionen, die mit einer Methode beschrieben werden können.

Funktionen, die weder über Energie-, Material- noch Signalflüsse verfügen, können

somit, mit der von Ponn und Lindemann definierten Funktion, nicht beschrieben wer-

den. Als Beispiel für eine solche Funktion führen van Beek und Tomiyama die Funktion

des Bügels bei einem Kopfhörer an, die sich mit der Wandlung der genannten Flüsse

nicht beschreiben lässt [van Beek und Tomiyama 2008, S. 4]. Bei der Wahl der Funkti-

onsdefinition und -ontologie ist es somit wichtig, dass sie auf den Anwendungsfall

abgestimmt sind, denn auf eine für alle Anwendungsfälle gültige Definition wurde

sich zumindest bis heute noch nicht geeinigt.

Obwohl Schwierigkeiten bei der Definition der Funktion bestehen wird das grundsätz-

liche Verfahren, die Funktionen bei der Entwicklung mechatronischer Systeme zu be-

schreiben, insbesondere in der Wissenschaft als wichtige Methode angesehen

. Ins-

besondere die Tatsache, dass es den Begriff der Funktion in allen Disziplinen der me-

chatronischen Systementwicklung (wenn auch in unterschiedlichem Umfang) gibt

und das Konzept der Funktionsmodellierung somit unabhängig von der Entwick-

lungsdisziplin ist, wird als einer der größten Vorteile angesehen [van Beek und

In der industriellen Anwendung gibt es zwar einige positive Beispiele (siehe z.B. [Balluchi et

al. 2002]), die allgemeine Verbreitung der disziplinübergreifenden Funktionsmodellierung ist

jedoch gering. Zum einen ist dies auf den Aufwand und den Schwierigkeitsgrad zurückzu-

führen, der mit der Erstellung der Funktionsartefakte verbunden ist [Kroll 2012, S. 168]. Dar-

über hinaus stellen die fehlende eindeutige Definition der Funktion sowie vorhandene „in-

dividuelle“ Definitionen ein echtes Einstiegshindernis dar [van Beek und Tomiyama 2008,

S. 5].

Entwicklung mechatronischer Systeme

Tomiyama 2008, S. 4]. Funktionsartefakte können somit von Experten unterschiedli-

cher Disziplinen gemeinsam entwickelt und als gemeinsame Sprache bei der Spezifi-

kation des zu entwickelnden Systems und dessen gewünschten Verhalten genutzt

werden [Erden et al. 2008, S. 147; van Beek und Tomiyama 2008, S. 4; Vermaas 2009,

S. 113].

Funktionen werden aus den funktionalen Anforderungen des Anforderungsartefakts

(siehe Kapitel 2.2.1) abgeleitet und in Artefakten dokumentiert [Ponn und Lindemann

2008, S. 56-57]. Die Definition der Haupt- und Hilfsfunktionen (unterschiedlicher Abs-

traktionsstufen), die ein System zur Verfügung stellen soll, ist damit ein Zwischenschritt

zwischen der Aufgabenstellung und der Entwicklung der Lösung. Dabei soll die expli-

zit lösungsneutrale Formulierung der Funktionen

dabei helfen, unvoreingenommen

an die Entwicklungsaufgabe heranzugehen und somit die Findung neuartiger Lösun-

gen zu unterstützen [Leemhuis 2005, S. 51; Pahl et al. 2007, S. 243; Ponn und Linde-

mann 2008, S. 56]. Zusätzlich hilft die Lösungsneutralität auch dabei, das System ohne

Bindung an bestimmte Entwicklungsdomänen zu beschreiben und trägt somit zur

Verständigung zwischen den Entwicklern unterschiedlicher Domänen bei [Erden et

al. 2008, S. 147].

2.2.3 VERHALTENSARTEFAKTE

Im Anschluss an die Modellierung der Funktionen mechatronischer Systeme erfolgt

die Festlegung konkreter Wirkprinzipien für deren Umsetzung und damit eine erste

grobe Auswahl beteiligter Systemelemente. Da nun die (dynamischen) Eigenschaf-

ten und die Interaktion dieser Elemente untereinander das gesamte Systemverhalten

beeinflussen [Vajna 2009, S. 29], ist es hilfreich dieses mit Hilfe von Verhaltensmodel-

len zu simulieren. Verhaltensmodelle sind abstrakte mathematische Modelle, mit de-

ren Hilfe bereits früh im Entwicklungsprozess belastbare Abschätzungen über Eigen-

schaften des zu entwickelnden Systems getroffen werden können [Janschek 2010,

S. 50]. Dabei liegt eine große Herausforderung in der Heterogenität der beteiligten

Entwicklungsdomänen begründet [Janschek 2010, S. 11]. So müssen sehr unter-

schiedliche Systemelemente im Verhaltensmodell integriert und in Kombination mit-

einander simuliert werden (z. B. Mechanik, Fluidik, digitale Informationsverarbeitung

usw.).

Die Lösungsneutralität bei der Beschreibung der Funktionen ist nicht unumstritten [Umeda

und Tomiyama 1995, S. 4; Chakrabarti und Bligh 2001, S. 500; Kroll 2012, S. 166]. Umeda und

Tomiyama argumentieren bspw., dass es häufig schwierig ist, die Funktion eines Systems

unabhängig von dessen Verhalten (und damit dessen Realisierung) zu betrachten [van

Beek und Tomiyama 2008, S. 4].

Entwicklung mechatronischer Systeme

Eine Sprache, die von vielen frei verfügbaren und kommerziellen Werkzeugen ge-

nutzt wird (z. B. OpenModelica der Universität Linköping, Dymola von Dassault Sys-

tèmes, MOSILAB von Fraunhofer FIRST, SimulationX der Gesellschaft für ingenieur-

technische Informationsverarbeitung [Modelica Association 2013]), ist Modelica

[Modelica Association 2012]. Für sie gibt es zahlreiche freie und kostenpflichtige Bibli-

otheken mit Objekten unterschiedlicher Disziplinen, die kombiniert und simuliert wer-

den können. Laut Janschek hat Modelica einige wichtige Eigenschaften: sie verfolgt

eine modellspezifische, anstatt einer mathematisch-orientierten Beschreibung, ist

anwendungsneutral, unterstützt gemischt kontinuierlich-diskrete Systeme und berück-

sichtigt physikalische Einheiten [Janschek 2010, S. 132].

Abbildung 11: Simulationsumgebungen auf Basis von Modelica [Otter 2011, S. 6]

Die Modellierung des Verhaltensmodells und der Simulationsdurchlauf verlaufen

meistens wie in Abbildung 11 dargestellt ab: die relevanten Objekte (z. B. ein Wider-

stand) werden in dem grafischen Editor aus Bibliotheken geladen und an ihren

„Ports“ mittels Signal- und Energie-Flüssen miteinander verknüpft [Modelica Associa-

tion 2012]. Jedes Objekt ist dabei textuell mit Modelica beschrieben. Nach Modellie-

rung des Verhaltensmodells werden diese textuellen Beschreibungen in C-Code

transformiert und die Simulation durchgeführt. Das Simulationsergebnis wird in Form

von Variablen und deren Verlauf über die Zeit ebenfalls in der Simulationsumgebung

ausgegeben.

Mit der Hilfe von Verhaltensartefakten lässt sich somit das Verhalten des zu entwi-

ckelnden Systems simulieren. Es werden die zu realisierenden Funktionen mit Hilfe von

Modellen der gewählten Systemelemente und Wirkprinzipien umgesetzt und deren

Zusammenwirken evaluiert.

Entwicklung mechatronischer Systeme

2.2.4 PRODUKTSTRUKTURARTEFAKTE

Laut Dubbel et al. bildet „die Produktstruktur […] den Aufbau eines Produktes in Form

einer hierarchischen Struktur ab.“ Diese Ansicht teilen zahlreiche andere Autoren,

welche die Produktstruktur bzw. die synonym zu gebrauchende Erzeugnisgliederung

als hierarchische Zerlegung eines Produkts in seine Haupt- und Teilkomponenten de-

finieren (z. B. [Schönsleben 2007, S. 21; VDI 2219, S. 10]). Im Kontext des Systems Engi-

neerings wird diese Definition im Kern beibehalten und nur insofern erweitert, dass

nicht nur Produkte, Baugruppen und Einzelteile, sondern darüber hinaus auch Syste-

me, Sub-Systeme, Software- und Informationselemente strukturiert werden. Die

Struktur wird Product Breakdown Structure [NASA STI 2007, S. 52] oder Work Break-

down Structure [Department of Defense 2001, S. 85] genannt.

Die Produkt- oder Systemstruktur dient somit der Verwaltung von Systemen, Baugrup-

pen sowie Bauteilen und Software- und Informationselementen, deren Leistung und

Funktionsweise in den Anforderungen spezifiziert, Funktionen in Funktionsartefakten

beschrieben und Verhalten in Verhaltensartefakten überprüft wurde.

2.2.5 ABHÄNGIGKEITEN ZWISCHEN ARTEFAKTEN

Die in den Kapiteln 2.2.1 bis 2.2.4 vorgestellten Artefakte stellen einige (wenngleich

wichtige) Beispiele möglicher Artefakte bei der Systementwicklung dar. Insbesondere

in der Detailentwicklung gibt es in den unterschiedlichen Entwicklungsdisziplinen zahl-

reiche auf besondere Aufgabenstellungen spezialisierte Werkzeuge, in denen weite-

re Artefakte erzeugt werden [Tudorache 2006, S. 2]. Allen Artefakten ist gemein, dass

sie nicht inhaltlich isoliert existieren, sondern Redundanzen bzw. inhaltliche Abhän-

gigkeiten zu anderen Artefakten aufweisen [Egyed 2000, S. 28; VDI-Richtlinie 2206,

S. 47; Tudorache 2006, S. 2]. So kann bspw. das Trägheitsmoment einer Komponente

einmal als Parameter in einem Verhaltens-Modell und einmal über die Abmessungen

und Materialauswahl in einem CAD-Programm beschrieben werden. Andererseits er-

füllen bspw. Funktionen des Funktionsartefakts Anforderungen, die in einer Anforde-

rungsspezifikation dokumentiert sind. Diese Funktionen werden wiederum von Lö-

sungselementen realisiert, das Verhalten in Verhaltensmodellen simuliert und deren

Gestalt in Form von CAD-Modellen in der Produktstruktur abgelegt wird.

Auch bei der Entwicklung des mechatronischen Außenspiegels lassen sich zahlreiche

Redundanzen und Abhängigkeiten zwischen den vier modellierten Artefakten (An-

forderungsspezifikation, Funktionsstruktur, Verhaltensmodell und Produktstruktur) iden-

tifizieren. So ist bspw. in den Anforderungen die maximale Dauer der Beheizung für

die Außenspiegel angegeben (= 360 Sekunden). Diese Dauer findet sich ebenfalls im

Verhaltensmodell als modellierter „Timer“ wieder, der die Schaltung der Spiegelhei-

Entwicklung mechatronischer Systeme

zung steuert. Diese Redundanz, die dadurch entsteht, dass der Parameter sowohl in

der Anforderungsspezifikation, als auch im Verhaltensmodell dokumentiert ist bzw.

verwendet wird, kann insbesondere bei einseitiger Änderungen zu Inkonsistenzen zwi-

schen den Artefakten und damit zur Nicht-Erfüllung von Anforderungen führen.

Gleiches gilt auch für Vorgaben für maximalen Abmessungen sowie die maximale

Masse, welche in den Anforderungen beschrieben sind. Zwar wird in diesem Fall der

Parameter nicht unverändert in die geometrischen Bauteile im CAD-Modell über-

nommen, jedoch müssen die Abmessungen bzw. die Masse bei der Validierung ge-

genüber diesen abgesichert werden. Es bestehen somit Abhängigkeiten zwischen

den Anforderungen und der Produktstruktur.

Auch wenn keine Parameter involviert sind, können Abhängigkeiten zwischen den

unterschiedlichen Elementen der Artefakte bestehen. So ist in den Anforderungen

des Außenspiegels spezifiziert, dass ein Toter-Winkel-Assistent in den Außenspiegel in-

tegriert werden soll. Dies hat zur Folge, dass die Studenten eine gleichnamige Funkti-

on im Funktionsmodell modelliert haben, die im Verhaltensmodell anschließend nä-

her hinterlegt wurde. Auch Abhängigkeiten zum Geometrie-Modell bestehen, da für

den Assistenten LEDs im Spiegel montiert und Kabel verlegt werden müssen. In Abbil-

dung 12 ist beispielhaft die ausgewählte LED-Baugruppe und ihre Positionierung im

CAD-Modell des Außenspiegels zu erkennen.

Abbildung 12: Darstellung der LEDs des Toter-Winkel-Assistenten im Geometriemodell des

Außenspiegels (vgl. [Amin et al. 2012])

Zusammenfassend kann festgestellt werden, dass inhaltliche Abhängigkeiten unter-

schiedlicher Ausprägung zwischen den Artefakten bei der Entwicklung technischer

Systeme bestehen. Diese zu kennen und explizit zu dokumentieren ist essentiell, da es

sonst zu Inkonsistenzen zwischen den Artefakten und damit zu Fehlern während der

Entwicklung kommen kann. Dies gilt insbesondere für die Entwicklung komplexer Sys-

Entwicklung mechatronischer Systeme

teme, da die Anzahl und Komplexität der Artefakte sowie die Anzahl der beteiligten

Entwickler hoch und somit das Potenzial für Inkonsistenzen besonders groß ist.

2.3 ZUSAMMENFASSUNG UND DISKUSSION

In Kapitel 2.1 wurden unterschiedliche Vorgehensmodelle zur Entwicklung mechatro-

nischer Systeme vorgestellt und miteinander verglichen. Diese haben zum Teil einen

ähnlichen Ablauf, wenngleich sie nicht alle denselben Zeitraum im Lebenszyklus eines

Systems abdecken. Auch bei der detaillierteren Betrachtung fallen Ähnlichkeiten auf,

die sich insbesondere anhand gleicher Prozessschritte ausprägen.

Neben diesen Ähnlichkeiten gibt es jedoch auch Unterschiede. Diese ergeben sich

u. a. aus der Herkunft und den Zielen der Vorgehensmodelle. So geht das Systems

Engineering bspw. von einer umfassenden Gesamtsystembetrachtung unter Berück-

sichtigung nicht-technischer Systeme aus. Die VDI 2206 wurde hingegen entwickelt,

um bereits bestehende domänenspezifische Vorgehensmodelle zu integrieren. Da-

her wird großer Wert auf den lösungsneutralen Systementwurf gelegt und die domä-

nenspezifischen Entwicklungsvorgehensweisen nicht näher betrachtet. Die ISO 26262

wurde für die Entwicklung sicherheitskritischer E/E-Funktionen spezifiziert, weshalb im

Unterschied zu den anderen Vorgehensmodellen der Fokus auf der Abschätzung

von Risiken sowie der Entwicklung von Gegenmaßnahmen liegt. Die industrielle Vor-

gehensweise, die in dieser Arbeit am Beispiel der Automobilindustrie beschrieben

wurde, unterscheidet sich am stärksten von den sonstigen Vorgehensmodellen. Es

wird auf die lösungsneutrale Beschreibung der Systeme verzichtet, da die überwie-

gende Anzahl der Entwicklungen evolutionäre Weiterentwicklungen sind, womit der

grundsätzliche Aufbau des Produkts unverändert bleibt.

Unabhängig vom genutzten Vorgehensmodell werden verschiedene Modelle und

Dokumente genutzt, um den Systementwurf und die Detailentwicklung durchzufüh-

ren und zu dokumentieren. Zusammenfassend können diese digitalen Ergebnisse als

Artefakte bezeichnet werden. Neben der kurzen Vorstellung der Artefakte war die

Erkenntnis des vorliegenden Kapitels, dass die Artefakte nicht inhaltlich isoliert existie-

ren, sondern Redundanzen und Abhängigkeiten zueinander aufweisen, ein essentiel-

les Ergebnis dieses Kapitels. Auf Probleme, die sich daraus ergeben und Lösungsan-

sätze, die diese adressieren, wird im folgenden Kapitel 3 eingegangen.

3 DURCHGÄNGIGE NACHVERFOLGBARKEIT

Ein Ansatz, um die in Kapitel 2 beschriebenen Redundanzen und Abhängigkeiten der

Artefakte der Systementwicklung zu dokumentieren und somit allen an der Entwick-

lung beteiligten Entwicklern zur Verfügung zu stellen, ist die durchgängige Nachver-

folgbarkeit bzw. Traceability

. Dabei werden die inhaltlichen Abhängigkeiten zwi-

schen den systembeschreibenden Artefakten und deren Elementen explizit mit Hilfe

von sog. Tracelinks abgebildet. Das Ergebnis ist eine durchgängige Nachverfolgbar-

keit, mit deren Hilfe die Artefakte untereinander konsistent gehalten werden können.

Die folgenden Kapitel geben einen Überblick über die Grundlagen, die Vorteile und

Nachteile der durchgängigen Nachverfolgbarkeit. Zunächst wird in Kapitel 3.1 näher

auf die Motivation, durchgängige Nachverfolgbarkeit zu praktizieren, eingegangen

und anschließend in Kapitel 3.2 ihre geschichtliche Entwicklung betrachtet. Eine Ein-

ordnung in den Unternehmenskontext erfolgt in Kapitel 3.5. Notwendige Grundbegrif-

fe werden in Kapitel 3.3 zusammengefasst, der grundlegende Ablauf zur Erstellung

und Verwendung von Traceability in Kapitel 3.4 dargestellt und die Herausforderun-

gen, die mit dieser Methode verbunden sind, in Kapitel 3.7 diskutiert. Kapitelübergrei-

fend werden dabei Traceability-Kriterien vorgestellt, mit deren Hilfe sich Software-

Werkzeuge charakterisieren lassen. Diese Kriterien wurden durch den Autor in Zu-

Die beiden Begriffe „(durchgängige) Nachverfolgbarkeit“ und „Traceability“ werden im

Rahmen dieser Arbeit synonym verwendet.

Durchgängige Nachverfolgbarkeit

sammenarbeit mit Simon Königs, Grischa Beier und Rainer Stark während der Erarbei-

tung der Veröffentlichung [Königs et al. 2012] erarbeitet und werden im Text „fett“

gekennzeichnet und die zugehörigen Ausprägungen bzw. Eigenschaften „kursiv“

dargestellt.

In Kapitel 3.6 werden die Traceability-Kriterien anschließend genutzt, um die Eigen-

schaften der dort vorgestellten aktuell verfügbaren kommerziellen Werkzeuge zur

Verwaltung, Modellierung und Verwendung von Traceability zu beschreiben. Beson-

dere Berücksichtigung findet dabei der ModelTracer (siehe Kapitel 3.6.4.3), welcher

im Rahmen des BMBF-geförderten Projekts ISYPROM in Kooperation der TU Berlin,

dem Fraunhofer IPK und der InMediasP GmbH entwickelt wurde, da er als Basis für

die prototypische Implementierung und anschließende Validierung der im Rahmen

dieser Arbeit entwickelten Methoden dient.

Abschließend werden in Kapitel 3.8 vorhandene Methoden, deren Umsetzung in

Software-Tools und Herausforderungen diskutiert und die Bedarfe für Ansätze in den

Bereichen der Erfassung von Tracelinks und Pflege von Tracelink-Modellen abgeleitet.

Das Ziel dieses Kapitels ist es, einen Überblick über das Thema durchgängige Nach-

verfolgbarkeit zu geben. Nach dem Lesen sollten die Grundbegriffe, Methoden so-

wie deren Umsetzungen bekannt und Vor- und Nachteile dieses Ansatzes verstanden

sein. Aus den Nachteilen sowie deren Eingrenzung auf die unterschiedlichen Phasen

der durchgängigen Nachverfolgbarkeit werden im folgenden Kapitel 4 die For-

schungsfragen abgeleitet und auf dieser Basis die Hypothesen formuliert.

3.1 BEDARF NACH DURCHGÄNGIGER NACHVERFOLGBARKEIT

Eine häufig getroffene Aussage im Zusammenhang mit modernen mechatronischen

Systemen ist, dass deren hohe Komplexität eine große Herausforderung für die Ent-

wicklung darstellt (vgl. bspw. [Tretow et al. 2008, S. 36]). Um die Ursachen dafür zu

analysieren, ist es zunächst notwendig, die Begriffe „System“ und „Komplexität“ nä-

her zu betrachten.

Allgemein definiert besteht ein System aus einer Anzahl von Elementen bzw. Teilsys-

temen, die miteinander in Beziehung stehen [Ehrlenspiel 2007, S. 20]. Es erfüllt zumeist

eine oder mehrere Funktionen [Haskins 2006, S. 1.5] und lässt sich durch eine System-

grenze von der Umwelt abgrenzen.

Die Komplexität ist eine Eigenschaft dieser Systeme, die sich objektiv aus der Anzahl

der das System ausmachenden Systemelemente und deren Abhängigkeiten ermit-

teln lässt [VDI-Richtlinie 2206, S. 4; Weilkiens 2006, S. 10; Ehrlenspiel 2007, S. 36]. Je

nach Definition werden zusätzlich noch die Anzahl der möglichen Systemzustände

Durchgängige Nachverfolgbarkeit

(und damit die Dynamik des Systems) in die Ermittlung der Komplexität miteinbezo-

gen (vgl. bspw. [Probst und Ulrich 1988, S. 58]).

Bei der Betrachtung heutiger Systeme fällt auf, dass eine Verschiebung von rein me-

chanischen Systemen hin zu mechatronischen Systemen stattgefunden hat, sodass

Elektronik und Software mittlerweile einen immer größeren Stellenwert für die Realisie-

rung von Funktionen einnehmen [Conrad et al. 2005, S. 3; Dannenberg und Burgard

2007, S. 4]. Das bedeutet, dass die unterschiedlichen Systemelemente häufig nicht

mehr nur einer Disziplin zuzuordnen sind, sondern vielmehr allen drei Disziplinen Me-

chanik, Elektronik/Elektrik und Software. Darüber hinaus erfolgt die Realisierung der

Funktionen durch ein enges Zusammenspiel der Wirkprinzipien der Disziplinen, was zu

einer großen Anzahl von Abhängigkeiten zwischen den Disziplinen führt [Conrad et

al. 2005, S. 3-4]. Zusätzlich sind bspw. im Automobilbau immer mehr Teilsysteme an

der Realisierung mehrerer Funktionen beteiligt

, was weitere Abhängigkeiten zwi-

schen den Teilsystemen und -funktionen zur Folge hat [Conrad et al. 2005, S. 3-4;

Dannenberg und Burgard 2007, S. 12]. Es kommt somit zu einer Erhöhung der Anzahl

der Abhängigkeiten zwischen den Elementen in einem System. Hinzu kommt, dass

sich auch die Anzahl dieser Elemente stetig erhöht und somit ebenfalls zu einer Stei-

gerung der Komplexität beiträgt. So beinhaltet ein modernes Fahrzeug heute, im

Vergleich zu früher, zahlreiche Systeme, die Sicherheits- oder Komfortfunktionen erfül-

len: die Anzahl verfügbarer Sonderausstattungen hat sich bspw. in einem 7er BMW

innerhalb von zwanzig Jahren von 14 im Jahr 1986 auf 92 in im Jahr 2006 gesteigert

[Dannenberg und Burgard 2007, S. 15]. Ebenfalls anschaulich illustriert wird diese Stei-

gerung der Anzahl der Elemente dadurch, dass 1974 wenige DIN A4 Seiten ausreich-

ten, um die Anforderungen an das Instrumentenpanel eines Fahrzeugs zu erfassen.

Heutzutage ähnelt der Umfang einer solchen Spezifikation eher dem eines Buches

[Almefelt et al. 2006, S. 121].

Zu der Komplexität des Systems kommt die Komplexität der Entwicklung des Systems

hinzu. Wie in Kapitel 2.2 dargestellt, werden für die Entwicklung eines mechatroni-

schen Systems unterschiedliche Artefakte durch zahlreiche Entwickler der beteiligten

Fachabteilungen in spezialisierten Werkzeugen erstellt, die zwar separat aber trotz-

dem inhaltlich aufeinander aufbauend entwickelt werden, wodurch Redundanzen

und Abhängigkeiten zwischen ihnen bestehen können [Egyed 2000, S. 28; VDI-

Richtlinie 2206, S. 47; Tudorache 2006, S. 2]. Das Wissen über diese Abhängigkeiten

liegt jedoch meistens nur implizit vor und ist nicht allen Entwicklern bewusst [Aizen-

bud-Reshef et al. 2006, S. 515; Tudorache 2006, S. 3]. Insbesondere bei Systemen, die

So werden bspw. beim PRE-Safe-System von Mecedes-Benz Crash-Sensoren, ESP, Sitzver-

stellung, Sicherheitsgurt und Schiebedach zusätzlich genutzt, um im Verbund Sicherheits-

funktionen zu realisieren [Dannenberg und Burgard 2007, S. 12].

Durchgängige Nachverfolgbarkeit

verteilt entwickelt werden, kann es deshalb aufgrund fehlender Kommunikation bei

Änderungen zu Schwierigkeiten kommen, was wiederum Inkonsistenzen zwischen

den Artefakten zur Folge haben kann [Pinheiro 2003, S. 91; Aizenbud-Reshef et al.

2006, S. 515; Tudorache 2006, S. 3]. Dies wurde auch im Rahmen einer Studie, in der

1401 Ingenieure aus unterschiedlichen Branchen befragt wurden, bestätigt: bei Än-

derungen der Artefakte bemängeln 51 % der Ingenieure, nicht rechtzeitig informiert

zu werden [Müller et al. 2013, S. 24].

Dies stellt vor dem Hintergrund, dass Änderungen während der Entwicklung sehr häu-

fig sind, ein Problem dar. So ändern sich üblicherweise mehr als 50 % der Systeman-

forderungen, bevor ein System zum Einsatz kommt [Kotonya und Sommerville 1998].

Dies wurde auch im Bereich des Systems Engineering (vgl. Kapitel 2.1.2) erkannt, und

das Management bzw. die Abschätzung der Auswirkungen von Änderungen als

wichtige Aufgabe des Systems Engineers definiert [Haskins 2006, S. 8.05].

Ein Ansatz, diese Abhängigkeiten zwischen den unterschiedlichen Artefakten der Sys-

tementwicklung zu verwalten, ist es, sie mit Hilfe von Methoden der Traceability expli-

zit zu dokumentieren. Die so erfassten Tracelinks können genutzt werden, um sog.

Auswirkungsanalysen

durchzuführen, mit welchen auch bei komplexen Systemen

von Änderungen betroffene Elemente identifiziert werden können [Gotel und Finkel-

stein 1994, S. 99; Spanoudakis et al. 2004, S. 105; Almefelt et al. 2006, S. 128; Eigner

und Stelzer 2009, S. 79; Mäder et al. 2009c, S. 7]. Auf ähnliche Weise helfen sie, das

Systemverständnis und die Transparenz der Entwicklung zu steigern, indem sie Ab-

hängigkeiten für alle Entwickler einsehbar dokumentieren [Sutinen et al. 2004, S. 5;

Maurer 2007, S. 37]. Darüber hinaus ermöglichen es die Tracelinks, die Entstehung der

unterschiedlichen Artefakte nachzuvollziehen (z. B. lassen sich die Begründung oder

der Urheber für Anforderungen mit ihrer Hilfe festhalten) [Ramesh und Edwards 1993,

S. 257; Gotel und Finkelstein 1994, S. 99; Dömges und Pohl 1998, S. 56; Ramesh und

Jarke 2001, S. 21; Egyed und Grünbacher 2002, S. 168-169; Pinheiro 2003, S. 101;

Spanoudakis et al. 2004, S. 105; Almefelt et al. 2006, S. 122], deren Konsistenz unterei-

nander zu gewährleisten [Ramesh und Edwards 1993, S. 256; Sutinen et al. 2000, S. 12;

Tudorache 2006, S. 52] sowie bei der Absicherung der Systeme, die Anforderungen

ihren erfüllenden Elementen zuzuordnen [Ramesh und Edwards 1993, S. 256; Gotel

und Finkelstein 1996, S. 167; Dömges und Pohl 1998, S. 56; Ramesh und Jarke 2001,

S. 16-17; Egyed und Grünbacher 2002, S. 168-169; Spanoudakis et al. 2004, S. 105;

Mäder et al. 2009c, S. 7; ISO 26262-3, S. 16]. Traceability kann demnach eine erhebli-

che Unterstützung bei der Entwicklung komplexer Systeme leisten.

engl.: Impact Analysis

Durchgängige Nachverfolgbarkeit

3.2 URSPRUNG UND VERBREITUNG DURCHGÄNGIGER NACHVERFOLGBARKEIT

Die Ursprünge dieser Methode liegen im Requirements Engineering der Softwareent-

wicklung, wo bereits 1978 das erste Werkzeug zur Verwaltung von Tracelinks in einem

Zeitschriftenaufsatz veröffentlicht wurde [Pierce 1978]. Seitdem wurde dieser, sehr

spezifische und nur auf Anforderungen bezogene, Ansatz erweitert und kann zur

Nachverfolgung aller, während der modellbasierten Entwicklung von Software ent-

stehender, Artefakte genutzt werden. In diesem Zusammenhang ergeben sich, ne-

ben reinen Dokumentationszwecken, weitere Vorteile bei der Validierung und Verifi-

kation der Software gegenüber den Anforderungen oder der Softwarewartung. Dar-

über hinaus können bei Modelltransformationen Abhängigkeiten automatisch do-

kumentiert und somit die manuellen Aufwände minimiert werden [Aizenbud-Reshef

et al. 2006, S. 515; Winkler und Pilgrim 2010, S. 531].

Aus diesen Gründen wird im Bereich der Softwareentwicklung Traceability als Kenn-

wert für Systemqualität und Prozessreife angesehen und insbesondere für sicher-

heitskritische Softwarefunktionen durch zahlreiche Standards vorgeschrieben [Aizen-

bud-Reshef et al. 2006, S. 515]. So gilt bspw. die MIL-STD-498 [Military Standard MIL-

STD-498] bei militärischen Auftragsentwicklungen für das Department of Defense der

USA und die DIN EN 9115 [DIN EN 9115] bei der Entwicklung von Luftfahrtsystemen.

Die Normen ISO 12207 [ISO 12207:2008], ISO 15504 [ISO/IEC 15504-5] und die IEEE

Std. 1219 Software Maintenance [IEEE 1219] adressieren allgemein die Softwareent-

wicklung bzw. die Wartung von Software. Dabei fordern alle genannten Standards

ähnliche Formen der Traceability. So soll die Nachverfolgbarkeit zwischen den Kun-

den-, System- und Softwareanforderungen, der Systemarchitektur sowie dem Soft-

wareentwurf und teilweise sogar dem detaillierten Softwaredesign etabliert und ge-

pflegt werden. Selbst die ISO 9000 [DIN EN ISO 9000], welche beschreibt, welche An-

forderungen ein Unternehmen bzgl. des Qualitätsmanagements erfüllen muss, be-

fasst sich mit Traceability. Die geforderte Form ist allerdings deutlich weniger spezi-

fisch als bei den zuvor genannten Standards. Es wird lediglich definiert, dass Doku-

mentation im Allgemeinen der Rückverfolgbarkeit dient und es ermöglicht werden

soll, u. a. den Werdegang und die Verwendung eines Produkts zu verfolgen.

Aufgrund der weit verbreiteten Anwendung gibt es im Bereich der Softwareentwick-

lung bereits zahlreiche positive Erfahrungen im Umgang mit Traceability. Diese äu-

ßern sich bspw. in der Verringerung der Anzahl später Änderungen, da ein Vergessen

von Anforderungen vermieden wird, was einen direkten Einfluss auf die Entwicklungs-

kosten hat. Die Vermeidung des Vergessens von Anforderungen ist auch bei sicher-

heitskritischen Anforderungen von großer Bedeutung, da bei diesen eine Nichterfül-

lung schwerwiegende Folgen haben kann. Darüber hinaus werden Traceability-

Informationen verwendet, um bspw. ein verbessertes Projektmanagement zu realisie-

Durchgängige Nachverfolgbarkeit

ren. Dabei werden die Status der Teilentwicklungen über Tracelinks aggregiert und

somit der übergreifende Projektfortschritt ermittelt. Zudem werden die Tracelinks ge-

nutzt, um bei Änderungen deren Auswirkungen auf andere Entwicklungsbereiche,

die Kosten der Änderung abzuschätzen und über die Notwendigkeit und den Um-

fang der Änderung zu entscheiden [Ramesh et al. 1997, S. 411; Dömges und Pohl

1998, S. 54].

Bei der Entwicklung mechatronischer Systeme findet durchgängige Nachverfolgbar-

keit aktuell noch keine flächendeckende Anwendung, obwohl sie gerade bei inter-

disziplinären Änderungsprozessen großes Potenzial birgt. Vielmehr wird sie sehr punk-

tuell bspw. bei der Entwicklung von Embedded Systems eingesetzt, da Traceability

hier bei sicherheitskritischen Funktionen gesetzlich durch die ISO 26262 vorgeschrie-

ben ist (vgl. [ISO 26262-8, S. 8]). Daneben kommt Traceability, im Sinne einer Doku-

mentation von Abhängigkeiten, zur Beantwortung sehr spezifischer Fragestellungen

zum Einsatz, um bspw. eine Modularisierung von Systemen zu planen [Maurer 2007].

3.3 GRUNDBEGRIFFE DURCHGÄNGIGER NACHVERFOLGBARKEIT

Vor dem Hintergrund, dass Traceability Anwendungsfelder in unterschiedlichen Dis-

ziplinen hat und in diesen jeweils weiterentwickelt wurde, ist es nicht verwunderlich,

dass sich keine übergreifend einheitliche Definition für Traceability herausgebildet hat

[Winkler und Pilgrim 2010, S. 530]. Vielmehr gibt es zahlreiche Definitionen, die Aspek-

te der jeweiligen Forschungsfelder aufgreifen und integrieren.

Eine allgemein gehaltene Definition kann dem Standard Glossary of Software Engi-

neering Terminology des Institute of Electrical and Electronics Engineers (IEEE) ent-

nommen werden. Diese besagt, dass Traceability dem Ausmaß entspricht, in dem

eine Beziehung zwischen mindestens zwei Produkten des Entwicklungsprozesses

etabliert werden kann. Dies gilt insbesondere, wenn diese eine Vorgänger-

Nachfolger- oder Eltern-Kind-Beziehung zueinander haben [IEEE 610.12-1990, S. 78].

Edwards und Howell definieren Traceability ebenfalls allgemein als Technik, mit deren

Hilfe Beziehungen zwischen Anforderungen, dem Design und der finalen Implemen-

tierung des Systems zur Verfügung gestellt werden können [Edwards und Howell

1992, S. 3.7].

Die Definitionen für Traceability aus dem Bereich der Modellbasierten Entwicklung

(MBE) (von Software) sind ähnlich gefasst, beziehen sich jedoch spezifisch auf die

Gegebenheiten der MBE, bei der ein besonderer Fokus auf Modelltransformationen

liegt [Winkler und Pilgrim 2010, S. 534]. So bezeichnen Paige et al. Traceability als Fä-

higkeit, eindeutig identifizierbare Objekte chronologisch auf eine Art und Weise zu

verknüpfen, die Sinn macht. Dabei handelt es sich bei den Objekten vorrangig um

Durchgängige Nachverfolgbarkeit

Modelle und Modellelemente, die mit Hilfe verketteter manueller oder automatisier-

ter Operationen ineinander überführt werden [Paige et al. 2008, S. 49]. Aizenbud-

Reshef et al. haben ein ähnliches Verständnis und bezeichnen jegliche Beziehung

zwischen Artefakten der Software-Entwicklung als Traceability

. Ausdrücklich schlie-

ßen die Autoren in dieser Definition Verknüpfungen ein, die durch Transformationen

generiert, die basierend auf existierenden Informationen berechnet und die basie-

rend auf Änderungshistorien ermittelt wurden [Aizenbud-Reshef et al. 2006, S. 516].

Im Bereich des (Software) Requirements Engineerings wird Traceability hingegen

deutlich spezifischer aus Sicht der Anforderung und der zugehörigen Anforderungs-

spezifikation definiert. Requirements Traceability bezeichnet in diesem Zusammen-

hang die Fähigkeit, den Lebenszyklus einer Anforderung zu beschreiben und nach-

zuvollziehen [Gotel und Finkelstein 1994, S. 97]. Werden dabei auch andere Artefakte

als Anforderungsspezifikationen mit einbezogen, wird von Extra-Requirements Trace-

ability gesprochen [Pinheiro 2003, S. 95]. Dabei wird weiter in Forward-Traceability

und Backwards-Traceability bzw. Pre- und Post-Requirements-Specification-

Traceability unterschieden, wodurch zum Ausdruck gebracht wird, dass die Nachver-

folgbarkeit einmal von der Anforderung über beliebige Zwischenprodukte zu den

Komponenten des zu entwickelnden Systems und einmal von der Anforderung zu ih-

ren Ursprüngen realisiert wird [Gotel und Finkelstein 1994, S. 97; Pinheiro 2003, S. 93].

Eine Anforderung wird somit als nachverfolgbar bezeichnet, wenn die Quelle, der

Grund für die Existenz, die Beziehungen zu weiteren Anforderungen und Artefakten

sowie der Status der Anforderung bekannt sind [Sutinen et al. 2000, S. 5].

Obwohl Traceability im Rahmen des Systems Engineerings als wichtig anerkannt wird

[Haskins 2006, S. 4.04], hat sich bisher noch keine an die spezifischen Vorgehenswei-

sen des Systems Engineerings angepasste Definition von Traceability herausgebildet.

Aus diesem Grund wird in dieser Arbeit die folgende Definition verwendet, die an die

vorangegangenen angelehnt wurde:

Traceability ist eine Methode zur Unterstützung der Entwicklung me-

chatronischer Systeme, bei welcher Abhängigkeiten zwischen den

Elementen produktbeschreibender Artefakte explizit dokumentiert

werden. Das Ziel der Methode, der Zustand einer durchgängigen

Nachverfolgbarkeit zwischen den produktbeschreibenden Artefak-

ten, wird ebenfalls mit dem Begriff Traceability beschrieben.

(1)

Bei den erwähnten Tracelinks handelt es sich um Software-Objekte, die je nach Um-

setzung bspw. die IDs der voneinander abhängigen Elemente oder Parameter bein-

Im Gegensatz zu den zuvor genannten Definitionen wird hier nicht zwischen Traceability

und Tracelink unterschieden.

Durchgängige Nachverfolgbarkeit

halten und darüber deren Abhängigkeit ausdrücken [van Gorp et al. 2006, S. 2]. In

Abbildung 13 ist dies für die Abhängigkeit zweier Elemente schematisch dargestellt,

wobei der Tracelink selbst zusätzlich als Pfeil visualisiert ist.

Abbildung 13: Schematische Darstellung des Objekts „Tracelink“

Darüber hinaus können die Tracelinks noch ergänzende Metadaten enthalten, um

weiterführende Analysen zu ermöglichen oder die Entstehung der Links nachzuvoll-

ziehen [Ramesh et al. 1997, S. 401; Aizenbud-Reshef et al. 2006, S. 517; Winkler und

Pilgrim 2010, S. 536-537]. Grundsätzlich lassen sich hinsichtlich der Semantik der

Tracelinks typisierte und untypisierte unterscheiden, je nachdem, ob sie lediglich die

grundsätzliche Abhängigkeit ausdrücken oder eine weitergehende Bedeutung ha-

ben. Über die Notwendigkeit zu typisieren und, im Fall der Typisierung, die Arten von

Tracelinks, gibt es weder in der Forschung noch in der Praxis eine allgemeingültige

Meinung. Grundsätzlich gilt, dass die spätere Verwendung der Tracelinks vorgibt, ob

und wenn ja, welche Semantik ein Tracelink beinhalten sollte. Während untypisierte

Tracelinks den Vorgang der Tracelink-Erfassung erleichtern, da nicht zwischen unter-

schiedlichen Arten von Verknüpfungen unterschieden werden muss, ermöglichen

typisierte Tracelinks durch die zusätzliche Semantik weiterführende automatisierbare

Analysen.

Bei typisierten Tracelinks gibt es zudem bei den unterschiedlichen Arten der Tracelinks

keine Einigung auf einen definierten Umfang von Ausprägungen, da unterschiedli-

che Stakeholder unterschiedliche Anforderungen an Tracelinks und mögliche Analy-

seformen haben [Ramesh et al. 1997, S. 401]. Trotzdem werden im Folgenden einige

Arten von Tracelinks vorgestellt. Die Auswahl orientiert sich an Aizenbud-Reshef et al.

[Aizenbud-Reshef et al. 2006, S. 517-518] und erhebt keinen Anspruch auf Vollstän-

digkeit:

- Satisfy-Tracelinks (erfüllen) beschreiben den Zusammenhang zwischen Ele-

menten zweier Artefakte, bei denen ein Element Bedingungen oder Forde-

rungen des anderen zu erfüllen hat.

- Justify-Tracelinks (rechtfertigen) zwischen zwei Elementen beschreiben, dass

ein Element die Daseinsberechtigung für ein anderes darstellt.

Durchgängige Nachverfolgbarkeit

- Describes-Tracelinks (beschreiben) drücken aus, dass ein Element den Inhalt

des anderen näher beschreibt.

- Depends-on-Tracelinks (von etwas abhängen) beschreiben einen Sachver-

halt, bei dem ein Element von dem Vorhandensein eines anderen abhängt.

- Validates-Tracelinks (validieren) verbinden zwei Elemente, wenn das eine zur

Validierung des anderen vorgesehen ist.

In Bezugnahme auf die in Kapitel 2.1.5 beschriebene Entwicklung eines mechatroni-

schen Außenspiegels werden somit die Funktion „Außenspiegel beheizen“ und die

Anforderung „Automatisches Entfernen von Eis vom Außenspiegel innerhalb von

t = 360 s“ mit Hilfe eines Satisfy-Tracelinks verknüpft, der ausdrückt, dass die Anforde-

rung durch die Funktion erfüllt wird. Dieselbe Anforderung ist zusätzlich über einen

Describes-Tracelink mit einem detaillierten Dokument, in dem Verfahren zur Berech-

nung des Aufheizverhaltens beschrieben sind, verknüpft. Die Unterscheidung der

Tracelink-Typen hat bspw. bei einer Auswirkungsanalyse, in der die Folgen der Verrin-

gerung der geforderten Zeit in der Anforderung auf t = 300 s bestimmt werden sollen,

den Vorteil, dass der Analyseumfang deutlich eingeschränkt werden kann. Da be-

schreibende Dokumente von der Änderung nicht betroffen sind, können diese über

die Einschränkung der untersuchten Typen von Tracelinks bei der Analyse ausge-

klammert werden. Diese Einschränkung wäre im Fall von untypisierten Tracelinks nicht

möglich, da die Anforderung sowohl mit der Funktion als auch mit dem beschrei-

benden Dokument mit einem Tracelink verknüpft wäre, der lediglich eine grundsätz-

liche Abhängigkeit ausdrückt, ohne deren Art zu spezifizieren.

Dieses Beispiel zeigt, dass insbesondere bei der Bearbeitung komplexer Artefakte mit

vielen Elementen und Abhängigkeiten eine Unterscheidung unterschiedlicher Arten

von Tracelinks notwendig ist. Aus Sicht des Autors dieser Arbeit sollte daher die Typi-

sierung zur Steigerung des Nutzens durchgängiger Nachverfolgbarkeit praktiziert

werden. Dazu muss jedoch zunächst festgelegt werden, wie die Tracelinks verwen-

det werden und welche Arten von Tracelinks dementsprechend notwendig sind. Um

die Erfassung der Tracelinks übersichtlich zu gestalten, sollten darüber hinaus nur die

Tracelink-Arten bei der Erfassung angeboten werden, die für die Kombination der

jeweiligen Artefakte zuvor als sinnvoll festgelegt wurden.

Bei der Umsetzung der in Kapitel 5.4 beschriebenen Methode zur effizienten Erfassung

von Tracelinks wurde jedoch auf die Typisierung verzichtet. Hintergrund dieser Verein-

fachung ist, dass nicht die Verwendung der Tracelinks (für die die Typisierung not-

wendig ist) im Fokus der Forschung lag, sondern deren effiziente Modellierung. Für die

Entwicklung und Evaluation der Methode war eine Unterscheidung unterschiedlicher

Arten von Tracelinks nicht notwendig. Allerdings ist eine Erweiterung der Methode um

diese Aspekte problemlos möglich und sollte zukünftig angestrebt werden.

Durchgängige Nachverfolgbarkeit

Darüber hinaus kann Tracelinks eine Richtung (gerichtet von Element 1 nach Ele-

ment 2; gerichtet von Element 2 nach Element 1 oder ungerichtet zwischen Ele-

ment 1 und Element 2) zugewiesen werden, die eine Reihenfolge in Kausalität oder

Zeit ausdrückt. Diese Richtung dient jedoch nur als Hinweis für den Anwender, da es

für die Auswertung notwendig ist, in beide Richtungen entlang der Links navigieren

zu können [Ramesh und Edwards 1993, S. 257; Winkler und Pilgrim 2010, S. 532]. Somit

kann trotz vorgegebener Richtung, bspw. von Anforderungen zu den sie erfüllenden

Bauteilen, und anders herum navigiert werden.

Weiter besteht die Möglichkeit, den Tracelinks eine Art Gewichtung zuzuordnen, mit

deren Hilfe bspw. das Ausmaß des Einflusses der Änderung eines Ausgangselements

auf die davon abhängigen Elemente beschrieben werden kann. In diesem Fall

spricht man bei der Art der Traceability von quantitativer Traceability, während die

qualitative Traceability lediglich die Identifikation betroffener Elemente erlaubt [Suti-

nen et al. 2002, S. 1]. Ein weiteres Beispiel quantitativer Traceability ist die Verknüp-

fung von Produkt- und Funktionsstruktur mit gewichteten Tracelinks. Mit Hilfe eines At-

tributs des Tracelinks kann anschließend abgeschätzt werden, in welchem Ausmaß

ein Bauteil an der Erfüllung einer Funktion beteiligt ist. Bei Kenntnis der Kosten der

Bauteile können somit die Kosten einer Funktion bestimmt und bspw. für die Kalkulati-

on verwendet werden. Eine Umsetzung dieser quantitativen Traceability findet sich in

der Software METUS der Firma ID Consult (siehe auch Kapitel 3.6.3.1). Bei dem zuvor

bemühten Beispiel des Außenspiegels sind bspw. neben der Heizspirale und dem

An/Aus-Schalter zusätzlich der Kabelstrang (teilweise), die Spiegelhalterung (hinsicht-

lich der Befestigung der Heizspirale) und Rechenressourcen eines Steuergeräts an der

Realisierung der Funktion „Außenspiegel beheizen“ beteiligt (siehe Abbildung 14).

Abbildung 14: Quantitative Traceability am Beispiel des mechatronischen Außenspiegels

Mit Hilfe der gewichteten Tracelinks lassen sich nun die Funktionskosten zu 6,6 € be-

rechnen und ggf. in Kombination mit der Durchführung eines Quality-Function-

Deployment (QFD), bei dem die Wichtigkeit der einzelnen Funktionen in Abhängig-

Durchgängige Nachverfolgbarkeit

keit der Kundenwünsche bestimmt wird, festgelegt werden, ob die Realisierung unter

den gegebenen Umständen lohnenswert ist.

Wie bei der Typisierung von Tracelinks wird auch die Unterscheidung in horizontale

und vertikale Traceability in der Forschung ohne Einigung auf ein gemeinsames Ver-

ständnis diskutiert. Pfleeger und Bohner sowie Bianchi et al. bezeichnen Traceability

dann als vertikal, wenn sie durch Tracelinks zwischen voneinander abhängigen Ele-

menten desselben Artefakts hergestellt wird. Besteht die Abhängigkeit der Elemente

hingegen über mehrere unterschiedliche Artefakte hinweg, sprechen sie von einer

horizontalen Traceability [Pfleeger und Bohner 1990, S. 323; Bianchi et al. 2000, S. 150].

Nejmeh et al. beschreiben die gleichen Kategorien, vertauschen jedoch deren Be-

deutungen. Nach ihrer Definition liegt somit vertikale Traceability dann vor, wenn

Elemente unterschiedlicher Artefakte mit Tracelinks in Beziehung gesetzt werden und

horizontale Traceability, wenn Elemente desselben Artefakts verknüpft werden

[Nejmeh et al. 1989]. Auch Winkler und Pilgrim unterscheiden zwischen horizontaler

und vertikaler Traceability. Im Gegensatz zu den vorangegangenen Definitionen be-

ziehen sie diese jedoch nicht auf Artefakte, sondern auf den zeitlichen Ablauf einer

Entwicklung: während Tracelinks zwischen Artefakten derselben Projektphase Teil ei-

ner horizontalen Traceability sind, gehören die zwischen Artefakten unterschiedlicher

Projektphasen zur vertikalen [Winkler und Pilgrim 2010, S. 533].

Horizontale und vertikale Traceability haben somit grundlegend unterschiedliche Be-

deutungen. Die erste – chronologische – bezieht sich auf den zeitlichen Ablauf der

Prozessphasen, in denen die Artefakte erstellt werden. Die zweite – artefakt-

bezogene – behandelt die Frage, ob die Tracelinks innerhalb eines oder zwischen

zwei unterschiedlichen Artefakten modelliert werden. Bei letzterer Bedeutung gibt es

sogar zwei invertierte Meinungen bzgl. der Ausrichtung von horizontal und vertikal,

was sich aus der visuellen Darstellung, wie Pfleeger und Bohner, Bianchi et al. und

Nejmeh et al. einen Prozess dokumentieren (von links nach rechts bzw. von oben

nach unten), ergibt. Aus diesem Grund werden diese Bedeutungen für die Charakte-

risierung einer Traceability im Rahmen dieser Arbeit getrennt betrachtet und mit Pro-

zessphasen-Kontext und Artefakt-Kontext bezeichnet [Königs et al. 2012, S. 930].

Der Prozessphasen-Kontext beschreibt den Zustand, ob ein Tracelink

Elemente zweier Artefakte der gleichen Phase (phasenintern) oder

unterschiedlicher Prozessphasen (phasenübergreifend) verbindet.

(2)

Somit sind bspw. Tracelinks zwischen Anforderungen einer oder mehrerer Spezifikati-

onen phasenintern, während solche von Anforderungen zu den sie erfüllenden Funk-

tionen der Funktionsstruktur oder Bauteilen der Produktstruktur phasenübergreifend

sind.

Durchgängige Nachverfolgbarkeit

Der Artefakt-Kontext bezieht sich hingegen auf die Artefakt-

Zugehörigkeit der in Abhängigkeit zueinander stehenden Elemente.

Sind beide in einem Artefakt enthalten, handelt es sich um eine ar-

tefaktinterne, bei unterschiedlichen Artefakten um eine artefakt-

übergreifende Traceability.

(3)

Tracelinks zwischen Anforderungen einer Spezifikation sind somit artefaktintern, wäh-

rend Tracelinks zwischen Anforderungen und den sie erfüllenden Funktionen der

Funktionsstruktur artefaktübergreifend sind.

3.4 PHASEN DER DURCHGÄNGIGEN NACHVERFOLGBARKEIT

Durchgängige Nachverfolgbarkeit lässt sich in vier Phasen unterteilen: Planung von

Traceability, Erfassung von Tracelinks, Verwendung von Tracelinks und Pflege von

Tracelink-Modellen [Winkler und Pilgrim 2010, S. 539]. Im Folgenden werden diese

Phasen vorgestellt.

3.4.1 ERFASSUNG VON TRACELINKS

Die Erfassung von Tracelinks beinhaltet die Identifikation von Abhängigkeiten zwi-

schen Elementen unterschiedlicher Artefakte und die Modellierung der entspre-

chenden Tracelinks. Dabei kann zwischen der Online-Erfassung, bei der die Links

(häufig automatisch) als Nebenprodukt der Entwicklung dokumentiert werden, und

der Offline-Erfassung, bei der die Links entweder manuell oder automatisch im An-

schluss an die Erstellung der Artefakte ermittelt werden, unterschieden werden

[Winkler und Pilgrim 2010, S. 539].

Es handelt sich um einen wichtigen und zugleich sehr anspruchsvollen Arbeitsschritt,

da alle Methoden, die während der Verwendungsphase angewendet werden (vgl.

Kapitel 3.4.2), auf dem Ergebnis dieser Phase aufbauen [Maurer 2007, S. 18 & 37; Bie-

dermann et al. 2010, S. 309].

Grundsätzlich gilt, dass bei der Tracelink-Erfassung ein möglichst hoher Grad der Au-

tomatisierung erreicht werden sollte [Ramesh und Edwards 1993, S. 259; Pinheiro

2003, S. 110]. Die Techniken, die dabei helfen sollen, den Aufwand zu reduzieren, sind

heutzutage jedoch hauptsächlich im Bereich der Forschung und weniger in der in-

dustriellen Anwendung zu finden (vgl. bspw. [Ramesh und Jarke 2001, S. 39]). Die

Ausnahme von dieser Regel stellen Entwicklungsdisziplinen dar, in denen Artefakte

automatisch aus anderen generiert und dabei Tracelinks abgeleitet werden können.

So lassen sich Tracelinks bspw. in der modellbasierten Softwareentwicklung während

Modelltransformationen (bspw. bei der Transformation von UML in Quellcode) ver-

Durchgängige Nachverfolgbarkeit

gleichsweise einfach als Nebenprodukt dokumentieren. Alternativ müssen die Inhalte

der Artefakte für eine automatisierte Erfassung von Tracelinks analysiert werden, um

Abhängigkeiten zwischen deren Elementen zu identifizieren. Dies wird jedoch in der

industriellen Anwendung durch die fehlende Formalisierung der Artefakte erschwert

[Winkler und Pilgrim 2010, S. 535]. So werden bspw. Anforderungen häufig in Form von

Fließtexten beschrieben. In diesen Texten müssen zunächst die Kerninhalte identifiziert

werden, um sie dann letztlich mit Elementen anderer Artefakte zu vergleichen. Dies

stellt eine weitere Herausforderung dar. Da im Bereich der Entwicklung technischer

Systeme sehr verschiedene Artefakte zur Anwendung kommen (siehe Kapitel 2.2), ist

ein einfacher Vergleich aufgrund der Verwendung unterschiedlichen Vokabulars

nicht immer zielführend. Die Abhängigkeit zwischen der Funktion „Eis entfernen“ des

Außenspiegels und dem Bauteil „Heizfolie“ könnte somit durch so einen vergleichen-

den Algorithmus nicht erkannt werden. Dies führt dazu, dass die manuelle Erfassung

der Tracelinks insbesondere im industriellen Umfeld noch sehr weit verbreitet ist und

massiv zu dem schlechten Aufwand-Nutzen-Verhältnis der durchgängigen Nachver-

folgbarkeit beiträgt. Bei der manuellen Erfassung sollten Tracelinks möglichst von den

Entwicklern und nicht von dedizierten Qualitätsteams erfasst werden, da nur sie die

Inhalte der Artefakte wirklich verstehen und somit über die Existenz von Abhängigkei-

ten entscheiden können [Pinheiro 2003, S. 110; Arkley und Riddle 2005, S. 386]. Zusätz-

lich sollten die Tracelinks nach Möglichkeit direkt bei der Feststellung einer Abhängig-

keit und damit bei der Erstellung der Artefakte dokumentiert werden, um Fehler zu

vermeiden [Pinheiro 2003, S. 104; Arkley und Riddle 2005, S. 386]. Ist eine direkte Erfas-

sung nicht möglich, sollte zumindest eine möglichst strukturierte Vorgehensweise an-

gewendet werden, um Fehler, wie das Vergessen von Tracelinks, zu vermeiden [Mau-

rer 2007, S. 18].

Methoden, die der Automatisierung, Unterstützung oder Verringerung des Aufwan-

des bei der Erfassung dienen, lassen sich unter dem Oberbegriff Modellierungsunter-

stützung zusammenfassen. Diese Unterstützung kann z. B. mit Hilfe von Template-

Ansätzen erfolgen, bei denen die Artefakte zunächst generisch ausgelegt und expli-

zit für die spätere Anpassung vorbereitet werden. Auch die Verwendung von Assis-

tenten (bzw. Wizards) ist möglich, die Nutzer durch den Erfassungsprozess führen und

den Aufwand u. U. durch Verringerung der zu betrachtenden Elementkombinatio-

nen verringert (siehe bspw. Kapitel 5.4). Ansätze, die sich mit der (teil-) automatisier-

ten Identifikation von Abhängigkeiten und der anschließenden Modellierung von

Tracelinks befassen, lassen sich in solche, die mit Hilfe von Regeln, und solche, die mit

Hilfe von Informationsrückgewinnung (engl.: Information Retrieval) vorgehen, eintei-

len [Winkler und Pilgrim 2010, S. 550].

Unabhängig von der Art der Modellierungsunterstützung können immer nur sog.

Kandidaten-Links ausgegeben werden, also Vorschläge für Tracelinks, die mit einer

Durchgängige Nachverfolgbarkeit

gewissen Wahrscheinlichkeit (die wiederum von der Art der Unterstützung abhängt)

zwischen zwei Elementen bestehen. Dabei gibt es keine Garantie, dass die vorge-

schlagenen Tracelinks vollständig oder korrekt sind [Egyed et al. 2009, S. 243; Winkler

und Pilgrim 2010, S. 551], weshalb letztliche die Entscheidung über die Existenz eines

Tracelinks immer beim Entwickler liegen muss [Pinheiro 2003, S. 111; Hayes et al. 2006,

S. 10]. Insbesondere der Aspekt der fehlenden Vollständigkeit führt dazu, dass Me-

thoden, die auf Regeln bzw. Informationsrückgewinnung basieren, für die automati-

sierte Erfassung von Tracelinks ohne menschliche Beurteilung nicht geeignet sind.

Deshalb werden sie im Rahmen dieser Arbeit ausschließlich zur Pflege von Tracelink-

Modellen (vgl. Kapitel 3.4.3 und 6.1) verwendet, da sie auf „Fehler“ in Form von feh-

lenden und falschen Tracelinks im Modell hinweisen.

3.4.2 VERWENDUNG VON TRACELINKS

Die Verwendung von Tracelinks stellt den eigentlichen Nutzen der Traceability dar.

Dabei gibt es je nach Art des Entwicklungsprojekts unterschiedliche Zwecke, für die

sich Tracelinks verwenden lassen und nach denen sich die unterschiedlichen Ansätze

kategorisieren lassen. So können sie zur Verifikation verwendet werden, indem sie ei-

ne Unterstützung bei dem Vergleich von ist-Werten eines technischen Systems mit

den soll-Werten einer Spezifikation darstellen. Ferner können auf Basis der Tracelinks

Analysen durchgeführt werden, bei denen bspw. die Auswirkungen einer Änderung

bestimmt oder aber Zusammenhänge nachvollzogen werden, um ein besseres Sys-

temverständnis zu erlangen. Darüber hinaus können Tracelinks im weiteren Sinne für

die Synthese eines Systems verwendet werden, indem bspw. einem Steuergerät

Funktionen mit Hilfe von Tracelinks zugewiesen werden. Ein weiterer möglicher Zweck

der Traceability ist die Dokumentation durchgängiger Nachverfolgbarkeit, u. a. wenn

dies durch Standards vorgeschrieben sein sollte (vgl. Kapitel 3.2). Eine ebenfalls prak-

tizierte Projektmanagement-Anwendung im Zusammenhang mit Tracelinks ist ihre

Nutzung zur Fortschrittskontrolle, bei der bspw. Informationen aggregiert und zu Fort-

schrittsberichten zusammengefasst werden können [Ramesh und Edwards 1993,

S. 258; Lago et al. 2009; Beier et al. 2013, S. 25-26]. Zusätzlich können Tracelinks auch

zur Synchronisation zweier Artefakte genutzt werden.

3.4.3 PFLEGE VON TRACELINK-MODELLEN

Für die Verwendung der Tracelinks im Sinne von Kapitel 3.4.2 ist eine hohe Qualität

des Tracelink-Modells notwendig, da dessen Fehler das Ergebnis der Analysen deut-

lich verfälschen können [Maurer 2007, S. 94; Biedermann et al. 2009, S. 119; Mäder et

al. 2009c, S. 7]. Dabei gibt es zwei mögliche Arten von Fehlern: fälschlicherweise mo-

dellierte Tracelinks zwischen Elementen, zwischen denen keine Abhängigkeit existiert

Durchgängige Nachverfolgbarkeit

(falsch positive Tracelinks) und fehlende Tracelinks zwischen Elementen, die eine Ab-

hängigkeit zueinander aufweisen (falsch negative Tracelinks) [Hayes et al. 2006, S. 7;

Biedermann et al. 2009, S. 119].

Diese Fehler im Tracelink-Modell können auf unterschiedliche Arten entstehen. Zum

einen können während der aufwändigen, manuellen Erfassung der Tracelinks Fehler

gemacht und so falsch positive und falsch negative Tracelinks dokumentiert werden

[Egyed et al. 2009, S. 256; Winkler und Pilgrim 2010, S. 539]. Zum anderen führen auch

die Weiterentwicklungen und Änderungen der Artefakte selbst [Sugden und Strens

1996, S. 458; Kotonya und Sommerville 1998] dazu, dass Abhängigkeiten zwischen

Elementen hinzukommen oder wegfallen [Cleland-Huang et al. 2003, S. 796; Egyed

2003, S. 116; Egyed et al. 2009, S. 242]. Aus diesem Grund ist es notwendig, Tracelink-

Modelle kontinuierlich zu pflegen, um einer stetigen Abnahme der Qualität vorzu-

beugen [Sutinen et al. 2000, S. 12; Egyed und Grünbacher 2002, S. 163; Mäder et al.

2008, S. 1].

Bei der Pflege werden bestehende Tracelinks auf ihre Korrektheit und Elementepaa-

re, die nicht mit Tracelinks verknüpft sind, auf Abhängigkeiten überprüft. Dabei fällt

insbesondere ersteres (die Identifikation von falsch positiven Tracelinks) Anwendern in

der manuellen Prüfung leichter, da nur existierende Tracelinks überprüft werden müs-

sen und nicht sämtliche Kombinationen von Elementen, die über keine Tracelinks ver-

fügen [Hayes et al. 2006, S. 7]. Wie die Erfassung von Tracelinks ist somit auch deren

Pflege sehr aufwändig [Egyed et al. 2009, S. 242], weshalb eine Softwareunterstüt-

zung notwendig ist. Dabei werden, wie in Kapitel 3.4.1 beschrieben, Methoden, die

auf Regeln bzw. Informationsrückgewinnung basieren, für die Pflege von Tracelink-

Modellen genutzt.

Einen Überblick über den Stand der Technik in diesem Bereich bietet Kapitel 6.1,

weshalb an dieser Stelle nicht genauer darauf eingegangen wird.

3.4.4 PLANUNG DURCHGÄNGIGER NACHVERFOLGBARKEIT

Die Planung durchgängiger Nachverfolgbarkeit befasst sich mit Aspekten, die vor

Beginn der eigentlichen Entwicklung mechatronischer Systeme durchgeführt wer-

den. Zunächst muss für das jeweilige Projekt entschieden werden, wie umfangreich

Tracelinks modelliert und damit zwischen welchen Artefakten Tracelinks erfasst wer-

den sollen. Einerseits wird empfohlen, dass insbesondere bei komplexen mechatroni-

schen Systemen ein umfassender Ansatz gewählt werden sollte, der die Artefakte al-

ler beteiligten Disziplinen berücksichtigt [Ramesh et al. 1997, S. 401]. Andererseits führt

dies zu erheblichen Mehraufwänden, die dem Nutzen und den Zielen im Rahmen

des Projekts gegenüber gestellt werden müssen. Eine kritische Auseinandersetzung

Durchgängige Nachverfolgbarkeit

mit dieser Fragestellung unter der Berücksichtigung von Projektplan, Budget, Entwick-

lungsstandards, Gesetzen und geplanten Anwendungen sollte somit im Rahmen der

Planung der Traceability erfolgen [Dömges und Pohl 1998, S. 54]. Im Anschluss an die

Festlegung, welche Artefakte einbezogen werden sollen, muss der Traceability-

Ansatz näher detailliert und die zu verwendenden Werkzeuge ausgewählt werden.

Letztere lassen sich anhand folgender Kriterien näher charakterisieren und kategori-

sieren.

Akquisition der Artefakte: In Bezug auf die Akquisition der Artefakte wird zwischen

zwei unterschiedlichen Philosophien unterschieden: integrative Software-Werkzeuge,

die Artefakte aus bestehenden Autorenwerkzeugen importieren bzw. synchronisieren

und nicht-integrative Werkzeuge, bei denen die Tracelinks nur zwischen werkzeugei-

genen Artefakten modelliert werden können.

Duplikation der Artefakte: Bei den akquirierten Artefakten kann es sich um Original-

daten handeln, so dass die durchgängige Nachverfolgbarkeit zwischen denselben

Datenobjekten hergestellt wird, die auch in den Autorensystemen erstellt und ver-

wendet werden. Alternativ kann eine Kopie (eines Teils) der Daten der Autorensys-

teme im Traceability-Werkzeug gehalten und die Tracelinks auf dieser Basis modelliert

werden.

Manipulierbarkeit der Artefakte: Dieses Kriterium beschreibt, ob die gewählten Arte-

fakte mit Hilfe des jeweiligen Traceability-Werkzeugs verändert werden können oder

nicht. Einige Werkzeuge erlauben bewusst keine Änderungen der original Daten, um

Entwickler dazu zu bringen, die Autorenwerkzeuge zu diesem Zweck zu verwenden.

Unterstützte Arten von Datenstrukturen: Die verwendeten Werkzeuge können weiter

nach den Arten von Datenstrukturen, die sie unterstützen, charakterisiert werden.

Mögliche Strukturen sind Listen oder Hierarchien, in denen Entwicklungsdaten häufig

vorliegen. Weiter sind jedoch auch poly-hierarchische (bei denen Kinderelemente

mehr als ein Elternelement besitzen können) oder netzartige Strukturen möglich.

Speicherort der Tracelinks: In Abhängigkeit des gewählten Traceability-Werkzeugs

kann der Speicherort der Tracelinks zur Charakterisierung herangezogen werden.

Tracelinks können entweder verteilt in mindestens einem der zu verknüpfenden Arte-

fakte oder separat in einer zentralen Datenbank bzw. einem Modell gespeichert

werden [Winkler und Pilgrim 2010, S. 537]. In letzterem Fall bezeichnet van Gorp et al.

das Modell, in dem diese Tracelinks gespeichert werden, als Traceability-Modell [van

Gorp et al. 2006, S. 2]. Betrachtet man dieses im Zusammenhang mit den zugehöri-

gen Artefakten, spricht man von einem integrierten Modell. Da insbesondere die

letztgenannte Definition jedoch keine Schlüsse auf den Zusammenhang mit Tracea-

bility zulässt, werden im Rahmen dieser Arbeit anschaulichere Namen für die beiden

Durchgängige Nachverfolgbarkeit

Modelle verwendet. Ersteres wird Tracelink- und letzteres Traceability-Modell

ge-

nannt.

Traceability-Schema: Einige Traceability-Werkzeuge sehen vor, dass im Rahmen der

Traceability Planung ein Metamodell spezifiziert wird, welches Tracelinktypen für be-

stimmte Element- bzw. Artefaktkombinationen vorschreibt [Winkler und Pilgrim 2010,

S. 539]. Die Restriktion mit Hilfe dieses Traceability-Schemas reduziert einerseits die Fle-

xibilität bei der Modellierung der Tracelinks, da nicht mehr jedes beliebige Elemente-

paar verknüpft werden kann, ermöglicht aber andererseits umfassendere Software

Unterstützung bei der Erfassung und Interpretation der Tracelinks.

Granularität: Ebenfalls während der Planung muss die notwendige Granularität der

zu etablierenden Traceability festgelegt werden. Diese beschreibt die Ebene, auf der

die Tracelinks zwischen den unterschiedlichen Artefakten modelliert werden. Diese

Ebenen reichen von sehr grober Traceability, die mit Hilfe von Tracelinks zwischen

zwei Artefakten etabliert wird, über die Verknüpfung von Elementen bis zur feinsten

Stufe der Traceability, bei der bis auf Parameterebene nachverfolgt werden kann.

Bei der Planung der Granularität ist zu beachten, dass es sich dabei um einen wichti-

gen Faktor bei der Balance zwischen ökonomischer und detaillierter, umfassender

Traceability handelt. Daher sollte die Granularität immer nur so detailliert wie not-

wendig gewählt werden (siehe dazu auch Kapitel 5.2.2).

Handhabung von Änderungen: Bei der Änderung von Elementen gibt es unterschied-

liche Ansätze, wie die Traceability-Werkzeuge reagieren. Zum einen ist es möglich,

dass betroffene verknüpfte Elemente von der Änderung benachrichtigt werden. An-

dererseits können im Fall der Änderungsübertragung direkt Veränderungen an den

betroffenen Elementen als Reaktion auf die Änderung ausgelöst werden.

Darstellung der Tracelinks: Je nach Traceability-Werkzeug stehen unterschiedliche

Arten der Darstellung der Tracelinks zur Verfügung. So können die Elemente der Arte-

fakte bspw. auf die Zeilen und Spalten einer Matrix verteilt werden. Eine Abhängig-

keit wird mit Hilfe eines Eintrags in der gemeinsamen Zelle der betroffenen Elemente

dokumentiert. Ebenfalls möglich ist die Darstellung als Graph, bei der Elemente als

Knoten und Tracelinks als Kanten dargestellt werden. Weit verbreitet ist die ver-

gleichsweise einfache Visualisierung mit Hilfe von Referenzen, die Abhängigkeiten zu

anderen Elementen beschreiben.

Das Traceability-Modell wird so genannt, da es alle zur Etablierung einer Traceability benö-

tigten Modelle beinhaltet.

Durchgängige Nachverfolgbarkeit

3.5 EINORDNUNG DER DURCHGÄNGIGEN NACHVERFOLGBARKEIT IN DEN

STRATEGISCHEN UNTERNEHMENSKONTEXT

Im Kontext eines Unternehmens bedeutet die Etablierung der durchgängigen Nach-

verfolgbarkeit zahlreiche Veränderungen, die es einzuordnen gilt. Diese Einordnung

wird in diesem Kapitel in Anlehnung an [Winter 2003] sowie an das am Produktions-

technischen Zentrum Berlin (PTZ) vorliegende Verständnis des Unternehmenskontex-

tes beschrieben. Dabei sind die vier unterschiedlichen Sichten Strategie, Prozess, Me-

thode und Technologie zur Beschreibung des Unternehmens zu betrachten.

Auf Strategieebene wird dabei auf abstraktem Niveau festgelegt, was die Ziele des

Unternehmens sind [Winter 2003, S. 93]. So kann bspw. definiert werden, welches Pro-

dukt für welches Marktsegment zukünftig entwickelt und produziert werden soll. Aus

Sicht der IT-Strategie wäre in diesem Zusammenhang die Entscheidung für die Einfüh-

rung eines PDM-Systems oder der Wechsel eines CAD-Systems denkbar. Es wird somit

vorgegeben, WAS gemacht werden soll [Winter 2003, S. 93].

In diesem Kontext sind in Bezug auf die durchgängige Nachverfolgbarkeit insbeson-

dere drei abstrakte Unternehmensziele zu nennen, die verfolgt werden können:

- Normkonformität: Aus strategischer Sicht der Unternehmensführung ist es aus

Haftungsgründen essentiell, dass auf Normkonformität bei der Entwicklung

mechatronischer Systeme geachtet wird. In den Bereichen der funktionalen

Sicherheit wird bereits heute die Nachverfolgbarkeit der Umsetzung sicher-

heitsrelevanter Anforderungen verlangt (siehe auch Kapitel 2.1.3).

- Entwicklung des richtigen Produkts: Um das richtige Produkt zu entwickeln ist

die Berücksichtigung aller Kundenanforderungen notwendig. Diese kann mit-

tels durchgängiger Nachverfolgbarkeit nachgewiesen werden und darüber

hinaus auf Basis der Tracelinks bspw. Vollständigkeitsanalysen hinsichtlich der

Umsetzung von Anforderungen durchgeführt werden.

- Reduzierung später Änderungen: Späte Änderungen sind häufig teuer [Eigner

und Stelzer 2009, S. 16], da sie eine Überarbeitung bereits entwickelter und

evtl. abgesicherter Modelle, Systeme usw. notwendig machen. Mit Hilfe

durchgängiger Nachverfolgbarkeit können Inkonsistenzen zwischen Entwick-

lungsartefakten sofort bei Entstehung identifiziert und behoben werden. Ein

spätes Erkennen nicht anforderungsgerechten Systemverhaltens und damit

späte Änderungen werden somit vermieden.

Die nächste zu betrachtende Sicht ist die Prozessebene, in der die Prozesse zur Um-

setzung, der auf Strategieebene vorgegebenen Ziele, beschrieben werden. Es wird

somit vorgegeben, WIE etwas realisiert werden soll. Dabei werden drei unterschiedli-

che Arten von Prozessen unterschieden: Leistungsprozesse (auch Geschäftsprozes-

Durchgängige Nachverfolgbarkeit

se), in denen Leistungen erbracht werden, Unterstützungsprozesse, welche die Leis-

tungsprozesse unterstützen, sowie Führungsprozesse, mit deren Hilfe die ersten beiden

Arten von Prozessen koordiniert werden [Winter 2003, S. 94]. Auf dieser Ebene werden

für die Umsetzung der zuvor genannten strategischen Ziele, und damit der Einführung

durchgängiger Nachverfolgbarkeit, die Etablierung neuer und Änderungen beste-

hender, unterstützender Prozesse notwendig. Neu sind bspw. der Planungsprozess

durchgängiger Nachverfolgbarkeit, dessen Inhalte in Kapitel 3.4.4 beschrieben sind,

die Erfassung im Fall einer Offline-Erfassung (siehe Kapitel 3.4.1), mit dessen Hilfe die

Tracelinks nach Fertigstellung der Artefakte parallel zum eigentlichen Entwicklungs-

prozess modelliert werden, sowie der Pflegeprozess, mit dem die Qualität des

Tracelink-Modells gesichert wird (siehe Kapitel 3.4.3). Anpassungen sind vorrangig bei

solchen Leistungs- und Unterstützungsprozessen möglich, die durch die Verwendung

von Tracelinks unterstützt werden können. So können bspw. im Änderungsmanage-

ment die modellierten Tracelinks verwendet werden, um Entwicklern die Möglichkeit

zu geben, selber Auswirkungsanalysen durchzuführen und somit abschätzen zu kön-

nen, welche Folgen eine geplante Änderung potenziell hat [Fei et al. 2011]. Eine

langwierige Abschätzung durch mehrere Funktionsverantwortliche ist im ersten Schritt

nicht notwendig, sondern muss erst bei der Indikation einer erheblichen Auswirkung

auf detailliertem Niveau erfolgen.

Auch auf methodischer Ebene ergeben sich durch die Einführung durchgängiger

Nachverfolgbarkeit in einem Unternehmen sowohl Anpassungen an existierenden,

als auch die Einführung neuer Methoden. So können bereits etablierte Methoden,

wie bspw. die Fehlermöglichkeits- und -Einflussanalyse (FMEA) [Beier et al. 2011,

S. 464], welche zur Vermeidung von Fehlern verwendet wird, oder das House of Qua-

lity (HoQ) [Beier et al. 2013, S. 25], mit dem Kundenwünsche den Eigenschaften eines

Systems gegenübergestellt werden, durch die Verwendung von Tracelinks teilauto-

matisiert durchgeführt werden. Für die neu eingeführten Erfassungs- und Pflegepro-

zesse sind neue Methoden bereitzustellen, welche die Entwickler bei der Erfassung

von Abhängigkeiten unterstützen. Einen Überblick über diese neu einzuführenden

Methoden bieten die Kapitel 3.4.1, 3.4.3, 5.1 sowie 6.1.

Um diese Methoden optimal anwenden zu können, sind auf technologischer Ebene

Anpassungen an den IT-Systemen notwendig. Diese bestehen einerseits aus der Um-

setzung der Methoden mit Hilfe von Wizards, Algorithmen usw. und andererseits aus

der Bereitstellung von Schnittstellen, um die Elemente der in unterschiedlichen Werk-

zeugen verwalteten Artefakte mit Tracelinks verknüpfen zu können. Die tatsächliche

Realisierung ist dabei von der Planung durchgängiger Nachverfolgbarkeit abhängig

(siehe Kapitel 3.4.4, insbesondere das Kriterium „Akquisition der Artefakte“).

Durchgängige Nachverfolgbarkeit

Die Einführung durchgängiger Nachverfolgbarkeit hat somit weitreichende Ände-

rungen auf allen Ebenen des Unternehmens zur Folge. Sind diese jedoch durchge-

führt und, insbesondere im Bereich der Erfassung von Tracelinks, Methoden zur Unter-

stützung der Entwickler etabliert, lässt sich umfangreicher Nutzen aus den modellier-

ten Tracelinks gewinnen. Neben den eingangs erwähnten strategischen Zielen erge-

ben sich auch Vorteile für Entwickler, die sich im Tagesgeschäft in Form von höherer

Effizienz oder Entscheidungssicherheit ausprägen.

3.6 SOFTWARE ZUR ERFASSUNG, PFLEGE UND VERWENDUNG VON TRACELINKS

Im Umfeld des Systems Engineerings gibt es zahlreiche Software-Werkzeuge, die Me-

thoden zur Erfassung, Pflege und Verwendung von Tracelinks informationstechnisch

unterstützen. Dabei unterscheiden sich die Ausprägungen der unterschiedlichen An-

sätze deutlich. Sie lassen sich, anhand ihrer Herkunft und ihres Zwecks, in vier Katego-

rien einteilen: Anforderungsmanagement-Software, PLM-Software, Software zur Ana-

lyse von Systemstrukturen sowie spezialisierte Traceability-Werkzeuge, in denen

Traceability zu Integrationszwecken genutzt wird.

In den folgenden Kapiteln werden ausgewählte Werkzeuge, anhand der zuvor ge-

nannten Kategorien strukturiert, kurz vorgestellt und jeweils zum Abschluss mit Hilfe

der Kriterien aus den Kapiteln 3.3 und 3.4 in Tabellenform charakterisiert.

3.6.1 ANFORDERUNGSMANAGEMENT-SOFTWARE

Anforderungsmanagement-Software bietet in erster Linie Funktionalitäten zur Erfas-

sung und Verwaltung von Anforderungen. Um in diesem Zusammenhang eine Nach-

verfolgbarkeit zwischen Anforderungsspezifikationen unterschiedlicher Detaillie-

rungstiefe herstellen zu können, werden vielfach auch Funktionalitäten zur Modellie-

rung von Tracelinks und Durchführung von einfachen Änderungsauswirkungsanaly-

sen bereitgestellt. Im Folgenden werden exemplarisch die beiden Werkzeuge

DOORS (siehe Kapitel 3.6.1.1) und Reqtify (siehe Kapitel 3.6.1.2) vorgestellt.

3.6.1.1 RATIONAL DOORS

Rational DOORS (Dynamic Object Oriented Requirements System) ist eine Anforde-

rungsmanagement-Software von IBM. Sie basiert auf einer Client-Server-Architektur

und ist für die gleichzeitige Verwendung durch mehrere Nutzer ausgelegt [Plette

2009, S. 3; Abma 2009, S. 57]. Die graphische Benutzungsschnittstelle orientiert sich an

Textverarbeitungsprogrammen, so dass keine Datenbankkenntnisse für die Anwen-

dung notwendig sind [IBM Corporation 2008; Plette 2009, S. 6]. Durch die Konfigurati-

Durchgängige Nachverfolgbarkeit

on von Sichten können die Informationsumfänge an die Bedarfe unterschiedlicher

Rollen angepasst werden [Plette 2009, S. 10].

Die Strukturierung der Datenbank erfolgt in sog. Projekten, in denen wiederum soge-

nannte Formal Modules gespeichert werden [Plette 2009, S. 4]. Diese Module ent-

sprechen unterschiedlichen Spezifikationen innerhalb eines Projekts. Sie sind hierar-

chisch strukturiert und einzelne Informationen wie Anforderungen, Überschriften, Bil-

der usw. werden innerhalb dieser Module als Objekte gespeichert. Ihnen werden

eindeutige Identifikationsnummern (UID) und optional eine beliebig definierbare An-

zahl an Attributen zugewiesen [IBM Corporation 2008; Abma 2009, S. 60]. Dadurch

lassen sie sich eindeutig identifizieren, einzeln versionieren [Plette 2009, S. 16] und um-

fassend beschreiben. Abhängigkeiten zwischen diesen Objekten werden mit gerich-

teten Tracelinks ausgedrückt [IBM Corporation 2008]. Sie werden im Link Module ge-

speichert und können beliebige Attribute zugewiesen bekommen. Die Darstellung

der Tracelinks erfolgt mithilfe von Pfeildarstellungen für ein- und ausgehende

Tracelinks im Textmodus (siehe Abbildung 15), blauen Quadern im Matrixmodus und

Linien im Grafikmodus.

Abbildung 15: Darstellungsform von Tracelinks in DOORS im Textmodus

Das Anlegen von Tracelinks kann manuell oder semi-automatisch durchgeführt wer-

den [Abma 2009, S. 61-62]:

- Manuell per Drag & Drop im Textmodus [IBM Corporation 2008] oder durch

Auswählen der entsprechenden Zelle im Matrixmodus.

Durchgängige Nachverfolgbarkeit

- Semi-Manuell, indem ein Attribut definiert wird, in dem die UIDs der zu verlin-

kenden Objekte eingetragen werden. Die Funktion „Link by attribute“ durch-

sucht dieses Attribut nach den UIDs und erstellt die entsprechenden Links im

Link Module.

Die erfassten Tracelinks können genutzt werden, um bspw. Auswirkungsanalysen

durchzuführen [IBM Corporation 2008]. Zu diesem Zweck werden Filter definiert, die

alle ein- und ausgehenden Tracelinks zusammenfassen aus Sicht des jeweiligen Ob-

jekts. Darüber hinaus werden bei der Änderung eines Objekts grundsätzlich alle seine

Links auf den Status „Suspect“ gesetzt, um Nutzer nach dem Push-Prinzip über die

Änderungen zu informieren [IBM Corporation 2008; Abma 2009, S. 67].

In der folgenden Tabelle 1 sind die Eigenschaften von DOORS bzgl. der Etablierung

einer durchgängigen Nachverfolgbarkeit zusammengefasst.

Akquisition der Artefakte

nicht-integrativ

Manipulierbarkeit der Artefakte

Duplikation der Artefakte

original Daten

Traceability Schema

nein

Granularität

Elementebene

Arten von Datenstrukturen

Listen, Hierarchien

Modellierungsunterstützung

Regeln

Art der Traceability

qualitativ

Handhabung von Änderungen

Benachrichtigung

Zweck

Analyse, Dokumentation

Darstellung der Tracelinks

Matrix, Graph, Referenz

Prozessphasen-Kontext

phasenintern

Artefakt-Kontext

artefaktintern, artefaktübergreifend

Semantik

nicht typisiert

Speicherort der Tracelinks

zentral

Tabelle 1: Traceability-Eigenschaften von DOORS (eine Erläuterung der Kategorien sowie

Eigenschaften ist in den Kapiteln 3.3 und 3.4 zu finden)

3.6.1.2 REQTIFY

Reqtify ist eine Software von Dassault Systèmes, mit deren Hilfe Nachverfolgbarkeit

von Anforderungen bis zum Design gewährleistet und Tracelinks visualisiert und ana-

lysiert werden können. Zu diesem Zweck werden Daten wie bspw. Spezifikationen

oder Modelle aus unterschiedlichen Quellen akquiriert und über unterschiedliche

Schnittstellen in Reqtify zur Verfügung gestellt [Geensoft 2010]. Unterstützte

Werkzeuge sind bspw. Rational DOORS, RequisitePro, Borland CaliberRM, 3SL Cradle,

Durchgängige Nachverfolgbarkeit

Microsoft Word, Microsoft Excel, Adobe PDF, ARTiSAN Studio, Enterprise Architect und

Simulink [Geensoft 2010].

Reqtify selbst verfügt über eine Projektdatei bzw. -datenbank, in der alle importieren

Dateien referenziert und projektspezifische Daten gespeichert werden. Der grundle-

gende Unterschied von Reqtify im Vergleich zu den anderen vorgestellten Werkzeu-

gen ist, dass die Tracelinks nicht in Reqtify erstellt oder gespeichert werden [Pohl und

Scheel 2004, S. 9]. Diese werden, als Referenzen in den originalen Dokumenten, mit

Hilfe sog. Tagger gesetzt und von Reqtify lediglich ausgelesen und interpretiert.

Um die importierten Dokumente zueinander in Kontext zu setzen, werden die Ab-

hängigkeiten der Dokumente zu Beginn eines Projekts im Konfigurationseditor model-

liert und somit ein Traceability-Schema aufgebaut. Dieses beschreibt bspw., dass die

funktionalen Anforderungen einer Spezifikation durch ein Simulink-Modell erfüllt wer-

den sollen [Pohl und Scheel 2004, S. 11].

Für die Analyse stehen drei unterschiedliche Modi zur Verfügung. Im Coverage-

Modus wird basierend auf dem im Konfigurationseditor definierten Traceability-

Schema überprüft, ob die zugehörigen Elemente der Dokumente bereits über

Tracelinks verfügen und somit laut Definition von Reqtify adressiert sind. Der Auswir-

kungsanalyse-Modus ermöglicht ausgehend von einem ausgewählten Element die

Abschätzung von Auswirkungen durch Darstellung der verknüpften Elemente. Der

grafische Modus steigert das allgemeine Verständnis über die Abhängigkeiten durch

die gleichzeitige Darstellung ausgewählter Elemente und deren Tracelinks als Linien

[Pohl und Scheel 2004, S. 13-16].

Darüber hinaus verfügt Reqtify über eine Funktion für die Erstellung von frei definier-

baren Reports, die für die Zertifizierung eines entwickelten Systems (siehe Kapitel 3.2)

notwendig sind. So lassen sich bspw. Traceability-Matrizen, als Übersicht miteinander

in Beziehung stehender Anforderungen, oder Coverage Reports, denen die Erfüllung

der Anforderungen entnommen werden kann, erzeugen [Pohl und Scheel 2004,

S. 22-23].

In der folgenden Tabelle 2 sind die Eigenschaften von Reqtify bzgl. der Etablierung

einer durchgängigen Nachverfolgbarkeit zusammengefasst.

Akquisition der Artefakte

integrativ

Manipulierbarkeit der Artefakte

nein

Duplikation der Artefakte

original Daten

Traceability Schema

Granularität

Elementebene

Arten von Datenstrukturen

Listen, Hierarchien

Durchgängige Nachverfolgbarkeit

Modellierungsunterstützung

keine

Art der Traceability

qualitativ

Handhabung von Änderungen

Benachrichtigung

Zweck

Analysen, Dokumentation, Fortschrittskontrolle

Darstellung der Tracelinks

Matrix, Graph, Referenz

Prozessphasen-Kontext

phasenintern, phasenübergreifend

Artefakt-Kontext

artefaktübergreifend

Semantik

typisiert

Speicherort der Tracelinks

verteilt

Tabelle 2: Traceability-Eigenschaften von Reqtify (eine Erläuterung der Kategorien sowie

Eigenschaften ist in den Kapiteln 3.3 und 3.4 zu finden)

3.6.2 PLM-SYSTEME

PLM-Systeme stellen eine Weiterentwicklung von PDM-Systemen um das Lifecycle-

und das Anforderungsmanagement dar [Eigner und Stelzer 2009, S. 38]. Sie dienen

damit nicht nur der Verwaltung reiner Produktdaten sondern darüber hinaus anderer

Artefakte wie bspw. Anforderungsspezifikationen. Im Folgenden werden die PLM Sys-

teme V6 von Dassault Systèmes (siehe Kapitel 3.6.2.1) sowie Teamcenter von Siemens

PLM Software (siehe Kapitel 3.6.2.2) näher beschrieben und hinsichtlich ihrer Funktio-

nalitäten zur Herstellung einer durchgängigen Nachverfolgbarkeit analysiert.

3.6.2.1 V6-SUITE (R2011X)

Bei der V6-Suite von Dassault Systèmes handelt es sich um eine Systemlandschaft, die

auf der RFLP-Methodik basiert. Diese Methodik wurde laut Bornat und Msadek in An-

lehnung an Systems Engineering Vorgehensmodelle (siehe Kapitel 2.1.2) bzw. die VDI

2206 (siehe Kapitel 2.1.1) entwickelt [Bornat und Msadek 2011] und erhielt ihren Na-

men durch die Zusammensetzung der Anfangsbuchstaben der vier relevantesten

Prozessschritte (bzw. Artefakte), die während der Entwicklung durchlaufen werden: R

(Requirements), F (Functional), L (Logical), P (Physical Design). Dabei werden die An-

forderungshierarchien in ENOVIA verwaltet und können darüber hinaus in CATIA vi-

sualisiert werden. Die Modellierung von Funktionsstrukturen, Verhaltensmodellen so-

wie die Detailentwicklung (zumindest im Fall der mechanischen Konstruktion) erfol-

gen in CATIA [Dassault Systèmes 2013].

Diese Artefakte bauen aufeinander auf, und Abhängigkeiten zwischen ihnen können

mithilfe von typisierbaren Tracelinks explizit dokumentiert werden. So können bspw.

Anforderungen und Funktionen mit „Implement Relations“ miteinander verknüpft

Durchgängige Nachverfolgbarkeit

werden, um auszudrücken durch welche Funktion eine Anforderung realisiert wird

[Pfeifer et al. 2012]. Die Erstellung der Tracelinks erfolgt per Drag-and-Drop.

Eine Zusammenstellung dieser artefaktübergreifenden Tracelinks kann als sog. Trace-

ability-Report ausgegeben werden. Dabei werden für wählbare Artefakt-Paarungen

(im vorangegangenen Beispiel wären dies Anforderungs- und Funktionsartefakt) alle

modellierten Tracelinks in Listenform ausgegeben.

In der folgenden Tabelle 3 sind die Eigenschaften der V6-Suite bzgl. der Etablierung

einer durchgängigen Nachverfolgbarkeit zusammengefasst.

Akquisition der Artefakte

integrativ

Manipulierbarkeit der Artefakte

Duplikation der Artefakte

original Daten

Traceability Schema

Granularität

Elementebene

Arten von Datenstrukturen

Listen, Hierarchien, netzartige Strukturen

Modellierungsunterstützung

keine

Art der Traceability

qualitativ

Handhabung von Änderungen

Benachrichtigung

Zweck

Verifikation, Analyse, Synthese, Dokumentation, Fort-

schrittskontrolle, Synchronisation

Darstellung der Tracelinks

Referenz

Prozessphasen-Kontext

phasenintern, phasenübergreifend

Artefakt-Kontext

artefaktintern, artefaktübergreifend

Semantik

Typisiert und nicht-typisiert

Speicherort der Tracelinks

zentral

Tabelle 3: Traceability-Eigenschaften der V6-Suite (eine Erläuterung der Kategorien so-

wie Eigenschaften ist in den Kapiteln 3.3 und 3.4 zu finden)

3.6.2.2 TEAMCENTER

Teamcenter von Siemens PLM Software verfügt ebenfalls über Funktionen zur Ver-

knüpfung von Objekten, die im PLM -System verwaltet werden. Dabei ist insbesonde-

re das Modul „Systems Engineering and Requirements Management“ zu erwähnen,

mit dem Tracelinks zwischen Anforderungen, funktionalen Strukturen, Verhaltensmo-

dellen und Produktstrukturen modelliert werden können (siehe Abbildung 16). Dar-

über hinaus ist es möglich auch andere Artefakte, die in externer Software modelliert

werden, nachzuverfolgen. Über Schnittstellen können diese Artefakte auf Element-

ebene in Teamcenter integriert und mit Tracelinks verknüpft werden.

Durchgängige Nachverfolgbarkeit

Zur Erstellung eines gerichteten Tracelinks wird zunächst das Ausgangselement an-

gewählt und über eine Menüauswahl das Endelement identifiziert. Die Tracelinks

können typisiert bis auf Parameterlevel angelegt und zentral in Teamcenter gespei-

chert werden [Königs 2012, S. 46-47].

Mit Hilfe der Traceability-View können die Tracelinks elementbasiert ausgewertet

werden. Dabei wird ein Element (z. B. eine Anforderung) ausgewählt und für diese im

sog. Complying-object-pane alle verknüpften Elemente ausgegeben. Alternativ ist es

möglich, eine Traceability-Matrix für die Visualisierung der Abhängigkeiten zwischen

Anforderungen zu verwenden.

Abbildung 16: Theoretisches Traceability-Schema in Teamcenter [Siemens PLM Software

2011]

Ähnlich der RFLP-Methodik bietet Siemens PLM Software zudem den „Mechatronics

Concept Designer“ als integrierten Ansatz zur Systementwicklung an. Dieser setzt auf

Teamcenter und der CAD Software NX auf und bietet Funktionalitäten zur Verwal-

tung und Verknüpfung von textuellen Anforderungen, Funktionsstrukturen, physikba-

sierten Verhaltensmodellen und 3D-Geometrien [Siemens PLM Software 2010].

In der folgenden Tabelle 4 sind die Eigenschaften von Teamcenter bzgl. der Etablie-

rung einer durchgängigen Nachverfolgbarkeit zusammengefasst.

Akquisition der Artefakte

integrativ

Manipulierbarkeit der Artefakte

Duplikation der Artefakte

original Daten

Traceability Schema

nein

Granularität

Parameterebene

Arten von Datenstrukturen

Listen, Hierarchien, netzartige Strukturen

Modellierungsunterstützung

keine

Art der Traceability

qualitativ

Durchgängige Nachverfolgbarkeit

Handhabung von Änderungen

Benachrichtigung, Änderungs-Übertragung

Zweck

Verifikation, Analysen, Synthese, Dokumentation, Fort-

schrittskontrolle, Synchronisation

Darstellung der Tracelinks

Referenz

Prozessphasen-Kontext

phasenintern, phasenübergreifend

Artefakt-Kontext

artefaktintern, artefaktübergreifend

Semantik

nicht-typisiert

Speicherort der Tracelinks

zentral

Tabelle 4: Traceability-Eigenschaften von Teamcenter (eine Erläuterung der Kategorien

sowie Eigenschaften ist in den Kapiteln 3.3 und 3.4 zu finden)

3.6.3 ANALYSE-SOFTWARE

Die im Folgenden vorgestellte Analyse-Software basiert auf der Definition und Analy-

se von Tracelinks. Sowohl in METUS (siehe Kapitel 3.6.3.1) als auch in LOOMEO (siehe

Kapitel 3.6.3.2) werden die Abhängigkeiten innerhalb von Systemen und zwischen

deren beschreibenden Artefakten zu dem Zweck abgebildet, unterschiedliche Ana-

lysen durchführen zu können. Auf diese Analysen wird folgend näher eingegangen.

3.6.3.1 METUS

METUS ist eine Analyse-Software, die von ID-Consult gemeinsam mit der Daimler AG

entwickelt wurde. Sie unterstützt alle Schritte einer zugehörigen Entwicklungsmetho-

dik (System Design Method), deren Ziel die Unterstützung der Entwicklung modularer

Produktarchitekturen ist (siehe Abbildung 17)

[ID-Systems GmbH 2013].

Erster Schritt dieser Methode ist die Identifikation relevanter Anforderungen und de-

ren Erfassung in METUS. Zu diesem Zweck können auch bestehende Anforderungslis-

ten über XML oder aus Microsoft Excel importiert werden. Anschließend werden not-

wendige Gesamtfunktionen aus den Anforderungen abgeleitet und in ihre Teilfunkti-

onen heruntergebrochen. Durch die Verknüpfung der Funktionen mit den Anforde-

rungen per Drag-and-Drop wird die Traceability zwischen den Artefakten hergestellt.

Den heruntergebrochenen Funktionen werden im nächsten Schritt Bauteile zugeord-

net, welche wiederum zu Baugruppen oder Modulen gruppiert werden können. Wie

bei den Anforderungen ist es auch bei den Bauteilen möglich, auf bestehende

Stücklisten in SAP oder Excel zuzugreifen. Zusätzlich ermöglicht die Integration mit

Teamcenter (Siemens PLM) den direkten Zugriff auf die dort verwalteten Produktda-

ten [Tretow et al. 2008].

Im Folgenden wird nur auf die unter den Gesichtspunkten der Traceability relevanten

Schritte dieser Methodik eingegangen.

Durchgängige Nachverfolgbarkeit

Abbildung 17: Die METUS-Methode für das Systemdesign [ID-Systems GmbH 2013]

Allen in METUS verwalteten Elementen können beliebige Attribute zugewiesen wer-

den. So können bspw. die Herstellungs- oder Bezugskosten der unterschiedlichen

Bauteile als Attribute verwaltet werden. Über die Gewichtung der Tracelinks zwischen

diesen Bauteilen und deren Funktionen kann dann erfasst werden, wie die Bauteile

zur Realisierung der Funktionen beitragen

. Ziel dieser prozentualen Gewichtung ist

es, die Kosten einzelner Funktionen zu ermitteln und somit teure Einzelfunktionen bzw.

evtl. Optimierungspotenziale identifizieren zu können.

Zusätzlich sieht die Methodik die Optimierung der Produkte hinsichtlich ihrer Modulari-

sierung vor. In diesem Zusammenhang kommen unterschiedliche Analyseverfahren

zum Einsatz. U. a. können die Tracelinks zwischen Funktionen und Bauteilen genutzt

werden, um die Modularisierung so zu wählen, dass Funktionen immer nur von einem

Modul erfüllt werden [Tretow et al. 2008].

In der folgenden Tabelle 5 sind die Eigenschaften von METUS bzgl. der Etablierung ei-

ner durchgängigen Nachverfolgbarkeit zusammengefasst.

Akquisition der Artefakte

nicht-integrativ

Manipulierbarkeit der Artefakte

Nein

Duplikation der Artefakte

kopierte Daten

Die Traceability, die durch diese gewichteten Tracelinks etabliert wird ist somit quantitativ

(vgl. Kapitel 3.3).

Durchgängige Nachverfolgbarkeit

Traceability Schema

Granularität

Elementebene

Arten von Datenstrukturen

Listen, Hierarchien

Modellierungsunterstützung

keine

Art der Traceability

quantitativ

Handhabung von Änderungen

keine

Zweck

Analysen

Darstellung der Tracelinks

Matrix, Graph

Prozessphasen-Kontext

phasen-übergreifend

Artefakt-Kontext

artefaktübergreifend

Semantik

nicht-typisiert

Speicherort der Tracelinks

zentral

Tabelle 5: Traceability-Eigenschaften von METUS (eine Erläuterung der Kategorien sowie

Eigenschaften ist in den Kapiteln 3.3 und 3.4 zu finden)

3.6.3.2 LOOMEO

Bei LOOMEO der Teseon GmbH handelt es sich um ein Software-Werkzeug zur Analy-

se von Systemstrukturen. Zu diesem Zweck bilden unterschiedliche Matrizen die Kern-

elemente dieser Software (siehe Abbildung 18).

Abbildung 18: Matizen als Kernelement der Software LOOMEO [Teseon GmbH 2012]

In diesen Matrizen werden die Abhängigkeiten in einem oder zwischen mehreren Ar-

tefakten quantitativ oder qualitativ dokumentiert. Zusätzlich können diese Zusam-

Durchgängige Nachverfolgbarkeit

menhänge auch mit Graphen dargestellt werden. Diese sind selbstordnend realisiert

und erleichtern so bspw. das Erkennen von zusammengehörigen Bauteilen, ähnli-

chen Varianten oder sich gegenseitig beeinflussenden Organisationseinheiten [Tese-

on GmbH 2012].

Auf dieser Datenbasis bietet LOOMEO, unter Verwendung graphentheoretischer An-

sätze, unterschiedliche Analysemöglichkeiten zur Optimierung von Systemstrukturen.

So können bspw. aus direkten Abhängigkeiten in den DMMs indirekte Abhängigkei-

ten in den DSMs abgeleitet oder, durch die Neusortierung der Zeilen und Spalten der

Matrizen, stark vernetzte Bereiche in Systemen identifiziert werden, die sich potenziell

zur Modularisierung eignen. Die Definition dieser sog. “Filter” erfolgt dabei über die

Kombination vorgefertigter Analysebausteine [Teseon GmbH, 2012].

Um auf existierenden Daten aufbauen bzw. die Analyseergebnisse weiterverwenden

zu können, stehen ein Import für Excel- und Text-Dateien sowie Exports in die Formate

*.png, *.txt und *.svg zur Verfügung.

In der folgenden Tabelle 6 sind die Eigenschaften von LOOMEO bzgl. der Etablierung

einer durchgängigen Nachverfolgbarkeit zusammengefasst.

Akquisition der Artefakte

nicht-integrativ

Manipulierbarkeit der Artefakte

nein

Duplikation der Artefakte

kopierte Daten

Traceability Schema

nein

Granularität

Elementebene

Arten von Datenstrukturen

Listen, Hierarchien

Modellierungsunterstützung

keine

Art der Traceability

qualitativ, quantitativ

Handhabung von Änderungen

Benachrichtigung

Zweck

Analysen, Dokumentation

Darstellung der Tracelinks

Matrix, Graph

Prozessphasen-Kontext

phasenintern, phasenübergreifend

Artefakt-Kontext

artefaktintern, artefaktübergreifend

Semantik

nicht-typisiert

Speicherort der Tracelinks

zentral

Tabelle 6: Traceability-Eigenschaften von LOOMEO (eine Erläuterung der Kategorien so-

wie Eigenschaften ist in den Kapiteln 3.3 und 3.4 zu finden)

Durchgängige Nachverfolgbarkeit

3.6.4 INTEGRATIONSSOFTWARE

Integrationssoftware verfolgt das Ziel, Artefakte unterschiedlicher Autorenwerkzeuge

zu integrieren, um so die Abhängigkeiten explizit abbilden zu können. Dies wird bei

ToolNet (siehe Kapitel 3.6.4.1) und dem ModelTracer (siehe Kapitel 3.6.4.3) umge-

setzt. Auch bei ConWeaver (siehe Kapitel 3.6.4.2) handelt es sich um eine Integrati-

onssoftware, die Inhalte aus unterschiedlichen Datenquellen akquiriert. Allerdings ist

hier die Zielstellung nicht die explizite Modellierung von Tracelinks, sondern die über-

greifende semantische Suche. Da die dafür verwendeten Mechanismen aus Sicht

der durchgängigen Nachverfolgbarkeit jedoch sehr interessant sind, wird auch diese

Software im Folgenden kurz vorgestellt und charakterisiert.

3.6.4.1 TOOLNET

Bei ToolNet handelt es sich um eine Integrationssoftware, die in einem Verbundpro-

jekt von DaimlerChrysler und EADS entwickelt wurde [Altheide et al. 2002, S. 53]. Das

Konzept von ToolNet sieht vor, im Entwicklungsprozess verwendete Autoren-

Werkzeuge über einen Backbone zu koppeln und somit eine Integration von Funktio-

nen und Daten zu realisieren [van Gorp et al. 2006; Rosenauer 2008, S. 97]. Dabei

agiert ToolNet als verknüpfendes Element für die Software-Werkzeuge, die mit Hilfe

von spezifischen Adaptern integriert werden. Mit Hilfe dieser Adapter ist es möglich,

Anfragen über den Backbone an andere Applikationen zu senden und Teile von de-

ren bzw. ToolNet-spezifische Services zu verwenden.

Ziel dieser Integration ist es, Funktionalitäten für die Etablierung einer durchgängigen

Nachverfolgbarkeit bereitzustellen. Elemente der Artefakte in den verschiedenen

angebundenen Werkzeugen können manuell mit sog. ToolNet-Relationen verknüpft

werden (siehe Abbildung 19). Zu diesem Zweck werden die beiden eindeutigen Ob-

jekt-IDs der zu verknüpfenden Elemente sowie Metadaten in dem ToolNet-Relation-

Repository gespeichert. Bei den erwähnten Metadaten handelt es sich bspw. um

den Autor, das Erstellungsdatum oder den Tracelink-Typ [Rosenauer 2008, S. 100].

Durch den Ansatz, die Elemente der verschiedenen Software-Werkzeuge nicht zu

kopieren sondern zu referenzieren, werden Inkonsistenzen vermieden. Darüber hinaus

gibt es die Möglichkeit sog. ChangeEvents für Tracelinks zu definieren. Änderungen

eines Elements werden dabei detektiert und das verknüpfte Element informiert. Wei-

ter ist es möglich, direkte Anpassungen der verknüpften Elemente durchzuführen, um

die Konsistenz zwischen den verknüpften Elementen wiederherzustellen [Rosenauer

2008, S. 105].

Durchgängige Nachverfolgbarkeit

Abbildung 19: Tracelinks in ToolNet (in Anlehnung an [Rosenauer 2008, S. 100])

Zum Verlinken der Elemente muss die eigentliche Arbeitsumgebung nicht verlassen

werden. So wird bspw. bei DOORS durch den ToolNet-Adapter das Kontextmenü um

einen Eintrag zur Generierung eines Tracelinks erweitert. Bei Selektion des Startele-

ments und Auswahl des Kontextmenüs in DOORS öffnet sich eine ToolNet-

Komponente, in der das Zielelement gewählt und der Tracelink bestätigt werden

kann [Rosenauer 2008, S. 105-107].

In der folgenden Tabelle 7 sind die Eigenschaften von ToolNet bzgl. der Etablierung

einer durchgängigen Nachverfolgbarkeit zusammengefasst.

Akquisition der Artefakte

integrativ

Manipulierbarkeit der Artefakte

nein

Duplikation der Artefakte

original Daten

Traceability Schema

nein

Granularität

Elementebene

Arten von Datenstrukturen

Listen, Hierarchien, netzartige Strukturen

Modellierungsunterstützung

keine

Art der Traceability

qualitativ

Handhabung von Änderungen

Benachrichtigung

Zweck

Analysen, Dokumentation, Synchronisation

Darstellung der Tracelinks

Prozessphasen-Kontext

phasenintern, phasenübergreifend

Artefakt-Kontext

artefaktübergreifend

Semantik

typisiert

Speicherort der Tracelinks

zentral

Tabelle 7: Traceability-Eigenschaften von ToolNet (eine Erläuterung der Kategorien sowie

Eigenschaften ist in den Kapiteln 3.3 und 3.4 zu finden)

Durchgängige Nachverfolgbarkeit

3.6.4.2 CONWEAVER

Bei ConWeaver handelt es sich nicht um eine Software zur Etablierung einer durch-

gängigen Nachverfolgbarkeit im eigentlichen Sinne, sondern um eine semantische

Suchmaschine (siehe Abbildung 20) [Fellner et al. 2008, S. 205]. Aus Sicht der Tracea-

bility ist sie trotzdem erwähnenswert, da die Kanten des semantischen Netzes, wel-

ches zwischen verschiedenen Unternehmensdaten aufgebaut wird, letztlich

Tracelinks zwischen Elementen unterschiedlicher Artefakte sind. Vor diesem Hinter-

grund sind insbesondere die Algorithmen zur teilautomatisierten Erstellung des se-

mantischen Netzes von Interesse und werden deshalb im Folgenden näher beleuch-

tet.

Abbildung 20: Darstellung der Suchergebnisse von ConWeaver (strukturiert nach Ergebnislis-

ten) [Abbildung mit freundlicher Genehmigung zur Publikation von der Con-

Weaver GmbH (www.conweaver.de) bereitgestellt]

Das Wissensnetz, welches durch ConWeaver aufgebaut wird, besteht aus drei

Schichten: Konzept-, Themen- und Wissensnetz. Das Konzeptnetz ist hierarchisch struk-

turiert und besteht aus sog. Konzepten. Diese Konzepte ermöglichen eine abstrakte

Ordnung von Themenbereichen, indem sie untereinander verknüpft werden. So wer-

den bspw. die Konzepte Krankheit und Symptom mit der Verknüpfung hatSymptom

verknüpft. Diesen Konzepten werden individuelle Ausprägungen (sog. Individuen)

zugeordnet. Das Individuum Grippe wird somit dem Konzept Krankheit zugewiesen.

Zusätzlich gibt es das Themennetz, in dem das Themenvokabular mit sprachlichen

und inhaltlichen Zusammenhängen enthalten ist [Dirsch-Weigand et al. 2006, S. 3-4].

Bei der Erstellung des Wissensnetzes muss zunächst das Konzeptnetz manuell erstellt

werden. Die individuellen Ausprägungen können hingegen aus existierenden Daten-

banken bezogen werden. Es muss lediglich einmalig ein Mapping hergestellt werden,

um die Individuen und ihre Attribute (z. B. Preise) korrekt zuordnen zu können. Das

Durchgängige Nachverfolgbarkeit

Themenvokabular wird hingegen vollautomatisch aus bestehenden Dokumenten

herausgefiltert. Bei dieser Indizierung von Texten kommen Analyseworkflows zum Ein-

satz, die anwendungsspezifisch konfiguriert werden können. Insgesamt existieren

über 200 verschiedene Analyseoperatoren, mit denen nicht nur nach Zeichenfolgen,

sondern auch nach der inhaltlichen Bedeutung von Wörtern gesucht werden kann.

Diese Analyseoperatoren stammen u. a. aus den Bereichen Textprocessing, Informa-

tionsextraktion, Klassifikation und Ähnlichkeit, automatische Übersetzung oder Nut-

zeranalyse [Dirsch-Weigand et al. 2006, S. 5-10; Fellner et al. 2008, S. 206]. Darin ent-

halten ist auch die sog. Stammformrückführung, wie sie auch in der Methode

TraceLegacy zum Einsatz kommt (siehe Kapitel 6.4).

Damit eignet sich ConWeaver sowohl für strukturierte, als auch für nicht strukturierte

Daten, die über eine XML-Schnittstelle aus vielen unterschiedlichen Datenquellen be-

zogen werden können [Fellner et al. 2008, S. 206].

In der folgenden Tabelle 8 sind die Eigenschaften von ConWeaver bzgl. der Etablie-

rung einer durchgängigen Nachverfolgbarkeit zusammengefasst.

Akquisition der Artefakte

integrativ

Manipulierbarkeit der Artefakte

nein

Duplikation der Artefakte

original Daten

Traceability Schema

trifft nicht zu

Granularität

Elementebene

Arten von Datenstrukturen

Listen, Hierarchien, Netzartige Strukturen

Modellierungsunterstützung

Regelbasiert, Informationsrückgewinnung

Art der Traceability

qualitativ

Handhabung von Änderungen

trifft nicht zu

Zweck

trifft nicht zu

Darstellung der Tracelinks

trifft nicht zu

Prozessphasen-Kontext

phasenintern, phasenübergreifend

Artefakt-Kontext

artefaktintern, artefaktübergreifend

Semantik

typisiert

Speicherort der Tracelinks

zentral

Tabelle 8: Traceability-Eigenschaften von ConWeaver (eine Erläuterung der Kategorien

sowie Eigenschaften ist in den Kapiteln 3.3 und 3.4 zu finden)

Durchgängige Nachverfolgbarkeit

3.6.4.3 MODELTRACER

Der ModelTracer (vormals ISyFMU) wurde in Kooperation des Fraunhofer IPK, der TU

Berlin und der InMediasP GmbH während des Verbundprojekts ISYPROM

entwickelt.

Dieses prototypische Traceability-Werkzeug dient als Plattform zur Evaluierung ver-

schiedener Methoden, darunter auch EcoTracing (siehe Kapitel 5.4), TraceEvaluation

(siehe Kapitel 6.3) und TraceLegacy (siehe Kapitel 6.4). Im Folgenden wird die grund-

sätzliche Funktionsweise des ModelTracers, die für das Verständnis der später vorge-

stellten Methoden notwendig ist, vorgestellt. Eine ausführliche Übersicht, insbesonde-

re über Details des Datenmodells und die Implementierung, ist in [Bornath 2011b] zu

finden.

Abbildung 21: Anlegen eines Tracelinks im ModelTracer

Die Artefakte, zwischen denen eine durchgängige Nachverfolgbarkeit hergestellt

werden soll, werden aus unterschiedlichen Autorenwerkzeugen geladen und im Mo-

delTracer visualisiert (siehe Abbildung 21, links). Der Import erfolgt dabei über das in

Entwicklung befindliche Mapping-Werkzeug ISyMAP, mit dessen Hilfe beliebige Me-

tamodelle auf das Modell des ModelTracers gemappt werden können. Darüber hin-

Das Projekt ISYPROM – Modellbasierte Prozess- und Systemgestaltung für die Innovations-

beschleunigung – wurde mit Mitteln des Bundesministeriums für Bildung und Forschung im

Rahmenkonzept „Forschung für die Produktion von morgen“ (Förderkennzeichen

02PC105x) gefördert und vom Projektträger Forschungszentrum Karlsruhe (PTKA), Bereich

Produktion und Fertigungstechnologien (PFT), betreut.

Durchgängige Nachverfolgbarkeit

aus existiert eine direkte Schnittstelle, um XML-Dateien im ReqIF-Format importieren zu

können. Als Datenstrukturen sind Listen, Hierarchien und Netze verarbeitbar.

Beim Import werden die eindeutigen IDs der verschiedenen Autorenwerkzeuge ge-

nutzt, um eine Referenz in der MySQL-Datenbank des ModelTracers anzulegen. Somit

bleibt die Verknüpfung zu den originalen Elementen erhalten, weshalb bspw. deren

Änderung identifiziert, visualisiert und synchronisiert werden kann.

Das Werkzeug ModelTracer wurde in der Entwicklungsumgebung Eclipse mit der Pro-

grammiersprache Java implementiert. Das Datenmodell des ModelTracers ist in Ab-

bildung 22 dargestellt. Ein Produkt besteht aus mehreren Artefakten, die es beschrei-

ben. Diese wiederum werden aus Elementen aufgebaut, die in Hierarchien struktu-

riert sein können. Die Elemente der unterschiedlichen Artefakte können durch sog.

Relation (die Tracelinks entsprechen) miteinander verknüpft werden.

Abbildung 22: Datenmodell des ModelTracers

Das Anlegen eines Tracelinks erfolgt im ModelTracer per Drag-and-Drop des Aus-

gangselements auf das Endelement. Anschließend werden Details zu den zu ver-

knüpfenden Elementen im unteren Bereich des ModelTracers dargestellt (siehe Ab-

bildung 21).

Hier kann eine nähere Beschreibung des Tracelinks erfolgen und diesem ein Typ zu-

gewiesen werden. Die so erstellten Tracelinks werden, wie die Referenzen der Ele-

mente, in einer MySQL-Datenbank gespeichert. Die realisierbare Granularität liegt

dabei auf Elementebene. Parameter können nicht verknüpft werden.

Durchgängige Nachverfolgbarkeit

Die Visualisierung der Tracelinks kann mit dem Modul Ariadne’s Eye durchgeführt

werden. Dazu wird Ariadne’s Eye vom ModelTracer aus gestartet und greift auf die in

der Datenbank abgelegten Artefakte und deren Tracelinks zu, um eine übersichtli-

che Visualisierung des Systemzusammenhangs zu ermöglichen (siehe Abbildung 23).

Das Konzept des Visualisierers sieht vor, die Schnittstelle zwischen Entwickler und

Traceability-Modell bereitzustellen. Mit seiner Hilfe soll bspw. das Systemverständnis

gebildet oder Auswirkungsanalysen durchgeführt werden können. Dabei werden die

Artefakte in einem N-Eck angeordnet, um Überschneidungen zwischen Hierarchien

und Tracelinks zu vermeiden. Die Tracelinks werden in der Mitte dargestellt und bei

Auswahl hervorgehoben. Wird ein sichtbares Element selektiert, werden alle seine

Tracelinks farblich hervorgehoben, sodass bestehende Abhängigkeiten auf einen

Blick erfassbar sind.

Abbildung 23: Ariadne's Eye zur Visualisierung der Artefakte und Tracelinks

Momentan stellt die begrenzte Anzahl an unterstützten Datenformaten das größte

Hindernis für eine verbreitete Anwendung des Werkzeugs ModelTracer dar. Dieses

Durchgängige Nachverfolgbarkeit

Defizit soll durch ISyMAP behoben werden, jedoch befindet es sich momentan noch

in der Entwicklung. Im Fall der Weiterentwicklung des ModelTracers, über den Status

eines Prototypen zur Evaluation von Methoden hinaus, müssten weitere Schnittstellen

implementiert oder aber dessen Funktionalitäten bspw. auf ein existierendes PLM-

System wie Teamcenter aufgesetzt werden.

In der folgenden Tabelle 9 sind die Eigenschaften des ModelTracers bzgl. der Etablie-

rung einer durchgängigen Nachverfolgbarkeit zusammengefasst.

Akquisition der Artefakte

integrativ

Manipulierbarkeit der Artefakte

nein

Duplikation der Artefakte

original Daten

Traceability Schema

nein

Granularität

Artefaktebene, Elementebene

Arten von Datenstrukturen

Listen, Hierarchien, netzartige Strukturen

Modellierungsunterstützung

Regelbasiert, Informationsrückgewinnung, Assistent

Art der Traceability

qualitativ

Handhabung von Änderungen

Benachrichtigung

Zweck

Analysen, Dokumentation, Fortschrittskontrolle

Darstellung der Tracelinks

Graph

Prozessphasen-Kontext

phasenintern, phasenübergreifend

Artefakt-Kontext

artefaktintern, artefaktübergreifend

Semantik

typisiert und nicht-typisiert

Speicherort der Tracelinks

zentral

Tabelle 9: Traceability-Eigenschaften des ModelTracers (eine Erläuterung der Kategorien

sowie Eigenschaften ist in den Kapiteln 3.3 und 3.4 zu finden)

3.7 HERAUSFORDERUNGEN DER DURCHGÄNGIGEN NACHVERFOLGBARKEIT

Die Etablierung einer durchgängigen Nachverfolgbarkeit ist bei der Anwendung zur

Entwicklung technischer Systeme mit zahlreichen Herausforderungen verbunden, die

im Folgenden aufgezählt und erläutert werden

. Dazu werden sie zunächst in Kapitel

3.7.1 allgemeingültig beschrieben und kategorisiert. Anschließend werden sie in Kapi-

tel 3.7.2 erneut aufgegriffen und mit Bezug zur Entwicklung des mechatronischen

Außenspiegels dargestellt, um die Herausforderungen aus der Perspektive der an der

Entwicklung beteiligten Ingenieure aufzuzeigen.

Viele der genannten Herausforderungen sind nicht auf disziplin-übergreifende technische

Systeme beschränkt, sondern sind auch im Bereich der durchgängigen Nachverfolgbarkeit

von Software zu finden.

Durchgängige Nachverfolgbarkeit

3.7.1 ALLGEMEINE DARSTELLUNG DER HERAUSFORDERUNGEN

Die Herausforderungen der Traceability lassen sich grob in technologische, methodi-

sche, zwischenmenschliche sowie monetäre klassifizieren

. Im Bereich der technolo-

gischen Herausforderungen ist es insbesondere die informelle Notation, in der die Ar-

tefakte erstellt werden (vgl. Kapitel 2.2), die eine Vollautomatisierung der Erfassung

der Tracelinks so gut wie unmöglich macht [Ramesh und Jarke 2001, S. 39; Egyed

2003, S. 116; Zisman et al. 2003, S. 448; Winkler und Pilgrim 2010, S. 550]. Hinzu kommt,

dass die Artefakte in unterschiedlichen Modellierungssprachen verfasst [Tudorache

2006, S. 54] und von unterschiedlichen Personen erstellt werden, was dazu führt, dass

die Tracelink-Erfassung heute überwiegend manuell durchgeführt werden muss

[Ramesh und Jarke 2001, S. 39]. Des Weiteren ist insbesondere bei der Entwicklung

mechatronischer Systeme zu berücksichtigen, dass unterschiedliche Disziplinen an

der Entwicklung beteiligt sind, die ihre jeweiligen spezialisierten Autorenwerkzeuge

verwenden. Die daraus folgende zumeist sehr heterogene Toollandschaft ist häufig

nicht integriert, so dass die Erfassung der Tracelinks zwischen den Artefakten wiede-

rum erschwert wird [Winkler und Pilgrim 2010, S. 545-546].

Selbst wenn eine Integration erreicht wird, fehlen noch Methoden, die den Entwick-

lern den Umgang mit der Traceability erleichtern [Ramesh und Jarke 2001, S. 44; Mä-

der et al. 2009a, S. 1, 2009b, S. 5; Winkler und Pilgrim 2010, S. 556-557]. So sind die Ar-

tefakte meist sehr komplex, so dass es ohne methodische Unterstützung schwierig ist,

korrekte Tracelinks zu modellieren [Ramesh und Jarke 2001, S. 44; Egyed und Grün-

bacher 2002, S. 163], den signifikanten Aufwand

für die manuelle Modellierung zu

bewältigen [Wieringa 1995, S. 16; Hayes et al. 2006, S. 4; Egyed et al. 2009, S. 242] und

den Überblick zu behalten. Letzteres gilt insbesondere für die Online-Erfassung von

Tracelinks. Zwar ist diese Vorgehensweise intuitiv, da Tracelinks modelliert werden so-

bald Abhängigkeiten während der Erstellung der Artefakte auftreten, allerdings ist

die Beurteilung der Vollständigkeit einer solchen Analyse nicht möglich. Darüber hin-

aus ist das Bestimmen der richtigen Granularität für die Modellierung der Links eine

bislang unbeantwortete Herausforderung [Mäder et al. 2009b, S. 4]. Da früh im Ent-

wicklungsprozess häufig noch nicht klar ist, zu welchen Zwecken die Tracelinks später

genutzt werden, müssen Ingenieure prognostizieren, bis zu welcher Granularität die

Links später benötigt werden [Egyed und Grünbacher 2002, S. 163; Egyed et al. 2009,

S. 242]. Ist die Granularität zu hoch, steigen die Kosten sowohl für die Ermittlung als

auch für die Pflege des Tracelink-Modells [Winkler und Pilgrim 2010, S. 545-546]. Ist sie

Im Folgenden werden die Herausforderungen kursiv dargestellt.

Wenn m Anforderungen auf ihre Abhängigkeit zu n Systemelementen überprüft werden

sollen, gibt es m * y mögliche Tracelinks, die auf ihre Existenz überprüft werden müssen.

Durchgängige Nachverfolgbarkeit

hingegen zu gering, ergeben die Analysen, die auf deren Basis durchgeführt werden

sollen, keine hinreichend genaue Ergebnisse. Die Abschätzung ist auch deshalb

schwierig, da es viele verschiedene Anwender mit sich teilweise wiedersprechenden

Anforderungen an die Traceability gibt [Gotel und Finkelstein 1994, S. 96; Ramesh et

al. 1997, S. 398; Ramesh und Jarke 2001, S. 4]. So liegt es bspw. im Interesse eines Pro-

jektmanagers die Erfüllung von Anforderungen zu überprüfen und die Entwicklungs-

zeit für künftige Projekte zu minimieren. Ein Anforderungsmanager dokumentiert mit

Hilfe der Traceability die Entwicklung einer Anforderung sowie deren Verifikation und

der Entwickler nutzt sie für Auswirkungsanalysen und zur Überprüfung, ob das System

vollständig ist [Wieringa 1995, S. 4-5; Aizenbud-Reshef et al. 2006, S. 516]. Es gibt somit

keine Standardlösung, die sich auf jedes Entwicklungsprojekt anwenden lässt. Viel-

mehr muss in jedem Projekt eine angepasste Form der Nachverfolgbarkeit etabliert

werden.

Somit fehlen den Anwendern sowohl industriell nutzbare Methoden als auch Werk-

zeuge, die sie bei der aufwändigen Modellierung von Tracelinks unterstützen. Hinzu

kommen zwischenmenschliche Aspekte, die eine weite Verbreitung durchgängiger

Nachverfolgbarkeit behindern. Dabei ist vor allen Dingen problematisch, dass dieje-

nigen, die für die Modellierung der Tracelinks verantwortlich sind, selten auch die

Nutzer der Traceability in späteren Entwicklungsphasen sind [Gotel und Finkelstein

1994, S. 97; Ramesh et al. 1997, S. 398-399; Sutinen et al. 2000, S. 7]. Sie werden somit

verpflichtet, neben ihrer eigentlichen Entwicklungsarbeit umfassende Ressourcen für

eine Methode einzusetzen, die für sie selbst keinen Nutzen bringt [Wieringa 1995,

S. 16]. Dieses Ungleichgewicht zwischen Aufwand und Nutzen sowie der Eindruck,

dass Traceability nicht kosteneffizient ist, haben fehlende Motivation und eine gerin-

ge Qualität des Tracelink-Modells zur Folge [Gotel und Finkelstein 1994, S. 97-98;

Winkler und Pilgrim 2010, S. 545-546]. Es werden nur die absolut notwendigen Res-

sourcen sehr lokal und nicht systemübergreifend eingesetzt und damit Aspekte wie

die Pflege des Tracelink-Modells bei Änderungen der Artefakte vernachlässigt [Gotel

und Finkelstein 1994, S. 97-98; Winkler und Pilgrim 2010, S. 545]. Darüber hinaus ist der

Aspekt, dass die Entwickler durch die Modellierung der Tracelinks ihr Entwicklungswis-

sen dokumentieren und dadurch befürchten können, sich selbst überflüssig zu ma-

chen, nicht zu vernachlässigen [Sutinen et al. 2000, S. 7]. Dass die Traceability als

Langzeitprojekt gesehen werden muss und auf Dauer dem ganzen Unternehmen hilft

[Ramesh et al. 1997, S. 410], wird dabei ausgeblendet. Dezidierte Teams, die sich nur

um die Etablierung der Traceability kümmern, sind jedoch auch nicht empfehlens-

wert, da umfassendes Wissen über die Artefakte für die Modellierung der Tracelinks

notwendig ist. Arkley und Riddle konnten zeigen, dass die Anzahl falscher Tracelinks

in Projekten, in denen spezielle Traceability-Teams eingesetzt wurden, höher war als

Durchgängige Nachverfolgbarkeit

in solchen, in denen die Tracelinks von Software-Entwicklern modelliert wurden

[Arkley und Riddle 2005, S. 385-386].

Unabhängig davon, wer die Links modelliert, ist das Ergebnis immer subjektiv und

nicht fehlerfrei (Stichwort: fehlende Tracelinks bzw. falsche Tracelinks) [Gotel und Fin-

kelstein 1994, S. 98-99; Egyed und Grünbacher 2002, S. 163; Egyed et al. 2009, S. 256].

Aus Sicht der Nutzer der Traceability hat dies zur Folge, dass sie die Qualität des

Tracelink-Modells nicht einschätzen können und diesem nicht vertrauen [Gotel und

Finkelstein 1994, S. 97-98].

Dem stehen, wie bereits erwähnt, ein nicht unerheblicher Aufwand und damit hohe

Kosten gegenüber [Winkler und Pilgrim 2010, S. 539]. So investiert das Department of

Defense (DoD) der USA ca. 4 % ihrer Systementwicklungskosten in Traceability

[Ramesh et al. 1997, S. 398]. Ansätze, die die Etablierung effizienter und durch Auto-

matisierung oder Prozessunterstützung kostengünstiger machen sollen, befinden sich

noch im Forschungsstadium [Ramesh und Jarke 2001, S. 44; Winkler und Pilgrim 2010,

S. 545], und das Bewusstsein für die Vorteile der Traceability ist noch nicht ausrei-

chend ausgeprägt [Arkley und Riddle 2005, S. 385-386; Mäder et al. 2009a, S. 1;

Winkler und Pilgrim 2010, S. 545-546]. Zudem lässt sich das Return on Investment (ROI)

nicht einfach ermitteln [Palmer 2000], und ein empirischer Nachweis, für welchen

Anwender sich Traceability ab wann lohnt, ist nicht vorhanden [Winkler und Pilgrim

2010, S. 545-546]. Dadurch wird das Kosten/Nutzen-Verhältnis in der Industrie als sehr

schlecht angesehen. Aus diesem Grund wird Traceability momentan nur in einem

minimal geforderten Umfang zu Dokumentationszwecken praktiziert, wo es gesetzlich

vorgeschrieben ist [Arkley und Riddle 2005, S. 385; Mäder et al. 2008, S. 1].

3.7.2 DARSTELLUNG DER HERAUSFORDERUNGEN AM BEISPIEL DER ENTWICKLUNG DES

MECHATRONISCHEN AUßENSPIEGELS

Bei der Analyse des Vorgehens der Studenten während der Lehrveranstaltung „Virtu-

al Engineering in Industry“ fällt auf, dass zwei unterschiedliche Rollen an der Entwick-

lung des mechatronischen Außensiegels direkt bzw. indirekt beteiligt waren. Zum ei-

nen die Studenten selbst, die, abgesehen von wenigen Tätigkeiten im Bereich des

Projektmanagements, als Entwickler tätig waren und jeweils für unterschiedliche Ent-

wicklungsartefakte verantwortlich zeichneten. Und andererseits die Betreuer, die den

Part des Entwicklungsmanagers übernahmen, in diesem Zusammenhang Design Re-

views veranstalteten und die Entwicklung überwachten.

Durch diese personelle Aufteilung zeigten sich hinsichtlich der Etablierung einer

durchgängigen Nachverfolgbarkeit deutliche Parallelen zu realen in der Literatur do-

kumentierten Entwicklungsprojekten (siehe bspw. [Ramesh und Jarke 2001]), weshalb

Durchgängige Nachverfolgbarkeit

die zuvor vorgestellten Herausforderungen im Folgenden nochmals anhand der Ent-

wicklung des mechatronischen Außenspiegels aufgezeigt werden sollen.

Während der Lehrveranstaltung spielten die technologischen Herausforderungen nur

eine untergeordnete Rolle. Wie in Kapitel 2.1.5 beschrieben, wurde für die Entwick-

lung des mechatronischen Außenspiegels die integrierte Entwicklungsumgebung V6

von Dassault Systèmes verwendet, weshalb die Modellierung von Tracelinks zwischen

den verwendeten Artefakten grundsätzlich möglich war. Aus technologischer Sicht

zeigte sich darüber hinaus, dass eine automatisierte Erfassung der Tracelinks auf-

grund der informellen Notation insb. der Anforderungen sowie der Tatsache, dass

während des Projekts keine verbindlichen Regeln für die Benennung der Elemente

vereinbart wurden, nicht möglich gewesen wäre. Abgesehen davon bietet die V6-

Umgebung zum aktuellen Zeitpunkt keine Funktionalitäten zur Unterstützung des Mo-

dellierungsprozesses von Tracelinks, weshalb ohnehin eine manuelle Verknüpfung

durchgeführt wurde.

Auf zwischenmenschlicher Ebene wurde deutlich, dass die Verteilung der Aufgaben

und des Nutzens analog zur Beschreibung in Kapitel 3.7.1 war: Traceability wurde von

den Entwicklungsmanagern (Betreuern) vorgeschrieben, um den Entwicklungsfort-

schritt verfolgen und die Traceability-Funktionalitäten der V6-Entwicklungsumgebung

testen zu lassen. Die Entwickler (Studenten) hingegen mussten die Tracelinks zwischen

den unterschiedlichen Artefakten modellieren, ohne einen direkten wahrgenomme-

nen Nutzen davon zu haben. Theoretisch konnten die Tracelinks zwar genutzt wer-

den, um während der Entwicklung bspw. bei Änderungen Auswirkungsanalysen

durchzuführen. Praktisch wurde diese formale Vorgehensweise jedoch aufgrund feh-

lender Funktionalität in V6 und der vergleichsweise geringen Komplexität des Ent-

wicklungsgegenstandes nicht angewendet. Somit war der Nutzen der Entwickler auf

die Dokumentation für die Zertifizierung (Benotung) beschränkt. Die notwendigen

Aufwände für die als Last empfundene Modellierung der Tracelinks mussten von den

ohnehin knapp bemessenen Ressourcen im Rahmen des Projekts aufgebracht wer-

den und fehlten bei der eigentlichen Entwicklung. Dies hatte zur Folge, dass das

Thema Traceability vernachlässigt wurde und bspw. eine kontinuierliche Pflege des

Tracelink-Modells nicht stattfand. Lediglich die Tracelinks zwischen Verhaltensmodell

und Produktstruktur (sog. Ports) wurden umfassend betrachtet, da sie die Integration

von Verhalten und Geometrie herstellen, die für die Validierung gefordert worden

war und in Design Reviews vorgestellt werden musste.

Auch für die Entwicklungsmanager, die eigentlichen Nutznießer der Traceability, war

diese Vorgehensweise der Entwickler bei der Modellierung und Pflege von Tracelinks

problematisch. Da die Arbeiten am Traceability-Modell meilensteingetrieben waren

und zudem nur mit den absolut notwendigen Ressourcen betrieben wurden, konnte

Durchgängige Nachverfolgbarkeit

nicht zu jeder Zeit von der Aktualität des Traceability-Modells ausgegangen werden.

Zudem sind die Tracelinks von der subjektiven Einschätzung der modellierenden Ent-

wickler abhängig und selten fehlerfrei. Das bedeutet, dass zwischen abhängigen

Elementen Tracelinks fehlten oder Tracelinks zwischen Elementen modelliert waren,

bei denen keine Abhängigkeit bestand. Im Zusammenhang mit der zuvor genannten

Vernachlässigung des Themas Traceability durch die Entwickler bedeutet dies, dass

die Qualität des Traceability-Modells nicht eingeschätzt werden konnte und damit

die verlässliche Beurteilung des Projektfortschritts bspw. durch eine Abdeckungsana-

lyse der Anforderungen nicht möglich war.

Dabei ist zu berücksichtigen, dass die Entwickler keinerlei methodische Unterstützung

bei der Modellierung der Tracelinks erhielten. Lediglich eine Einführung in die Funktio-

nalitäten zur manuellen Tracelinkerstellung wurde zu Beginn des Projektes im Rahmen

einer Übung durchgeführt. Es wurde allerdings nicht weiter darauf eingegangen, zwi-

schen welchen Artefakten oder zu welchem Zeitpunkt Tracelinks modelliert werden

sollten. Auch wurde nicht die zu erreichende Granularität der Tracelinks diskutiert. Die

Entscheidung zwischen welchen Artefakten, zu welchem Zeitpunkt und in welcher

Granularität die durchgängige Nachverfolgbarkeit erreicht werden sollte, lag somit

bei den Entwicklern. Diese entschieden sich, die Artefakte jeweils nach der Fertigstel-

lung in Reihenfolge der Entstehung mit Tracelinks bis zur untersten Hierarchieebene zu

verknüpfen (Anforderungsartefakt – Funktionsartefakt – Verhaltensartefakt – Produkt-

struktur). Auch wenn die Artefakte im Vergleich zu industriellen Maßstäben weniger

komplex waren, so waren die dafür notwendigen Aufwände nicht zu unterschätzen:

insgesamt existierten artefaktübergreifend 101 Elemente und theoretisch mussten

1304 Entscheidungen über die Existenz einer Abhängigkeit zwischen den Elementen

getroffen werden. Diese Entscheidungen waren dabei nicht immer leicht zu treffen.

Während bspw. ein Tracelink zwischen der Anforderung, die die Realisierung einer

Außenspiegelheizung verlangt, und der Funktion „Außenspiegel beheizen“ ver-

gleichsweise einfach zu modellieren war, war die Entscheidung, welche der model-

lierten Funktionen an der Umsetzung der Anforderung „elektronische Verstellbarkeit

des Außenspiegels vorsehen“ beteiligt sind, weniger eindeutig. Gründe dafür liegen

bspw. darin, dass die Anforderung durch mehrere Funktionen realisiert wurde, oder

dass eine eher indirekte Beteiligung an der Realisierung vorlag. So hat bspw. die

Funktion „Rückwärtsfahrt erkennen“ auf den ersten Blick keine Abhängigkeit zur For-

derung nach einer elektronischen Verstellbarkeit des Außenspiegels. Wird jedoch be-

rücksichtigt, dass sich der Außenspiegel bei Rückwärtsfahrt automatisch verstellen

soll, besteht Anlass, einen Tracelink zwischen diesen beiden Elementen zu modellie-

ren. Solche Beispiele, ähnlich dem zuvor genannten, existieren zwischen allen Arte-

fakten und erschweren die Entscheidungsfindung bei der Modellierung von

Durchgängige Nachverfolgbarkeit

Tracelinks enorm, insbesondere wenn man, wie die Entwickler im beschriebenen Pro-

jekt, den späteren Verwendungszweck der Tracelinks nicht kennt.

Zusammenfassend kann somit gesagt werden, dass Entwickler einen nicht unerhebli-

chen Aufwand betreiben mussten, um Tracelinks zu modellieren. Dabei handelte es

sich um eine nicht-triviale Aufgabe, welche die umfassende Kenntnis der betrachte-

ten Artefakte erforderte und bei der teilweise Entscheidungen getroffen werden

mussten, deren Konsequenzen nicht abgesehen werden konnten. Hinzu kam, dass

die Entwickler nicht die Nutznießer der so etablierten, durchgängigen Nachverfolg-

barkeit waren. Jedoch galt auch für die Entwicklungsmanager, die im beschriebe-

nen Projekt die Nutzer darstellten, dass das Thema durchgängige Nachverfolgbarkeit

nicht unproblematisch war, da sie die Qualität des Tracelink-Modells nicht einschät-

zen konnten und eine uneingeschränkte Nutzung somit nicht möglich war.

3.8 ZUSAMMENFASSUNG UND DISKUSSION

In Kapitel 3 wurden die Grundlagen durchgängiger Nachverfolgbarkeit beschrieben.

Dafür wurde zunächst auf den Bedarf eingegangen, der sich durch die Verschie-

bung von der Entwicklung rein mechanischer Systeme hin zu mechatronischen Sys-

temen, die durch eine hohe Vernetzung geprägt sind, ergibt. Darüber hinaus stellt

jedoch auch deren Entwicklung, an der unterschiedliche Disziplinen beteiligt sind, ei-

ne Herausforderung dar, da die disziplinübergreifenden Abhängigkeiten meist nur

implizit bekannt und nicht allen Entwicklern bewusst sind [Aizenbud-Reshef et al.

2006, S. 515; Tudorache 2006, S. 3].

Im Anschluss wurde durchgängige Nachverfolgbarkeit als Lösungsansatz für die zuvor

beschriebenen Herausforderungen vorgestellt, sowie deren Ursprung und Verbrei-

tung näher betrachtet. Dabei wurde aufgezeigt, dass die Methode im Vergleich zur

Entwicklung technischer Systeme in der Software-Entwicklung, bereits verbreitet ist,

und auch zahlreiche positive Erfahrungen im Umgang mit Traceability gemacht wur-

den. Unabhängig vom Einsatzgebiet lassen sich dabei vier Phasen der Traceability

unterscheiden die näher charakterisiert wurden: Planung, Erfassung, Verwendung

und Pflege.

Bei der Anwendung dieser Methode zur Entwicklung technischer Systeme bestehen

Herausforderungen, die vier Kategorien zugeordnet werden können: technologische,

methodische, zwischenmenschliche und monetäre Herausforderungen. So stellen die

informelle Notation der Entwicklungsartefakte, ihre Mehrsprachigkeit sowie die hete-

rogene Toollandschaft, die durch spezialisierte Software geprägt ist, große techni-

sche Hürden bei der Etablierung einer durchgängigen Nachverfolgbarkeit dar. Dar-

über hinaus fehlen bislang die Berücksichtigung in den meisten Vorgehensmodelle

Durchgängige Nachverfolgbarkeit

(vgl. Kapitel 2.1), Methoden zum effizienten Umgang mit der Traceability und dem

Treffen der notwendigen Entscheidungen. Hinzu kommt, dass es keine Unterstützung

bei der Festlegung der „angemessenen“ Granularität für die Modellierung von

Tracelinks gibt, um ein Optimum zwischen Nutzen und Aufwand zu erreichen. Ferner

ist der Aspekt, dass diejenigen, die für die Modellierung der Tracelinks verantwortlich

zeichnen, selten auch die Nutzer der Nachverfolgbarkeit in späteren Entwicklungs-

phasen sind, eine große Herausforderung, welche zu mangelnder Qualität der

Tracelink-Modelle führen kann. Abschließend bleibt zu erwähnen, dass dem Nutzen

ein nicht unerheblicher Aufwand und damit hohe Kosten gegenübersteht.

Um diese Herausforderungen an den Belangen der an der Entwicklung beteiligten

Ingenieure zu spiegeln, wurde das Beispiel des mechatronischen Außenspiegels ana-

lysiert und festgestellt, dass Entwicklungsingenieure mit der Modellierung von

Tracelinks vor eine nicht-triviale, aufwändige Aufgabe gestellt werden, bei der

schwere Entscheidungen getroffen werden müssen. Dem gegenüber stehen ein als

gering wahrgenommener Nutzen und die Tatsache, dass die eigentlichen Nutznießer

der durchgängigen Nachverfolgbarkeit andere sind. Diese konnten am Beispiel der

Entwicklung des mechatronischen Außenspiegels als Entwicklungsmanager identifi-

ziert werden, für die der Umgang mit dem Tracelink-Modell jedoch auch nicht un-

problematisch ist, da sie die Qualität der Tracelinks nicht einschätzen können. Diese

Herausforderungen führen dazu, dass durchgängige Nachverfolgbarkeit heute zu-

meist nur dort praktiziert wird, wo es gesetzlich vorgeschrieben ist [Arkley und Riddle

2005, S. 385; Mäder et al. 2008, S. 1] und dann meist nur zu Dokumentationszwecken

und in einem Umfang, der minimal die Vorschriften erfüllt.

Trotzdem gibt es auch im Umfeld der Entwicklung mechatronischer Systeme bereits

Software-Tools zur Erfassung, Pflege und Verwendung von Tracelinks. Eine Auswahl

wurde in Kapitel 3.5 anhand der vier Kategorien Anforderungsmanagement-

Software, PLM-Software, Analyse-Software sowie Integrationssoftware vorgestellt und

ihre Eigenschaften hinsichtlich der durchgängigen Nachverfolgbarkeit mit Hilfe der in

den Kapiteln 3.3 und 3.4 beschriebenen Kategorien bewertet. In der folgenden Ta-

belle 10 sind diese Kategorien (linke graue Spalte), deren Ausprägungen (weiße Zel-

len) sowie die Bewertungen der einzelnen Software-Tools (mittels Kürzel) zusammen-

gefasst.

Bei der Betrachtung der verfügbaren Software-Tools zur Verwaltung von Tracelinks in

Tabelle 10 fällt auf, dass insbesondere im Bereich der Modellierungsunterstützung

wenige Lösungen für die Entwicklung mechatronischer Systeme verfügbar sind. Glei-

ches gilt für den Bereich der Pflege von Tracelink-Modellen, die von keinem der

Werkzeuge unterstützt wird.

Die durchgängige Nachverfolgbarkeit bietet somit große Potenziale, um für die ein-

Durchgängige Nachverfolgbarkeit

gangs erwähnten Herausforderungen bei der Entwicklung mechatronischer Systeme

eine Hilfestellung zu bieten. Allerdings leidet sie in diesem Kontext unter vielschichti-

gen Akzeptanzproblemen. Vordergründig ist dafür das schlechte Kosten/Nutzen-

Verhältnis des Ansatzes, welcher in den hohen Aufwänden und dem (gefühlt) gerin-

gen Nutzen begründet liegt, verantwortlich. Um dieses Verhältnis zu verbessern, er-

geben sich somit zwei Forschungsrichtungen: es gilt die Kosten zu reduzieren und den

Nutzen zu steigern. Die vorliegende Arbeit fokussiert dabei auf die erste Forschungs-

richtung, indem Methoden zur effizienten Modellierung von Tracelinks sowie deren

Pflege konzipiert und evaluiert werden. Die konkreten Forschungsfragen, die dabei

beantwortet werden sowie die Hypothesen, die zu diesem Zweck aufgestellt wurden,

sind im folgenden Kapitel 4 zusammengefasst.

Akquisition der

Artefakte

integrativ

nicht-integrativ

R V T N C MT

D M L

Manipulierbarkeit

der Artefakte

nein

D V T

R M L N C MT

Duplikation der

Artefakte

original

Daten

kopierte

Daten

D R V T N C MT

M L

Traceability

Schema

nein

R V M

D T L N MT

Granularität

Artefakt-

Ebene

Element-

Ebene

Parameter-

Ebene

D R V M L N C MT

Arten von

Datenstrukturen

Liste

Hierarchie

Poly-Hierarchie

netzartige Struk-

turen

D R V T M L N C MT

V T N C MT

Modellierungsun-

terstützung

keine

Regelbasiert

Informations-

rückführung

Wizard

Template

D R V T M L N

C MT

Art der

Traceability

qualitativ

quantitativ

D V T L N C MT

M L

Handhabung von

Änderungen

Benachrichti-

gung

Änderungsüber-

tragung

keine

D R V T L N MT

Zweck

Analyse

Dokumentation

Fortschritts-

kontrolle

Verifikation

Synthese

Synchroni-

sation

D R V T M L N MT

D R V T L N MT

R V T MT

V T

Darstellung der

Tracelinks

Matrix

Graph

Referenz

D R M L

D R V T

Prozessphasen-

Kontext

phasenintern

phasenübergr.

D R V T L N C MT

R V T M L N C MT

Artefakt-Kontext

artefaktintern

artefakt-

übergreifen

D V T L C MT

D R V T M L N C MT

Semantik

typisiert

nicht typisiert

R V N C MT

D V T M L MT

Speicherort der

Tracelinks

verteilt

zentral

D V T M L N C MT

Tabelle 10: Traceability-Eigenschaften der betrachteten Software-Tools (D – DOORS, R –

Reqtify, V – V6-Suite, T – Teamcenter, M – Metus, L – Loomeo. N – ToolNet, C –

ConWeaver, MT – ModelTracer)

4 FORSCHUNGSFRAGEN UND HYPOTHESEN

Wie in Kapitel 3 dargestellt, bietet die durchgängige Nachverfolgbarkeit ein großes

Potenzial für die Anwendung zur Entwicklung technischer Systeme. Ziel dabei ist es,

Abhängigkeiten zwischen Entwicklungsartefakten explizit zu modellieren, um Inkonsis-

tenzen zu vermeiden und die Entwicklung insgesamt transparenter zu gestalten. Al-

lerdings bestehen zahlreiche Herausforderungen, die einem umfassenden Einsatz bis-

lang noch entgegenstehen. Insgesamt wurden in Kapitel 3.7.1 zwölf Herausforderun-

gen identifiziert, den Kategorien technologische, methodische, zwischenmenschli-

che und monetäre Herausforderungen zugeordnet und am Beispiel des mechatroni-

schen Außenspiegels aus der Perspektive von Entwicklungsingenieuren und Entwick-

lungsmanagern reflektiert.

Auch wenn dies für eine industrielle Nutzung durchgängiger Nachverfolgbarkeit sinn-

voll wäre – nicht alle diese Herausforderungen können im Rahmen der vorliegenden

Arbeit adressiert werden. Aus diesem Grund wurde sich auf die folgenden methodi-

schen Herausforderungen beschränkt, um Ingenieure mit Methoden zur Erstellung

und Pflege durchgängiger Nachverfolgbarkeit zu unterstützen:

1 Fehlende methodische Unterstützung, um bei der Modellierung von

Tracelinks den Überblick zu behalten.

2 Fehlende methodische Unterstützung, um den signifikanten Aufwand für die

manuelle Modellierung zu bewältigen.

Forschungsfragen und Hypothesen

3 Fehlende methodische Unterstützung, um korrekte Tracelinks zu modellieren

bzw. im Nachhinein falsche und fehlende zu identifizieren.

Diese Herausforderungen werden vor dem Hintergrund der beiden Phasen „Erfas-

sung von Tracelinks“ (siehe auch Kapitel 3.4.1) sowie „Pflege von Tracelink-Modellen“

(siehe auch Kapitel 3.4.3) betrachtet. Konkret bedeutet dies, dass in Kapitel 4.1 eine

Forschungsfrage vorgestellt wird, die sich der methodischen Unterstützung zur effi-

zienten Modellierung von Tracelinks widmet und damit die zuvor beschriebenen Her-

ausforderungen 1 und 2 adressiert. In den Kapiteln 4.2 sowie 4.3 werden anschlie-

ßend Forschungsfragen formuliert, die sich mit der Sicherung der Qualität des

Tracelink-Modells befassen und somit an Herausforderung 3 richten, indem Metho-

den erforscht werden, die eine Identifikation von falschen und fehlenden Tracelinks

im Kontext der Entwicklung technischer Systeme ermöglichen.

Grundsätzlich ist anzumerken, dass keine dieser Forschungsfragen und Hypothesen

den Anspruch erhebt, die formulierten Herausforderungen in Gänze zu bewältigen.

Vielmehr handelt es sich um konkrete Teilaspekte, die erforscht werden, um einen

Beitrag zur stärkeren Verbreitung durchgängiger Nachverfolgbarkeit zur Entwicklung

technischer Systeme zu leisten.

Die Methoden, die in diesem Zusammenhang in dieser Arbeit entwickelt werden,

richten sich an den Bedarfen der Entwicklung technischer Systeme aus. So werden

im Folgenden die bereits vorgestellten Artefakte, die zur Entwicklung mechatroni-

scher Systeme genutzt werden, hinsichtlich ihrer Strukturierungsansätze analysiert und

die Erläuterung sowie Evaluation der Methoden mit Beispielen, die der Entwicklung

mechatronischer Systeme entstammen, durchgeführt. Unabhängig davon sind die

entwickelten Methoden jedoch nicht zwingend auf die Entwicklung technischer Sys-

teme festgelegt. Vielmehr ist eine Übertragbarkeit auf die Softwareentwicklung (der

die durchgängige Nachverfolgbarkeit ursprünglich entstammt) durchaus denkbar,

wird allerdings im Rahmen der vorliegenden Arbeit nicht angestrebt.

4.1 METHODISCHE UNTERSTÜTZUNG ZUR EFFIZIENTEN MODELLIERUNG VON TRACELINKS

In der Phase der Erfassung von Tracelinks besteht u. a. die Herausforderung, dass es

bei der heute üblichen manuellen Modellierung von Tracelinks ohne methodische

Unterstützung für die Ingenieure schwierig ist, den Überblick zu behalten. Insbesonde-

re bei der Analyse von Artefakten mit einer großen Anzahl von Elementen führt eine

unstrukturierte Vorgehensweise dazu, dass nicht festgestellt werden kann, welche

Elementkombinationen bereits auf Abhängigkeiten untersucht wurden. Hinzu kommt

der signifikante Aufwand, der für die Modellierung aufgebracht werden muss. Die

Forschungsfrage, die diese Herausforderungen adressiert, lautet:

Forschungsfragen und Hypothesen

Kann methodische Unterstützung helfen, den Aufwand bei der Modellie-

rung von Tracelinks zu reduzieren? Wie muss diese ausgeprägt sein?

Sie adressiert den zuvor in Kapitel 3 beschriebenen Aspekt, dass bislang zu wenig effi-

ziente Methoden für Erfassung von Tracelinks existieren. Die zugehörige Hypothese 1

macht sich die Eigenschaften bestimmter Arten von Hierarchien (siehe Kapitel

5.2.1.1) zunutze:

Die Eigenschaften von Inklusionshierarchien können genutzt werden, um

die Anzahl zu treffender Entscheidungen bei der Modellierung von

Tracelinks zu verringern.

Auf dieser Hypothese basierend wurde die Methode EcoTracing konzipiert, prototy-

pisch implementiert und evaluiert. Alle notwendigen Grundlagen sowie die Be-

schreibung und Evaluierung der Methode ist Kapitel 5 zu entnehmen.

4.2 METHODISCHE UNTERSTÜTZUNG ZUR VERTEILTEN QUALITÄTSSICHERUNG

Bei der Pflege von Tracelink-Modellen besteht u. a. die Herausforderung, falsche

Tracelinks zwischen Elementen, die keine Abhängigkeit zueinander aufweisen, zu

identifizieren. Diese falsch positiven Tracelinks haben zur Folge, dass bspw. bei Aus-

wirkungsanalysen Elemente fälschlicherweise berücksichtigt werden und somit zu-

sätzliche Aufwände erzeugt werden. Um diese Tracelinks zu identifizieren wurde fol-

gende Forschungsfrage formuliert:

Können Methoden des Crowdsourcings zur Steigerung der Qualität des

Tracelink-Modells genutzt werden?

Das Crowdsourcing (deutsch: Schwarmauslagerung) ist eine relativ neue Strategie,

die vor allen Dingen bei einer Vielzahl von Diensten im Internet zu finden ist [Estelles-

Arolas und Gonzalez-Ladron-de-Guevara 2012, S. 189] und sich potenziell gut für die

verteilte Sicherung der Qualität des Tracelink-Modells durch eine Vielzahl an Nutzern

eignen könnte. Die zugehörige Hypothese 2, die in diesem Zusammenhang evaluiert

wird, ist zweigeteilt:

Während der Interaktion mit dem Traceability-Modell fallen Nutzern falsch

modellierte Tracelinks auf.

Die Anzahl der Nutzer hat einen Einfluss auf die Vollständigkeit der Ergeb-

nisse.

Forschungsfragen und Hypothesen

Die Hypothese basiert auf der Annahme, dass den Nutzern des Tracelink-Modells

während der Verwendung von Tracelinks (z. B. zur Durchführung von Auswirkungs-

analysen) falsch positive Tracelinks auffallen und sie diese melden können. Der zwei-

te Teil der Hypothese adressiert die Annahme, dass sich eine große Anzahl an Nut-

zern positiv auf die Anzahl identifizierter falsch positiver Tracelinks auswirkt.

Basierend auf dieser Hypothese wurde die Methode TraceEvaluation entwickelt und

zum Zweck ihrer Evaluierung eine Studie durchgeführt. Die Beschreibung der Metho-

de und das Ergebnis der Evaluation ist in Kapitel 6.3 zusammengefasst.

4.3 VERWENDUNG DES WISSENS VERGANGENER PROJEKTE ZUR QUALITÄTSSICHERUNG

Eine weitere Herausforderung bei der Pflege von Tracelink-Modellen ist es, Elemente-

kombinationen zwischen denen eine Abhängigkeit besteht, aber kein Tracelink mo-

delliert wurde, zu identifizieren. Diese falsch negativen Tracelinks haben zur Folge,

dass bspw. bei Auswirkungsanalysen im Fall von Änderungen Elemente fälschlicher-

weise nicht berücksichtigt werden, was zu späten und damit teuren Änderungen füh-

ren kann. Um diese Tracelinks zu identifizieren wurde folgende Forschungsfrage for-

muliert:

Kann das Wissen, welches mithilfe von Tracelinks in vergangenen Projekten

dokumentiert wurde, in aktuellen Projekten zur Steigerung der Qualität des

Tracelink-Modells genutzt werden?

Die Frage ist, ob Wissen über Abhängigkeiten zwischen Elementen, welches in ver-

gangenen Projekten dokumentiert wurde, wiederverwendet und zur Generierung

von Vorschlägen für fehlende Tracelinks in aktuellen Projekten herangezogen wer-

den kann. Die in diesem Zusammenhang formulierte Hypothese 3 postuliert, dass dies

möglich ist:

Auf Basis von Tracelink-Modellen ähnlicher Vorgänger-Entwicklungs-

projekte können relevante Vorschläge für fehlende Tracelinks in aktuellen

Projekten generiert werden.

Als Einschränkung wird angegeben, dass es sich um inhaltlich ähnliche Projekte han-

deln muss und somit ähnliche Systeme entwickelt werden. Basierend auf dieser Hypo-

these wurde die Methode TraceLegacy konzipiert und implementiert. Die eigentliche

Evaluation erfolgte mit Hilfe eines repräsentativen Beispiels. Alle Beschreibungen der

Methode sowie deren Evaluation sind in Kapitel 6.4 zusammengestellt.

5 METHODEN ZUR EFFIZIENTEN MODELLIERUNG VON

TRACELINKS

In Kapitel 5 liegt der Fokus auf Methoden, die Ingenieuren bei der Offline-Erfassung

von Tracelinks helfen, indem der notwendige Aufwand für die manuelle Modellie-

rung von Tracelinks reduziert wird. In diesem Zusammenhang werden zunächst in Ka-

pitel 5.1 vorhandene Methoden des Stands der Technik vorgestellt. Da Hypothese 1

postuliert, dass sich Inklusionshierarchien für die angestrebte Aufwandsreduzierung

eignen, werden in Kapitel 5.2 zunächst deren Eigenschaften erörtert. Anschließend

wird für die bereits in Kapitel 2.2 beschriebenen Artefakte herausgearbeitet, ob und

unter welchen Voraussetzungen die Hypothese für sie Anwendung finden kann. Um

diese auf theoretischen Vorüberlegungen basierenden Grundlagen im Kontext der

Entwicklung eines technischen Systems zu überprüfen, wurde anschließend eine Stu-

die durchgeführt, deren Aufbau, Durchführung und Ergebnisse in Kapitel 5.3 be-

schrieben werden. Auf Basis der so zusammengestellten Voraussetzungen und An-

forderungen wurde die Methode EcoTracing zur effizienten Erfassung von Tracelinks

konzipiert, deren Funktionsprinzip und prototypische Implementierung in Kapitel 5.4

zusammengefasst werden. Die Wirksamkeit der Methode wurde in einer weiteren

Studie nachgewiesen, die in Kapitel 5.4.5 erläutert und diskutiert wird.

Explizit nicht im Fokus sind Methoden, die auf Informationsrückführung zum Vorschla-

gen von Tracelinks basieren. Wie bereits in Kapitel 3.4.1 dargestellt, werden diese im

Methoden zur effizienten Modellierung von Tracelinks

Rahmen dieser Arbeit dem Bereich der Pflege von Tracelink-Modellen zugeordnet

und deshalb in Kapitel 6 betrachtet.

5.1 STAND DER TECHNIK UND FORSCHUNG

Im Stand der Technik und Forschung sind nur wenige Methoden vorhanden, um Ent-

wickler bei der Erfassung von Tracelinks zu unterstützen. Zwar gibt es Empfehlungen,

Tracelinks möglichst direkt von Entwicklern und nicht von dezidierten Qualitätsteams

und darüber hinaus beim Feststellen einer Abhängigkeit erfassen zu lassen, wie dies

jedoch gelebt werden soll, wird selten detailliert. So ist es heute insbesondere in der

industriellen Anwendung üblich, Entwickler Abhängigkeitsmatrizen entweder allein

oder im Rahmen von Workshops ausfüllen zu lassen [Stark 2011].

Egyed et al. beschreiben in [Egyed et al. 2009] die Methode „Value-based Trace En-

hancement“, die zwar keine direkten Empfehlungen zur Modellierung gibt, jedoch

den Aufwand zur Erfassung von Tracelinks in der Softwareentwicklung reduziert und

damit Entwicklern eine Hilfestellung bietet. Die Methode geht von dem Grundsatz

aus, dass bei der Modellierung von Tracelinks nicht alle Elemente eines Artefakts die-

selbe Wichtigkeit für das zu entwickelnde System haben und somit nicht in derselben

Granularität hinsichtlich des Vorhandenseins von Tracelinks analysiert werden müs-

sen. Da es laut Egyed et al. wichtiger ist, vollständig als präzise zu sein, beginnt man

zunächst damit, die Abhängigkeiten der betrachteten Artefakten in einer groben

Granularität möglichst vollständig zu ermitteln. Eine Verfeinerung erfolgt nur in Berei-

chen der Artefakte, die eine hohe Wichtigkeit für die Entwicklung aufweisen.

Diese Wichtigkeit wird letztlich durch die spätere Verwendung der Tracelinks für un-

terschiedliche Zwecke bestimmt, die sich jedoch nicht einfach voraussagen lassen.

Als guter Indikator für die Wichtigkeit eignen sich laut Egyed et al. die Prioritäten der

Anforderungen, da sie die Gewichtung der beteiligten Stakeholder wiedergeben. Al-

ternativ können Tracelinks auch manuell direkt Wichtigkeiten zugeordnet werden.

Niedrig priorisierte Anforderungen werden somit grobgranular und hoch priorisierte

feingranular nachverfolgt. Alternativ ist es auch möglich, die Traceability erst bei Be-

darf zu verfeinern.

Durch diese Vorgehensweise ergeben sich Einsparungen, die sich jedoch nicht all-

gemeingültig quantifizieren lassen, da diese von der Struktur der betrachteten Arte-

fakte abhängig sind. So ist ein Anteil von 50 % wichtiger Anforderungen nicht gleich-

bedeutend mit 50 % Aufwandsersparnis, da diese u. U. für die Definition großer Teile

des zu entwickelnden Systems relevant sind. Egyed et al. berichten von einem Bei-

spiel, bei dem 40 % der wichtigen Anforderungen für 50-80 % des Sourcecodes rele-

Methoden zur effizienten Modellierung von Tracelinks

vant sind. Trotzdem waren in diesem Beispiel (durch Modifikation des Algorithmus zur

Bestimmung der Wichtigkeit) Einsparungen von 30-70 % realisierbar.

Tilstra et al. beschreiben die Vorgehensweise „Distributed Modeling of Component

DSM“ zum Ausfüllen von DSMs, mit deren Hilfe sich der dazu notwendige Aufwand

reduzieren lässt [Tilstra et al. 2009]. Dabei werden die Elemente einer DSM in logische

Gruppen (z. B. nach Modulen) aufgeteilt (siehe Abbildung 24, a) und deren interne

Abhängigkeiten ermittelt. Zusätzlich wird diesen Gruppen jeweils ein Element mit

dem Namen „extern“ hinzugefügt, um Abhängigkeiten über die Gruppengrenzen

hinweg modellieren zu können (siehe Abbildung 24, b). Im Anschluss werden die Ab-

hängigkeiten der Platzhalter-Gruppen untereinander in einer separaten sog. System-

DSM ermittelt (siehe Abbildung 24, c), welche im darauffolgenden Schritt durch Er-

setzen der Gruppen durch die beinhalteten Elemente wieder erweitert wird (siehe

Abbildung 24, d). Abschließend müssen noch die „extern“-Elemente auf Abhängig-

keiten überprüft werden, während die schraffierten Zellen in Abbildung 24, d) nicht

erneut betrachtet werden müssen.

Abbildung 24: Methode "Distributed Modeling of Component DSM" zur Verringerung des Auf-

wands bei der Modellierung von Tracelinks (in Anlehnung an [Tilstra et al. 2009,

S. 245])

Durch dieses Vorgehen wird eine vollständige DSM entwickelt ohne alle Element-

kombinationen überprüfen zu müssen. In einem von den Autoren beschriebenen Bei-

spiel ließen sich durch Anwendung der Methode so ca. 50 % des Aufwandes einspa-

Methoden zur effizienten Modellierung von Tracelinks

ren, indem nicht alle 1056 sondern nur 508 Zellen der DSM auf Abhängigkeiten analy-

siert werden mussten [Tilstra et al. 2009, S. 245].

Einen sehr ähnlichen Ansatz wählen Biedermann et al. [Biedermann et al. 2010]. Sie

beschreiben eine Methode, die Entwicklern Empfehlungen gibt, wie bei der Identifi-

kation von Abhängigkeiten vorgegangen werden soll und sich die Aufwände bei

dem Ausfüllen von Traceability Matrizen verringern lassen. Zu diesem Zweck wird zu-

nächst zusätzlich zur eigentlich betrachteten, detaillierten Matrix (DSM) ein abstraktes

System-Modell entwickelt und in einer DSM abgelegt. Im nächsten Schritt werden die

Abhängigkeiten zwischen abstrakter und detaillierter DSM ermittelt (bspw. die Zuge-

hörigkeiten von Bauteilen zu einem System) und in einer zusätzlichen DMM dokumen-

tiert. In der abstrakten DSM werden dann die Abhängigkeiten innerhalb des Systems

ermittelt und mit Hilfe der DMM auf die detaillierte DSM übertragen. Dies hat zur Fol-

ge, dass viele Einträge in der detaillierten DSM „vorausgefüllt“ werden. Diese müssen

dann auf ihre Korrektheit überprüft und ggf. entfernt werden. Die erreichbaren Er-

sparnisse wurden im Rahmen einer vergleichenden Studie ermittelt und in Form einer

Verringerung der notwendigen Zeit zur Erfassung der Abhängigkeiten um ca. 65 %

angegeben [Biedermann et al. 2010, S. 310].

Die beschriebenen Methoden dienen der Unterstützung der Erfassung von Tracelinks

und erfordern im Fall von Tilstra [Tilstra et al. 2009] und Biedermann [Biedermann et al.

2010] zusätzliche Verknüpfungen zwischen unterschiedlichen Abstraktionsebenen.

Ausgehend von dieser Beobachtung wird im Folgenden untersucht, ob weitere Er-

sparnisse durch eine methodische Unterstützung möglich sind, die auf den zusätzli-

chen Arbeitsschritt der Verknüpfung von Abstraktionsebenen verzichtet und an Stelle

dessen hierarchische Information verwendet. Zu diesem Zweck werden in Kapitel 5.2

Hierarchien, ihre Eigenschaften und Verwendung im Kontext der Entwicklung techni-

scher Systeme diskutiert sowie wichtige Grundlagen zur Bewertung von Methoden zur

Modellierungsunterstützung vorgestellt.

5.2 GRUNDLAGEN ZUR KONZEPTION UND BEWERTUNG DER METHODEN

Im vorliegenden Kapitel werden alle Grundlagen, die zur Konzeption einer Methode

zur effizienten Erfassung von Tracelinks notwendig sind, zusammengefasst. Dazu wird

in Kapitel 5.2.1 zunächst eine Analyse der Eigenschaften unterschiedlicher Arten von

Hierarchien durchgeführt, um herauszuarbeiten, ob und unter welchen Bedingungen

sich diese zur Konzipierung einer Methode zur Modellierungsunterstützung eignen.

Anschließend wird dies auf die in Kapitel 2.2 vorgestellten Artefakte angewendet. Zu-

sätzlich werden in Kapitel 5.2.2 unterschiedliche Granularitätsstufen der Traceability

erläutert und Schlussfolgerungen gezogen, die für die Entwicklung des Algorithmus

der Methode wichtig sind. Die mathematischen Grundlagen zur Berechnung des

Methoden zur effizienten Modellierung von Tracelinks

Aufwandes bei der manuellen Erfassung von Tracelinks sind in Kapitel 5.2.3 beschrie-

ben. In Kapitel 5.2.4 werden die Erkenntnisse abschließend kurz zusammengefasst

und diskutiert.

5.2.1 STRUKTURANALYSE DER ARTEFAKTE DER ENTWICKLUNG MECHATRONISCHER SYSTEME

In Kapitel 2.2 wurden gängige Artefakte der Entwicklung mechatronischer Systeme

vorgestellt und als Fazit herausgearbeitet, dass Abhängigkeiten zwischen den Ele-

menten dieser Artefakte bestehen, die sich mit Hilfe durchgängiger Nachverfolgbar-

keit abbilden lassen.

Im vorliegenden Kapitel werden diese hierarchischen Artefakte erneut aufgegriffen

und hinsichtlich ihrer Struktur analysiert. Zu diesem Zweck werden in Kapitel 5.2.1.1 zu-

nächst unterschiedliche Arten von Hierarchien vorgestellt, deren Eigenschaften cha-

rakterisiert und auf dieser Basis die Hypothese 1* entwickelt. Hintergrund dieser Hypo-

these ist, dass die Eigenschaften der verwendeten Hierarchien genutzt werden kön-

nen, um eine Effizienzsteigerung bei der Erfassung von Tracelinks zu erzielen. Um fest-

zustellen, auf welche der in Kapitel 2.2 vorgestellten Artefakte sich die Hypothese 1*

anwenden lässt und welche Voraussetzungen dafür gelten, werden diese in Kapi-

tel 5.2.1.2 hinsichtlich ihrer Strukturierungsansätze analysiert. Die Strukturierungsansät-

ze sind dabei der Literatur entnommen und stellen den üblichen Aufbau der Artefak-

te und damit Empfehlungen für deren Strukturierung dar.

5.2.1.1 ARTEN VON HIERARCHIEN UND IHRE EIGENSCHAFTEN

Technische Systeme sind zumeist hierarchisch aufgebaut [van den Hamer und Lepo-

eter 1996, S. 9; VDI-Richtlinie 2206, S. 24; Lane 2006, S. 86-87]. Die Ursache dafür liegt in

den zahlreichen Vorteilen, die sich daraus ergeben. So lassen sich bspw. in sich ab-

geschlossene Unterbaugruppen vormontieren, deren Entwicklung oder Fertigung

auslagern bzw. deren Wiederverwendung forcieren. Letzteres wird bspw. in Form der

modularen Quer- und Längsbaukästen in der Automobilindustrie bereits gelebt bzw.

befindet sich aktuell in der Umsetzung. Darüber hinaus ergeben sich durch den hie-

rarchischen oder modularisierten Aufbau der Systeme voneinander getrennte Ent-

wicklungsaufgaben, die nur über deren Systemgrenzen miteinander in Kontakt ste-

hen. Eine Verteilung auf mehrere Entwicklungsteams und die Begrenzung der Kom-

plexität der einzelnen Entwicklungsaufgabe ist damit möglich.

Daher sind auch die meisten der zur Entwicklung dieser Systeme verwendeten Mo-

delle bzw. Dokumente in Anlehnung an das System hierarchisch aufgebaut, wenn-

gleich sich die Arten der Hierarchien dabei unterscheiden können. Während das Ziel

der Hierarchie bei Anforderungsdokumenten bspw. eine Sortierung sein kann, wer-

Methoden zur effizienten Modellierung von Tracelinks

den Funktionsmodelle in unterschiedlichen Detaillierungs- oder Abstraktionsstufen

aufgebaut, um schlussendlich elementare Funktionen zu identifizieren, die durch ein-

fache Wirkprinzipien umgesetzt werden können [Pahl et al. 2007, S. 243].

Wie in Kapitel 3.7.1 dargestellt, mangelt es bei der Erstellung der durchgängigen

Nachverfolgbarkeit an Methoden, mit denen eine effiziente Modellierung von

Tracelinks unterstützt wird. Im Folgenden werden deshalb unterschiedliche Arten von

Hierarchien vorgestellt und hinsichtlich ihrer Eigenschaften analysiert, um diese

zwecks einer Effizienzsteigerung bei der Tracelink-Modellierung einzusetzen.

Nach Allen ist eine Hierarchie eine Sammlung von Elementen, die zueinander in

asymmetrischen Beziehungen stehen. Diese Asymmetrie bezieht sich darauf, dass die

Elemente in Ebenen angeordnet sind und die Beziehungen zwischen diesen von der

höheren zu der niedrigeren gerichtet sind. Die Zuordnung der Elemente zu den Ebe-

nen kann dabei nach beliebigen Kriterien erfolgen, die teilweise auch zeitgleich an-

gewendet werden. So können höhere Ebenen bspw. aufgrund folgender Auswahl

von Kriterien über niedrigeren Ebenen angeordnet sein [Allen 2011]:

- Sie sind der Kontext der unteren Ebenen.

- Sie stellen technische Randbedingungen für die unteren Ebenen dar.

- Sie verhalten sich langsamer, bei einer geringeren Frequenz, als untere Ebe-

nen.

- Sie enthalten bzw. bestehen aus unteren Ebenen.

Grundsätzlich ist anzumerken, dass das Konzept der Hierarchie sehr allgemein ist und

in einer Vielzahl von unterschiedlichen Wissenschaften Anwendung findet. Im Kontext

des Systems Engineerings kommen sog. Inklusionshierarchien

mit ihren unterschiedli-

chen Ausprägungen zur Anwendung. Bei einer Inklusionshierarchie stellen die Ele-

mente einer höheren Ebene einen Container für Elemente niedrigerer Ebenen dar

(siehe bspw. Abbildung 25). Zur Verdeutlichung dieser Art von Hierarchie wird häufig

das Beispiel der Matroschka-Puppen herangezogen, bei denen die äußere, größte

Puppe eine kleinere enthält, die wiederum eine noch kleinere Puppe beinhaltet. Die-

ses Beispiel stellt jedoch einen Sonderfall der Inklusionshierarchie dar, da immer ge-

nau ein Element im nächst höheren enthalten ist [Simon 1973, S. 5]. Im Normalfall

können in den übergeordneten Elementen eine beliebige Anzahl an untergeordne-

ten Elementen beliebiger Art enthalten sein [Grobstein 1973, S. 32; Lane 2006, S. 84-

85; Pumain 2006, S. 3-4].

Auch verschachtelte Hierarchie genannt.

Methoden zur effizienten Modellierung von Tracelinks

Abbildung 25: Beispiel einer Inklusionshierarchie [Grobstein 1973, S. 32]

Die bekanntesten und am häufigsten verwendeten Arten der Inklusionshierarchien

sind die subsumtive Inklusionshierarchie

und die kompositionelle Inklusionshierarchie.

Mit Hilfe der subsumtiven Inklusionshierarchie können Objekte von allgemein bis spezi-

fisch klassifiziert werden. Sie wird auch „is a“-Hierarchie genannt und entspricht der

Generalisierung im Blockdefinitionsdiagramm der SysML [Weilkiens 2006, S. 158]. Ein

anschauliches Beispiel dafür ist die Kategorisierung der Tierwelt, ausgehend von dem

sehr abstrakten Element „Tier“, welches das Element „Säugetier“ enthält, welches

wiederum die Elemente „Hund“, „Katze“ usw. enthält (siehe Abbildung 26).

Abbildung 26: Kategorisierung der Tierwelt mit Hilfe einer subsumtiven Inklusionshierarchie

Die kompositionelle Inklusionshierarchie ist umgangssprachlich auch als „is part of“

oder „is composed of“-Hierarchie bekannt. Sie wird verwendet, um Systeme zu struk-

turieren [Lane 2006, S. 85-86; Pumain 2006, S. 4] und ist damit die am meisten ver-

wendete Art der Hierarchie im Systems Engineering. Dabei wird ein System so lange

Auch Klassifikationshierarchie genannt.

«block»

Tier

«block»

Säugetier

«block»

Hund «block»

Katze

Methoden zur effizienten Modellierung von Tracelinks

in seine Subsysteme gegliedert, bis man zu einer Ebene gelangt, die sich nicht weiter

unterteilen lässt bzw. nicht mehr sinngemäß ist. Im Blockdefinitionsdiagramm der

SysML entspricht dies der Komposition bzw. Aggregation

eines Systems aus seinen

Bestandteilen [Weilkiens 2006, S. 155-157].

Beiden vorgestellten Arten von Inklusionshierarchien ist gemein, dass die hierarchi-

schen Relationen, die verwendetet werden, um die unterschiedlichen Ebenen der

Hierarchien miteinander zu verbinden, transitiv sind [Hybertson 2009, S. 90]. In Kombi-

nation mit den ebenfalls transitiven Tracelinks [Egyed und Grünbacher 2002, S. 164]

kann diese Eigenschaft bei der Modellierung von Tracelinks ausgenutzt werden. In

Abbildung 27 ist die anhand der drei Elemente A1, B1 und B1.1 dargestellt: existiert

ein Tracelink zwischen den Elementen A1 und B1.1 (durchgängiger Pfeil), so kann ein

Tracelink unter Ausnutzung der Transitivität zwischen den Elementen A1 und B1 abge-

leitet werden (gestrichelter Pfeil). Diese Eigenschaft kommt bspw. bei der Visualisie-

rung von Traceability-Modellen zum Einsatz, wenn nicht alle Hierarchieebenen dar-

gestellt, aber trotzdem alle Abhängigkeiten abgebildet werden sollen [Abma 2009,

S. 69; Beier et al. 2012, S. 16].

Abbildung 27: Ableitung von Tracelinks durch Ausnutzung der Transitivität

Im Kontext der Erfassung von Tracelinks kann diese Transitivität nun umgekehrt aus-

genutzt werden, um die Entscheidung, keinen Tracelink zwischen A1 und B1 zu mo-

dellieren (da keine Abhängigkeit vorliegt) auf die Elementekombination von A1 und

B1.1 zu übertragen

. Diese Eigenschaft ist Basis für die Hypothese 1* auf deren

Grundlage im Folgenden die EcoTracing-Methode entwickelt wird:

Der Unterschied zwischen Komposition und Aggregation besteht darin, dass bei ersterer

die Elternelemente existenziell für ihre Kinderelemente verantwortlich sind. Abgesehen da-

von verfügen sie über die gleichen Eigenschaften. Diese feine Unterscheidung gibt es bei

der kompositionellen Inklusionshierarchie nicht, weshalb sowohl Komposition als auch Ag-

gregation einer kompositionellen Inklusionshierarchie entsprechen.

Diese Eigenschaft wird auch bei dem sog. Trace Enhancement ausgenutzt, bei dem zu-

nächst nur auf hoher Ebene Tracelinks modelliert werden und erst bei Bedarf eine Detaillie-

rung vorgenommen wird. Diese Detaillierung erfolgt dann nur zwischen den Kindern von

Elementen, bei denen ein Tracelink vorliegt (siehe Kapitel 5.1) [Egyed et al. 2009, S. 249].

Methoden zur effizienten Modellierung von Tracelinks

Weist ein Element in Artefakt B eine Abhängigkeit zu einem Element in Artefak-

te A auf, so müssen auch alle seine Elternelemente eine Abhängigkeit zu dem

Element in Artefakt A bzw. (soweit vorhanden) seinen Elternelementen aufwei-

sen.

Um diese theoretisch hergeleitete Hypothese empirisch für die Erfassung von

Tracelinks zu validieren, wurde eine Studie durchgeführt. Der Aufbau, die Durchfüh-

rung und die Ergebnisse dieser Studie sind in Kapitel 5.3 zusammengefasst.

Grundsätzlich ist es somit möglich, die Entscheidung über Abhängigkeiten auf abs-

trakter hierarchischer Ebene zu treffen und diese ebenfalls auf die zugehörigen Kin-

derelemente zu übertragen, um Aufwände bei der Modellierung von Tracelinks ein-

zusparen. Allerdings sind diese Entscheidungen nicht trivial, da sie auf Basis der auf

abstrakter Ebene zur Verfügung stehenden Informationen bzw. Eigenschaften der

betrachteten Elternelemente getroffen werden müssen. Welche Informationen dies

in Abhängigkeit der verwendeten Art der Hierarchie sind, wird im Folgenden erläu-

tert.

So wird, wie zuvor beschrieben, ein Elternelement in einer kompositionellen Inklusi-

onshierarchie durch die Kinderelemente der jeweils niedrigeren Ebene aufgebaut.

Die Eigenschaften des Elternelements bestimmen sich aus denen der einzelnen Kin-

derelemente [Tudorache 2006, S. 55-56; Allen 2011] und deren Zusammenwirken. Die-

ser Zusammenhang wird „upward-causation“ genannt [Raia 2005, S. 297]. Bildlich ge-

sprochen bestehen somit die Eigenschaften des Elternelements aus zwei Teilen: der

Summe der Eigenschaften seiner Kinderelemente und den Eigenschaften, die sich

aus deren Zusammenwirken ergeben. In Abbildung 28 ist dies auf der linken Seite

schematisch für die kompositionelle Inklusionshierarchie dargestellt. Die Eigenschaf-

ten (dargestellt durch farbige Quadrate) der Elemente ergeben sich aus denen ihrer

Kinderelemente sowie durch deren Zusammenspiel. Kennt man also die Gesamtfunk-

tion „Spiegelglas verstellen“, mit der das Außenspiegelglas an die Position und Größe

des Fahrers angepasst werden kann, kann man Rückschlüsse hinsichtlich der Teilfunk-

tionen „Spiegelglas in x-Richtung verstellen“ und „Spiegelglas in y-Richtung verstel-

len“ ziehen und bereits auf Gesamtfunktionsebene entscheiden, dass bspw. eine

elektronische Steuerung oder eine elektrische Versorgung gegeben sein muss

. Bei

der Abhängigkeitsanalyse eines Artefakts, welches mit einer kompositionellen Inklusi-

onshierarchie strukturiert wurde, ist es somit (theoretisch) möglich, Entscheidungen

über Abhängigkeiten auf Basis dieser aggregierten Eigenschaften des jeweiligen El-

ternelements zu treffen.

Voraussetzung ist natürlich, dass es sich um einen elektrischen Außenspiegel handelt.

Methoden zur effizienten Modellierung von Tracelinks

Im Kontext der Entwicklung eines technischen Systems stellt eine subsumtive Inklusi-

onshierarchie hingegen eine Art Kategorisierung eines Artefakts dar. Allgemeine Ele-

mente auf hoher Ebene werden durch spezifischere, untergeordnete Elemente de-

tailliert. Ähnlich der Kategorisierung der Tierwelt (siehe Abbildung 26) können so

bspw. spezifische Anforderungen hinsichtlich ihrer Hauptmerkmale „Geometrie“,

„Energie“, „Fertigung“ usw. kategorisiert werden [Pahl et al. 2007, S. 220]. Bei dieser

Art der Hierarchie stehen im Vergleich zur kompositionellen Inklusionshierarchie weni-

ger Informationen auf abstrakter Hierarchieebene zur Verfügung, da die Eigenschaf-

ten der Elternelemente in der Hierarchie nicht aus denen der Kinderelemente ag-

gregiert werden sondern durch deren Generalisierung lediglich der „gemeinsame

Nenner“ der Eigenschaften abgebildet wird (in Abbildung 28 auf der rechten Seite

durch das rote Quadrat dargestellt).

Abbildung 28: Schematische Darstellung der Zusammensetzung von Eigenschaften (visuali-

siert durch farbige Quadrate) in kompositionellen (links) und subsumtiven In-

klusionshierarchien (rechts)

Bei einer Abhängigkeitsanalyse können anhand eines übergeordneten Elements so-

mit nur Abhängigkeiten identifiziert werden, die sich aus diesem Nenner der Eigen-

schaften ergeben. Für die Identifikation aller weiteren Abhängigkeiten, die sich aus

den konkretisierten Eigenschaften der Kinderelemente ergeben, ist deren detaillierte

Kenntnis notwendig. So kann bspw. auf Basis der Kategorie „geometrische Anforde-

rungen“ noch nicht entschieden werden, an welche Bauteile des Außenspiegels sich

die enthaltenen Anforderungen richten.

Methoden zur effizienten Modellierung von Tracelinks

Es gibt somit zwei Arten von Hierarchien, die während der Entwicklung technischer

Systeme eine Rolle spielen: subsumtive und kompositionelle Inklusionshierarchien. In

diesem Kapitel wurde herausgearbeitet, dass es im Fall der kompositionellen Inklusi-

onshierarchie bei Kenntnis des Elternelements theoretisch möglich ist, auf dieser abs-

trakten Ebene Entscheidungen über Abhängigkeiten ganzer Hierarchieäste zu tref-

fen. Bei der Abhängigkeitsanalyse subsumtiver Inklusionshierarchien ist hingegen die

Kenntnis der Kinderelemente und deren Eigenschaften Voraussetzung.

5.2.1.2 ARTEFAKTE ZUR ENTWICKLUNG MECHATRONISCHER SYSTEME

Die bereits in Kapitel 2.2 kurz vorgestellten Artefakte werden im vorliegenden Kapitel

erneut aufgegriffen und hinsichtlich ihres Strukturierungsansatzes analysiert. Ziel ist es

zu beurteilen, welche Arten von Hierarchien zur Strukturierung üblicherweise genutzt

werden, um die Voraussetzungen für die Anwendbarkeit der Hypothese 1* für das

jeweilige Artefakt zu klären.

Anforderungsartefakte

Anforderungen werden, wie in Kapitel 2.2.1 beschrieben, in Anforderungsartefakten

dokumentiert. Für den Aufbau dieser Artefakte gibt es dabei keine allgemeingültige

Vorgabe. Vielmehr gibt es Empfehlungen für unterschiedliche hierarchische Struktu-

rierungsansätze, die unternehmensspezifisch ausgeprägt werden müssen [Hood und

Wiebel 2005, S. 63]. Um diese zu charakterisieren, können drei grundsätzliche Prinzi-

pien verwendet werden [Yeh und Zave 1980, S. 1078]:

- Konkretisierung (Gegenteil: Abstraktion): aus allgemeinen Anforderungen

werden spezielle abgeleitet

- Partitionierung (Gegenteil: Komposition): eine Anforderung wird in mehrere

zerlegt

- Projektion (Gegenteil: Integration): eine Gesamtsicht auf das Produkt wird aus

mehreren Teilsichten zusammengesetzt

Beim Prinzip der Konkretisierung werden zunächst sog. übergeordnete Anforderun-

gen definiert

, die das übergeordnete Ziel des Systems in seinem Umfeld beschrei-

ben [NASA STI 2007, S. 41]. Diese Anforderungen werden anschließend Schritt für

Schritt mit Hilfe von konkreten technischen

, funktionalen und Leistungsanforderun-

gen detailliert. Man spricht in diesem Zusammenhang von der Verfeinerung der An-

Auch „High-Level Requirements“, „Erwartungen“ oder „Business Anforderungen“ genannt.

Technische Anforderungen sind abgestimmte, validierte Anforderungen, die eine vollstän-

dige Beschreibung des Problems darstellen und zur Entwicklung des Lösungsansatzes ge-

nutzt werden können [NASA STI 2007, S. 41].

Methoden zur effizienten Modellierung von Tracelinks

forderungen, die einer Generalisierung im Blockdefinitionsdiagramm der SysML ent-

spricht (siehe Abbildung 29)

. Entsprechend der Analyse in Kapitel 5.2.1.1 handelt

sich bei diesem Strukturierungsansatz um eine subsumtive Inklusionshierarchie, da all-

gemeine Anforderungen detaillierteren übergeordnet sind. So kann bspw. die detail-

lierte Anforderung bzgl. der Leistung einer Heizfolie die allgemeinere Anforderung

„Außenspiegelheizung vorsehen“ verfeinern.

Abbildung 29: Strukturierung des Anforderungsartefakts mit Hilfe der Konkretisierung

Die Partitionierung wird hingegen durchgeführt, um eine Anforderung in mehrere zu

zerlegen. So kann bspw. eine Anforderung an das Gesamtgewicht des Außenspie-

gels in mehrere Anforderungen zerlegt werden, die unterschiedlichen Systeme und

Bauteile adressieren. Im Blockdefinitionsdiagramm lässt sich diese Abhängigkeit zwi-

schen übergeordneter Anforderung und untergeordneten Anforderungen mit Hilfe

der Komposition abbilden (siehe Abbildung 30). Diese Zerlegung führt somit zu einer

kompositionellen Inklusionshierarchie (vgl. Kapitel 5.2.1.1).

Abbildung 30: Strukturierung des Anforderungsartefakts mit Hilfe der Partitionierung

Bei der Projektion werden hingegen mehrere unterschiedliche Sichten auf das zu

entwickelnde System gebildet, die sich zu einer Gesamtsicht zusammenführen lassen.

Diese Sichten können losgelöst von dem zu entwickelnden System definiert werden,

wie es bspw. beim FURPS-System (Functionality, Usability, Reliability, Performance und

Supportability) [Weilkiens 2006, S. 41] oder bei der Strukturierung nach Hauptmerkma-

len (z. B. Gestalt, Ergonomie, Fertigung usw.) umgesetzt ist [Pahl et al. 2007, S. 220]. Al-

ternativ ist der Bezug zu dem zu entwickelnden System möglich, wenn dieses bereits

hinreichend bekannt ist (z. B. bei Anpassungskonstruktionen). In diesem Fall werden

Um den Abgleich mit den in Kapitel 5.2.1.1 beschriebenen Hierarchien zu ermöglichen wird

für die Darstellung der Anforderungsartefakte in Abbildung 29 bis Abbildung 31 das Block-

definitionsdiagramm und nicht das Anforderungsdiagramm der SysML verwendet.

Methoden zur effizienten Modellierung von Tracelinks

häufig die Funktions-, System- oder Produktstruktur als Basis für Sichten und damit für

die Benennung von Kategorien für die Strukturierung der Anforderungen verwendet

[Pahl et al. 2007, S. 216].

Unabhängig von der Art stellen diese Sichten bzw. Kategorien dabei eine abstrakte

Beschreibung der darin enthaltenen Anforderungen dar (z. B. „funktionale Anforde-

rungen“ oder „Anforderungen an den Außenspiegel“), was mit Hilfe der Generalisie-

rung abgebildet werden kann (siehe Abbildung 31).

Abbildung 31: Strukturierung des Anforderungsartefakts mit Hilfe der Projektion

Bei der Projektion handelt es sich somit um eine subsumtive Inklusionshierarchie, da

die zu sortierenden Anforderungen einer Sicht bzw. Kategorie zugeordnet werden.

Die Anforderung „Spiegelverstellung bei Rückwärtsfahrt“ kann über die „is-a“ Bezie-

hung bspw. in die Kategorien „funktionale Anforderungen“ oder „Anforderungen an

den Außenspiegel“ eingeordnet werden.

Zusammenfassend ist als Ergebnis der Analyse der Anforderungsartefakte wichtig zur

Kenntnis zu nehmen, dass die Partitionierung von Anforderungen mit einer kompositi-

onellen Inklusionshierarchie abgebildet wird. Sowohl die Konkretisierung als auch die

Projektion werden hingegen in subsumtiven Inklusionshierarchien strukturiert. Entspre-

chend der Bewertung der subsumtiven Inklusionshierarchie in Kapitel 5.2.1.1 können

somit für diese beiden Ansätze die Eigenschaften der Kinderelemente nicht umfas-

send auf übergeordneter Ebene bewertet werden und bei Abhängigkeitsanalysen ist

die Kenntnis der Kinderelemente und ihrer Eigenschaften notwendig.

Funktionsartefakte

In Kapitel 2.2.2 wurden Funktionen als lösungsneutrale Beschreibungsform techni-

scher Systeme eingeführt. Die Vorgehensweise zur Spezifikation der Funktionen ist

dabei von abstrakt nach detailliert (top-down): die vergleichsweise abstrakten Ge-

samtfunktion wird schrittweise in ihre Teilfunktionen heruntergebrochen [Pahl et al.

2007, S. 242-248; Ponn und Lindemann 2008, S. 58]. Durch das Herunterbrechen wer-

den die Funktionen immer konkreter bis Wirkprinzipien bzw. Lösungselemente für de-

ren Erfüllung identifiziert werden können [Pahl et al. 2007, S. 255]. Die Frage der Gra-

nularität („Auf welcher Ebene hört man auf zu modellieren?“) ist dabei nicht einfach

zu beantworten [Chakrabarti und Bligh 2001, S. 500]. So spielen bspw. die Art des zu

entwickelnden Systems und der Entwicklung eine große Rolle. Während bei Neuent-

wicklungen eine höhere Granularität notwendig ist, sind bei evolutionären Weiter-

entwicklungen auch abstraktere Funktionsstrukturen für die Kommunikation der Ent-

Methoden zur effizienten Modellierung von Tracelinks

wickler ausreichend. Genauso gibt es Unterschiede zwischen den Disziplinen. Sobald

festgelegt wird, wie eine Funktion umgesetzt werden soll, kann es bspw. in der Soft-

wareentwicklung notwendig sein, die Funktionen weiter herunterzubrechen, wäh-

rend die abstrakte Darstellung für die mechanische Konstruktion vollkommen ausrei-

chend sein kann.

Solange die abstrakte Hauptfunktion überhaupt heruntergebrochen wird, stellen die

Funktionsartefakte eine Verbindung zwischen der abstrakten Aufgabenstellung und

den Detailentwicklungen der unterschiedlichen Disziplinen her [Erden et al. 2008,

S. 147]. Ziel ist dabei, neben der lösungsneutralen Beschreibung des zu entwickeln-

den Systems, auch die Partitionierung der Entwicklungsaufgaben auf unterschiedli-

che Abteilungen bzw. Entwickler, was sich auf Basis der Teilfunktionen gut durchfüh-

ren lässt [Leenders et al. 2007, S. 168; Pahl et al. 2007, S. 243].

Grundsätzlich gibt es drei unterschiedliche Strukturierungsansätze, um die Gesamt-

funktion und ihre Teilfunktionen zu erfassen. Eine Listendarstellung eignet sich bspw.

zur Dokumentation von relativ unabhängigen Funktionen oder zur Sammlung aller

Funktionen als vorbereitende Vorstufe für die Erarbeitung anderer Darstellungen

[Ponn und Lindemann 2008, S. 61]. Eine Erweiterung der Liste ist die Hierarchie, in der

die Eltern-Kind-Beziehung der Gesamtfunktion und ihrer Teilfunktionen, aus denen sie

besteht, abgebildet werden kann [Ponn und Lindemann 2008, S. 62]. Die Gesamt-

funktion des Außenspiegels „Rückblick gewährleisten“ kann so übergeordnet zu sei-

nen Teilfunktionen „Eis beseitigen“, „Rückblickrichtung verstellen“, „Außenspiegel

steuern“ usw. dargestellt werden. Die Beziehung zwischen über- und untergeordneter

Funktion wird im Funktionsartefakt, wie in Abbildung 32 dargestellt, mit einer Komposi-

tion abgebildet (die Gesamtfunktion besteht aus den Teilfunktionen), die einer kom-

positionellen Inklusionshierarchie entspricht (vgl. Kapitel 5.2.1.1).

Abbildung 32: Strukturierung des Funktionsartefakts mit Hilfe einer Hierarchie

Dieser Strukturierungsansatz eignet sich zur Erfassung der Funktionen, da die Anzahl

der dargestellten Hierarchieebenen frei gewählt und so leicht der gewünschte Abs-

traktionsgrad von abstrakter Gesamtfunktion bis zur detaillierten Teilfunktion einge-

stellt werden kann. Dies gilt, solange die Abhängigkeiten zwischen den Teilfunktionen

der unterschiedlichen Hierarchieebenen eine untergeordnete Rolle spielen. Sind die-

se jedoch für die Analyse der Funktionen und damit für die Weiterentwicklung zur Lö-

Methoden zur effizienten Modellierung von Tracelinks

sung wichtig, eignet sich die Funktionsstruktur, die häufig in Blockdiagrammen darge-

stellt wird, besser als die Hierarchie (siehe Abbildung 33).

Abbildung 33: Dreidimensionale Blockdarstellung einer Funktionsstruktur [Pahl et al. 2007,

S. 45]

Bei dieser Darstellungsform werden alle Funktionen, die sich auf einer hierarchischen

Ebene befinden, sowie deren Abhängigkeiten dargestellt. Um die unterschiedlichen

hierarchischen Ebenen gleichzeitig zu visualisieren, kann bspw. eine dreidimensionale

Blockdarstellung wie in Abbildung 33 gewählt werden.

Hinsichtlich des Aufbaus des Funktionsartefakts bedeutet die Verwaltung von Funkti-

onsstrukturen eine Erweiterung des in Abbildung 32 beschriebenen Modells um die

Möglichkeit, Verknüpfungen zwischen den Funktionen abbilden zu können (siehe

Abbildung 34).

Abbildung 34: Strukturierung des Funktionsartefakts mit Hilfe einer Funktionsstruktur

Als wichtigste Erkenntnisse kann zusammengefasst werden, dass Funktionsartefakte

der lösungsneutralen Beschreibung der Funktionen eines zu entwickelnden Systems

dienen. Zu ihrer Strukturierung stehen drei Ansätze zur Verfügung: Liste, Hierarchie und

Funktionsstruktur. Während die erste lediglich der Sammlung von Funktionen dient,

werden die Hierarchie und die Funktionsstruktur Top-Down entwickelt, indem eine zu-

nächst definierte Gesamtfunktion schrittweise in ihre Teilfunktionen heruntergebro-

chen wird. Bei der so entstehenden hierarchischen Struktur bestehen die übergeord-

Methoden zur effizienten Modellierung von Tracelinks

neten aus den untergeordneten Funktionen, was einer kompositionellen Inklusionshie-

rarchie entspricht.

Verhaltensartefakte

Wie in Kapitel 2.2.3 beschrieben, dienen Verhaltensartefakte der Simulation des Ver-

haltens von Systemen. In diesem Zusammenhang sind objektorientierte Modellie-

rungsansätze in der Systementwicklung sehr verbreitet [Vajna 2009, S. 313]. Im Mittel-

punkt dieser Ansätze steht eine textuelle Objektbeschreibungssprache [Janschek

2010, S. 132], mit deren Hilfe die Objekte beschrieben werden. Dazu werden Differen-

zial-, algebraische und diskrete Gleichungen genutzt [Vajna 2009, S. 314]. Darüber

hinaus besitzen sie Parameter, die während der Simulation konstant sind, Variablen

und Schnittstellen, über welche die Objekte miteinander kommunizieren [Drogies

2006, S. 75]. Dabei werden Objekte verwendet, um (Teil-)Systeme darzustellen. Mit Hil-

fe von Hierarchisierung können sie strukturiert und wiederum in ihre Subsysteme zer-

legt werden. Dabei gilt, dass die Subsysteme möglichst unabhängig voneinander

sein sollten und die Anzahl der Schnittstellen zwischen ihnen zu minimieren ist. Das

Verhaltensmodell des Außenspiegels könnte so u. a. in die Systeme „Außenspiegel-

heizung“ und „Spiegelglasverstellung“ strukturiert werden, in denen das jeweilige

Verhalten wiederum mit Objekten aus Bibliotheken nachgebildet wird. Die Kommuni-

kation zwischen den Objekten erfolgt innerhalb der einzelnen Hierarchiestufen mittels

Signal- und Energieflüssen, mit denen die Objekte bzw. (Teil-) Systeme miteinander

verbunden werden. Hinsichtlich des Aufbaus von Verhaltensartefakten bedeutet

dies, dass die abgebildeten Systemelemente mit Hilfe einer Komposition aufgebaut

werden. Zwischen diesen Systemelementen bestehen jeweils auf einer Ebene Ab-

hängigkeiten, die unterschiedlich ausgeprägt sein können (siehe Abbildung 35). Bei

der so entstehenden Hierarchie handelt es sich um eine kompositionelle Inklusionshie-

rarchie.

Abbildung 35: Strukturierung eines Verhaltensartefakts

Zusammenfassend ist für Verhaltensartefakte festzuhalten, dass diese hierarchisch

aufgebaut werden. Die Struktur der Artefakte orientiert sich dabei an dem Aufbau

des zu entwickelnden Systems, indem dieses in seine Subsysteme aufgeteilt und mit

Methoden zur effizienten Modellierung von Tracelinks

Hilfe von Objekten (überwiegend aus Bibliotheken) nachgebildet wird. Bei der so

entstehenden kompositionellen Inklusionshierarchie bestehen somit übergeordnete

aus untergeordneten Objekten.

Produktstrukturartefakte

In Kapitel 2.2.4 wurde bereits beschrieben, dass Produkt- bzw. Systemstrukturen der

Verwaltung von Systemen, Baugruppen sowie Bauteilen, Softwareelementen und In-

formationselementen dienen. Die Art und Weise der Gliederung - also welches Bau-

teil welcher Baugruppe bzw. welchem System zugeordnet wird - orientiert sich in der

industriellen Anwendung am Zweck der Produktstruktur. Typische Ansätze, die auch

in Kombination vorkommen können, sind u. a. die Strukturierung des Produkts nach:

- Entwicklungsdisziplinen: Produkte werden in Systeme unterteilt, die sich auf-

grund ihrer Entwicklung voneinander unterscheiden. Diese können auf ver-

schiedene Entwicklungsabteilungen aufgeteilt werden. In der Fahrzeugent-

wicklung kann so bspw. ein Kfz in die Systeme Rohkarosse, Interieur, Verkabe-

lung, Antrieb, Unterboden und Fahrwerk unterteilt und verteilt entwickelt wer-

den.

- Funktionen: Bei diesem Ansatz werden Bauteile, Baugruppen und Systeme

nach ihren jeweiligen Funktionen klassifiziert und diesen zugeordnet [Eigner

und Stelzer 2009, S. 28]. Dabei wirkt sich insbesondere die Tatsache, dass eine

eindeutige Funktionszuordnung schwierig ist (entweder weil die Funktion eines

Bauteils nicht direkt ersichtlich ist oder weil mehrere Funktionen unterstützt

werden), als negativ aus.

- Modularisierungsgesichtpunkten: Bauteile werden den Baugruppen auf eine

Art und Weise zugeordnet, dass sich möglichst in sich abgeschlossene Module

ergeben, die nur eine geringe Anzahl Schnittstellen zu anderen Modulen auf-

weisen. Dieser Ansatz soll insbesondere bei komplexen Systemen zur verbesser-

ten Übersicht und Transparenz beitragen [Vajna 2009, S. 206].

- Fertigungsgesichtspunkten: Bauteile werden nach ihrem Fertigungsverfahren

zusammengefasst. Diese Art der Strukturierung findet insbesondere in der Pro-

duktionsplanung Anwendung [Eigner und Stelzer 2009, S. 28].

- Montagegesichtspunkten: Die Bauteile werden zu vormontierbaren Baugrup-

pen zusammengefasst, die bei der späteren Montage zum Endprodukt zu-

sammengefügt werden [Schuh et al. 2012, S. 118].

Somit ist es möglich, dasselbe Produkt nach unterschiedlichen Gesichtspunkten zu

gliedern und zu jeweils unterschiedlich ausgeprägten Produktstrukturen zu gelangen.

Dies ist in Abbildung 36 anhand der beispielhaften Strukturierung eines Außenspiegels

dargestellt: im Fall a) wird der Außenspiegel hinsichtlich unter Montagegesichtspunk-

ten strukturiert. Die Heizfolie wird in diesem Fall der Glaseinheit zugeordnet, da diese

Methoden zur effizienten Modellierung von Tracelinks

auf das Spiegelglas aufgeklebt wird. In Fall b) wird der Außenspiegel hinsichtlich sei-

ner Funktionen strukturiert. In diesem Fall wird die Heizfolie der Spiegelheizung zuge-

ordnet.

Abbildung 36: Ausschnitt einer beispielhaften Strukturierung eines Außenspiegels a) unter Be-

rücksichtigung von Montagegesichtspunkten und b) entsprechend der Funkti-

onen

Unabhängig von der Wahl des Strukturierungsansatzes wird die Produktstruktur immer

aus Systemen, Baugruppen, sowie Bauteilen und Software- und Informationselemen-

ten aufgebaut. Erstere sind dabei die in der Hierarchie übergeordneten Knoten, wo-

bei sie selbst wieder Systemen oder Baugruppen untergeordnet sein können. Bauteile

liegen auf der niedrigsten hierarchischen Ebene. Die Beziehungen zwischen den ein-

zelnen Ebenen der Hierarchie werden dabei mit einer Aggregation gebildet [Weil-

kiens 2006, S. 118] (siehe Abbildung 37). Die Hierarchie der Produktstruktur entspricht

damit einer kompositionellen Inklusionshierarchie.

Abbildung 37: Schematischer Aufbau einer Produktstruktur

Methoden zur effizienten Modellierung von Tracelinks

5.2.1.3 ZUSAMMENFASSUNG UND DISKUSSION

In Kapitel 5.2.1.1 wurden zunächst die zur Strukturierung von Artefakten verbreiteten

subsumtive und die kompositionelle Inklusionshierarchie vorgestellt und ihre Eigen-

schaften vor dem Hintergrund effizienter Tracelink-Modellierung analysiert.

Als Ergebnis dieser Analyse wurde herausgearbeitet, dass bei Inklusionshierarchien

aufgrund hierarchischer Transitivität Entscheidungen, die auf einer abstrakten Ebene

für Elternelemente bzgl. Abhängigkeiten zu anderen Elementen getroffen werden,

auf deren Kinderelemente übertragen werden können. Dies ist Vorteilhaft, da auf

diese Weise insbesondere bei der Entscheidung für die Nicht-Existenz einer Abhän-

gigkeit viele Elementkombinationen vorab von der Analyse ausgeschlossen werden

können. Diese Erkenntnis bildete die Grundlage für Hypothese 1*, die im Folgenden

als Ausgangspunkt für die Entwicklung einer Methode zur effizienten Modellierung

von Tracelinks dient (siehe Kapitel 5.4). Darüber hinaus wurde herausgearbeitet, dass

in kompositionellen Inklusionshierarchien die Eigenschaften der Kinderelemente auf-

grund der bestehenden Kompositions- bzw. Aggregationsbeziehungen auf Ebene

des Elternelements abgeschätzt und damit Entscheidungen über Abhängigkeiten

getroffen werden können. Bei subsumtiven Inklusionshierarchien kann diese Eigen-

schafts-Abschätzung hingegen aufgrund der vorliegenden Generalisierungsbezie-

hungen nicht ohne Kenntnis der Kinderelemente und deren Eigenschaften durch-

führt werden.

Anschließend wurden in Kapitel 5.2.1.2 die bereits in Kapitel 2.2 vorgestellten Artefak-

te einer Strukturanalyse unterzogen, um herauszuarbeiten mit welcher Art Hierarchie

sie üblicherweise strukturiert werden und unter welchen Bedingungen sich die Hypo-

these 1* anwenden lässt. Eine Übersicht der Artefakte und deren Zuordnung zu den

vorgestellten Arten der Hierarchien ist Tabelle 11 zu entnehmen.

kompositionelle

Inklusionshierarchie

(Aggregation / Komposition)

subsumtive

Inklusionshierarchie

(Generalisierung)

Anforderungsartefakte

Funktionsartefakte

Verhaltensmodelle

Produktstrukturen

Tabelle 11: Zuordnung von verwendeten Artefakten zur Art der Hierarchie

Grundsätzlich zeigte sich bei der Analyse, dass alle betrachteten Artefakte mit Inklu-

sionshierarchien aufgebaut werden und Hypothese 1* damit für die betrachteten Ar-

tefakte seine Gültigkeit hat. Bei der Mehrzahl der Artefakte kommen kompositionelle

Inklusionshierarchien zum Einsatz, bei denen die übergeordneten Elemente aus ihren

Kinderelementen aufgebaut sind. In dieser Hinsicht die einzige Ausnahme stellt das

Methoden zur effizienten Modellierung von Tracelinks

100

Anforderungsartefakt dar. Wird dieses mittels Projektion oder Konkretisierung struktu-

riert, bestehen Generalisierungsbeziehungen zwischen Eltern- und Kinderelementen.

Ergebnis ist eine subsumtive Inklusionshierarchie, bei der Entscheidungen über Ab-

hängigkeiten auf abstrakter Ebene nicht ohne die Kenntnis der Kinderelemente ge-

troffen werden können.

Um die theoretisch hergeleitete Hypothese 1* sowie die beschriebenen Eigenschaf-

ten der Inklusionshierarchien hinsichtlich der auf abstrakter Ebene für eine Entschei-

dung zur Verfügung stehenden Informationen im Kontext der Entwicklung eines

technischen Systems zu verifizieren, wurde eine Studie durchgeführt, deren Aufbau,

Durchführung und Ergebnisse in Kapitel 5.3 beschrieben sind.

5.2.2 GRANULARITÄT IM KONTEXT DER TRACEABILITY

Wie in Kapitel 5.2.1 beschrieben, sind Artefakte im Systems Engineering aus Elemen-

ten aufgebaut, welche in beliebig viele hierarchische Ebenen strukturiert werden

können. Mit Hilfe dieser Inklusionshierarchien lassen sich die Artefakte sortieren bzw.

Detaillierungsgrade von abstrakt bis detailliert abbilden. Elemente können darüber

hinaus mit Parametern beschrieben werden, was die detaillierteste Form darstellt. Ei-

ne Darstellung des Aufbaus von Artefakten sowie der Bedeutung der Begriffe „Gra-

nularität“, „Detaillierungsgrad“ und „hierarchische Ebene“ ist Abbildung 38 zu ent-

nehmen.

Abbildung 38: Aufbau von Artefakten im Systems Engineering und Einordnung der Begriffe

"Granularität", "Detaillierungsgrad" und "hierarchische Ebene"

Im Kontext der durchgängigen Nachverfolgbarkeit stellt die Festlegung, zwischen

welchen dieser Detaillierungsstufen bzw. in welcher Granularität Tracelinks modelliert

werden, einen wichtigen Faktor zur Beeinflussung des Aufwand/Nutzen-Verhältnisses

Methoden zur effizienten Modellierung von Tracelinks

101

dar (siehe auch Kapitel 3.4.4). Insgesamt gibt es fünf relevante Arten der Tracelink-

Modellierung (siehe Abbildung 39). Diese werden im Folgenden kurz erläutert und

anhand des schematischen Auszugs der beiden Artefakte „Anforderungsspezifikati-

on“ und „Funktionshierarchie“ des mechatronischen Außenspiegels in Abbildung 40

veranschaulicht.

Abbildung 39: Granularitätsebenen bei der Modellierung von Tracelinks

a) Die Modellierung von Tracelinks auf Artefakt-Ebene (Artefakt «» Artefakt) ist ei-

ne sehr abstrakte Form der Traceability (Abbildung 39, a). Sie wird bspw. ge-

nutzt, um auszudrücken, dass eine bestimmte Anforderungsspezifikation durch

ein Funktionsmodell adressiert wird. Bei der Entwicklung eines Pkws könnte so-

mit beschrieben werden, dass die Anforderungen der Anforderungsspezifika-

tion „Außenspiegel“ durch die Funktionshierarchie „Außenspiegel“ erfüllt wer-

den. Der Nutzen ist damit vergleichsweise gering, der Aufwand zur Modellie-

rung von Tracelinks jedoch ebenfalls. Diese Detaillierungsstufe wird hauptsäch-

lich genutzt, um Traceability-Schemata zu erstellen.

b) Tracelinks zwischen Artefakten und Elementen (Artefakt «» Element) stellen die

nächst detailliertere Stufe der Modellierung dar (Abbildung 39, b). Sie werden

bspw. genutzt, um auszudrücken, dass ein Element relevant für die Ausarbei-

tung eines vollständigen Artefakts ist. Am Beispiel des Außenspiegels würde ein

Tracelink zwischen der Anforderung 5.6 und der Funktionshierarchie „Außen-

spiegel“ bedeuten, dass die geforderte Außenspiegelheizung durch die Funk-

Methoden zur effizienten Modellierung von Tracelinks

102

tionshierarchie realisiert wird. Dies kann bspw. sinnvoll sein, wenn mehrere

Funktionsartefakte existieren (bspw. eine für den Einklappmechanismus und

eine für die Beheizung). Der Aufwand zur Erfassung von Tracelinks hängt dabei

stark davon ab, bis zu welcher hierarchischen Element-Ebene Tracelinks mo-

delliert werden sollen.

Abbildung 40: Auszug aus dem Anforderungs- und Funktionsartefakt des mechatronischen

Außenspiegels

c) Die Modellierung von Tracelinks zwischen Elementen unterschiedlicher Arte-

fakte (Element «» Element) ist die häufigste Stufe der Modellierung (Abbild-

ung 39, c). Auf dieser Stufe lässt sich bspw. ausdrücken, welche Anforderun-

gen durch welche Funktionen oder welche Bauteile erfüllt werden müssen. Im

Beispiel sagt ein Tracelink auf Elementebene aus, dass die Funktion „Außen-

spiegel beheizen“ zur Realisierung der Anforderung 5.6 beiträgt. Wie bei (Arte-

fakt «» Element), hängt der Aufwand stark von der hierarchischen Struktur der

Artefakte ab. Ist diese sehr tief und werden die Tracelinks bis zur untersten hie-

rarchischen Ebene modelliert, ist die Anzahl der betrachteten Elemente und

damit der Aufwand sehr groß.

Methoden zur effizienten Modellierung von Tracelinks

103

d) In der Stufe (Element «» Parameter) werden Elemente direkt mit bestimmten

Parametern anderer Artefakte durch Tracelinks verknüpft (Abbildung 39, d).

Dadurch können bspw. textuell beschriebene Anforderungen direkt auf Pa-

rameter in Funktions- oder Geometrie-Modellen bezogen werden und damit,

im Fall von Änderungen, eine präzisere Identifikation betroffener Parameter

durchgeführt werden. Die Anforderung 5.6, in der die maximale Zeit, in der Eis

vom Außenspiegel entfernt werden soll, im Fließtext beschrieben ist, würde

somit mit dem Leistungsparameter der Funktion 5.2 verknüpft. Insbesondere,

wenn die Funktion über mehrere Parameter verfügt, ermöglicht diese Art der

Modellierung die Identifikation spezifischer Parameter, bspw. bei Änderungen

der textuellen Beschreibung der Anforderung. Der notwendige Aufwand ist

höher als bei (Element «» Element), da die feingranularen Parameter in der

Analyse berücksichtigt werden müssen.

e) Die höchste Granularitätsstufe der Traceability wird erreicht, wenn Links zwi-

schen einzelnen Parametern (Parameter «» Parameter) der Elemente model-

liert werden (Abbildung 39, e). Es würde also der explizit modellierte Parameter

der Anforderung tmax = 30 s direkt mit dem Leistungsparameter der Funktion

verknüpft werden. In Abhängigkeit der Realisierung im jeweiligen Software

Tool lässt sich so bspw. der Parameter der Funktion, der während der Entwick-

lung der Funktionshierarchie ggf. variiert wird, mit dem der Anforderung ab-

gleichen. Abweichungen lassen sich so direkt und ohne manuelle Überprü-

fung feststellen und automatisiert melden. Alternativ ist es möglich, dass nicht

nur überwacht, sondern direkt geändert wird. Eine Änderung der Vorgabe in

der Anforderung hätte somit direkt eine Änderung des Leistungsparameters

der Funktion zur Folge. Nachteil dieser detailliertesten Form der Traceability-

Modellierung ist der Aufwand, der für die Erfassung der Tracelinks notwendig

ist. Letztlich muss jeder Parameter, der überwacht werden soll, per Hand ver-

knüpft werden.

Anzumerken ist, dass eine geringe Granularität keine fehlenden Tracelinks zur Folge

hat, da diese von den höheren Ebenen der Hierarchie auf die unteren vererbt wer-

den [Sutinen et al. 2000, S. 12]. Das hat zur Folge, dass zahlreiche Elemente und Pa-

rameter einen Tracelink erben, die eigentlich keine Abhängigkeit aufweisen [Egyed

et al. 2009, S. 248]. In Abbildung 41 ist dies beispielhaft dargestellt.

Besteht ein Tracelink von einem Artefakt A zu Artefakt B, so erben alle Kinderelemen-

te B1 und B2 ebenfalls einen Tracelink (Abbildung 41, a). Dadurch nimmt die Präzisi-

on, mit der betroffene Elemente und Parameter bei einer Auswirkungsanalyse identi-

fiziert werden können, deutlich ab [Bianchi et al. 2000, S. 156; Egyed et al. 2009,

S. 247]. Bei einer Auswirkungsanalyse müssten somit bei einer Änderung von A sowohl

das abhängige Element B1 als auch das unabhängige Element B2 auf Auswirkungen

Methoden zur effizienten Modellierung von Tracelinks

104

untersucht werden. Die Wahl einer höheren Granularität hätte indes zur Folge, dass

ausgehend von Artefakt A nur das tatsächlich abhängige Element B1 mit einem

Tracelink verknüpft wird (Abbildung 41, b). Bei Durchführung derselben Auswirkungs-

analyse müsste somit nur B1 auf Auswirkungen untersucht werden.

Abbildung 41: Folgen der Reduktion der Granularität auf die Auswertung von Tracelinks: a)

durch eine niedrige Granularität werden viele Tracelinks zwischen Elementen

vererbt, bei denen keine Abhängigkeit besteht. b) durch die Wahl einer höhe-

ren Granularität werden nur tatsächlich Abhängige Elemente verknüpft.

Eine allgemeingültige Aussage, welche Granularität der Tracelinks die „angemesse-

ne“ ist, kann nicht getroffen werden [Mäder et al. 2009a, S. 5], da diese von unter-

schiedlichen Aspekten abhängig ist. Unternehmensspezifische Vorgehensweisen und

Methoden haben bspw. einen großen Einfluss auf die Strukturierung der Artefakte

und damit auf den notwendigen Aufwand zur Erfassung der Tracelinks. Ähnlich ver-

hält es sich mit individuellen Vorgehensweisen der Ingenieure, die beim Modellieren

der Artefakte unterschiedliche Strukturierungsansätze wählen. Darüber hinaus wer-

den während der Produktentwicklung in Abhängigkeit der Branche unterschiedliche

Artefakte erstellt bzw. vom Gesetzgeber gefordert und diese wiederum sehr unter-

schiedlich aufgebaut. Den größten Einfluss auf die zu wählende Granularität eines

Traceability-Ansatzes hat jedoch die geplante Verwendung der Tracelinks, welche

sich zum Zeitpunkt der Erfassung auf mittel- und langfristige Sicht nur schwer voraus-

sehen lässt [Bianchi et al. 2000, S. 156; Egyed et al. 2009, S. 257; Mäder et al. 2009a,

S. 4].

Deshalb ist es sinnvoll, falls der Verwendungszweck nicht bekannt ist, die Modellie-

rung der Tracelinks im Rahmen der zur Verfügung stehenden Ressourcen zunächst

auf den hohen hierarchischen Element-Ebenen durchzuführen und insbesondere de-

ren Korrektheit und Vollständigkeit zu berücksichtigen [Egyed et al. 2009, S. 242]. Da-

bei sollte beachtet werden, dass alle involvierten Artefakte auf einem ähnlichen

Granularitätsniveau betrachtet werden. Eine Missachtung dieser Faustregel führt laut

Mäder et al. zu einer großen Anzahl von Tracelinks, die nicht mehr Aussagekraft bie-

ten, als das Verknüpfen auf einer hohen hierarchischen Ebene [Mäder et al. 2009a,

S. 4]. Anschließend können beispielsweise Methoden wie das „Value-based Trace

Methoden zur effizienten Modellierung von Tracelinks

105

Enhancement“ von Egyed et al. [Egyed et al. 2009] o. ä. [Ramesh und Edwards 1993,

S. 257; Bianchi et al. 2000, S. 157; Ramesh und Jarke 2001, S. 19] gezielt angewendet

werden, um die Traceability ziel- und bedarfsgerecht zu verfeinern.

Hinsichtlich der Methoden zur effizienten Modellierung von Tracelinks gilt es somit

festzuhalten, dass eine flexible Unterstützung der unterschiedlichen Granularitäts-

ebenen gewährleistet werden sollte. Insbesondere bei der Modellierung auf der

(Element «» Element)-Ebene, die in Abhängigkeit der Strukturierung der Artefakte sehr

umfangreich sein kann, sollte die Modellierungstiefe frei wählbar sein.

5.2.3 ERMITTLUNG DES AUFWANDS BEI DER MANUELLEN ERFASSUNG VON TRACELINKS

Wie in Kapitel 3.4.1 beschrieben, kann bei der Erfassung von Tracelinks zwischen einer

Online- und einer Offline-Erfassung unterschieden werden. Während erstere parallel

zur Modellierung der Artefakte durch den Anwender durchgeführt wird, findet letzte-

re im Anschluss an die Modellierung der Artefakte statt. Da es sich bei der im Kapi-

tel 5.3 vorgestellten Methode EcoTracing um eine Offline-Methode handelt, wird die-

se Vorgehensweise hier als Grundlage für die Ermittlung des Aufwandes verwendet.

Bei der Offline-Erfassung definiert sich der Aufwand für die Erfassung vorwiegend

über die Anzahl der Entscheidungen (ob eine Abhängigkeit zwischen zwei Elemen-

ten besteht oder nicht), die bei der Analyse getroffen werden müssen, sowie die be-

nötigte Zeit. Vereinfachend wird dabei angenommen, dass die Erfassung nach dem

u. a. von Maurer, Lindemann et al. und Biedermann et al. beschriebenen Schema in

Form von Workshops, bei denen alle Elementkombinationen überprüft werden,

durchgeführt wird (siehe Abbildung 42) [Maurer 2007, S. 98; Lindemann et al. 2009,

S. 79; Biedermann et al. 2010, S. 309].

Abbildung 42: Vorgehensweise zur Erfassung von Abhängigkeiten am Beispiel einer DSM (in

Anlehnung an [Maurer 2007, S. 98])

Methoden zur effizienten Modellierung von Tracelinks

106

Diese strukturierte Vorgehensweise wird von den Autoren empfohlen, da so keine

Elementekombinationen übergangen werden. Neben diesen Quellen aus dem aka-

demischen Bereich wird diese Vorgehensweise auch im industriellen Kontext ange-

wendet, wie im Rahmen einer Studie zu den Herausforderungen moderner Pro-

duktentstehungsprozesse durch das Fraunhofer IPK festgestellt wurde [Stark 2011].

Im Folgenden wird die Berechnung anhand eines abstrakten Beispiels durchgeführt

(Abbildung 43). Dabei werden die Artefakte A und B betrachtet, die jeweils aus m

bzw. n Elementen hierarchisch aufgebaut sind.

Abbildung 43: Abstraktes Beispiel zur Ermittlung des Aufwands

Für dieses Beispiel ergibt sich die Anzahl notwendiger Entscheidungen EM für die Arte-

fakte mit m bzw. n Elementen, nach der oben beschriebenen Vorgehensweise, somit

zu:

𝑬𝑴=𝒎∗𝒏 .

(1)

Der notwendige zeitliche Aufwand TM kann damit, bei einer gemittelten Bearbei-

tungs- bzw. Entscheidungszeit von tØ, wie folgt berechnet werden:

𝑻𝑴=𝒎∗𝒏∗𝒕∅ .

(2)

Werden nicht nur zwei sondern x Artefakte betrachtet und miteinander verknüpft,

ergibt sich die Anzahl notwendiger Artefaktkombinationen o nach folgender Formel:

𝒐=∑𝒊

𝒙−𝟏

𝒊=𝟏

(3)

Somit lassen sich die Anzahl notwendiger Entscheidungen und der zeitliche Aufwand

folgendermaßen berechnen:

Methoden zur effizienten Modellierung von Tracelinks

107

𝑬𝑴=∑𝒎𝒊∗𝒏𝒊

𝒐

𝒊=𝟏

(4)

bzw.

𝑻𝑴=∑(𝒎𝒊∗𝒏𝒊)∗𝒕∅

𝒐

𝒊=𝟏 .

(5)

Für das Beispiel in Abbildung 43 ergeben sich damit, unter Berücksichtigung der Ele-

ment-Anzahlen m = 8 und n = 11 und einer geschätzten mittleren Bearbeitungszeit

von tØ = 2 s, folgende Werte:

𝑬𝑴=𝒎∗𝒏=𝟖∗𝟏𝟏=𝟖𝟖

(6)

bzw.

𝑻𝑴=𝒎∗𝒏∗𝒕∅=𝟖∗𝟏𝟏∗𝟐𝒔=𝟏𝟕𝟔 𝒔 .

(7)

5.2.4 ZUSAMMENFASSUNG UND SCHLUSSFOLGERUNGEN

In Kapitel 5.2.1 wurde zunächst eine Betrachtung hierarchischer Artefakte durchge-

führt. Bei dieser Analyse wurde herausgearbeitet, dass es aufgrund der Transitivität

hierarchischer Relationen möglich ist, Entscheidungen, die über Abhängigkeiten von

Elternelementen getroffen werden, auf deren Kinderelemente zu übertragen. Diese

Erkenntnis bildete die Grundlage für Hypothese 1*, die im Folgenden als Ausgangs-

punkt für die Entwicklung einer Methode zur effizienten Modellierung von Tracelinks

dient (siehe Kapitel 5.4). Da die Analyse zusätzlich ergab, dass die Art der Hierarchie

Auswirkungen auf die Erfassung von Tracelinks hat, wurden anschließend die bereits

in Kapitel 2.2 vorgestellten Artefakte wieder aufgenommen und einer Strukturanalyse

unterzogen. Dabei wurde analysiert mit welcher Art Hierarchie sie üblicherweise struk-

turiert werden und unter welchen Voraussetzungen die Abhängigkeitsanalyse

durchgeführt werden kann. Um diese theoretischen Ausführungen zusätzlich im Kon-

text der Entwicklung eines technischen Systems zu verifizieren wurde eine Studie

durchgeführt, die im Folgenden Kapitel 5.3 beschrieben ist.

Darüber hinaus wurde in Kapitel 5.2.2 die Granularität im Kontext der durchgängigen

Nachverfolgbarkeit betrachtet. Hintergrund dieser Betrachtung war, dass der Auf-

wand bei der Erfassung von Tracelinks maßgeblich von der Granularität der model-

lierten Tracelinks abhängt. Diese hängt wiederum u. a. von dem Verwendungszweck

der Tracelinks ab, der in den frühen Phasen der Systementwicklung meist noch nicht

final definiert ist. Eine Methode zur effizienten Modellierung von Tracelinks sollte somit

die Wahl der Granularität dem Nutzer überlassen, um zunächst eine niedrige Gra-

nularitätsstufe und zu einem späteren Zeitpunkt eine bedarfsgerechte Verfeinerung

in eine höhere Granularitätsstufe zu ermöglichen:

Methoden zur effizienten Modellierung von Tracelinks

108

Anforderung 1: Die Granularität der Tracelinks muss während der Erfassung frei

wählbar sein.

5.3 EVALUATION DER HYPOTHESE 1* IM KONTEXT DER SYSTEMENTWICKLUNG

In Kapitel 5.2.1 wurde durch die Analyse der Eigenschaften unterschiedlicher Arten

von Hierarchien sowie deren Zuordnung zu den Artefakten der Systementwicklung

die Hypothese 1* abgeleitet, die für die später vorgestellte Methode EcoTracing es-

sentiell ist. Um die Anwendbarkeit der Hypothese im Kontext der Systementwicklung

abzusichern, wurde eine Studie mit 17 Probanden durchgeführt und die zugehörige

Nullhypothese überprüft. Sie lautet:

Weist ein Element in B eine Abhängigkeit zu einem Element in A auf, so darf

keines seiner Elternelemente eine Abhängigkeit zu dem Element in A bzw.

(soweit vorhanden) seinen Elternelementen aufweisen.

Der Aufbau und die Durchführung der Studie werden im folgenden Kapitel 5.3.1 vor-

gestellt. Die Beschreibung der Auswertung und Diskussion der Ergebnisse sind im Kapi-

tel 5.3.2 zu finden.

5.3.1 AUFBAU UND DURCHFÜHRUNG DER STUDIE

Um die theoretisch hergeleitete Hypothese empirisch im Kontext der Systementwick-

lung überprüfen zu können und damit die Nullhypothese zu falsifizieren, ist es not-

wendig, anhand von Beispielartefakten Abhängigkeitsuntersuchungen getrennt

voneinander auf einer niedrigen und einer hohen hierarchischen Ebene durchzufüh-

ren. Anschließend wird analysiert, ob sich Widersprüche zwischen den Tracelinks die-

ser Ebenen ergeben. Ein Widerspruch (der die Nullhypothese stützt) liegt vor, wenn

auf niedriger hierarchischer Ebene ein Tracelink zwischen zwei Elementen modelliert

wurde, deren Elternelemente aber keinen Tracelink zueinander aufweisen.

Der Aufbau der Studie sah vor, dass Probanden anhand mehrerer Beispiele manuelle

Abhängigkeitsuntersuchungen durchführen. Die gewählten Beispielartefakte waren

Funktionshierarchien und Produktstrukturen (strukturiert als kompositionelle Inklusions-

hierarchien), die über eine Gesamtfunktions- bzw. Baugruppenebene und eine Teil-

funktions- bzw. Bauteilebene verfügten (siehe Anhang A). Diese Abstraktionsebenen

wurden getrennt voneinander bearbeitet und zudem die hierarchischen Zusammen-

hänge zwischen den Ebenen (also welche Teilfunktionen zu welcher Gesamtfunktion

und welche Bauteile zu welcher Baugruppe gehören) bei der Bearbeitung der Auf-

gabenstellung nicht dargestellt, um eine unabhängige Bewertung der Elemente-

kombinationen zu erreichen.

Methoden zur effizienten Modellierung von Tracelinks

109

Bei der Auswertung wurde nach Abschluss der Modellierung überprüft, ob die jewei-

ligen Elternelemente derjenigen Elemente, die über einen Tracelink verknüpft wur-

den, ebenfalls über einen modellierten Tracelink verfügen (siehe Abbildung 44). Sollte

dies nicht der Fall sein, wurde der Widerspruch, der die Nullhypothese stützt, erfasst

und gesondert mit dem Probanden diskutiert, um die Gründe für die Entstehung des

Widerspruchs zu erörtern.

Abbildung 44: Bei der Auswertung wird überprüft, ob auf höchster hierarchischer Ebene ein

Tracelink vorhanden ist (dargestellt durch die graue gestrichelte Linie), wenn

deren Kinderelemente einen Tracelink aufweisen (dargestellt durch die rote

durchgängige Linie). Ist dem nicht so, wird ein Widerspruch registriert.

Zum Zweck der Erfassung von Entscheidungen bzgl. der Existenz von Abhängigkeiten

zwischen den Elementen der Artefakte wurden Excel-Matrizen verwendet (siehe Ab-

bildung 45). Die Visualisierung der Systeme und Baugruppen bzw. Bauteile

erfolgte

dabei in den Zeilen links der Matrix. Die Funktionen wurden, entgegen der üblichen

Darstellung in Matrizen, bei der die Beschriftungen der Spalten um 45° oder 90° ge-

dreht werden, ebenfalls waagerecht angeordnet, um eine gute Lesbarkeit zu ge-

währleisten. Um trotzdem eine eindeutige Zuordnung der Funktionen zu der gemein-

samen Schnittzelle mit dem Produktstruktur-Element zu erreichen, wurden beide Ele-

mente bei Auswahl der Zelle gelb hinterlegt (siehe Abbildung 45).

Die Navigation zwischen den Zellen der Matrix und damit zwischen den Elementen

der Artefakte erfolgte mit den Pfeiltasten: „Pfeil nach rechts“  und „Pfeil nach links“

. Bei Erreichen des rechten Rands der Matrix sprang die ausgewählte Zelle automa-

tisch, durch Betätigen der Taste „Pfeil nach rechts“, in die erste Zelle der darauffol-

genden Zeile. Die Probanden wurden angewiesen nur diese Tasten und nicht die

Maus zu nutzen, sodass (abgesehen von nachträglichen Korrekturen) überwiegend

von der gleichen Bearbeitungsreihenfolge der unterschiedlichen Probanden ausge-

gangen werden kann.

In Abhängigkeit, ob die Analyse auf hoher oder niedriger hierarchischer Ebene der Arte-

fakte durchgeführt wird, werden links der Matrix entweder die Systeme und Baugruppen

oder die Bauteile dargestellt.

Methoden zur effizienten Modellierung von Tracelinks

110

Abbildung 45: Beispieldarstellung einer in der Studie verwendeten Abhängigkeitsmatrix

Die Studie wurde mit insgesamt 17 Probanden über einen Zeitraum von zwei Wochen

am Produktionstechnischen Zentrum in Berlin durchgeführt. Bei den Probanden han-

delte es sich um Ingenieure bzw. angehende Ingenieure im Bachelor- oder Master-

Studiengang des Fraunhofer IPK bzw. des Fachgebiets Industrielle Informationstech-

nik der Technischen Universität Berlin.

Zu Beginn der Studie erhielten die Probanden eine textuelle Aufgabenbeschreibung,

in der die Grundlagen der Abhängigkeitsanalyse und die zuvor beschriebene Funkti-

onsweise der matrixbasierten Tracelinkerfassung erläutert wurden (siehe Anhang A).

Im Anschluss konnte die Funktionsweise anhand eines Einführungsbeispiels getestet

und sich mit der Aufgabenstellung vertraut gemacht werden. Als Beispiel wurde ein

Haus verwendet, da ein Vorwissen über dessen „Baugruppen“ (Räume) und deren

Funktionen vorausgesetzt werden konnte.

Bei den gewählten hierarchischen Artefakten unterschiedlicher Komplexität, die den

Inhalt der eigentlichen Aufgabenstellung darstellten, handelte es sich um die Funkti-

onshierarchien und Produktstrukturen von einem Kaffeevollautomaten und einem

Fahrrad. Die Beispiele wurden vom Autor dieser Arbeit entwickelt und entsprechend

seiner Vorstellungen strukturiert. Da hinsichtlich des Aufbaus von Funktionsstrukturen

und der Gruppierung von Bauteilen zu Baugruppen bzw. Systemen keine eindeutig

„richtige“ Strukturierung existiert, wurde den Probanden vor Bearbeitung der jeweili-

gen Aufgabenstellung eine Beschreibung der Beispiele zur Verfügung gestellt. Diese

sollte ein gewisses Mindestverständnis über den Aufbau und die Funktionsweise si-

cherstellen, indem die Baugruppen und Bauteile anhand von Abbildungen darge-

stellt und zudem deren jeweilige Funktionen textuell beschrieben wurden.

Die Produktstruktur des Kaffeevollautomats enthielt insgesamt 8 Baugruppen bzw.

Systeme auf höchster hierarchischer Ebene und 32 Bauteile. Die Baugruppe „Auf-

fangeinheit“ ist in Abbildung 46 beispielhaft mit ihren Bauteilen und ihrer Orientierung

im Kontext des Kaffeevollautomaten schematisch dargestellt.

Methoden zur effizienten Modellierung von Tracelinks

111

Abbildung 46: Schematische Darstellung des Kaffeevollautomaten (links: Übersicht, rechts:

Darstellung der Baugruppe Auffangeinheit mit beschrifteten Einzelteilen)

Die Funktionsstruktur enthielt sieben Funktionen auf höchster hierarchischer Ebene,

die in insgesamt 17 Teilfunktionen zerlegt wurden. Eine Übersicht aller Bauteile inkl. vi-

sueller Darstellung sowie der vollständigen Funktionshierarchie ist Anhang A zu ent-

nehmen.

Im Fall des Fahrrad-Beispiels beinhaltete die Produktstruktur acht Baugruppen und

Systeme auf höchster hierarchischer Ebene, die aus 26 Bauteilen aufgebaut waren.

Das Fahrrad als Übersichtsabbildung sowie das Antriebssystem sind in Abbildung 47

schematisch dargestellt.

Abbildung 47: Schematische Darstellung des Fahrrads (links: Übersicht, rechts: Darstellung

der Antriebssystems mit beschrifteten Einzelteilen)

Die zugehörige Funktionsstruktur beinhaltete vier Funktionen auf höchster hierarchi-

scher Ebene und 11 Funktionen auf niedrigster hierarchischer Ebene. Eine Übersicht

Methoden zur effizienten Modellierung von Tracelinks

112

aller Bauteile inkl. visueller Darstellung sowie der vollständigen Funktionshierarchie ist

in Anhang A zu finden.

Bei der Bearbeitung beider Beispiele wurden die beiden Granularitätsebenen (Bau-

gruppen «» Gesamtfunktionen und Bauteile «» Teilfunktionen) nacheinander durch

die Probanden analysiert. Dabei wurden alle Elementekombinationen durch Bear-

beitung aller Zellen der Matrix überprüft und die Entscheidungen für Existenz bzw.

Nicht-Existenz einer Abhängigkeit durch eine „1“ bzw. „0“ in der jeweiligen Zelle do-

kumentiert. Um bei der späteren Auswertung eventuelle Lerneffekte ausschließen zu

können, wurde sowohl die Bearbeitungsreihenfolge der Beispiele als auch die der

beiden Granularitätsebenen über die Probanden alterniert.

Im Anschluss an die vollständige Bearbeitung der Beispiele wurden die Matrizen hin-

sichtlich der vorkommenden Widersprüche zwischen den Abstraktionsebenen analy-

siert und diese mit den Probanden diskutiert. Ziel dieser Diskussion war es, den Grund

für die Entscheidungen, einen Tracelink auf niedriger hierarchischer Ebene, aber kei-

nen zwischen deren Elternelementen auf hoher hierarchischer Ebene zu modellieren,

zu verstehen. Dabei war insbesondere die Kategorisierung der Widersprüche von In-

teresse, um eine Einordnung hinsichtlich der Hypothese zu ermöglichen.

Die Eigenschaften der Studie sind noch einmal zusammenfassend in Tabelle 12 dar-

gestellt.

Aufgaben-

stellung

Identifikation von Abhängigkeiten und manuelle Modellierung von

Tracelinks auf zwei Granularitätsebenen für drei Beispiele. Es handelt sich

dabei um eine realistische Aufgabenstellung, die an industrielle Aufga-

benstellungen angelehnt ist, sich jedoch in Ausprägung der Artefakte hin-

sichtlich Umfang und Komplexität unterscheidet

Analyseeinheit

Getroffene Entscheidungen auf beiden Granularitätsebenen

Analyse-

methode

Überprüfung, ob für alle Elemente der niedrigsten hierarchischen Ebene

der Produktstruktur, die einen Tracelink zu einer Teilfunktion der niedrigsten

hierarchischen Ebene der Funktionshierarchie haben, ebenfalls Tracelinks

zwischen deren Elternelementen der höchsten hierarchischen Ebene vor-

handen sind.

Methode zur

Datenerfassung

Direkte Erfassung der Entscheidungen der Probanden in den Matrizen; In-

terview der Probanden, um die Gründe für Entscheidungen zu erfassen

Anzahl der Teil-

nehmer

Charakterisie-

rung der Teil-

nehmer

Studentische Hilfskräfte und wissenschaftliche Mitarbeiter aus dem Bereich

Virtuelle Produktentstehung des Fraunhofer IPK und dem Fachgebiet In-

dustrielle Informationstechnik der Technischen Universität Berlin; Grund-

sätzliche Kenntnisse über Artefakte, deren Entwicklung und Abhängigkei-

ten zwischen diesen vorhanden

Methoden zur effizienten Modellierung von Tracelinks

113

Untersuchungs-

objekt

Zwei Artefakte eines Hauses (Einführungsbeispiel):

- Funktionshierarchie mit 10 Funktionen auf zwei Hierarchieebenen

- Produktstruktur mit 12 Baugruppen und Bauteilen auf zwei Hierar-

chieebenen

Zwei Artefakte eines Kaffeevollautomaten:

- Funktionshierarchie mit 21 Funktionen auf zwei Hierarchieebenen

- Produktstruktur mit 51 Baugruppen und Bauteilen auf zwei Hierar-

chieebenen

Zwei Artefakte eines Fahrrads

- Funktionshierarchie mit 15 Funktionen auf zwei Hierarchieebenen

- Produktstruktur mit 40 Baugruppen und Bauteilen auf zwei Hierar-

chieebenen

Tabelle 12: Eigenschaften der Studie zur Überprüfung der Hypothese 1*

5.3.2 AUSWERTUNG UND DISKUSSION DER ERGEBNISSE

Die Ergebnisse der einzelnen Probanden sind für die drei Beispiele Haus, Kaffeevollau-

tomat und Fahrrad in Tabelle 13 zusammengefasst. Für das Einführungsbeispiel des

Hauses bewegt sich die Anzahl an Widersprüchen zwischen 0 und 2, was bezogen

auf die Gesamtzahl möglicher Widersprüche Werten von 0 % bis 10 % entspricht.

Beim Kaffeevollautomaten liegt die Anzahl der Widersprüche zwischen 2 und 10 bzw.

4 % und 18 %. Beim Fahrrad ist die Anzahl der Widersprüche mit 0 bis 7 geringer als

beim Kaffeevollautomaten. Prozentual gesehen liegt das Fahrrad-Beispiel zwischen

0 % und 22%, wobei der Maximalwert damit sogar höher ist, als beim Kaffeevollauto-

mat-Beispiel.

Bei der Betrachtung der Mittelwerte der Widersprüche fällt auf, dass das Haus- und

das Fahrrad-Beispiel mit 4,7 % und 5 % in etwa auf einem Niveau liegen, während der

Mittelwert des Kaffeevollautomaten mit 9 % fast doppelt so hoch ist. Damit wird die

Nullhypothese im Haus-Beispiel in 95,3 %, im Fahrrad-Beispiel in 95 % und im Kaffee-

vollautomaten-Beispiel in 91 % der Fälle falsifiziert. In der überwiegenden Anzahl der

Fälle weisen die Elternelemente somit einen Tracelink auf, wenn deren Kinderelemen-

te ebenfalls einen aufweisen. Dabei war ein Wert von 100 % aufgrund der nicht ein-

deutigen Strukturierung der Beispielartefakte und des subjektiv unterschiedlichen

Produktverständnisses der Probanden nicht zu erwarten.

Allerdings zeigt sich bei näherer Betrachtung, dass eine Korrelation zwischen dem

Mittelwert der Selbsteinschätzung

bzgl. des Produktverständnisses der Probanden

Die Selbsteinschätzung ist ein Wert zwischen 0 (geringe Kenntnis) und 10 (umfassende

Kenntnis), mit dem sich die Probanden selbst hinsichtlich ihrer Kenntnis der jeweiligen Bei-

spiele bewertet haben.

Methoden zur effizienten Modellierung von Tracelinks

114

und dem Mittelwert der genormten Anzahl an Widersprüchen

besteht, die mit ei-

nem Korrelationskoeffizienten von -0,98 bestimmt werden kann. Das heißt, es besteht

ein Zusammenhang zwischen der Kenntnis der Beispiele und der Anzahl an Wider-

sprüchen, die sich bei der Abhängigkeitsanalyse durch die Bewertung der Proban-

den ergeben: je besser das Beispielprodukt bekannt ist, desto weniger Widersprüche

ergeben sich zwischen den Bearbeitungsebenen. In Abbildung 48 sind die Werte der

Selbsteinschätzung sowie die Kehrwerte der genormten Anzahl an Widersprüchen

über den drei Beispielprodukten dargestellt.

Haus

Kaffeevollautomat

Fahrrad

Wider-

sprüche

(Anzahl)

Wider-

sprüche

(Prozent)

Wider-

sprüche

(Anzahl)

Wider-

sprüche

(Prozent)

Wider-

sprüche

(Anzahl)

Wider-

sprüche

(Prozent)

Proband 1

5,0 %

11,0 %

13,0 %

Proband 2

5,0 %

14,0 %

6,0 %

Proband 3

0,0 %

7,0 %

6,0 %

Proband 4

0,0 %

7,0 %

0,0 %

Proband 5

10,0 %

18,0 %

16,0 %

Proband 6

10,0 %

5,0 %

0,0 %

Proband 7

5,0 %

16,0 %

0,0 %

Proband 8

5,0 %

7,0 %

0,0 %

Proband 9

5,0 %

3,0 %

Proband 10

0,0 %

4,0 %

0,0 %

Proband 11

10,0 %

11,0 %

0,0 %

Proband 12

5,0 %

4,0 %

0,0 %

Proband 13

5,0 %

7,0 %

13,0 %

Proband 14

5,0 %

9,0 %

0,0 %

Proband 15

5,0 %

11,0 %

0,0 %

Proband 16

5,0 %

12,0 %

6,0 %

Proband 17

0,0 %

11,0 %

22,0 %

Mittelwert

0,94

4,7 %

5,24

9,0 %

1,59

5,0 %

Summe

Tabelle 13: Ergebnis der Studie zur Überprüfung der Hypothese 1* (Erläuterung, was als

Widerspruch gezählt wird, in Abbildung 44)

Diese Erkenntnis wird auch durch die Nachbesprechungen, in denen die Widersprü-

che diskutiert wurden, bestätigt. Die Widersprüche ergaben sich in der Mehrzahl der

Fälle dadurch, dass den Probanden die Baugruppen mit ihren Bauteilen oder die

Funktionsstrukturen nicht ausreichend bekannt waren. Im Folgenden wird daher für

Dabei wird die Anzahl an Widersprüchen auf die maximal mögliche Anzahl an Widersprü-

chen bezogen, um vergleichbare Werte zu erlangen.

Da es sich um eine negative Korrelation handelt wurde für die Darstellung der Kehrwert

gewählt, um für eine eingängigere Darstellung einen parallelen Verlauf der Werte zu errei-

chen.

Methoden zur effizienten Modellierung von Tracelinks

115

die beiden Beispielprodukte Fahrrad und Kaffeevollautomat näher auf einige häufig

auftretende Widersprüche eingegangen und deren Entstehung diskutiert.

Abbildung 48: Korrelation zwischen der Selbsteinschätzung und der Anzahl der Widersprüche

In Tabelle 14 sind die kumulierten Widersprüche, die bei der Analyse des Fahrrad-

Beispiels aufgetreten sind, in Bezug zur Elementekombination, bei der sie aufgetreten

sind, dargestellt. Dabei fallen insbesondere die vier Kombinationen „Antriebseinheit /

Variable Übersetzung realisieren“, „Vorderrad / Bremsen realisieren“, „Vorderrad /

Lenken ermöglichen“ sowie „Hinterrad / Lenken ermöglichen“ mit jeweils drei bis vier

Nennungen auf. Der Widerspruch, der bei der ersten Kombination aufgetreten ist,

konnte in den Nachbesprechungen bei allen Fällen auf die unerwartete Strukturie-

rung der Baugruppen zurückgeführt werden, die durch den Autor dieser Arbeit vor-

genommen wurde. Dabei wurde die Zahnkranzkassette, die sowohl eine Teilfunktion

bei der Realisierung des Antriebs als auch bei der variablen Übersetzung übernimmt,

der Baugruppe Antriebseinheit zugeordnet. Bei der Analyse auf Baugruppenebene

war diese Zuordnung den Probanden nicht bewusst, weshalb die Antriebseinheit

nicht mit der Funktion „Variable Übersetzung realisieren“ in Verbindung gebracht

wurde. Hätten die Probanden das Beispiel selber entwickelt und somit selber über die

Strukturierung des Produkts entschieden, oder wären die Bestandteile der Baugruppe

einsehbar gewesen, wäre dieser Widerspruch laut Aussage der Probanden nicht

aufgetreten.

Kaffeevollautomat Fahrrad Haus

1 / genormte Anzahl Widersprüche

Selbsteinschätzung

Korrelation zwischen Selbsteinschätzung & Anzahl der Widersprüche

Selbsteinschätzung 1/(genormte Anzahl Widersprüche)

Methoden zur effizienten Modellierung von Tracelinks

116

Antrieb realisieren

Bremsen realisieren

Lenken ermöglichen

Variable Übersetzung realisieren

Rahmen

Lenkung

Antriebseinheit

Schaltung

Bremssystem

Sitzeinheit

Vorderrad

Hinterrad

Tabelle 14: Kumulierte Widersprüche des Fahrrad-Beispiels

Die anderen drei Widersprüche, in die die Baugruppen Vorder- und Hinterrad invol-

viert sind, ergeben sich hingegen nicht aus der fehlenden Kenntnis des Beispiels. Hier

änderte sich vielmehr das Verständnis der Probanden, wie ein Bauteil zu der Erfüllung

einer Funktion beiträgt, während der Studie. Während vorher auf der abstrakten Be-

wertungsebene nur Abhängigkeiten zwischen Funktionen und ihren tatsächlichen

Funktionsträger dokumentiert wurden, zeigte sich bei den Rädern eine Verschiebung

hin zu einem Kraftflussdenken. Bei dieser Betrachtungsweise sind dann bspw. bei der

Funktion „Bremsen ermöglichen“ nicht mehr nur das eigentliche Bremssystem, son-

dern auch die Nabe, die Speichen, die Felge und die Reifen beteiligt, da sie zur

Übertragung der Bremskräfte beitragen.

Tabelle 15 beinhaltet die aufgetretenen Widersprüche des Kaffeevollautomaten-

Beispiels. Der am häufigsten aufgetretene Widerspruch ist der zwischen der Elemen-

tekombination „Wasserbehälter / Benutzer warnen“. Er liegt darin begründet, dass

ein Wasserstandssensor in der Baugruppe „Wasserbehälter“ integriert ist, den ca.

80 % der Probanden nicht dort, sondern eher im elektrischen System vermutet hätten.

Gleiches gilt für die Widersprüche mit der Funktion „Umwelteinflüsse fernhalten“ in

Kombination mit den Baugruppen „Bohnenspeicher“, „Wasserbehälter“, „Mahlein-

heit“ und „Brüheinheit“, die entweder über einen Deckel verfügen oder über ein

Gehäuse, welche bei der Analyse der Baugruppen auf Abhängigkeiten vergessen

wurden. Grund dafür war, dass die Probanden die Realisierung dieser Funktion allein

beim Gehäuse gesehen und somit auf abstrakter Ebene nicht weiter berücksichtigt

haben.

Bei den beiden Elementekombinationen „Mahleinheit / Kaffee zubereiten“ und „Flu-

idsystem / Kaffee zubereiten“ ist hingegen nicht die fehlende Kenntnis der Produkt-

struktur sondern der Funktionshierarchie ausschlaggebend für die Entstehung der Wi-

dersprüche. Bei der Nachbesprechung stellte sich hier heraus, dass die Probanden

eine sehr unterschiedliche Vorstellung von der Funktion „Kaffee zubereiten“ hatten.

Während der eigentliche Beispielaufbau vorsah, dass alle Teilfunktionen ab „Drücken

Methoden zur effizienten Modellierung von Tracelinks

117

des Kaffeebezugsknopfes“ beinhaltet sind („Bohnen mahlen“, „Kaffeepulver verdich-

ten“ usw.), verstanden viele der Probanden lediglich das Versetzen des Kaffeepul-

vers mit Wasser unter dieser Funktion.

Bohnen aufbewahren

Umwelteinflüsse fernhalten

Abfall sammeln

Frischwasser bereitstellen

Kaffee zubereiten

Zubereitung steuern

Benutzer warnen

Gehäuse

Bohnenspeicher

Auffangeinheit

Wasserbehälter

Mahleinheit

Brüheinheit

Fluidsystem

Elektrisches System

Tabelle 15: Kumulierte Widersprüche des Kaffeevollautomaten-Beispiels

Wie bereits erwähnt wurde die Hypothese 1* im Rahmen der Studie in 95,3 % (Haus-

Beispiel), 95 % (Kaffeevollautomaten-Beispiel) und 91 % der Fälle (Fahrrad-Beispiel)

bestätigt. In den verbleibenden 4,7 % bis 9 % der Fälle, in denen ein Widerspruch zur

Hypothese und somit eine Bestätigung der Nullhypothese auftritt, können zwei grund-

sätzliche Arten unterschieden werden: solche, die sich aus der nicht ausreichenden

Kenntnis der in den Beispielprodukten verwendeten Funktions- und Produktstrukturen

ergeben und solche, die auf fälschlicherweise modellierten Tracelinks basieren, bei

denen eigentlich keine Abhängigkeit vorliegt (wenn z. B. der Kraftfluss als Bewer-

tungsgrundlage angewendet wird). Es trat kein Fall auf, welcher der anfangs formu-

lierten Hypothese 1* tatsächlich widerspricht.

Die Hypothese 1* kann somit für die Entwicklung einer Methode zur effizienten Model-

lierung von Tracelinks verwendet werden. Entgegen der Ausführungen in Kapi-

tel 5.2.1.1 ist es jedoch für alle Hierarchiearten notwendig, dass die Anwender der

Methode über umfassende Kenntnisse der zu analysierenden Artefakte verfügen. Für

die Erfüllung dieser Voraussetzung spricht im industriellen Umfeld, dass sich die Struk-

turierung der Artefakte nicht wie in der Studie an den Vorstellungen einer Person ori-

entiert, sondern an festen Regeln und Vereinbarungen, die den Entwicklern bekannt

sind. Zusätzlich wird die Methode nicht durch unbeteiligte Personen, sondern durch

Experten angewendet, die umfassenden Kenntnisse der Systeme, deren Strukturie-

rung sowie deren Funktionen haben.

Es lassen sich somit zwei weitere Anforderungen für die Umsetzung der Methode

EcoTracing formulieren:

Methoden zur effizienten Modellierung von Tracelinks

118

Anforderung 2: Eine Methode, die die transitiven Eigenschaften von Inklusionshie-

rarchien zur effizienten Modellierung von Tracelinks nutzt, kann

nur von Anwendern mit umfassenden Kenntnissen der zu analy-

sierenden Artefakte genutzt werden.

Anforderung 3: Eine Methode, die die transitiven Eigenschaften von Inklusions-

hierarchien zur effizienten Modellierung von Tracelinks nutzt, muss

so realisiert werden, dass sich die Anwender jederzeit über den

Kontext (Identifikation der Eltern- und Kinderelemente) eines

Elements informieren können.

5.4 ECOTRACING – METHODE ZUR EFFIZIENTEN MODELLIERUNG VON TRACELINKS

Die im Folgenden beschriebene Methode EcoTracing basiert auf der in Kapitel 5.3

evaluierten Hypothese 1*. Sie nutzt den hierarchischen Aufbau der im Systems Engi-

neering verwendeten Artefakte, um während der Erfassung von Tracelinks Entschei-

dungen über Abhängigkeiten eines betrachteten Elternelements auf seine Kin-

derelemente zu übertragen. Ziel ist es dabei die Anzahl der notwendigen Entschei-

dungen zu reduzieren.

Die Methode EcoTracing wurde durch den Autor dieser Arbeit entwickelt und im

Rahmen der Studienarbeit von Michel Bornath prototypisch implementiert [Bornath

2011a]. Die Ergebnisse wurden auf der International Conference on Engineering De-

sign vorgestellt [Stark und Figge 2011] und in [Beier et al. 2011] sowie [Königs et al.

2012] veröffentlicht.

5.4.1 FUNKTIONSPRINZIP DER METHODE ECOTRACING

Bei der Methode EcoTracing handelt es sich um einen Top-Down-Ansatz, bei dem

die zu untersuchenden Artefakte ausgehend von hohen hierarchischen Ebenen ana-

lysiert werden. Die Detaillierungsstufe, auf der die Elemente auf Abhängigkeiten un-

tersucht werden, wird schrittweise erhöht, bis die benötigte Granularität der

Tracelinks erreicht ist. Dies bringt zum einen den bereits erwähnten Vorteil mit sich,

dass bereits auf hoher hierarchischer Ebene Entscheidungen über Abhängigkeiten

getroffen und somit der Aufwand zur Erfassung von Tracelinks reduziert werden kann.

Zum anderen ermöglicht dieser Ansatz eine Vorgehensweise, wie sie in Kapitel 5.2.4

als Anforderung 1 formuliert wurde: Tracelinks können zunächst auf einer groben

Granularitätsstufe und erst bei Bedarf in einzelnen Teilbereichen der Artefakte detail-

lierter modelliert werden.

Methoden zur effizienten Modellierung von Tracelinks

119

Dabei nutzt die Methode EcoTracing die transitiven Eigenschaften von Inklusionshie-

rarchien, um den Aufwand bei der Erfassung von Tracelinks zu reduzieren.

Abbildung 49 stellt diese Vorgehensweise am abstrakten Beispiel einer Anforderungs-

spezifikation und einer Funktionshierarchie dar. Ausgehend von Anforderung R1 wird

überprüft, ob zur Funktion F2 eine Abhängigkeit besteht. Da dies nicht der Fall ist wird

kein Tracelink modelliert (dargestellt durch das Kreuz in Abbildung 49, linke Seite). Ba-

sierend auf dieser Entscheidung wird die hierarchische Strukturierung der Funktions-

hierarchie ausgenutzt, um diese Festlegung auch auf F2.1 sowie F2.2 zu übertragen

(dargestellt durch die Kreuze in Abbildung 49, rechte Seite). Die Überprüfung der

Kombinationen mit R1 können eingespart werden.

Abbildung 49: Funktionsprinzip der Methode EcoTracing

5.4.2 ALGORITHMUS DER METHODE ECOTRACING

Der Top-Down Algorithmus der Methode EcoTracing wird im Folgenden anhand der

beiden generischen Artefakte A und B erläutert. Ausgehend von Artefakt A wird zu-

nächst das Element A1 in Kombination mit den Elementen der höchsten hierarchi-

schen Ebene des Artefakts B (B1, B2 und B3) auf Abhängigkeiten untersucht (darge-

stellt durch Fragezeichen in Abbildung 50).

Abbildung 50: Untersuchung der Artefakte auf Abhängigkeiten zwischen den Elementen

Werden zwischen A1 und einem der Elemente Bx keine Abhängigkeiten festgestellt,

so wird dies jeweils durch Markierung der Elementkombination mit einem „X“ doku-

Methoden zur effizienten Modellierung von Tracelinks

120

mentiert. Wie in Kapitel 5.4.1 beschrieben, können aus dieser Festlegung bereits auf

dieser Betrachtungsebene die Abhängigkeit zwischen A1 und einem der Kinderele-

mente von B1 ausgeschlossen werden und brauchen deshalb nicht mehr analysiert

werden (dargestellt durch Kreuze in Abbildung 51). Je nach Tiefe der Hierarchie kön-

nen hierdurch eine große Anzahl von Kombinationen noch vor ihrer Betrachtung

ausgeschlossen werden.

Abbildung 51: Markierung von Elementkombinationen bei nicht vorhandener Abhängigkeit

Wird zwischen den betrachteten Elementen eine Abhängigkeit festgestellt, wie in

Abbildung 52 durch den Haken auf der Verbindungslinie zwischen A1 und B3 visuali-

siert, so wird ein Tracelink zwischen diesen modelliert. Zeitgleich werden alle Kombi-

nationen von A1 mit den direkten Kinderelementen von B3 für eine spätere Untersu-

chung vorgemerkt (dargestellt durch eine Fahne in Abbildung 52), da die Wahr-

scheinlichkeit, dass mindestens eines der Elemente eine Abhängigkeit zu A1 aufweist,

sehr groß ist. Die Markierung dient dabei dem Zweck, die Erfassung der Tracelinks

abbrechen, zu einem beliebigen späteren Zeitpunkt wieder aufnehmen und die bis-

herige Analyse nachvollziehen zu können. Insgesamt lassen sich mit Hilfe der unter-

schiedlichen Markierungen folgende Zustände von Elementkombinationen unter-

scheiden:

- Elementkombinationen, welche bereits untersucht wurden, aber keine

Abhängigkeit zwischen ihnen festgestellt werden konnte,

- Elementkombinationen, welche noch nicht auf Abhängigkeiten zuei-

nander untersucht wurden und

- Elementkombinationen, bei denen eine Abhängigkeit wahrscheinlich

ist, eine detaillierte Untersuchung jedoch noch aussteht.

Methoden zur effizienten Modellierung von Tracelinks

121

Abbildung 52: Modellierung von Tracelinks und Markierung der Kinder-Elemente für eine

spätere Untersuchung

Sobald ausgehend von A1 alle Kombinationen mit Elementen der höchsten hierar-

chischen Ebene von Artefakt B analysiert wurden, werden zunächst alle Geschwis-

terelemente

von A1 in gleicher Weise untersucht. Erst im nächsten Schritt werden

die tieferen hierarchischen Ebenen der beiden Artefakte auf Abhängigkeiten analy-

siert. Diese Vorgehensweise ermöglicht es dem Anwender, beide Artefakte zunächst

vollständig auf abstraktem Niveau auf Abhängigkeiten zu untersuchen und die Gra-

nularität im Anschluss schrittweise zu erhöhen (wie in Anforderung 1 gefordert). Eine

detaillierte Darstellung des beschriebenen Algorithmus ist in Abbildung 53 zu finden.

Dabei werden die betrachteten Artefakte mit A und B bezeichnet. Die Hierarchie-

ebene wird mit Hilfe des Hierarchie-Indexes AH bzw. BH ausgedrückt, wobei die obers-

te Ebene mit dem Index 1 bezeichnet wird. Elemente, die auf derselben Hierarchie-

ebene liegen (auch Geschwisterelemente genannt) werden mit dem Geschwister-

Index durchnummeriert.

Ergänzend zu diesem Ablauf wurde in der prototypischen Implementierung (siehe

Kapitel 5.4.3) ein weiterer, leicht abgewandelter Algorithmus umgesetzt. Dieser sieht

vor, dass ausgehend von A1 eine Erfassung der Tracelinks direkt bis in die niedrigste

Granularitätsstufe von Artefakt B durchgeführt wird. Diese Vorgehensweise bietet sich

an, wenn ohnehin eine hohe Granularität angestrebt wird, da sich der Anwender auf

die Abhängigkeiten zwischen zwei Elementen und deren Kinderelementen konzent-

rieren kann und der Kontext nicht ständig geändert wird.

Als Geschwisterelemente werden Elemente bezeichnet, die auf einer hierarchischen Ebe-

ne liegen.

Methoden zur effizienten Modellierung von Tracelinks

122

Abbildung 53: Algorithmus der EcoTracing Methode (zunächst Erfassung der Tracelinks auf

hoher hierarchischer Ebene und folgend schrittweise Erhöhung der Granulari-

tät).

Methoden zur effizienten Modellierung von Tracelinks

123

5.4.3 PROTOTYPISCHE IMPLEMENTIERUNG DER METHODE ECOTRACING

Bei der Methode EcoTracing handelt es sich um eine sog. Offline-Methode zur Erfas-

sung von Tracelinks. Ihre Anwendung erfolgt damit separat und nicht während der

Erstellung der Artefakte. Im Vergleich zur manuellen Online-Erfassung liegt der Vorteil

der Offline-Erfassung darin, dass Tracelinks nicht während der Modellierung der Arte-

fakte erfasst werden, sondern im Nachgang strukturiert vorgegangen wird (siehe

Abbildung 54). Zwar wirkt die Online-Erfassung zunächst intuitiver, da die Entwickler

die Tracelinks sofort bei Auftreten einer Abhängigkeit modellieren, allerdings kann

durch diese unstrukturierte Vorgehensweise eine Vollständigkeit der Abhängigkeits-

analyse nicht garantiert werden

Abbildung 54: Vergleich der Online- mit der Offline-Erfassung von Tracelinks: kontinuierliche,

jedoch unvollständige Online-Analyse gegenüber einer vollständigen Offline-

Analyse zu bestimmten Zeitpunkten im Entwicklungsprozess (hier dargestellt:

zum Ende der jeweiligen Phase)

Um EcoTracing als Offline-Methode jedoch auch während der Entwicklung anwen-

den zu können sind zwei Anwendungsfälle zu unterscheiden:

Fall 1: Artefakte haben einen finalen Zustand: Wenn beide zu untersuchenden Arte-

fakte bereits einen finalen Zustand haben und damit nicht mehr bzw. nur noch wenig

bearbeitet werden, kann EcoTracing ohne Einschränkungen zur Abhängigkeitsanaly-

se eingesetzt werden.

Es ist grundsätzlich möglich, EcoTracing als offline-Methode mit der online-Erfassung zu

kombinieren. In diesem Fall würden während der Erstellung der Artefakte online Tracelinks

modelliert und abschließend eine offline-Erfassung durchgeführt, um die Vollständigkeit

garantieren zu können. Bei dieser Analyse können die online erfassten Tracelinks berück-

sichtigt werden, jedoch müssten alle Element-Kombinationen, die keinen Tracelink aufwei-

sen nachträglich hinsichtlich vorhandener Abhängigkeiten analysiert werden.

Methoden zur effizienten Modellierung von Tracelinks

124

Fall 2: Artefakte haben einen Zwischenzustand: Auch wenn eins der beiden oder

beide Artefakte noch keinen finalen Zustand haben, ist die Anwendung der Metho-

de EcoTracing möglich. In diesem Fall sollte der EcoTracing-Algorithmus so konfigu-

riert werden, dass die Abhängigkeitsanalyse Ebenen-weise von abstrakt nach detail-

liert durchgeführt wird (siehe Kapitel 5.4.2, Seite 121). Die Analyse wird dann bis zu ei-

ner beliebigen Granularität durchgeführt, die nur von der bis dahin fertiggestellten

Detaillierungstiefe der Artefakte begrenzt wird. Zu einem späteren Zeitpunkt, wenn

die Artefakte weiterentwickelt und somit ein neuer Zwischenstand erreicht wurde,

kann die Analyse an der gleichen Stelle wieder aufgenommen werden, da allen

Elementekombinationen ein Analyse-Status zugeordnet wird. Grundlegende Voraus-

setzung für die Anwendung von EcoTracing ist jedoch, dass die Artefakte Ebenen-

weise von abstrakt nach detailliert entwickelt werden und sich nach Erstellung der

Elemente keine gravierenden Änderungen mehr ergeben. Sollten doch noch Ände-

rungen auf abstrakter Ebene (bspw. durch Hinzufügen eines Elements) in einem der

Artefakte auftreten, so muss dieses nachträglich in Kombination mit allen Elementen

des anderen Artefakts untersucht werden. Gleiches gilt für ein Elternelement, wenn

dessen Kinderelemente gravierend geändert werden und sich dadurch seine Eigen-

schaften ebenfalls ändern. So müsste bspw. das Modul „Außenspiegelverstellung“ in

einem Verhaltensmodell erneut auf Abhängigkeiten zu anderen Artefakten unter-

sucht werden, wenn dessen Wirkprinzip von manueller auf elektrische Verstellung ge-

ändert und damit viele seiner Systemelemente ausgetauscht werden würden.

Vor dem Hintergrund dieser beiden Anwendungsfälle wurde die prototypische Im-

plementierung der Methode EcoTracing realisiert. Sie wurde als Plug-In in den in Kapi-

tel 3.6.4.3 vorgestellten ModelTracer als Wizard (genannt: EcoTracer), der den An-

wender strukturiert durch den Prozess der Erfassung von Tracelinks führt, integriert.

Das EcoTracing beginnt mit der Auswahl der zu analysierenden Artefakte über zwei

Drop-Down-Menüs (Abbildung 55, Nr. 1). Die so ausgewählten Artefakte werden an-

schließend in einer reduzierten Darstellung visualisiert (Abbildung 55, Nr. 2). Elemente,

die bereits analysiert wurden und deren Abhängigkeit bereits zuvor ausgeschlossen

wurde, werden nicht angezeigt, was die Übersichtlichkeit durch Reduzierung der An-

zahl angezeigter Elemente für den Anwender erhöht. In den so dargestellten Artefak-

ten können im Anschluss die Bereiche, die im Rahmen der Tracelink-Erfassung analy-

siert werden sollen, durch Mehrfachauswahl eingegrenzt werden. Dabei ist es mög-

lich, die Auswahl auf beliebigen Hierarchieebenen zu treffen. Diese Auswahl ermög-

licht es, bspw. nur eine bestimmte Elementekombination und alle ihre Kinderelemen-

te direkt bis in eine hohe Granularität zu untersuchen und Verantwortlichkeiten für

die Verknüpfung bestimmter Artefaktbereiche zu berücksichtigen.

Methoden zur effizienten Modellierung von Tracelinks

125

Abbildung 55: Graphical User Interface (GUI) des EcoTracers

Im Anschluss an die Bereichsauswahl beginnt die Erfassung der Tracelinks. Die aktuell

betrachtete Elementekombination wird grün hervorgehoben (Abbildung 55, Nr. 3).

Um sich dabei den Kontext des betrachteten Elements vergegenwärtigen zu kön-

nen, ist es möglich, die Hierarchiebäume auf- bzw. zuzuklappen

. Für jede der so be-

trachteten Elementekombination hat der Anwender drei Möglichkeiten zur Auswahl:

- „Überspringen“: Es wird aktuell keine Entscheidung für die Kombination getrof-

fen (Abbildung 55, Nr. 4). Dies überträgt sich auch auf deren Kinderelemente,

die in der aktuellen Analysesitzung nicht mehr zur Überprüfung vorgeschlagen

werden.

- „Verwerfen“: Es wird bestätigt, dass keine Abhängigkeit zwischen der aktuel-

len Elementekombination vorhanden ist (Abbildung 55, Nr. 5). Somit wird kein

Tracelink modelliert. Diese Aussage überträgt sich auch auf deren Kinderele-

mente, die weder in der aktuellen Analysesitzung, noch zu einem späteren

Zeitpunkt überprüft werden müssen.

Diese Funktionalität adressiert die Anforderung 3 aus Kapitel 5.3.2, in der gefordert wird,

dass man jederzeit Kinder- und Elternelemente visualisieren können muss, um bspw. ab-

schätzen zu können, welche Bauteile in einer Baugruppe enthalten sind.

Methoden zur effizienten Modellierung von Tracelinks

126

- „Bestätigen“: Es wird eine Abhängigkeit zwischen der hervorgehobenen Ele-

mentekombination bestätigt und ein Tracelink modelliert (Abbildung 55, Nr. 6).

Zusätzlich besteht die Möglichkeit diesem Tracelink im Feld „Relationsbe-

schreibung“ eine Beschreibung (z. B. den Grund für den Tracelink oder Typ des

Tracelinks) hinzuzufügen. Alle Kinderelemente werden im weiteren Verlauf der

Sitzung zur Analyse vorgeschlagen.

Diese Status werden separat für jede Artefakt-Kombination gespeichert. Die gewähl-

te Datenstruktur entspricht einer Matrix, da so für jedes Elementepaar ein Status ge-

speichert werden kann. Dabei wird für jedes Elementepaar zunächst ein Status „initi-

al“ vergeben, um zu einem späteren Zeitpunkt feststellen zu können, welche Kombi-

nationen bereits vom Anwender analysiert wurden und wo sich der Wiedereinstiegs-

punkt für die Fortsetzung der Analyse befindet. Während für die Funktionalität „Über-

springen“ kein Status vergeben wird, werden „Verworfen“ und „Bestätigt“ den Kom-

binationen zugeordnet. Dabei wird der erstgenannte auch auf die Kinderelemente

übertragen und bei letztgenanntem den jeweiligen Kinderelementen der Status

„möglich“ zugeordnet. Zusätzlich werden die Tracelinks, die durch das Bestätigen ei-

ner Abhängigkeit erstellt werden, in die Datenbank des ModelTracers eingetragen.

Sobald eine der drei Möglichkeiten durch den Anwender gewählt wird, springt der

Algorithmus zur nächsten Elementekombination. Der strukturierte Ablauf der Erfas-

sung erfolgt dabei wie in Kapitel 5.4.2 beschrieben. Dadurch können keine Elemen-

tekombinationen vergessen werden, was im Vergleich zu der manuellen Analyse von

Artefakten ein großer Vorteil ist. Der Fortschritt der Erfassung wird als Verhältnis von

bereits analysierten zu insgesamt zu analysierenden Kombinationen mittels eines Fort-

schrittsbalkens visualisiert. Letztere Zahl ergibt sich dabei aus der Multiplikation der

Anzahl der Elemente der beiden Artefakte (siehe Formel (1) aus Kapitel 5.2.3).

5.4.4 ERMITTLUNG DES AUFWANDS BEI DER ERFASSUNG VON TRACELINKS MIT ECOTRACING

Die Ermittlung der Anzahl notwendiger Entscheidungen mit Hilfe von EcoTracing un-

terscheidet sich von der bei manueller Vorgehensweise (vgl. Kapitel 5.2.3), da nicht

alle Elementekombinationen berücksichtigt werden müssen. Die folgenden Erläute-

rungen gelten für Artefakte mit zwei Hierarchieebenen, das Prinzip ist jedoch auf Ar-

tefakte mit beliebigen Hierarchietiefen übertragbar. Um die Anzahl notwendiger Ent-

scheidungen bei der Anwendung von EcoTracing zu ermitteln, muss zunächst auf der

höheren Hierarchieebene überprüft werden, ob ein Tracelink zwischen einem Ele-

mentepaar vorliegt. Ist dies der Fall, müssen diese und alle Elementekombinationen

ihrer Kinderelemente zur Anzahl notwendiger Entscheidungen addiert werden. Liegt

keine Abhängigkeit vor, ist nur die Entscheidung, für dieses Elementepaar keinen

Methoden zur effizienten Modellierung von Tracelinks

127

Tracelink zu modellieren, notwendig. Für dessen Kinderelemente lautet die automati-

sche Entscheidung, alle Abhängigkeiten auszuschließen.

Ek sei die Anzahl der Entscheidungen für eine Kombination der Elternelemente Aa und

Bb, während pa und qb für die jeweilige Anzahl der Kinderelemente dieser Elternele-

mente (inkl. dem Elternelement selbst) stehen. Die Indizes a und b entsprechen der

Anzahl der Elemente auf oberster Hierarchieebene und laufen von 1 bis r bzw. s (sie-

he Abbildung 56).

Abbildung 56: Notwendige Parameter zur Bestimmung des Aufwands unter Verwendung von

EcoTracing

Die Anzahl notwendiger Entscheidungen mittels EcoTracing EET ergibt sich somit zu:

𝑬𝑬𝑻 = ∑𝑬𝒌

𝒓∙𝒔

𝒌=𝟏

(8)

𝑬𝒌={𝒑𝒂∙𝒒𝒃,(𝑨𝒂,𝑩𝒃)=𝟏

𝟏, (𝑨𝒂,𝑩𝒃)=𝟎

für 𝒂=𝟏…𝒓 und 𝒃=

𝟏…𝒔

(9)

Die Unterscheidung in Formel (9) ist notwendig, da bei Existenz einer Abhängigkeit

der Elternelemente zusätzlich alle Kombinationen der Kinderelemente überprüft wer-

den und somit Entscheidungen getroffen werden müssen. Besteht jedoch keine Ab-

hängigkeit zwischen diesen Elementen, so muss nur bei den Elternelementen die Ent-

scheidung getroffen werden, keinen Tracelink zu modellieren. Alle weiteren Ent-

scheidungen entfallen.

In Abbildung 57 ist ein Beispiel in einer Matrix dargestellt, anhand dessen die Berech-

nung des Aufwands exemplarisch erläutert werden soll. Die modellierten Tracelinks

Methoden zur effizienten Modellierung von Tracelinks

128

auf höchster hierarchischer Ebene zwischen A1 und B1 sowie A2 und B2 sind durch

ein „x“ dargestellt, während zwischen A1 und B2 sowie A2 und B1 keine Abhängigkeit

besteht und daher kein Tracelink modelliert wurde (dargestellt durch ein „-“).

Abbildung 57: Beispiel zur Erläuterung der Ermittlung der Anzahl der Entscheidungen unter

Verwendung von EcoTracing (Elementkombinationen, bei denen eine Ent-

scheidung getroffen werden muss, sind schraffiert dargestellt)

Die Anzahl notwendiger Entscheidungen für den Fall, dass EcoTracing verwendet

wird, beträgt somit:

𝑬𝟏=𝒑𝟏∙𝒒𝟏=𝟓∙𝟑=𝟏𝟓

(10)

𝑬𝟐=𝟏

(11)

𝑬𝟑=𝟏

(12)

𝑬𝟒=𝒑𝟐∙𝒒𝟐=𝟒∙𝟓=𝟐𝟎

(13)

𝑬𝑬𝑻 = ∑𝑬𝒌

𝟒

𝒌=𝟏 =𝟏𝟓+𝟏+𝟏+𝟐𝟎=𝟑𝟕

(14)

Für das vorliegende Beispiel müssen somit unter Anwendung von EcoTracing 37 Ent-

scheidungen getroffen werden.

5.4.5 EVALUATION DER METHODE ECOTRACING

Um die Aufwandsersparnis der Methode EcoTracing zu ermitteln und damit die Wirk-

samkeit der Hypothese 1 zu überprüfen, wurde eine Studie mit mehreren Probanden

durchgeführt. Hypothese 1 zielt auf die Ausnutzung der Eigenschaften von Inklusions-

hierarchien, um Einsparungen bei der Erfassung von Tracelinks zu erreichen (siehe

Kapitel 4.1).

Methoden zur effizienten Modellierung von Tracelinks

129

Der Aufbau und die Durchführung der Studie werden im folgenden Kapitel 5.4.5.1

vorgestellt. Die Beschreibung der Auswertung und Diskussion der Ergebnisse befindet

sich im Kapitel 5.4.5.2.

5.4.5.1 AUFBAU UND DURCHFÜHRUNG DER STUDIE

Zur Überprüfung der Hypothese 1 wurde eine Studie mit 19 Probanden am Produkti-

onstechnischen Zentrum Berlin durchgeführt. Die Teilnehmer waren studentische

Hilfswissenschaftler und wissenschaftliche Mitarbeiter, denen das grundsätzliche

Themengebiet der Abhängigkeiten zwischen unterschiedlichen Artefakten in der Sys-

tementwicklung bekannt war.

Abbildung 58: Übersicht der Artefakte des Fahrradbeispiels

Die im Rahmen der Studie verwendeten drei Artefakte waren das Anforderungsmo-

dell, die Funktionsliste und die Produktstruktur eines Fahrrads, die in Vorbereitung der

Studie erstellt wurden. Während das Anforderungsmodell als subsumtive Inklusionshie-

rarchie strukturiert war, waren die Funktionsliste und die Produktstruktur als kompositi-

onelle Inklusionshierarchie aufgebaut.

Methoden zur effizienten Modellierung von Tracelinks

130

Das Anforderungsmodell beinhaltete 10 Anforderungen und drei Kategorien auf zwei

Hierarchieebenen, die Funktionsliste 20 Funktionen auf zwei Hierarchieebenen und

die Produktstruktur 29 Bauteile und Baugruppen ebenfalls auf zwei Hierarchieebenen.

Eine Übersicht der Artefakte ist in Abbildung 58 abgebildet.

Zu Beginn der Studie erhielten die Probanden eine Einweisung zum Thema Traceabili-

ty und der Funktionsweise der prototypischen Implementierung der Methode Eco-

Tracing, welche im Rahmen der Studie für die Abhängigkeitsanalyse am PC verwen-

det werden sollte. Im Anschluss erhielten sie die Aufgabenstellung, welche aus drei

Teilaufgaben bestand, wobei sich nur die erste auf die Methode EcoTracing bezog

(siehe Anhang B). Bei den anderen beiden handelte es sich um zwei Auswirkungs-

analysen, von denen eine der Evaluierung der Methode TraceEvaluation diente (sie-

he Kapitel 6.3.3). Unter Anwendung des EcoTracing-Algorithmus sollten die Proban-

den die drei Artefakte auf Abhängigkeiten untersuchen und entsprechend Tracelinks

bis zur höchsten Granularitätsstufe modellieren. Das dabei entstehende Traceability-

Modell wurde für jeden Probanden einzeln gespeichert, sodass eine individuelle

Auswertung möglich war. Während der Durchführung der Studie konnten die Pro-

banden Fragen an den Versuchsleiter stellen.

In Tabelle 16 sind die Eigenschaften der Studie in Tabellenform als Steckbrief zusam-

mengefasst.

Analyseeinheit

Anzahl der notwendigen Entscheidungen bei der Analyse der Ar-

tefakte auf Abhängigkeiten unter Verwendung der Methode

EcoTracing im Vergleich zur manuellen Vorgehensweise (vgl. da-

zu Kapitel 5.2.3)

Analysemethoden

Vergleich der Anzahl der Entscheidungen für EcoTracing und für

die manuelle Vorgehensweisen pro Proband

Methode zur

Datenerfassung

Nachträgliche Analyse der Abhängigkeitsmatrizen, die durch das

EcoTracing generiert werden

Aufgabenstellung

Identifikation von Abhängigkeiten und Modellierung von

Tracelinks unter der Verwendung von EcoTracing; realistische

Aufgabenstellung, die an industrielle Aufgabenstellungen ange-

lehnt ist, sich jedoch in Ausprägung der Artefakte hinsichtlich Um-

fang und Komplexität unterscheidet

Durchschnittliche Dauer

der Studie

ø 32 Minuten 10 Sekunden

Anzahl der Teilnehmer

Charakterisierung der

Teilnehmer

Studentische Hilfskräfte und wissenschaftliche Mitarbeiter aus

dem Bereich Virtuelle Produktentstehung des Fraunhofer IPK und

dem Fachgebiet Industrielle Informationstechnik der Technischen

Universität Berlin; Grundsätzliche Kenntnisse über Artefakte, deren

Entwicklung und Abhängigkeiten zwischen diesen vorhanden

Methoden zur effizienten Modellierung von Tracelinks

131

Untersuchungsobjekt

Drei Artefakte eines Fahrrads:

- Anforderungsmodell mit 10 Anforderungen und 3 sortie-

renden Überschriften mit zwei Hierarchieebenen,

- Funktionsliste mit 20 Funktionen auf zwei Hierarchieebe-

nen,

- Produktstruktur mit 29 Bauteilen und Baugruppen auf zwei

Hierarchieebenen.

Tabelle 16: Eigenschaften der Studie zur Überprüfung der Hypothese 1

5.4.5.2 AUSWERTUNG DER STUDIE

Im Anschluss an die Durchführung der Studie wurden die erstellten Traceability-

Modelle nach Excel exportiert (siehe Tabelle 17).

A1.1 Vortrieb

A1.1.1 Hinterradantrieb mittels Fußku...

A1.1.2 Übersetzung mittels Kettenscha...

A1.2 Bremsen

A1.2.1 Verschmutzungsrisiko minimieren

A1.2.2 zuverlässiges Bremsen bei Nässe

A1.2.3 muss mit Handkraft betrieben w...

A1.2.4 geringer Verschleiß von Kompon...

A1.3 sicheres Lenken / Manövrieren

A1.4 geländetaugliche Federung und Üb...

A1.4.1 Unebenheiten im Gelände und im...

A1.4.2 Verschiedene Übersetzungen

A1.5 Beleuchtung vorsehen

F1.1 Vortrieb gewährleisten

F1.1.1 Fußkraft aufnehmen

F1.1.2 Antriebskraft leiten

F1.1.3 Kraft / Moment wandeln

F1.1.4 Rotationsmoment auf Straße übe...

F1.2 Verzögerung realisieren

F1.2.1 Handkraft aufnehmen

F1.2.2 Kraft leiten

F1.2.3 Bremskraft auf Hinterrad / Str...

F1.3 Fahrtrichtung ändern

F1.3.1 Steuersignal aufnehmen

F1.3.2 Richtungsänderung ausführen

F1.4 variable Übersetzung gewährleisten

F1.4.1 Fingerkraft aufnehmen

F1.4.2 Kraft leiten

F1.4.3 Übersetzung wechseln

F1.5 Sichtbarkeit gewährleisten

F1.5.1 unmittelbare Umgebung beleuchten

F1.5.2 Licht reflektieren

F1.6 Federung / Dämpfung

Tabelle 17: Darstellung der durch Proband 1 modellierten Tracelinks für die Artefaktkom-

bination (Anforderungen «» Funktionen)

Die Darstellungsform ist an Multi Domänen Matrizen (MDM) angelehnt, weshalb für

die drei Artefakte Anforderungsmodell, Funktionsliste und Produktstruktur pro Proband

Methoden zur effizienten Modellierung von Tracelinks

132

jeweils drei Matrizen erstellt wurden. Dabei wird jeweils ein Artefakt in den Zeilen und

eins in den Spalten eingetragen und die Existenz eines ungerichteten Tracelinks

durch eine „1“ in deren gemeinsamer Zelle dokumentiert.

Mit Hilfe dieser Matrizen lassen sich unter Berücksichtigung der Berechnungsvorschrif-

ten aus den Kapiteln 5.2.3 und 5.4.4 einige für das Traceability-Modell charakteristi-

sche Größen ableiten. Diese wurden in Form der „Anzahl Entscheidungen“ und der

„Ersparnis“ (im Vergleich zur manuellen Vorgehensweise) pro Proband und Artefakt-

kombination berechnet. Das Ergebnis ist in Tabelle 18 dargestellt.

Bei der Analyse der erfassten Daten fällt auf, dass die Probanden sehr unterschiedli-

che Umfänge an Entscheidungen zu treffen hatten. Die maximale durch Proband 02

getroffene Anzahl betrug 830 und die minimale durch Proband 05 getroffene Anzahl

360. Die anderen 17 Probanden liegen überwiegend, mit der Anzahl der von ihnen

getroffenen Entscheidungen, im Bereich des Mittelwerts von ca. 500 Entscheidungen.

Anzahl Entscheidungen

mit EcoTracing

Ersparnis mit EcoTracing (im Vergleich zur

manuellen Vorgehensweise)

A - F

A - P

F - P

∑

A - F

A - P

F - P

∑

Proband 01

144

197

432

65,0 %

61,8 %

66,0 %

64,5 %

Proband 02

169

319

342

830

35,0 %

15,4 %

41,0 %

31,8 %

Proband 03

215

157

149

521

17,3 %

58,4 %

74,3 %

57,2 %

Proband 04

152

197

199

548

41,5 %

47,7 %

65,7 %

55,0 %

Proband 05

178

360

68,1 %

73,7 %

69,3 %

70,4 %

Proband 06

166

150

191

507

36,2 %

60,2 %

67,1 %

58,3 %

Proband 07

133

288

518

62,7 %

64,7 %

50,3 %

57,4 %

Proband 08

100

214

221

535

61,5 %

43,2 %

61,9 %

56,0 %

Proband 09

110

207

196

513

57,7 %

45,1 %

66,2 %

57,8 %

Proband 10

132

163

389

63,8 %

65,0 %

71,9 %

68,0 %

Proband 11

140

189

420

65,0 %

62,9 %

67,4 %

65,5 %

Proband 12

112

162

365

65,0 %

70,3 %

72,1 %

70,0 %

Proband 13

137

146

199

482

47,3 %

61,3 %

65,7 %

60,4 %

Proband 14

213

196

492

68,1 %

43,5 %

66,2 %

59,6 %

Proband 15

101

124

186

411

61,2 %

67,1 %

67,9 %

66,2 %

Proband 16

129

228

371

728

50,4 %

39,5 %

36,0 %

40,2 %

Proband 17

167

174

421

69,2 %

55,7 %

70,0 %

65,4 %

Proband 18

118

197

410

54,6 %

74,8 %

66,0 %

66,3 %

Proband 19

197

157

230

584

24,2 %

58,4 %

60,3 %

52,0 %

Mittelwerte

121,3

164,9

212,0

498,2

53,4 %

56,2 %

63,4 %

59,1 %

Maximal

215

319

371

830

69,2 %

74,8 %

74,3 %

70,4 %

Minimal

149

360

17,3 %

15,4 %

36,0 %

31,8 %

Tabelle 18: Studienergebnisse für die Anzahl der Entscheidungen und die Ersparnis an Ent-

scheidungen durch Anwendung von EcoTracing pro Proband zwischen Anfor-

derungen (A), Funktionen (F) und Produktelementen (P)

Methoden zur effizienten Modellierung von Tracelinks

133

Es wird deutlich, dass die Modellierung von Tracelinks mit EcoTracing und damit die

Anzahl der zu treffenden Entscheidungen sehr stark von der subjektiven Interpretati-

on der Artefakte durch die Probanden beeinflusst wird. Zur näheren Analyse wurden

daher in Tabelle 19 die modellierten Tracelinks aller 19 Probanden am Beispiel der

Anforderungen und Funktionen aggregiert

. Eine 19 in einer Zelle bedeutet somit,

dass alle Probanden für diese Elementekombination einen Tracelink modelliert ha-

ben. Über die Existenz dieser Abhängigkeit herrschte somit Einigkeit und die Wahr-

scheinlichkeit, dass zwischen dieser Elementekombination tatsächlich ein Tracelink

sinnvoll ist, ist groß. Umgekehrt gilt für die Nicht-Existenz einer Abhängigkeit: hat keiner

der Probanden bei einem Elementepaar einen Tracelink modelliert, ist die Nicht-

Existenz der Abhängigkeit sehr wahrscheinlich (dargestellt durch eine grüne Färbung

der Zelle in Tabelle 19). Eine 9 hingegen bedeutet, dass 9 Probanden für diese Ele-

mentekombination einen Tracelink modelliert haben, jedoch auch 10 Probanden

keine Abhängigkeit zwischen diesen Elementen gesehen haben. Die Existenz einer

Abhängigkeit ist somit nicht sicher (dargestellt durch eine rote Färbung der Zelle in

Tabelle 19). Werte, die zwischen den genannten liegen, werden entsprechend ihrer

Nähe zu 9 in Abstufungen der Farben Grün, Rot und Gelb dargestellt. Unabhängig

von der Studie wurde das Beispielprodukt auch vom Autor dieser Arbeit hinsichtlich

vorhandener Abhängigkeiten untersucht. Tracelinks, die bei dieser Analyse modelliert

wurden, sind in Tabelle 19 durch rote Zahlen dargestellt.

Um die Entscheidungen für oder gegen einen Tracelink und damit die Bewertung, ob

eine Abhängigkeit zwischen Anforderung und Funktion besteht, näher zu betrachten,

werden im Folgenden einige exemplarische Elementekombinationen beschrieben

und deren Eigenschaften diskutiert:

„F1.1 Vortrieb gewährleisten“ | „A1.1 Vortrieb“: Zwischen der Anforderung „A1.1 Vor-

trieb“ und der Funktion „F1.1 Vortrieb gewährleisten“ sowie allen Kinderelementen

der Funktion (F1.1.1 – F1.1.4) wurde durch alle Probanden eine Abhängigkeit identifi-

ziert. Wie der Tabelle 19 zu entnehmen ist, wurde auch durch den Autor an dieser

Stelle ein Tracelink modelliert. Begründet ist dies darin, dass die Funktion und ihre Teil-

funktionen den Vortrieb des Fahrrads adressieren. Hilfreich ist dabei auch die teilwei-

se übereinstimmende Bezeichnung der Elemente. Bei dem Kinderelement der Anfor-

derung „A1.1.2 Übersetzung mittels Kettenschaltung realisieren“ zeigen sich dagegen

große Unterschiede in der Bewertung durch die Probanden. Aus Sicht des Autors ist

zu keinem der Funktionselemente ein Tracelink gerechtfertigt, da sich die Forderung

nach einer Kettenschaltung nicht an die lösungsneutrale Funktion „F1.1 Vortrieb ge-

währleisten“, sondern an „F1.4 variable Übersetzung gewährleisten“ richtet. Dass

Die Tabellen der anderen Artefaktkombinationen sind Anhang B zu entnehmen.

Methoden zur effizienten Modellierung von Tracelinks

134

trotzdem durch ca. 50% der Probanden eine Abhängigkeit identifiziert wurde, liegt

wahrscheinlich daran, dass nicht die lösungsneutrale Funktion bewertet wurde, son-

dern bereits eine Vorfixierung auf die späteren Lösungselemente Kettenblätter und

Zahnkranzkassette stattgefunden hat, die beide neben der Realisierung des Vortriebs

ebenfalls an der durch die Anforderung spezifizierten Funktion beteiligt sind.

A1.1 Vortrieb

A1.1.1 Hinterradantrieb mittels Fußku...

A1.1.2 Übersetzung mittels Kettenscha...

A1.2 Bremsen

A1.2.1 Verschmutzungsrisiko minimieren

A1.2.2 zuverlässiges Bremsen bei Nässe

A1.2.3 muss mit Handkraft betrieben w...

A1.2.4 geringer Verschleiß der Kompon...

A1.3 sicheres Lenken / Manövrieren

A1.4 geländetaugliche Federung und Üb...

A1.4.1 Unebenheiten im Gelände und im...

A1.4.2 Verschiedene Übersetzungen

A1.5 Beleuchtung vorsehen

F1.1 Vortrieb gewährleisten

F1.1.1 Fußkraft aufnehmen

F1.1.2 Antriebskraft leiten

F1.1.3 Kraft / Moment wandeln

F1.1.4 Rotationsmoment auf Straße übe...

F1.2 Verzögerung realisieren

F1.2.1 Handkraft aufnehmen

F1.2.2 Kraft leiten

F1.2.3 Bremskraft auf Hinterrad / Str...

F1.3 Fahrtrichtung ändern

F1.3.1 Steuersignal aufnehmen

F1.3.2 Richtungsänderung ausführen

F1.4 variable Übersetzung gewährleisten

F1.4.1 Fingerkraft aufnehmen

F1.4.2 Kraft leiten

F1.4.3 Übersetzung wechseln

F1.5 Sichtbarkeit gewährleisten

F1.5.1 unmittelbare Umgebung beleuchten

F1.5.2 Licht reflektieren

F1.6 Federung / Dämpfung

Tabelle 19: Aggregierte Anzahl modellierter Tracelinks zwischen Anforderungen und Funk-

tionen (fette Zahlen markieren eine Zelle in der ein Tracelink durch den Autor

modelliert wurde)

„F1.2 Verzögerung realisieren“ | „A1.2 Bremsen“: Auch bei dieser Elementekombina-

tion sind sich alle Probanden zunächst auf höchster Ebene einig und sehen eine Ab-

hängigkeit zwischen der Forderung nach einer Bremse und der Funktion das Fahrrad

zu verzögern. Auch in Bezug auf die Teilfunktionen in Kombination mit der Anforde-

rung „A1.2 Bremsen“ stimmen die Bewertungen der Probanden überein. Die Elemen-

tekombination der Funktion „F1.2 Verzögerung realisieren“ und der Anforderung

Methoden zur effizienten Modellierung von Tracelinks

135

„A1.2.4 geringer Verschleiß der Komponenten“ stellt hingegen einen interessanten

Fall dar

. Bei der Anforderung handelt es sich um eine nicht-funktionale Anforde-

rung, deren Forderung sich somit zunächst nicht an die lösungsneutrale Funktion,

sondern an die Bauteile in der Produktstruktur richtet. Allerdings ist das Produkt „Fahr-

rad“ mit seinen Komponenten den Probanden hinreichend bekannt und immer ähn-

lich aufgebaut, sodass für die Umsetzung der Funktion „F1.2 Verzögerung realisieren“

implizit die Bauteile „Bremsscheibe“ und „Bremsklötze“ vermutet werden. Durch diese

gedankliche Verbindung der tatsächlichen Realisierung, an die sich die Anforderung

A1.2.4 richtet, und der Funktion, modellierten ca. 50 % der Probanden (wie auch der

Autor) einen Tracelink zwischen diesen Elementen.

„F1.4 variable Übersetzung gewährleisten“ | „A1.4 geländetaugliche Federung und

Übersetzung“: Bei dieser Kombination zeigt sich, dass die Übereinstimmung der Pro-

banden vergleichsweise hoch ist, solange sprechende Elementnamen, die direkt As-

soziationen hervorrufen, bzw. einzelne Worte wiederverwendet werden (in diesem

Fall „Übersetzung“). So sind alle Kombinationen der Funktionen „F1.4 variable Über-

setzung gewährleisten“ und „F1.4.3 Übersetzung wechseln“ mit den Anforderungen

„A1.4 geländetaugliche Federung und Übersetzung“ und „A1.4.2 verschiedene

Übersetzungen“ jeweils von 15 bis 16 Probanden als abhängig bewertet worden.

Sobald jedoch detaillierte Teilfunktionen betrachtet werden, deren Bezeichner keine

eindeutigen Assoziationen bei den Probanden hervorrufen („F1.4.1 Fingerkraft auf-

nehmen“ und „F1.4.2 Kraft leiten“), ergibt sich ein unentschiedenes Bild bei den Be-

wertungen.

Trotz dieser subjektiven Einflüsse bei der Tracelink Modellierung, die sehr stark von der

Interpretation der Artefakte durch die Probanden abhängt, zeigt sich, dass bei ca.

80 % der Elementekombinationen viele (16-17) bis sehr viele (18-19) Probanden über-

einstimmen und somit einen bzw. eben keinen Tracelink modelliert haben (siehe Ab-

bildung 59).

Diese unterschiedlichen Interpretationen wirken sich natürlich auf die zu erreichende

Aufwandsersparnis bei der Anwendung von EcoTracing aus, deren Ermittlung das ei-

gentliche Ziel der Studie darstellte. Die Anzahl der Entscheidungen, welche die

19 Probanden treffen mussten, um die drei Artefakte auf Abhängigkeiten zu untersu-

chen, liegen zwischen minimal 360 und maximal 830 (siehe Tabelle 18). Die erreich-

bare Aufwandsersparnis liegt zwischen minimal 31,8 % und maximal 70,4 % bei einer

Standardabweichung von 9,5 %. Der Mittelwert der Anzahl der Entscheidungen liegt

bei ca. 500, was bei einer maximal möglichen Anzahl von Entscheidungen (wie bei

Dieser Fall taucht auch bei anderen Elementekombinationen auf, soll aber anhand dieses

Beispiels exemplarisch erläutert werden.

Methoden zur effizienten Modellierung von Tracelinks

136

der manuellen Vorgehensweise) von 1217 einer Aufwandsersparnis von ca. 60 % ent-

spricht (siehe Abbildung 60).

Abbildung 59: Häufigkeit in der unterschiedliche Anzahlen von Probanden übereinstimmen

und somit einen bzw. keinen Tracelink modelliert haben

Bei der näheren Betrachtung der modellierten Tracelinks von Proband 02 und Pro-

band 16, die bei der Berechnung der erreichten Ersparnis als Ausreißer auffallen, zeigt

sich, dass bei der Bewertung, ob eine Abhängigkeit besteht, ähnliche Schwierigkei-

ten bei der Interpretation des Konzepts „Tracelink“ auftraten, wie schon in Kapi-

tel 5.3.2 beschrieben. So wurden nicht die eigentliche Funktionserfüllung oder Anfor-

derungsrealisierung zur Bewertung herangezogen, sondern darüber hinaus andere

Maßstäbe wie geometrische Nähe oder Kraftfluss verwendet.

Abbildung 60: Ersparte Entscheidungen durch EcoTracing im Vergleich zur manuellen Me-

thode (in %)

67,0%

13,7% 8,6% 6,0%

4,7%

0,0%

10,0%

20,0%

30,0%

40,0%

50,0%

60,0%

70,0%

80,0%

>18 16-17 14-15 12-13 10-11

Anteil der Elementkombinationen

Anzahl der Probanden, die eine bzw. keine Abhängigkeit zwischen zwei

Elementen identifizieren

0,0%

10,0%

20,0%

30,0%

40,0%

50,0%

60,0%

70,0%

80,0%

Ersparnis Mittelwert Ersparnis

Methoden zur effizienten Modellierung von Tracelinks

137

Das führte bei den Probanden dazu, dass bspw. der Rahmen des Fahrrads an der Er-

füllung aller Anforderungen beteiligt ist. Gleiches gilt für die Anforderung „A1.1 Vor-

trieb“, die mit allen Bauteilen und Baugruppen der Produktstruktur verknüpft wurde.

Streicht man diese beiden Probanden folglich als Ausreißer ergibt sich eine mittlere

Aufwandsersparnis von ca. 62 % und eine Standardabweichung von ca. 5,4 %.

5.5 ZUSAMMENFASSUNG UND DISKUSSION

Das Kapitel 5 behandelt die Forschungsfrage, ob eine methodische Unterstützung zur

Modellierung von Tracelinks dabei helfen kann, den dafür notwendigen Aufwand zu

reduzieren (siehe Kapitel 4.1). Die vor dem Hintergrund dieser Fragestellung formulier-

te Hypothese 1 geht davon aus, dass die Eigenschaften von Inklusionshierarchien

genutzt werden können, um die Anzahl zu treffender Entscheidungen bei der Model-

lierung von Tracelinks zu verringern. Um die Forschungsfrage zu beantworten und die

Hypothese überprüfen zu können, wurden in Kapitel 5.1 der aktuelle Stand der Tech-

nik zusammengefasst und in Kapitel 5.2 notwendigen Grundlagen erörtert. Dabei

wurde ein besonderer Fokus auf unterschiedliche Arten von Hierarchien, deren Ei-

genschaften sowie deren Abbildung auf gängige Artefakte der Systementwicklung

gelegt. Ergebnis dieser Analyse war die konkretisierte Hypothese 1*, die die Eigen-

schaften kompositioneller Hierarchien charakterisiert und damit die Grundlage für die

Methode EcoTracing darstellt. Um diese theoretisch hergeleitete Hypothese 1* empi-

risch zu evaluieren, wurde eine Studie durchgeführt, bei der die Hypothese unter ei-

ner Voraussetzung bestätigt werden konnte. Diese Voraussetzung, die aus der ermit-

telten Korrelation zwischen dem Wissen der Probanden und der Anzahl auftretender

Widersprüche, sowie den Ergebnissen der Nachbesprechungen, abgeleitet wurde, ist

eine umfassende Kenntnis der zu analysierenden Artefakte hinsichtlich der vorhan-

denen Elemente und deren Strukturierung durch die Anwender.

Vor diesem Hintergrund wurde das Funktionsprinzip der Methode EcoTracing erläu-

tert und der gewählte Algorithmus zur Abarbeitung von Elementekombinationen bei

der Abhängigkeitsanalyse detailliert beschrieben. Dieser wurde in einer prototypi-

schen Implementierung realisiert, die für die anschließende Evaluation der Leistungs-

fähigkeit der Methode mit Hilfe einer weiteren Studie benötigt wurde. Bei dieser Stu-

die wurde eine erreichbare Aufwandsersparnis von durchschnittlich ca. 60 % ermit-

telt, die mit der Methode im Vergleich zur manuellen Vorgehensweise erreichbar ist.

Der Vergleich mit dem in Kapitel 5.1 beschriebenen Stand der Technik zeigt, dass

EcoTracing bei der möglichen Ersparnis ähnliche oder bessere Werte als die dort be-

schriebenen Methoden ermöglicht. Tilstra et al. ermitteln die mögliche Ersparnis

durch Anwendung ihrer Methode anhand eines Schraubenziehers, den sie selbst-

ständig gruppieren und anschließend die Anzahl zu analysierender Zellen (entspricht

Methoden zur effizienten Modellierung von Tracelinks

138

der Anzahl an Entscheidungen) mit der maximal möglichen Anzahl an Entscheidun-

gen ins Verhältnis setzen. Da ihre Methode sehr abhängig von der Gruppierung der

Bauteile ist, führen Sie eine Studie durch, in deren Rahmen das gleiche Beispiel mittels

eines Zufallsgenerators gruppiert und die möglichen Ersparnisse automatisiert ermit-

teln werden. Dabei zeigt sich, dass eine Ersparnis von maximal 50 % für das gegebe-

ne Beispiel erreichbar ist (anstelle von 1056 müssen nur 508 Zellen analysiert werden)

[Tilstra et al. 2009, S. 245].

Auch Biedermann et al. haben eine Fallstudie durchgeführt, um die erreichbare Er-

sparnis ihrer Methode zu ermitteln. Gegenstand dieser Studie war die Struktur einer

Montagezelle, die auf Abhängigkeiten untersucht wurde. Als Ergebnis werden ca.

65 % Zeitersparnis bei der Analyse angegeben, wobei unterschiedliche Dauern für

die Diskussion der Elementepaare in den unterschiedlichen Matrizen zugrunde gelegt

werden (72 Sekunden pro Entscheidung in der abstrakten DSM, 1,8 Sekunden pro

Entscheidung in der DMM und 36 Sekunden pro Entscheidung in der detaillierten

DSM) [Biedermann et al. 2010, S. 310]. Da diese Annahmen insbesondere bei der Er-

mittlung von Abhängigkeiten in der DMM (deren Erstellung im Vergleich zur manuel-

len Vorgehensweise als zusätzliche Arbeit notwendig ist) als zu optimistisch angese-

hen werden und zudem eine Vergleichbarkeit auf Basis der Anzahl der Entscheidun-

gen leichter möglich ist, ist es notwendig die Angaben umzurechnen. Damit ergibt

sich, dass unter Anwendung der Methode von Biedermann et al. 3519 Entscheidun-

gen getroffen werden müssen, was im Vergleich zur manuellen Vorgehensweise ei-

ner Ersparnis von ca. 33 % entspricht.

Als Ergebnis des Kapitels 5 kann die Hypothese 1 bestätigt werden: die Eigenschaften

von Inklusionshierarchien können genutzt werden, um die Anzahl zu treffender Ent-

scheidungen bei der Modellierung von Tracelinks zu verringern. Diese Art von Hierar-

chien ist sehr weit verbreitet in Artefakten, die üblicherweise in der Systementwick-

lung genutzt werden. Voraussetzung ist jedoch, dass die Anwender der Methode ein

umfassendes Wissen über die zu analysierenden Artefakte und deren Aufbau haben.

Für die Erfüllung dieser Voraussetzung spricht im industriellen Umfeld, dass sich die

Strukturierung der Artefakte an festen Regeln orientiert, die den Entwicklern bekannt

sind. Zusätzlich sollte die Methode durch Experten angewendet werden, die umfas-

sende Kenntnisse der Systeme, deren Strukturierung sowie deren Funktionen haben.

Unabhängig von der Methode EcoTracing konnte durch die durchgeführten Studien

nachgewiesen werden, dass die Modellierung von Tracelinks sehr stark durch die

subjektive Interpretation der inhaltlichen Bedeutung der Elemente und des Konzepts

„Tracelink“ durch den Anwender geprägt ist. So konnte festgestellt werden, dass Ab-

hängigkeiten häufiger als solche identifiziert werden, wenn die betroffenen Elemente

gleiche oder synonyme Worte in ihren Bezeichnern aufweisen. Darüber hinaus wer-

Methoden zur effizienten Modellierung von Tracelinks

139

den nicht immer dieselben Maßstäbe bei der Bewertung von Abhängigkeiten ver-

wendet. Verbreitet vorgekommen ist in den Studien bspw. neben der eigentlichen

Funktionserfüllung, Kraftflüsse oder geometrische Nähe als Indikator für oder gegen

die Entscheidung, einen Tracelink zu modellieren, zu verwenden. Auch ist der Um-

gang mit nicht-funktionalen Anforderungen bei der Abhängigkeitsanalyse zwischen

Anforderungs- und Funktionsartefakten nicht einfach und wurde durch die Proban-

den unterschiedlich interpretiert.

Dieser Aspekt der Modellierung von Tracelinks wurde bislang nicht berücksichtigt und

birgt große Forschungspotenziale. Ziel muss es in diesem Zusammenhang sein, die

Entwickler als Anwender der Methoden bei dem Treffen der einzelnen Entscheidun-

gen zu unterstützen. So könnte bspw. die Strukturierung von Anforderungen nach

funktionalen Aspekten bei der Abhängigkeitsanalyse zwischen Anforderungs- und

Funktionsartefakten eine große Hilfe darstellen. Ebenfalls vielversprechend könnte

hinsichtlich einer optimierten Abhängigkeitsanalyse die detailliertere Untersuchung

unterschiedlicher Formen der Elementbeschreibung sein, um bei den Anwendern ei-

ne klarere Vorstellung von deren Inhalt hervorzurufen und somit die eindeutigere Ab-

leitung von Tracelinks zu ermöglichen.

Trotzdem stellt die Methode EcoTracing einen deutlichen Fortschritt zum Stand der

Technik dar. In Bezugnahme auf die in Kapitel 4 beschriebenen Herausforderung 1

hilft sie dem Entwickler aufgrund der Umsetzung als Wizard in Kombination mit der

strukturierten Abarbeitung aller relevanten Elementkombinationen den Überblick bei

der Erfassung von Tracelinks zu behalten. Damit gelingt es eine Traceability-Analyse

durchzuführen, deren Vollständigkeit im Vergleich zu sonst üblichen Online-

Erfassungsmethoden garantiert werden kann. Darüber hinaus wurde dargestellt, dass

die Anzahl zu treffender Entscheidungen durch Anwendung von EcoTracing im Mittel

um ca. 60 % reduziert werden kann. EcoTracing adressiert damit Herausforderung 2,

indem der signifikante Aufwand für die manuelle Modellierung von Tracelinks verrin-

gert wird.

141

6 METHODEN ZUR PFLEGE VON TRACELINK-MODELLEN

Wie in Kapitel 3.4.3 dargestellt, ist es notwendig, Abhängigkeitsnetze kontinuierlich zu

pflegen, um deren Qualität hoch, also die Zahl enthaltener Fehler niedrig, zu halten.

Dies ist insbesondere vor dem Hintergrund der späteren Nutzung der Abhängigkeits-

netze für unterschiedliche Anwendungen wie z. B. Auswirkungsanalysen essentiell, da

diese andernfalls nicht korrekt durchgeführt werden können.

Die Fehler im Tracelink-Modell können auf unterschiedliche Arten entstehen. Zum ei-

nen können während der manuellen Erfassung der Tracelinks Fehler gemacht wer-

den. Dabei ist zu berücksichtigen, dass es sich bei der Entscheidung, einen Tracelink

zu modellieren, um eine sehr individuelle Einschätzung handelt, die auf der subjekti-

ven Interpretation der betrachteten Elemente beruht und damit ein „korrektes“

Tracelink-Modell nicht existiert (siehe Diskussion in Kapitel 5.5). Zum anderen führen

auch die dynamischen Weiterentwicklungen und Änderungen der Artefakte dazu,

dass Abhängigkeiten zwischen Elementen hinzukommen oder wegfallen [Egyed und

Grünbacher 2002, S. 169].

Auch wenn die Fehler im Traceability-Modell unterschiedliche Ursachen haben und

unter Umständen gar nicht eindeutig als Fehler identifiziert werden können, sondern

eher auf unterschiedlichen Interpretationen der Elemente und Artefakte beruhen,

sind Methoden notwendig, um Hinweise auf wahrscheinliche Fehler zu geben und

somit die Möglichkeit für deren Beseitigung zu geben.

Methoden zur Pflege von Tracelink-Modellen

142

Wie bereits in Kapitel 3.4.1 erwähnt, werden auch Methoden, die sich mit der (teil-)

automatisierten Identifikation von Abhängigkeiten und der anschließenden Modellie-

rung von Tracelinks befassen, im Rahmen dieser Arbeit der Pflege von Tracelink-

Modellen zugeordnet, da eine Vollständigkeit nicht sinnvoll bewertet werden kann.

Diese und andere Methoden werden in Kapitel 6.1 als Stand der Technik beschrie-

ben, kategorisiert und auf dieser Basis Defizite (und damit potenzielle Forschungsrich-

tungen) aufgedeckt. Im Folgenden werden die beiden Methoden TraceEvaluation

(siehe Kapitel 6.3) und TraceLegacy (siehe Kapitel 6.4)vorgestellt, die diese Defizite

adressieren und über den aktuellen Stand der Technik hinausgehen. Die für die Ent-

wicklung der Methoden sowie deren Evaluation notwendigen Grundlagen werden

zuvor in Kapitel 6.2 beschrieben. Die abschließende Diskussion der Methoden erfolgt

in Kapitel 6.5.

6.1 STAND DER TECHNIK UND FORSCHUNG

Die Methoden zur (teil-)automatisierten Pflege von Tracelink-Modellen basieren da-

rauf, dass unterschiedliche Informationsquellen hinsichtlich bestimmter Kriterien ana-

lysiert werden. Anhand der dazu verwendeten Analysealgorithmen lassen sich die

Methoden zur Pflege von Tracelink-Modellen kategorisieren. Dabei werden zwei

grundsätzliche Kategorien unterschieden: Methoden, die auf Regeln und Methoden,

die auf linguistischen Analysen bzw. Informationsrückgewinnung

(IR) basieren

[Winkler und Pilgrim 2010, S. 550]. Erstere nutzen Regeln, die definieren, wann eine

Abhängigkeit zwischen zwei Elementen wahrscheinlich bzw. unwahrscheinlich ist.

Häufig werden die Strukturen der Artefakte und/oder Tracelink-Modelle analysiert

und so potenzielle Abhängigkeiten identifiziert. Methoden der zweiten Kategorie

wenden hingegen bspw. linguistische Untersuchungen der textuellen Beschreibun-

gen der Elemente an und erkennen so, bspw. durch wiederkehrende Worte in unter-

schiedlichen Elementen, Ähnlichkeiten.

Das Ergebnis der Analyse sind in jedem Fall Empfehlungen für fehlende Tracelinks zwi-

schen Elementen, bei denen eine Abhängigkeit vorliegt (falsch negative Tracelinks)

bzw. für fälschlicherweise modellierte Tracelinks zwischen Elementen, bei denen kei-

ne Abhängigkeit vorhanden ist (falsch positive Tracelinks) (vgl. auch Kapitel 3.4.3).

Dabei stellen alle hier vorgestellten Algorithmen Ansätze zur Unterstützung der Nutzer

dar, denen letztlich die Entscheidung über das Vorhandensein einer Abhängigkeit

obliegt [Hayes et al. 2006, S. 5-6]. Eine vollautomatisierte Pflege ist bislang noch nicht

möglich, da die Algorithmen nicht alle falsch positiven bzw. falsch negativen Trace-

Informationsrückgewinnung ist im Englischen unter dem Begriff „information retrieval“ be-

kannt.

Methoden zur Pflege von Tracelink-Modellen

143

links identifizieren können [Lucia et al. 2007, S. 44] und sich die Abhängigkeiten dar-

über hinaus häufig nicht nur aus den einzelnen Elementen, sondern zusätzlich deren

Kontext ergeben, welcher noch nicht zuverlässig automatisiert erfasst werden kann.

Das Ziel der Methoden zur Pflege von Tracelink-Modellen ist somit nicht, den Entwick-

ler zu ersetzen, sondern ihm vielmehr eine Unterstützung bei den zahlreichen Ent-

scheidungsprozessen während der Pflege zu bieten bzw. ihn durch gezielte Vor-

schläge zu unterstützen.

Ferner ist anzumerken, dass es bislang noch nicht „die Methode“ zur Pflege von

Tracelink-Modellen gibt, die für alle Anwendungsbereiche geeignet ist. Es wird viel-

mehr in absehbarer Zukunft dabei bleiben, dass mehrere Methoden Teile eines ge-

meinsamen Puzzles darstellen, welches in Kombination eine möglichst gute Qualität

des Tracelink-Modells sicherstellt [Aizenbud-Reshef et al. 2006, S. 523].

In den Kapiteln 6.1.1 und 6.1.2 werden, strukturiert nach den zuvor genannten Kate-

gorien, einige Methoden vorgestellt, um einen grundsätzlichen Überblick über den

Stand der Technik zu geben. Anschließend werden sie in Kapitel 6.1.3 anhand ihrer

Eigenschaften charakterisiert

, Defizite aufgezeigt und auf dieser Basis mögliche

Weiterentwicklungsmöglichkeiten in diskutiert.

6.1.1 REGELBASIERTE METHODEN

Regelbasierte Methoden analysieren die Strukturen der Artefakte und/oder des zu-

gehörigen Tracelink-Modells, mit dem Ziel dessen Qualität zu verbessern [Winkler und

Pilgrim 2010, S. 550]. Dabei kommen Regeln zur Anwendung, die häufig auf Erfahrun-

gen basieren und definieren, welche Bedingungen für einen bestimmten Elementtyp

erfüllt sein müssen, damit dieser in Bezug auf seine modellierten Tracelinks als fehler-

frei gelten kann. So kann bspw. eine Regel definiert werden, die aussagt, dass jede

funktionale Anforderung mindestens einen Tracelink zu einer Funktion in der Funkti-

onsliste bzw. -struktur aufweisen muss (Methode 1). Existiert dieser Tracelink nicht,

kann davon ausgegangen werden, dass entweder die Anforderung noch nicht in

dem Funktionsartefakt berücksichtigt wurde oder aber, dass ein Fehler im Tracelink-

Modell vorliegt. Die Auswertung des Traceability-Modells würde somit solche Anfor-

derungen identifizieren, die keinen Tracelink aufweisen und einer erneuten Überprü-

fung unterzogen werden sollten [Spanoudakis et al. 2004, S. 112]. Eine Erweiterung

dieser Methode wird durch Eben et al. beschrieben. Dabei ist nicht nur eine direkte

Verknüpfung zu den Funktionen, sondern darüber hinaus zu den anderen verwende-

Um diese Charakterisierung zielgerichtet durchführen zu können werden alle folgend vor-

gestellten Methoden durchnummeriert.

Methoden zur Pflege von Tracelink-Modellen

144

ten Artefakten bis hin zur Produktstruktur erforderlich, um die Bedingung der Fehler-

freiheit zu erfüllen (Methode 2) [Eben et al. 2010, S. 1061].

Ein weiteres Beispiel für die Definition einer Regel wird von Winkler und Pilgrim ge-

nannt, welche bei der Verwendung von transitiven Tracelinks angewendet werden

kann [Winkler und Pilgrim 2010, S. 550]. Gesetzt den Fall, dass ein Element des Arte-

fakts A mit einem Element des Artefakts B verknüpft ist, welches wiederum mit einem

Element in Artefakt C verknüpft ist, kann automatisch ein Tracelink von dem Element

in Artefakt A zu dem in C vorgeschlagen bzw. modelliert werden (Methode 3)

[Winkler und Pilgrim 2010, S. 550].

Auch Maurer beschreibt Methoden, die auf der Transitivität der Tracelinks basieren,

um im Kontext von Abhängigkeitsmatrizen artefaktinterne Tracelinks aus artefakt-

übergreifenden abzuleiten (Methode 4). Konkret geht es um die Erstellung von De-

sign Structure Matrices (DSM) auf Basis der Informationen in Domain Mapping Matri-

ces (DMM). Er identifiziert sechs unterschiedliche Regeln, die sich ergeben, da die

Richtung der Tracelinks berücksichtigt wird [Maurer 2007, S. 95]. Eine Übersicht der

Regeln ist in Abbildung 61 zu sehen. Eine nähere Erläuterung der Regeln anhand

übersichtlicher Beispiele ist in [Maurer 2007] zu finden.

Abbildung 61: Regeln zur Ableitung von Abhängigkeiten nach [Maurer 2007, S. 95]

Egyed und Grünbacher schlagen eine Methode vor, die laut dem angeführten Bei-

spiel im Rahmen der Softwareentwicklung angewendet, jedoch mit Hilfe einiger An-

passungen auch auf andere Einsatzbereiche übertragen werden kann. Analysiert

werden dabei die Tracelinks zwischen Anforderungen und Bereichen im Quellcode

einer Software. Die Hypothese der Autoren lautet dabei, dass für den Fall, dass eine

Anforderung A auf einen Bereich CA im Code und eine zweite Anforderung B auf ei-

nen Bereich CB im Code verweist, und diese beiden Bereiche eine Überlappung

aufweisen (und somit zumindest teilweise identisch sind), eine Abhängigkeit zwischen

den Anforderungen A und B möglich ist. Dabei gilt, je größer die Überlappung zwi-

schen den beiden Bereichen, desto größer die Wahrscheinlichkeit, dass eine Abhän-

Methoden zur Pflege von Tracelink-Modellen

145

gigkeit besteht und somit ein Tracelink modelliert werden sollte (Methode 5) [Egyed

und Grünbacher 2002, S. 169].

6.1.2 LINGUISTISCHE UND IR-METHODEN

Linguistische Methoden analysieren im Gegensatz zu den regelbasierten Methoden,

nicht die Strukturen der Artefakte bzw. des Tracelink-Modells, sondern die textuellen

Bezeichner der Elemente der Artefakte. Während die linguistischen Methoden über

vergleichsweise einfache Vergleichsalgorithmen verfügen, sind Methoden der Infor-

mationsrückgewinnung in der Lage unstrukturierte Fließtexte zu analysieren und

Schlüsselbegriffe zu extrahieren [Lucia et al. 2007, S. 11-12; Manning et al. 2009, S. 1].

Sie können damit bspw. auch zur Analyse textueller Anforderungsspezifikationen, und

nicht nur deren Anforderungsbezeichner, zum Einsatz kommen [Winkler und Pilgrim

2010, S. 551]. Im Kontext der durchgängigen Nachverfolgbarkeit können die so

extrahierten Schlüsselwörter eines Artefakts als Suchanfrage an ein anderes Artefakt

dienen und somit die Ähnlichkeit zwischen ihnen berechnet werden. Ist diese zwi-

schen spezifischen Bereichen oder Elementen hoch, wird die Empfehlung ausgege-

ben, einen Tracelink zu modellieren [Lucia et al. 2007, S. 11-12].

Eine vergleichsweise einfache linguistische Methode wurde von Kaindl et al. vorge-

stellt (Methode 6). Dabei werden Texte mittels Stringabgleich nach gemeinsamen

Wörtern durchsucht und bei Übereinstimmung Tracelinks modelliert [Kaindl et al.

1999]. Im Kontext der Systementwicklung und den zuvor in Kapitel 2.2 vorgestellten

Artefakten würde dies bedeuten, dass bspw. die Anforderungen und Funktionsbe-

schreibungen analysiert und bei übereinstimmenden Worten ein Tracelink vorge-

schlagen werden würde.

Eine Erweiterung dieses Ansatzes stellt die von Spanoudakis et al. beschriebene Me-

thode dar (Methode 7) [Spanoudakis et al. 2004]. Sie basiert auf der Verwendung

von sog. RTOM-Regeln (Requirements-to-object-model), um Tracelinks zwischen An-

forderungsspezifikationen und weiteren Artefakten zu modellieren. Im Unterschied zu

der Methode von Kaindl et al. werden die Texte jedoch nicht nur hinsichtlich einzel-

ner Wörter analysiert, sondern mit Hilfe des sog. CLAWS-Algorithmus auch deren

grammatikalische Funktion in der Satzstruktur identifiziert [Lancaster University - Cent-

re for Computer Corpus Research on Language 2013]. Die Texte werden zwar nicht

hinsichtlich ihrer Semantik untersucht, allerdings lassen sich aussagekräftige Bereiche

in Sätzen anhand der grammatikalischen Funktionen der zugehörigen Wörter identifi-

zieren. Anschließend wird der Stringabgleich auf diese relevanten Bereiche einge-

grenzt, um die Relevanz der Tracelinkvorschläge sicherzustellen [Spanoudakis et al.

2004, S. 106].

Methoden zur Pflege von Tracelink-Modellen

146

Cerbah und Euzenat verwenden hingegen eine Art Glossar, in dem technische Be-

griffe dokumentiert sind, um den Stringabgleich auf relevante Worte zu beschränken

(Methode 8). Mittels dieser technischen Begriffe können formale und informale Arte-

fakte durchsucht und, bei Existenz in beiden Artefakten, ein Tracelink vorgeschlagen

werden (siehe Abbildung 62) [Cerbah und Euzenat 2001].

Abbildung 62: Verwendung eines Glossars, um wichtige Begriffe in textuellen Beschreibun-

gen identifizieren zu können [Cerbah und Euzenat 2001, S. 33]

Eine von Antoniol et al. beschriebene Methode basiert auf Informationsrückgewin-

nung um Abhängigkeiten zwischen Fließtext, wie er bspw. in Anforderungen vor-

kommt, und Quellcode zu identifizieren (Methode 9). Dabei werden die Fließtexte

vorbereitet (Ersetzen von Groß- durch Kleinbuchstaben, Entfernung von Stoppworten

und Konvertierung von Plural- in Singular-Formen) und indiziert. Gleiches wird auch für

die Bezeichner der Klassen durchgeführt. Die Berechnung der Ähnlichkeit zwischen

Suchanfrage und den indizierten Dokumenten erfolgt dann mit Hilfe eines Vektor-

raum-IR-Modells, bei dem der Vektorraum durch die in den Bezeichnern und Doku-

menten enthaltenen Worte aufgespannt wird. Das Ergebnis ist für jede Klasse eine Lis-

te anhand ihrer Ähnlichkeit sortierter Dokumente, zu denen ein Tracelink potenziell

sinnvoll wäre [Antoniol et al. 2000].

Auch Hayes et al. verwenden unterschiedliche IR-Algorithmen, um Vorschläge für

potenzielle Abhängigkeiten zu generieren (Methode 10). Ihr Fokus liegt dabei auf

dem Vorschlagen von Tracelinks zwischen Anforderungsspezifikationen unterschiedli-

chen Detaillierungslevels. Zu diesem Zweck haben sie das Werkzeug RETRO (REqui-

rements TRacing On-target) entwickelt, mit dessen Hilfe die Anforderungen indiziert

und mit unterschiedlichen IR-Algorithmen auf Ähnlichkeiten zueinander analysiert

werden. Die Grundlage bildet das Vektorraum-IR-Modell, welches auch von Antoniol

Methoden zur Pflege von Tracelink-Modellen

147

et al. verwendet wird (siehe Methode 9). In RETRO wird es um einen Thesaurus sowie

das sog. Latent Semantic Indexing ergänzt. Letzteres erlaubt Analysen, die über ei-

nen Wortvergleich hinausgehen und die Ähnlichkeit zweier Vektoren mithilfe des Ko-

sinus ermitteln [Hayes et al. 2006].

6.1.3 ZUSAMMENFASSUNG UND DISKUSSION

In den vorangegangenen Kapiteln 6.1.1 und 6.1.2 wurden insgesamt 10 Methoden

vorgestellt, mit denen Artefakte und Tracelink-Modelle analysiert werden können, um

Vorschläge für Tracelinks zu generieren und somit zur Qualitätssicherung des

Tracelink-Modells beizutragen. In der folgenden Tabelle 20 werden diese Methoden

anhand ihrer Eigenschaften unterschiedlichen Kategorien zugeordnet. Mit der ersten

Kategorie wird charakterisiert, welche Art von Fehlern im Tracelink-Modell mit der je-

weiligen Methode identifiziert werden kann (falsch positive und/oder falsch negative

Tracelinks). Die zweite Kategorie adressiert die Art der Informationsquelle, die durch

die Algorithmen analysiert wird, um Abhängigkeiten zu identifizieren (das Artefakt

inkl. seiner Elemente, die bereits modellierten Tracelinks im Tracelink-Modell oder,

wenn beides analysiert wird, das Traceability-Modell). In der dritten Kategorie wird

bewertet, ob als Informationsquelle nur aktuelle Artefakte und Tracelink-Modelle

herangezogen oder, ob (zusätzlich) Informationen vergangener Projekte zur Ermitt-

lung von Vorschlägen für Tracelinks verwendet werden (entstammt die Informations-

quelle dem aktuellen oder einem vorherigen Projekt).

Identifikation von

falsch ...

Art der analysierten

Informationsquelle

Aktualität der analysierten

Informationsquelle

Methode

positiven

Tracelinks

negativen

Tracelinks

Artefakt

Tracelink-

Modell

aktuelles

Projekt

Tabelle 20: Kategorisierung der Methoden des Stands der Technik

Bei der Betrachtung der Tabelle 20 wird deutlich, dass alle vorgestellten regelbasier-

ten Methoden (1-5) die Existenz eines Tracelink-Modells voraussetzen, da die Regeln

Methoden zur Pflege von Tracelink-Modellen

148

die Struktur der Elemente im Traceability-Modell (bestehend aus Artefakten und

Tracelink-Modell) überwachen. Es werden somit bei der regelbasierten Analyse im-

mer die Tracelinks und bei den Methoden 1, 2 und 5 zusätzlich die Elemente der Arte-

fakte sowie deren hierarchischen Verknüpfungen berücksichtigt. Bei den linguisti-

schen bzw. IR-Methoden (6-10) werden hingegen immer die textuellen Bezeichner

bzw. Beschreibungen der Elemente analysiert, weshalb die für die Analyse notwen-

digen Informationen in allen Fällen den Artefakten entnommen werden und das

Tracelink-Modell nicht berücksichtigt wird.

Was übergreifend für alle vorgestellten Methoden gilt ist, dass sie sich maßgeblich für

die Identifikation von falsch negativen Tracelinks eignen. Tracelinks, die modelliert

wurden, obwohl keine Abhängigkeit zwischen Elementen besteht, werden durch die

Methoden in ihrer beschriebenen Umsetzung nicht erkannt. Auch wenn diese Fehler,

wie in Kapitel 3.4.3 beschrieben, leichter zu identifizieren sind, ist eine Unterstützung

bei deren Identifikation im Kontext der Qualitätssicherung des Tracelink-Modells not-

wendig. Im Folgenden Kapitel 6.2 werden daher die Grundlagen des Konzepts

Crowdsourcing

erörtert, da es sich potenziell gut für die Unterstützung eben dieses

Prozesses eignet.

Weiter fällt auf, dass alle Analyse-Methoden ihre Informationen lediglich aus aktuel-

len Projekten beziehen. Das hat bei den linguistischen und IR-Methoden den Nach-

teil, dass die Elemente der analysierten Artefakte überlappende Inhalte in Form von

Wörtern, Synonymen oder Beschreibungen aufweisen müssen, da Abhängigkeiten

sonst nicht erkannt werden können [Winkler und Pilgrim 2010, S. 552]. Dies ist, insbe-

sondere wenn unterschiedliche Arten von Artefakten hinsichtlich ihrer Abhängigkei-

ten zueinander analysiert werden, nicht immer gegeben. So kann sich bspw. das

verwendete Vokabular, welches bei der Anforderungsspezifikation verwendet wird,

von dem bei der Benennung der Bauteile und Baugruppen in der Produktstruktur un-

terscheiden und somit die Analyse-Methoden keine Abhängigkeit feststellen

. Für

diesen Fall kann es sinnvoll sein, auf Artefakte vergangener Projekte und damit auf

darin gespeichertes Wissen zuzugreifen.

An diesen beiden vom Stand der Technik noch nicht adressierten Aspekten orientie-

ren sich die im Folgenden beschriebenen Methoden TraceEvaluation und

TraceLegacy, um ein Puzzle-Stück zur Sicherung der Qualität des Tracelink-Modells

beizutragen.

Deutsch: Schwarmauslagerung

Eine Ausnahme stellt in diesem Zusammenhang die Methode 10 dar, da ein Thesaurus

verwendet wird und somit auch verwandte Begriffe erkannt werden können.

Methoden zur Pflege von Tracelink-Modellen

149

6.2 GRUNDLAGEN ZUR KONZEPTION UND BEWERTUNG DER METHODEN

In Kapitel 6.2 werden Grundlagen erläutert, die für die Entwicklung und die Bewer-

tung der Methoden TraceEvaluation und TraceLegacy essentiell sind. Dabei ist das

Kapitel 6.2.1 die Basis für die Crowdsourcing-Methode TraceEvaluation, bei der das

Wissen der Mitarbeiter genutzt wird, um fehlerhafte Tracelinks zu identifizieren. In Kapi-

tel 6.2.2 werden die beiden Messgrößen Trefferquote und Präzision eingeführt, die für

die Bewertung der beiden Methoden im Rahmen der durchgeführten Evaluationen

herangezogen werden.

6.2.1 CROWDSOURCING

Crowdsourcing ist eine relativ neue Strategie, die vor allen Dingen bei einer Vielzahl

von Diensten im Internet zu finden ist [Estelles-Arolas und Gonzalez-Ladron-de-

Guevara 2012, S. 189]. Wie häufig bei neu aufkommenden Themenbereichen ver-

breitet, gibt es auch in diesem Bereich aktuell noch Diskussionen über eine eindeuti-

ge Namensgebung [Doan et al. 2011, S. 86] und die beinhalteten Aspekte [Estelles-

Arolas und Gonzalez-Ladron-de-Guevara 2012, S. 189]. So werden neben dem Begriff

Crowdsouring auch zahlreiche andere synonym verwendet: peer production, user-

powered systems, user-generated content, collaborative systems, cummunity sys-

tems, social systems, social search, social media, collective intelligence, wikinomics,

crowd wisdom, smart mobs, mass collaboration und human computation [Doan et

al. 2011, S. 86]. Hinsichtlich der genauen Definition stellen insbesondere die sehr un-

terschiedlichen Ausprägungen des Crowdsourcings die Wissenschaftler vor eine Her-

ausforderung [Estelles-Arolas und Gonzalez-Ladron-de-Guevara 2012, S. 189]. Typi-

sche Beispiele für Crowdsourcing unterschiedlicher Ausprägungen sind Wikipedia

[Wikimedia Foundation Inc 2013], Linux [Linux.org 2013], Yahoo! Anwers [Yahoo! Inc.

2013], Amazon Mechanical Turk [Amazon.com 2013], bei denen unterschiedlich

komplexe Aufgabenstellungen an den Schwarm ausgelagert werden. Eine weit ver-

breitete Definition, die auch im Rahmen dieser Arbeit angewendet wird, lautet:

„We say that a system is a CS [Crowdsourcing] system, if it enlists a crowd

of humans to help solve a problem defined by the system owners

[...].“[Doan et al. 2011, S. 87]

Demnach ist Crowdsourcing ein System, mit dessen Hilfe vom Prozesseigner definierte

Aufgaben- oder Problemstellungen durch eine größere Anzahl an Menschen bear-

beitet werden. Der Grundsätzliche Aufbau dieses Systems ist in Abbildung 63 (grauer

Kasten) abgebildet.

Methoden zur Pflege von Tracelink-Modellen

150

Abbildung 63: Typisches Crowdsourcing System [Geiger et al. 2011, S. 2]

Den Ausgangspunkt stellt dabei eine Organisation oder Person (allg.: Auftraggeber)

dar, die eine bestimmte Aufgabenstellung definiert, die durch das Crowdsourcing-

System bearbeitet werden soll. Diese Aufgabenstellung wird im Folgenden in Sub-

Aufgabenstellungen aufgeteilt, die an die Mitwirkenden (die Crowd) verteilt und von

diesen bearbeitet werden. Im Anschluss müssen deren Beiträge, welche Sub-

Ergebnisse darstellen, zu einem Gesamtergebnis aggregiert werden, welches wieder-

um die in der Aufgabenstellung definierte Fragestellung beantwortet [Geiger et al.

2011, S. 1-2; Jones 2013, S. 133].

Unabhängig vom konkreten Crowdsourcing-System stellen sich vier typische Frage-

stellungen, die laut Jones für eine erfolgreiche Umsetzung beantwortet werden müs-

sen [Jones 2013, S. 133]:

- Wie werden die Mitwirkenden rekrutiert?

- Was können die Mitwirkenden zur Gesamtaufgabenstellung beitragen?

- Wie können die Teilergebnisse aggregiert werden?

- Wie wird mit Missbrauch umgegangen?

Geiger et al. haben diese Fragen aufgegriffen und eine umfassende Literaturrecher-

che durchgeführt, um die Eigenschaften eines Crowdsourcing-Systems herauszuar-

beiten und damit eine Basis für die Kategorisierung existierender, aber auch Entwick-

lung neuer Crowdsourcing-Systeme bereitzustellen (siehe Abbildung 64) [Geiger et

al. 2011, S. 5-6].

Die so identifizierten vier Kategorien Vorauswahl der Mitwirkenden, Zugänglichkeit

der einzelnen Teilergebnisse, Aggregation der Teilergebnisse und Entlohnung für Teil-

ergebnisse werden im Folgenden näher erläutert.

Vorauswahl der Mitwirkenden. Diese Kategorie adressiert den Pool, aus dem die Mit-

wirkenden rekrutiert werden. Geiger et al. identifizieren insgesamt vier unterschiedli-

che Arten der Vorauswahl [Geiger et al. 2011, S. 6]. So kann ein bestimmtes Vorwis-

sen für die Bearbeitung der Aufgabenstellungen notwendig sein. In diesem Fall wür-

den die Mitwirkenden qualifikationsbasiert ausgewählt, wobei die Qualifikation bspw.

Methoden zur Pflege von Tracelink-Modellen

151

mit Hilfe eines Tests vor der Bearbeitung überprüft werden kann. Eine Vorauswahl ist

hingegen kontextspezifisch, wenn sie aufgrund des Kontextes der Mitwirkenden ge-

troffen wird [Corney et al. 2010, S. 298; Rouse 2010, S. 5; Estelles-Arolas und Gonzalez-

Ladron-de-Guevara 2012, S. 193-194]. Dies kann bspw. der Fall sein, wenn Geheim-

haltungsstufen eingehalten werden müssen und daher nur Mitarbeiter einer speziel-

len Firma im Crowdsourcing-System mitwirken können. Darüber hinaus kann es vor-

kommen, dass sowohl die Qualifikation als auch der Kontext zur Auswahl der Mitwir-

kenden herangezogen wird oder aber keine Vorauswahl getroffen wird [Geiger et al.

2011, S. 6].

Abbildung 64: Taxonomie zur Beschreibung der Eigenschaften von Crowdsourcing-Systemen

[Geiger et al. 2011, S. 6]

Zugänglichkeit der einzelnen Teilergebnisse. Diese Kategorie beschreibt die Form der

Zusammenarbeit der einzelnen Mitwirkenden anhand der Zugänglichkeit der Teiler-

gebnisse für andere. Keine bedeutet, dass die Mitwirkenden isoliert voneinander die

Aufgabenstellungen bearbeiten und die Ergebnisse anderer nicht berücksichtigt

werden können. Sehen hingegen heißt, dass die Mitwirkenden die Ergebnisse ande-

rer zu sehen bekommen und bei ihrer Bearbeitung der Aufgabenstellung berücksich-

tigen können. Werden in der Umsetzung des Crowdsourcing-Systems, neben dem

Sehen der anderen Beiträge, noch Funktionen zum Kommentieren oder Bewerten

dieser bereitgestellt, ordnet man diesem System das Attribut beurteilen zu. Die stärks-

te Form der Interaktion zwischen den Mitwirkenden liegt bei ändern vor, da hier Bei-

träge anderer geändert oder gelöscht werden können [Geiger et al. 2011, S. 7].

Aggregation der Teilergebnisse. Die von den Mitwirkenden erzielten Teilergebnisse

müssen hinsichtlich ihrer Korrektheit bewertet, sortiert und zusammengeführt werden,

um das anvisierte Gesamtergebnis zu erhalten [Doan et al. 2011, S. 95]. Hier kommt

Methoden zur Pflege von Tracelink-Modellen

152

es stark auf den Beitrag der Mitwirkenden an. Während z. B. bei der Wikipedia die In-

tegration und Kontrolle der Ergebnisse durch die Mitwirkenden selbst durchgeführt

werden, sind eher lose Kopplungen, bei denen die Mitwirkenden von den Ergebnis-

sen der anderen wissen, die Regel. In diesen Fällen muss die Aggregation durch den

Auftraggeber durchgeführt werden. Grundsätzlich lassen sich aber zwei Ausprägun-

gen unterscheiden. Bei der integrativen Aggregation werden alle Teilergebnisse der

Mitwirkenden genutzt, solange sie nicht gesetzte Qualitätsstandards verfehlen. Bei

einer selektiven Aggregation wird dagegen eine Auswahl getroffen und eine Vielzahl

an Ergebnissen verworfen [Geiger et al. 2011, S. 7].

Entlohnung für Teilergebnisse. Die Entlohnung für die Erbringung von Teilergebnissen

stellt einen wichtigen Aspekt von Crowdsourcing Systemen dar. Dabei werden von

Geiger et al. die drei Ausprägungen fixiert, erfolgsbasiert und keine unterschieden.

Während bei der ersten Ausprägung die Entlohnung vor Bearbeitung festgelegt und

unabhängig vom Ergebnis ausgezahlt wird, spielt die Qualität des Ergebnisses bei der

erfolgsbasierten Ausprägung eine entscheidende Rolle [Geiger et al. 2011, S. 7-8].

Wird keine Entlohnung bereitgestellt, müssen entweder Freiwillige gefunden oder

aber bspw. Mitarbeiter einer Firma zum Mitwirken verpflichtet werden [Doan et al.

2011, S. 94].

Diese vier Kategorien der Taxonomie nach Geiger et al. werden in Kapitel 6.3.1 wie-

deraufgenommen und zur Charakterisierung der Methode TraceEvaluation herange-

zogen. Darüber hinaus wird die Darstellung aus Abbildung 64 genutzt, um das Tra-

ceEvaluation-Crowdsourcing-System zu beschreiben.

6.2.2 TREFFERQUOTE UND PRÄZISION

Trefferquote (engl.: Recall) und Präzision (engl.: Precision) sind die beiden am weitest

verbreiteten Messgrößen, die genutzt werden, um die Effektivität eines IR-Systems zu

messen [Manning et al. 2009, S. 5 & 155]. Da Methoden zur Pflege von Tracelink-

Modellen entweder auf IR-Methoden basieren oder ähnliche In- und Output-

Parameter haben, werden diese Messgrößen auch häufig zur Bewertung von Me-

thoden im Kontext der durchgängigen Nachverfolgbarkeit angewendet.

Die Präzision einer Methode definiert sich über den Anteil generierter relevanter Vor-

schläge im Verhältnis zur gesamten Anzahl an Vorschlägen. In Bezug auf Traceability

entspricht dies der Anzahl korrekt identifizierter Tracelinks bezogen auf die Anzahl der

insgesamt gemachten Vorschläge.

𝑃𝑟ä𝑧𝑖𝑠𝑖𝑜𝑛=𝐴𝑛𝑧𝑎ℎ𝑙 𝑟𝑒𝑙𝑒𝑣𝑎𝑛𝑡𝑒𝑟 𝑉𝑜𝑟𝑠𝑐ℎ𝑙ä𝑔𝑒

𝐴𝑛𝑧𝑎ℎ𝑙 𝑉𝑜𝑟𝑠𝑐ℎ𝑙ä𝑔𝑒

(15)

Methoden zur Pflege von Tracelink-Modellen

153

Die Trefferquote einer Methode berechnet sich über den Anteil generierter relevan-

ter gegenüber der Anzahl maximal möglicher relevanter Vorschläge. In Bezug auf

Traceability entspricht dies der Anzahl korrekt identifizierter Tracelinks bezogen auf

die Anzahl existierender Abhängigkeiten zwischen den Elementen der Artefakte.

𝑇𝑟𝑒𝑓𝑓𝑒𝑟𝑞𝑢𝑜𝑡𝑒= 𝐴𝑛𝑧𝑎ℎ𝑙 𝑟𝑒𝑙𝑒𝑣𝑎𝑛𝑡𝑒𝑟 𝑉𝑜𝑟𝑠𝑐ℎ𝑙ä𝑔𝑒

𝐴𝑛𝑧𝑎ℎ𝑙 𝑒𝑥𝑖𝑠𝑡𝑖𝑒𝑟𝑒𝑛𝑑𝑒𝑟 𝐴𝑏ℎä𝑛𝑔𝑖𝑔𝑘𝑒𝑖𝑡𝑒𝑛

(16)

Dabei ist zu berücksichtigen, dass sich Präzision und Trefferquote häufig gegenläufig

zueinander verhalten. So ist es möglich eine Trefferquote von 100 % zu erreichen in-

dem bei allen bislang Tracelink-freien Elementekombinationen ein Vorschlag gene-

riert wird. In diesem Fall wäre jedoch die Präzision sehr gering, da viele falsch positive

Tracelinks vorgeschlagen werden [Manning et al. 2009, S. 156].

Auch Hayes et al. nutzen diese Messgrößen, um ihren Prototyp RETRO (siehe Kapi-

tel 6.1.2) hinsichtlich seiner Effektivität zu bewerten. Zu diesem Zweck geben sie an,

welche Werte für die beiden Größen „Präzision“ und „Trefferquote“ „akzeptabel“,

„gut“ und „exzellent” sind [Hayes et al. 2006, S. 11]. Bei diesen Werten handelt es sich

um Erfahrungswerte, welche in industriellen Projekten durch die Analyse zahlreicher

(automatisch und manuell generierter) Abhängigkeitsmatrizen gewonnen wurden.

Während bei einer exzellenten Präzision und Trefferquote kaum noch manuelle Kor-

rekturen notwendig sind, bedeutet ein akzeptabler Wert, dass der Anwender ohne

Unterstützung ähnlich effektiv sein würde. Die Autoren betonen dabei, dass es sich

bei diesen Werten um erste Abschätzungen handelt und Feedback willkommen sei

[Hayes et al. 2006, S. 11]. Die Werte sind in Tabelle 21 zusammengestellt.

Akzeptabel

Gut

Exzellent

Präzision

20 % - 29 %

30 % - 49 %

50 % - 100 %

Trefferquote

60 % - 69 %

70 % - 79 %

80 % - 100 %

Tabelle 21: Bewertung der Größen Präzision (Precision) und Trefferquote (Recall) [Hayes et

al. 2006, S. 11]

Da dem Autor dieser Arbeit keine alternativen Werte aus der Traceability-Literatur

bekannt sind oder aus eigenen Projekten zur Verfügung stehen, wird sich auch im

Rahmen dieser Arbeit auf diese Werte berufen. Der Vorteil ist, dass eine Vergleich-

barkeit mit den Ergebnissen von Hayes et al. erreicht wird, auch wenn die Spannen

der Werte (bspw. exzellente Präzision = 50 % - 100 %) nicht verifiziert werden können.

Methoden zur Pflege von Tracelink-Modellen

154

6.3 TRACEEVALUATION – METHODE ZUR VERTEILTEN BEWERTUNG VON TRACELINKS

Die Methode TraceEvaluation dient der Bewertung bestehender Tracelinks, um falsch

positive Tracelinks zu identifizieren und somit die Qualität des Tracelink-Modells ent-

wicklungsbegleitend zu verbessern. Sie basiert auf den in Kapitel 6.2.1 beschriebenen

Grundlagen des Crowdsourcings und adressiert die Hypothese 2, die postuliert, dass

Nutzer bei der Interaktion mit dem Traceability-Modell falsch modellierte Tracelinks

bemerken. Damit ist ein ergänzender Einsatz von TraceEvaluation immer möglich,

wenn Tracelinks für die Unterstützung der Entwicklungsprozesse verwendet werden

(siehe auch Kapitel 3.4.2). Eine erste Veröffentlichung des zugrundeliegenden Kon-

zepts erfolgte in [Stark et al. 2010].

Ein in [Beier et al. 2012] dokumentierter Ansatz stellt den Anwendern bspw. das Ab-

hängigkeitsnetz in Form des Visualisierungswerkzeugs Ariadne’s Eye zur Verfügung,

um damit unterschiedliche Aufgaben im Kontext der Systementwicklung durchzufüh-

ren (siehe Kapitel 3.6.4.3). Durch die Visualisierung der Abhängigkeiten zwischen den

Artefakten eines Systems kann so bspw. die Schaffung eines Systemverständnisses un-

terstützt werden. Darüber hinaus verfügt Ariadne’s Eye über einen Assistenten zur

Durchführung von Auswirkungsanalysen zur Vorbereitung von Änderungen. Ariadne’s

Eye soll durch eine Vielzahl unterschiedlicher Entwickler genutzt werden.

Im Kontext dieser Arbeit dient Ariadne’s Eye als beispielhafter Ansatz zur Verwendung

des Tracelink-Modells auf den die Methode TraceEvaluation aufsetzt. Während der

zuvor erwähnten Routineaufgaben kann TraceEvaluation somit nebenbei angewen-

det werden, um kontinuierlich die Qualität des Abhängigkeitsnetzes zu verbessern.

Anwender sind dabei unterschiedliche Experten der an der Entwicklung des mechat-

ronischen Systems beteiligten Disziplinen.

6.3.1 FUNKTIONSPRINZIP DER METHODE TRACEEVALUATION

Die Methode TraceEvaluation zielt auf die entwicklungsbegleitende Verbesserung

der Qualität des Tracelink-Modells durch die Nutzer der Tracelinks. Während an der

Erfassung der Tracelinks nur eine sehr begrenzte Anzahl an Personen beteiligt ist, kann

TraceEvaluation von einer großen Anzahl an Entwicklern verwendet werden. Diese

können dabei ihr Expertenwissen für diesen parallelen Qualitätssicherungsprozess oh-

ne großen Aufwand im Sinne eines Crowdsourcing-Ansatzes zur Verfügung stellen,

indem sie Verbesserungsvorschläge für die von Ihnen betrachteten Bereiche des

Tracelink-Modells generieren.

Konkret sieht die TraceEvaluation vor, im Kontext der unterschiedlichen Methoden zur

Verwendung von Tracelinks die technische Möglichkeit zur Bewertung bereits model-

lierter Tracelinks bereitzustellen. Dies ist in Abbildung 65 für die Nutzer 1 und n exemp-

Methoden zur Pflege von Tracelink-Modellen

155

larisch für eine beliebig große Anzahl von n Nutzern dargestellt (Zeilen „Nutzer 1“ und

„Nutzer n“).

Nutzer 1 führt bspw. eine Auswirkungsanalyse durch und verwendet zu diesem Zweck

das Traceability-Modell. Ausgehend von einem zu ändernden Element (bspw. einem

Bauteil) verfolgt er somit die Tracelinks zu Anforderungen, Funktionen und anderen

Bauteilen, um zu bewerten, ob diese von der Änderung betroffen sind. Bei dieser Tä-

tigkeit, bei der die Abhängigkeit von jeweils zwei verknüpften Elementen zur Zeit be-

wertet wird, erkennt der Nutzer leicht Tracelinks, deren Korrektheit er bezweifelt. Für

diesen Zweck wird ihm durch TraceEvaluation eine Funktionalität zum Melden dieses

Zweifels in seinem Autorenwerkzeug zur Verfügung gestellt. Bei Meldung eines

Tracelinks wird das Feedback zusammen mit dem entsprechenden Tracelink als At-

tribut gespeichert.

Gleiches gilt für den Nutzer n, der bei der Durchführung einer FMEA die Tracelinks

verwendet, um für eine gegebene Funktion die zugehörigen Fehler aus einem Feh-

lerbaum sowie Entdeckungsmaßnahmen und Vermeidungsmaßnahmen zusammen-

zustellen und somit einen FMEA-Vordruck zu füllen (vgl. [Beier et al. 2011]). Fälschli-

cherweise verknüpfte Elemente fallen auf und können mittels integrierter TraceEva-

luation-Funktionalität gemeldet werden.

Abbildung 65: Ablauf der Methode TraceEvaluation

Methoden zur Pflege von Tracelink-Modellen

156

Dabei ist diese Bewertung nicht die hauptsächliche Aufgabe der Nutzer, sondern

vielmehr können Zweifel über die Korrektheit der Tracelinks, die sich während der Er-

ledigung ihrer eigentlichen Aufgabenstellung ergeben, quasi im Vorbeigehen doku-

mentiert werden.

Die Auswertung der angezweifelten Tracelinks erfolgt zeitlich unabhängig von deren

Erfassung (siehe Abbildung 65, Zeile „Qualitätsbeauftragter“). Zu einem beliebigen

Zeitpunkt kann der Qualitätsbeauftragte die Auswertung des Feedbacks durchfüh-

ren. Dazu werden die in der Datenbank des ModelTracers gespeicherten Attribute

ausgelesen und die angezweifelten Tracelinks in aggregierter Form dargestellt. Diese

werden nacheinander überprüft und entschieden, ob tatsächlich fälschlicherweise

ein Tracelink modelliert wurde. Ggf. ist es dafür notwendig sich mit den jeweiligen Ex-

perten, die an der Erstellung der betroffenen Artefakte beteiligt waren, abzustimmen.

Wird dabei erkannt, dass keine Abhängigkeit zwischen den verknüpften Elementen

besteht, wird der Tracelink gelöscht oder andernfalls, wenn sich der Nutzer in seiner

Bewertung geirrt hatte, die Meldung verworfen.

Die Methode TraceEvaluation wurde dabei unter Berücksichtigung der Taxonomie

von Geiger et al. entwickelt (siehe Abbildung 64) [Geiger et al. 2011, S. 2] und wird im

Folgenden anhand der vier dort aufgegriffenen Kategorien charakterisiert.

Vorauswahl der Mitwirkenden. Die Vorauswahl der Mitwirkenden wird sowohl kon-

textspezifisch als auch qualifikationsbasiert vorgenommen. Der Kontext ergibt sich

daraus, dass nur Mitarbeiter der eigenen Firma bzw. berechtigte Zulieferer Zugriff auf

die Tracelinks haben. Allerdings wird dieser Pool an Mitarbeitern noch weiter hinsicht-

lich ihrer Qualifikation eingeschränkt. Diese Einschränkung ergibt sich dadurch, dass

nur Mitarbeiter, die sich im Tagesgeschäft mit Artefakten und den zugehörigen

Tracelinks befassen, auch zu deren Bewertung herangezogen werden.

Zugänglichkeit der einzelnen Teilergebnisse. Die Zugänglichkeit der Teilergebnisse der

Mitarbeiter untereinander ist im vorliegenden Konzept von TraceEvaluation nicht ge-

geben. Dies ist insofern auch nicht notwendig, da jeweils nur die Einschätzung der

einzelnen Personen gefragt ist und diese nicht durch die Einschätzung anderer be-

einflusst werden soll.

Aggregation der Teilergebnisse. Bei der Aggregation der Teilergebnisse wird ein in-

tegrativer Ansatz gewählt, bei dem alle Inputs der Mitarbeiter berücksichtigt und hin-

sichtlich ihrer Korrektheit bewertet werden.

Entlohnung für Teilergebnisse. Eine Entlohnung für die Bereitstellung von Feedback

bzgl. potenziell falscher Tracelinks ist in der aktuellen Umsetzung des Konzepts nicht

vorgesehen, da zunächst dessen Validierung im Vordergrund steht. Da die Entloh-

nung für die Erbringung von Teilergebnissen jedoch einen wichtigen Aspekt hinsicht-

Methoden zur Pflege von Tracelink-Modellen

157

lich der Motivation bei der Mitwirkung darstellt, ist eine Erweiterung des Konzepts in

weiteren Ausbaustufen denkbar. So könnten bspw. Anreize für jeden vorgeschlage-

nen Tracelink, der sich nach Überprüfung tatsächlich als falsch herausstellt, geschaf-

fen werden. Was diese Anreize genau sind, wäre dann allerdings im jeweiligen Fir-

menkontext festzulegen.

In Anlehnung an Abbildung 63 wurde in Abbildung 66 die Methode TraceEvaluation

als Crowdsourcing-System dargestellt.

Abbildung 66: TraceEvaluation als Crowdsourcing-System in Anlehnung an [Geiger et al.

2011, S. 2]

Wie zuvor bereits in Abbildung 65 dargestellt besteht das Crowdsourcing-System Tra-

ceEvaluation aus zwei Teilen, die in der Implementierung berücksichtigt werden müs-

sen: der Erfassung und der Auswertung des Feedbacks bzgl. der Korrektheit der

Tracelinks. Im Folgenden werden diese beiden Teile im Zusammenhang mit deren

prototypischer Implementierung erläutert.

6.3.2 PROTOTYPISCHE IMPLEMENTIERUNG DER METHODE TRACEEVALUATION

Um die Wirksamkeit der Methode TraceEvaluation im Rahmen einer Studie und damit

den Wahrheitsgehalt der zugehörigen Hypothese 2 überprüfen zu können, wurde

TraceEvaluation prototypisch implementiert. Der Prototyp besteht dabei, entspre-

chend der zweiteiligen Methode, aus zwei Modulen: dem Anwendermodul, mit dem

das Feedback der Nutzer erfasst wird, und dem Auswertungsmodul, welches als Plug-

In im ModelTracer umgesetzt wurde und der Auswertung des Feedbacks dient.

Das Anwendermodul wurde im Prototyp exemplarisch auf den Traceability-Viewer

Ariadne’s Eye aufgesetzt. Dessen Konzept sieht vor, die Schnittstelle zwischen Ent-

wickler und Traceability-Modell bereitzustellen. Ariadne’s Eye zielt somit auf eine gro-

Methoden zur Pflege von Tracelink-Modellen

158

ße Anwenderzahl, was für die Wirksamkeit der TraceEvaluation einen wichtigen As-

pekt darstellt. Insbesondere die Auswirkungsanalysen eignen sich dabei für die Identi-

fikation falscher Tracelinks, da bei der Änderung eines Elements die Tracelinks zu

möglicherweise betroffenen Elementen nachverfolgt werden. Somit werden die

Tracelinks nicht einfach nur als gegeben hingenommen, sondern deren Korrektheit

im Kontext der betrachteten Änderung und damit unterbewusst auch im Allgemei-

nen bewertet.

Abbildung 67: Melden eines falschen Tracelinks in Ariadne's Eye

In der prototypischen Implementierung von Ariadne’s Eye können die Nutzer

Tracelinks, die auf Basis der eigenen Expertise als falsch bewertet werden, auswäh-

len, mit einem Rechtsklick ein Kontextmenü aufrufen und ihren Zweifel an deren Kor-

rektheit melden (siehe Abbildung 67). Dies kann neben der Bearbeitung der eigentli-

chen Aufgabenstellung (z. B. der Durchführung einer Auswirkungsanalyse), ohne den

eigentlichen Arbeitsprozess signifikant zu stören, durchgeführt werden.

Die erfassten Bewertungen werden in der ModelTracer-Datenbank gemeinsam mit

den Tracelinks in Form des Attributs „doubtcounter“ gespeichert. Bei dem Attribut

handelt es sich um einen Zähler, der initial auf „0“ steht und bei jeder Meldung durch

einen Anwender inkrementell erhöht wird.

Der für die durchgängige Nachverfolgbarkeit Qualitätsbeauftragte kann zu jeder Zeit

das Auswertungsmodul im ModelTracer aufrufen und eine Qualitätsüberprüfung des

Methoden zur Pflege von Tracelink-Modellen

159

Tracelink-Modells starten, um sich die Ergebnisse der TraceEvaluation anzeigen zu las-

sen.

Abbildung 68: Auswertungsmodul zur Analyse der gemeldeten falschen Tracelinks

Dabei besteht die Möglichkeit, einen Schwellwert für das Attribut „doubtcounter“ zu

definierten, ab dem angezweifelte Tracelinks in der Zusammenstellung des Feed-

backs angezeigt werden. Ziel dieses Schwellwerts ist es, die Signifikanz der Meldung

zu erhöhen, indem bspw. mindestens zwei Meldungen eines Tracelinks verlangt wer-

den, bevor dieser auf seine Richtigkeit hin überprüft wird. Da sich der Wert dabei

nicht allgemeingültig festlegen lässt, sondern bspw. von der Unternehmensgröße und

der Anzahl der Traceability-Anwender abhängt, kann er individuell im Rahmen der

Qualitätssicherung angepasst und z. B. schrittweise verringert werden.

Eine denkbare Erweiterung dieses Konzepts wäre es, die Meldungen rollenbezogen

auszuwerten und somit zu erfassen, ob die meldende Person für einen bestimmten

Artefaktbereich besonderer Kompetenzträger ist. Diese Meldung könnte ein höheres

Gewicht erhalten und unabhängig vom festgesetzten Schwellwert immer angezeigt

werden. Eine Umsetzung dieser Erweiterung wurde jedoch in der prototypischen Im-

plementierung nicht durchgeführt.

Zur Erstellung der Übersicht gemeldeter Tracelinks werden die Tracelinks nacheinan-

der vom Auswertungsmodul aus der Datenbank ausgelesen und ihr Attribut „doubt-

counter“ überprüft. Ist keine negative Bewertung vorhanden und das Attribut

„doubtcounter“ somit gleich „0“, wird zur Überprüfung des nächsten Tracelinks über-

gegangen. Sobald das Attribut ungleich „0“ ist, erfolgt ein Abgleich mit dem im vori-

gen Absatz beschriebenen Schwellwert. Je nachdem, ob dieser unter- oder über-

schritten ist, wird entweder zum nächsten ungeprüften Tracelink übergegangen oder

aber der Tracelink dem Qualitätsbeauftragen im Auswertungsmodul unter Angabe

der Anzahl negativer Bewertungen zur Überprüfung vorgeschlagen (siehe Abbil-

dung 69).

Methoden zur Pflege von Tracelink-Modellen

160

Abbildung 69: Algorithmus zur Zusammenstellung angezweifelter Tracelinks

6.3.3 EVALUATION DER METHODE TRACEEVALUATION

In Hypothese 2 wurde postuliert, dass Nutzer während der Interaktion mit dem Trace-

ability-Modell falsch modellierte Tracelinks erkennen, und dass darüber hinaus die

Anzahl der Nutzer einen Einfluss auf die Vollständigkeit der Ergebnisse hat. Ob diese

Hypothese durch die Methode TraceEvaluation bestätigt werden kann, wurde mit

Hilfe einer Studie evaluiert. Der Aufbau und die Durchführung der Studie werden im

folgenden Kapitel 6.3.3.1 beschrieben und die Ergebnisse in Kapitel 6.3.3.2 ausgewer-

tet. Die Diskussion erfolgt dann im Rahmen der Zusammenfassung in Kapitel 6.3.4.

6.3.3.1 AUFBAU UND DURCHFÜHRUNG DER STUDIE

Um die Hypothese 2 überprüfen zu können ist es notwendig, Probanden eine von der

Qualitätssicherung losgelöste Aufgabenstellung anhand eines fehlerhaften Tracelink-

Modells bearbeiten zu lassen und ihnen dabei die Möglichkeit zur Verfügung zu stel-

len, falsche Tracelinks zu melden.

Der Aufbau der Studie sah daher vor, dass die Probanden drei Auswirkungsanalysen

für sich ändernde Anforderungen bzw. Bauteilen mit Hilfe des Viewers Ariadne’s Eye

durchführen. Konkret handelte es sich um die folgenden Anforderungen und Bautei-

le die sich laut Aufgabenbeschreibung geändert hatten und für die potenziell be-

troffene Elemente identifiziert werden sollten (siehe Anhang B, Aufgabe 3):

Methoden zur Pflege von Tracelink-Modellen

161

1. A: Übersetzung mittels Kettenschaltung,

2. A: Muss mit Handkraft betrieben werden können und

3. A: Hinterradantrieb mittels Fußkurbel und Kette,

4. P: Hydraulische Scheibenbremsen

5. P: Hydraulikleitungen

6. P: Bremshebel

7. P: Bremsscheiben

Zur Bearbeitung der Aufgabenstellungen erhielten die Probanden die Anforderungs-,

Funktions- und Produktstrukturartefakte eines Fahrrads sowie ein vollständiges

Tracelink-Modell, welches im Vorfeld der Studie während eines Workshops erstellt

wurde. Zusätzlich wurden in dieses Tracelink-Modell vorab neun fehlerhafte Tracelinks

integriert, die in Tabelle 22 als Kombination ihrer Start- und Zielelemente zusammen-

gestellt sind.

Nr.

Quellelement

Zielelement

A1.1.2 Übersetzung mittels Kettenschaltung

P1.6.2 Sattel

A1.1.2 Übersetzung mittels Kettenschaltung

P1.7.3 Beleuchtung

A1.1.1 Hinterradantrieb mittels Fußkurbel

und Kette

P1.2.1 hydraulische Federgabel

A1.1.1 Hinterradantrieb mittels Fußkurbel

und Kette

P1.4.2 Schaltwerk

P1.5.3 Hydraulikleitungen

F1.6 Federung/Dämpfung

P1.5.2 Bremshebel

A1.4.1 Unebenheiten im Gelände und Fahrbelag

ausgleichen

P1.5.2 Bremshebel

F1.5.2 Licht reflektieren

P1.5.4 Bremsscheiben

A1.1.1 Hinterradantrieb mittels Fußkurbel und Kette

P1.5.4 Bremsscheiben

F1.3.1 Steuersignal aufnehmen

Tabelle 22: Elementepaare, zwischen denen im Vorfeld der Studie falsche Tracelinks mo-

delliert wurden

Die Durchführung der Evaluation wurde in die im Kapitel 5.4.5 beschriebene Studie in-

tegriert. Dabei wurde mit einer Einführung in die Interaktionsfunktionalitäten der un-

terschiedlichen genutzten Prototypen begonnen. Für Ariadne’s Eye war dies u. a. die

zuvor beschriebene Funktionalität zum Anzweifeln von Tracelinks. In diesem Zusam-

menhang wurden die Probanden darauf hingewiesen, dass sie wenn möglich zur

Qualitätsverbesserung des Tracelink-Modells beitragen sollten. Anschließend wurde

zunächst die Modellierung von Tracelinks zwischen den Artefakten mit Hilfe der Me-

thode EcoTracing durchgeführt. Dies hatte den Vorteil, dass eine grundsätzliche

Kenntnis der drei Artefakte (Anforderungsmodell mit 10 Anforderungen und 3 sortie-

rende Überschriften, Funktionsliste mit 20 Funktionen und Produktstruktur mit 29 Bau-

teilen und Baugruppen) vorausgesetzt werden konnte (siehe Abbildung 58). An-

schließend sollte die zuvor erwähnte Auswirkungsanalyse durchgeführt werden. Es

Methoden zur Pflege von Tracelink-Modellen

162

wurde hier nur am Rande auf die Funktionalität zur Meldung falscher Tracelinks hin-

gewiesen.

In Tabelle 23 sind die Eigenschaften der Studie in Tabellenform als Steckbrief zusam-

mengefasst.

Analyseeinheit

Meldungen falscher Tracelinks durch die Probanden

Analysemethode

Häufigkeit und Vollständigkeit der Meldung falscher Tracelinks

Methode zur

Datenerfassung

Verwendung des Anwendermoduls der prototypischen Imple-

mentierung der Methode TraceEvaluation zur Erfassung der Mel-

dungen der Probanden und Analyse im Auswertungsmodul

Aufgabenstellung

Durchführung von Auswirkungsanalysen bei Änderungen vorge-

gebener Elemente; Meldung falscher Tracelinks nur nebenbei

erwähnt; realistische Aufgabenstellung, die an industrielle Auf-

gabenstellungen angelehnt ist, sich jedoch in Ausprägung der

Artefakte hinsichtlich Umfang und Komplexität unterscheidet

Anzahl der Teilnehmer

Charakterisierung der

Teilnehmer

Studentische Hilfskräfte und wissenschaftliche Mitarbeiter aus

dem Bereich Virtuelle Produktentstehung des Fraunhofer IPK und

dem Fachgebiet Industrielle Informationstechnik der Technischen

Universität Berlin; Grundsätzliche Kenntnisse über Artefakte, deren

Entwicklung und Abhängigkeiten zwischen diesen vorhanden

Untersuchungsobjekt

Drei Artefakte eines Fahrrads:

- Anforderungsmodell mit 10 Anforderungen und 3 sortie-

renden Überschriften mit zwei Hierarchieebenen

- Funktionsliste mit 20 Funktionen auf zwei Hierarchieebe-

nen

- Produktstruktur mit 29 Bauteilen und Baugruppen auf zwei

Hierarchieebenen

Vollständiges Tracelink-Modell, welches durch neun fehlerhafte

Tracelinks ergänzt wurde

Tabelle 23: Eigenschaften der Studie zur Überprüfung der Hypothese 2

6.3.3.2 AUSWERTUNG DER STUDIE

Von 19 Probanden nutzten 13 während der Durchführung der Auswirkungsanalysen

zusätzlich die Möglichkeit falsche Tracelinks zu melden. Insgesamt wurden 74 mal

Tracelinks zur erneuten Prüfung vorgeschlagen wovon 65 Meldungen (88 %) mit den

bei der Vorbereitung der Studie hinzugefügten falschen Tracelinks übereinstimmten.

Neun Tracelinks (12 %) wurden im Vergleich zu den im Workshop erarbeiteten

Tracelinks fälschlicherweise gemeldet (siehe Tabelle 24). Alle Tracelinks müssten in der

Realität einer genaueren Prüfung unterzogen werden, es sei denn, der eingestellte

Schwellwert würde dies vermeiden.

Methoden zur Pflege von Tracelink-Modellen

163

Korrekte Meldung fal-

scher Tracelinks

Fälschliche Meldung

korrekter Tracelinks

Gesamte

Anzahl

Meldungen

Präzision

Treffer-

quote

Proband 1

100 %

67 %

Proband 2

75 %

33 %

Proband 3

100 %

56 %

Proband 4

Proband 5

78 %

Proband 6

88 %

78 %

Proband 7

100 %

67 %

Proband 8

100 %

78 %

Proband 9

88 %

78 %

Proband 10

100 %

56 %

Proband 11

75 %

33 %

Proband 12

Proband 13

Proband 14

50 %

11 %

Proband 15

Proband 16

75 %

33 %

Proband 17

Proband 18

83 %

56 %

Proband 19

Gesamt

88 %

100 %

Relativ

88 %

12 %

100 %

Tabelle 24: Meldung von Tracelinks pro Proband

Die insgesamt 74 gemeldeten Tracelinks verteilen sich auf insgesamt 15 Elemente-

kombinationen (siehe Tabelle 25), wovon neun Elementekombinationen korrekter-

und sechs fälschlicherweise gemeldet wurden. Bei der Betrachtung der Häufigkeit

der Nennung dieser 15 Tracelinks fällt auf, dass die bewusst integrierten falschen

Tracelinks mit einem Durchschnittswert von 7,2 mal durch die Probanden genannt

wurden (zwischen 2 und 10 mal), während die fälschlicherweise gemeldete Trace-

links durchschnittlich lediglich 1,5 mal gemeldet wurden (zwischen 1 und 2 mal). Die

Verwendung eines Schwellwerts für den Bewertungszähler würde in diesem Zusam-

menhang also Sinn machen. Gesetzt den Fall, er würde auf mind. zwei Nennungen

definiert werden, könnten immerhin drei der sechs fälschlicherweise gemeldeten

Tracelinks aus der Analyseübersicht herausgefiltert werden. Die Ergebnisse zeigen je-

doch auch, dass in diesem Zusammenhang Vorsicht geboten ist, da die Differenz der

Häufigkeit der Nennung zwischen korrekten und falschen Tracelinks nicht so groß ist,

dass die Tracelinks eindeutig bzw. automatisch bewertet werden können. Würde

bspw. der Schwellwert auf drei gesetzt werden, würden zwar alle fälschlicherweise

gemeldeten Tracelinks herausgefiltert, jedoch auch ein falscher Tracelink, der eigent-

lich zu untersuchen wäre. Der Wert lässt sich, wie erwähnt, nicht allgemeingültig fest-

Methoden zur Pflege von Tracelink-Modellen

164

legen, sondern hängt bspw. von der Unternehmensgröße ab und muss somit auf Ba-

sis der Erfahrung individuell festgelegt werden.

Quellelement

Zielelement

Häufigkeit

Nennung

Korrekte Meldung falscher Tracelinks

A1.1.1 Hinterradantrieb mittels Fuß-

kurbel und Kette

P1.2.1 hydraulische Federgabel

A1.1.1 Hinterradantrieb mittels Fuß-

kurbel und Kette

P1.5.4 2 Bremsscheiben

A1.1.1 Hinterradantrieb mittels Fuß-

kurbel und Kette

P1.4.2 Schaltwerk (Übersetzung hin-

ten)

A1.1.2 Übersetzung mittels Ketten-

schaltung

P1.6.2 Sattel

A1.1.2 Übersetzung mittels Ketten-

schaltung

P1.7.3 Beleuchtung

A1.4.1 Unebenheiten im Gelände

und im Fahrbelag ausgleichen

P1.5.2 2 Bremshebel

F1.3.1 Steuersignal aufnehmen

P1.5.4 2 Bremsscheiben

F1.5.2 Licht reflektieren

P1.5.2 2 Bremshebel

F1.6 Federung/Dämpfung

P1.5.3 2 Hydraulikleitungen

Fälschliche Meldung korrekter Tracelinks

A1.1.1 Hinterradantrieb mittels Fuß-

kurbel und Kette

P1.3.3 Hinterrad

A1.2 Bremsen

P1.5.3 2 Hydraulikleitungen

A1.2.1 Verschmutzungsrisiko minimie-

ren

P1.5.1 2 hydraulische Scheibenbrem-

sen

A1.2.1 Verschmutzungsrisiko minimie-

ren

P1.5.4 2 Bremsscheiben

A1.2.3 muss mit Handkraft betrieben

werden können

P1.5.1 2 hydraulische Scheibenbrem-

sen

F1.2.2 Kraft leiten

P1.5.4 2 Bremsscheiben

Tabelle 25: Übersicht der Elementepaare, die von den Probanden als falsch gemeldet

wurden

Beim Abgleich von Tabelle 22 mit Tabelle 25 fällt auf, dass alle falschen Tracelinks, die

vorsätzlich in das Tracelink-Modell integriert wurden, durch die Probanden identifiziert

wurden, obwohl deren eigentliche Aufgabenstellung eine Auswirkungsanalyse vor-

sah. Die Trefferquote (bezogen auf die Anzahl falscher Tracelinks) für die aggregier-

ten Werte beträgt somit 100 % und die Präzision 88 %. Der erste Teil der Hypothese 2

wurde somit durch die Studie bestätigt: während der Interaktion mit dem Traceabili-

ty-Modell fallen Nutzern falsch modellierte Tracelinks auf. Dass, wie durch den zwei-

ten Teil der Hypothese 2 postuliert, die Anzahl der Probanden einen Einfluss auf die

Vollständigkeit der Ergebnisse hat, lässt sich Tabelle 22 entnehmen. Keiner der Pro-

Methoden zur Pflege von Tracelink-Modellen

165

banden hat allein alle neun falsch modellierten Tracelinks identifizieren können.

Durch die Kombination der Ergebnisse aller 19 Probanden konnten jedoch alle fal-

schen Tracelinks identifiziert werden. Dieses Ergebnis lässt den Schluss zu, dass die Me-

thode TraceEvaluation in der industriellen Anwendung einer Vielzahl an Nutzern zur

Verfügung gestellt werden sollte, um möglichst viele fehlerhafte Tracelinks zu identifi-

zieren.

6.3.4 ZUSAMMENFASSUNG UND DISKUSSION

Das Kapitel 6.3 adressierte die Forschungsfrage, ob Crowdsourcing-Methoden ge-

nutzt werden können, um die Qualität des Tracelink-Modells zu verbessern (siehe Ka-

pitel 4.2). Die in diesem Zusammenhang formulierte Hypothese postuliert, dass Fehler

im Traceability-Modell quasi nebenbei bei der Verwendung von Traceability-

Modellen identifiziert und gemeldet werden können, und dass die Anzahl der Nutzer

eine Auswirkung auf die Vollständigkeit der Ergebnisse hat.

Auf dieser Hypothese aufbauend wurde die Crowdsourcing-Methode TraceEvaluati-

on entwickelt, die den Anwendern von Tracelinks erstmals im Kontext der Traceability

bei beliebigen Aufgabenstellungen eine Art Add-on zur Verfügung stellt, mit dessen

Hilfe falsche Tracelinks einfach gemeldet werden können. Ergänzt wird dieses Add-

on durch ein Modul zur Auswertung, in dem die Meldungen potenziell falscher

Tracelinks aggregiert und ausgewertet werden können.

Um die Wirksamkeit der Methode und damit die Hypothese 2 evaluieren zu können,

wurde eine prototypische Implementierung vorgenommen, die auf dem Viewer Ari-

adne’s Eye aufsetzt. Darüber wird den Anwendern in ihrem alltäglichen Arbeitsum-

feld die Möglichkeit zur Verfügung stellt, Bewertungen abzugeben. Auf Basis der pro-

totypischen Implementierung wurde eine Studie durchgeführt, bei der die Proban-

den im Rahmen von Auswirkungsanalysen von Änderungen betroffene Bauteile iden-

tifizieren sollten. Um den industriellen Anwendungsfall zu simulieren war die Qualitäts-

sicherung lediglich eine am Rande erwähnte Zusatzoption, die jedoch von der Mehr-

zahl der Probanden wahrgenommen wurde.

In der Studie gelang es, die Hypothese 2 zu bestätigen, denn alle vorsätzlich im Bei-

spiel platzierten falschen Tracelinks wurden durch die Probanden identifiziert, obwohl

eigentlich eine andere Aufgabenstellung bearbeitet werden sollte. Die so erreichte

Trefferquote von 100 % sowie die Präzision von 88 % sind als exzellent zu bewerten.

Andererseits gelang es keinem einzelnen Probanden, alle falschen Tracelinks zu iden-

tifizieren – die Anzahl der Probanden hat somit eine Auswirkung auf die Vollständig-

keit der Analyse.

Methoden zur Pflege von Tracelink-Modellen

166

Im Rahmen der Studie wurden durch die Probanden auch korrekte Tracelinks als po-

tenziell falsch eingeordnet, was bei der Auswertung zusätzliche Aufwände bei der

Bewertung der Meldungen bedeutet. Jedoch waren diese Meldungen mit einem

Anteil von 12 % an der Gesamtanzahl gemeldeter Tracelinks in der Minderheit. Es

zeigte sich in diesem Zusammenhang zudem, dass die Anzahl an Meldungen bei tat-

sächlich falschen Tracelinks mit durchschnittlich 7,5 Nennungen deutlich höher als

bei fälschlicher Weise gemeldeten Tracelinks (durchschnittlich 1,5 Nennungen) war.

Ein Schwellwert würde an dieser Stelle helfen, die Anzahl fälschlicherweise gemelde-

ter Tracelinks und somit den Aufwand für deren Bewertung zu reduzieren. Die Höhe

des Schwellwerts ist jedoch nicht verallgemeinerbar und birgt zudem die Gefahr

Meldungen tatsächlich falscher Tracelinks auszublenden.

Wie auch schon in der Diskussion in Kapitel 5.5 angemerkt, gilt im Übrigen auch im Zu-

sammenhang mit der Methode TraceEvaluation, dass die Entscheidung für oder ge-

gen einen Tracelink sehr stark durch die subjektive Interpretation der inhaltlichen Be-

deutung der Elemente und des Konzepts „Tracelink“ durch den Anwender beein-

flusst ist. Eine eindeutige Kategorisierung der Tracelinks in „richtig“ und „falsch“ ist so-

mit nicht einfach möglich. Jedoch gelingt es mit der Methode TraceEvaluation, po-

tenziell falsche Tracelinks, die durch viele Benutzer gemeldet werden, an einer zent-

ralen Stelle aggregiert zu analysieren. Der für die durchgängige Nachverfolgbarkeit

zuständige Entwickler kann nach Auswertung der Meldungen in Diskussionen mit den

Fachexperten versuchen, eine einheitliche Sicht auf das Konzept „Tracelink“ einzu-

bringen und somit die Qualität des Tracelink-Modells langfristig steigern.

6.4 TRACELEGACY – METHODE ZUR IDENTIFIKATION FEHLENDER TRACELINKS

Wie in Kapitel 6.1.3 diskutiert, basieren die meisten Methoden des Stands der Technik

darauf, Vorschläge für Tracelinks durch einen Vergleich der Bezeichnungen bzw. der

detaillierten Beschreibungen der Elemente der Artefakte, zwischen denen eine

durchgängige Nachverfolgbarkeit hergestellt werden soll, zu generieren. Für diesen

Vergleich kommen unterschiedlich komplexe Algorithmen zum Einsatz, um auf

sprachlicher bzw. inhaltlicher Ebene eine Ähnlichkeit der Elemente zu identifizieren.

Problematisch ist dabei, dass ähnliche Begriffe verwendet werden müssen, um eine

Abhängigkeit zu identifizieren. Selbst wenn eine Synonymbildung angewendet wird,

um eventuell genutzte Ausdrücke mit gleicher oder ähnlicher Bedeutung zu erken-

nen, ist es notwendig, dass die Elemente in den betrachteten Artefakten mit einem

ähnlichen Vokabular beschrieben werden. Während dies zwischen einer Anforde-

rungsspezifikation und einer Funktionsstruktur u. U. funktioniert, da bspw. die ge-

wünschten Funktionen explizit in den Anforderungen benannt werden, stoßen diese

Ansätze bei der Analyse von Funktionsstrukturen in Kombination mit Produktstrukturen

Methoden zur Pflege von Tracelink-Modellen

167

u. U. an ihre Grenzen, da die Bauteile häufig nicht nach ihren Funktionen benannt

werden.

Vor diesem Hintergrund stellt sich die Forschungsfrage, ob Wissen, welches mithilfe

von Tracelinks in vergangenen Projekten dokumentiert wurde, geeignet ist, um in ak-

tuellen Projekten zur Steigerung der Qualität des Tracelink-Modells beizutragen.

Durch den Autor dieser Arbeit wurde die Hypothese aufgestellt, dass auf dieser Wis-

sensbasis Vorschläge für fehlende Tracelinks generiert werden können. Um diese Hy-

pothese zu evaluieren, wurde die Methode TraceLegacy entwickelt und prototy-

pisch evaluiert. Dabei stand nicht die Optimierung der Methode, sondern nur die

grundsätzliche Überprüfung der Machbarkeit im Fokus. Während das grundlegende

Funktionsprinzip der Methode im folgenden Kapitel 6.4.1 beschrieben wird, erfolgt die

Beschreibung des entwickelten Algorithmus in Kapitel 6.4.2 und dessen prototypische

Implementierung in Kapitel 6.4.3. Die Evaluierung der Methode wird in Kapitel 6.4.4

erläutert und die Ergebnisse der Untersuchung sowie Potenziale der Weiterentwick-

lung in Kapitel 6.4.5 diskutiert.

6.4.1 FUNKTIONSPRINZIP DER METHODE TRACELEGACY

Wie beschrieben, greift die Methode TraceLegacy auf Entwicklungswissen aus ver-

gangenen, ähnlichen Projekten zurück, um Vorschläge für fehlende Tracelinks zu ge-

nerieren

. Dabei werden nicht die aktuellen Artefakte untereinander, sondern mit

Artefakten aus Vorgängerprojekten (engl.: Legacy Projects) verglichen, die zugehö-

rigen Tracelinks aus Vorgängerprojekten analysiert und so Vorschläge für neue

Tracelinks generiert. Das Funktionsprinzip der Methode ist in Abbildung 70 dargestellt.

Tracelinks, die in einem Projekt zwischen Artefakten modelliert werden, werden in ei-

ner zentralen Datenbank gespeichert (Abbildung 70, A), um zu einem späteren Zeit-

punkt wieder darauf zurückgreifen zu können. Werden in einem neuen Projekt die-

selben Artefakt-Typen auf Abhängigkeiten zueinander untersucht, wird eine Anfrage

an die Datenbank gesendet, um zu ermitteln, ob eine ähnliche Elementekombinati-

on bereits zu einem früheren Zeitpunkt schon einmal per Tracelink verknüpft war

(Abbildung 70, B). Ist dies der Fall wird ein Vorschlag für einen zu modellierenden

Tracelink im aktuellen Projekt ausgegeben (Abbildung 70, C).

Das Funktionsprinzip sieht somit nicht die linguistische Untersuchung der Elemente von

Artefakten unterschiedlichen, sondern gleichen Typs vor. In dem in Abbildung 70

dargestellten Beispiel werden somit die Anforderungen des aktuellen mit denen des

Vorgängerprojekts verglichen. Das ist insofern vorteilhaft, da die Bezeichner von Ele-

Sie lässt sich somit nutzen, um falsch negative Tracelinks zu identifizieren.

Methoden zur Pflege von Tracelink-Modellen

168

menten gleichen Typs tendenziell eher mit gleichem Vokabular beschrieben werden

und somit die Ähnlichkeit der Elemente leichter festgestellt werden kann.

Abbildung 70: Funktionsprinzip der Methode TraceLegacy

Die potenzielle Abhängigkeit zwischen den Elementen unterschiedlichen Typs im ak-

tuellen Projekt (R1 und F1 in Abbildung 70) wird somit nicht auf Basis der aktuellen Ar-

tefakte sondern auf Basis eines Tracelinks in einem vergangenen Projekt identifiziert.

Dieser Tracelink kann im vergangenen Projekt bspw. in einem manuellen Prozess

durch einen Entwickler modelliert worden sein. Das Wissen des Entwicklers, welches in

Form eines Tracelinks dokumentiert wurde, wird durch Anwendung der Methode

TraceLegacy somit zur Verbesserung der Qualität des aktuellen Tracelink-Modells

wiederverwendet.

6.4.2 ALGORITHMUS DER METHODE TRACELEGACY

Der Algorithmus der Methode TraceLegacy lässt sich in die zwei Arbeitsschritte „Vor-

verarbeitung“ und „Abhängigkeitsanalyse“ unterteilen.

In der Vorverarbeitung werden zunächst die Ähnlichkeiten aktueller Elemente zu de-

nen vergangener Projekte bestimmt. Dabei wird vorbereitend die sog. Stammform-

reduktion durchgeführt, bei der die Worte der Elementbezeichner des aktuellen Pro-

jekts auf ihren Wortstamm reduziert werden. Ziel ist es, verschiedene morphologische

Varianten eines Wortes erkennen zu können. Zunächst werden für die Suche irrele-

Methoden zur Pflege von Tracelink-Modellen

169

vante Bindewörter und Artikel (wie bspw. „und“, „oder“, „der“, „die“, „das“) aus den

Bezeichnern entfernt. Zusätzlich können beliebige Wörter auf einer sog. Negativliste

(engl.: Blacklist) definiert werden, die ebenfalls entfernt und somit im Folgenden igno-

riert werden. Anschließend werden die verbliebenen Wörter des Bezeichners mit Hilfe

des Porter-Stemmer-Algorithmus auf ihren Wortstamm zurückgeführt [Porter 2006].

Dieser Algorithmus verfügt über mehrere Verkürzungsregeln, die nacheinander auf

die Wörter angewendet werden, bis eine minimale Anzahl von Silben übrig bleibt, die

möglichst in allen grammatikalischen Formen der Wörter auftaucht

. Für nähere In-

formationen zur Funktionsweise dieses Algorithmus, der auf [Porter 2013b] zum Down-

load angeboten wird, empfiehlt sich die Lektüre von [Porter 2006] oder [Porter

2013a]. Eine beispielhafte Übersicht zurückgeführter deutscher Verben ist auf [Porter

2013a] zu finden.

Übrig bleibt für jedes Element der beiden betrachteten aktuellen Artefakte ein redu-

zierter Elementbezeichner, welcher aus mehreren auf den Wortstamm reduzierten

Worten besteht. Dieser dient im Folgenden als Suchanfrage, um die Ähnlichkeit zu

Elementen vergangener Projekte über einen einfachen Stringvergleich zu berech-

nen. Der Stringvergleich ermöglicht in der prototypischen Implementierung der Me-

thode die Unterscheidung in „ähnlich“, wenn mindestens ein Wort der reduzierten

Bezeichner übereinstimmt, und „nicht ähnlich“, wenn kein Wort übereinstimmt.

Zum Zweck der Verwaltung der so ermittelten Ähnlichkeitswerte „1“ (ähnlich) und „0“

(nicht ähnlich) existiert für jeden Artefakt-Typ (also Anforderungsspezifikation, Funkti-

onshierarchie, Produktstruktur usw.) eine projektübergreifende Datenbank, in der die

Werte mit Bezug zur Elementekombination dokumentiert werden. Eine schematische

Darstellung dieses Verwaltungsprinzips ist in Abbildung 71 in Form einer Matrix darge-

stellt. Die Elemente aller Projekte werden auf die Zeilen und Spalten verteilt und die

Ähnlichkeitswerte in die gemeinsamen Zellen eingetragen.

Somit entsteht für jeden Artefakt-Typ jeweils eine quadratische Matrix, in der die Ähn-

lichkeit der textuellen Bezeichner der Elemente vergangener und aktueller Projekte

untereinander bewertet wird. Da die Ähnlichkeit nicht gerichtet ist, wird nur eine Hälf-

te der Matrix zur Bewertung der Ähnlichkeiten genutzt. Die Werte auf der Hauptdia-

gonalen sind immer „1“, da die reduzierten Bezeichner mit sich selbst verglichen

werden. Diese vergleichsweise einfache Form der Umsetzung wurde gewählt, da zu-

nächst im Vordergrund stand, die Methode grundsätzlich abzusichern. In einer Wei-

terentwicklung der Methode TraceLegacy wäre es an dieser Stelle sinnvoll, weitere

Methoden (siehe bspw. Kapitel 6.1.2) zu evaluieren, um eine genauere Bewertung

So ist das Ergebnis der Anwendung des Porter-Stemming-Algorithmus für jedes der Wörter

„aufeinanderfolge“, „aufeinanderfolgen“, „aufeinanderfolgend“, „aufeinanderfolgende“,

„aufeinanderfolgenden“, „aufeinanderfolgender“ der Wortstamm „aufeinanderfolg“.

Methoden zur Pflege von Tracelink-Modellen

170

der Ähnlichkeit der textuellen Beschreibungen der Elemente vornehmen zu können

und eine höhere Präzision zu erreichen.

Abbildung 71: Schematische Darstellung der Verwaltung der Ähnlichkeitswerte in Form von

Matrizen

Bei der an die Vorverarbeitung (Erstellung der Ähnlichkeitsmatrizen) anschließenden

Abhängigkeitsanalyse werden alle Elementekombinationen eines aktuellen Projekts,

die bisher noch nicht mit einem Tracelink miteinander verknüpft wurden, hinsichtlich

einer möglichen Abhängigkeit zueinander untersucht. Dabei werden für jede Ele-

mentekombination der Artefakte A und B die folgenden Schritte durchlaufen (siehe

auch Abbildung 72):

1. Für das aktuell betrachtete Element a werden ähnliche Elemente ai vergan-

gener Projekte aus der Übereinstimmungsmatrix A ermittelt. Gleiches gilt für

das Element b, für das ähnliche Elemente bj aus der Übereinstimmungsmatrix B

zusammengestellt werden.

2. Die so ermittelten Elemente ai und bj werden miteinander kombiniert und

überprüft, ob zwischen ihnen in einem vergangenen Projekt eine Abhängig-

keit mit einem Tracelink dokumentiert wurde.

3. Ist dies der Fall, wird eine Empfehlung für die Modellierung eines Tracelinks im

aktuellen Projekt ausgegeben.

Um den Algorithmus näher zu erläutern, wird er im Folgenden anhand des generi-

schen Beispiels aus Abbildung 72 beschrieben. Im aktuellen Projekt werden zwei Arte-

fakte A und B betrachtet, deren Elemente a1 und b1 noch keinen Tracelink zueinan-

der aufweisen. Dem zuvor beschriebenen TraceLegacy-Algorithmus folgend, werden

nun zu a1 und b1 ähnliche Elemente aus den Übereinstimmungsmatrizen A und B er-

mittelt, die alle bis zu diesem Zeitpunkt erstellten Elemente ai und bj beinhalten. Die

Abfrage ergibt für das Element a1, dass a3 und a4 aus einem vergangenen Projekt ei-

ne Ähnlichkeit aufweisen. Für b1 wird das Element b4 zurückgegeben. Diese drei Ele-

mente (a3, a4 und b4) werden miteinander kombiniert und in der ModelTracer Da-

tenbank überprüft, ob in einem früheren Projekt Tracelinks zwischen ihnen modelliert

worden sind. Dies ist für die Kombination a3 / b4 der Fall, weshalb für die aktuelle

Methoden zur Pflege von Tracelink-Modellen

171

Kombination a1 / b1 die Empfehlung ausgegeben wird, diese auf eine Abhängigkeit

zueinander zu überprüfen und ggf. einen Tracelink zu modellieren. Diese Vorgehens-

weise wird für alle Elementekombinationen der beiden Artefakte A und B, die noch

nicht miteinander verknüpft sind, wiederholt.

Abbildung 72: Algorithmus der Abhängigkeitsanalyse mit TraceLegacy

6.4.3 PROTOTYPISCHE IMPLEMENTIERUNG DER METHODE TRACELEGACY

Die Methode TraceLegacy wurde auf Basis des in Kapitel 3.6.4.3 vorgestellten Mo-

delTracers prototypisch implementiert. Sie wird, wie die TraceEvaluation über das

Menü „Quality Check“ gestartet. Die GUI ist in Abbildung 73 dargestellt und wird im

Folgenden erläutert. Bevor die Analyse gestartet wird, kann mit der Auswahlbox (1)

definiert werden, ob eine Stammformreduktion durchgeführt werden soll. Zusätzlich

kann die Negativliste mit Wörtern, die bei der Analyse ignoriert werden sollen, über

den Blacklist-Button (2) aufgerufen werden. Über den Start-Button (3) wird die Vor-

Methoden zur Pflege von Tracelink-Modellen

172

verarbeitung (Erstellung der Übereinstimmungsmatrizen der unterschiedlichen Arte-

fakte) und Abhängigkeitsanalyse gestartet und deren Fortschritt in dem Fortschritt-

balken (4) dargestellt.

Abbildung 73: GUI des Prototyps der Methode TraceLegacy

Nach Abschluss der Analyse werden die Tracelink-Vorschläge im Hauptfenster (5)

dargestellt. Für die Methode TraceLegacy sind dabei die drei ersten Spalten rele-

vant: Start- und Endelement des aktuellen Projekts für die ein Tracelink vorgeschla-

gen wird sowie die Beschreibung, weshalb ein Tracelink zur Überprüfung vorgeschla-

gen wird. Wird einer der Tracelink-Vorschläge im Hauptfenster ausgewählt, werden

zusätzliche Informationen im unteren Bereich des Fensters angezeigt (6). Zum einen

werden die Bezeichner der Elemente, zwischen denen ein Tracelink vorgeschlagen

wird, angezeigt und zusätzlich in Klammern dargestellt, welchem Artefakt-Typ sie an-

gehören. Zum anderen werden die Tracelinks, die zwischen Elementen aus Artefak-

ten vergangener Projekte gefunden wurden und aufgrund derer der Vorschlag ge-

neriert wurde, angezeigt. Der Vorschlag kann, wenn er als korrekt bewertet wird und

demnach im aktuellen Projekt eine Abhängigkeit zwischen den betrachteten Ele-

menten existiert, die bislang noch nicht berücksichtigt wurden, per Klick auf den

„Vorschlag akzeptieren“-Button (7) angenommen und somit ein Tracelink modelliert

werden.

Methoden zur Pflege von Tracelink-Modellen

173

6.4.4 EVALUATION DER METHODE TRACELEGACY

Die Evaluation der Methode TraceLegacy wurde anhand zweier Beispiele durchge-

führt, die unabhängig voneinander von Studenten im Rahmen ihrer Tätigkeit als stu-

dentische Hilfskraft am Fraunhofer IPK bzw. in der Lehrveranstaltung Virtual Enginee-

ring in Industry im Wintersemester 2012/13 am Fachgebiet Industrielle Informations-

technik entwickelt wurden. Im Folgenden Kapitel 6.4.4.1 wird zunächst der Aufbau

dieser Beispiele sowie Vorgehensweise und Durchführung der Evaluation beschrie-

ben. Im Kapitel 6.4.4.2 folgt die Auswertung und Diskussion der Ergebnisse.

6.4.4.1 AUFBAU UND DURCHFÜHRUNG DER EVALUATION

Das Beispiel, welches im Rahmen der Evaluation entsprechend der Beschreibung des

Algorithmus in Kapitel 6.4.2 als Vorgängerprojekt dienen soll, wurde von Michel Bor-

nath während seiner Tätigkeit als studentische Hilfskraft am Fraunhofer IPK entwickelt

und zusätzlich in seiner Diplomarbeit dokumentiert [Bornath 2011b]. Es handelt sich

um die drei Artefakte Anforderungsliste, Funktionshierarchie und Produktstruktur eines

Fahrrads sowie die zugehörigen Tracelink-Modelle zwischen diesen Artefakten.

Eine kurze Charakterisierung der Artefakte ist in Tabelle 26 anhand der jeweiligen An-

zahl an Elementen, Hierarchieebenen sowie Tracelinks zwischen den verschiedenen

Artefakten zusammengefasst. Die vollständigen Artefakte und das Tracelink-Modell

sind im Anhang C zu finden.

Anforderungsliste

Funktionshierarchie

Produktstruktur

Anzahl Elemente

Anzahl Ebenen

Anzahl

Tracelinks

Tabelle 26: Charakterisierung des Vorgängerprojekts Fahrrad

Das Fahrrad-Beispiel besteht aus drei Artefakten mit insgesamt 62 Elementen zwi-

schen denen 161 Tracelinks modelliert wurden. Die Bezeichner der Elemente sind auf

Deutsch verfasst und bestehen aus bis sieben Worten.

Das Pedelec-Beispiel, welches im Rahmen der Evaluation als aktuelles Projekt gilt,

wurde durch neun Studenten im Rahmen der Lehrveranstaltung „Virtual Engineering

in Industry“ entwickelt [Fielitz et al. 2013].

Methoden zur Pflege von Tracelink-Modellen

174

Es ist wichtig zu erwähnen, dass die Ersteller der beiden Beispiele ihre Modelle voll-

kommen unabhängig voneinander aufgebaut haben. Die Element-Bezeichner sind

somit durch unterschiedliche Personen und ohne Beeinflussung durch Vorwissen über

das Vorgänger- bzw. Nachfolgerprojekt definiert worden.

Diese wurden durch den Autor der Arbeit aus CATIA V6 ausgeleitet und in ein durch

den ModelTracer interpretierbares Format (ReqIF) überführt. Da die Lehrveranstal-

tung auf Englisch gehalten wurde, wurden in diesem Arbeitsschritt zusätzlich die Be-

zeichner der Elemente in Deutsche übersetzt. Dabei wurde darauf geachtet, dass

die Wörter 1:1 mit Hilfe des verbreiteten Online-Wörterbuchs LEO

übersetzt wurden,

um die durch die Studenten gewählten Bezeichner möglichst nicht zu verfälschen.

Anforderungsliste

Funktionshierarchie

Produktstruktur

Anzahl Elemente

Anzahl Ebenen

Anzahl

Tracelinks

Tabelle 27: Charakterisierung des aktuellen Projekts Pedelec

Insgesamt verfügen die drei Artefakte des aktuellen Projekts über 148 Elemente (sie-

he Tabelle 27), zwischen denen für die Evaluation noch keine Tracelinks modelliert

wurden. Eine durch den Autor dieser Arbeit mit EcoTracing durchgeführte Abhängig-

keitsanalyse ergab 152 Tracelinks zwischen der Anforderungsliste und der Funktions-

hierarchie, 74 zwischen Funktionshierarchie und Produktstruktur sowie 207 zwischen

Anforderungsliste und Produktstruktur

. Die Bezeichner der Elemente sind nach der

Übersetzung deutsch und bis zu fünf Wörter lang.

Zur Durchführung der Evaluation wurden die Artefakte der beiden Projekte in den

ModelTracer geladen. Die Artefakte des Fahrrad-Beispiels, welches als Vorgänger-

projekt fungiert, wurden mit dem Präfix „__“ versehen. In Abbildung 74 ist dies auf der

linken Seite zu erkennen. Zusätzlich sind die bereits modellierten Tracelinks (siehe An-

hang C) anhand der Elementsymbole auf der rechten Seite der Abbildung (einge-

hende: rotes Dreieck und ausgehende: grünes Dreieck) zu erkennen.

http://dict.leo.org

Die Modellierung der Tracelinks wurde durchgeführt, um die Vorschläge der Methode

TraceLegacy hinsichtlich ihrer Korrektheit bewerten und die Trefferquote berechnen zu

können.

Methoden zur Pflege von Tracelink-Modellen

175

Abbildung 74: Verwaltung der beiden Projekte im ModelTracer (Artefakte des Vorgängerpro-

jekts „Fahrrad“ wurden mit dem Präfix „__“ versehen).

Im Anschluss wurden zwei Analysen durchgeführt. Bei der Ersten wurde die Stamm-

formreduktion, bei der die in den Bezeichnern enthaltenen Worte auf ihren Wort-

stamm heruntergebrochen werden, deaktiviert. Bei der zweiten war die Stammform-

reduktion aktiviert. Die Darstellung der Ergebnisse, deren Interpretation und Diskussion

erfolgt im anschließenden Kapitel 6.4.4.2.

6.4.4.2 AUSWERTUNG DER EVALUATION

Die beiden Analysen ergaben jeweils eine Anzahl von Vorschlägen für das aktuelle

Projekt „Pedelec“, die durch den Algorithmus auf Basis des Vorgänger-Projekts „Fahr-

rad“ ermittelt wurden. In Abbildung 75 sind die Vorschläge für die Analyse, bei der

die Stammformreduktion aktiviert war, dargestellt. Diese Vorschläge inkl. der Informa-

tionen bzgl. der ähnlichen Tracelinks im Vorgänger-Projekt wurden im Anschluss ma-

nuell in Excel-Tabellen übertragen und hinsichtlich ihrer Korrektheit bewertet.

In Tabelle 28 sind einige exemplarische Vorschläge, die durch die Methode

TraceLegacy ohne die Verwendung der Stammformrückführung generiert wurden,

zusammengestellt. Die Vorschläge sind zeilenweise angegeben und durchnumme-

riert

. Darüber hinaus sind jeweils die Start- und Endelemente, für die ein Tracelink-

Vorschlag erstellt wurde (linke Spalte „Aktuelles Pedelec-Projekt“), und die Start- und

Endelemente, auf deren Basis die Empfehlung abgeleitet wurde (rechte Spalte

„Vergangenes Fahrrad-Projekt“), angegeben. In der zuletzt genannten Spalte kön-

nen dabei auch mehrere Start- und Endelemente pro Zeile erfasst sein, wenn die

Empfehlung aufgrund mehrerer Übereinstimmungen im vergangenen Projekt gene-

riert wurde. Die Übereinstimmungen der Bezeichner, die den Grund für die Empfeh-

lung darstellen, wurden in den einzelnen Zellen fett markiert. Falls ein Vorschlag als

Die Nummerierung entspricht dabei der im Anhang, weshalb in den Tabellen keine durch-

gängige Nummerierung gewährleistet werden kann.

Methoden zur Pflege von Tracelink-Modellen

176

nicht korrekt bewertet wurde, wurde in der zweiten Spalte ein „x“ vermerkt. Die voll-

ständigen Auswertungsergebnisse sind in Anhang C zu finden.

Abbildung 75: Ergebnisliste der prototypischen Implementierung der Methode TraceLegacy

anhand der Beispiele „Fahrrad“ und „Pedelec“

Aktuelles Pedelec-Projekt

Vergangenes Fahrrad-Projekt

von

Beleuchtung

Bereitstellung Ener-

gie für Licht System

Beleuchtung vorse-

hen

Licht reflektieren

Umwandlung Rota-

tion in translatori-

sche Bewegung

Hinterrad

Rotationsmoment

auf Straße übertra-

gen

Hinterrad

Pedal Signal emp-

fangen

Vorderrad

Signal in Richtungs-

änderung umsetzen

Vorderrad

Griff Handbremse

Bremse

Bremsen

Bremseinheit

zuverlässiges Brem-

sen bei Nässe

Bremseinheit

muss mit Handkraft

betrieben werden

können

Bremseinheit

Tabelle 28: Evaluationsergebnis ohne Stammformrückführung (Auszug)

Vorschlag Nr. 1: Aufgrund des Tracelinks zwischen der Fahrrad-Anforderung „Be-

leuchtung vorsehen“ und der Fahrrad-Funktion „Licht reflektieren“ wurde der Vor-

schlag generiert, die Elementekombination von Pedelec-Anforderung „Beleuch-

tung“ und der Pedelec-Funktion „Bereitstellung Energie für Licht System“ auf eine

Methoden zur Pflege von Tracelink-Modellen

177

Abhängigkeit zu überprüfen. In der Bewertung wurde dem Vorschlag zugestimmt, da

die Pedelec-Funktion durch die Pedelec-Anforderung notwendig wird.

Vorschlag Nr. 3: Aufgrund des Tracelinks zwischen der Fahrrad-Funktion „Rotations-

moment auf Straße übertragen“ und dem Fahrrad-Bauteil „Hinterrad“ wurde der

Vorschlag generiert, die Elementekombination von Pedelec-Funktion „Umwandlung

Rotation in translatorische Bewegung“ und dem Pedelec-Bauteil „Hinterrad“ auf Ab-

hängigkeiten zu überprüfen. In der Bewertung wurde dem Vorschlag zugestimmt, da

das Pedelec-Hinterrad an der Realisierung der Funktion beteiligt ist. Bei diesem Vor-

schlag wird deutlich, dass die in Kapitel 6.1 vorgestellten Methoden wahrscheinlich

nicht zu einem Vorschlag geführt hätten, da sich der inhaltliche Zusammenhang

nicht direkt aus einem Wortvergleich oder dem Verständnis der Bezeichner ergibt.

Mit Hilfe der Methode TraceLegacy wird jedoch auf Wissen über diesen Zusammen-

hang zurückgegriffen, das in dieser Form durch menschliche Entscheidungen in der

Vergangenheit generiert wurde.

Vorschlag Nr. 5: Aufgrund des Tracelinks zwischen der Fahrrad-Funktion „Signal in

Richtungsänderung umsetzen“ und dem Fahrrad-Bauteil „Vorderrad“ wurde der Vor-

schlag generiert, die Elementekombination von Pedelec-Funktion „Pedal Signal

empfangen“ und dem Pedelec-Bauteil „Vorderrad“ auf Abhängigkeiten zu überprü-

fen. Dieser Vorschlag wurde als falsch eingestuft, da im Pedelec-Beispiel zwischen

dem Pedal-Signal und dem Vorderrad kein Zusammenhang besteht. Er wurde gene-

riert, da das Signal im Fahrrad-Beispiel nicht näher spezifiziert wurde.

Vorschlag Nr. 7: Bei Vorschlag Nr. 7 führten mehrere Tracelinks aus dem Fahrrad-

Projekt dazu, dass für das Pedelec-Beispiel zwischen der Anforderung „Griff Hand-

bremse“ und dem Bauteil „Bremse“ ein Tracelink-Vorschlag generiert wurde. Dieser

Tracelink wurde als korrekt bewertet, da die Forderung nach einem Griff für die

Handbremse sich an das Bremssystem und damit auch an die Bremse richtet. Dieser

Vorschlag wäre auch durch einen einfachen Wortvergleich der Elemente des Pede-

lec-Projekts zu generieren gewesen.

Insgesamt wurden bei der Analyse ohne Stammformrückführung 20 Vorschläge für zu

modellierende Tracelinks durch die Methode TraceLegacy gemacht. Von diesen

Vorschlägen wurden 18 als korrekt und 2 als nicht korrekt bewertet. Das entspricht ei-

ner Präzision von 90,0 % und einer Trefferquote von 4,2 %.

In Tabelle 29 ist ein Auszug des Ergebnisses der Analyse mit aktivierter Stammform-

rückführung dargestellt. Anhand der fett markierten Suchworte wird deutlich, dass

nicht mehr ganze Worte als Suchanfragen genutzt wurden, sondern nur Wortteile, die

nach Anwendung der Stammformrückführung übrig geblieben sind. Das führt dazu,

Methoden zur Pflege von Tracelink-Modellen

178

dass mehr Vorschläge zurückgegeben werden, die ohne die Rückführung nicht ge-

funden werden können.

Aktuelles Pedelec-Projekt

Vergangenes Fahrrad-Projekt

von

Frontbeleuchtung

Beleuchtung

Beleuchtung vorse-

hen

unmittelbare Um-

gebung beleuchten

Antrieb

Umwandlung Rota-

tion in translatori-

sche Bewegung

Hinterantrieb mittels

Fußkurbel und Kette

Rotationsmoment

aufnehmen

Hinterantrieb mittels

Fußkurbel und Kette

Rotationsmoment

leiten

Hinterantrieb mittels

Fußkurbel und Kette

Rotationsmoment

wandeln

Hinterantrieb mittels

Fußkurbel und Kette

Rotationsmoment

auf die Straße über-

tragen

Schaltung

Anweisung Gang-

wechsel empfan-

gen

Übersetzung mittels

Kettenschaltung

Übersetzung wech-

seln

Tabelle 29: Evaluationsergebnis mit Stammformrückführung (Auszug)

Vorschlag Nr. 4: Aufgrund des Tracelinks zwischen der Fahrrad-Anforderung „Be-

leuchtung vorsehen“ und der Fahrrad-Funktion „unmittelbare Umgebung beleuch-

ten“ wurde der Vorschlag generiert, die Elementekombination von Pedelec-

Anforderung „Frontbeleuchtung“ und Pedelec-Funktion „Beleuchtung“ auf eine Ab-

hängigkeit zu überprüfen. In der Bewertung wurde dem Vorschlag zugestimmt, da

die Pedelec-Funktion durch die Pedelec-Anforderung notwendig wird.

Vorschlag Nr. 20: Bei Vorschlag Nr. 20 führten mehrere Tracelinks aus dem Fahrrad-

Projekt dazu, dass für das Pedelec-Beispiel zwischen der Anforderung „Antrieb“ und

der Funktion „Umwandlung Rotation in translatorische Bewegung“ ein Tracelink-

Vorschlag generiert wurde. Dieser Tracelink wurde als korrekt bewertet, da diese An-

forderungskategorie Anforderungen bzgl. der Pedale, dem E-Motor, der Schaltung

und der Höchstgeschwindigkeit zusammenfasst und somit direkt mit der Funktion in

Abhängigkeit steht. Auch bei diesem Vorschlag wird deutlich, dass die in Kapitel 6.1

vorgestellten Methoden wahrscheinlich nicht zu einer Empfehlung geführt hätten, da

sich der inhaltliche Zusammenhang nicht direkt aus einem Wortvergleich oder dem

Verständnis der Bezeichner ergibt.

Vorschlag Nr. 21: Aufgrund des Tracelinks zwischen der Fahrrad-Anforderung „Über-

setzung mittels Kettenschaltung“ und der Fahrrad-Funktion „Übersetzung wechseln“

wurde der Vorschlag generiert, die Elementekombination von Pedelec-Anforderung

„Schaltung“ und der Pedelec-Funktion „Anweisung Gangwechsel empfangen“ auf

Abhängigkeiten zu überprüfen. In der Bewertung wurde dem Vorschlag zugestimmt,

da die Forderung nach der Integration einer Schaltung direkt mit deren Steuerung in

der Funktionsstruktur zusammenhängt. Auch dieser Vorschlag wäre mit den Metho-

Methoden zur Pflege von Tracelink-Modellen

179

den aus Kapitel 6.1 nicht generiert worden, da der Zusammenhang zwischen schal-

ten und wechseln nicht identifiziert worden wäre.

Insgesamt wurden bei der Analyse mit Stammformrückführung 82 Tracelink-

Vorschläge durch die Methode TraceLegacy generiert. Von diesen Vorschlägen

wurden 50 als korrekt und 32 als nicht korrekt bewertet. Anzumerken ist jedoch, dass

ein Vorschlag auf Grundlage unterschiedlicher Tracelinks im Vorgänger-Projekt dop-

pelt ausgegeben wurde. Dieser wird somit nur einmal gezählt. Daraus ergibt sich eine

korrigierte Präzision von 60,9 % und eine Trefferquote von 11,5 %.

6.4.5 ZUSAMMENFASSUNG UND DISKUSSION

Das Kapitel 6.4 beschäftigte sich mit der Forschungsfrage, ob Wissen, welches mithilfe

von Tracelinks in vergangenen Projekten dokumentiert wurde, geeignet ist, um in ak-

tuellen Projekten zur Steigerung der Qualität des Tracelink-Modells beizutragen.

Durch den Autor dieser Arbeit wurde die Hypothese aufgestellt, dass auf dieser Wis-

sensbasis Vorschläge für fehlende Tracelinks generiert werden können.

Die vorgestellte Methode TraceLegacy zielt daher darauf ab, Entwicklungswissen

vergangener Projekte zu nutzen, um Vorschläge für fehlende Tracelinks in aktuellen

Projekten zu generieren. Sie ist somit dazu geeignet, falsch negative Tracelinks zu

identifizieren. Dabei werden im Gegensatz zu den Methoden im Stand der Technik

nicht die aktuellen Artefakte miteinander, sondern diese mit Artefakten gleichen Typs

aus Vorgängerprojekten verglichen, die zugehörigen Tracelinks analysiert und so Vor-

schläge für neue Tracelinks generiert. Der Vorteil dieses Funktionsprinzips ist, dass im-

mer Artefakte gleichen Typs (bspw. ein aktuelles Anforderungsartefakt mit einem An-

forderungsartefakt aus einem vergangenen Projekt) miteinander verglichen werden,

in denen die Elemente tendenziell mit ähnlichem Vokabular beschrieben werden.

Die Vorschläge für Tracelinks zwischen den Elementen zweier aktueller Artefakte un-

terschiedlichen Typs (bspw. zwischen einem Anforderungs- und einem Funktionsarte-

fakt), bei denen sich die Bezeichner hinsichtlich der verwendeten Vokabeln unter-

scheiden können, werden dann auf Basis der zuvor berechneten Ähnlichkeiten sowie

der Tracelinks des Vorgängerprojekts berechnet. Das Wissen aus dem Vorgängerpro-

jekt wird durch Anwendung der Methode TraceLegacy somit zur Verbesserung der

Qualität des aktuellen Tracelink-Modells wiederverwendet.

In der prototypischen Implementierung des TraceLegacy-Algorithmus kommt ein

Wortvergleich mit optionaler Stammformrückführung zum Einsatz, um die Überein-

stimmungsmatrizen zu erstellen, die benötigt werden, um die Ähnlichkeit der Elemen-

te des aktuellen Projekts zu denen aus vergangenen Projekten zu ermitteln. Auf die-

ser Basis werden Elemente vergangener Projekte identifiziert, hinsichtlich vorhande-

Methoden zur Pflege von Tracelink-Modellen

180

ner Tracelinks beurteilt und Vorschläge für Tracelinks im aktuellen Projekt ausgege-

ben.

Die Evaluation der Methode TraceLegacy wurde, mit dem Ziel die grundsätzliche

Funktionsfähigkeit der Methode nachzuweisen und damit die Hypothese 3 zu bestä-

tigen, anhand zweier Beispiele durchgeführt, die unabhängig voneinander entwi-

ckelt wurden. Dieses Szenario bildet somit den Anwendungsfall ab, dass bei der Ent-

wicklung des aktuellen Projekts „auf der grünen Wiese“ begonnen wurde, ohne Arte-

fakte aus dem Vorgängerprojekt wiederzuverwenden.

Auf Basis der Artefakte der beiden Projekte wurde die Analyse einmal ohne und ein-

mal mit Stammformrückführung durchgeführt. Bei ersterer wurden 20 Tracelinks durch

die Methode TraceLegacy vorgeschlagen. Von diesen Vorschlägen wurden 18 als

korrekt und 2 als nicht korrekt bewertet. Das entspricht einer Präzision von 90 % und

einer Trefferquote von ca. 4 %. Bei der Analyse mit Stammformrückführung wurden 82

einzelne Vorschläge für zu modellierende Tracelinks generiert. Von diesen Vorschlä-

gen wurden 50 als korrekt und 32 als nicht korrekt bewertet. Die Präzision entspricht

somit ca. 60 % und die Trefferquote ca. 11 %.

Die grundsätzliche Funktionsfähigkeit der Methode wurde nachgewiesen und damit

die Hypothese 3 bestätigt, indem relevante Vorschläge für Tracelinks auf Basis eines

ähnlichen Vorgängerprojekts berechnet werden konnten. Unter diesen Vorschlägen

waren auch solche, die mit den beschriebenen Ansätzen des Stands der Technik

nicht zu identifizieren gewesen wären, da die Bezeichner der Elemente der Artefakte

des aktuellen Projekts keine identischen oder synonymen Worte aufwiesen.

Es wurde bei der Evaluation ebenfalls deutlich, dass der Algorithmus zur Berechnung

der Element-Ähnlichkeit einen großen Einfluss auf die charakteristischen Messwerte

Trefferquote und Präzision hat. So ist die Präzision von TraceLegacy ohne Stammform-

rückführung deutlich höher als mit, da nur bei vollständiger Übereinstimmung ein Vor-

schlag generiert wird. Jedoch werden dafür insgesamt weniger zu modellierende

Tracelinks vorgeschlagen, weshalb die Trefferquote geringer ist. Für beide Varianten

gilt, dass die ermittelten Präzisionswerte nach der Skala von Hayes et al. als exzellent

und die Trefferquoten als schlecht zu bewerten sind [Hayes et al. 2006, S. 11].

Im Rahmen dieser Arbeit stand jedoch nicht die Optimierung der Methode

TraceLegacy, sondern nur die grundsätzliche Überprüfung der Machbarkeit im Fokus.

Da diese nachgewiesen wurde, sollte aufbauend auf dem grundsätzlichen Funkti-

onsprinzip die Betrachtung möglicher Kombinationen der Methode TraceLegacy mit

anderen Algorithmen zur Bewertung der Ähnlichkeit (siehe bspw. Kapitel 6.1) Gegen-

stand weiterführender Forschung sein.

Methoden zur Pflege von Tracelink-Modellen

181

Zusätzlich wird auch durch die Methode TraceLegacy bestätigt, was in Kapitel 3.4.1

beschrieben wurde: nach Meinung des Autors eignen sich die bisher vorhandenen

Methoden zur automatisierten Erfassung von Tracelinks nicht dazu, bei der Erfassung

der Tracelinks in der Mechatronik zum Einsatz zu kommen. Das liegt einerseits an der

Präzision, die bei keiner der betrachteten Methoden 100 % ist, und zum anderen an

den üblicherweise geringen Trefferquoten, die besagen, dass viele Tracelinks nicht

automatisiert identifiziert werden können. Während die Erfassung der Tracelinks, ent-

weder direkt bei der Entwicklung der Artefakte oder im Anschluss, durch die Entwick-

ler erfolgen sollte, können die automatisierten Methoden geeignet kombiniert wer-

den und bei der Sicherung der Qualität des Tracelink-Modells unterstützen.

6.5 ZUSAMMENFASSUNG UND DISKUSSION

In Kapitel 6 wurden Methoden zur Pflege von Tracelink-Modellen thematisiert. Dazu

wurden zunächst Methoden des aktuellen Stands der Technik vorgestellt (siehe Kapi-

tel 6.1), anhand ihrer Eigenschaften kategorisiert und so Forschungspotenziale auf-

gedeckt. Einerseits wurde deutlich, dass sich die dargestellten Methoden in ihrer be-

schriebenen Umsetzung nicht für die Ermittlung falsch negativer Tracelinks eignen.

Andererseits zeigte sich, dass die Methoden zur Analyse lediglich Informationen aus

aktuellen Projekten berücksichtigen. Das hat insbesondere bei der Analyse von Arte-

fakten unterschiedlichen Typs (bspw. bei einer Funktionsstruktur in Kombination mit

einer Produktstruktur) den Nachteil, dass deren Elemente überlappende Inhalte in

Form von Wörtern, Synonymen oder Beschreibungen aufweisen müssen, damit Ab-

hängigkeiten erkannt werden können. An diesen vom Stand der Technik noch nicht

adressierten Aspekten orientierten sich die im Folgenden beschriebenen Methoden

TraceEvaluation und TraceLegacy, die ein weiteres „Puzzlestück“ zur Sicherung der

Qualität des Tracelink-Modells darstellen.

Die Crowdsourcing-Methode TraceEvaluation adressiert Hypothese 2. Diese besagt,

dass Fehler im Traceability-Modell quasi nebenbei bei der Nutzung von Tracelinks

identifiziert und gemeldet werden können. TraceEvaluation ermöglicht es den An-

wendern, im Tagesgeschäft falsche Tracelinks einfach zu melden. Diese Meldungen

laufen in einem Auswertungsmodul zusammen und können durch den Qualitätssi-

cherungsbeauftragen analysiert werden. Die Wirksamkeit der Methode wurde in ei-

ner Studie evaluiert, bei der die Probanden im Rahmen von Auswirkungsanalysen

von Änderungen betroffene Bauteile identifizieren sollten. Den Probanden gelang es

dabei, alle vorsätzlich im Beispiel platzierten falschen Tracelinks zu identifizieren. Die

so erreichte Trefferquote von 100 % sowie die Präzision von 88 % sind als exzellent zu

bewerten. Darüber hinaus gelang es jedoch keinem der Probanden allein, alle fal-

Methoden zur Pflege von Tracelink-Modellen

182

schen Tracelinks zu identifizieren – die Anzahl der Probanden hat somit eine Auswir-

kung auf die Vollständigkeit der Analyse.

Die Methode TraceLegacy adressiert die Hypothese 3. Diese postuliert, dass auf der

Basis von Tracelink-Modellen vergangener Projekte Vorschläge für fehlende Trace-

links in aktuellen Projekten generiert werden können. TraceLegacy berechnet dem-

entsprechend für alle Elemente, die in Artefakten des aktuellen Projekts enthalten

sind, die Ähnlichkeit zu Elementen desselben Typs aus vergangenen Projekten. Unter

Berücksichtigung des Tracelink-Modells des vergangenen Projekts, können auf diese

Weise Vorschläge für Tracelinks im aktuellen Projekt generiert werden. Die Evaluation

der Methode TraceLegacy wurde mit dem Ziel, deren grundsätzliche Machbarkeit zu

überprüfen und damit die Hypothese 3 zu bestätigen, anhand zweier Beispiele

durchgeführt, die unabhängig voneinander entwickelt wurden. Je nach gewähltem

Vergleichsalgorithmus (ohne bzw. mit Stammformrückführung) konnten so exzellente

Präzisionswerte von ca. 90 % bzw. 61 % erzielt werden. Für die Trefferquote liefert

TraceLegacy mit ca. 4 % bzw. 11 % vergleichsweise schlechte Ergebnisse. Die Me-

thode lieferte somit in jedem Fall relevante Vorschläge, wodurch die Hypothese 3

bestätigt wurde. Zur Optimierung der Methode, die im Rahmen dieser Arbeit nicht im

Vordergrund stand, sollten zukünftig andere Algorithmen zur Bewertung der Ähnlich-

keit, als der eingesetzte Stringvergleich, evaluiert werden.

Die im Kontext der Qualitätssicherung durchgeführten Studien und Evaluationen be-

stätigten im Übrigen, was schon in der Diskussion in Kapitel 5.5 angemerkt wurde: die

Entscheidung für oder gegen einen Tracelink ist sehr stark durch die subjektive Inter-

pretation der inhaltlichen Bedeutung der Elemente und des Konzepts „Tracelink“

durch den Anwender geprägt. Eine eindeutige Kategorisierung der Tracelinks in

„richtig“ und „falsch“ ist somit nicht immer einfach möglich. Jedoch gelingt es mit

der Methode TraceEvaluation, potenziell falsche Tracelinks, die durch viele Benutzer

gemeldet werden, an einer zentralen Stelle zusammenlaufen zu lassen. Der für die

durchgängige Nachverfolgbarkeit zuständige Entwickler kann nach Auswertung der

Meldungen in Diskussionen mit den Fachexperten versuchen, eine einheitliche Sicht

auf das Konzept „Tracelink“ zu generieren und somit die Qualität des Tracelink-

Modells langfristig steigern. Ähnlich wirkt auch die Methode TraceLegacy. Basierend

auf dem Wissen vergangener Projekte (und damit potenziell anderer Entwickler),

werden Vorschläge für Tracelinks generiert, die dann in Diskussionen auf ihre Richtig-

keit überprüft werden können. Das anvisierte Ziel, mit den beiden Methoden zwei

weitere Puzzlestücke zur Sicherung der Qualität des Tracelink-Modells bereitzustellen,

konnte somit erreicht werden.

183

7 ANWENDUNG DER METHODEN ZUR ENTWICKLUNG EINES

TECHNISCHEN SYSTEMS

In diesem Kapitel wird die Anwendung der in den Kapiteln 5.4, 6.3 und 6.4 beschrie-

benen Methoden EcoTracing, TraceEvaluation und TraceLegacy im Entwicklungs-

prozess vorgestellt. Zu diesem Zweck werden die genannten Methoden zunächst in

Kapitel 7.1 im V-Modell des Fraunhofer IPK verortet, um darzustellen wann sie wäh-

rend der Entwicklung eingesetzt werden können. Anschließend werden die Metho-

den in Kapitel 7.2 im Kontext der Entwicklung des mechatronischen Außenspiegels,

die anhand ihrer Prozessphasen beschrieben wird, demonstriert.

Ziel des Kapitels ist es, den Einsatz der Methoden unter realistischen (wenngleich hin-

sichtlich Umfang und Komplexität vereinfachten) Bedingungen darzustellen und Vor-

und Nachteile, die sich durch den Einsatz für die Anwender ergeben, aufzuzeigen.

Dabei wird nicht auf alle Aspekte der Entwicklung eingegangen, sondern der Fokus

auf die Erstellung und Änderung der wichtigsten Artefakte gelegt und darüber hinaus

von einem sequenziellen Entwicklungsverlauf ohne Iterationen ausgegangen. Aus

diesem Entwicklungsverlauf werden ausgewählte Entwicklungsschritte näher erläu-

tert, die Einsatzmöglichkeiten der zuvor erwähnten Methoden am Beispiel dargestellt

und dabei vergleichend auf die Vorgehensweise mit und ohne jeweilige Methode

eingegangen.

Anwendung der Methoden zur Entwicklung eines technischen Systems

184

Abschließend werden die Einsatzmöglichkeiten und die Anwendung der Methoden

in Kapitel 7.3 zusammengefasst und diskutiert.

7.1 VERORTUNG DER METHODEN IM V-MODELL

Die in den vorhergehenden Kapiteln 5.4, 6.3 und 6.4 beschriebenen Methoden

EcoTracing, TraceEvaluation und TraceLegacy dienen der Unterstützung der Erfas-

sungs- und Pflegeaktivitäten von Tracelinks und Tracelink-Modellen. Da diese Aktivitä-

ten kontinuierlich während der Entwicklung technischer Systeme durchgeführt wer-

den müssen, bieten sich unterschiedliche Einsatzzeitpunkte für die genannten Me-

thoden an. In Abbildung 76 sind diese anhand des V-Modells des Fraunhofer IPK

schematisch dargestellt.

Abbildung 76: Verortung der Methoden im V-Modell des Fraunhofer IPK

Die Einsatzmöglichkeiten der Methode EcoTracing (ET) sind jeweils den Prozessschrit-

ten, in denen Artefakte modelliert werden, nachgelagert bzw. in ihnen enthalten.

Abhängig ist der Einsatzzeitpunkt von der Tracelink-Modellierungsstrategie im Rah-

men des Entwicklungsprojekts. Werden die Tracelinks erst nach Fertigstellung der Ar-

tefakte modelliert, wird EcoTracing im Anschluss an die jeweiligen Prozessschritte

durchgeführt. Sollen hingegen bereits Zwischenstände der Artefakte hinsichtlich vor-

handener Abhängigkeiten zu anderen Artefakten analysiert werden, so findet die

Anwendung der Methode während des jeweiligen Prozessschritts statt.

Anwendung der Methoden zur Entwicklung eines technischen Systems

185

Gleiches gilt für die Methode TraceLegacy (TL), deren Einsatz in Abbildung 76 jeweils

zum gleichen Zeitpunkt wie EcoTracing dargestellt wird. Hintergrund ist, dass sich die

Durchführung der Qualitätssicherung des Tracelink-Modells mit TraceLegacy im An-

schluss an die Modellierung der Tracelinks anbietet, um zu prüfen, ob Abhängigkei-

ten bei der Analyse übersehen wurden. Grundsätzlich lässt sich die Methode jedoch

zu jedem Zeitpunkt im Entwicklungsprozess

durchführen.

Die Methode TraceEvaluation (TE) wird im Gegensatz dazu überwiegend während

der Prozessschritte angewendet. Da TraceEvaluation auf einem Crowdsourcing-

Ansatz basiert, mit dem Hinweise bzgl. möglicher falscher Tracelinks von den Entwick-

lern erfasst werden, ist der Einsatz der Methode immer sinnvoll, wenn eine Interaktion

mit den Artefakten (die in den Prozessschritten erstellt, bearbeitet und verwendet

werden) stattfindet. Dies ist insbesondere bei der integrierten Funktions- und Eigen-

schaftsabsicherung sowie bei der Eigenschaftsbestätigung der Fall, da bei diesen Ak-

tivitäten die Tracelinks verwendet werden, um aktuelle IST- mit SOLL-Parametern

bspw. der Anforderungen abzugleichen, wobei falsche Tracelinks besonders auffal-

len.

7.2 DEMONSTRATION DER METHODEN AM BEISPIEL DER ENTWICKLUNG EINES

MECHATRONISCHEN AUßENSPIEGELS

Die Vorgehensweise während der Entwicklung des mechatronischen Außenspiegels

im Rahmen der Lehrveranstaltung „Virtual Engineering in Industry“ orientierte sich an

dem V-Modell des Fraunhofer IPK (siehe auch Kapitel 2.1.5). Aufgrund begrenzter

Ressourcen wurden dabei nicht alle Prozessschritte des V-Modells durchlaufen son-

dern insb. auf die Phase der durchgängige Systemauslegung und des neutralen Ent-

wurf fokussiert. In Abbildung 77 sind die durchgeführten Prozessschritte mittels roter

Umrandung dargestellt.

Insgesamt wurden die folgenden sechs Prozessschritte durchlaufen:

1. Anforderungen: die Studenten erhielten eine Spezifikation mit vorgegebenen

Anforderungen

2. Anforderungskaskade: die vorgegebenen Anforderungen wurden ergänzt,

strukturiert und in die PLM-Software ENOVIA übertragen

3. Vorentwurf der Funktionen und Eigenschaften: aus den Anforderungen wur-

den zu realisierende Funktionen identifiziert und mittels CATIA V6 in einer Funk-

tionsstruktur modelliert

Einzige Voraussetzungen sind, dass mehr als ein Artefakt vorhanden ist und in der vergan-

genheit bereits ähnliche Entwicklungsprojekte durchgeführt wurden.

Anwendung der Methoden zur Entwicklung eines technischen Systems

186

5. Vorentwurf des Systemmodells: Wirkprinzipien für die modellierten Funktionen

wurden gewählt und das Verhalten abgebildet

7. Integrierte Funktions- und Eigenschaftsabsicherung: durch Simulation des Ver-

haltens des Außenspiegels wurde die Realisierung von Funktionen und Eigen-

schaften überprüft und mit den Anforderungen abgeglichen

8. Mechanik: mechanische Komponenten wurden in CATIA modelliert

Abbildung 77: Darstellung der durchgeführten Prozessschritte während der Entwicklung des

mechatronischen Außenspiegels

Diese Prozessschritte wurden durch unterstützende Aktivitäten begleitet, von denen

im Kontext dieser Arbeit insb. die Erfassung von Tracelinks von Interesse ist. In Abbil-

dung 77 ist dies durch die Aktivitäten (4), (6) und (9) in Form der Anwendung der Me-

thode EcoTracing visualisiert

Die so durchnummerierten Prozessschritte und Aktivitäten dienen im Folgenden als

eine Art Drehbuch, anhand dessen die Entwicklung des mechatronischen Außen-

spiegels beschrieben wird. Um die Zuordnung zu erleichtern wurden diese Nummern

in Kapitel 7.2 als Unterüberschriften 7.2.x wieder aufgenommen.

Zusätzlich wird der Einsatz der Methoden TraceEvaluation (Aktivität 10) und

TraceLegacy (Aktivität 11) zur Pflege des Tracelink-Modells beschrieben. In Kapitel 7.2

findet sich dies in den Kapiteln „7.2.10 Durchführung einer Auswirkungsanalyse“ und

„7.2.11 Durchführung einer Qualitätskontrolle“ wieder.

Tatsächlich wurde durch die Studenten eine manuelle Tracelink-Modellierung durchge-

führt. Nähere Informationen sind den zugehörigen Kapiteln 7.2.4, 7.2.6 und 7.2.9 zu ent-

nehmen.

Anwendung der Methoden zur Entwicklung eines technischen Systems

187

7.2.1 ANFORDERUNGEN

Zu Beginn des Projektes erhielt die Studentengruppe von den Betreuern eine Anfor-

derungsspezifikation, in der grundlegende Randbedingungen der Entwicklung sowie

des Außenspiegels spezifiziert wurden. Insgesamt enthielt die Spezifikation elf Anfor-

derungen, die bspw. das Maximalgewicht, Kosten oder spezifische Funktionen (wie

die Verstellung des Spiegels bei Rückwärtsfahrt) vorgaben. In Tabelle 30 sind die Ei-

genschaften der Anforderungsspezifikation zusammengefasst.

Artefaktname

Customer Requirments Specification

Strukturierungsart

Liste

Anzahl Elemente

Anzahl Hierarchieebenen

Tabelle 30: Eigenschaften der initialen Anforderungsspezifikation

7.2.2 ANFORDERUNGSKASKADE

Da diese Anforderungen nicht ausreichten, um sich ein umfassendes Bild von dem zu

entwickelnden System zu machen, führten die Studenten ein Brainstorming sowie ei-

ne Machbarkeitsprüfung durch, um die Anforderungsspezifikation zu ergänzen. Die

so gesammelten 27 Anforderungen wurden in ENOVIA textuell beschrieben (Eigen-

schaften siehe Tabelle 31). Zur Strukturierung des Anforderungsartefakts wurde eine

Projektion mit sechs Kategorien auf höchster Ebene verwendet (siehe auch Kapi-

tel 5.2.1.2). Im Folgenden werden diese Kategorien kurz vorgestellt:

- Basic Functions: Unter der Kategorie „Basic Functions“ wurden alle Anforde-

rungen zusammengefasst, welche die Grundfunktionen eines Außenspiegel-

systems betreffen. Dazu zählen bspw. die manuelle und automatische Verstel-

lung des Spiegelglases.

- Boundary conditions: Randbedingungen, die überwiegend durch die Aufga-

benstellung definiert wurden, wie maximale Kosten, Gewicht und Dimensio-

nen des Außenspiegels;

- Command: Enthält Anforderungen, die Bedienung des Außenspiegelsystems

durch den Benutzer betreffend;

- Comfort Functions: Kategorie für Anforderungen, die erweiterte Komfortfunkti-

onen des Außenspiegelsystems fordern;

- Protective Equipment: Zusammenstellung von Anforderungen, die Sicherheits-

aspekte (insbesondere bzgl. der Interaktion mit dem Außenspiegelsystem) be-

treffen;

- Legal: Anforderungen, die sich aus der Patent- und Rechtssituation ergeben.

Anwendung der Methoden zur Entwicklung eines technischen Systems

188

Ergänzend zur textuellen Beschreibung der Anforderungen wurden ihre Wichtigkeit,

die Schwierigkeit ihrer Umsetzung sowie die geplante Validierungsmethode festge-

legt und ebenfalls in ENOVIA dokumentiert.

Artefaktname

Side Mirror Requirements Specification

Strukturierungsart

Hierarchie (Strukturierung mittels Projektion)

Anzahl Elemente

Anzahl Hierarchieebenen

Tabelle 31: Eigenschaften der Anforderungsspezifikation des mechatronischen Außen-

spiegels

In Abbildung 78 ist ein Ausschnitt der beschriebenen Anforderungshierarchie (links)

sowie die textuelle Beschreibung der Anforderung „Maximum Angle“ (rechts) darge-

stellt, welche den maximalen Ausschlagwinkel des Spiegelglases vorgibt. Es wird

deutlich, dass die Anforderungen über eine textuelle Beschreibung verfügen (im Feld

„Beschreibung“ in der rechten Abbildung) und Parameter nicht explizit sondern nur

als Bestandteil der Beschreibung angegeben wurden.

Abbildung 78: Darstellung eines Ausschnitts der Anforderungshierarchie (links) sowie Eigen-

schaften der Anforderung „Maximum Angle“ (rechts) in CATIA V6 (vgl. [Amin

et al. 2012])

Anwendung der Methoden zur Entwicklung eines technischen Systems

189

7.2.3 VORENTWURF DER FUNKTIONEN UND EIGENSCHAFTEN

Im Anschluss an die Dokumentation der Anforderungen wurden alle für deren Erfül-

lung notwendigen Funktionen des mechatronischen Außenspiegels identifiziert und

im Funktionsmodul von CATIA V6 in einer Funktionsstruktur mit sog. „Building Blocks“

modelliert. Die Funktionsstruktur bestand aus insgesamt 20 Elementen. Eine Auflistung

der wichtigsten Funktionen wird im Folgenden kurz dargestellt:

- Hauptfunktionen (Spiegelglaseinstellung)

- Sicherheitsfunktionen (Toter Winkel Warnung, Spiegelglasbeheizung)

- Komfortfunktionen (Spiegel einklappen, Fahrtrichtung anzeigen, Außenbe-

leuchtung)

- Außenspiegel kontrollieren (Regelung der unterschiedlichen Funktionen des

Außenspiegels)

- Nutzereingaben erfassen (Erfassung der Nutzereingaben zur Steuerung unter-

schiedlicher Funktionen)

- Umgebungszustand erfassen

Nach Modellierung der Funktionen wurden diese mit Informationsflüssen verknüpft,

um interne Abhängigkeiten abzubilden. Die so modellierte Funktionsstruktur ist in Ab-

bildung 79 dargestellt.

Abbildung 79: Funktionsstruktur des mechatronischen Außenspiegels [Amin et al. 2012]

Anwendung der Methoden zur Entwicklung eines technischen Systems

190

Ziel der Studenten bei der Modellierung der Funktionsstruktur (Eigenschaften siehe

Tabelle 32) war es, einen Schritt von den abstrakten Anforderungen hin zur tatsächli-

chen späteren Umsetzung zu nehmen. Deshalb wurden die Funktionen nicht lö-

sungsneutral formuliert, sondern unter Berücksichtigung der tatsächlichen Lösungs-

elemente. Diese Vorgehensweise erwies sich später als sinnvoll, da sie im weiteren

Verlauf des Projekts aufgrund abgegrenzter Aufgaben und klar definierter Schnittstel-

len paralleles Arbeiten ermöglichte.

Artefaktname

Side Mirror Functional

Strukturierungsart

Hierarchie

Anzahl Elemente

Anzahl Hierarchieebenen

Tabelle 32: Eigenschaften der Funktionsstruktur des mechatronischen Außenspiegels

7.2.4 ERFASSUNG VON TRACELINKS ZWISCHEN ANFORDERUNGEN UND FUNKTIONEN

Im Anschluss an die Fertigstellung der Funktionsstruktur galt es die Nachverfolgbarkeit

zwischen den Anforderungen und der Funktionsstruktur herzustellen, um zu dokumen-

tieren, welche Funktionen zur Erfüllung welcher Anforderungen beitragen. Die Stu-

denten wendeten zu diesem Zweck die in CATIA vorgesehene manuelle Modellie-

rung von Tracelinks an, die im Folgenden kurz beschrieben wird:

Manuelle Modellierung von Tracelinks: Zum Zweck der Verknüpfung von Elementen

verfügt CATIA V6 über die sog. Implementierungsbeziehungen, die von den Studen-

ten verwendet wurden, um die Anforderungen und Funktionen miteinander zu ver-

knüpfen. Diese Beziehungen sind typisierte und gerichtete Tracelinks, die ausdrücken,

dass eine Anforderung durch eine Funktion implementiert wird.

Ausgehend von der Anforderungsspezifikation wird dabei in CATIA der Strukturbaum

abgelaufen und nacheinander für jedes der 36 Anforderungs-Elemente überprüft,

durch welche der 20 Funktionen die Anforderung realisiert wird. Sollte eine Abhän-

gigkeit bestehen wird durch Auswahl der Anforderung und Öffnen des Kontextmenüs

die Modellierung einer Implementierungsbeziehung gestartet (siehe Abbildung 80).

Anschließend wird durch Navigation in der Funktionsstruktur die betroffene Funktion

ausgewählt und die Implementierungsbeziehung bestätigt.

Anwendung der Methoden zur Entwicklung eines technischen Systems

191

Abbildung 80: Anlegen einer Implementierungsbeziehung zwischen einer Anforderung und

einer Funktion (vgl. [Amin et al. 2012])

Diese Vorgehensweise wurde teilweise online während der Modellierung der Artefak-

te durch die Studenten verwendet, um einen Tracelink zu modellieren. Um bei dieser

Analyse jedoch keine Abhängigkeit zu übersehen, wurden die Elemente zusätzlich

nach Fertigstellung der Artefakte (offline) auf Abhängigkeiten überprüft. Dabei wur-

den alle Anforderungen nacheinander betrachtet und hinsichtlich Abhängigkeiten

zu den Funktionen der Funktionsstruktur analysiert. Dieses Vorgehen erforderte insge-

samt 720 (teilweise implizite) Entscheidungen der Studenten über die Existenz einer

Abhängigkeit zwischen jeweils zwei Elementen. Wie in Kapitel 3.7.2 beschrieben, sind

diese Entscheidungen nicht immer leicht zu treffen. So ist die Entscheidung, einen

Tracelink zwischen der Anforderung, in der die maximale Heizdauer von 360 s spezifi-

ziert wird, und der Funktion „Außenspiegel beheizen“ zu modellieren, vergleichswei-

se einfach. Auch die Entscheidungen, dass die genannte Anforderung keine Ab-

hängigkeit zur Funktion „Toter Winkel Warnung“ aufweist, ist leicht zu treffen. Welche

der modellierten Funktionen an der Umsetzung der Anforderung „elektronische Ver-

stellbarkeit des Außenspiegels vorsehen“ beteiligt sind, ist hingegen weniger leicht zu

bestimmen, da mehrere Teilfunktionen die Verstellbarkeit realisieren.

Modellierung von Tracelinks mit EcoTracing: Zur strukturierten Durchführung dieser

Abhängigkeitsanalyse, bei der keine Kombinationen übersehen und trotzdem die

notwendigen Aufwände minimiert werden, lässt sich die Methode EcoTracing einset-

zen. Durch eine Integration der Methode in V6 lassen sich die bereits modellierten Ar-

tefakte zu Beginn der Analyse auswählen. In Abbildung 81 ist dies für die Anforde-

rungsspezifikation und die Funktionsstruktur dargestellt

Da zum aktuellen Zeitpunkt noch keine Integration des Prototypen mit der V6-Suite von

Dassault Systèmes existiert, wurden die Artefakte des Außenspiegels nachmodelliert und in

den ModelTracer importiert.

Anwendung der Methoden zur Entwicklung eines technischen Systems

192

Abbildung 81: Anwendung der Methode EcoTracing zur Abhängigkeitsanalyse zwischen An-

forderungen und Funktionen des Außenspiegels

Anschließend wird der Analysevorgang gestartet. Der EcoTracing-Algorithmus hebt

dabei nacheinander jeweils ein Elementepaar zur Bewertung grün hervor. Der Ent-

wicklungsingenieur, der diese Bewertung durchführt, entscheidet durch Auswahl des

jeweiligen Buttons, ob eine Abhängigkeit zwischen Anforderung und Funktion be-

steht. Im Anschluss an die Entscheidung springt der Algorithmus zum nächsten Ele-

mentepaar. Wie bei der manuellen Modellierung von Tracelinks sind insgesamt ma-

ximal 720 Kombinationen von Anforderungen und Funktionen zu untersuchen (dar-

gestellt als Fortschrittsbalken).

Vergleich der beiden Vorgehensweisen: Für den Nutzer, der die Abhängigkeitsanaly-

se mit EcoTracing durchführt, ergeben sich im Vergleich zur Standardvorgehensweise

in CATIA V6 einige Vorteile. So wird das Übersehen einer Elementekombination und

damit eines möglichen Tracelinks durch die schrittweise Abarbeitung des Algorithmus

(siehe Abbildung 53) ausgeschlossen. Zwar können dem Anwender teilweise schwie-

rige Entscheidungen hinsichtlich der Abhängigkeit von Elementen nicht gänzlich er-

spart werden, jedoch ermöglicht der Algorithmus die Verringerung der Anzahl an

Entscheidungen um ca. 59 %, da nicht tatsächlich 720 Elementkombinationen, wie

bei der manuellen Vorgehensweise, sondern nur 295 Kombinationen untersucht wer-

den müssen. Zur Modellierung eines Tracelinks müssen dabei aufgrund der Umset-

zung der Methode als Wizard im Gegensatz zur manuellen Vorgehensweise keine

Kontextmenüs geöffnet und Auswahlen durchgeführt, sondern nur auf den Button

Anwendung der Methoden zur Entwicklung eines technischen Systems

193

„bestätigen“ geklickt werden. Diese Art der Tracelink-Modellierung kann natürlich

auch nachteilig sein, wenn während der Modellierung der Artefakte schnell ein

Tracelink erstellt werden soll

. Allerdings ist diese unstrukturierte Vorgehensweise oh-

ne nachgelagerte Vollständigkeitsüberprüfung ohnehin nicht zu empfehlen, da nicht

davon ausgegangen werden kann, dass tatsächlich alle relevanten Elemente in

Kombination untersucht wurden. Das Ergebnis der EcoTracing-Anwendung ist hinge-

gen eine vom Nutzer durchgeführte Abhängigkeitsanalyse, deren Vollständigkeit ga-

rantiert werden kann, ohne dass alle Elementekombinationen tatsächlich untersucht

werden müssen.

7.2.5 VORENTWURF DES SYSTEMMODELLS

Im Anschluss an die Abhängigkeitsanalyse wurden für die zu realisierenden Funktio-

nen Wirkprinzipien und Lösungselemente gewählt und als Verhaltensmodell in dem in

CATIA integrierten DYMOLA-Editor modelliert. Insgesamt wurden sieben Module als

Blöcke definiert: Spiegelglasverstellung, Einklappmechanismus, Speichermodul, Blin-

ker-Modul, Toter-Winkel-Warner, Außenbeleuchtung sowie Spiegelglasbeheizung.

Diese Module wurden aufgrund klar definierter Schnittstellen durch mehrere Studen-

ten gleichzeitig in Form von Modelica-Modellen entwickelt. Die in diesen Modellen

enthaltenen Systemelemente wurden dabei mit Elementen aus der Modelica-

Bibliothek abgebildet. In Abbildung 82 ist dies für die Spiegelglasbeheizung darge-

stellt. In diesem Modell steuern ein „timer“, mit dem die maximale Dauer der Behei-

zung definiert wird sowie ein Schalter, der mit „booleanExpression2“ abgebildet wur-

de, die Beheizung des Außenspiegels. Sind beide aktiv, wird die Heizspirale, repräsen-

tiert durch einen Heizwiderstand, aktiviert. Das Spiegelglas wird durch die Kombinati-

on eines „heatCapacitor“ und eines „thermalConductors“ abgebildet.

Wie in Abbildung 82 zu erkennen, werden die verwendeten Objekte dabei auf einer

Zeichenfläche durch Piktogramme dargestellt und mit Hilfe von Signal- und Energie-

flüssen miteinander verknüpft. Neben den genannten wurden zur Modellierung der

anderen Module zahlreiche weitere Objekte verwendet, die hier jedoch nicht im Ein-

zelnen vorgestellt werden. Für nähere Details, den Aufbau der Modelica-Modelle be-

treffend, sei an dieser Stelle auf [Amin et al. 2012, S. 37-46] verwiesen. Die Eigenschaf-

ten des Verhaltensmodells sind in Tabelle 33 zusammengefasst.

Im Fall der Methode EcoTracing müsste dafür dann der Wizard gestartet, die entsprechen-

den Artefakte ausgewählt und das Element gesucht werden.

Anwendung der Methoden zur Entwicklung eines technischen Systems

194

Abbildung 82: Modelica-Modell zur Simulation des Verhaltens der Spiegelglasbeheizung

(vgl. [Amin et al. 2012])

Artefaktname

Side Mirror Logical

Strukturierungsart

Hierarchie

Anzahl Elemente

120

Anzahl Hierarchieebenen

Tabelle 33: Eigenschaften des Verhaltensmodells des mechatronischen Außenspiegels

7.2.6 ERFASSUNG VON TRACELINKS ZWISCHEN FUNKTIONEN UND VERHALTENSMODELL

Nachdem das Verhaltensmodell fertig modelliert war, wurde die durchgängige

Nachverfolgbarkeit zu der Funktionsstruktur hergestellt, um abzubilden, welche Mo-

dule an der Realisierung der Funktionen beteiligt sind. Aufgrund des geringen Detail-

lierungsgrades der Funktionsstruktur war es dabei ausreichend, die höchste Ebene

des Verhaltensmodells in Kombination mit der Funktionsstruktur zu betrachten. Eine

detailliertere Analyse wäre zwar möglich gewesen, allerdings hätten diese Tracelinks

zwischen abstrakten Funktionen und detaillierten Systemelementen im Verhaltens-

modell, wie durch Mäder et al. beschrieben [Mäder et al. 2009a, S. 4] und in Kapitel

5.2.1 diskutiert, keine höhere Aussagekraft als solche auf abstrakter Ebene.

Anwendung der Methoden zur Entwicklung eines technischen Systems

195

Manuelle Modellierung von Tracelinks: Die Vorgehensweise der Studenten war bei

der Abhängigkeitsanalyse die gleiche, wie sie bereits zwischen Anforderungs- und

Funktionsartefakt angewendet wurde: durch sequenzielle Betrachtung aller Funktio-

nen in Kombination mit den logischen Modulen und dem Anlegen von Implementie-

rungsbeziehungen. Insgesamt mussten somit bei der Analyse 140 Entscheidungen

durch die Studenten getroffen werden. U. a. wurde so ein Tracelink zwischen der

Funktion 5.2 „Außenspiegel beheizen“ und dem Modul „Spiegelglasbeheizung“ mo-

delliert.

Modellierung von Tracelinks mit EcoTracing: Wie schon bei der Analyse der Anforde-

rungen in Kombination mit den Funktionen wäre auch in diesem Fall der Einsatz der

Methode EcoTracing möglich gewesen, um die Vollständigkeit der Analyse zu garan-

tieren. Die Anwendung wäre dabei analog zum zuvor beschriebenen Einsatz durch-

zuführen: die Funktionsstruktur und das Verhaltensmodell werden geladen und die

Analyse begonnen. Nacheinander werden Elementepaare aus Funktionen und Mo-

dulen durch den Algorithmus hervorgehoben und müssen hinsichtlich ihrer Realisie-

rungsbeziehung zueinander bewertet werden. Sobald die gewünschte Granularität

der Tracelinks erreicht ist, wird die Analyse beendet. Insgesamt müssten

104 Entscheidungen getroffen werden.

Vergleich der beiden Vorgehensweisen: Aufgrund der flachen Hierarchie des Verhal-

tensartefakts, bei dem abgesehen von der höchsten hierarchischen Ebene alle wei-

teren Elemente bei der Analyse nicht berücksichtigt werden, lassen sich nicht diesel-

ben Einsparungen erreichen wie bei der in Kapitel 7.2.4 beschriebenen Analyse.

Dennoch ermöglicht die Modellierung der Tracelinks mit EcoTracing die schrittweise,

geführte Abarbeitung aller relevanten Elementkombinationen der beiden Artefakte.

Dabei ist die Verringerung der Anzahl notwendiger Entscheidungen um ca. 26 %

möglich, weshalb die Anwendung der Methode im Fall der Analyse von Funktions-

und Verhaltensartefakten sinnvoll ist.

7.2.7 INTEGRIERTE ABSICHERUNG

Die integrierte Absicherung wurde durch die Studenten auf Basis des Verhaltensmo-

dells durchgeführt, um für jedes der Module möglichst frühzeitig dessen Eigenschaf-

ten abschätzen und mit den Anforderungen abgleichen zu können. So wurde bspw.

für die in Kapitel 7.2.5 beschriebene Spiegelglasbeheizung das Aufheizverhalten des

Spiegels simuliert. Die Simulation kam zu dem Ergebnis, dass eine Spiegeloberflächen-

temperatur von 15 °C nach 12 Sekunden erreicht war. Mit Hilfe der zuvor modellier-

ten Tracelinks konnten anschließend leicht die relevanten Anforderungen bestimmt

werden. Zu diesem Zweck wurde ausgehend vom Modul „Spiegelglasheizung“ die

vorhandene Implementierungsbeziehung verfolgt und so die Funktion 5.2 „Außen-

Anwendung der Methoden zur Entwicklung eines technischen Systems

196

spiegel beheizen“ identifiziert. Wiederum ausgehend von dieser Funktion wurden die

Anforderungen „heating“, „heating_manual“ und „heating_automatic“ bestimmt

und hinsichtlich der Spezifikation des Aufheizverhaltens überprüft. Dies wurde in der

Anforderung „heating“ mit einer zu erreichenden Temperatur von 15 °C nach

20 Sekunden beschrieben, womit das modellierte Verhalten das geforderte übertraf.

Diese Absicherung wurde für die unterschiedlichen Module iterativ wiederholt, wenn

enthaltene Komponenten geändert wurden und somit eine Änderung der Eigen-

schaften eines Moduls zu erwarten war.

7.2.8 ENTWICKLUNG MECHANISCHER KOMPONENTEN

Parallel zur Entwicklung des Systemmodells bzw. leicht zeitversetzt begann die Detail-

konstruktion der Bauteile und Baugruppen in CATIA. Dazu wurde zunächst in ENOVIA

eine Produktstruktur erstellt (Eigenschaften siehe Tabelle 34), in der die wichtigsten

Baugruppen abgebildet wurden. In dieser Produktstruktur wurden kontinuierlich die

Bauteile eingepflegt. Aus Sicht der durchgängigen Nachverfolgbarkeit ist vor allen

Dingen diese Produktstruktur von Interesse, weshalb an dieser Stelle darauf verzichtet

wird die Modellierung der Bauteile näher zu beschreiben. Für detaillierte Informatio-

nen, die Konstruktion der einzelnen Bauteile betreffend, sei auf den Projektbericht

von Amin et al. verwiesen [Amin et al. 2012, S. 47-67].

Artefaktname

Side_Mirror_Physical

Strukturierungsart

Hierarchie

Anzahl Elemente

Anzahl Hierarchieebenen

Tabelle 34: Eigenschaften der Produktstruktur des mechatronischen Außenspiegels

7.2.9 ERFASSUNG VON TRACELINKS ZWISCHEN PRODUKTSTRUKTUR UND VERHALTENSMODELL

SOWIE ANFORDERUNGEN

Im Anschluss an die Definition der Produktstruktur war es erneut notwendig, die

durchgängige Nachverfolgbarkeit herzustellen. Im Gegensatz zu den in den Kapi-

teln 7.2.4 und 7.2.6 beschriebenen Analysen waren dabei zwei unterschiedliche Arte-

fakte in Kombination mit der Produktstruktur auf Abhängigkeiten zueinander zu unter-

suchen. Zum einen wurden sog. „Ports“ verwendet, um das Verhaltensmodell und

die 3D-Geometrie in der Produktstruktur zu verknüpfen. Hintergrund dieser Verknüp-

fungen war die Zuordnung von modellierten Systemelementen im Verhaltensmodell

zu deren geometrischer Ausprägung, um die Geometrie auf Basis der Simulationen

im Verhaltensmodell animieren zu können. So war es bspw. möglich, das Einklappen

des Außenspiegels oder das Verstellen des Spiegelglases zu visualisieren und ggf.

Anwendung der Methoden zur Entwicklung eines technischen Systems

197

Überschneidungen der Bauteile festzustellen. Ein Einsatz der Methode EcoTracing ist

zur Erstellung dieser Art von Verknüpfungen nicht vorgesehen.

Manuelle Modellierung von Tracelinks zwischen Produktstruktur und Anforderungen:

Zum anderen wurden Tracelinks zwischen der Produktstruktur und den Anforderun-

gen modelliert, da eine indirekte Verknüpfung über die Artefakte Funktionsstruktur

und Verhalten bei nicht-funktionalen Anforderungen nicht immer möglich ist. Wäh-

rend bspw. die nicht-funktionale Anforderung, in der die maximale Heizdauer von

360 s spezifiziert wird, der Funktion „Außenspiegel beheizen“ zugeordnet werden

kann, ist es nicht möglich, die Anforderung, die die maximale Masse des Außenspie-

gels vorgibt, mit einer Funktion (abgesehen von der Gesamtfunktion) zu verknüpfen.

Bei der Analyse wurden somit nur nicht-funktionale Anforderungen berücksichtigt

und auf Abhängigkeiten zu den Bauteilen und Baugruppen in der Produktstruktur un-

tersucht. Zu diesem Zweck wurden auch hier die Verknüpfungen durch die Studen-

ten mit Hilfe der Implementierungsbeziehung modelliert. Die Vorgehensweise war

dabei analog zu den Analysen zuvor: Ausgehend von den Anforderungen, die

nacheinander durchlaufen werden, wurde überprüft, welche der Bauteile an der

Realisierung der jeweiligen Anforderung beteiligt sind. Lag eine Abhängigkeit vor,

wurde die Modellierung über das Kontextmenü einer Implementierungsbeziehung

gestartet, das Bauteil in der Produktstruktur ausgewählt und die Beziehung bestätigt.

Insgesamt waren 480 Entscheidungen zu treffen.

Modellierung von Tracelinks zwischen Produktstruktur und Anforderungen mit EcoTra-

cing: Zur Modellierung der Tracelinks zwischen nicht-funktionalen Anforderungen und

Bauteilen mit EcoTracing wurden zunächst die beiden Artefakte ausgewählt, beim

Anforderungsartefakt die Vorauswahl auf nicht-funktionale Anforderungen einge-

schränkt und anschließend die Analyse begonnen. Nacheinander wurden Elemente-

paare aus Anforderungen und Bauteilen hervorgehoben und es musste bewertet

werden, ob eine Abhängigkeit besteht. Insgesamt müssten 300 Entscheidungen ge-

troffen werden.

Vergleich der beiden Vorgehensweisen: Auch bei der Modellierung von Tracelinks

zwischen Anforderungen und Bauteilen in der Produktstruktur ist der Einsatz von

EcoTracing sinnvoll, da durch die schrittweise Abarbeitung des Algorithmus ein Über-

sehen von Elementkombinationen ausgeschlossen wird. Zusätzlich können 37,5 % der

Entscheidungen eingespart werden, da insgesamt 180 Entscheidungen weniger ge-

troffen werden müssen.

Anwendung der Methoden zur Entwicklung eines technischen Systems

198

7.2.10 DURCHFÜHRUNG EINER AUSWIRKUNGSANALYSE AUFGRUND EINER GEÄNDERTEN

ANFORDERUNG

Zu jeder Zeit während des Entwicklungsprozesses können die bis dahin modellierten

Tracelinks genutzt werden, um bspw. Auswirkungsanalysen durchzuführen. Dabei

werden im Fall von Änderungen die entsprechenden Tracelinks nachverfolgt und es

wird bewertet, welche der verknüpften Elemente von der Änderung betroffen sind.

Im vorliegenden Fall wird diese Analyse mit dem Traceability-Viewer Ariadne’s Eye

durchgeführt. Im Folgenden wird beispielhaft eine solche Auswirkungsanalyse be-

schrieben und dabei zusätzlich auf die Anwendung der Methode TraceEvaluation

eingegangen:

Nachdem die Funktionsstruktur und das Verhaltensmodell bereits fertiggestellt wur-

den und die Produktstruktur in ihren Grundzügen festgelegt ist, ergibt sich eine Ände-

rung einer Anforderung. Erfahrungen des Kunden, für den der Außenspiegel entwi-

ckelt wird, belegen, dass die Zeit, nach der die Heizung im Spiegel automatisch de-

aktiviert wird, zu kurz gewählt wurde. Diese Zeit soll auf seinen Wunsch hin von 360 s

auf 420 s erhöht werden, um das einwandfreie Abtauen von Schnee und Eis zu ga-

rantieren. Diese Änderung wird durch den Anforderungsmanager in den Eigenschaf-

ten der Anforderung „Heating_automatic“ vorgenommen.

Da dem Anforderungsmanager nicht klar ist, welche Funktionen und Bauteile von

dieser Änderung betroffen sind, entschließt er sich, eine Auswirkungsanalyse durchzu-

führen. Zu diesem Zweck startet er Ariadne’s Eye und verfolgt, ausgehend von der

geänderten Anforderung, die Tracelinks zu den Funktionen und Bauteilen. Dabei

identifiziert er folgende, potenziell betroffene Funktionen und Bauteile:

- Funktion: Nutzereingaben Erfassen (heating_switch),

- Funktion: Außenspiegel kontrollieren (side_mirror_control_module),

- Funktion: Spiegelglasbeheizung (heating_mirror),

- Bauteil: Heizspirale (heating).

Außerdem fällt ihm auf, dass die betrachtete Anforderung, neben den zuvor ge-

nannten Verknüpfungen, auch einen Tracelink zu dem Bauteil “Connector Folding

Modul” aufweist, den er nicht erwartet hätte. Er wählt diesen Link in Ariadne’s Eye

aus, ruft das Kontextmenü auf und markiert ihn für eine spätere Überprüfung (siehe

Abbildung 83). Im Anschluss fährt er mit seiner Auswirkungsanalyse fort und setzt sich

mit seinen Kollegen aus der Detailkonstruktion sowie mit dem, für die Funktionsstruktur

verantwortlichen, Systemarchitekten in Verbindung.

Anwendung der Methoden zur Entwicklung eines technischen Systems

199

Abbildung 83: Impact Analyse in Ariadne's Eye & Anwendung der Methode TraceEvaluation

7.2.11 DURCHFÜHRUNG EINER QUALITÄTSKONTROLLE DES TRACELINK-MODELLS

Zu einem späteren Zeitpunkt führt der Traceability-Verantwortliche eine Qualitätskon-

trolle für das aktuelle Außenspiegel-Entwicklungsprojekt durch. Dazu startet er das

Auswertungsmodul im ModelTracer und wählt zunächst den Reiter „Bewertungen“

aus (siehe Abbildung 84). In diesem laufen alle Meldungen über potenziell falsche

Tracelinks zusammen, so dass sie nacheinander abgearbeitet werden können. Im

vorliegenden Fall hat seit der letzten Kontrolle nur der Anforderungsmanager einen

potenziell falschen Tracelink gemeldet (siehe Kapitel 7.2.10). Der Traceability-

Verantwortliche erhält die Informationen über die Start- und Zielelemente sowie die

Anzahl der Meldungen, die gleichzeitig als Ranking genutzt werden. Nach kurzer

Überprüfung der Baugruppe in CATIA V6 entscheidet er, dass der Tracelink fälschli-

cherweise modelliert wurde und löscht ihn aus der Datenbank des ModelTracers.

Abbildung 84: Auswertungsmodul der Methode TraceEvaluation

Anwendung der Methoden zur Entwicklung eines technischen Systems

200

Im Anschluss an die Auswertung der Methode TraceEvaluation entschließt sich der

Traceability-Verantwortliche eine weitere Maßnahme durchzuführen. Er wählt zu die-

sem Zweck im Qualitätssicherungsmodul des ModelTracers den Reiter Legacy aus

und konfiguriert die Einstellungen der Methode TraceLegacy. Zunächst editiert er

durch Klick auf den Button „Blacklist“ die Negativliste, in der Begriffe dokumentiert

sind, die während der Analyse ignoriert werden. Da alle Elemente zur leichteren Iden-

tifikation im PDM-System die Endung des Entwicklungsteams „Team 1“ tragen, fügt er

dieser Liste den Begriff „team 1“ hinzu, da sonst u. U. irrelevante Ähnlichkeiten identi-

fiziert werden würden. Bevor er die Analyse startet, aktiviert er die Stammformrück-

führungsoption, mit deren Hilfe die Worte der Elementbezeichner auf ihren Wort-

stamm zurückgeführt werden. Das Ergebnis der Analyse ist in Abbildung 85 darge-

stellt.

Abbildung 85: Ergebnis der Analyse mittels TraceLegacy

Da es sich nicht um die erste Außenspiegel-Entwicklung seiner Firma handelt, sondern

bereits mehrere Entwicklungen im selben Umfeld durchgeführt wurden, greift das Sys-

tem auf einen großen Wissensschatz, der mittels Tracelinks dokumentiert wurde, zu-

rück. Insgesamt werden ihm durch das System sieben Vorschläge für fehlende

Tracelinks angeboten. Diese Vorschläge wurden aufgrund ähnlich benannter Anfor-

derungen bzw. Bauteile in vergangenen Projekten ausgegeben. Nach Überprüfung

stellt der Traceability-Verantwortliche fest, dass die folgenden vier Vorschläge korrekt

sind:

- Anforderung: electronic_adjustment | Baugruppe: mirror_actuator,

- Anforderung: width | Bauteil: cover_shell,

- Anforderung: folding | Baugruppe: folding_module,

- Anforderung: turn_signal | Bauteil: turn_signal_cover.

Er wählt die Vorschläge nacheinander aus, bestätigt die Abhängigkeiten zwischen

den jeweiligen Elementen und modelliert somit direkt vier Tracelinks, die im Tracelink-

Modell bisher gefehlt haben.

Anwendung der Methoden zur Entwicklung eines technischen Systems

201

Mit Hilfe der beiden Methoden TraceEvaluation und TraceLegacy hat der Traceabili-

ty-Verantwortliche somit einen falschen Tracelink und vier Abhängigkeiten, bei de-

nen vergessen wurde, einen Tracelink zu modellieren, identifizieren können. Während

die Beseitigung aller Fehler wichtig ist, tragen insbesondere die durch ihn hinzugefüg-

ten vier Tracelinks zur Verbesserung des Tracelink-Modells bei, da somit bspw. bei zu-

künftigen Auswirkungsanalysen diese Abhängigkeiten berücksichtigt werden können.

7.3 ZUSAMMENFASSUNG

In Kapitel 7 wurde die Anwendung der in dieser Arbeit entwickelten Methoden

EcoTracing, TraceEvaluation und TraceLegacy während der Entwicklung eines tech-

nischen Systems beschrieben. Dazu wurde zunächst in Kapitel 7.1 anhand des Fraun-

hofer IPK V-Modells aufgezeigt, wann die Methoden im Entwicklungsprozess einge-

setzt werden können. Anschließend wurden die Methoden am Beispiel der Entwick-

lung eines mechatronischen Außenspiegels demonstriert. Ziel war es, den Einsatz der

Methoden durch Entwickler und die sich daraus ergebenden Vorteile zu beschrei-

ben. So lässt sich EcoTracing zur strukturierten Abhängigkeitsanalyse der meisten ent-

stehenden Artefakte einsetzen und durch die Anwendung der Methode die Berück-

sichtigung aller Elemente garantieren. Darüber hinaus konnte im dargestellten Bei-

spiel die Anzahl teilweise schwer zu treffender Entscheidungen durch den EcoTra-

cing-Algorithmus um 26 % - 59 % reduziert werden (siehe Abbildung 86).

Abbildung 86: Übersicht der erstellten Artefakte, modellierter Tracelinks (rote Pfeile) sowie

der erreichten Ersparnis durch EcoTracing (wenn angewendet)

Hinsichtlich der intuitiven Erfassung von Tracelinks kann der Methode EcoTracing ihre

Konzeption als Offline-Methode negativ ausgelegt werden. Dabei werden Tracelinks

nicht bei Erkennen einer Abhängigkeit während der Erstellung der Artefakte, sondern

in einem dedizierten Arbeitsschritt erfasst. Während eine Funktionalität zur schnellen

Online-Modellierung von Tracelinks aus Sicht des Autors dringend erforderlich ist, da

die Artefakte aufgrund bestimmter Abhängigkeiten modelliert werden (bspw. wurde

die Funktion „Spiegelglasbeheizung“ nur modelliert, weil es eine entsprechende An-

forderung in der Anforderungsspezifikation gab), die direkt dokumentiert werden soll-

ten, kann aufgrund dieser unstrukturierten Vorgehensweise nicht davon ausgegan-

Anwendung der Methoden zur Entwicklung eines technischen Systems

202

gen werden, dass tatsächlich alle relevanten Elementepaare untersucht wurden.

Genau hier liegen die Vorteile der Offline-Erfassung mit EcoTracing, bei der struktu-

riert alle Elementekombinationen überprüft werden und eine Vollständigkeit der Ana-

lyse garantiert werden kann. Die Kombination einer Online- mit einer nachgelager-

ten Offline-Erfassung ist somit empfehlenswert.

Der Einsatz der Methode TraceEvaluation wurde exemplarisch anhand einer Auswir-

kungsanalyse beschrieben, die aufgrund einer geänderten Anforderung durchge-

führt wurde (siehe Kapitel 7.2.10). Dabei wurde ein falsch positiver Tracelink durch ei-

nen Anforderungsmanager bei Durchführung seiner Analyse identifiziert, gemeldet

und später vom Traceability-Verantwortlichen gelöscht (siehe Kapitel 7.2.11). Es wur-

de deutlich, dass die Methode TraceEvaluation in Methoden, die aktuell verwendet

werden, integriert werden muss, um eine große Reichweite und damit Wirksamkeit zu

erreichen.

Als weitere Qualitätssicherungsmaßnahme wurde die Methode TraceLegacy auf die

Beispieldaten angewendet. Dabei wurden vier Abhängigkeiten von Elementen des

aktuellen Projekts auf Basis modellierter Tracelinks aus einem vergangenen Projekt

identifiziert und anschließend durch Tracelinks dokumentiert. Die Identifikation dieser

falsch negativen Tracelinks ist insofern wichtig, da deren Fehlen eine fehlerhafte

Auswirkungsanalyse und damit die Nichtberücksichtigung von Auswirkungen einer

Änderung zur Folge haben kann.

203

8 ZUSAMMENFASSUNG UND AUSBLICK

Die durchgängige Nachverfolgbarkeit ist eine aus der Informatik stammende Me-

thode, bei der Abhängigkeiten zwischen unterschiedlichen Artefakten der Entwick-

lung mit sog. Tracelinks dokumentiert werden. Die vorliegende Arbeit widmet sich

dem Thema „durchgängige Nachverfolgbarkeit“ aus Sicht der Entwicklung mechat-

ronischer Systeme. Um diesen Kontext zu beschreiben, wurden in Kapitel 2 fünf Vor-

gehensmodelle sowie die für die Analyse- und Syntheseschritte verwendeten Model-

le und Dokumente analysiert und diskutiert. Vor diesem Hintergrund wurden in Kapi-

tel 3 die Grundlagen durchgängiger Nachverfolgbarkeit vorgestellt, die Vor- und

Nachteile beschrieben und herausgearbeitet, dass sich nicht alle aus der Software-

entwicklung bekannten Prinzipien auf den erweiterten Kontext der Entwicklung me-

chatronischer Systeme anwenden lassen. Insbesondere zur Erfassung und Pflege von

Tracelinks existieren bislang nur wenige Methoden, die eine Unterstützung für diese

essentiellen Phasen bieten, was massiv zum schlechten (wahrgenommenen) Auf-

wand/Nutzen-Verhältnis der durchgängigen Nachverfolgbarkeit beiträgt und daher

eine große Hürde für deren industrielle Nutzung darstellt. Aus diesem Grund be-

schränkt sich die Anwendung durchgängiger Nachverfolgbarkeit aktuell hauptsäch-

lich auf Bereiche, in denen sie explizit durch die Gesetzgebung gefordert wird.

Um eine größere industrielle Verbreitung der durchgängigen Nachverfolgbarkeit und

der damit verbundenen Vorteile für die Entwicklung mechatronischer Systeme zu er-

reichen, ist es notwendig, unterstützende Methoden für eben diese Phasen der Erstel-

Zusammenfassung und Ausblick

204

lung sowie Pflege des Tracelink-Modells zur Verfügung zu stellen. Die Forderung nach

einer Reduktion des für die durchgängige Nachverfolgbarkeit notwendigen Auf-

wands stellt den Ausgangspunkt für die drei, in dieser Arbeit behandelten, For-

schungsfragen dar.

Zur Beantwortung dieser Forschungsfragen wurden insgesamt drei Methoden entwi-

ckelt und evaluiert. Die erarbeiteten Ergebnisse werden im folgenden Kapitel 8.1 zu-

sammengefasst und ein Ausblick auf notwendige Weiterentwicklungen für einen in-

dustriellen Einsatz der Methoden gegeben. Im anschließenden Kapitel 8.2 werden

Einsatzmöglichkeiten aufgezeigt und die damit verbundenen Auswirkungen auf die

Integration der Methoden in die IT-Architektur eines Unternehmens diskutiert. Ab-

schließend werden in Kapitel 8.3 unterschiedliche, unbeantwortete Forschungsaspek-

te aus dem Themengebiet der durchgängigen Nachverfolgbarkeit zusammenge-

fasst, die während der Bearbeitung der vorliegenden Arbeit identifiziert wurden, die

weitere Forschungsrichtungen erschließen.

8.1 ZUSAMMENFASSUNG DER ERGEBNISSE DIESER ARBEIT

Im Rahmen der vorliegenden Arbeit wurden die drei Methoden EcoTracing, Trace-

Evaluation und TraceLegacy entwickelt, um Forschungsfragen aus den Bereichen

der Erstellung und Pflege von Tracelink-Modellen zu beantworten. In den folgenden

drei Kapiteln 8.1.1 bis 8.1.3 werden die Entwicklung der Methoden sowie ihre Evalua-

tion zusammenfassend beschrieben und die zugehörigen Forschungsfragen beant-

wortet. Darüber hinaus wird ein Ausblick auf Weiterentwicklungen gegeben, die für

die Industrialisierung der Methoden notwendig wären.

8.1.1 ECOTRACING

In Kapitel 5 wurde zunächst die Modellierung von Tracelinks betrachtet und die For-

schungsfrage untersucht, ob eine methodische Unterstützung des Entwicklers helfen

kann, den Aufwand bei der Modellierung von Tracelinks zu verringern. Während ver-

gleichbare Methoden des Stands der Technik zusätzliche Bearbeitungsschritte benö-

tigen, nutzt der Algorithmus, der in diesem Zusammenhang entwickelten Methode

EcoTracing, den hierarchischen Aufbau der systembeschreibenden Artefakte, um

die Anwender strukturiert durch Abhängigkeitsanalysen zu führen und dabei Auf-

wände einzusparen. Bei der, zum Zweck der Evaluation der Leistungsfähigkeit der

Methode EcoTracing, durchgeführten Studie konnte im arithmetischen Mittel eine

Aufwandsersparnis von ca. 60 % erreicht werden. Die Forschungsfrage kann somit

positiv beantwortet werden: der Modellierungsaufwand lässt sich durch methodische

Unterstützung, welche die Eigenschaften kompositioneller Hierarchien ausnutzt, redu-

Zusammenfassung und Ausblick

205

zieren. Allerdings wurde als Einschränkung festgestellt, dass es für den Einsatz der Me-

thode erforderlich ist, dass der Anwender über eine umfassende Kenntnis der zu ana-

lysierenden Artefakte und deren Aufbau verfügt, da er sonst nicht in der Lage ist, die

notwendigen Entscheidungen auf hoher Abstraktionsebene zu fällen.

Um die Methode EcoTracing im industriellen Umfeld einsetzen zu können, sind noch

weiterführende Implementierungs- und Evaluationsaufgaben im Anschluss an diese

Arbeit zu leisten. Zunächst sollte eine Umsetzung in Rational DOORS verfolgt werden

(siehe Kapitel 3.6.1.1), da es sich hierbei um eine weit verbreitete Software zur Ver-

waltung von Anforderungen handelt, zwischen denen die durchgängige Nachver-

folgbarkeit bereits heute vielfach manuell etabliert wird. Darüber hinaus wird DOORS

während der Entwicklung von Embedded Systems teilweise zweckentfremdet, um

neben Anforderungsspezifikationen auch Funktionshierarchien zu verwalten (siehe

dazu auch Kapitel 5.1 und 5.2.3). Es wäre somit möglich, zwei unterschiedliche, be-

reits heute existierende Anwendungsfälle (prozessphasen-interne und -externe

Tracelinks) abzudecken. Diese Umsetzung sollte anschließend genutzt werden, um

eine Evaluation der Methode mit Datenumfängen industriellen Ausmaßes (hinsicht-

lich der Anzahl an Elementen und Hierarchieebenen) durchzuführen. Dabei ist zu be-

rücksichtigen, dass möglichst die Entwickler selbst die Abhängigkeitsanalyse durch-

führen, um die zuvor erwähnte notwendige Kenntnis der Artefakte voraussetzen zu

können. Sollte diese Evaluation positiv verlaufen und Interesse seitens der Industrie

vorliegen, wäre im nächsten Schritt die Implementierung der Methode in einem PLM-

System (bspw. Teamcenter) durchzuführen, um möglichst alle Artefakte, die während

der Entwicklung erstellt werden, mit EcoTracing analysieren zu können. In Abhängig-

keit der geplanten Verwendung der Tracelinks und des verwendeten PLM-Systems

wäre es dabei sinnvoll, die Methode EcoTracing um die Funktionalität, typisierte

Tracelinks modellieren zu können, zu erweitern.

8.1.2 TRACEEVALUATION

Einmal erstellt, müssen die Tracelink-Modelle kontinuierlich gepflegt werden, um ihre

Qualität und damit ihre Einsetzbarkeit bspw. für Auswirkungsanalysen sicherzustellen.

Da die Aufwände auch hierfür als erheblich einzuschätzen sind, wurden unterschied-

liche Methoden im Bereich der Unterstützung der Qualitätssicherung von Tracelink-

Modellen erforscht. Zunächst wurde untersucht, ob sich Crowdsourcing (deutsch:

Schwarmauslagerung), als relativ neue Strategie einer Vielzahl von Diensten im Inter-

net, für die Qualitätssicherung von Tracelink-Modellen eignet. Denn obwohl das

Crowdsourcing eine immer größere Verbreitung findet, wurde dessen Einsatz im Kon-

text der durchgängigen Nachverfolgbarkeit bisher weder erforscht noch kommerziell

realisiert. Die zur Überprüfung dieser Frage entwickelte Methode TraceEvaluation

Zusammenfassung und Ausblick

206

stellt Experten während der Bearbeitung ihrer Aufgaben im Tagesgeschäft die Mög-

lichkeit zur Verfügung, fehlerhafte Tracelinks für eine spätere Überprüfung zu melden.

Durch dieses Verfahren lässt sich das Feedback vieler Nutzer schnell sammeln und

zentral leicht auswerten. Auch diese Methode wurde im Rahmen einer Studie evalu-

iert. Die dabei erreichte Trefferquote von 100 % sowie die Präzision von 88 % sind als

exzellent zu bewerten. Hinsichtlich der gestellten Forschungsfrage lässt sich somit aus-

sagen, dass sich Methoden des Crowdsourcings sehr gut zur Steigerung Tracelink-

Modell-Qualität eignen. Es zeigte sich jedoch auch, dass keiner der Probanden allein

in der Lage war, alle falschen Tracelinks zu identifizieren. Mehrere hingegen schon,

weshalb die Methode in industrieller Anwendung einer großen Anzahl an Nutzern zur

Verfügung gestellt werden sollte.

Für die Industrialisierung der Methode TraceEvaluation muss zunächst ein Unterneh-

men gefunden werden, das bereits heute zumindest die durchgängige Nachver-

folgbarkeit der Anforderungen etabliert. Bei der Wahl sollte darauf geachtet werden,

dass dies möglichst nicht nur zu Dokumentationszwecken geschieht, sondern die

Tracelinks darüber hinaus für weitere Verwendungszwecke (bspw. Auswirkungsanaly-

sen) genutzt werden. Hintergrund dieser Forderung ist, dass erst bei der tatsächlichen

Nutzung falsch modellierte Tracelinks auffallen und somit auch erst dann gemeldet

werden können. Bei diesem Anwender sollte evaluiert werden, welche Software-

Werkzeuge die Tracelinks verwenden und wo diese verwaltet werden. Diese Erfas-

sung stellt dann die Basis für die Integration des Anwender- und des Auswertungs-

moduls entsprechend der Beschreibung in Kapitel 6.3.2 dar. Abschließend ist es not-

wendig, die Entwickler aufzufordern, zur Sicherung der Qualität des Tracelink-Modells

beizutragen und ggf. ein entsprechendes Entlohnungssystem (siehe Kapitel 6.3.1) zu

entwickeln.

8.1.3 TRACELEGACY

Ebenfalls aus dem Bereich der Unterstützung der Qualitätssicherung von Tracelink-

Modellen stammt die dritte betrachtete Forschungsfrage. Sie hinterfragt, ob sich

Tracelinks aus vergangenen Entwicklungsprojekten als Wissensquelle für die Siche-

rung der Tracelink-Modellqualität aktueller Projekte nutzen lassen. Zur Untersuchung

dieser Frage wurde die Methode TraceLegacy entwickelt, die Entwicklungswissen

vergangener Projekte nutzt, um Vorschläge für fehlende Tracelinks zu generieren. Die

Evaluation, die anhand zweier Studentenprojekte durchgeführt wurde, ergab Tref-

ferquoten von 4 % bis 11 % sowie Präzisions-Werte von 61 % bis 90 %. Die grundsätzli-

che Funktionsfähigkeit der Methode wurde nachgewiesen und damit die For-

schungsfrage positiv beantwortet. Aus den Tracelinks vergangener Projekte können

zur Steigerung der Tracelink-Modell-Qualität sinnvolle Vorschläge für Tracelinks aktuel-

Zusammenfassung und Ausblick

207

ler Projekte berechnet werden. Es konnten zudem Vorschläge für Tracelinks generiert

werden, die mit den Ansätzen aus dem Stand der Technik nicht zu identifizieren ge-

wesen wären. Anzumerken bleibt, dass insbesondere hinsichtlich der erreichbaren

Präzision ein großes Potenzial für Verbesserung besteht. Da im Rahmen dieser Arbeit

die Überprüfung der Machbarkeit und nicht die Optimierung der Methode im Vor-

dergrund stand, wurde ein vergleichsweise einfacher Algorithmus zur Bestimmung

der Ähnlichkeit der Elemente verwendet (Stringvergleich stammrückgeführter Ele-

mentbezeichner), auf den die schlechten Präzisions-Werte zurückzuführen sind.

Erster Schritt auf dem Weg zur Industrialisierung der Methode TraceLegacy muss es

somit sein, den Algorithmus gegen mächtigere aus dem Bereich der Informations-

rückführung auszutauschen und somit die Trefferquote der Methode zu steigern.

Denkbar wäre es in diesem Zusammenhang, ähnlich der Realisierung in der Software

ConWeaver (siehe Kapitel 3.6.4.2), mehrere unterschiedliche Algorithmen zu imple-

mentieren. Aus diesen könnten, je nach Bedürfnissen der Anwender bzw. in Abhän-

gigkeit der Art und des Aufbaus der zu analysierenden Artefakte, passende Algo-

rithmen ausgewählt und die Methode TraceLegacy somit individuell konfiguriert

werden. Anschließend sollte die Integration in die Software, die für die Verwaltung

der Tracelinks verwendet wird, erfolgen.

8.1.4 FAZIT

Im Rahmen der vorliegenden Arbeit wurden die drei Methoden EcoTracing, Trace-

Evaluation und TraceLegacy konzipiert, prototypisch implementiert und evaluiert, um

Forschungsfragen aus den Bereichen der Erfassung von Tracelinks sowie der Pflege

von Tracelink-Modellen beantworten zu können. Übergeordnetes Ziel war es in die-

sem Zusammenhang, Entwickler bei der oft manuellen Modellierung von Tracelinks

und dem Suchen nach Fehlern im Tracelink-Modell zu unterstützen und, wenn mög-

lich, die Aufwände für diese Tätigkeiten im Vergleich zur gelebten Praxis zu reduzie-

ren. Dieses Ziel wurde erreicht, da mit EcoTracing eine Reduzierung des notwendigen

Modellierungsaufwands erreicht und mit TraceEvaluation sowie TraceLegacy falsche

bzw. fehlende Tracelinks identifiziert werden können. Dabei wurden, wie in den vo-

rangegangenen Kapiteln 8.1.1 bis 8.1.3 beschrieben, unterschiedliche Stadien der

Anwendungsreife erreicht. Während TraceEvaluation, abgesehen von der optiona-

len Entwicklung eines Entlohnungssystems, ohne Anpassungen in kommerzielle Soft-

wareprodukte integriert werden könnte, sind sowohl bei EcoTracing als auch

TraceLegacy noch weiterführende Evaluations- und Implementierungsschritte durch-

zuführen.

Für alle drei Methoden gilt dabei gleichermaßen, dass sie lediglich Teilaspekte der in

Kapitel 3.7 beschriebenen Herausforderungen adressieren und damit drei Puzzletei-

Zusammenfassung und Ausblick

208

len entsprechen, die einen Beitrag zur Steigerung der Effizienz und Qualität durch-

gängiger Nachverfolgbarkeit leisten können [Aizenbud-Reshef et al. 2006, S. 523]. Um

jedoch eine umfassende Lösung bereitzustellen, ist es notwendig, EcoTracing, Tra-

ceEvaluation und TraceLegacy zielgerichtet mit anderen Methoden zu kombinieren.

Neben Methoden aus dem Bereich der Erstellung und Pflege von Tracelink-Modellen

sollten dabei insbesondere Methoden zur Verwendung der modellierten Tracelinks

berücksichtigt werden, um die vielfältigen Anwendungsmöglichkeiten der durch-

gängigen Nachverfolgbarkeit auszunutzen und somit das Aufwand/Nutzen-

Verhältnis positiv zu beeinflussen.

8.2 EINSATZMÖGLICHKEITEN DER METHODEN UND DEREN AUSWIRKUNGEN AUF DIE

IT-ARCHITEKTUR

Für die im Rahmen dieser Arbeit entwickelten Methoden ergeben sich während des

Entwicklungsprozesses mehrere Einsatzmöglichkeiten (siehe auch Kapitel 7.1 und Ab-

bildung 76).

So kann die Methode EcoTracing in Abhängigkeit der Tracelink-Modellierungs-

strategie während bzw. im Anschluss an die Modellierung von Artefakten (je nach-

dem, ob Zwischenstände oder finale Artefakte analysiert werden) eingesetzt werden.

Die Wahl der Modellierungsstrategie kann dabei auch Auswirkungen auf das IT-

Architekturkonzept haben (siehe Abbildung 87). Werden die Tracelinks während der

Erstellung der Artefakte durch die Entwickler modelliert, so ist die Integration auf Ebe-

ne der Autoren-Systeme sinnvoll, um die Methode direkt in der gewohnten Entwick-

lungsumgebung bereitzustellen. Ausgehend von dem jeweiligen Artefakt könnten

die Entwickler den EcoTracing-Wizard starten, ein weiteres Artefakt, welches über

den PLM-Backbone bereitgestellt wird, auswählen und mit der Verknüpfung der bei-

den Artefakte beginnen. Findet die Modellierung der Tracelinks hingegen nach Fer-

tigstellung der Artefakte bspw. durch den Traceability-Verantwortlichen oder Syste-

marchitekten statt, so kann EcoTracing auch direkt in das PLM-System integriert wer-

den (siehe Abbildung 87, PLM-Backbone).

TraceLegacy wurde hingegen als qualitätssichernde Methode konzipiert, die nicht

von allen Entwicklern, sondern dem Traceability-Verantwortlichen genutzt wird, um

fehlende Tracelinks auf Basis vergangener Projekte zu identifizieren. Damit ist eine In-

tegration der Methode in unterschiedliche Autoren-Systeme nicht notwendig, son-

dern im Tracelink-verwaltenden System ausreichend. In Abbildung 87 wird dies durch

den PLM-Backbone realisiert, der die Daten disziplinübergreifend verwaltet

. Hin-

Alternativ wäre auf gleicher Ebene eine PLM-unabhängige Umsetzung bspw. mit Hilfe des

ModelTracers (siehe Kapitel 3.6.4.3) denkbar.

Zusammenfassung und Ausblick

209

sichtlich der zeitlichen Einordnung der Einsatzmöglichkeiten ist eine Kopplung an die

Modellierung von Tracelinks (und damit an den Einsatz der Methode EcoTracing)

sinnvoll, da so direkt überprüft werden kann, ob Abhängigkeiten, die in vergangenen

Projekten bereits mit einem Tracelink bestätigt wurden, übersehen worden sind.

Grundsätzlich lässt sich die Methode jedoch zu jedem Zeitpunkt im Entwicklungspro-

zess anwenden.

Abbildung 87: Einordnung der Methoden EcoTracing, TraceEvaluation und TraceLegacy in

einem beispielhaften vierstufigen IT-Architekturkonzept (in Anlehnung an [Eig-

ner und Stelzer 2009, S. 43])

Die Methode TraceEvaluation wird im Gegensatz dazu überwiegend während der

Modellierung der Artefakte und damit in den Prozessschritten angewendet, um das

Feedback der Entwickler zu erfassen (siehe Abbildung 76). Damit muss das Anwen-

dermodul der zweiteiligen Methode auf Autoren-System-Ebene in solche Werkzeuge

integriert werden, in denen Tracelinks verwendet werden (siehe Abbildung 87). Dies

ist insbesondere bei der integrierten Funktions- und Eigenschaftsabsicherung sowie

bei der Eigenschaftsbestätigung der Fall, da bei diesen Aktivitäten die Tracelinks

verwendet werden, um aktuelle IST- mit SOLL-Parametern bspw. der Anforderungen

abzugleichen, wobei falsche Tracelinks besonders auffallen. Die Implementierung

sollte dabei vorzugsweise so umgesetzt werden, dass lediglich ein Rechtsklick auf

den entsprechenden Tracelink und eine Bestätigung zu erfolgen haben, um den

Aufwand für den Anwender so gering wie möglich zu halten. Das Auswertungsmodul,

in dem das Feedback gesammelt und bewertet wird, ist hingegen nur für die Ver-

Zusammenfassung und Ausblick

210

wendung durch den Traceability-Verantwortlichen vorgesehen. Es kann somit auf

PLM-Backbone-Ebene implementiert und zu jeder Zeit im Entwicklungsprozess genutzt

werden, um zu überprüfen, ob potenziell falsche Tracelinks gemeldet wurden.

8.3 AUSBLICK

Neben den in Kapitel 8.1 beschriebenen konkreten Weiterentwicklungsansätzen, die

verfolgt werden sollten, um eine industrielle Anwendbarkeit der Methoden zu errei-

chen, gilt es, einige grundsätzliche Forschungsaspekte zu klären, um die Verbreitung

durchgängiger Nachverfolgbarkeit zu steigern. Diese wurden insb. bei der Durchfüh-

rung der Studien und damit bei der Interaktion mit potenziellen Anwendern identifi-

ziert und werden im Folgenden kurz zusammengefasst.

Mittelfristig erscheint die vollständig automatisierte Erfassung von Tracelinks mit Hilfe

konfigurierbarer Regeln und Methoden der Informationsrückführung aus Sicht des

Autors als unmöglich. Aus diesem Grund muss die Entscheidung über die Modellie-

rung eines Tracelinks letztlich immer beim Anwender liegen, da die Vollständigkeit ei-

ner Analyse sonst nicht vorausgesetzt werden kann. Allerdings sind auch Anwender

natürlich nicht unfehlbar, weshalb sich die Traceability-Forschung u. a. auf deren Un-

terstützung fokussieren sollte.

So ist die Entscheidung, ob eine Abhängigkeit zwischen zwei Elementen besteht und

somit ein Tracelink modelliert wird, eine sehr subjektive, die von der Erfahrung des

Modellierenden, der Strukturierung der Artefakte sowie der Beschreibung der Ele-

mente abhängig und häufig nicht eindeutig ist. Die Frage ist in diesem Zusammen-

hang, wie Entwickler als Anwender unterschiedlicher Methoden zur Erfassung von

Tracelinks bei dem Treffen der einzelnen Entscheidung besser unterstützt werden

können.

Als ein Ansatz könnte bspw. die Strukturierung von Anforderungen nach funktionalen

Aspekten bei der Abhängigkeitsanalyse von Anforderungs- und Funktionsartefakten

eine große Hilfe darstellen. Die detailliertere Untersuchung unterschiedlicher Formen

der Elementbeschreibung könnte ebenfalls vielversprechend hinsichtlich einer opti-

mierten Abhängigkeitsanalyse sein, um bei den Anwendern eine klarere Vorstellung

von deren Inhalt hervorzurufen und somit die eindeutigere Ableitung von Tracelinks

zu ermöglichen. Weiter wäre es möglich, Anwendern bei der Modellierung von

Tracelinks Hintergrundinformationen zum jeweils aktuell betrachteten Elementepaar

zur Verfügung zu stellen. Auch die algorithmische Bewertung

der Wahrscheinlich-

Zur Bewertung der Wahrscheinlichkeit könnten dieselben Algorithmen, die bei der Metho-

de TraceLegacy zur Identifikation der Ähnlichkeit zweier Elemente genutzt werden (siehe

Kapitel 8.1.3), zum Einsatz kommen.

Zusammenfassung und Ausblick

211

keit, mit der eine Abhängigkeit zwischen zwei Elementen besteht, könnte bei der

Modellierung von Tracelinks hilfreich sein. In diesem Fall wäre allerdings zu untersu-

chen, ob Anwender Entscheidungen noch selber treffen oder ob sie immer der au-

tomatischen Bewertung Glauben schenken.

Auch die Einführung eines Konfidenzniveaus für Tracelinks sollte zukünftig näher be-

trachtet werden. Mit diesem Niveau könnten bei der Erfassung von Tracelinks Unsi-

cherheiten bzgl. der Existenz eines Tracelinks ausgedrückt werden, was den Erfas-

sungsprozess für den Anwender vereinfacht, da keine schwarz/weiß-Entscheidungen

mehr getroffen werden müssen. Tracelinks mit einem hohen Konfidenzniveau wären

demnach eindeutig vorhanden. Bei Tracelinks mit einem geringen Konfidenzniveau

wäre die Abhängigkeit zweier Elemente als weniger eindeutig einzuschätzen, was

sowohl bei deren Verwendung (bspw. bei Auswirkungsanalysen) als auch bei der

Pflege des Tracelink-Modells Berücksichtigung finden könnte. So könnten Tracelinks

mit einem geringen Konfidenzniveau bspw. öfter oder durch mehr Anwender hin-

sichtlich ihrer Korrektheit bewertet werden. Interessant wäre es in diesem Zusammen-

hang zu untersuchen welche Auswirkungen die Einführung dieses Konfidenzniveaus

auf die modellierenden Anwender hätte. So wäre es denkbar, dass Anwender sehr

häufig ein niedriges Niveau wählen, um keine eindeutigen, auf sie zurückführbaren

Entscheidungen mehr treffen zu müssen.

Langfristig sollte jedoch bei der Erfassung von Tracelinks und der Pflege von Tracelink-

Modellen eine möglichst hohe (wenn nicht vollständige) Automatisierung anvisiert

werden, um die manuellen Aufwände auf ein Minimum zu reduzieren und somit eine

weite Verbreitung der durchgängigen Nachverfolgbarkeit zu erreichen.

213

LITERATURVERZEICHNIS

ABMA, B. J. M. (2009): Evaluation of requirements management tools with support

for traceability-based change impact analysis. Master Thesis, University of

Twente.

AIZENBUD-RESHEF, N.; NOLAN, B. T.; RUBIN, J. UND SHAHAM-GAFNI, Y. (2006): Model

traceability. In: IBM Systems Journal 45 (3), S. 515-526.

ALLEN, T.F. (2011): A Summary of the Principles of Hierarchy Theory.

http://www.isss.org/hierarchy.htm. Zuletzt geprüft am 17. April 2011.

ALMEFELT, L.; BERGLUND, F.; NILSSON, P. UND MALMQVIST, J. (2006): Reqirements man-

agement in practice: findings from an empirical study in the automotive indus-

try. In: Research in Engineering Design, S. 113-134.

ALTHEIDE, F.; DÖRR, H. UND SCHÜRR, A. (2002): Requirements to a Framework for Sus-

tainable Integration of System Development Tools. In: Proceedings of the 3rd

European Systems Engineering Conference (EuSEC'02), H. STOEWER UND L.

GARNIER (Hrsg.), Toulouse, Frankreich, S. 53-57.

Amazon.com (2013): Amazon Mechanical Turk. Artificial Artificial Intelligence.

https://www.mturk.com/mturk/welcome. Zuletzt geprüft am 13. Februar 2013.

AMIN, A.; SAID AL-DAHABI, M.; FRIEDRICH, F. UND THIELE, J. (2012): Virtual Engineering in

Industry: Development of a Mechatronic Side Miror. Projekt Report, Technische

Universität Berlin.

ANTONIOL, G.; CANFORA, G.; LUCIA, A. DE UND CASAZZA, G. (2000): Information Re-

trieval Models for Recovering Traceability Links between Code and Documen-

tation. In: Proceedings of the International Conference on Software Mainte-

nance (ICSM 2000), L. BRIAND (Hrsg.). San Jose, Kalifornien, USA, 11 - 14 Oktober,

S. 40-49.

ARKLEY, P. UND RIDDLE, S. (2005): Overcoming the traceability benefit problem. In:

Proceedings of the 13th IEEE International Conference on Requirements Engi-

neering. Paris, Frankreich, 29. August - 2. September, S. 385-389.

BALLUCHI, A.; FERRARI, A.; SANGIOVANNI-VINCENTELLI, A.; FLORA, R.; GAVIANI, G.; NESCI, W.

UND SERRA, G. (2002): Functional And Architectural Specification For Power-Train

Control System Design. In: Proceedings of the 2nd IFAC Conference on Mecha-

tronic Systems. Berkeley, Kalifornien, USA, 9.-11. Dezember, S. 319-324.

BEIER, G.; FIGGE, A.; LEHNER, T. UND METIN, A. (2011): Durchgängige Nachverfolgbar-

keit in der Systementwicklung. Datendurchgängigkeit für die Entwicklung von

Fahrzeugfunktionen. In: ZwF Zeitschrift für wirtschaftlichen Fabrikbetrieb 106 (6),

S. 462-465.

BEIER, G.; FIGGE, A.; MÜLLER, R.; ROTHENBURG, U. UND STARK, R. (2013): Supporting Prod-

uct Development through Cross-Discipline Dependency-Modeling – Novel Ap-

proaches for Traceability-Usage. In: Lecture Notes on Information Theory (LNIT)

1 (1), S. 21-28.

BEIER, G.; ROTHENBURG, U.; WOLL, R. UND STARK, R. (2012): Durchgängige Entwicklung

mit erlebbaren Prototypen. Modellbasiertes Systems Engineering. In: Digital En-

gineering 11 (3).

BIANCHI, A.; FASOLINO, A. R. UND VISAGGIO, G. (2000): An Exploratory Case Study of

the Maintenance Effectiveness of Traceability Models. In: Proceedings of the

Literaturverzeichnis

214

8th International Workshop on Program Comprehension (IWPC 2000). Limerick,

Irland, 10. - 11. Juni, S. 149-158.

BIEDERMANN, W.; KREIMEYER, M. UND LINDEMANN, U. (2009): Measurement System to

Improve Data Acquisition Workshops. In: Proceedings of the 11th International

DSM Conference (DSM'09). Greenville, South Carolina, USA, 12.-13. Oktober,

S. 119-130.

BIEDERMANN, W.; STRELKOW, B.; KARL, F.; LINDEMANN, U. UND ZAEH, M. F. (2010): Reducing

Data Acquisition Effort by Hierarchical System Modelling. In: Proceedings of the

12th International DSM Conference – Managing Complexity by Modelling De-

pendencies, D. WYNN; M. KREIMEYER; K. EBEN; M. MAURER; U. LINDEMANN UND P.

CLARKSON (Hrsg.). Cambridge, UK, 22.-23. Juli, S. 309-318.

BLESSING, L.T.M. UND CHAKRABARTI, A. (2009): DRM, a Design Research Methodology.

Springer-Verlag, London.

BORNAT, P. UND MSADEK, N. (2011): Variant Modeling Approach of Automotive Elec-

tric/Electronic (E/E) Architectures and Bridge to AUTOSAR infrastructure. In: Pro-

ceedings of Complex Systems Design & Management (CSD&M). Paris, Frank-

reich, 7.-9. Dezember.

BORNATH, M. (2011a): Untersuchung und prototypische Implementierung einer Me-

thode zur effizienten Modellierung von Abhängigkeiten zwischen Partialmodel-

len. Studienarbeit, Technische Universität Berlin.

BORNATH, M. (2011b): Untersuchung und prototypische Implementierung unter-

schiedlicher Methoden zur Pflege des Verknüpfungsmodells zwischen Partial-

modellen. Diplomarbeit, Technische Universität Berlin.

British Standards Institution (2008). ISO 12207:2008: Systems and software engi-

neering. ISO/IEC-IEEE, Geneva.

CERBAH, F. UND EUZENAT, J. (2001): Traceability between models and texts through

terminology. In: Data & Knowledge Engineering 38 (1), S. 31-43.

CHAKRABARTI, A. UND BLIGH, T. P. (2001): A scheme for functional reasoning in con-

ceptual design. In: Design Studies 22 (6), S. 493-517.

CLELAND-HUANG, J.; CHANG, C. UND CHRISTENSEN, M. (2003): Event-based traceability

for managing evolutionary change. In: IEEE Transactions on Software Enginee-

ring 29 (9), S. 796-810.

CONRAD, M.; FEY, I.; GROCHTMANN, M. UND KLEIN, T. (2005): Modellbasierte Entwick-

lung eingebetteter Fahrzeugsoftware bei DaimlerChrysler. In: Informatik - For-

schung und Entwicklung 20 (1-2) (2005), S. 3-10.

CORNEY, J. R.; TORRES-SÁNCHEZ, C. UND JAGADEESAN, A. P. (2010): Outsourcing labour

to the cloud. In: International Journal of Innovation and Sustainable Develop-

ment S. 294-313.

DANNENBERG, J. UND BURGARD, J. (2007): 2015 car innovation. Innovationsmanage-

ment in der Automobilindustrie. Oliver Wyman.

Dassault Systèmes (2013): 3D Design & Engineering Best in Class Software Prod-

ucts. CAD, Modeling, Finite Element Simulation and more: From Designer to

Consumer, Creating Brand User Experiences. http://www.3ds.com/products/.

Zuletzt geprüft am 17. Februar 2013.

Department of Defense (1994). Military Standard MIL-STD-498: Software Develop-

ment and Documentation.

Literaturverzeichnis

215

Department of Defense (2001): Systems Engineering Fundamentals. Defense Ac-

quisition University Press, Fort Belvoir, Virginia.

DIN Deutsches Institut für Normung e. V. (2005). DIN EN ISO 9000: Qualitätsmana-

gementsysteme - Grundlagen und Begriffe. Beuth Verlag GmbH.

DIN Deutsches Institut für Normung e. V. (2006). ISO/IEC 15504-5: Informations-

technik - Prozess-Assessment - Teil 5: Beispiel für ein Prozess-Assessmentmodell.

Beuth Verlag GmbH.

DIN Deutsches Institut für Normung e. V. (2013). DIN EN 9115: Qualitätsmanage-

mentsysteme - Anforderungen an Organisationen der Luftfahrt, Raumfahrt und

Verteidigung - Mitgelieferte Software. Beuth Verlag GmbH.

DIRSCH-WEIGAND, A.; SCHMIDT, I.; REIN, B.; STENZEL, R. UND KAMPS, T. (2006): ConWeaver

- Automatisierte Wissensnetze für die semantische Suche. In: Proceedings der

28. Online-Tagung der DGI und 58. Jahrestagung der DGI, M. OCKENFELD (Hrsg.).

Frankfurt am Main, 4.-6. Oktober.

DOAN, A.; RAMAKRISHNAN, R. UND HALEVY, A. Y. (2011): Crowdsourcing systems on the

World-Wide Web. In: Communications of the ACM 54 (4), S. 86-96.

DÖMGES, R. UND POHL, K. (1998): Adapting traceability environments to project-

specific needs. In: Communications of the ACM 41 (12) (1998), S. 54-62.

DROGIES, S. (2006): Objektorientierte Modellbildung des fahrdynamischen Verhal-

tens mit MODELICA. In: Fahrdynamik-Regelung, R. ISERMANN (Hrsg.). Vieweg,

Wiesbaden, S. 71-91.

DUBBEL, H., BEITZ, W. UND GROTE, K.-H. (2011): Dubbel. Taschenbuch für den Maschi-

nenbau. Springer-Verlag, Berlin.

EBEN, K.; DANIILIDIS, C. UND LINDEMANN, U. (2010): Interrelating and Prioritising Re-

quirements on multiple Hierarchy Levels. In: Proceedings of International Design

Conference - Design 2010. Dubrovnik, Kroatien, 17.-20. Mai, S. 1055-1064.

EDWARDS, M. UND HOWELL, S. (1992): A Methodology for Requirements Specification

and Traceability for Large Real-Time Complex Systems. Naval Surface Warfare

Center.

EGYED, A. (2000): Heterogeneous view integration and its automation. Disserta-

tion, University of Southern California.

EGYED, A. (2003): A scenario-driven approach to trace dependency analysis. In:

IEEE Transactions on Software Engineering 29 (2), S. 116-132.

EGYED, A. UND GRÜNBACHER, P. (2002): Automating Requirements Traceability: Be-

yond the Record & Replay Paradigm. In: Proceedings of the 17th IEEE Interna-

tional Conference on Automated Software Engineering (ASE). Edinburg, Schott-

land, 23.-27. September, S. 163-171.

EGYED, A.; GRÜNBACHER, P.; Heindlm M. und BIFFL, S. (2009): Value-Based Require-

ments Traceability: Lessons Learned. In: Design Requirements Engineering: A

Ten-Year Perspective, K. LYYTINEN; P. LOUCOPOULOS; J. MYLOPOULOS UND B. ROBINSON

(Hrsg.). Springer-Verlag, Berlin, S. 240-257.

EHRLENSPIEL, K. (2007): Integrierte Produktentwicklung. Denkabläufe, Methodenein-

satz, Zusammenarbeit. Carl Hanser Verlag, München.

EIGNER, M. UND STELZER, R. (2009): Product Lifecycle Management. Ein Leitfaden für

Product Development und Life Cycle Management. Springer-Verlag, Berlin,

Heidelberg.

Literaturverzeichnis

216

ERDEN, M. S.; KOMOTO, H.; VAN BEEK, T. J.; D'AMELIO, V.; ECHAVARRIA, E. UND TOMIYAMA, T.

(2008): A review of function modeling: Approaches and applications. In: Artifi-

cial Intelligence for Engineering Design, Analysis and Manufacturing 22 (02),

S. 147-169.

ESTELLES-AROLAS, E. UND GONZALEZ-LADRON-DE-GUEVARA, F. (2012): Towards an inte-

grated crowdsourcing definition. In: Journal of Information Science 38 (2),

S. 189-200.

FEI, G.; GAO, J.; OWODUNNI, O. UND TANG, X. (2011): A method for engineering de-

sign change analysis using system modelling and knowledge management

techniques. In: International Journal of Computer Integrated Manufacturing 6

(24), S. 535-551.

FELLNER, D. W.; KAMPS, T.; KOHLHAMMER, J. UND STRICKER, A. (2008): Vorsprung durch

Wissen. In: ZwF Zeitschrift für wirtschaftlichen Fabrikbetrieb 103 (4), S. 205-208.

FIELITZ, S., OSTERLINK, M., GÖZE, D., KAWANO, K., KIM, S., LENGERT, D., VINOT, M., ELSNER, M.

UND KONTAR, S. (2013): Product Life Cycle and Systems Engineering. Pedelec

Team 2 - MobSys VEI12/13. http://prezi.com/f8diw0st8-qa/product-life-cycle-

and-systems-engineering/?auth_key=a13457a2737e1f05b99460045

a07a8f5c04cf645. Zuletzt geprüft am 4. Februar 2013.

Geensoft (2010): Reqtify. http://www.geensoft.com/en/article/reqtify. Zuletzt

geprüft am 5. März 2012.

GEIGER, D.; SCHULZE, T.; SEEDORF, S.; NICKERSON, R. UND SCHADER, M. (2011): Managing

the Crowd: Towards a Taxonomy of Crowdsourcing Processes. In: Proceedings

of the 17th Americas Conference on Information Systems. Detroit, Michigan,

USA, 4.-7. August.

GOTEL, O. UND FINKELSTEIN, A. (1994): An Analysis of the Requirements Traceability

Problem. In: 1st International Conference on Rquirements Engineering. Colora-

do Springs, CO, U.S.A, S. 94-101.

GOTEL, O. UND FINKELSTEIN, A. (1996): Revisiting requirements production. In: Soft-

ware Engineering Journal 11 (3), S. 166-182.

GROBSTEIN, C. (1973): Hierarchical Order and Neogenesis. In: Hierarchy Theory. The

challenge of complex systems, H. H. PATTEE (Hrsg.). G. Braziller, New York, S. 31-

47.

HASKINS, C. (2006): Systems Engineering Handbook. A guide for system life cycle

processes and activities. INCOSE - International Council on Systems Engineer-

ing.

HAYES, J.; DEKHTYAR, A. UND SUNDARAM, S. (2006): Advancing candidate link genera-

tion for requirements tracing: the study of methods. In: IEEE Transactions on

Software Engineering 32 (1), S. 4-19.

HOOD, C. UND WIEBEL, R. (2005): Optimieren von Requirements Management & En-

gineering. Mit dem HOOD Capability Model. Springer-Verlag, Berlin, New York.

HORSTKÖTTER, J.; METZ, P.; NTIMA, A. UND SEIM, W. (2010): Funktionale Sicherheit und

ISO 26262 - Entmystifiziert. SynSpace und Fleckner & Simon.

http://www.synspace.com/view-document-details/60-funktionale-sicherheit-

und-iso-26262-entmystifiziert.html. Zuletzt geprüft am 07. März 2012.

HYBERTSON, D.W. (2009): Model-oriented systems engineering science. A unifying

framework for traditional and complex systems. Complex and enterprise sys-

tems engineering. CRC Press, Boca Raton.

Literaturverzeichnis

217

IBM Corporation (2008): The Telelogic DOORS application. Requirements man-

agement for complex systems and software.

ID-Systems GmbH (2013): METUS - The System Design Method. http://www.id-

consult.com/fileadmin/user_upload/PDFs/IDS_METUS_Raute_neu_090405.pdf.

Zuletzt geprüft am 22. April 2013.

IEEE Standards Board (1990) IEEE 610.12-1990: IEEE standard glossary of software

engineering terminology. Institute of Electrical and Electronics Engineers, New

York, N.Y., USA.

IEEE-SA Standards Board (1998). IEEE 1219: IEEE standard for software mainte-

nance. Institute of Electrical and Electronics Engineers, New York, N.Y., USA.

International Organization for Standardization (2011). ISO 26262-1: Road vehicles -

Functional Safety - Part 1: Vocabulary.

International Organization for Standardization (2011). ISO 26262-2: Road vehicles -

Functional Safety - Part 2: Management of functional safety.

International Organization for Standardization (2011). ISO 26262-3: Road vehicles -

Functional Safety - Part 3: Concept phase.

International Organization for Standardization (2011). ISO 26262-4: Road vehicles -

Functional Safety - Part 4: Product development at the system level.

International Organization for Standardization (2011). ISO 26262-5: Road vehicles -

Functional Safety - Part 5: Product development at the hardware level.

International Organization for Standardization (2011). ISO 26262-6: Road vehicles -

Functional Safety - Part 6: Product development at the software level.

International Organization for Standardization (2011). ISO 26262-7: Road vehicles -

Functional Safety - Part 7: Production and operation.

International Organization for Standardization (2011). ISO 26262-8: Road vehicles -

Functional Safety - Part 8: Supporting processes.

International Organization for Standardization (2011). ISO 26262-9: Road vehicles -

Functional Safety - Part 9: Automotive Safety Integrity Level (ASIL)-oriented and

safety-oriented analyses.

JANSCHEK, K. (2010): Systementwurf mechatronischer Systeme. Methoden, Model-

le, Konzepte. Springer-Verlag, Berlin, Heidelberg.

JONES, G. J. F. (2013): An Introduction to Crowdsourcing for Language and Multi-

media Technology Research. In: Information Retrieval Meets Information Visua-

lization, D. HUTCHISON; T. KANADE; J. KITTLER; J. M. KLEINBERG; F. MATTERN; J. C.

MITCHELL; M. NAOR; O. NIERSTRASZ; C. PANDU RANGAN; B. STEFFEN; M. SUDAN; D.

TERZOPOULOS; D. TYGAR; M. Y. VARDI; G. WEIKUM; M. AGOSTI; N. FERRO; P. FORNER; H.

MÜLLER UND G. SANTUCCI (Hrsg.). Springer-Verlag, Berlin, Heidelberg, S. 132-154.

KAINDL, H.; KRAMER, S. UND DIALLO, P. S. N. (1999): Semiautomatic generation of

glossary links: a practical solution. In: Proceedings of the 10th ACM Conference

on Hypertext and Hypermedia: Returning to our Diverse Roots. Darmstadt,

Deutschland, 21.-25. Februar, S. 3-12.

KÖNIGS, S. (2012): Konzeption und Realisierung einer Methode zur templatege-

stützten Systementwicklung. Dissertation, Technische Universität Berlin.

KÖNIGS, S. F.; BEIER, G.; FIGGE, A. UND STARK, R. (2012): Traceability in Systems Engine-

ering. Review of industrial practices, state-of-the-art technologies and new re-

search solutions. In: Advanced Engineering Informatics 26 (4), S. 924-940.

Literaturverzeichnis

218

KOTONYA, G. UND SOMMERVILLE, I. (1998): Requirements engineering. Processes and

techniques. Worldwide series in computer science. Wiley, Chichester.

KROLL, E. (2012): Design theory and conceptual design: contrasting functional

decomposition and morphology with parameter analysis. In: Research in Engi-

neering Design 24 (2), S. 165-183.

LAGO, P.; MUCCINI, H. UND VAN VLIET, H. (2009): A scoped approach to traceability

management. In: Journal of Systems and Software 82 (1), S. 168-182.

Lancaster University - Centre for Computer Corpus Research on Language (2013):

CLAWS part-of-speech tagger for English. http://ucrel.lancs.ac.uk/claws/. Zu-

letzt geprüft am 25. Januar 2013.

LANE, D. (2006): Hierarchy, Complexity, Society. In: Hierarchy in Natural and Social

Sciences, D. PUMAIN (Hrsg.). Springer-Verlag, Berlin, Heidelberg, S. 81-119.

LEEMHUIS, H. (2005): Funktionsgetriebene Konstruktion als Grundlage verbesserter

Produktentwicklung. Dissertation, Technische Universität Berlin.

LEENDERS, R. T. A. J.; VAN ENGELEN, J. M. L. UND KRATZER, J. (2007): Systematic Design

Methods and the Creative Performance of New Product Teams: Do They Con-

tradict or Complement Each Other? In: Journal of Product Innovation Man-

agement 24 (2), S. 166-179.

LINDEMANN, U., MAURER, M. UND BRAUN, T. (2009): Structural complexity manage-

ment. An approach for the field of product design. Springer-Verlag, Berlin.

Linux.org (2013). http://www.linux.org/. Zuletzt geprüft am 13. Februar 2013.

LUCIA, A. DE; FASANO, F.; OLIVETO, R. UND TORTORA, G. (2007): Recovering traceability

links in software artifact management systems using information retrieval meth-

ods. In: ACM Transactions on Software Engineering and Methodology 16 (4)

(2007), S. 13:1–13:50.

MÄDER, P.; GOTEL, O. UND PHILIPPOW, I. (2008): Enabling automated traceability

maintenance by recognizing development activities applied to models. In:

Proceedings on 23rd International Conference on Automated Software Engi-

neering (ASE2008). L’Aquila, Italien, 17.-19. September.

MÄDER, P.; GOTEL, O. UND PHILIPPOW, I. (2009a): Getting Back to Basics: Promoting

the Use of a Traceability Information Model in Practice. In: Proceedings of the

5th International Workshop on Traceability in Emerging Forms of Software Engi-

neering (TEFSE2009). Vancouver, Canada, 18. Mai.

MÄDER, P.; GOTEL, O. UND PHILIPPOW, I. (2009b): Motivation Matters in the Traceability

Trenches. In: Proceedings of the 17th International Requirements Engineering

Conference (RE’09). Atlanta, Georgia, USA, 31. August - 4. September.

MÄDER, P.; GOTEL, O. UND PHILIPPOW, I. (2009c): traceMAINTAINER: A Tool for the Se-

mi-automated Maintenance of Model Traceability. In: Proceedings of the 5th

ECMDA Traceability Workshop (ECMDA-TW 2009). Enschede, Netherlands, 23.

Juni, S. 7-16.

MANNING, C.D., RAGHAVAN, P. UND SCHUTZE, H. (2009): An Introduction to Information

Retrieval. Cambridge University Press, Cambridge, England.

MAURER, M.S. (2007): Structural awareness in complex product design. Verlag Dr.

Hut, München.

Modelica Association (2012): Modelica - A Unified Object-Oriented Language for

Systems Modeling. Language Specification. Version 3.3.

Literaturverzeichnis

219

Modelica Association (2013): Modelica Tools. https://www.modelica.org/tools.

Zuletzt geprüft am 22. April 2013.

MÜLLER, P.; PASCH, F.; DREWINSKI, R. UND HAYKA, H. (2013): Kollaborative Produktent-

wicklung und digitale Werkzeuge. Defizite heute - Potenziale morgen. Fraun-

hofer Institut für Produktionsanlagen und Konstruktionstechnik, Berlin.

NASA STI (2007): Systems engineering handbook. National Aeronautics and

Space Administration, Washington, DC, USA.

NEJMEH, B.; DICKEY, T. UND WARTIK, S. (1989): Traceability Technology at the Software

Productivity Consortium. In: Proceedings of the 11th IFIP Congress, 28. August -

1. September, S. 981-984.

OTTER, M. (2011): Modelica Overview.

https://modelica.org/education/educational-material/lecture-

material/english/ModelicaOverview.pdf/view. Zuletzt geprüft am 1. August

2013.

PAHL, G., BEITZ, W., FELDHUSEN, J. UND GROTE, K.-H. (2007): Konstruktionslehre. Grund-

lagen erfolgreicher Produktentwicklung Methoden und Anwendung. Springer-

Verlag, New York, Berlin, Heidelberg.

PAIGE, R.; OLSEN, G. K.; KOLOVOS, D.; ZSCHALER, S. UND POWER, C. (2008): Building

model-driven engineering traceability classifications. In: Proceedings of the

ECMDA Traceability Workshop (ECMDA-TW) 2008, J. OLDEVIK; K. GØRAN; T. NEPLE;

R. PAIGE UND J. OLDEVIK (Hrsg.). Berlin, Deutschland, 12. Juni, S. 49-58.

PALMER, J. D. (2000): Traceability. In: Software requirements engineering, R. H.

THAYER; M. DUNCAN UND A. M. DAVIS (Hrsg.). IEEE Computer Society Press, Los

Alamitos, S. 412-422.

PFEIFER, M.; SEILER, S.; BÖTTJER, T. UND LIEBERUM, M. (2012): Virtual Engineering in Indus-

try: Development of a Mechatronic Side Miror. Projekt Report, Technische Uni-

versität Berlin.

PFLEEGER, S. UND BOHNER, S. (1990): A framework for software maintenance metrics.

In: Proceedings of the Conference on Software Maintenance. IEEE Computer

Society Press, Washington, DC, S. 320-327.

PIERCE, R. A. (1978): A Requirements Tracing Tool. In: ACM SIGMETRICS Perfor-

mance Evaluation Review 7 (3-4), S. 53-60.

PINHEIRO, F. A. C. (2003): Requirements Traceability. In: Perspectives on software

requirements, J. C. SAMPAIO DO PRADO LEITE UND J. H. DOORN (Hrsg.). Kluwer

Academic Publishers, Boston, S. 91-113.

PLETTE, A. (2009): Ganzheitliches Lastenheftmanagement. IBM Rational Roadshow.

2009.

POHL, M. UND SCHEEL, C. (2004): Toolvorstellung Reqtify. Technische Universität Ber-

lin. http://swt.cs.tu-berlin.de/lehre/eks/ws0304/SlidesPaper/ausarbeitung

%20reqtify.pdf. Zuletzt geprüft am 5. März 2012.

PONN, J. UND LINDEMANN, U. (2008): Konzeptentwicklung und Gestaltung techni-

scher Produkte. Optimierte Produkte - systematisch von Anforderungen zu Kon-

zepten. Springer-Verlag, Berlin, Heidelberg.

PORTER, M. (2006): An algorithm for suffix stripping. In: Program: electronic library

and information systems 40 (3), S. 211-218.

PORTER, M. (2013a): German stemming algorithm. http://snowball.tartarus.org

/algorithms/german/stemmer.html. Zuletzt geprüft am 2. Februar 2013.

Literaturverzeichnis

220

PORTER, M. (2013b): Snowball. http://snowball.tartarus.org/index.php. Zuletzt ge-

prüft am 2. Februar 2013.

PROBST, G.J.B. UND ULRICH, H. (1988): Anleitung zum ganzheitlichen Denken und

Handeln. Ein Brevier für Führungskräfte. Haupt Verlag, Bern, Stuttgart.

PUMAIN, D., Ed. (2006): Hierarchy in Natural and Social Sciences. Springer-Verlag,

Berlin, Heidelberg.

RAIA, F. (2005): Students' Understanding of Complex Dynamic Systems. In: Journal

of Geoscience Education, S. 297-308.

RAMESH, B. UND EDWARDS, M. (1993): Issues in the development of a requirements

traceability model. In: Proceedings on the IEEE International Symposium on Re-

quirements Engineering (RE '93). San Diego, CA USA, 4.-6. Januar, S. 256-259.

RAMESH, B. UND JARKE, M. (2001): Toward reference Models for Requirements

Traceability. In: IEEE Transactions on Software Engineering 27 S. 1-54.

RAMESH, B.; STUBBS, C.; POWERS, T. UND EDWARDS, M. (1997): Requirements traceability:

Theory and practice. In: Annals of Software Engineering. Kluwer Academic

Publishers, S. 397-415.

ROSENAUER, G. B. (2008): A Standards-Based Approach to Dynamic Tool Integrati-

on Using Java Business Integration. A Redesign of the ToolNet Framework built

on Entrerprise Integration Standards. Diplomarbeit, ISIS Vienna Universitity of

Technology.

ROUSE, A. (2010): A preliminary taxonomy of crowdsourcing. In: Proceedings of the

21st Australasian Conference on Information Systems (ACIS 2010). Brisbane,

Australia, 1.-3. Dezember, S. 76-87.

SCHÖNSLEBEN, P. (2007): Integrales Logistikmanagement. Operations and Supply

Chain Management in umfassenden Wertschöpfungsnetzwerken. Springer-

Verlag, Berlin.

SCHUH, G.; LENDERS, M.; NUßBAUM, C. UND RUDOLF, S. (2012): Produktarchitekturgestal-

tung. In: Handbuch Produktion und Management 3. Innovationsmanagement,

G. SCHUH (Hrsg.). Springer-Verlag, Berlin, S. 115-160.

Siemens PLM Software (2010): Mechatronics Concept Designer. Ein funktionsori-

entierter Ansatz für den Maschinen- und Anlagenbau.

www.siemens.de/plm/mcd. Zuletzt geprüft am 17. Februar 2013.

Siemens PLM Software (2011): White Paper: Managing the development of com-

plex automotive products through a systems-driven process.

http://m.plm.automation.siemens.com/en_us/Images/Siemens-PLM-Systems-

Driven-Product-Development-wp_tcm1224-121850.pdf. Zuletzt geprüft am 27.

August 2013.

SIMON, H. A. (1973): The Organization of Complex Systems. In: Hierarchy Theory.

The challenge of complex systems, H. H. PATTEE (Hrsg.). G. Braziller, New York,

S. 3-27.

SPANOUDAKIS, G.; ZISMAN, A.; PEREZ-MINANA, E. UND KRAUSE, P. (2004): Rule-based ge-

neration of requirements traceability relations. In: The Journal of Systems and

Software 72 S. 105-127.

STARK, R. (2011): Challenges in modern Product Creation Processes. PEP2015.

Technical Steering Committee. 29. Juni 2011, Darmstadt.

STARK, R.; BEIER, G.; FIGGE, A. UND WÖHLER, T. (2010): Cross-Domain Dependency

Modelling - How to achieve consistent System Models with Tool Support. In:

Literaturverzeichnis

221

Proceedings EuSEC 2010 - European Systems Engineering Conference. Stock-

holm, Sweden, 23.-26. Mai.

STARK, R. UND FIGGE, A. (2011): Eco Tracing - A Systems Engineering Method for Effi-

cient Tracelink Modelling. In: Proceedings of the 18th International Conference

on Engineering Design (ICED11), Vol. 4. Product and Systems Design, S. J.

CULLEY; B. J. HICKS; T. C. MCALOONE; T. J. HOWARD UND U. LINDEMANN (Hrsg.). Kopen-

hagen, Dänemark, S. 21-32.

SUGDEN, R. UND STRENS, M. (1996): Strategies, tactics and methods for handling

change. In: Proceedings: IEEE Symposium and Workshop on Engineering of

Computer-Based Systems. Friedrichshafen, Germany, 11.-15. März, S. 457-463.

SUTINEN, K.; ALMEFELT, L. UND MALMQVIST, J. (2000): Implementation of requirements

traceability in systems engineering tools. In: Proceedings of the Product Models

Conference. Linköping, Schweden, 7.-8. November, S. 313-330.

SUTINEN, K.; ALMEFELT, L. UND MALMQVIST, J. (2002): Supporting Concept Development

Using Quantitative Requirements Traceability. In: Proceedings of the 12th An-

nual International Symposium INCOSE 2002. Las Vegas, Nevada, USA, 28. Juli -

1. August.

SUTINEN, K.; GUSTAFSSON, G. UND MALMQVIST, J. (2004): Computer Support for Requi-

rements Management in an international Product Development Project. In:

Proceedings of the ASME 2004 Design Engineering and Technical Conferences

and Computers and Information in Engineering Conference (DETC’04). Salt La-

ke City, Utah, USA, 28. September - 2. Oktober.

Teseon GmbH: LOOMEO complexity software. http://teseon.de/loomeo. Zuletzt

geprüft am 18. August 2012.

Teseon GmbH (2012): LOOMEO Highlights. http://teseon.de/component/ pho-

cadownload/category/2-loomeo-public?download=6:loomeo-highlights-de.

Zuletzt geprüft am 18. August 2012.

TILSTRA, A. H.; SEEPERSAD, C. C. UND WOOD, K. (2009): Distributed Modeling of Com-

ponent DSM. In: Proceedings of the 11th International DSM Conference

(DSM'09). Greenville, South Carolina, USA, 12.-13. Oktober, S. 243-258.

TOMIZUKA, M. (2002): Mechatronics: from the 20th to 21st century. In: Control Engi-

neering Practice 10 (8), S. 877-886.

TRETOW, G.; GÖPFERT, J. UND HEESE, C. (2008): In sieben Schritten systematisch entwi-

ckeln. In: CAD-CAM Report (8), S. 36-39.

TUDORACHE, T. (2006): Employing Ontologies for an Improved Development Pro-

cess in Collaborative Engineering. Dissertation, Technische Universität Berlin.

UMEDA, Y. UND TOMIYAMA, T. (1995): FBS modeling: modeling scheme of function for

conceptual design. In: Proceedings of the 9th International Workshop on Quali-

tative Reasoning. Amsterdam, Niederlande, 16.-19. Mai, S. 271-278.

VAJNA, S. (2009): CAx für Ingenieure. Eine praxisbezogene Einführung. Springer-

Verlag, Berlin, Heidelberg.

VAN BEEK, T. J. UND TOMIYAMA, T. (2008): Requirements for Complex Systems Mode-

ling. In: Proceedings of the CIRP Design Conference: Design Synthesis. Ensche-

de, Niederlande, 7.-9. April.

VAN DEN HAMER, P. UND LEPOETER, K. (1996): Managing design data: the five dimensi-

ons of CAD frameworks, configuration management, and product data ma-

nagement. In: Proceedings of the IEEE 84 (1), S. 42-56.

Literaturverzeichnis

222

VAN GORP, P.; ALTHEIDE, F. UND JANSSENS, D. (2006): Traceability and Fine-Grained

Constraints in Interactive Inconsistency Management. In: Second ECMDA

Traceability Workshop (ECMDA-TR 2006), T. NEPLE; J. OLDEVIK UND J. AAGEDAL

(Hrsg.). Bilbao, Spanien, 10. Juli.

Verein Deutscher Ingenieure (2004). VDI-Richtlinie 2206: Entwicklungsmethodik für

mechatronische Systeme. Beuth Verlag GmbH, Berlin.

Verein Deutscher Ingenieure (2012). VDI 2219: Informationsverarbeitung in der

Produktentwicklung - Einführung und Wirtschaftlichkeit von EDM/PDM-

Systemen. Beuth Verlag GmbH, Berlin.

VERMAAS, P. E. (2009): The flexible Meaning of Function in Engineering. In: Procee-

dings of the 17th International Conference on Engineering Design (ICED'09),

Vol. 2, M. NORELL BERGENDAHL; M. GRIMHEDEN; L. LEIFER; P. SKOGSTAD UND U.

LINDEMANN (Hrsg.). Standford University, California, USA, 24.-27. August, S. 113-

124.

WEBER, C.; FRANKE, H.-J. UND STELZER, R. (2007): Wissensmanagement. In: Innovati-

onspotenziale in der Produktentwicklung, F.-L. KRAUSE; H.-J. FRANKE UND J.

GAUSEMEIER (Hrsg.). Carl Hanser Verlag, München, Wien, S. 141-149.

WEBER, J. (2009): Automotive development processes. Processes for successful

customer oriented vehicle development. Springer-Verlag, Dordrecht, New York.

WEILKIENS, T. (2006): Systems engineering mit SysML/UML. Modellierung, Analyse,

Design. Dpunkt-Verlag, Heidelberg.

WIERINGA, R. (1995): An introduction to requirements traceability. Technical Report

IR-389. Faculty of Mathematics and Computer Science, University of Vrije, Ams-

terdam.

Wikimedia Foundation Inc (2013): Wikipedia. The Free Encyclopedia.

http://en.wikipedia.org/. Zuletzt geprüft am 13. Februar 2013.

WINKLER, S. UND PILGRIM, J. (2010): A survey of traceability in requirements enginee-

ring and model-driven development. In: Software & Systems Modeling 9 (4),

S. 529-565.

WINTER, R. (2003): Modelle, Techniken und Werkzeuge im Business Engineering. In:

Business engineering. Auf dem Weg zum Unternehmen des Informationszeital-

ters, H. ÖSTERLE (Hrsg.). Springer-Verlag, Berlin [u.a.], S. 87-118.

WRASSE, K. R. (2011): Modellübergreifende Abhängigkeiten in der Entwicklung

mechatronischer Systeme. Erarbeitung und Aufbereitung eines industrienahen

Modells zu Evaluationszwecken. Studienarbeit, Technische Universität Berlin.

Yahoo! Inc. (2013): Yahoo! Answers. http://answers.yahoo.com/. Zuletzt geprüft

am 13. Februar 2013.

YEH, R. UND ZAVE, P. (1980): Specifying software requirements. In: Proceedings of

the IEEE 68 (9), S. 1077-1085.

ZISMAN, A.; SPANOUDAKIS, G.; PÉREZ-MIÑANA, E. UND KRAUSE, P. (2003): Tracing Software

Requirements Artefacts. In: Proceedings of the 2003 International Conference

on Software Engineering Research and Practice (SERP'03). Las Vegas, USA, 23.-

26. Juni, S. 448-455.

223

GLOSSAR

Begriff

Beschreibung

Synonym

Abhängigkeit

Die Abhängigkeitsbeziehung (engl. depen-

dency) ist eine Beziehung zwischen zwei Elemen-

ten, die beschreibt, dass ein Element ein anderes

Element für seine Spezifikation oder Implementie-

rung benötigt [Weilkiens 2006, S. 233].

Algorithmus

Endliches Set von definierten Regeln für die Lö-

sung eines Problems mit einer endlichen Anzahl

von Schritten [IEEE 610.12-1990, S. 9].

Allokation

Prozess der Verteilung von Anforderungen, Res-

sourcen oder anderen Elementen auf die Kom-

ponenten eines Systems (in Anlehnung an [IEEE

610.12-1990, S. 10] und [ISO 26262-1, S. 1]).

Anforderung

Dokumentierte Beschreibung eines Zustands oder

einer Fähigkeit, die von einem Nutzer benötigt

wird, um ein Problem zu lösen oder ein Ziel zu er-

reichen (in Anlehnung an [IEEE 610.12-1990,

S. 62]).

Architektur

Repräsentation der Systems, die die Identifikation

der Systemelemente, Systemgrenzen und Schnitt-

stellen erlaubt [ISO 26262-1, S. 2]).

Artefakt

Beschreibt jegliche Art von während der Pro-

duktentwicklung erzeugten produktbeschrei-

benden Informationen (Spezifikationen, Funkti-

onsstrukturen, Produktstrukturen etc.), unabhän-

gig von ihrer informationstechnischen Ausführ-

barkeit [Cleland-Huang et al. 2003, S. 797].

Partialmodell

artefaktinterner

Tracelink

Beschreibt die Abhängigkeit zwischen zwei Ele-

menten aus dem gleichen Artefakt [Königs et al.

2012, S. 930].

artefaktübergreifender

Tracelink

Beschreibt die Abhängigkeit zwischen zwei Ele-

menten aus unterschiedlichen Artefakten [Königs

et al. 2012, S. 930].

Auswirkungsanalyse

Traceability-basierte Methode, bei welcher alle

Elemente der Produkt-beschreibenden Artefakte

eines Systems identifiziert werden, die von einer

vorgeschlagenen Änderung direkt oder indirekt

potentiell betroffen sein können.

Impact Analyse

Glossar

224

Begriff

Beschreibung

Synonym

CATIA

CAD-Programm der Firma Dassault Systèmes

(Computer Aided Three-Dimensional Interactive

Application).

Crowdsourcing

Beim Crowdsourcing wird eine von einem Pro-

zesseigner definierte Aufgaben- oder Problem-

stellungen durch eine größere Anzahl an Men-

schen bearbeitet [Doan et al. 2011, S. 87].

Daten

„Daten sind Symbole und Zahlenwerte ohne Be-

deutung“ [Weber et al. 2007, S. 141]

Design Research

Methodology

Die Design Research Methodology (DRM) nach

Blessing und Chakrabarti ist eine Methodik zur

Durchführung von Forschungsarbeiten im Bereich

der Konstruktion und Entwicklung [Blessing und

Chakrabarti 2009].

Design Structure Matrix

Die Design Structure Matrix (DSM) ist eine Matrix,

in der Abhängigkeiten zwischen Elementen eines

Artefakts dokumentiert und ausgewertet werden

können [Maurer 2007, S. 54].

Disziplin

Abgrenzung der klassischen Fachgebiete wie

Mechanik, Elektrik & Elektronik und Informations-

technik [VDI-Richtlinie 2206, S. 14]

Domäne

Domain Mapping Mat-

rix

Die Domain Mapping Matrix (DMM) ist eine Mat-

rix, in der Abhängigkeiten zwischen Elementen

unterschiedlicher Artefakte dokumentiert und

ausgewertet werden können [Maurer 2007,

S. 58].

Durchgängige Nach-

verfolgbarkeit

siehe. Traceabi-

lity

Dymola

Auf Modelica basierende Simulationsumgebung

der Firma Dassault Systèmes.

Element

Elemente stellen die Bestandteile der Artefakte

dar. Sie können innerhalb eines Artefakts hierar-

chisch strukturiert und darüber hinaus über Pa-

rameter konkretisiert sein.

Elternelement

Als Elternelemente werden Elemente bezeichnet,

die einem anderen Element (sog. Kinderelemen-

te) in einer Hierarchie übergeordnet sind.

ENOVIA

PLM-System der Firma Dassault Systèmes.

Falsch negativer

Tracelink

Fälschlicherweise fehlender Tracelink zwischen

einem Elementpaar, zwischen dem eine Abhän-

gigkeit besteht.

Glossar

225

Begriff

Beschreibung

Synonym

Falsch positiver

Tracelink

Fälschlicherweise vorhandener Tracelink zwi-

schen einem Elementpaar, zwischen dem keine

Abhängigkeit besteht [Hayes et al. 2006, S. 4].

Funktion

Funktionen stellen im Kontext der Systementwick-

lung „eine am Zweck orientierte, lösungsneutrale,

als Operation beschriebene Beziehung zwischen

Eingangs- und Ausgangsgrößen eines Systems“

dar [Ponn und Lindemann 2008, S. 56].

Funktionsstruktur

Verknüpfung von Teilfunktionen zu einer Gesamt-

funktion [Pahl et al. 2007, S. 243].

Geschwisterelement

Als Geschwisterelemente werden Elemente be-

zeichnet, die auf einer hierarchischen Ebene ei-

ner Struktur liegen.

Granularität

Bezeichnet im Kontext der durchgängigen Nach-

verfolgbarkeit den Detaillierungsgrad auf dem

zwischen unterschiedlichen Artefakten Tracelinks

modelliert werden [Egyed et al. 2009, S. 2]. Wäh-

rend eine hohe oder feine Granularität bedeu-

tet, dass sehr detailliert modelliert wird (z. B. zwi-

schen Parametern unterschiedlicher Elemente),

bedeutet eine geringe oder grobe Granularität,

dass auf einer abstrakten Ebene modelliert wird.

Hierarchie

Struktur, bei der Komponenten in Ebenen unter-

schiedlichen Rangs angeordnet sind. Dabei hat

jede Komponente null, eine oder mehr Kinder

und keine Komponente mehr als eine Eltern-

Komponente (in Anlehnung an [IEEE 610.12-1990,

S. 37]).

Identifier

Name, Adresse, Label oder kennzeichnender In-

dex eines Elements in einem Computer Pro-

gramm [IEEE 610.12-1990, S. 38].

ID, Unique ID

Impact Analyse

siehe Auswir-

kungsanalyse

Inklusionshierarchie

Hierarchisches Konstrukt, bei dem die überge-

ordneten Elemente abstrakte Container für die

untergeordneten Elemente darstellen.

Informationen

„Informationen sind an einen speziellen Kontext

gebundene Daten mit für den Menschen ver-

ständlicher Bedeutung“ [Weber et al. 2007,

S. 141]

Glossar

226

Begriff

Beschreibung

Synonym

Integrative Software

Werkzeuge

Im Kontext der durchgängigen Nachverfolgbar-

keit werden Software Werkzeuge als integrativ

bezeichnet, wenn mit ihnen Tracelinks zwischen

Artefakten, die aus bzw. mit existierenden Auto-

renwerkzeugen importiert bzw. synchronisiert

werden können.

Kandidaten-Link

Kandidaten-Links sind Vorschläge für Tracelinks,

die mit einer gewissen Wahrscheinlichkeit zwi-

schen zwei Elemente bestehen. Sie werden von

Methoden zur Unterstützung der Erfassung und

Pflege von Traceability-Modellen ausgegeben

und bedürfen einer manuellen Überprüfung.

Kinderelement

Als Kinderelemente werden Elemente bezeich-

net, die einem anderen Element (sog. Elternele-

mente) in einer Hierarchie untergeordnet sind.

Komplexität

Die Komplexität bezieht sich auf die Anzahl und

Art der Beziehungen zwischen Elementen in ei-

nem System [Weilkiens 2006, S. 10].

Kompliziertheit

Bezieht sich auf die Anzahl der unterschiedlichen

Elemente [Weilkiens 2006, S. 10].

Komponente

Bestandteil aus welchen ein System aufgebaut

ist. Komponenten können sowohl Hard- als auch

Software sein und weiter in andere Komponen-

ten unterteilt werden [IEEE 610.12-1990, S. 18].

Kompositionelle

Inklusionshierarchie

Die kompositionelle Inklusionshierarchie ist um-

gangssprachlich auch als „is part of“ oder „is

composed of“-Hierarchie bekannt. Sie wird ver-

wendet, um Systeme zu strukturieren [Lane 2006,

S. 85-86; Pumain 2006, S. 4]. Dabei wird ein Sys-

tem so lange in seine Subsysteme gegliedert, bis

man zu einer Ebene gelangt, die sich nicht weiter

unterteilen lässt bzw. nicht mehr sinngemäß ist.

Konsistenz

Grad der Uniformität, Standardisierung und Frei-

heit von Widersprüchen zwischen den Artefakten

bzw. Teilen eines Systems oder Komponente [IEEE

610.12-1990, S. 21].

Mechatronik

„Mechatronik ist die synergetische Integration

physikalischer Systeme mit Informationstechnolo-

gie[…]“ (aus dem Englischen nach [Tomizuka

2002, S. 877] sowie in Anlehnung an [VDI-

Richtlinie 2206, S. 14])

Glossar

227

Begriff

Beschreibung

Synonym

Metamodell

Bezeichnet ein übergeordnetes Modell, in dem

für ein Traceability-Werkzeug die zur Verknüpfung

erlaubten Artefakte, Elemente und Tracelinks be-

schrieben werden.

Traceability

Schema

Methode

Planmäßiges Vorgehen zum Erreichen eines be-

stimmten Ziels [Pahl et al. 2007, S. 784].

Modelica

Objektorientierte Beschreibungssprache für phy-

sikalische Modelle.

Modell

Ein dem Zweck entsprechender Repräsentant

(Vertreter) eines Originals [Pahl et al. 2007,

S. 784].

Modellbasierte Ent-

wicklung

Verwendet Modelle als zentrale Komponente.

Während des Entwicklungsprozesses werden un-

terschiedliche Arten von Modellen für spezifische

Aufgabenstellungen entwickelt, die spezifische

Aspekte des Systems beschreiben [Tudorache

2006, S. 23].

Modellieren

Erstellen und Verändern (Modifizieren) eines Mo-

dells im Gesamten oder in Teilen [Pahl et al. 2007,

S. 784].

Multiple-Domain Matrix

Die Multiple-Domain Matrix (MDM) stellt eine

Kombination aus mehreren DSMs und DMMs dar

[Maurer 2007, S. 60].

Nicht-integrative Soft-

ware Werkzeuge

Im Kontext der durchgängigen Nachverfolgbar-

keit werden Software Werkzeuge als nicht-

integrativ bezeichnet, wenn mit ihnen ausschließ-

lich Tracelinks zwischen Artefakten modelliert

werden können, die in demselben Werkzeug er-

stellt wurden.

Partialmodell

Dokumente, Modelle, Code usw., die während

einer Phase des Entwicklungsprozesses erstellt

werden

Artefakt

phaseninterner

Tracelink

Beschreibt die Abhängigkeit zwischen zwei Ele-

menten aus Artefakten der gleichen Prozesspha-

se.

phasenübergreifender

Tracelink

Beschreibt die Abhängigkeit zwischen zwei Ele-

menten aus Artefakten unterschiedlicher Pro-

zessphasen.

Glossar

228

Begriff

Beschreibung

Synonym

Präzision

Ein Parameter zur Angabe der Relevanz einer

Treffermenge, der sich aus dem Verhältnis der

Anzahl der korrekterweise identifizierten Elemente

und der Vereinigungsmenge aller identifizierten

Elemente ergibt [Manning et al. 2009, S. 155].

Precision

Produktmodell

Gesamtmenge aller, im Rahmen der Entwicklung

entstehenden, Produkt-beschreibenden Modelle

(wie bspw. Anforderungen oder Geometrie-

Modelle)

Qualität

Grad zu welchem ein System, eine Komponente

oder Prozess die spezifizierten Anforderungen er-

füllt [IEEE 610.12-1990, S. 60].

Qualitative Traceability

Lässt nur die Identifikation abhängiger Elemente

zu, ohne Aussagen über den Grad der Abhän-

gigkeit treffen zu können.

Quantitative

Traceability

Lässt Aussagen über das Ausmaß der Beeinflus-

sung eines Elements durch die Änderung eines

abhängigen Elements zu [Sutinen et al. 2002,

S. 1].

Trefferquote

Ein Parameter zur Angabe der Vollständigkeit ei-

ner Treffermenge, der sich aus dem Verhältnis

der Anzahl der korrekterweise identifizierten Ele-

mente zu der Vereinigungsmenge der relevanten

Elemente ergibt [Manning et al. 2009, S. 155].

Recall

Requirements

Traceability

Bezieht sich auf die Fähigkeit, das Leben einer

Anforderung zu beschreiben und zu verfolgen:

sowohl vorwärts als auch rückwärts [Gotel und

Finkelstein 1994, S. 94].

Subelement

siehe Kinder-

element

Subsumtive Inklusions-

hierarchie

Mit Hilfe der subsumtiven Inklusionshierarchie

können Objekte von allgemein bis spezifisch klas-

sifiziert werden. Sie wird auch „is a“-Hierarchie

genannt und entspricht der Generalisierung im

Blockdefinitionsdiagramm der SysML [Weilkiens

2006].

System

Ein System ist eine Zusammenstellung unter-

schiedlicher, miteinander interagierender Syste-

melemente, die ein gemeinsames oder mehrere

Ziele verfolgen [Department of Defense 2001,

S. 3; Haskins 2006, S. 1.5].

Glossar

229

Begriff

Beschreibung

Synonym

Systems Engineering

Interdisziplinäre Methodik zur erfolgreichen Ent-

wicklung von Systemen [Haskins 2006, S. 1.5].

Top-Down

Vorgehensweise, bei der ausgehend vom Abs-

trakten schrittweise konkretisiert wird.

Traceability

Traceability ist eine Methode zur Unterstützung

der Entwicklung mechatronischer Systeme, bei

welcher Abhängigkeiten zwischen den Elemen-

ten Produkt-beschreibender Artefakte explizit

dokumentiert werden. Das Ziel der Methode, der

Zustand einer durchgängigen Nachverfolgbar-

keit zwischen den produktbeschreibenden Arte-

fakten, wird ebenfalls mit dem Begriff Traceability

beschrieben.

Durchgängige

Nachverfolg-

barkeit

Traceability-Matrix

Matrix zur Dokumentation von Beziehungen zwi-

schen zwei oder mehr Produkten (Artefakten)

des Entwicklungsprozesses [IEEE 610.12-1990,

S. 78].

Traceability-Modell

Bezeichnet die Gesamtheit aus betrachteten Ar-

tefakten und ihrer, die gegenseitigen Abhängig-

keiten beschreibenden, Tracelinks (in Anlehnung

an [Pinheiro 2003]).

Integriertes

Modell

Traceability-Schema

Bezeichnet ein Schema, in dem für ein Traceabili-

ty-Werkzeug die zur Verknüpfung erlaubten Arte-

fakte, Elemente und Tracelinks beschrieben wer-

den [Winkler und Pilgrim 2010, S. 536].

Metamodell

Tracelink

Bei Tracelinks handelt es sich um Software-

Objekte, die je nach Umsetzung bspw. die IDs

der voneinander abhängigen Elemente oder Pa-

rameter beinhalten und darüber deren Abhän-

gigkeit ausdrücken [van Gorp et al. 2006, S. 2].

Trace Link,

Traceability

Link, Verknüp-

fung, Relation

Tracelink-Modell

Bezeichnet die Gesamtheit der Tracelinks zwi-

schen einer festzulegenden Anzahl von Artefak-

ten. Ist Teilmenge des Traceability-Modells.

Abhängigkeits-

modell

Verknüpfung

siehe Tracelink

Wissen

„Wissen ist angewandte Information mit Bezug zu

anderen Informationen, d. h. Wissen ist relational“

[Weber et al. 2007, S. 142]

231

ANHANG

Anhang

232

A. MATERIAL ZUR STUDIE „EVALUATION DER HYPOTHESE 1* IM KONTEXT DER

SYSTEMENTWICKLUNG“

STUDIENEINFÜHRUNG UND AUFGABENSTELLUNG

Abhängigkeiten zwischen Funktionen und Bauteilen

Vielen Dank für Ihre Teilnahme an unserer Studie!

In dieser Untersuchung geht es um Abhängigkeiten zwischen den Funktionen eines

Geräts und den Bauteilen des Geräts. Die beiden Geräte, die im Rahmen der Studie

untersucht werden, sind eine Kaffee-Vollautomaten und ein Fahrrad.

Der Versuchsablauf gliedert sich folgendermaßen:

1) Einführung in die Thematik und

2) Einführung in die verwendete Versuchs-Software

3) Bearbeitung zweier Teilaufgaben jeweils an den beiden Beispielen Kaffee-

Vollautomat und Fahrrad:

1. Bearbeitung der Abhängigkeiten zwischen Gesamtfunktionen und

Baugruppen bzw. Systemen

2. Bearbeitung der Abhängigkeiten zwischen Teilfunktionen und Bauteilen

4) Ausfüllen eines Fragebogens

5) Nachbesprechung

Für Zwischenfragen steht Ihnen der Versuchsleiter jederzeit gerne zur Verfügung!

Zuerst füllen sie bitte folgende Angaben zu ihrer Person aus:

Alter

Geschlecht

Abschluss bzw.

Fachgebiet

Einschätzung der

eigenen Kenntnis

des Gerätes

„Kaffee-

Vollautomat“

Kenne ich

nicht

Kenne die Bau-

teile und weiß in

etwa wie es

funktioniert

Habe ich

selbst schon

repariert

Anhang

233

Einschätzung der

eigenen Kenntnis

des Geräts „Fahr-

rad“

Kenne ich

nicht

Kenne die Bau-

teile und weiß in

etwa wie es

funktioniert

Habe ich

selbst schon

repariert

1. Einführung in die Thematik

Im Folgenden möchten wir Ihnen einen kurzen inhaltlichen Einblick in das Themen-

gebiet geben, aus dem die zu lösenden Aufgaben entstammen. Bitte lesen sie ihn

aufmerksam, da ein grundsätzliches Verständnis der Beispiele für die Bearbeitung

notwendig ist.

1.1 Partialmodelle, Abhängigkeiten und Tracelinks

Im Entwicklungsprozess eines Gerätes entstehen verschiedene Partialmodelle, die un-

terschiedliche Sichtweisen auf das System strukturiert abbilden. Am Anfang des Ent-

wicklungsprozesses stehen zunächst Anforderungen an ein zu entwickelndes Produkt.

In der sich anschließenden Entwurfsphase entstehen Funktions-Modelle, um die funk-

tionelle Realisierung der Anforderungen zu beschreiben, sowie Modelle, die die Pro-

duktstruktur im Hinblick auf Baugruppen, Systeme und Bauteile abbilden.

Zwischen den Elementen, aus denen diese Modelle aufgebaut sind, bestehen dabei

inhaltliche Abhängigkeiten, d.h.: „dieses Bauteil trägt zur Umsetzung dieser Funktion

bei“. So kann bspw. die Funktion „Energieversorgung realisieren“ durch das Bauteil

„Batterie“ in der Produktstruktur definiert werden. Im Rahmen der folgenden Aufga-

benstellungen werden Sie Funktions-Modelle und Produktstrukturen auf genau solche

inhaltlichen Abhängigkeiten zueinander untersuchen.

1.2 Matrixdarstellungen zur Erfassung der Abhängigkeiten

Zum Zweck dieser Untersuchungen werden Matrizen in Excel genutzt (siehe Abbil-

dung 1). Dabei werden die Baugruppen und Bauteile in den Zeilen links von der Mat-

rix dargestellt. Die Funktionen sind für eine bessere Lesbarkeit ebenfalls waagerecht

Anhang

234

und oberhalb der Matrix angeordnet. Abhängigkeiten zwischen einem Bauteil und

einer Funktion werden in deren gemeinsamer Zelle innerhalb der Matrix gekenn-

zeichnet. Es geht dabei um direkte Abhängigkeiten im Sinne von „Funktion wird

durch Bauteil (teilweise) realisiert“. Um die Bauteile und Funktionen eindeutig identifi-

zieren zu können, wenn die gemeinsame Zelle ausgewählt ist, werden sie gelb mar-

kiert.

Abbildung 1: Matrix mit Funktionen (oben) und Bauteilen (links)

Ihre Aufgabe ist es im Folgenden alle Zellen der Matrix mit den Pfeiltasten durchzu-

gehen und die zugehörigen gelb markierten Bauteil-Funktion-Kombinationen auf in-

haltliche Abhängigkeiten zueinander zu untersuchen. Sollte Ihrer Meinung nach eine

Abhängigkeit zwischen Bauteil und Funktion bestehen, dokumentieren Sie dies mit

einer „1“ (eine Abhängigkeit ist vorhanden). Sind sie hingegen der Meinung, dass ein

Bauteil keinen Beitrag zur Erfüllung einer Funktion leistet, dokumentieren Sie dies mit

einer „0“ (es ist keine Abhängigkeit vorhanden).

Wenn Sie bereit sind die Studie zu beginnen, klicken Sie bitte auf den Start Button. Im

Anschluss wählen sie die Zelle links oben in der Matrix aus und fangen an Ihre Ent-

scheidungen mit „0“ und „1“ einzutragen. Die Navigation von einer Zelle zur nächs-

ten innerhalb der Matrix erfolgt mit den Pfeiltasten: „Pfeil nach rechts“  und „Pfeil

nach links“ . Sollte der rechte Rand der Matrix erreicht werden springt die ausge-

wählte Zelle automatisch bei Druck der Taste  in die erste Zelle der darauffolgen-

den Zeile. Sollten Sie eine Entscheidung nachträglich ändern wollen, können Sie die

zugehörige Zelle entweder mit den Tasten oder der Maus erreichen.

1.3 Einführungsbeispiel

Um den Umgang mit Abhängigkeiten zwischen Funktionen und Bauteilen und deren

Dokumentation in der Excel Tabelle zu üben, bearbeiten Sie zunächst ein einfaches

und kleines Beispiel. In diesem Einführungsbeispiel handelt es sich um ein Wohnhaus

mit unterschiedlichen Räumen und Einrichtungsgegenständen und deren Funktio-

nen. Das Beispiel ist genau wie die später folgenden zwei geteilt: zunächst werden

wird reali-

siert durch

/ in

Anhang

235

Sie Abhängigkeiten zwischen Gesamtfunktionen und Baugruppen und im Anschluss

auf Teilfunktionen und Bauteile untersuchen. Bitte zögern Sie nicht, Fragen zu äußern,

die während der Bearbeitung des Einführungsbeispiels aufkommen!

2. Aufgabe „Kaffeevollautomat“

Damit Sie, auch wenn Sie Ihre Kenntnis des Beispiels „Kaffeevollautomat“ als gering

eingestuft haben, die Aufgabenstellung lösen können, werden Ihnen im Folgenden

die Systeme, Baugruppen und Bauteile sowie die grundlegende Funktionsweise des

Kaffeevollautomaten erläutert. Dabei liegt der Fokus auf den wichtigsten Baugrup-

pen und Funktionen.

Als Modell des Kaffeeautomaten wurde

die am IPK vorhandene Variante ge-

wählt, so dass die Wahrscheinlichkeit

groß ist, dass sie den Automaten schon

einmal gesehen haben. In der Abbil-

dung auf der linken Seite ist der Kaffee-

vollautomat schematisch dargestellt.

Anhand dieser Abbildung werden fol-

gend die Baugruppen, Systeme und

Bauteile des Kaffeevollautomaten er-

läutert.

Gehäuse:

Das Gehäuse des Vollautomaten be-

steht aus insgesamt vier Bauteilen: der

Gehäusefront und dem Gehäuse-

Oberteil sowie den beiden Gehäuse-

Seitenteilen.

Bohnenspeicher:

In dem Bohnenspeicher werden, wie

der Name schon sagt, die ungemahle-

nen Bohnen bis zur Verwendung auf-

bewahrt. Er besteht aus zwei Bauteilen:

dem Bohnenbehälter sowie einer Ab-

deckung, um Schmutz und Staub von

den Bohnen fern zu halten.

Anhang

236

Auffangeinheit:

Die Auffangeinheit ist unten im Kaffee-

vollautomaten angeordnet. In dieser

Baugruppe werden alle Abfälle ge-

sammelt. Sie besteht aus der Tropfscha-

le, in der das Schmutzwasser gesam-

melt wird. Im vorderen Bereich wird sie

vom Tropfblech abgedeckt, auf das die

Kaffeetasse gestellt wird. Mittig wird der

Abfallbehälter auf die Tropfschale ge-

setzt, in dem der gemahlene und be-

nutzte Kaffee gesammelt wird.

Wasserbehälter:

Die Baugruppe „Wasserbehälter“ um-

fasst eine vergleichsweise große Anzahl

an Bauteilen. Das offensichtlichste ist

der Wassertank, in dem Frischwasser zur

Verfügung gestellt wird. Die Abdeckung

gegen Schmutz und Staub wird durch

den Wassertankdeckel gewährleistet.

Damit das Wasser beim Nachfüllen

nicht unten aus dem Tank herausläuft

gibt es ein Wassertank-Ventil, welches

nur im eingesetzten Zustand geöffnet ist.

Zusätzlich verfügt der Wasserbehälter

über einen Wasserstandssensor, der der

Steuerelektronik meldet, wenn der Tank

leer ist. Bei Bezug eines Kaffees wird das

Wasser durch einen Wasserfilter gezo-

gen, um eine Verkalkung des Vollauto-

maten zu verhindern. Dieser Wasserfilter

wird mit Hilfe der Wasserfilter-Fixierung

in Position gehalten.

Mahleinheit:

In der Mahleinheit werden die Bohnen

aus dem Bohnen-Speicher zu Kaffee-

pulver gemahlen. Dabei werden die

Bohnen zwischen den sich drehenden

Mahlkegel und Mahlring zerkleinert. Der

Antrieb erfolgt mit Hilfe des Mahlwerk-

Motors. Um das für den Mahlvorgang

notwendige Drehmoment aufbringen

zu können, wird es mit dem Mahlwerk-

Getriebe übersetzt.

Anhang

237

Brüheinheit:

In der Baugruppe „Brüheinheit“ wird das

gemahlene Kaffeepulver im Kaffeepul-

ver-Verdichtungsrohr verdichtet. Dies

wird mit Hilfe des Brüheinheit-Verdich-

tungsmotors und dem Brüheinheit-Ge-

triebe durchgeführt. Sobald das Pulver

verdichtet wurde wird es mit unter

Druck stehendem Frischwasser durch-

setzt. Um die Brüheinheit als Ganzes aus

dem Vollautomaten entnehmen und

reinigen zu können, verfügt sie über ein

eigenes Brüheinheit-Gehäuse.

Fluidsystem:

Das Fluidsystem dient der Wasserversor-

gung innerhalb des Kaffeevollautoma-

ten. Es besteht aus einer Wasserpumpe,

die das Wasser aus dem Tank pumpt

und einen hohen Druck herstellt. Dieses

Wasser wird im Durchlauferhitzer er-

wärmt und von dort in die Brüheinheit

gepumpt. Der fertige Kaffee wird über

den Kaffeeauslauf in die Tasse geleitet.

Zusätzlich verfügt das Fluidsystem noch

über einen Durchflussmelder und einen

Temperatursensor, die die Steuerelekt-

ronik mit Informationen zur Steuerung

der Zubereitung versorgen. Die eben-

falls zugehörigen Schläuche verbinden

die unterschiedlichen Bauteile und sind

in der Abbildung links nicht dargestellt.

Elektrisches System:

Das elektrische System besteht in seiner

vereinfachten Form insbesondere aus

der Steuerungselektronik, die die Sens-

ordaten des Fluidsystems und des Was-

serbehälters als Input verarbeitet und

die Kaffee-Zubereitung steuert. Um

Feedback an den Nutzer ausgeben zu

können verfügt es über ein Display.

Ebenfalls dem elektrischen System zuge-

rechnet wird der Transformator, der die

Spannung von 220 V auf 12 V transfor-

miert. Kabelstränge werden im vorlie-

genden Beispiel vernachlässigt.

Anhang

238

Sie erhalten nun eine Excel Matrix, in der die Funktionen und Bauteile, die Sie eben

vorgestellt bekommen haben, enthalten sind. Bitte füllen Sie die Matrix genau so aus,

wie Sie es bei dem Einführungsbeispiel getan haben.

3. Aufgabe „Fahrrad“

Das Fahrrad-Beispiel sollte jedem vom

grundsätzlichen Aufbau her bekannt

sein. In der Abbildung auf der linken Sei-

te ist ein Fahrrad schematisch darge-

stellt. Anhand dieser Abbildung werden

folgend die wichtigsten Baugruppen,

Systeme und Bauteile des Fahrrads er-

läutert.

Rahmen:

Der Rahmen ist das Gestell des Fahr-

rads. Er trägt das Gewicht des Fahrers,

das er auf die Räder überträgt und an

ihm sind alle Komponenten befestigt,

die für weitere Funktionen des Fahrra-

des (zum Beispiel Lenkung und Antrieb)

benötigt werden. Im vorliegenden Bei-

spiel besteht der Rahmen aus zwei Bau-

teilen: dem Grundrahmen und dem Hin-

terbau. Dieser Aufbau ist so gewählt, um

eine Federung des Hinterrads zu realisie-

ren, die jedoch im Folgenden vernach-

lässigt wird.

Lenkung:

Die Lenkung dient der Beeinflussung der

Fahrtrichtung des Fahrrads. Sie besteht

aus dem Lenker, welcher über den

Vorbau mit der Federgabel verbunden

ist. Die drehbar gelagerte Verbindung

zum Rahmen wird über den Steuersatz

hergestellt.

Anhang

239

Antriebseinheit:

Die Antriebseinheit realisiert den Vor-

trieb des Fahrrads, indem die Fußkraft

des Fahrers auf das Hinterrad übertra-

gen wird. Sie besteht aus den Pedalen

und Tretkurbeln, die mit den Kettenblät-

tern (Zahnräder vorne) verbunden sind.

Die Fußkraft wird über diese Bauteile auf

die Kette und von dieser auf die Zahn-

kranzkassette (Zahnräder hinten) über-

tragen.

Schaltung:

Mit Hilfe der Schaltung kann das Über-

setzungsverhältnis der Antriebseinheit

verändert werden. Sie besteht aus dem

Schaltwerk, welches die seitliche Ver-

schiebung der Kette auf der Zahnkranz-

kassette (Zahnräder hinten) realisiert

und dem Umwerfer, der die gleiche

Funktion für die Kettenblätter (Zahnrä-

der vorne) hat. Die Wahl des Gangs er-

folgt im vorliegenden Beispiel mit zwei

Schaltdrehgriffen, die über Bowdenzü-

gen mit den Schaltvorrichtungen ver-

bunden sind.

Bremssystem:

An dem Fahrrad im Beispiel wird ein

Scheibenbremssystem verwendet. Es

besteht aus den beiden Scheibenbrem-

sen am Vorder- und Hinterrad, welche

von den Bremssätteln umschlossen

werden. Diese sind über Hydrauliklei-

tungen mit den Bremshebeln am Lenker

verbunden.

Sitzeinheit:

Die Sitzeinheit besteht aus dem Sattel

der fest mit der Sattelstütze verbunden

ist. Über den Schnellspanner sind diese

mit dem Rahmen verbunden und kön-

nen einfach in der Höhe verstellt wer-

den.

Anhang

240

Vorder- und Hinterrad:

Da die Zahnkranzkassette der Antriebs-

einheit und die Bremsscheiben dem

Bremssystem zugeordnet werden sind

das Vorder- und das Hinterrad in diesem

Beispiel baugleich. Sie bestehen aus ei-

ner Nabe, die am Rahmen bzw. der Fe-

dergabel befestigt wird. Die Felge, die

den Reifen aufnimmt wird mit der Nabe

über Speichen verbunden.

Sie erhalten nun eine Excel Matrix, in der die Funktionen und Bauteile, die Sie eben

vorgestellt bekommen haben, enthalten sind. Bitte füllen Sie die Matrix genau so aus,

wie Sie es bei dem Einführungsbeispiel getan haben.

ARTEFAKTE DES BEISPIELPRODUKTS „HAUS“

Bauteile abstrakt

Funktionen abstrakt

Wohnzimmer

Lebensmittel verarbeiten

Badezimmer

Freizeit genießen

Schlafzimmer

Körperpflege ermöglichen

Küche

Kleidung lagern

Schlafgelegenheit bieten

Bauteile detailliert

Funktionen detailliert

Sofa

Essen erwärmen

Fernseher

Lebensmittel kühlen

Dusche

Videos anzeigen

Waschbecken

Körper waschen

Bett

Zahnputzabwasser aufnehmen

Kleiderschrank

Kleidung lagern

Herd

Schlafgelegenheit bieten

Kühlschrank

Anhang

241

ARTEFAKTE DES BEISPIELPRODUKTS „KAFFEEVOLLAUTOMAT“

Bauteile abstrakt

Funktionen abstrakt

Gehäuse

Bohnen aufbewahren

Bohnenspeicher

Umwelteinflüsse fernhalten

Auffangeinheit

Abfall sammeln

Wasserbehälter

Frischwasser bereitstellen

Mahleinheit

Kaffee zubereiten

Brüheinheit

Zubereitung steuern

Fluidsystem

Benutzer warnen

Elektrisches System

Bauteile detailliert

Funktionen detailliert

Gehäuse-Oberteil

Bohnen aufbewahren

Gehäusefront

Umwelteinflüsse fernhalten

Gehäuseseitenteil links

Schmutzwasser sammeln

Gehäuseseitenteil rechts

Trester sammeln

Bohnenbehälter

Frischwasser speichern

Bohnenbehälterabdeckung

Frischwasser filtern

Tropfschale

Frischwasser vor Umwelt schützen

Tropfblech

Frischwasser zuführen

Abfallbehälter

Bohnen mahlen

Wassertank

Kaffeepulver verdichten

Wassertankdeckel

Wasser erhitzen

Wasserstandssensor

Wasser verdichten

Wassertank-Ventil

Kaffee in Tasse füllen

Wasserfilter

Zubereitung steuern

Wasserfilter-Fixierung

Warnen wenn kein Frischwasser vorhanden

Bohnen-Mahlkegel

Warnen, wenn Schmutzwasser voll

Bohnen-Mahlring

Warnen, wenn Tresterbehälter voll

Mahlwerk-Getriebe

Mahlwerk-Motor

Brüheinheit-Gehäuse

Brüheinheit-Getriebe

Brüheinheit-Verdichtungsmotor

Kaffee-Verdichtungsrohr

Wasserpumpe

Durchflussmelder

Durchlauferhitzer

Temperatursensor

Kaffeeauslauf

Anhang

242

Bauteile detailliert

Funktionen detailliert

Schläuche

Display

Steuerelektronik

Transformator

ARTEFAKTE DES BEISPIELPRODUKTS „FAHRRAD“

Bauteile abstrakt

Funktionen abstrakt

Rahmen

Antrieb realisieren

Lenkung

Bremsen realisieren

Antriebseinheit

Lenken ermöglichen

Schaltung

Variable Übersetzung realisieren

Bremssystem

Sitzeinheit

Vorderrad

Hinterrad

Bauteile detailliert

Funktionen detailliert

Grundrahmen

Fußkraft aufnehmen

Hinterbau

Fußkraft übertragen

Lenker

Fußkraft auf Hinterrad übertragen

Vorbau

Bremskraft aufnehmen

Steuersatz

Bremskraft übertragen

Federgabel

Bremskraft auf Räder übertragen

Kettenblätter

Lenkbewegung aufnehmen

Tretkurbel

Lenkbewegung auf Rad übertragen

Pedal

Schaltkraft aufnehmen

Kette

Schaltkraft übertragen

Zahnkranzkasette

Übersetzung wechseln

Schaltdrehgriffe

Bowdenzüge

Umwerfer

Schaltwerk

Bremshebel

Hydraulikleitung

Bremssattel

Scheibenbremse

Sattel

Sattelstütze

Anhang

243

Bauteile detailliert

Funktionen detailliert

Schnellspanner

Nabe

Speichen

Felge

Reifen

Anhang

244

B. MATERIAL ZUR STUDIE „EVALUATION DER METHODEN ECOTRACING UND

TRACEEVALUATION“

STUDIENEINFÜHRUNG UND AUFGABENSTELLUNG

Studie zu Abhängigkeiten zwischen Modellen

Bitte füllen Sie zunächst die untenstehenden Felder aus.

Alter: Geschlecht:

Studiengang/Beruf:

Einführung in das Thema

Im Rahmen der Entwicklung von Produkten werden viele unterschiedliche Modelle

erstellt (siehe Abbildung 1). Die bekanntesten Modelle beschreiben die Anforderun-

gen (was soll das Produkt leisten), die Funktionen (wie sollen die Anforderungen reali-

siert werden) und die Produktstruktur (welche geometrischen Baugruppen und -teile

werden benötigt). Die genannten Modelle bestehen aus mehreren Elementen, die

häufig hierarchisch strukturiert sind (z.B. Eltern-Kind-Beziehung).

Abbildung 1: Entwicklung unterschiedlicher Modelle entlang des Entwicklungsprozesses

Zwischen den Modellelementen bestehen viele inhaltliche Zusammenhänge. Eine

Funktion beispielsweise erfüllt eine Anforderung und wird durch ein oder mehrere

Produktstrukturelemente umgesetzt. Zum Beispiel wird die Funktion „Klima regeln“

vom Produktstrukturelement „Klimaanlage“ umgesetzt. „Klima regeln“ oder „Klima-

Domänenspezi-

fischer Entwurf

ProduktAnforderungen

Anhang

245

anlage“ können hierbei noch beliebig viele weitere Detaillierungen (Kindelemente),

wie beispielsweise „heizen“, „kühlen“ oder „Luftfilter“ enthalten.

Die inhaltlichen Zusammenhänge zwischen den Elementen werden durch sogenann-

te Tracelinks gespeichert, um u. a. bei einer Änderung während der Produktentwick-

lung nachverfolgen zu können, auf welche anderen Modellelemente diese Einfluss

haben könnte. Die roten Linien in Abbildung 2 repräsentieren solche Tracelinks. Die

Gesamtheit aller für ein Produkt existierenden Tracelinks bildet das Abhängigkeits-

modell.

Abbildung 2: Abhängigkeiten zwischen Modellelementen

Zu dieser Studie

In dieser Studie sollen Sie das Anlegen, Überprüfen und Nutzen des Abhängigkeits-

modells durchführen.

Für das relativ einfache und alltägliche Produktbeispiel eines Fahrrads, sollen Sie zu-

nächst mittels eines Softwaretools ein solches Abhängigkeitsmodell erstellen (eine

Übersicht einiger eventuell unklarer Fahrradteile können Sie auch der ausgelegten

Abbildung entnehmen). Im nächsten Schritt erhalten Sie ein vorgegebenes Abhän-

gigkeitsmodell. In verschiedenen Szenarios sollen Sie die Auswirkungen von Änderun-

gen nachempfinden. Dies geschieht mit Hilfe eines Softwaretools zur Darstellung des

Abhängigkeitsmodells (Viewer). Abschließend sollen Sie in einer weiteren Aufgabe

erneut entscheiden, welche Elemente des Fahrradbeispiels ihrer Meinung nach

durch eine Änderung an einem bestimmten Modellelements beeinflusst werden. Für

die letzte Aufgabe steht Ihnen jedoch lediglich eine einfache Listendarstellung der

Modellelemente zur Verfügung.

Vor Beginn der Aufgaben erhalten Sie Gelegenheit sich mit der Bedienung der bei-

den zu nutzenden Softwarewerkzeuge vertraut zu machen.

Lesen Sie bitte bei jeder Aufgabe zunächst die vollständige Aufgabenstellung.

Falls Sie an dieser Stelle offene Fragen haben, zögern Sie bitte nicht, diese jetzt dem

Betreuer zu stellen.

Anhang

246

Aufgabe 1

In dieser Aufgabe erlernen Sie den Umgang mit dem Softwaretool EcoTracer (Abbil-

dung 3), sowie dem entsprechenden Viewer (Abbildung 4). Mit dem EcoTracer kön-

nen Sie zwischen den Elementen zweier Teilmodelle (z.B. Anforderungen und Funktio-

nen) Verknüpfungen anlegen. Das Programm schlägt Ihnen Schritt für Schritt Elemen-

tepaare für eine Verknüpfung vor. Sie haben in jedem Schritt die Wahl, die vorge-

schlagene Paarung als Tracelink zu bestätigen (Button unten rechts), sie zu verwerfen

(Button unten Mitte) oder die Paarung zunächst zu überspringen und später zu bear-

beiten (Button unten links). Über die notwendigen Vorbereitungen, um den Ablauf zu

starten, werden Sie am Platz informiert. Sie haben nun zunächst etwas Zeit um den

Ablauf des Programms zu testen und zu verstehen. In dieser Einführung brauchen Sie

sich keine Gedanken um Fehler oder falsche Entscheidungen bei der Modellierung

zu machen.

Prinzipiell gilt:

 Sind Sie sich sicher, dass zwischen den markierten Elementen eine Abhängig-

keit besteht, klicken Sie auf bestätigen. (Beispiel: Die Anforderung „Sicherheit

des Fahrers gewährleisten“ eines Kfz sollte definitiv mit dem Bauteil „Airbag“

verknüpft werden.)

 Sind Sie sich sicher, dass zwischen den markierten Elementen keine Abhängig-

keit besteht, klicken sie auf verwerfen. (Beispiel: Die Anforderung „Sicherheit

des Fahrers gewährleisten“ eines Kfz hat keinen direkten Bezug zu der Funktion

„Klima regeln“ und sollte daher als Verknüpfung abgelehnt werden.)

 Bei Unsicherheiten können Sie das Elementepaar überspringen.

Abbildung 3: grafische Oberfläche des EcoTracers

Anhang

247

Sobald Sie sich mit der Bedienung des EcoTracers vertraut gemacht haben, bekom-

men Sie Gelegenheit, die Funktionalitäten des Viewers (Abbildung 4) kennenzuler-

nen.

Mit diesem Tool haben Sie die Möglichkeit, ein Abhängigkeitsmodell übersichtlich zu

betrachten und mit ihm zu interagieren.

Abbildung 4: Screenshot des Viewers

Für jedes Modell wird die gesamte Modellstruktur ihrer Hierarchie entsprechend dar-

gestellt. Verknüpfungen werden nur auf der jeweils tiefstmöglichen Ebene darge-

stellt. Die Verknüpfungslinien befinden sich also hauptsächlich im freien Raum zwi-

schen den Modellen. Die hierarchisch höher gelegenen Elemente eines Modells

„wachsen“ nach außen. Sie können also stets nachverfolgen, zu welchem Modell ein

Element gehört.

Bitte machen Sie sich zumindest mit den folgenden Interaktionsfunktionen vertraut:

 Vergrößern/Verkleinern der Modelle

 Verschieben der Modelle

 Anzweifeln einer Verknüpfung / rückgängig machen einer Anzweiflung

 (De)Selektion eines Elements

 Verändern der Schriftgröße von Elementnamen

 Ein- Ausblenden eines Modells

- Eine Übersicht der Interaktionen ist am Platz ausgelegt.

Anhang

248

Aufgabe 2

Nun sollen Sie, wie in Aufgabe 1 getestet, ein vollständiges Abhängigkeitsmodell für

das Fahrradbeispiel erstellen. Laden Sie hierzu nacheinander die Modellkombinatio-

nen

1. Anforderungsliste-Funktionsstruktur,

2. Funktionsstruktur-Produktstruktur und

3. Anforderungsliste-Produktstruktur

und arbeiten Sie diese mit dem EcoTracer vollständig ab.

Für jede Modellkombination haben Sie 15 Minuten Zeit.

Es gilt nach wie vor:

 Sind Sie sich sicher, dass zwischen den markierten Elementen eine Abhängig-

keit besteht, klicken Sie auf bestätigen.

 Sind Sie sich sicher, dass zwischen den markierten Elementen keine Abhängig-

keit besteht, klicken sie auf verwerfen.

 Bei Unsicherheiten können Sie das Elementepaar überspringen.

Haben Sie alle Elemente einer Modellkombination bewertet bzw. sind sich bei den

übriggebliebenen Verknüpfungen nicht sicher, klicken Sie auf Stop und laden die

nächste Modellkombination.

Achtung: Es gibt keine Möglichkeit Aktionen nachträglich zu ändern oder zurück-

zunehmen. Überlegen Sie sich ihre Interaktionen also bitte sorgfältig.

Sobald Sie die Aufgabe abgeschlossen haben, geben Sie bitte Bescheid.

Aufgabe 3

In dieser Aufgabe arbeiten Sie mit dem Viewer und einem Abhängigkeitsmodell, das

bereits für Sie modelliert wurde. Das vorgegebene Abhängigkeitsmodell kann Fehler

enthalten. Sollten Sie Fehler im Modell entdecken, markieren Sie diese bitte direkt im

Viewer (wie geübt), damit wir die Qualität des Modells sukzessive verbessern können.

Versetzen Sie sich bitte in die unterschiedlichen Situationen und bearbeiten Sie die

beschriebenen Aufgaben.

(3a)

Sie sind Verantwortlicher für die Fertigungsplanung des neuen Fahrradmodells Ihrer

Firma. Sie erhalten Informationen über Anforderungen, die geändert wurden. Sie

müssen nun die Fertigungsabteilung von den Änderungen in Kenntnis setzen. Um un-

Anhang

249

nötigen Planungsaufwand zu verhindern, müssen Sie zunächst die von der Änderung

betroffenen Bauteile identifizieren.

Folgende Anforderungen haben sich geändert.

1) Übersetzung mittels Kettenschaltung

2) Muss mit Handkraft betrieben werden können

3) Hinterradantrieb mittels Fußkurbel und Kette

Identifizieren Sie anhand der Verknüpfungslinien die von den Änderungen betroffe-

nen Bauteile und notieren Sie die relevanten. Es genügt die Nummerierung des be-

troffenen Elementes zu notieren (z.B: A1.2.3).

(3b)

Sie sind Verantwortlicher der Einkaufsabteilung. Ihre Firma hat alternative Angebote

für folgende Bauteile erhalten.

1) Hydraulische Scheibenbremsen

2) Hydraulikleitungen

3) Bremshebel

4) Bremsscheiben

Mit den aufgeführten Bauteilalternativen könnten die Kosten für die Fahrradherstel-

lung drastisch reduziert werden. Es muss jedoch zunächst geprüft werden, ob die

Funktionen und Anforderungen auch mit den neuen Bauteilen weiterhin erfüllt wer-

den können. Hierfür identifizieren und notieren Sie bitte alle von den Bauteiländerun-

gen betroffenen Anforderungen und Funktionen. Es genügt die Nummerierung des

betroffenen Elementes zu notieren (z.B: A1.2.3).

Sobald Sie die Aufgabe abgeschlossen haben, geben Sie bitte Bescheid.

Anhang

250

Aufgabe 4

Bei der Entwicklung von Produkten kommt es häufig zu Änderungen während des

laufenden Prozesses. Ändert sich ein Element, sind davon häufig auch andere Ele-

mente direkt betroffen. Ändert sich bspw. die Anforderung über das „zulässige Ma-

ximalgewicht“ eines Fahrrads, muss häufig das Material des Rahmens angepasst

werden– bei der nun folgende Analyse müsste also das Element „Rahmen“ der Pro-

duktstruktur markiert werden.

Ihre Aufgabe besteht darin, nach Vorgabe einer Änderung an einem Element, zu

bestimmen, welche Elemente (in allen drei Modellen) von dieser Änderung betroffen

sein könnten.

In dieser letzten Aufgabe erhalten Sie erneut das Modell des Fahrrads ohne Verknüp-

fungen. Diesmal arbeiten Sie mit einer einfachen Listendarstellung der Anforderun-

gen, Funktionen und Produktstruktur (enthält die Bauteile) des Fahrrads.

Kommentare zur Studie

Anhang

251

AGGREGIERTE ANZAHL MODELLIERTER TRACELINKS ZWISCHEN ANFORDERUNGEN

UND PRODUKTELEMENTEN

A1.1 Vortrieb

A1.1.1 Hinterradantrieb mittels Fußku...

A1.1.2 Übersetzung mittels Kettenscha...

A1.2 Bremsen

A1.2.1 Verschmutzungsrisiko minimieren

A1.2.2 zuverlässiges Bremsen bei Nässe

A1.2.3 muss mit Handkraft betrieben w...

A1.2.4 geringer Verschleiß von Kompon...

A1.3 sicheres Lenken / Manövrieren

A1.4 geländetaugliche Federung und Üb...

A1.4.1 Unebenheiten im Gelände und im...

A1.4.2 Verschiedene Übersetzungen

A1.5 Beleuchtung vorsehen

P1.1 Rahmen

P1.2 Steuereinheit

P1.2.1 hydraulische Federgabel

P1.2.2 Vorbau

P1.2.3 Lenkstange

P1.2.4 Steuersatz

P1.2.5 Vorderrad

P1.3 Antriebseinheit

P1.3.1 Tretkurbel und Kettenblätter

P1.3.2 Kette

P1.3.3 Hinterrad

P1.3.4 Zahnkranzkassette

P1.4 Schalteinheit

P1.4.1 Umwerfer (Übersetzung vorne)

P1.4.2 Schaltwerk (Übersetzung hinten)

P1.4.3 2 Bowdenzüge (für Schaltwerk u...

P1.4.4 2 Schalthebel (für Schaltwerk ...

P1.5 Bremseinheit

P1.5.1 2 hydraulische Scheibenbremsen...

P1.5.2 2 Bremshebel (Vorderrad- und H...

P1.5.3 2 Hydraulikleitungen

P1.5.4 2 Bremsscheiben

P1.6 Sitzeinheit

P1.6.1 Patentsattelstütze und Sattels...

P1.6.2 Sattel

P1.7 Sonstige Komponenten

P1.7.1 Reflektoren

P1.7.2 Schutzbleche

P1.7.3 Beleuchtung

Anhang

252

AGGREGIERTE ANZAHL MODELLIERTER TRACELINKS ZWISCHEN FUNKTIONEN UND

PRODUKTELEMENTEN

F1.1 Vortrieb gewährleisten

F1.1.1 Fußkraft aufnehmen

F1.1.2 Antriebskraft leiten

F1.1.3 Kraft / Moment wandeln

F1.1.4 Rotationsmoment auf Straße übe...

F1.2 Verzögerung realisieren

F1.2.1 Handkraft aufnehmen

F1.2.2 Kraft leiten

F1.2.3 Bremskraft auf Hinterrad / Str...

F1.3 Fahrtrichtung ändern

F1.3.1 Steuersignal aufnehmen

F1.3.2 Richtungsänderung ausführen

F1.4 variable Übersetzung gewährleisten

F1.4.1 Fingerkraft aufnehmen

F1.4.2 Kraft leiten

F1.4.3 Übersetzung wechseln

F1.5 Sichtbarkeit gewährleisten

F1.5.1 unmittelbare Umgebung beleuchten

F1.5.2 Licht reflektieren

F1.6 Federung / Dämpfung

P1.1 Rahmen

P1.2 Steuereinheit

P1.2.1 hydrauli-

sche Federgabel

P1.2.2 Vorbau

P1.2.3 Lenkstange

P1.2.4 Steuersatz

P1.2.5 Vorderrad

P1.3 Antriebsein-

heit

P1.3.1 Tretkurbel

und Kettenblätter

P1.3.2 Kette

P1.3.3 Hinterrad

P1.3.4 Zahnkranz-

kassette

P1.4 Schalteinheit

P1.4.1 Umwerfer

(Übersetzung vor-

ne)

P1.4.2 Schaltwerk

(Übersetzung hin-

ten)

P1.4.3 2 Bowden-

züge (für Schalt-

werk u.

Anhang

253

F1.1 Vortrieb gewährleisten

F1.1.1 Fußkraft aufnehmen

F1.1.2 Antriebskraft leiten

F1.1.3 Kraft / Moment wandeln

F1.1.4 Rotationsmoment auf Straße übe...

F1.2 Verzögerung realisieren

F1.2.1 Handkraft aufnehmen

F1.2.2 Kraft leiten

F1.2.3 Bremskraft auf Hinterrad / Str...

F1.3 Fahrtrichtung ändern

F1.3.1 Steuersignal aufnehmen

F1.3.2 Richtungsänderung ausführen

F1.4 variable Übersetzung gewährleisten

F1.4.1 Fingerkraft aufnehmen

F1.4.2 Kraft leiten

F1.4.3 Übersetzung wechseln

F1.5 Sichtbarkeit gewährleisten

F1.5.1 unmittelbare Umgebung beleuchten

F1.5.2 Licht reflektieren

F1.6 Federung / Dämpfung

P1.4.4 2 Schalthe-

bel (für Schalt-

werk ...

P1.5 Bremseinheit

P1.5.1 2 hydrauli-

sche Scheiben-

brems.

P1.5.2 2 Bremshe-

bel (Vorderrad-

und H.

P1.5.3 2 Hydraulik-

leitungen

P1.5.4 2 Brems-

scheiben

P1.6 Sitzeinheit

P1.6.1 Patentsat-

telstütze und Sat-

tels...

P1.6.2 Sattel

P1.7 Sonstige

Komponenten

P1.7.1 Reflektoren

P1.7.2 Schutzble-

che

P1.7.3 Beleuch-

tung

Anhang

254

C. MATERIAL ZUR EVALUATION DER METHODE TRACELEGACY

TRACELINKS ZWISCHEN ANFORDERUNGS- UND FUNKTIONSHIERARCHIE DES FAHR-

RADS (VERGANGENES PROJEKT)

Vortrieb

Hinterradantrieb mittels Fußkurbel un...

Übersetzung mittels Kettenschaltung

Bremsen

Verschmutzungsrisiko minimieren

zuverlässiges Bremsen bei Nässe

muss mit Handkraft betrieben werden k...

geringer Verschleiß von Komponenten

sicheres Lenken / Manövrieren

Geländetauglichkeit

Unebenheiten im Gelände und im Fahrbe...

Verschiedene Übersetzungen

Beleuchtung vorsehen

Vortrieb gewährleisten

Rotationsmoment aufnehmen

Rotationsmoment leiten

Rotationsmoment wandeln

Rotationsmoment auf Straße übertragen

Verzögerung realisieren

Bremskraft aufnehmen

Kraft leiten

Bremskraft auf Straße übertragen

Fahrtrichtung ändern

Steuersignal aufnehmen

Signal in Richtungsänderung umsetzen

variable Übersetzung gewährleisten

Schaltkraft aufnehmen

Kraft leiten

Übersetzung wechseln

Sichtbarkeit gewährleisten

unmitelbare Umgebung beleuchten

Licht reflektieren

Federung / Dämpfung

Anhang

255

TRACELINKS ZWISCHEN ANFORDERUNGSHIERARCHIE UND PRODUKTSTRUKTUR DES

FAHRRADS (VERGANGENES PROJEKT)

Vortrieb

Hinterradantrieb mittels Fußkurbel un...

Übersetzung mittels Kettenschaltung

Bremsen

Verschmutzungsrisiko minimieren

zuverlässiges Bremsen bei Nässe

muss mit Handkraft betrieben werden k...

geringer Verschleiß von Komponenten

sicheres Lenken / Manövrieren

Geländetauglichkeit

Unebenheiten im Gelände und im Fahrbe...

Verschiedene Übersetzungen

Beleuchtung vorsehen

Rahmen

Steuereinheit

hydraulische Federgabel

Vorbau

Lenkstange

Steuersatz

Vorderrad

Antriebseinheit

Tretkurbel

Kette

Hinterrad

Zahnkranzkassette

Schalteinheit

Umwerfer (Übersetzung vorne)

Schaltwerk (Übersetzung hinten)

2 Bowdenzüge (für Schaltwerk und Umwe...

2 Schalthebel (für Schaltwerk und Umw...

Bremseinheit

2 hydraulische Scheibenbremsen

2 Bremshebel

2 Hydraulikleitungen

2 Bremsscheiben

Sitzeinheit

Patentsattelstütze und Sattelstange

Sattel

Sonstige Komponenten

Reflektoren

Schutzbleche

Beleuchtung

Anhang

256

TRACELINKS ZWISCHEN FUNKTIONSHIERARCHIE UND PRODUKTSTRUKTUR DES FAHR-

RADS (VERGANGENES PROJEKT)

Vortrieb gewährleisten

Rotationsmoment aufnehmen

Rotationsmoment leiten

Rotationsmoment wandeln

Rotationsmoment auf Straße übertragen

Verzögerung realisieren

Bremskraft aufnehmen

Kraft leiten

Bremskraft auf Straße übertragen

Fahrtrichtung ändern

Steuersignal aufnehmen

Signal in Richtungsänderung umsetzen

variable Übersetzung gewährleisten

Schaltkraft aufnehmen

Kraft leiten

Übersetzung wechseln

Sichtbarkeit gewährleisten

unmitelbare Umgebung beleuchten

Licht reflektieren

Federung / Dämpfung

Rahmen

Steuereinheit

hydraulische Fe-

dergabel

Vorbau

Lenkstange

Steuersatz

Vorderrad

Antriebseinheit

Tretkurbel

Kette

Hinterrad

Zahnkranzkasset-

Schalteinheit

Umwerfer (Über-

setzung vorne)

Schaltwerk (Über-

setzung hinten)

2 Bowdenzüge

(für Schaltwerk

und Umwe...

2 Schalthebel (für

Schaltwerk und

Umw...

Bremseinheit

2 hydraulische

Scheibenbremsen

2 Bremshebel

2 Hydraulikleitun-

gen

2 Bremsscheiben

Sitzeinheit

Patentsattelstütze

und Sattelstange

Sattel

Sonstige Kompo-

nenten

Anhang

257

Vortrieb gewährleisten

Rotationsmoment aufnehmen

Rotationsmoment leiten

Rotationsmoment wandeln

Rotationsmoment auf Straße übertragen

Verzögerung realisieren

Bremskraft aufnehmen

Kraft leiten

Bremskraft auf Straße übertragen

Fahrtrichtung ändern

Steuersignal aufnehmen

Signal in Richtungsänderung umsetzen

variable Übersetzung gewährleisten

Schaltkraft aufnehmen

Kraft leiten

Übersetzung wechseln

Sichtbarkeit gewährleisten

unmitelbare Umgebung beleuchten

Licht reflektieren

Federung / Dämpfung

Reflektoren

Schutzbleche

Beleuchtung

ANFORDERUNGSHIERARCHIE DES PEDELECS (AKTUELLES PROJEKT)

1 Antrieb

1.1 Pedal

1.2 E Motor

1.3 Schaltung

1.4 Höchstgeschwindigkeit

2 Geometrie

2.1 Reifen

2.2 Breite

2.3 Wendekreis

2.4 Höhe

2.5 Länge

3 Fahrer

3.1 Größe

3.2 Gewicht

3.3 Führerschein

4 Energie und Widerstand

4.1 Energieverbrauch ohne Motor Unterstützung

4.2 Energieverbrauch mit Motor Unterstützung

4.3 Reichweite

4.4 Rekuperation

4.5 Stop & Go

5 Ergonomie

5.1 Griff Hand Bremse

5.2 Sitz

5.3 Einstellung Höhe

6 Betriebsarten

6.1 Generator im Stehen

6.2 Generator beim Fahren

6.3 Motor beim Fahren

6.4 Muskelkraft beim Fahren

7 Szenarien

7.1 Manager

Anhang

258

7.1.1 Anzug

7.1.2 Wetter Schutz Haar

7.1.3 Wetter Schutz Körper

7.1.4 Erscheinung

7.2 Mutter

7.2.1 Transport des Kindes

7.2.2 Transport der Kinderutensilien

7.2.3 Wetter Schutz Haar

7.2.4 Wetter Schutz Körper

7.2.5 Kinder Sitz

7.3 Grill Team

7.3.1 Grill

7.3.2 Kühlbox

8 Beleuchtung

8.1 DIN 22958 Erfüllung

8.1.1 Rücklicht

8.1.1.1 Standlicht

8.1.2 Frontbeleuchtung

8.1.3 Reflektoren

8.2 Dynamo

8.3 Reflektoren Pedal

8.4 Energie Versorgung

8.5 Umfang des Beleuchtungssystems

9 Hupsystem

9.1 DIN 33946 Erfüllung

9.2 Lautsprecher System

10 Sicherheit

10.1 Charakteristik Bremse

10.2 Integrierte Kabel

10.3 Federung

10.4 Rückspiegel

10.5 Reifen

10.6 Anzahl Bremsen

10.7 Qualität Bremsen

10.8 Zuladung

11 Infotainment

11.1 Fixierung Cockpit

11.2 Fahr Modus

11.3 Energie Parameter

11.3.1 Batterie Status

11.3.2 Ladung

11.4 Kommunikation

12 Wartung

12.1 Reguläre Wartung

12.2 Ersatzteile

13 Kosten

13.1 Kosten Effizient

14 Zeitplan

14.1 Erstes Design Review

14.2 Zweites Design Review

14.3 Finales Design Review

14.4 Finaler Report

Anhang

259

FUNKTIONSHIERARCHIE DES PEDELECS (AKTUELLES PROJEKT)

1 Bewege Pedelec

1.1 Anpassung der mechanischen Leistung

1.2 Umwandlung Rotation in translatorische Bewegung

1.3 Einkuppeln / Auskuppeln

2 Unterstützung Fahren

2.1 Umwandlung mechanische Leistung

2.2 Verwaltung elekrische Leistung

2.3 Bereitstellung Energie für Licht System

3 Fahrer schützen

3.1 Reduktion Schwingungen

3.2 Beleuchtung

3.3 Bremsen

4 Verwaltung

4.1 System kontrollieren

4.1.1 Geschwindigkeit kontrollieren

4.1.2 Energie Speicher kontrollieren

4.1.3 Fahrmodus kontrollieren

4.2 Verwaltung Pedelec von Informationen

4.3 System Input empfangen

4.3.1 Pedal Signal empfangen

4.3.2 Fahrmodus Anweisung empfangen

4.3.3 Anweisung Bremse empfangen

4.3.4 Anweisung Gangwechsel empfangen

4.3.5 Anweisung Lenkung empfangen

4.3.6 Anweisung Beleuchtung empfangen

PRODUKTSTRUKTUR DES PEDELECS (AKTUELLES PROJEKT)

1 Rad

1.1 Hinterrad

1.1.1 Schwalbe Reifen

1.1.2 Schwalbe Schlauch

1.1.3 Alu Hinterrad

1.2 Vorderrad

1.2.1 Schwalbe Schlauch

1.2.2 Pegasus Reifen

1.2.3 Alu Vorderrad

2 Rahmen

2.1 Dach

2.1.1 Plexiglas

2.1.2 Vorderes Befestigungsschild

2.2 Grundrahmen

2.2.1 Alu Rohr

2.3 Stauraum

2.3.1 Alu Rohr

3 Sitz

3.1 Fahrer Sitz

3.2 Kinder Sitz

4 Lenkung

4.1 Lenker

4.1.1 Lenkerbügel

4.2 Griff

4.2.1 Moos-Gummi Griffbezüge

Anhang

260

4.3 Lenkerbügel

4.3.1 Lenkerbügel Tiller

5 Bremse

5.1 Scheibenbremse

5.1.1 Shimano Scheibenbremse

6 E Motor

7 Batterie / Rekuperation

8 Schaltung

9 Beleuchtung

9.1 Rücklicht

9.2 Frontleuchte

10 Hupe

11 Infotainment

12 Steuerung

VERWENDETE NEGATIVLISTE

gegen

ein

darf

oder

haben

eine

das

sind

hat

einem

dass

einen

der

muss

einer

über

müssen

ist

und

die

auf

kann

von

dürfen

bei

können

werden

sollte

mit

wird

sollte

mittels

ERGEBNIS DER ANWENDUNG VON TRACELEGACY OHNE STEMMING

Aktuelles Pedelec-Projekt

Vergangenes Fahrrad-Projekt

von

Beleuchtung

Bereitstellung Ener-

gie für Licht System

Beleuchtung vorse-

hen

Licht reflektieren

Umfang des Be-

leuchtungssystems

Bereitstellung Ener-

gie für Licht System

Beleuchtung vorse-

hen

Licht reflektieren

Umwandlung Rota-

tion in translatori-

sche Bewegung

Hinterrad

Rotationsmoment

auf Straße übertra-

gen

Hinterrad

Umwandlung Rota-

tion in translatori-

sche Bewegung

Alu Hinterrad

Rotationsmoment

auf Straße übertra-

gen

Hinterrad

Pedal Signal emp-

fangen

Vorderrad

Signal in Richtungs-

änderung umsetzen

Vorderrad

Pedal Signal emp-

fangen

Alu Vorderrad

Signal in Richtungs-

änderung umsetzen

Vorderrad

Anhang

261

Aktuelles Pedelec-Projekt

Vergangenes Fahrrad-Projekt

von

Griff Hand Bremse

Bremse

Bremsen

Bremseinheit

zuverlässiges Brem-

sen bei Nässe

Bremseinheit

muss mit Handkraft

betrieben werden

können

Bremseinheit

Beleuchtung

Beleuchtung vorse-

hen

Beleuchtung

Umfang des Be-

leuchtungssystems

Beleuchtung

Beleuchtung vorse-

hen

Beleuchtung

Charakteristik Brem-

Bremse

Bremsen

Bremseinheit

zuverlässiges Brem-

sen bei Nässe

Bremseinheit

Anzahl Bremsen

Bremse

Bremsen

Bremseinheit

zuverlässiges Brem-

sen bei Nässe

Bremseinheit

Qualität Bremsen

Bremse

Bremsen

Bremseinheit

zuverlässiges Brem-

sen bei Nässe

Bremseinheit

Griff Hand Bremse

Scheibenbremse

Bremsen

2 hydraulische

Scheibenbremsen

zuverlässiges Brem-

sen bei Nässe

2 hydraulische

Scheibenbremsen

Griff Hand Bremse

Shimano Scheiben-

bremse

Bremsen

2 hydraulische

Scheibenbremsen

zuverlässiges Brem-

sen bei Nässe

2 hydraulische

Scheibenbremsen

Charakteristik Brem-

Scheibenbremse

Bremsen

2 hydraulische

Scheibenbremsen

zuverlässiges Brem-

sen bei Nässe

2 hydraulische

Scheibenbremsen

Charakteristik Brem-

Shimano Scheiben-

bremse

Bremsen

2 hydraulische

Scheibenbremsen

zuverlässiges Brem-

sen bei Nässe

2 hydraulische

Scheibenbremsen

Anzahl Bremsen

Scheibenbremse

Bremsen

2 hydraulische

Scheibenbremsen

zuverlässiges Brem-

sen bei Nässe

2 hydraulische

Scheibenbremsen

Anzahl Bremsen

Shimano Scheiben-

bremse

Bremsen

2 hydraulische

Scheibenbremsen

zuverlässiges Brem-

sen bei Nässe

2 hydraulische

Scheibenbremsen

Qualität Bremsen

Scheibenbremse

Bremsen

2 hydraulische

Scheibenbremsen

zuverlässiges Brem-

sen bei Nässe

2 hydraulische

Scheibenbremsen

Qualität Bremsen

Shimano Scheiben-

bremse

Bremsen

2 hydraulische

Scheibenbremsen

zuverlässiges Brem-

sen bei Nässe

2 hydraulische

Scheibenbremsen

Anhang

262

ERGEBNIS DER ANWENDUNG VON TRACELEGACY MIT STEMMING

Aktuelles Projekt

Altes Projekt

von

Griff Hand Bremse

Bremsen

Bremskraft aufneh-

men

Bremsen

Bremskraft auf Stra-

ße übertragen

zuverlässiges Brem-

sen bei Nässe

Bremskraft auf Stra-

ße übertragen

muss mit Handkraft

betrieben werden

können

Bremskraft aufneh-

men

Beleuchtung

Beleuchtung vorse-

hen

unmittelbare Um-

gebung beleuchten

Beleuchtung

Anweisung Be-

leuchtung empfan-

gen

Beleuchtung vorse-

hen

unmittelbare Um-

gebung beleuchten

Frontbeleuchtung

Beleuchtung

Beleuchtung vorse-

hen

unmittelbare Um-

gebung beleuchten

Frontbeleuchtung

Anweisung Be-

leuchtung empfan-

gen

Beleuchtung vorse-

hen

unmittelbare Um-

gebung beleuchten

Umfang des Be-

leuchtungssystems

Beleuchtung

Beleuchtung vorse-

hen

unmittelbare Um-

gebung beleuchten

Charakteristik Brem-

Bremsen

Bremskraft aufneh-

men

Bremsen

Bremskraft auf Stra-

ße übertragen

zuverlässiges Brem-

sen bei Nässe

Bremskraft auf Stra-

ße übertragen

Anzahl Bremsen

Bremsen

Bremskraft aufneh-

men

Bremsen

Bremskraft auf Stra-

ße übertragen

zuverlässiges Brem-

sen bei Nässe

Bremskraft auf Stra-

ße übertragen

Qualität Bremsen

Bremsen

Bremskraft aufneh-

men

Bremsen

Bremskraft auf Stra-

ße übertragen

zuverlässiges Brem-

sen bei Nässe

Bremskraft auf Stra-

ße übertragen

Beleuchtung

unmittelbare Um-

gebung beleuchten

Beleuchtung

Bremsen

Bremse

Bremskraft aufneh-

men

Bremseinheit

Bremskraft aufneh-

men

2 Bremshebel

Bremskraft auf Stra-

ße übertragen

Bremseinheit

Bremskraft auf Stra-

ße übertragen

2 Bremsscheiben

Anhang

263

Aktuelles Projekt

Altes Projekt

von

Anweisung Bremse

empfangen

Bremse

Bremskraft aufneh-

men

Bremseinheit

Bremskraft aufneh-

men

2 Bremshebel

Bremskraft auf Stra-

ße übertragen

Bremseinheit

Bremskraft auf Stra-

ße übertragen

2 Bremsscheiben

Anweisung Be-

leuchtung empfan-

gen

Beleuchtung

unmittelbare Um-

gebung beleuchten

Beleuchtung

Charakteristik Brem-

Anweisung Bremse

empfangen

Bremsen

Bremskraft aufneh-

men

Bremsen

Bremskraft auf Stra-

ße übertragen

zuverlässiges Brem-

sen bei Nässe

Bremskraft auf Stra-

ße übertragen

Anzahl Bremsen

Anweisung Bremse

empfangen

Bremsen

Bremskraft aufneh-

men

Bremsen

Bremskraft auf Stra-

ße übertragen

zuverlässiges Brem-

sen bei Nässe

Bremskraft auf Stra-

ße übertragen

Qualität Bremsen

Anweisung Bremse

empfangen

Bremsen

Bremskraft aufneh-

men

Bremsen

Bremskraft auf Stra-

ße übertragen

zuverlässiges Brem-

sen bei Nässe

Bremskraft auf Stra-

ße übertragen

Griff Hand Bremse

Anweisung Bremse

empfangen

Bremsen

Bremskraft aufneh-

men

Bremsen

Bremskraft auf Stra-

ße übertragen

zuverlässiges Brem-

sen bei Nässe

Bremskraft auf Stra-

ße übertragen

muss mit Handkraft

betrieben werden

können

Bremskraft aufneh-

men

Umfang des Be-

leuchtungssystems

Bereitstellung Ener-

gie für Licht System

Beleuchtung vorse-

hen

Licht reflektieren

Umfang des Be-

leuchtungssystems

Anweisung Be-

leuchtung empfan-

gen

Beleuchtung vorse-

hen

unmittelbare Um-

gebung beleuchten

Antrieb

Umwandlung Rota-

tion in translatori-

sche Bewegung

Hinterantrieb mittels

Fußkurbel und Kette

Rotationsmoment

aufnehmen

Hinterantrieb mittels

Fußkurbel und Kette

Rotationsmoment

leiten

Hinterantrieb mittels

Fußkurbel und Kette

Rotationsmoment

wandeln

Hinterantrieb mittels

Fußkurbel und Kette

Rotationsmoment

auf die Straße über-

tragen

Anhang

264

Aktuelles Projekt

Altes Projekt

von

Schaltung

Anweisung Gang-

wechsel empfan-

gen

Übersetzung mittels

Kettenschaltung

Übersetzung wech-

seln

Betriebsarten

Bremsen

muss mit Handkraft

betrieben werden

können

Bremskraft aufneh-

men

Betriebsarten

Anweisung Bremse

empfangen

muss mit Handkraft

betrieben werden

können

Bremskraft aufneh-

men

Beleuchtung

Bereitstellung Ener-

gie für Licht System

Beleuchtung vorse-

hen

Licht reflektieren

Frontbeleuchtung

Bereitstellung Ener-

gie für Licht System

Beleuchtung vorse-

hen

Licht reflektieren

Sicherheit

Umwandlung Rota-

tion in translatori-

sche Bewegung

sicheres Lenken /

Manövrieren

Fahrtrichtung än-

dern

Sicherheit

Unterstützung Fah-

ren

sicheres Lenken /

Manövrieren

Fahrtrichtung än-

dern

Sicherheit

Umwandlung me-

chanische Leistung

sicheres Lenken /

Manövrieren

Fahrtrichtung än-

dern

Sicherheit

Fahrer Schützen

sicheres Lenken /

Manövrieren

Fahrtrichtung än-

dern

Sicherheit

Pedal Signal emp-

fangen

sicheres Lenken /

Manövrieren

Steuersignal auf-

nehmen

sicheres Lenken /

Manövrieren

Signal in Richtungs-

änderung umsetzen

Umwandlung Rota-

tion in translatori-

sche Bewegung

Rad

Rotationsmoment

auf Straße übertra-

gen

Hinterrad

Fahrtrichtung än-

dern

Vorderrad

Umwandlung Rota-

tion in translatori-

sche Bewegung

Hinterrad

Rotationsmoment

auf Straße übertra-

gen

Hinterrad

Umwandlung Rota-

tion in translatori-

sche Bewegung

Alu Hinterrad

Rotationsmoment

auf Straße übertra-

gen

Hinterrad

Umwandlung Rota-

tion in translatori-

sche Bewegung

Vorderrad

Fahrtrichtung än-

dern

Vorderrad

Umwandlung Rota-

tion in translatori-

sche Bewegung

Alu Vorderrad

Fahrtrichtung än-

dern

Vorderrad

Umwandlung Rota-

tion in translatori-

sche Bewegung

Vorderes Befesti-

gungsschild

Fahrtrichtung än-

dern

Vorderrad

Umwandlung Rota-

tion in translatori-

sche Bewegung

Lenker

Fahrtrichtung än-

dern

Lenkstange

Unterstützung Fah-

ren

Rad

Fahrtrichtung än-

dern

Vorderrad

Unterstützung Fah-

ren

Vorderrad

Fahrtrichtung än-

dern

Vorderrad

Anhang

265

Aktuelles Projekt

Altes Projekt

von

Unterstützung Fah-

ren

Alu Vorderrad

Fahrtrichtung än-

dern

Vorderrad

Unterstützung Fah-

ren

Vorderes Befesti-

gungsschild

Fahrtrichtung än-

dern

Vorderrad

Unterstützung Fah-

ren

Lenker

Fahrtrichtung än-

dern

Lenkstange

Umwandlung me-

chanische Leistung

Rad

Fahrtrichtung än-

dern

Vorderrad

Umwandlung me-

chanische Leistung

Alu Rad

Fahrtrichtung än-

dern

Vorderrad

Umwandlung me-

chanische Leistung

Vorderes Befesti-

gungsschild

Fahrtrichtung än-

dern

Vorderrad

Umwandlung me-

chanische Leistung

Lenker

Fahrtrichtung än-

dern

Lenkstange

Fahrer schützen

Rad

Fahrtrichtung än-

dern

Vorderrad

Fahrer schützen

Vorderrad

Fahrtrichtung än-

dern

Vorderrad

Fahrer schützen

Alu Vorderrad

Fahrtrichtung än-

dern

Vorderrad

Fahrer schützen

Vorderes Befesti-

gungsschild

Fahrtrichtung än-

dern

Vorderrad

Fahrer schützen

Lenker

Fahrtrichtung än-

dern

Lenkstange

Bremsen

Scheibenbremse

Bremskraft auf Stra-

ße übertragen

2 hydraulische

Scheibenbremsen

Bremsen

Shimano Scheiben-

bremse

Bremskraft auf Stra-

ße übertragen

2 hydraulische

Scheibenbremsen

Pedal Signal emp-

fangen

Rad

Signal in Richtungs-

änderung umsetzen

Vorderrad

Pedal Signal emp-

fangen

Vorderrad

Signal in Richtungs-

änderung umsetzen

Vorderrad

Pedal Signal emp-

fangen

Alu Vorderrad

Signal in Richtungs-

änderung umsetzen

Vorderrad

Pedal Signal emp-

fangen

Vorderes Befesti-

gungsschild

Signal in Richtungs-

änderung umsetzen

Vorderrad

Pedal Signal emp-

fangen

Lenker

Signal in Richtungs-

änderung umsetzen

Lenkstange

Steuersignal auf-

nehmen

Lenkstange

Anweisung Bremsen

empfangen

Scheibenbremse

Bremskraft auf Stra-

ße übertragen

2 hydraulische

Scheibenbremsen

Anweisung Bremsen

empfangen

Shimano Scheiben-

bremse

Bremskraft auf Stra-

ße übertragen

2 hydraulische

Scheibenbremsen

Anweisung Gang-

wechsel empfan-

gen

Hinterrad

Übersetzung wech-

seln

Schaltwerk (Über-

setzung hinten)

Anweisung Gang-

wechsel empfan-

gen

Alu Hinterrad

Übersetzung wech-

seln

Schaltwerk (Über-

setzung hinten)

Anweisung Gang-

wechsel empfan-

gen

Vorderrad

Übersetzung wech-

seln

Umwerfer (Überset-

zung vorne)

Anhang

266

Aktuelles Projekt

Altes Projekt

von

Anweisung Gang-

wechsel empfan-

gen

Alu Vorderrad

Übersetzung wech-

seln

Umwerfer (Überset-

zung vorne)

Anweisung Gang-

wechsel empfan-

gen

Vorderes Befesti-

gungsschild

Übersetzung wech-

seln

Umwerfer (Überset-

zung vorne)

Griff Hand Bremse

Bremse

Bremsen

Bremseinheit

Bremsen

2 Bremshebel

Bremsen

2 Bremsscheiben

zuverlässiges Brem-

sen bei Nässe

Bremseinheit

zuverlässiges Brem-

sen bei Nässe

2 Bremsscheiben

muss mit Handkraft

betrieben werden

können

Bremseinheit

muss mit Handkraft

betrieben werden

können

2 Bremshebel

Beleuchtung

Beleuchtung vorse-

hen

Beleuchtung

Umfang des Be-

leuchtungssystems

Beleuchtung

Beleuchtung vorse-

hen

Beleuchtung

Charakteristik Brem-

Bremse

Bremsen

Bremseinheit

Bremsen

2 Bremshebel

Bremsen

2 Bremsscheiben

zuverlässiges Brem-

sen bei Nässe

Bremseinheit

zuverlässiges Brem-

sen bei Nässe

2 Bremsscheiben

Anzahl Bremsen

Bremse

Bremsen

Bremseinheit

Bremsen

2 Bremshebel

Bremsen

2 Bremsscheiben

zuverlässiges Brem-

sen bei Nässe

Bremseinheit

zuverlässiges Brem-

sen bei Nässe

2 Bremsscheiben

Qualität Bremsen

Bremse

Bremsen

Bremseinheit

Bremsen

2 Bremshebel

Bremsen

2 Bremsscheiben

zuverlässiges Brem-

sen bei Nässe

Bremseinheit

zuverlässiges Brem-

sen bei Nässe

2 Bremsscheiben

Frontbeleuchtung

Beleuchtung

Beleuchtung vorse-

hen

Beleuchtung

Griff Hand Bremse

Scheibenbremse

Bremsen

2 hydraulische

Scheibenbremsen

zuverlässiges Brem-

sen bei Nässe

2 hydraulische

Scheibenbremsen

Anhang

267

Aktuelles Projekt

Altes Projekt

von

Griff Hand Bremse

Shimano Scheiben-

bremse

Bremsen

2 hydraulische

Scheibenbremsen

zuverlässiges Brem-

sen bei Nässe

2 hydraulische

Scheibenbremsen

Charakteristik Brem-

Scheibenbremse

Bremsen

2 hydraulische

Scheibenbremsen

zuverlässiges Brem-

sen bei Nässe

2 hydraulische

Scheibenbremsen

Charakteristik Brem-

Shimano Scheiben-

bremse

Bremsen

2 hydraulische

Scheibenbremsen

zuverlässiges Brem-

sen bei Nässe

2 hydraulische

Scheibenbremsen

Anzahl Bremsen

Scheibenbremse

Bremsen

2 hydraulische

Scheibenbremsen

zuverlässiges Brem-

sen bei Nässe

2 hydraulische

Scheibenbremsen

Anzahl Bremsen

Shimano Scheiben-

bremse

Bremsen

2 hydraulische

Scheibenbremsen

zuverlässiges Brem-

sen bei Nässe

2 hydraulische

Scheibenbremsen

Qualität Bremsen

Scheibenbremse

Bremsen

2 hydraulische

Scheibenbremsen

zuverlässiges Brem-

sen bei Nässe

2 hydraulische

Scheibenbremsen

Qualität Bremsen

Shimano Scheiben-

bremse

Bremsen

2 hydraulische

Scheibenbremsen

zuverlässiges Brem-

sen bei Nässe

2 hydraulische

Scheibenbremsen

Betriebsarten

Bremse

muss mit Handkraft

betrieben werden

können

2 Bremshebel

muss mit Handkraft

betrieben werden

können

Bremseinheit

Sicherheit

Lenker

sicheres Lenken /

Manövrieren

Lenkstange