BERICHTE AUS DEM PRODUKTIONSTECHNISCHEN ZENTRUM BERLIN

Größe: px
Ab Seite anzeigen:

Download "BERICHTE AUS DEM PRODUKTIONSTECHNISCHEN ZENTRUM BERLIN"

Transkript

1

2 BERICHTE AUS DEM PRODUKTIONSTECHNISCHEN ZENTRUM BERLIN Grischa Beier Verwendung von Traceability-Modellen zur Unterstützung der Entwicklung technischer Systeme Herausgeber: Prof. Dr.-Ing. R. Stark Prof. Dr.-Ing. R. Jochem Prof. Dr.-Ing. H. Kohl Prof. Dr.-Ing. J. Krüger Prof. Dr.-Ing. M. Rethmeier Prof. Dr.-Ing. G. Seliger Prof. Dr. h. c. Dr.-Ing. E. Uhlmann INSTITUT PRODUKTIONSANLAGEN UND KONSTRUKTIONSTECHNIK INSTITUT WERKZEUGMASCHINEN UND FABRIKBETRIEB TECHNISCHE UNIVERSITÄT BERLIN

3 Kontaktadresse: Fraunhofer-Institut für Produktionsanlagen und Konstruktionstechnik IPK Pascalstraße Berlin Telefon Fax URL Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar. ISBN (Print): Zugl.: Berlin, TU, Diss., 2013 D 83 Druck: Mediendienstleistungen des Fraunhofer-Informationszentrum Raum und Bau IRB, Stuttgart Für den Druck des Buches wurde chlor- und säurefreies Papier verwendet. by FRAUNHOFER VERLAG, 2014 Fraunhofer-Informationszentrum Raum und Bau IRB Postfach , Stuttgart Nobelstraße 12, Stuttgart Telefon Fax URL Alle Rechte vorbehalten Dieses Werk ist einschließlich aller seiner Teile urheberrechtlich geschützt. Jede Ver wertung, die über die engen Grenzen des Urheberrechtsgesetzes hinausgeht, ist ohne schriftliche Zustimmung des Verlages unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikro ver filmungen sowie die Speiche rung in elektronischen Systemen. Die Wiedergabe von Warenbezeichnungen und Handelsnamen in diesem Buch berechtigt nicht zu der An nahme, dass solche Bezeichnungen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und deshalb von jedermann benutzt werden dürften. Soweit in diesem Werk direkt oder indirekt auf Gesetze, Vorschriften oder Richtlinien (z.b. DIN, VDI) Bezug genommen oder aus ihnen zitiert worden ist, kann der Verlag keine Gewähr für Richtigkeit, Vollständigkeit oder Aktualität übernehmen.

4 Verwendung von Traceability-Modellen zur Unterstützung der Entwicklung technischer Systeme vorgelegt von Grischa Beier Dipl.-Ing. aus Berlin 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: Univ.-Prof. Dr.-Ing. Jörg Krüger 1. Gutachter: Univ.-Prof. Dr.-Ing. Rainer Stark 2. Gutachter: Univ.-Prof. Dr.-Ing. Christian Weber Tag der wissenschaftlichen Aussprache: Berlin 2014 D83

5

6 ABSTRACT When developing complex mechatronic products a big number of digital product-defining artefacts is generated in highly specialized software tools. Even experienced developers have difficulties to fully understand the interdependencies between these artefacts. It is the primary aim of traceability to make these interdependencies explicit by using information technology in order to support product development. Currently there are two main obstacles for the broader use of traceability in industrial practice: the high effort required to capture the traceability model and the unclear benefits of its usage. The latter is the main motivation for this thesis: namely to develop innovative concepts for the usage of traceability information in the development of mechatronic products. To address this challenge, the present thesis is investigating how established development methods can be supported by artefact-spanning traceability models. For a selection of these methods (e. g. FMEA and House of Quality) concepts of how they can be assisted with traceability information are elaborated. A software prototype was implemented for the method House of Quality in order to exemplarily verify the developed concept. A further benefit of traceability information is that its visualization supports developers in comprehending complex systems. Therefore a concept for visualizing artefact-spanning traceability information is developed that also takes the specifics of mechatronics into account. It is evaluated through a user study and implemented in the prototypical visualization software Ariadne s Eye, which itself is compared with conventional visualization solutions through established readability metrics. Traceability can also play an important role in engineering change management, since traceability models allow for an efficient analysis of potential change impacts. For that reason a traceability-based impact analysis method for mechatronic products is developed, whose efficiency is verified through a user study. This method is then combined with Ariadne s Eye to a visual, dialogue-based assistance system for impact analyses. Another user study shows that the efficiency and user acceptance of the developed solution is significantly better than impact analyses based on matrix- or list-visualization. In this manner the present thesis offers a variety of traceability usage solutions for different phases of the development process for mechatronic products. It therefore provides a significant contribution in promoting the introduction of traceability in industry. iii

7

8 ZUSAMMENFASSUNG Bei der Entwicklung komplexer mechatronischer Produkte wird in spezialisierten Software- Werkzeugen eine Vielzahl digitaler Produkt-beschreibender Informationsartefakte generiert. Selbst erfahrene Entwickler können die inhaltlichen Zusammenhänge zwischen diesen Artefakten nicht vollständig erfassen. Das Ziel von Traceability ist es, diese Systemzusammenhänge zur Unterstützung der Entwickler informationstechnisch zu explizieren. Derzeit stehen dem Einsatz von Traceability in der Praxis jedoch zwei wesentliche Hindernisse entgegen: die aufwändige Erstellung von Traceability-Modellen sowie deren unklarer Mehrwert für die Unternehmen. Die Entwicklung neuartiger Nutzenoptionen von Traceability für die Mechatronik-Entwicklung ist das übergeordnete Ziel der vorliegenden Arbeit. Dazu wird zunächst untersucht, wie etablierte Methoden der Produktentwicklung durch Traceability-Modelle unterstützt werden können. Für ausgewählte Entwicklungsmethoden (u. a. FMEA und House of Quality) wird die Anreicherung mit Traceability-Informationen auf konzeptioneller Ebene beschrieben und die Wirksamkeit der Unterstützung mittels einer prototypischen Software-Implementierung exemplarisch für das House of Quality nachgewiesen. Ein weiterer Vorteil von Traceability ist, dass deren Visualisierung, durch das Abbilden der Zusammenhänge, Entwicklern das Verständnis komplexer Systeme erleichtert. Daher wird im Rahmen der Arbeit ein Traceability-Visualisierungskonzept hergeleitet, das den Spezifika der Mechatronik Rechnung trägt, und dessen Eignung durch Nutzerstudien abgesichert. Das Konzept wird im Visualisierungswerkzeug Ariadne s Eye prototypisch implementiert. Dessen Evaluierung auf Basis etablierter Lesbarkeitsmetriken ergibt im Vergleich zu einer konventionellen Visualisierung erhebliche Vorteile. Auch im Änderungsmanagement kommt der Traceability eine große Bedeutung zu, weil ein existierendes Traceability-Modell effiziente Auswirkungsanalysen von Änderungen (sog. Impact Analysen) ermöglicht. Daher wird eine Methode zur Traceability-basierten Impact Analyse für mechatronische Produkte hergeleitet und deren Wirksamkeit mittels einer Nutzerstudie abgesichert. Anschließend wird die Methode mit Ariadne s Eye zu einem visuellen Impact-Analyse-Assistenzsystem kombiniert. In einer weiteren Nutzerstudie wird belegt, dass die Effizienz und Nutzerakzeptanz von Impact Analysen auf Basis der entwickelten Visualisierung alternativen Bewertungsmethoden signifikant überlegen ist. In der vorliegenden Arbeit wird somit ein breites Spektrum an Lösungen für die Verwendung von Traceability-Modellen in unterschiedlichen Phasen der Produktentwicklung aufgezeigt. Sie leistet somit einen wichtigen Forschungsbeitrag auf dem Weg, die Hemmschwelle zur Einführung von Traceability in Unternehmen weiter zu senken. v

9

10 GELEITWORT DER HERAUSGEBER Die Schriftenreihe Berichte aus dem Produktionstechnischen Zentrum Berlin wird von den Professoren der im Produktionstechnischen Zentrum Berlin dauerhaft angelegten Fach- und Forschungsgebiete der TU Berlin gemeinsam herausgegeben. Zweck der Schriftenreihe ist es, die auf den Gebieten der Produktentstehung, Produktionstechnik und Informationstechnik erarbeiteten Forschungsergebnisse einer breiten Fachöffentlichkeit zugänglich zu machen. In der Schriftenreihe erscheinen in erster Linie die an den Fachgebieten des Instituts für Werkzeugmaschinen und Fabrikbetrieb (IWF) der TU Berlin und am Fraunhofer-Institut für Produktionsanlagen und Konstruktionstechnik entstandenen Dissertationen. Daneben werden aber auch andere Forschungsberichte, die in den thematischen Rahmen passen und von allgemeinem 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. Beier beschäftigt sich mit der Erforschung und der Evaluierung der nächsten Generation von Methoden und Werkzeugen des Traceability Engineering (Entwicklungsvorgehen der aktiven Nutzung durchgängiger Nachverfolgbarkeit zwischen Modellartefakten), einer entscheidenden Teildisziplin des Systems Engineering und somit Wegbereiter der modernen disziplinübergreifenden Produktentwicklung. In der vorliegenden Arbeit wird aufgezeigt, dass die Erstellung eines Traceability-Modells nicht nur gesetzliche Bestimmungen erfüllt, sondern auch eine Vielzahl bestehender Prozesse in der Produktentwicklung unterstützen kann. Traceability-basierte Methoden werden erforscht und entwickelt, so dass Anwenderunternehmen einen Mehrwert aus der Erfassung und Dokumentation von Abhängigkeiten ziehen können, um den notwendigen Aufwand der Erstellung von Traceability Modellen zumindest auszugleichen. Dem Autor der vorliegenden Arbeit ist es im besonderen Maße gelungen, eine durchgängige wissenschaftliche Vorgehensweise zu etablieren, welche sich ausgehend von dem Erkennen der Probleme in der Praxis und den Defiziten des Standes der Technik, über daraus abgeleitete konkrete Anforderungen an verbesserte Modellierungsumgebungen, die sich anschließende Hypothesen- und konzeptionelle Modellbildung sowie die Entwicklung einer Architektur und Implementierung des Softwarepaketes bis hin zu einer ersten Evaluierung im Rahmen von mehreren wissenschaftlichen Nutzerstudien erstreckt. Berlin, Januar 2014 Rainer Stark vii

11

12 DANKSAGUNG DES AUTORS Dem Brei sagt man nach, viele Köche verdürben ihn. Ich hoffe, gemeinsam mit den vielen Köchen, welche zur Entstehung dieser Arbeit beigetragen haben und denen ich an dieser Stelle danken möchte, diesem Schicksal entronnen zu sein. Diese Dissertation entstand während meiner Tätigkeit am Geschäftsfeld Virtuelle Produktentstehung des Fraunhofer-Instituts für Produktionsanlagen und Konstruktionstechnik (IPK) und wurde wissenschaftlich durch den Leiter des Fachgebiets Industrielle Informationstechnik der Technischen Universität Berlin Prof. Dr.-Ing. Rainer Stark betreut. Ihm danke ich zudem für die zahllosen Denkanstöße sowie das stete Anmahnen, den ingenieurmäßigen Anwendungskontext zu berücksichtigen. Für die Begutachtung meiner Arbeit sowie die Übernahme des Vorsitzes der Prüfungskommission möchte ich mich bei Prof. Dr.-Ing. Christian Weber und Prof. Dr.-Ing. Jörg Krüger herzlich bedanken. Wenn jede Mannschaft nur so gut ist wie ihr Gegner, gilt dies bei Forschern wohl eher für das eigene Team. Daher möchte ich mich ganz herzlich bei meinen Kollegen bedanken, die mir in etlichen Situationen eine große Hilfe und Quell kritisch-konstruktiver Inspiration waren. Aber auch meinen studentischen Helfern gebührt großer Dank: ohne Euch, Robert und Michel, wäre die Durchführung der Nutzerstudien und die Implementierung der Softwareprototypen so nicht möglich gewesen. Ganz besonders dankbar bin ich jedoch für die Unterstützung von Asmus, mit dem ich in zahllosen Forschungssessions Ideen hin und her wälzen, verwerfen und (deutlich seltener) verfeinern durfte, und von Moni, die unermüdlich dafür Sorge trug, dass ich u. a. den Mut nie sinken ließ. Meinen anderen Freunden möchte ich dafür Dank sagen, dass sie selbst nach der x-ten Absage nicht müde wurden zu fragen, ob ich nicht Zeit für einen gemeinsamen Saft hätte. Ich hoffe inständig, diese Zeit nun hinter mir gelassen zu haben und zukünftig auf wahrhaft freundschaftliche Weise Kompensation leisten zu können. Was jedoch wäre ich ohne meine Familie? Das kann zwar niemand wissen, aber trotzdem bin ich mehr als dankbar, meine Mischpoche zu haben. Meinen Eltern möchte ich dafür danken, dass sie mir eine so behütete und sorgenfreie Jugend ermöglicht sowie beigebracht haben, kritisch und selbständig zu denken. Das ist ein hohes Gut und absolutes Privileg, was ich sehr zu schätzen weiß. Unterstützt wurden sie dabei insbesondere von zwei ganz Großen: Oma Hella und Opa Werner. Ich bedaure zutiefst, den erfolgreichen Abschluss dieser Arbeit nicht mehr mit Euch feiern zu können - denn sie ist Euch gewidmet! Berlin, im Januar 2014 Grischa Beier ix

13

14 INHALTSVERZEICHNIS ABSTRACT... III ZUSAMMENFASSUNG... V GELEITWORT DER HERAUSGEBER... VII DANKSAGUNG DES AUTORS... IX INHALTSVERZEICHNIS... XI AKRONYMVERZEICHNIS...XVII ABBILDUNGSVERZEICHNIS... XIX TABELLENVERZEICHNIS... XXV 1. EINLEITUNG UND ZIELSETZUNG Ausgangssituation und Motivation Zielsetzung der Arbeit Forschungsfragen Methodisches Vorgehen und Aufbau der Arbeit GRUNDLAGEN DER ENTWICKLUNG MECHATRONISCHER PRODUKTE Einführung und Definition gängiger Begriffe aus der Produktentwicklung Artefakte in der Produktentwicklung Anforderungsspezifikationen Funktionsbeschreibungen Verhaltensmodelle Produktstruktur Weitere Artefakte Hierarchische Struktur der Artefakte Vorgehensmodelle in der Produktentwicklung Theoretische Vorgehensmodelle Produktentwicklung in der industriellen Praxis Zusammenfassung, Diskussion und Schlussfolgerungen TRACEABILITY-GRUNDLAGEN Einführung in die Traceability-Modellierung Motivation der Notwendigkeit von Traceability Traceability-Grundbegriffe und -Definitionen xi

15 Inhaltsverzeichnis Ursprung und zeitliche Weiterentwicklung der Traceability Phasen der Traceability-Modellierung Planung von Traceability Traceability-Eigenschaften Tracelink-Eigenschaften Erfassung von Tracelinks Modellierungsunterstützung Tracelink-Erfassung in der Software-Entwicklung Erfassung von Tracelinks am Beispiel eines mechatronischen Assistenzsystems Werkzeuge und Methoden zur Traceability-Modellierung - Stand der Wissenschaft und Technik Traceability-basierte Spezial-Werkzeuge Anforderungsmanagement-Werkzeuge PLM-Werkzeuge Zusammenfassung Traceability-Modellierungswerkzeug ModelTracer Zusammenfassung und Diskussion TRACEABILITY-BASIERTE UNTERSTÜTZUNG ETABLIERTER METHODEN DER PRODUKTENTWICKLUNG Traceability-unterstützbare Methoden für die Produktentwicklung und ihre Umsetzung im Stand der Wissenschaft und Technik Produkt-bezogene Methoden und ihre Unterstützbarkeit durch Traceability-Informationen Prozess-bezogene Methoden und ihre Unterstützbarkeit durch Traceability-Informationen Zusammenfassung und Diskussion Detaillierung und prototypische Implementierung der Methode Traceability-unterstütztes House of Quality Zusammenfassung und Diskussion GRAPHISCHE DARSTELLUNG VON TRACEABILITY-MODELLEN Grundlagen der interaktiven, visuellen Repräsentation von Traceability- Modellen Motivation und Notwendigkeit der visuellen Repräsentation von Traceability-Modellen Terminologie und theoretische Grundlagen der Informationsvisualisierung Anforderungen an die Traceability-Visualisierung aus Sicht der Produktentwicklung xii

16 Inhaltsverzeichnis 5.2. Herausforderungen bei der graphischen Abbildung von Traceability- Modellen Stand der Wissenschaft und Technik Existierende Werkzeuge zur Visualisierung von Traceability- Informationen Analyse vergleichender Studien der Repräsentationsformen zur Visualisierung von Traceability-Informationen Zusammenfassung und Diskussion Hypothese 1 zur verbesserten Lesbarkeit von Traceability-Modellen in Node-Link-Diagrammen Herleitung des interaktiven Traceability-Visualisierungskonzepts Ariadne s Eye Evaluierung des Visualisierungskonzepts Ariadne s Eye: Nutzerstudie Lesbarkeit der Anordnung Studienteilnehmer und -materialien Studiendesign Durchführung Ergebnisse und Auswertung Diskussion und Schlussfolgerung Weiterentwicklung des Visualisierungskonzepts Verbesserung der Effizienz der Flächennutzung Modifikation der Visualisierungsobjekte Herleitung eines Interaktionskonzepts für Ariadne s Eye Implementierung des Prototyps Ariadne s Eye Vergleichende Evaluierung der Lesbarkeit: Ariadne s Eye vs. Forcedirected-Layout Zusammenfassung und Diskussion TRACEABILITY-BASIERTE IMPACT-ANALYSE-METHODE FÜR DIE ENTWICKLUNG MECHATRONISCHER PRODUKTE Grundlagen des Änderungsmanagements im Systems Engineering Theoretische Grundlagen der Impact Analyse Definitionen zur Impact Analyse Grundbegriffe der Mengenlehre Metriken zur Messung der Qualität von Impact Analysen Existierende Impact-Analyse-Ansätze - Stand der Wissenschaft Impact Analyse in der Softwareentwicklung Impact Analyse Bei der Entwicklung mechatronischer Systeme Zusammenfassung und Diskussion existierender Impact-Analyse- Ansätze Hypothese 2 zur Impact Analyse für die Entwicklung mechatronischer Produkte xiii

17 Inhaltsverzeichnis 6.5. Herleitung einer Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte Grundannahmen zur Impact-Analyse-Methode Hierarchische Transitivität bei der Impact Analyse Berücksichtigung der flexiblen Tracelink-Modellierungstiefe bei der Impact Analyse Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte Zusammenfassung und Diskussion Nutzerstudie Wirksamkeit des Impact-Analyse-Algorithmus Studienteilnehmer und -materialien Studiendesign Grundannahmen Durchführung Ergebnisse und Auswertung Diskussion und Schlussfolgerung hinsichtlich der Wirksamkeit des Impact-Analyse-Algorithmus Zusammenfassung und Diskussion SOFTWARE-PROTOTYP ZUR VISUELLEN IMPACT ANALYSE Stand der Wissenschaft und Technik für die visuelle Unterstützung von Impact Analysen Hypothese 3 zur graphischen Unterstützung der Artefakt-übergreifenden Impact Analyse Nutzerstudie zum Vergleich der Anwendungseffizienz dreier Visualisierungskonzepte für das Änderungsmanagement Studienteilnehmer und materialien Studiendesign Durchführung Ergebnisse und Auswertung Diskussion und Schlussfolgerung Interaktions- und Visualisierungskonzept für einen dialogbasierten Impact-Analyse-Assistenten Anforderungen an den dialogbasierten Impact-Analyse-Assistenten Funktionales Konzept für einen dialogbasierten Impact-Analyse- Assistenten Prototypische Implementierung des dialogbasierten Impact-Analyse- Assistenten Zusammenfassung und Diskussion ZUSAMMENFASSUNG UND AUSBLICK Zusammenfassung der Ergebnisse der Arbeit xiv

18 Inhaltsverzeichnis Unterstützung etablierter Methoden der Produktentwicklung durch Traceability Graphische Darstellung von Traceability-Modellen Tracelink-basierte Impact-Analyse Visuelle Unterstützung bei der Durchführung von Impact Analysen Grenzen der entwickelten Methoden und korrespondierende offene Forschungsfragen Fazit LITERATURVERZEICHNIS GLOSSAR ANHANG Anhang A1: Verknüpfte Beispielartefakte Fahrrad, Klimaanlage und Pedelec Anhang A2: Material zur Studie Lesbarkeit der Anordnung Anhang A3: Screenshots des Prototyps Ariadne s Eye Anhang A4: Material zur Studie Wirksamkeit des Impact-Analyse-Algorithmus Anhang A5: Material zur Studie Vergleich der Anwendungseffizienz dreier Visualisierungskonzepte xv

19

20 AKRONYMVERZEICHNIS Akronym AF AIS CAD CAE CAM CATIA CIS CNC CPM CPS DIS DMM DMU DRM DSM E/E EIS ENOVIA ERP FDMU FEM Ausgeschriebene Bedeutung Artefakt Actual Impact Set Computer-Aided Design Computer-Aided Engineering Cambridge Advanced Modeller Computer Aided Three-dimensional Interactive Application; 3D-CAD- und CAx-Werkzeug aus der V6-Suite von Dassault Systèmes Candidate Impact Set Computerized Numerical Control Change Prediction Method Cyber-physisches System Discovered Impact Set Domain Mapping Matrices Digital Mock-Up Design Research Methodology Design Structure Matrix Elektrik / Elektronik Estimated Impact Set Produktdatenmanagement-Werkzeug der V6-Suite von Dassault Systèmes Enterprise-Resource-Planning Functional Digital Mock-Up Finite-Elemente-Methode xvii

21 Akronymverzeichnis Akronym FMEA FPIS FTA HoQ INCOSE ISO IT MDM NX OEM ORM PDD PDM PLM QFD RCP ReqIF RPZ SIS SPSS SysML TLX UID UML VDI Ausgeschriebene Bedeutung Failure Mode and Effects Analysis False-Positive Impact Set Fault Tree Analysis House of Quality International Council on Systems Engineering International Organization for Standardization Informationstechnik Multi Domain Matrix 3D-CAD-Modellierungswerkzeug von Siemens PLM Original Equipment Manufacturer Object-Relational Mapping Property-Driven Development/Design Produktdatenmanagement Product Lifecycle Management Quality-Function-Deployment Rapid Control Prototyping Requirements Interchange Format Risikoprioritätszahl Starting Impact Set Statistik- und Analyse-Software Systems Modeling Language Task-Load-Index Unique Identifier Unified Modeling Language Verein Deutscher Ingenieure xviii

22 ABBILDUNGSVERZEICHNIS Abbildung 1: Isolierte Verwaltung von Produktinformationen im Unternehmen... 2 Abbildung 2: Zeitliche Entwicklung von Rückrufaktionen [BERTSCHE ET AL. 2009, S. 5]... 4 Abbildung 3: Aufbau der Arbeit und inhaltlicher Zusammenhang der Kernkapitel... 7 Abbildung 4: Abbildung 5: Abbildung 6: Schematische Darstellung der methodischen Vorgehensweise und der zugehörigen Kapitel... 9 Abstraktes Artefakt-Metamodell und reduzierte Instanziierung am Beispiel von Anforderungen und Produktstruktur einer KFZ- Klimaanlage Schematische Darstellung einer Funktionsstruktur mit drei horizontalen Hierarchieebenen als Blockdiagramm [PAHL ET AL. 2007, S. 45] Abbildung 7: Schematische Darstellung der hierarchischen Transitivität Abbildung 8: In der Produktentwicklung zu durchlaufendes V-Modell als Makrozyklus [VDI-Richtlinie 2206, S. 29] Abbildung 9: Systems-Engineering-Prozess [Department of Defense 2001, S. 31] Abbildung 10: Zuordnung der einzelnen Teile der ISO zum klassischen V- Modell [ISO , S. vi] Abbildung 11: Abbildung 12: Abbildung 13: Schematische Darstellung der Matrixorganisation bei einem Automobilhersteller [KÖNIGS ET AL. 2012, S. 925] Grober Entwicklungsprozess in der Automobilindustrie [WEBER 2009, S. 12] Schematische Darstellung der Abhängigkeiten zwischen unterschiedlichen Artefakten der Produktentwicklung Abbildung 14: Mögliche Granularitäten in der Traceability-Modellierung Abbildung 15: Traceability zwischen den Artefakten zur Beschreibung des Toten- Winkel-Assistenzsystems Abbildung 16: Unterscheidung der Abhängigkeitsmatrizen DSM, DMM und MDM Abbildung 17: Abbildung 18: Abbildung 19: Befüllen der Abhängigkeitsmatrizen DSM (links) und DMM (rechts) in LOOMEO Workbook im CAM zur Verknüpfung zweier DSM s (hier Anforderungs- und Funktions-DSM) in einer MDM Erzeugung eines Tracelinks durch Auswahl des Quellelements (links) und des Zielelements (rechts) im Formal Module xix

23 Abbildungsverzeichnis Abbildung 20: Abbildung 21: Abbildung 22: Darstellung der Erfassung eines Tracelinks zwischen Verhaltensmodell und korrespondierendem Produktstrukturelement in V Grundlegendes Verknüpfungskonzept des Systems-Engineering- Ansatzes in Teamcenter 9.1 [Siemens PLM Software Inc. 2012, S. 1 43] Integrierte Systementwicklung unter Verwendung von Traceability im Mechatronics Concept Designer [Siemens PLM Software Inc. 2010, S. 1] Abbildung 23: Modellierungskonzept des Werkzeugs ModelTracer Abbildung 24: Datenmodell des ModelTracers Abbildung 25: Screenshot des Werkzeugs ModelTracer Abbildung 26: Schematische Darstellung der EcoTracing-Methode Abbildung 27: Analyse und Restrukturierung von Produktstrukturen mittels Clustering in einer Traceability-Matrix [LINDEMANN ET AL. 2009, S. 90] Abbildung 28: Unterstützung der FMEA-Methode durch Traceability Abbildung 29: Schematisches Konzept des Traceability-unterstützten Progress Monitorings Abbildung 30: Ermittlung des Status einer Anforderung mittels Traceability Abbildung 31: Abbildung 32: Schematische Darstellung OEM-Zulieferer-Kommunikation mittels Traceability Stufenmodell der Traceability-Granularität je Artefakt zur Unterstützbarkeit ausgewählter Entwicklungsmethoden Abbildung 33: Auswahl des Kundenwünsche-Artefakts (hier: Anforderungsliste) Abbildung 34: Auswahl des Produkteigenschaften-Artefakts (hier: Funktionsstruktur) Abbildung 35: Manuelle Auswahl der zu betrachtenden Anforderungen (Schritt 3 linke Box) und automatische Zuordnung von Funktionen (Schritt 4 rechte Box) Abbildung 36: Abbildung 37: Wichtung ausgewählter Anforderungen auf vordefinierter fünfstufiger Skala Bewertung des Erfüllungsgrades auf vordefinierter vierstufiger Skala Abbildung 38: Ermittlung von Priorisierungsvorschlägen für die Produktfunktionen Abbildung 39: Abbildung 40: Abbildung 41: Abbildung 42: Wesentliche Schritte der House-of-Quality-Methode und deren Unterstützbarkeit durch Traceability-Informationen Abbildung der Zusammenhänge zwischen den Artefakten eines Toter-Winkel-Warnsystems und deren Disziplin-Zugehörigkeit Identifikation der Steuergeräte für die Funktion "Toter-Winkel- Warnung" Identifikation der vom Steuergerät AX23-E9 zu realisierenden Funktionen xx

24 Abbildungsverzeichnis Abbildung 43: Abbildung 44: Repräsentationsformen für die Traceability-Visualisierung - Liste (links), Abhängigkeitsmatrix (mitte) und Node-Link-Diagramm Darstellung eines Space-filling- (links), eines Node-Link-Diagramms (mitte) und eines Compound Graphen (rechts) Abbildung 45: Traceability-Visualisierungsmöglichkeiten in DOORS Abbildung 46: Visualisierung verknüpfter Elemente in TraceLine, wobei diese spaltenweise nach Artefakten sortiert sind Abbildung 47: Visualisierungsoptionen in Reqtify [ChiasTek Sales 2011] Abbildung 48: Visualisierung mit DEPNET [OUERTANI UND GZARA 2008, S. 11] Abbildung 49: Abbildung 50: Abbildung 51: Abbildung 52: Abbildung 53: Abbildung der Tracelinks mittels Node-Link-Diagramm in METUS [ID-Consult GmbH 2012] Visualisierung der Traceability-Informationen in LOOMEO in den Repräsentationsformen Matrix (links) und Node-Link-Diagramm (rechts) Visualisierung der Tracelinks in der Traceability Matrix view von Rational RequisitePro [IBM Corp. 2012a] Traceability-Visualisierung in Teamcenter 9.1 mittels Liste (links) und Traceability-Matrix [Siemens PLM Software Inc. 2012] Traceability-Visualisierung in V6 als Kante im Node-Link-Diagramm (oben rechts), Symbol (unten rechts) und Liste im Produktstruktur- Baum (links) Abbildung 54: Wurzelbaum in einem Constraint-based Layout Abbildung 55: Abbildung 56: Anordnung der Artefakte auf einer segmentierten, gemeinsamen Kreisbahn Hierarchieebenen eines Wurzelbaums auf konzentrischen Kreisbögen Abbildung 57: Anordnungskonzept im vertikalen Tree Layout Abbildung 58: Anordnungskonzept im Balloon-Tree Layout Abbildung 59: Anordnungskonzept Ariadne s Eye Abbildung 60: Boxplot der Studienergebnisse für die Messgröße Lösungszeit Abbildung 61: Schematische Darstellung der trigonometrischen Zusammenhänge für die Anordnungen Kreis und n-eck mit jeweils drei (linke Spalte) bzw. vier Artefakten Abbildung 62: Übersicht der Anordnungsschemata mit fiktiven Artefakthierarchien Abbildung 63: Schematische Darstellung des Konzepts von Ariadne s Eye Abbildung 64: Startansicht der KFZ-Klimaanlage in Ariadne s Eye Abbildung 65: Visuelle Hervorhebung der Suchergebnisse Abbildung 66: Automatisches Hervorheben der verknüpften Funktionen Abbildung 67: Abbildung 68: Multiselektion der beiden übergeordneten Funktionen zweiter Hierarchieebene Abbildung der Vergleichslayouts Force-directed (oben) und Ariadne's Eye xxi

25 Abbildungsverzeichnis Abbildung 69: Abbildung 70: Zweistufiger Prozess zur Identifikation potentiell betroffener Elemente (Schritt 1) und deren manuelle Bewertung (Schritt 2) Schematische Darstellung der beiden Elementkategorien "betroffen" und "nicht betroffen" Abbildung 71: Teilmengen der identifizierten und tatsächlich betroffenen Elemente Abbildung 72: Propagieren einer Änderung entlang hierarchischer Relationen (geändertes Element jeweils rot grundiert) Abbildung 73: Propagieren einer Änderung über verknüpftes Elternelement Abbildung 74: Abbildung 75: Abbildung 76: Abbildung 77: Abbildung 78: Algorithmisches Ablaufdiagramm der entwickelten Impact-Analyse- Methode Konfigurationsschritte (oben) und listenartige Visualisierung der Ergebnisse des Analysis-Wizards (unten) in DOORS Visualisierung der CPM-Ergebnisse mittels Abhängigkeitsmatrix (links) und Force-directed-Diagramm (nach [KELLER ET AL. 2005, S. 6,8]) Impact Analyse in Reqtify mit getrennter Auflistung eingehend (links) und ausgehend verknüpfter Elemente [Claytex Services Limited 2012] Abbildung eines Abhängigkeitspfades zwischen Anforderungen und Funktionen im RFLP-Navigator mittels Node-Link-Diagramm [VORSATZ 2012, S. 48] Abbildung 79: Pedelec-Produktmodell in der Repräsentationsform Liste Abbildung 80: Pedelec-Produktmodell in der Repräsentationsform Abhängigkeitsmatrix Abbildung 81: Pedelec-Produktmodell im Node-Link-Layout Ariadne s Eye Abbildung 82: Für die Nutzerstudie bereitgestelltes Lösungsblatt Abbildung 83: Schematische Übersicht des Studienablaufs je Teilnehmer Abbildung 84: Abbildung 85: Abbildung 86: Boxplot für die Lösungszeiten je Teilaufgabe und Repräsentationsform Boxplot der Subskalen des AttrakDiff-Fragebogens je Repräsentationsform Diagrammartige Übersicht der AttrakDiff-Ergebnisse zu den Dimensionen HQ und PQ Abbildung 87: Boxplot für die wahrgenommene Belastung je Repräsentationsform Abbildung 88: Abbildung 89: Schematische Darstellung der Notwenigkeit von Mehrfachbewertungen Traversierende Abarbeitungsreihenfolge der Elemente eines Artefakts in Abhängigkeit der hierarchischen Nähe Abbildung 90: Datenmodell für den Impact-Analyse-Assistenten Abbildung 91: Ablaufdiagramm des Impact-Analyse-Assistenten auf Basis des funktionalen Konzepts Abbildung 92: Starten des Impact-Analyse-Assistenten aus Ariadne's Eye Abbildung 93: Eingabe der Metadaten für die startende Impact Analyse xxii

26 Abbildungsverzeichnis Abbildung 94: Bewertung der Betroffenheit einer verknüpften Funktion Abbildung 95: Manuelles Hinzufügen einer fälschlicherweise nicht identifizierten Funktion Abbildung 96: Motorcontroller wird als von der Änderung betroffen klassifiziert Abbildung 97: Fenster zur Information über Abschluss der Impact Analyse Abbildung 98: Verwaltung bestehender Impact Analysen Abbildung 99: Übersicht der nicht-betroffenen Elemente im Impact-Analyse-Report Abbildung 100: Traceability-Visualisierung in Ariadne's Eye am Beispiel eines Pedelec-Modells Abbildung 101: Durchführung einer Impact Analyse mit dem entwickelten Dialogbasierten Assistenzwerkzeug xxiii

27

28 TABELLENVERZEICHNIS Tabelle 1: Tabelle 2: Tabelle 3: Tabelle 4: Tabelle 5: Tabelle 6: Tabelle 7: Anzahl verwendeter Modellierungswerkzeuge je Unternehmen und Prozessphase Übersicht der Traceability-relevanten Eigenschaften ausgewählter Werkzeuge Werkzeuge zur Traceability-Visualisierung und deren Repräsentationsformen Erfüllungsgrad der Anforderungen für die vorgestellten Visualisierungsfunktionen Relevanz der Studien bzgl. der Anforderungen aus der Produktentwicklung Ausprägung der visuellen Grammatik im Visualisierungskonzept Ariadne's Eye Charakteristika der Nutzerstudie "Lesbarkeit der Anordnungskonzepte" Tabelle 8: Mittelwerte der Messwerte Fehleranzahl und Lösungszeit Tabelle 9: Ergebnisse der Varianzanalyse je Aufgabe Tabelle 10: Tabelle 11: Ergebnisse der Varianzanalyse für Aufgabe 3 je Anordnungskonzeptpaarung Verteilung der individuellen Anordnungskonzept-Präferenz der Studienteilnehmer Tabelle 12: Vergleichende Übersicht der durchschnittlichen Tracelink-Längen Tabelle 13: Übersicht der Werte für die Label-Überschneidungen Tabelle 14: Übersicht der Werte zum Überlauf der Visualisierungsobjekte Tabelle 15: Übersicht der Werte zur Flächennutzung Tabelle 16: Tabelle 17: Übersicht der wesentlichsten Interaktionsmechanismen und ihrer IT-Umsetzung Beschreibung der Lesbarkeitsmetriken nach [DUNNE UND SHNEIDERMAN 2009] Tabelle 18: Ergebnisse des Vergleichs der Lesbarkeitsmetriken Tabelle 19: Grundbegriffe der Mengenlehre Tabelle 20: Tabelle 21: Erfüllungsgrad der vorgestellten Ansätze hinsichtlich der Anforderungen aus der Mechatronik Charakteristika der Nutzerstudie Wirksamkeit des Impact-Analyse- Algorithmus Tabelle 22: Häufigkeit der Anwendung der jeweiligen Ausschlusskriterien xxv

29 Tabellenverzeichnis Tabelle 23: Zuordnungskriterien der Elemente Tabelle 24: Ergebnisse der Nutzerstudie pro Teilnehmer und Teilaufgabe Tabelle 25: Tabelle 26: Tabelle 27: Tabelle 28: Tabelle 29: Übersicht der Mittelwerte und Standardabweichungen für die Messgrößen Precision, Recall und Accuracy Klassifikationsschema zur Interpretation der Parameter Precision und Recall (nach [HAYES ET AL. 2006, S. 11]) Übersicht der bereinigten Mittelwerte und Standardabweichungen für die Messgrößen Precision, Recall und Accuracy Vollständigkeit der durch den Impact-Analyse-Algorithmus identifizierten Elemente in Abhängigkeit der Fehlerinterpretation Ausprägung der Visualisierungsobjekte und Interaktionsmöglichkeiten je Repräsentationsform Tabelle 30: Übersicht der Charakteristika der Nutzerstudie Tabelle 31: Tabelle 32: Übersicht der Lösungszeiten je Teilaufgabe und Repräsentationsform Ergebnisse der einfaktoriellen Varianzanalyse für die Lösungszeit je Teilaufgabe Tabelle 33: Übersicht der Fehler (FP und FN) je Repräsentationsform Tabelle 34: Tabelle 35: Tabelle 36: Tabelle 37: Tabelle 38: Tabelle 39: Tabelle 40: Ergebnisse der einfaktoriellen Varianzanalyse für die begangenen Fehler Übersicht der Ergebnisse der vier Dimensionen des AttrakDiff- Fragebogens in Abhängigkeit der Repräsentationsform Ergebnisse der einfaktoriellen Varianzanalyse für die Attraktivität der Repräsentationslösungen Ergebnisse des NASA-TLX-Fragebogens für die wahrgenommene Belastung Ergebnisse der Varianzanalyse zur wahrgenommenen Belastung (NASA-TLX) Ergebnisse für die motorische Belastung durch Nutzung der Eingabegeräte Ergebnisse der Varianzanalyse für die Nutzungsintensität der Eingabegeräte Tabelle 41: Festlegungen zu den Ausprägungen der Visualisierungsobjekte xxvi

30 1. EINLEITUNG UND ZIELSETZUNG Das Forschungsgebiet der virtuellen Produktentstehung befasst sich mit der wissenschaftlichen Erarbeitung und Evaluierung von Methoden und Software-Werkzeugen, welche die beteiligten Akteure bei der Entwicklung insbesondere hochgradig komplexer Produkte unterstützen. Die Entwicklung dieser Produkte erfolgt unternehmensintern, wie im weiteren Verlauf der Arbeit ausgeführt wird, zumeist entlang definierter, schrittweise strukturierter Vorgehensweisen unter Beteiligung unterschiedlicher Disziplinen 1 (bspw. Mechanik, Elektrotechnik, Informationstechnik) und ggf. von Zulieferunternehmen. In jedem dieser Entwicklungsschritte werden digitale Modelle oder Dokumente erzeugt, die das spätere Produkt (oder Teile davon) aus verschiedenen Sichtweisen spezifizieren, unterschiedliche Abstraktionsniveaus haben und in den jeweils zugehörigen Autorenwerkzeugen verwaltet werden [VAN GORP ET AL. 2006, S. 50; MOHAN UND RAMESH 2007, S. 968], wodurch das Produktwissen im Unternehmen verteilt [WEBER 2007, S. 103], aber isoliert und nicht integriert verfügbar sein kann (siehe Abbildung 1). Für die beteiligten Entwickler ist es daher nicht immer einfach, den Überblick über diese Vielzahl an generierten Informationen zu behalten und alle Quereinflüsse und Abhängigkeiten zu anderen Teillösungen zu erkennen. Zumal diese Interdependenzen den Entwicklern größtenteils nur implizit, durch langjährige Erfahrungswerte zu konkreten Problemstellungen, bekannt sind, wodurch die Gefahr von Inkonsistenzen in der Produktbeschreibung besteht [AIZENBUD-RESHEF ET AL. 2006, S. 515]. 1 Hinweis zum Lesen der Arbeit: Begriffe, die bei erstmaliger Nennung in kursiver Schrift dargestellt sind, werden im Glossar näher erläutert. 1

31 1 Einleitung und Zielsetzung Abbildung 1: Isolierte Verwaltung von Produktinformationen im Unternehmen Für ein effizientes, also auch inhaltlich konsistentes Entwickeln sind daher gemäß [STEVENS ET AL. 1998, S. 345] u. a. Organisation, Planung, eine eindeutige Zuordnung der Verantwortlichkeiten sowie eine explizite Abbildung der Abhängigkeiten zwischen den Modellen notwendig. Aus der Softwareentwicklung stammt ein Ansatz, der darauf abzielt, inhaltliche Abhängigkeiten zwischen den einzelnen Bestandteilen der erarbeiteten Modelle über den gesamten Entwicklungsprozess hinweg explizit abzubilden. Er wird in der Fachliteratur mit dem Begriff Traceability bezeichnet und wird im weiteren Verlauf der Arbeit detailliert erörtert. Dem Wissen um diese genannten Abhängigkeiten kann in der Produktentwicklung eine große Bedeutung zukommen, da es u. a. hilft, die eigene Teillösung in das übergeordnete Ganze einzuordnen [BURGAUD 2006, S. 2]. Dadurch werden fundiertere Entscheidungen ermöglicht [RIEBISCH ET AL. 2011, S. 11], eine Reihe von Entwicklungsprozessen unterstützt [ULRICH 1995, S. 419; CLELAND-HUANG ET AL. 2003, S. 796] und die Entwicklungsfähigkeit eines Systems verbessert [BODE UND RIEBISCH 2010, S. 192]. Unter anderem aus den genannten Gründen wird Traceability auch als Zeichen reifer Prozess- und Systemqualität erachtet, von den Reifegradmodellen CMMI und SPICE empfohlen und in einer Vielzahl von Entwicklungsstandards vorgeschrieben (MIL-STD-2167A, DO-178B, MIL-STD-498, ISO/IEC 12207, ISO etc.) [BURGAUD 2006, S. 2; AIZENBUD-RESHEF ET AL. 2006, S. 516; STOLZ UND KRAUSE 2009, S. 10]. In diesem einleitenden Kapitel wird zunächst eine übergeordnete Hinführung auf das Themengebiet der Erfassung und Auswertung von Abhängigkeiten zwischen unterschiedlichen Produktmodellen im Rahmen der virtuellen Produktentwicklung gegeben, indem die Ausgangssituation in diesem Ingenieursbereich und die sich daraus ergebende Motivation geschildert werden (Kapitel 1.1). Darauf aufbauend wird in Kapitel 1.2 die Zielsetzung der Arbeit beschrieben, bevor in Kapitel 1.3 die zu betrachtenden Forschungsfragen vorgestellt werden. Das Kapitel schließt mit einer Beschreibung der methodischen Vorgehensweise im Rahmen dieser Arbeit und ihrem daraus resultierende Aufbau (Kapitel 1.4). 2

32 1 Einleitung und Zielsetzung 1.1. AUSGANGSSITUATION UND MOTIVATION Neben den bereits genannten positiven Aspekten der Traceability können sich aus ihrer Anwendung weitere Potentiale ergeben. Gemäß den Ergebnissen einer Studie aus der industriellen Praxis wenden Ingenieure einen großen Teil (vereinzelt bis zu 60 %) ihrer Arbeitszeit für Kommunikation mit dem Zweck der Abstimmung bzw. Koordination auf [STARK ET AL. 2012, S. 20]. In derselben Studie gaben 71% der befragten Ingenieure an, die Beschaffung von Informationen als besonders belastend zu empfinden [STARK ET AL. 2012, S. 21]. Vor diesem Hintergrund muss berücksichtigt werden, dass die explizite Abbildung von Abhängigkeiten mittels Traceability ein Vehikel ist, um das dringend benötigte Wissen über Systemzusammenhänge zu transportieren [MÄDER ET AL. 2012, S. 1]. Dieses Wissen um die Systemzusammenhänge ist gleichzeitig die Voraussetzung, um effizient nach relevanten Informationen suchen und sich ggf. mit anderen, von der eigenen Entwicklung betroffenen Akteuren abstimmen zu können. In zahlreichen Publikationen wird daher festgestellt, dass Traceability hilft, bei den beteiligten Entwicklern ein verbessertes Systemverständnis zu etablieren [JARKE UND POHL 1993, S. 32; LINOS ET AL. 1994; KELLER ET AL. 2006, S. 63; BODE UND RIEBISCH 2009, S. 88]. Ferner sollte berücksichtigt werden, dass die Komplexität moderner Produkte und deren interne funktionale Vernetzung in den letzten Jahren stetig gewachsen sind [TRETOW ET AL. 2008, S. 36; BERTSCHE ET AL. 2009, S. 3; MÄDER ET AL. 2012, S. 1; KÖNIGS 2012, S. 1f]. Dies liegt u. a. an der wachsenden Bedeutung der Disziplinen Elektronik und Informationstechnik in traditionell mechanisch geprägten Entwicklungsprozessen, die darauf zurückzuführen ist, dass deren Anteil an den innovativen Produktfunktionalitäten stetig zunimmt [TUDORACHE 2006, S. 15; DANNENBERG UND BURGARD 2007, S. 4]. Jede der genannten Disziplinen, die unter Umständen in unterschiedlichen Organisationseinheiten auch geographisch verteilt entwickeln, vertraut auf historisch gewachsene und bewährte Vorgehensweisen, nutzt eigene Spezialsoftware zur Entwicklung und verwendet eine eigene Fachsprache. Diese Faktoren führen häufig dazu, dass sowohl im Unternehmen, als auch mit den Zulieferunternehmen, Kommunikationsdefizite entstehen, die im Endeffekt zu Inkonsistenzen im Produktmodell 2 führen [FRICKE ET AL. 2000, S. 172]. Die Entwicklung der Rückrufaktionen, aufgrund sicherheitskritischer Mängel im Zeitraum , wie sie in [BERTSCHE ET AL. 2009, S. 5] auf Basis der Zahlen des Kraftfahrt-Bundesamtes publiziert sind (siehe Abbildung 2), veranschaulicht eingängig, welche möglichen Konsequenzen nicht beherrschte Komplexität haben kann. Jüngstes Beispiel aus dem März 2013: Subaru musste in Nordamerika für Fahrzeuge die Warnung ausgeben, dass diese u. U. autonom starten können, weil bei der Konzipierung der Anlassfernsteuerung nicht berücksichtigt wurde, dass diese herunterfallen oder anderweitig erschüttert werden kann, wodurch fatalerweise der Startvorgang eingeleitet wird [KNIGHT 2013]. 2 Mit dem Begriff Produktmodell wird die Gesamtmenge aller, im Rahmen der Entwicklung entstehenden, Produkt-beschreibenden Modelle (wie bspw. Anforderungen oder Geometrie-Modelle) bezeichnet. 3

33 1 Einleitung und Zielsetzung Abbildung 2: Zeitliche Entwicklung von Rückrufaktionen [BERTSCHE ET AL. 2009, S. 5] Das Ziel sollte es daher sein, die zuvor beschriebene Trennung der Entwicklungswelten aufzuheben bzw. diese stärker zu integrieren, wozu es einer gemeinsamen übergeordneten Sicht auf das zu entwickelnde Produkt bedarf. Diese integrative Funktion kann Traceability übernehmen: in [JARRATT ET AL. 2004, S. 11] wird von einem erfahrenen Entwickler berichtet, der die Visualisierung von Traceability-Daten für geeignet hält, um eine Sichtbarkeit zwischen unterschiedlichen Menschen und Gruppen herzustellen. Diese Einschätzung unterstreicht eine Untersuchung in der Automobilindustrie, wo Traceability-Informationen ebenfalls eine gemeinsame Sicht auf das zu entwickelnde Produkt ermöglicht haben [SUTINEN ET AL. 2000, S. 325]. Doch trotz dieser großen Nutzenpotentiale wird Traceability, abgesehen von den Unternehmen die dazu gesetzlich verpflichtet sind, in der industriellen Praxis nicht so häufig praktiziert, wie deren Wichtigkeit vermuten ließe [GOTEL UND FINKELSTEIN 1994, S. 95; DÖMGES UND POHL 1998, S. 54; MÄDER ET AL. 2012, S. 1]. Das hat im Wesentlichen zwei Gründe: den hohen manuellen Aufwand zur Generierung der Traceability-Informationen, die dem Unternehmen Kosten verursachen [RAMESH ET AL. 1997, S. 410; AIZENBUD- RESHEF ET AL. 2006, S. 516] und den unklaren Nutzen, den das Unternehmen aus den Traceability-Informationen ziehen kann [ARKLEY UND RIDDLE 2005, S. 388] ZIELSETZUNG DER ARBEIT Der letztgenannte Grund bildet die übergeordnete Zielsetzung für die vorliegende Arbeit. Es soll aufgezeigt werden, dass die Erstellung eines Traceability-Modells nicht nur gesetzliche Bestimmungen erfüllt, sondern auch eine Vielzahl bestehender Prozesse in der Produktent- 4

34 1 Einleitung und Zielsetzung wicklung unterstützen kann. Dafür sollen Traceability-basierte Methoden entwickelt werden, mit denen Anwenderunternehmen einen Mehrwert aus der Erfassung und Dokumentation von Abhängigkeiten ziehen können, um den notwendigen Aufwand zumindest auszugleichen. Der Anspruch der Arbeit ist es daher, ein breites Spektrum von Nutzenpotentialen für die Verwendung von Traceability-Informationen aufzuzeigen und zu evaluieren. Die von [STOLZ UND KRAUSE 2009, S. 39] und [HOFFMANN ET AL. 2004, S. 303f] formulierten Anforderungen an den Funktionsumfang eines zeitgemäßen Traceability-Werkzeugs, wonach neben dem essentiellen Erfassen der Abhängigkeiten auch ein nutzerfreundliches, graphisches Navigieren durch selbige sowie die Erstellung von Auswirkungsanalysen ermöglicht werden müssen, bilden dafür eine erste Grundlage. Von dem technischen Report ISO/IEC TR 24766:2009 Information technology - Systems and software engineering werden zudem Funktionalitäten wie Traceability-Reports, Coverage Analysen, Templates für das Quality- Function-Deployment und Status Reports von zukünftigen Systems-Engineering- Werkzeugen gefordert, um das Entwickeln komplexer technischer Systeme rechentechnisch zu unterstützen [International Organisation for Standardization 2009, S. 5]. Im Rahmen der Arbeit werden diese und weitere Funktionalitäten auf ihre Unterstützbarkeit durch Traceability überprüft und geeignete Methoden zu deren informationstechnischer Umsetzung entwickelt. Dabei wird die ursprüngliche Erfassung der Abhängigkeiten nicht im Fokus der Betrachtungen stehen, sondern vielmehr davon ausgegangen, dass bereits ein hinreichend hochwertiges Traceability-Modell vorliegt FORSCHUNGSFRAGEN Das übergeordnete Forschungsthema dieser Arbeit ist somit die Identifikation möglicher Nutzenpotentiale von Traceability-Daten sowie die Entwicklung von Methoden, um diese im Entwicklungsprozess informationstechnisch nutzbar zu machen. Dabei ist anzumerken, dass die im Rahmen dieser Arbeit vorgestellten Softwareprototypen primär dem Zweck dienen, die entwickelten Methoden zu evaluieren, weshalb der wissenschaftliche Fokus der Ausführungen jeweils auf der Entwicklung und Bewertung der Methoden und nicht auf der entsprechenden Software-Implementierung liegt. Konkret liegt der wissenschaftliche Fokus der Arbeit auf vier unterschiedlichen Forschungsfragen: 1. Gibt es etablierte Methoden der Produktentwicklung, deren Durchführung durch Traceability-Modelle informationstechnisch unterstützt werden kann? Wie kann diese Unterstützung konkret erfolgen? 2. Wie muss ein Visualisierungswerkzeug für die Darstellung von Traceability-Modellen gestaltet sein, um eine möglichst intuitive und effiziente 3 Interaktion mit einer flexiblen Anzahl an hierarchischen Produkt-beschreibenden Modellen zu ermöglichen? 3 im Sinne von schnell und fehlerfrei 5

35 1 Einleitung und Zielsetzung 3. Können auf Basis eines vorhandenen Traceability-Modells die Auswirkungen von Änderungen auf andere Produkt-beschreibende Modelle abgeschätzt werden? Wie muss ein solcher Analyse-Algorithmus ausgeprägt sein, um den Besonderheiten der Mechatronik Rechnung zu tragen? 4. Kann die Abschätzung der Änderungsauswirkungen durch geeignete Visualisierung unterstützt werden? Welche besonderen Anforderungen ergeben sich aus diesem Anwendungsfall an die Visualisierung und wie müssen die entsprechenden Daten für eine effiziente Bearbeitung repräsentiert werden? 1.4. METHODISCHES VORGEHEN UND AUFBAU DER ARBEIT Die methodische Vorgehensweise zur Erlangung der im Rahmen der Arbeit vorgestellten Forschungsinhalte orientiert sich an der Design Research Methodology (DRM) gemäß [BLESSING UND CHAKRABARTI 2009]. Das darin empfohlene iterative Vorgehen, aus deskriptiven und präskriptiven Untersuchungen zur Verfeinerung der Annahmen und Evaluierung der Methoden, wird in den einzelnen forschungsrelevanten Kapiteln angewandt. Die konkrete Ausprägung der Methodik in den Kapiteln soll im Folgenden gemeinsam mit dem groben Aufbau der Arbeit beschrieben werden. Nach den einleitenden Ausführungen zur Motivation und Zielsetzung der Arbeit, werden in Kapitel 2 zunächst die Grundlagen zur Entwicklung mechatronischer Produkte beschrieben, wobei neben den elementaren Grundbegriffen (Kapitel 2.1), die dabei häufig erstellten Modelle (Kapitel 2.2) und dafür gängigen Vorgehensweisen (Kapitel 2.3) erläutert werden. Im anschließenden Kapitel 3 wird der Traceability-Ansatz ausführlich vorgestellt, der darauf abzielt, inhaltliche Abhängigkeiten zwischen den einzelnen Bestandteilen der erarbeiteten Modelle über den gesamten Entwicklungsprozess hinweg explizit abzubilden. Im Rahmen dieser Ausführungen wird auch das Forschungsziel der Arbeit herausgearbeitet (1. Stadium der DRM), wobei dies im Wesentlichen durch eine Literaturrecherche und Interviews von industriellen Anwendern erfolgt. Wie in Kapitel 1.3 bereits formuliert, adressiert die übergeordnete Forschungsfrage dieser Arbeit die möglichen Nutzenpotentiale von Traceability-Daten, in dem Methoden entwickelt werden, um diese im Entwicklungsprozess informationstechnisch nutzbar zu machen. Die informationstechnische Plattform zur Erzeugung und Verwaltung der Traceability-Daten, der Softwareprototyp ModelTracer wird in Kapitel 3.6 vorgestellt. Der inhaltliche Aufbau und die Grobstruktur der Kernkapitel sowie das Zusammenwirken ihrer Inhalte sind in der folgenden Abbildung 3 dargestellt. 6

36 1 Einleitung und Zielsetzung Abbildung 3: Aufbau der Arbeit und inhaltlicher Zusammenhang der Kernkapitel Eine Möglichkeit, Traceability-Daten gewinnbringend in der Produktentwicklung zu nutzen, liegt in deren Verwendung zur informationstechnischen Unterstützung etablierter Entwicklungsmethoden, was Gegenstand von Kapitel 4 ist. Dazu werden in Kapitel 4.1 zunächst deskriptive Untersuchungen mittels einer ausführlichen Literaturrecherche (2. Stadium der DRM) durchgeführt, deren Ziel es ist, etablierte Methoden der Produktentwicklung zu identifizieren, deren Durchführung durch eine Anreicherung mit Traceability-Daten unterstützt werden kann. Anschließend werden für ausgewählte Methoden Grobkonzepte vorgestellt, mit denen aufgezeigt wird, wie eine solche Traceability-Unterstützung vorzusehen wäre. Im folgenden Kapitel 4.2 erfolgt die präskriptive Untersuchung (3. Stadium der DRM) exemplarisch anhand der Entwicklungsmethode House of Quality, für welche, mittels eines methodischen Feinkonzepts und eines Software-Prototyps, die Unterstützbarkeit durch Traceability-Daten evaluiert wird. Abgesehen von der Unterstützung konkreter, etablierter Ingenieursmethoden (bei denen die Traceability-Daten primär als Daten-Aggregator fungieren) kann durch eine eingängige Traceability-Visualisierung auch das Verständnis für das zu entwickelnde Produkt verbessert werden [LINOS ET AL. 1994; MARCUS ET AL. 2005, S. 56; DUAN UND CLELAND-HUANG 2006, S. 5]. Die Entwicklung einer adäquaten Visualisierungsform für Traceability-Daten im mechatronischen Kontext ist Gegenstand von Kapitel 5. Dazu werden in einer ersten deskriptiven Untersuchung zunächst die Grundlagen der Informationsvisualisierung im Kontext Traceability (Kapitel 5.1) und der zugehörige Stand der Technik und Anwendung (Kapitel 5.2) mittels einer Literaturrecherche untersucht, bevor aus deren Ergebnissen induktiv eine Hypothese 7

37 1 Einleitung und Zielsetzung zur Eignung einer Repräsentationsform abgeleitet wird (Kapitel 5.3). Basierend auf den Erkenntnissen der theoretischen Analyse wird im darauffolgenden Kapitel 5.4 ein interaktives Traceability-Visualisierungskonzept präskriptiv hergeleitet, welches den zuvor formulierten Anforderungen Rechnung trägt. Das Visualisierungskonzept wird in Kapitel 5.5 wiederum in einer erneuten deskriptiven Untersuchung mittels einer empirischen Nutzerstudie evaluiert, um dessen Eignung zu überprüfen. Die aus der Nutzerstudie gewonnenen Erkenntnisse werden anschließend verwendet, um durch eine erneute präskriptive Aktivität zunächst das Visualisierungskonzept weiterzuentwickeln (Kapitel 5.6) und dieses in dem Software- Prototyp Ariadne s Eye zu implementieren (Kapitel 5.7). In einer abschließenden deskriptiven Untersuchung wird die Visualisierung eines Beispielmodells mittels Ariadne s Eye im Vergleich zu einem etablierten Layout-Algorithmus über anerkannte Lesbarkeitsmetriken evaluiert (Kapitel 5.8). In Kapitel 6 wird untersucht, ob und wie Traceability-Daten genutzt werden können, um die Auswirkungen von Änderungen einzelner Bestandteile eines produktbeschreibenden Modells auf andere Modelle abzuschätzen. Dieser Vorgang der Abschätzung von Änderungsauswirkungen wird in der Fachliteratur mit dem Begriff Impact Analyse bezeichnet. Im deskriptiven, auf Literaturrecherchen basierenden Teil des Kapitels werden zunächst die allgemeinen Grundlagen des Änderungsmanagements (Kapitel 6.1) und der Impact Analyse (Kapitel 6.2) erläutert, bevor der Stand der Technik zu existierenden Impact Analysen aus dem Umfeld der Software- und mechatronischen Produktentwicklung vorgestellt und diskutiert wird (Kapitel 6.3). Auf Basis dieser theoretischen Grundlagen wird induktiv eine Hypothese für eine Traceability-basierte Impact Analyse für die Mechatronik abgeleitet (Kapitel 6.4). Die anschließenden präskriptiven Ausführungen behandeln die Herleitung eines solchen Impact- Analyse-Algorithmus (Kapitel 6.5), an den die zuvor identifizierten Spezifika des mechatronischen Kontextes als Anforderungen formuliert werden. In der in Kapitel 6.6 beschriebenen empirischen Nutzerstudie wird die Wirksamkeit des entwickelten Impact-Analyse-Algorithmus deskriptiv untersucht. Das in Kapitel 5 entwickelte Visualisierungskonzept Ariadne s Eye und der in Kapitel 6 vorgestellte Impact-Analyse-Algorithmus bilden die theoretischen Grundlagen für die Ausführungen in Kapitel 7, das sich mit der Entwicklung eines Dialog-basierten visuellen Impact- Analyse-Assistenzwerkzeugs befasst. Dazu wird in Kapitel 7.1 zunächst der Stand der Technik hinsichtlich der visuellen Unterstützung von Impact Analysen auf Basis einer Literaturrecherche deskriptiv untersucht, was in der Formulierung der induktiv hergeleiteten Hypothese zur Eignung einer speziellen, visuellen Repräsentationsform mündet (Kapitel 7.2). Den deskriptiven Teil dieses Kapitels beschließt eine empirische, vergleichende Nutzerstudie dreier Repräsentationsformen, mit deren Hilfe die Forschungshypothese evaluiert wird (Kapitel 7.3). Auf Basis der durch die Nutzerstudie gewonnenen Erkenntnisse werden in der Folge präskriptiv sowohl ein funktionales Visualisierungs- und Interaktionskonzept für das Dialogbasierte, visuelle Impact-Analyse-Assistenzwerkzeug hergeleitet (Kapitel 7.4), als auch dessen prototypische Implementierung an einem einfachen Beispiel vorgestellt (Kapitel 7.5). 8

38 1 Einleitung und Zielsetzung Im abschließenden Kapitel 8 werden die Ergebnisse der Arbeit und die Beantwortung der Forschungsfragen zusammengefasst, die Grenzen der Methodik diskutiert und ein Ausblick auf zukünftige Forschungsaktivitäten im thematischen Umfeld der Verwendung von Traceability-Daten gegeben. Eine schematische Darstellung der beschriebenen methodischen Vorgehensweise und die Zuweisung der zugehörigen Kapitel kann Abbildung 4 entnommen werden. Abbildung 4: Schematische Darstellung der methodischen Vorgehensweise und der zugehörigen Kapitel 9

39

40 2. GRUNDLAGEN DER ENTWICKLUNG MECHATRONISCHER PRODUKTE Da der wissenschaftliche Beitrag der vorliegenden Arbeit Methoden zur Unterstützung der Entwicklung mechatronischer Produkte behandelt, soll in Kapitel 2 zunächst das abstrakte Vorgehen bei der Entwicklung mechatronischer Produkte erläutert werden. Dazu werden die Art und Abfolge der digitalen Produkt-beschreibenden Informationen, die entlang des Entwicklungsprozesses üblicherweise erstellt werden, vorgestellt. Zusätzlich werden die Gemeinsamkeiten und Unterschiede zwischen theoretischen Vorgehensweisen und deren Akzeptanz in der industriellen Praxis diskutiert. In Kapitel 2.1 werden dazu zunächst die grundlegenden Begriffe hinsichtlich des Entwicklungsvorgehens eingeführt, bevor in Kapitel 2.2 eine Auswahl häufig verwendeter Modelltypen vorgestellt wird. Kapitel 2.3 widmet sich den allgemeinen Vorgehensweisen zur Entwicklung mechatronischer Produkte, wie sie in Theorie und Praxis empfohlen werden, und damit der empfohlenen Abfolge zur Erstellung der vorgestellten Modelltypen im Rahmen der Produktentwicklung. Kapitel 2.4 schließt das Kapitel mit einer zusammenfassenden Analyse EINFÜHRUNG UND DEFINITION GÄNGIGER BEGRIFFE AUS DER PRODUKTENTWICKLUNG Im Rahmen der vorliegenden Arbeit soll die Entwicklung moderner, komplexer 4 Systeme betrachtet werden. Diese beinhalten Funktionalitäten, die zum Teil über elektronische und informationstechnische Lösungen realisiert werden und deren Synergien heutzutage für einen erheblichen Anteil der Innovationen (bspw. Infotainment in Automobilen oder Flugzeugen) verantwortlich zeichnen [DANNENBERG UND 2007, S. 4]. Für die Kategorie von Produkten, die nicht ausschließlich mechanische, sondern ebenfalls elektrotechnische Lösungskomponenten beinhalten, wurde von dem Japaner Ko Kikuchi im Jahr 1969 der Begriff Mechatronik 5 geprägt ([HARASHIMA ET AL. 1996], zit. n. [VDI-Richtlinie 4 5 Eine formale Definition des Komplexitätsbegriffs erfolgt in Kapitel (Seite 36). Im englischsprachigen Original: Mechatronics 11

41 2 Grundlagen der Entwicklung mechatronischer Produkte 2206, S. 9]). Im deutschsprachigen Umfeld wird häufig die Definition nach [ISERMANN 1999, S. 4] verwendet, der im weiteren Verlauf dieser Arbeit gefolgt wird: Mechatronik ist ein interdisziplinäres Gebiet, bei dem folgende Disziplinen zusammenwirken: mechanische und mit ihnen gekoppelte Systeme, elektronische Systeme, Informationstechnik. Dabei ist das mechanische System im Hinblick auf die [Gesamtfunktion des Produkts, der Verf.] dominierend. Es werden synergetische Effekte angestrebt, die mehr beinhalten als die reine Addition der Disziplinen. Für die Abgrenzung der klassischen Fachgebiete wie Mechanik, Elektrik & Elektronik (E/E) und Informationstechnik wird der Begriff Disziplinen verwendet, wie er auch in der obigen Mechatronik-Definition Anwendung findet. In der Literatur wird dafür auch häufig der Begriff Domänen genutzt, der im Rahmen dieser Arbeit jedoch nicht aufgegriffen wird. Ein weiterer elementarer Begriff in der Produktentwicklung lautet System. Hierzu wird die Definition nach [EHRLENSPIEL 2007, S. 20] übernommen: Ein System besteht aus einer Menge von Elementen (Teilsystemen), die Eigenschaften besitzen und durch Beziehungen miteinander verknüpft sind. Ein System wird durch eine Systemgrenze von der Umgebung abgegrenzt und steht mit ihr durch Ein- und Ausgangsgrößen in Beziehung [ ]. Für mechatronische Produkte, die mittels einer Dateninfrastruktur untereinander kommunizieren, hat sich in den letzten Jahren der Begriff Cyber-physische Systeme (CPS) etabliert. Da es sich bei den CPS um einen recht jungen Forschungsgegenstand handelt, deren Wesensmerkmale und Spezifika noch nicht abschließend erforscht sind, werden im Rahmen dieser Arbeit klassische mechatronische Produkte (ohne die zusätzliche Dimension der Datenkommunikation) betrachtet. Zumal die im Rahmen dieser Arbeit vorgestellten Forschungsfragen grundlegenden Charakters sind und daher eine weitere Steigerung der Komplexität des Betrachtungsgegenstandes unter Umständen kontraproduktiv sein könnte. Bestimmte Aspekte von Systemen und des späteren Produkts werden im Verlauf der Produktentwicklung unter spezifischen Gesichtspunkten beschrieben, wozu Modelle erstellt werden. Die Modellbildung ist besonders wichtig, da laut [STACHOWIAK 1980, S. 53] jedem Erkenntnisprozess zunächst ein Abbildungsprozess zugrunde liegt, bei welchem Wesensmerkmale des Originals modellseitig nachempfunden werden. Im Kontext der Produktentwicklung wird daher auch von Produktmodellen gesprochen. Für den Begriff des Modells müssen unterschiedlichen Aspekte betrachtet werden. Laut [KORFF 2008, S. 59] erfüllen Modelle primär den Zweck eines Informationsspeichers für die Projektbeteiligten und müssen zudem mit anderen Modellen verknüpft werden. Ausführliche Betrachtungen zum Modellbegriff wurden durch STACHOWIAK publiziert. Demnach muss ein Modell u. a. die folgenden Merkmale aufweisen [STACHOWIAK 1973, S. 131f]: 12

42 2 Grundlagen der Entwicklung mechatronischer Produkte Das Abbildungsmerkmal gibt an, dass jedes Modell exemplarisch für sein Original steht. Das Verkürzungsmerkmal berücksichtigt, dass ein Modell nicht alle Eigenschaften des Originals verkörpert, sondern lediglich ausgewählte Eigenschaften abbildet, die möglicherweise in modifizierter Form repräsentiert werden. Das pragmatische Merkmal verdeutlicht, dass ein Modell für die Fragestellung des spezifischen Betrachtungszwecks das Original repräsentieren muss. Diesen Betrachtungen folgend kann somit die reduzierte Modell-Definition nach [PAHL ET AL. 2007, S. 784] als für diese Arbeit hinreichend betrachtet werden, nach der ein Modell ein dem Betrachtungszweck entsprechender Repräsentant seines Originals zu sein hat. Laut [BUUR UND ANDREASEN 1989, S. 155] gibt es in der Produktentwicklung ein breites Spektrum an Modellen wie bspw. Designmodelle, Skizzen, Funktionsmodelle oder Prototypen. Da in den Disziplinen Elektrotechnik und Informationstechnik der Modell-Begriff häufig mit informationstechnisch ausführbaren Modellen assoziiert ist, wird im weiteren Verlauf der Arbeit der generischere Begriff Artefakt genutzt. In Übereinstimmung mit [RAMESH UND JARKE 2001, S. 61; CLELAND-HUANG ET AL. 2003, S. 797; MOHAN ET AL. 2008, S. 922; CHEN 2010, S. 506] ist dieser Begriff für jegliche Art von Produkt-beschreibenden Informationen (Spezifikationen, Funktionsstrukturen, Produktstrukturen etc.) gültig, unabhängig von ihrer informationstechnischen Ausführbarkeit ARTEFAKTE IN DER PRODUKTENTWICKLUNG Im Rahmen der Entwicklung mechatronischer Produkte wird eine Vielzahl an Artefakten entwickelt [STOLZ UND KRAUSE 2009, S. 4], deren gemeinsames Ziel es ist, das zu entwickelnde Produkt aus unterschiedlichen Perspektiven zu beschreiben. Diese Artefakte können in unterschiedlichen Modellierungssprachen und Software-Werkzeugen modelliert werden [VAN GORP ET AL. 2006, S. 50]. Für den Gebrauch in dieser Arbeit wird allen Artefakten ein abstraktes Metamodell (siehe Abbildung 5, links) zugewiesen. Danach besteht jedes Artefakt aus Elementen, die untereinander in einer hierarchischen Beziehung stehen können. Jedes Artefakt verfügt zudem über einen eindeutigen Identifizierer, einen Bezeichner, eine Angabe in welchem Werkzeug es ursprünglich modelliert wurde und eine Zuordnung, welches Produkt es beschreibt. Die Elemente, aus denen sich das Artefakt zusammensetzt, weisen ihrerseits ebenfalls einen eindeutigen Identifizierer, einen Bezeichner und die Zugehörigkeit zum Artefakt auf. Auf die hierarchische Struktur, welche die Artefakte aufweisen können, wird in Kapitel näher eingegangen. Im rechten Teil der Abbildung 5 sind zwei Instanzen dieses Metamodells für ein Beispielprodukt dargestellt. Dabei handelt es sich um die Anforderungen und die Produktstruktur einer KFZ-Klimaanlage, wobei beide Artefakte nur einen ausgewählten Auszug der tatsächlichen Elementanzahl enthalten. Aus Gründen der Übersichtlichkeit sind zudem die Attribute identi- 13

43 2 Grundlagen der Entwicklung mechatronischer Produkte fier, sourcetoolidentifier und product bzw. artifact nicht dargestellt. Diese müssten in einer tatsächlichen informationstechnischen Repräsentation jedoch berücksichtigt werden. Abbildung 5: Abstraktes Artefakt-Metamodell und reduzierte Instanziierung am Beispiel von Anforderungen und Produktstruktur einer KFZ-Klimaanlage In den folgenden Kapiteln werden einige Typen dieser Artefakte, die im gesamten Verlauf der Arbeit immer wieder aufgegriffen werden, theoretisch vorgestellt. Konkrete Beispielartefakte, die für die Durchführung der Nutzerstudien entwickelt wurden und in deren Rahmen zur Anwendung kamen, können zusätzlich Anhang A1 (Seite 288ff) entnommen werden ANFORDERUNGSSPEZIFIKATIONEN Mit der Dokumentation von Anforderungen wird das Ziel verfolgt, eine lösungsneutrale Spezifikation der gewünschten Eigenschaften und Funktionalitäten des zu entwickelnden Produkts festzulegen [PAHL ET AL. 2007, S. 215; WEILKIENS 2008, S. 38ff]. Der Anforderungsdokumentation kommt somit in einer frühen Phase von Entwicklungsprojekten eine erhebliche Bedeutung zu, da alle Entwickler ihre Arbeiten, über den gesamten Lebenszyklus hinweg [BAHILL UND GISSING 1998, S. 521], an den Anforderungen ausrichten müssen [BURGAUD 2006, S. 2]. Sie erhalten somit auch eine prozessuale Relevanz. Zumal die Priorisierung der Anforderungen als Orientierung genutzt werden kann, um Entwicklungsressourcen zuzuweisen [BARNETT UND RAJA 1995, S. 28]. Anforderungen werden im Verlauf der Systementwicklung schrittweise detailliert. Gemäß [AXENATH ET AL. 2006, S. 161] kommt Ihnen dabei die Rolle zu, die intrinsischen Einschränkungen des Ingenieursproblems zu spezifizieren. In Disziplinen mit einem vergleichsweise geringen Anteil mechanischer Komponenten erfolgt das über eine Kaskadierung unterschiedlicher Beschreibungen, deren inhaltliche Abstraktheit sukzessive abnimmt. Sie sollten im Folgenden kurz erläutert werden. 14

44 2 Grundlagen der Entwicklung mechatronischer Produkte Das abstrakteste Level, mit dem bei einer Systemneuentwicklung häufig begonnen wird, ist das Anwendungsszenario. Es beschriebt in einfacher Weise eine mögliche Abfolge von Ereignissen, die vom System unterstützt werden müssen, und durch den Nutzer, externe Systeme oder andere Objekte ausgeführt werden [ABMA 2009, S. 9f]. Aus dem Anwendungsszenario kann ein Use Case abgeleitet werden das nächstspezifischere Abstraktionslevel der Anforderungen. Dazu wird das Zusammenspiel mit dem Nutzer, externen Systemen oder anderen Objekten modelliert. Nach der Definition in [AIZENBUD-RESHEF ET AL. 2006, S. 521] beschreibt ein Use Case eine Abfolge von Aktivitäten, die einen Wert für den Nutzer liefern. Aus den Use Cases werden in einem nächsten Schritt textuelle Anforderungen abgeleitet. Während die zuvor beschriebenen Abstraktionslevels hauptsächlich in der Software- und E/E-Entwicklung angewendet werden, ist die textuelle Dokumentation der Anforderungen in allen Disziplinen gängig. Die textuellen Anforderungen werden zumeist hierarchisch in Listen strukturiert, in denen u. a. Verfeinerungen und Abhängigkeiten dokumentiert werden [AXENATH ET AL. 2006, S. 161]. Für diese Strukturierung gibt es keine starren Vorgaben, lediglich Empfehlungen, die firmenspezifisch ausgeprägt werden können [HOOD UND WIEBEL 2005, S. 63]. Eine weit verbreitete Art der Strukturierung ist die Aufteilung in funktionale und nichtfunktionale Anforderungen [SUTINEN ET AL. 2004, S. 194; ABMA 2009, S. 9]. Funktionale Anforderungen beschreiben die Ansprüche an die Funktionalität und Leistung des zu entwickelnden Systems [SUTINEN ET AL. 2004, S. 194]. Nicht-funktionale Anforderungen sind in [SUTINEN ET AL. 2004, S. 194] als Anforderungen beschrieben werden, die nicht das Verhalten, sondern vielmehr qualitative Aspekte wie Umweltfaktoren, physische Form oder andere Einschränkungen adressieren. [KORFF 2008, S. 59] ergänzt für die nicht-funktionalen Anforderungen Aspekte hinsichtlich zeitlicher Limitationen, Zuverlässigkeit, Wartbarkeit, Erlernbarkeit, Bedienbarkeit, Normen und gesetzlicher Vorgaben. Bei der Spezifikation der Anforderungen werden in einem ersten Schritt zunächst übergeordnete Anforderungen 6 formuliert, die das Ziel des Systems beschreiben [WEILKIENS 2008, S. 34ff]. Diese Anforderungen sind in der Folge weiter zu detaillieren, strukturieren und partitionieren, bis sie das zu entwickelnde System bzw. dessen Teilsysteme hinreichend konkret beschreiben. Bei der Verwaltung und dem Umgang mit Anforderungen ist zudem zu beachten, dass diese im Projektverlauf einem steten Wandel unterliegen [HASKINS 2006, S. 8.5]. Dieses Phänomen ist nicht branchenspezifisch, sondern wurde sowohl für die Automobilentwicklung [ALMEFELT ET AL. 2006, S. 123], die Entwicklung militärischer Systeme [SUTINEN ET AL. 2004, S. 189] als auch die Software-Entwicklung [O'NEAL UND CARVER 2001, S. 190] beschrieben. Auch aufgrund dieses dynamischen Verhaltens sind Anforderungen oft unvollständig und widersprüchlich [ALMEFELT ET AL. 2006, S. 120]. 6 Engl. Fachbegriff: High-Level Requirements 15

45 2 Grundlagen der Entwicklung mechatronischer Produkte FUNKTIONSBESCHREIBUNGEN Der Funktionsbegriff ist in der Fachliteratur nicht einheitlich beschrieben. Die folgenden Ausführungen stellen daher nur eine der mehreren möglichen Sichten auf den Funktionsbegriff dar. Die beschriebene Sicht wird jedoch im Rahmen der Arbeit durchgängig als Referenzdefinition verwendet. LEEMHUIS sieht in den Funktionen [ ] das zentrale Strukturierungsmittel zur Abstraktion der Konstruktionsaufgabe und der Lösung [LEEMHUIS 2005, S. 9]. Das liegt daran, dass die Funktionen ein zentrales Bindeglied zwischen den Artefakten der frühen Phase der Produktentwicklung bilden [AHMAD ET AL. 2012, S. 3]. Daher wird das Funktionsartefakt aus den zuvor formulierten Anforderungen abgeleitet, wodurch jeder Teilfunktion ein Satz an funktionalen Anforderungen zugeordnet werden kann [HASKINS 2006, S. 4.4; PONN UND LINDEMANN 2008, S. 56f]. Die Funktionen ihrerseits bilden die Grundlage für die in der Folge zu konkretisierenden technischen Produktartefakte [ULRICH 1995, S. 419] wie bspw. Modelle zur Beschreibung des Verhaltens oder der Geometrie des zu entwickelnden Produktes. Funktionen stellen eine abstrakte Beschreibung dar, wie das zu entwickelnde Produkt die an es gestellten funktionalen Anforderungen realisieren soll [LEEMHUIS 2005, S. 19]. Diese abstrakte Beschreibung ist zunächst lösungsneutral [WERNER ET AL. 1997, S. 238], orientiert sich an dem zu erfüllenden Zweck und vermittelt qualitativ, auf welche Art und Weise die eingehenden Größen in Ausgangsgrößen transformiert werden [PAHL ET AL. 2007, S. 44; PONN UND LINDEMANN 2008, S. 56]. Die einzelnen Funktionen können über die zwischen ihnen ausgetauschten Material-, Energie- oder Signalflüsse miteinander in Beziehung gesetzt werden (vgl. [PAHL ET AL. 2007, S. 44]). Auch das Funktionsartefakt ist in einem Sinne hierarchisch strukturiert, dass abstrakte, übergeordnete Funktionen in konkretere Teil- oder Hilfsfunktionen heruntergebrochen werden, welche die zu realisierenden Transformationen detaillierter beschreiben. Das Vorgehen bei der Entwicklung des Artefakts Funktionen ist daher Top-Down orientiert. [LEEMHUIS 2005, S. 20f] empfiehlt, die Funktionen in einem iterativen Prozess unter Einbeziehung von Experten aus allen beteiligten Disziplinen zu entwickeln, womit sie zu einem Disziplinübergreifenden, gemeinsamen Verständnis über das zu entwickelnde Produkt beitragen können. Das gesamte hierarchische Konstrukt aus Gesamtfunktion, Hilfs- und Teilfunktionen sowie deren Beziehungen untereinander bilden das Funktionsartefakt. Für die Abbildung von Funktionsartefakten häufig genutzte Formen sind die Funktionsliste oder eine Darstellung als Funktionsstruktur mittels eines Blockdiagramms, die besonders bevorzugt wird, wenn die konkreten Beziehungen zwischen den Unterfunktionen im Zentrum der Betrachtung stehen (siehe Abbildung 6). 16

46 2 Grundlagen der Entwicklung mechatronischer Produkte Abbildung 6: Schematische Darstellung einer Funktionsstruktur mit drei horizontalen Hierarchieebenen als Blockdiagramm [PAHL ET AL. 2007, S. 45] VERHALTENSMODELLE Sind die gewünschten, lösungsneutralen Funktionen des Systems beschrieben, erfolgt eine Festlegung konkreter Wirkprinzipien für deren Umsetzung. Dazu muss eine initiale Festlegung bzgl. der Art des realisierenden Systemelements in Form von Verhaltensmodellen erfolgen. Um das Zusammenspiel der unterschiedlichen Eigenschaften (statische und dynamische) der gewählten Systemelemente abschätzen zu können, wird deren Verhalten integriert in einer graphischen Modellierungssprache modelliert. Verhaltensmodelle sind insbesondere von Nutzen, wenn die korrekte Interaktion von Teilfunktionen sowie die Vollständigkeit und Konsistenz der Beschreibung des Gesamtsystemverhaltens überprüft werden soll oder wenn eine Vielzahl systeminterner, korrelierender Zustände betrachtet werden muss [CONRAD ET AL. 2005, S. 5]. Dabei muss berücksichtigt werden, dass sich die unterschiedlichen betrachteten Aspekte gegenseitig beeinflussen, sodass Änderungen in den Wirkprinzipien einer Disziplin Auswirkungen auf das gesamte Produktverhalten haben können [BUUR UND ANDREASEN 1989, S. 155]. Ein Verhaltensmodell ist ein abstraktes mathematisch-physikalisches Modell, mit dem bereits zu einem frühen Zeitpunkt in der Produktentwicklung belastbare Prognosen über die zu erwartenden, damit simulierbaren Produkteigenschaften erzielt werden können [JANSCHEK 2010, S. 50]. Dabei müssen Aspekte aus unterschiedlichen Disziplinen (Mechanik, Thermodynamik, Hydraulik, Regelungstechnik, Elektrotechnik und Elektronik etc.) im Verhaltensmodell berücksichtigt werden. Die erzeugten Verhaltensmodelle können mittels differential algebraischer oder diskreter Gleichungen beschrieben sein, mit denen das Modell hinsichtlich seines zeitlichen Verhaltens, seiner Zustände und zu erwartender Ereignisse charakterisiert wird. Dazu wird üblicherweise vom Entwickler manuell ein physikalisches Modell erstellt. Die physikalischen Verhaltensmodelle werden mittels der graphischen Modellierungsoberfläche hierarchisch und modular aufgebaut. Die Verknüpfung der einzelnen Objekte erfolgt innerhalb jeder Hierarchieebene mit Hilfe von Signal- oder Energieflüssen. Anschließend wird das physikalische Modell von der entsprechenden Modellierungssoftware automatisch in ein mathematisches Modell überführt und abschließend unter den zuvor definierten Rahmenbedingun- 17

47 2 Grundlagen der Entwicklung mechatronischer Produkte gen algorithmisch gelöst. In den Kapiteln und sind exemplarisch die Modellierungsoberflächen zur Erstellung der physikalischen Verhaltensmodelle in zwei PLM- Werkzeugen abgebildet. Eine sehr verbreitete Sprache zur Verhaltensmodellierung ist Modelica [Modelica Association 2013]. Mit Modelica können die physikalischen Eigenschaften der Systemelemente und ihr Zusammenspiel über einen graphischen Editor modelliert werden. Anschließend wird daraus ein C-Code generiert, auf dessen Basis die Simulation erfolgt. Das ausgegebene Ergebnis zeigt das Verhalten der zuvor definierten Variablen in dem modellierten und simulierten Kontext PRODUKTSTRUKTUR Die tatsächliche Strukturierung der Komponenten des späteren Produkts erfolgt in der Produktstruktur. Gemäß [GROTE UND FELDHUSEN 2011, S. Y21] bildet die Produktstruktur [ ] den Aufbau eines Produktes in einer hierarchischen Struktur ab". In [VDI-Richtlinie 2219, S. 10] wird vorgeschlagen, die Produktstruktur so aufzubauen, dass das Produkt darin in Haupt- und Teilkomponenten hierarchisch gegliedert wird. Die Produktstruktur stellt somit ein weiteres Produkt-beschreibendes Modell dar, in welchem alle festgelegten Beziehungen zwischen Baugruppen und Einzelteilen eines Produktes dokumentiert sind. Auch im Bereich des Systems Engineerings werden Produktstrukturen verwendet, obgleich die vorgeschlagene Strukturierung gemäß [VDI-Richtlinie 2219, S. 10] darin um die Betrachtungsebenen Systeme, Sub-Systeme, Software- und Informationselemente erweitert wird. Im Systems-Engineering-Kontext wird die Produktstruktur u. a. mit dem Begriff Product Breakdown Structure [NASA STI 2007, S. 52] bezeichnet. Wie oben beschrieben werden Produktstrukturen im Sinne einer besseren Verständlichkeit [STASKO ET AL. 2000, S. 686] und Handhabbarkeit hierarchisch strukturiert [GROTE UND FELDHUSEN 2011, S. Y21; VDI-Richtlinie 2219, S. 10]. Häufig erfolgt diese Strukturierung in folgender fallender Abstraktionssequenz: Produkt, System, Subsystem, Baugruppe, Bauteil. Die übergeordneten Hierarchieebenen stehen mit den jeweils untergeordneten Hierarchieebenen in einer aggregierenden Relation. Das bedeutet, dass sich bspw. eine Baugruppe jeweils aus ihren hierarchisch untergeordneten Bauteilen zusammensetzt. Das Produktstruktur-Artefakt wird in großen Unternehmen zumeist in einem PLM-System verwaltet. Zudem wird in der Regel die Stückliste eines Produkts direkt aus der Produktstruktur abgeleitet [GROTE UND FELDHUSEN 2011, S. Y21] WEITERE ARTEFAKTE Zur Entwicklung mechatronischer Produkte werden in den drei beteiligten Disziplinen jeweils weitere, in deren Entwicklungsprozessen historisch gewachsene und für spezielle Fragestellungen benötigte Artefakte generiert. Da diese im weiteren Verlauf der Arbeit keine prominente Rolle spielen, wird im Folgenden lediglich eine Auswahl dieser Artefakte kurz vorgestellt. 18

48 2 Grundlagen der Entwicklung mechatronischer Produkte In der Mechanik-Entwicklung werden u. a. Artefakte zur Beschreibung der Produktgeometrie, sog. CAD 7 -Modelle, sowie zu deren räumlicher Integration und Kollisionsabsicherung, sog. Digital Mock-Ups (DMU) erzeugt. Ferner gibt es Modelle zur numerischen Analyse der mechanischen Festigkeit von Festkörpern mittels der Finite-Elemente-Methode (FEM), Modelle zur integrierten geometrisch-funktionalen Absicherung über sog. Functional Digital Mock-Ups (FDMU) sowie Modelle zur Simulation des Fertigungsprozesses von Bauteilen, bspw. über eine computergestützte numerische Steuerung (CNC). Im Rahmen der Softwareentwicklung werden in den frühen Entwicklungsphasen formale Artefakte erstellt, mit welchen die zu entwickelnde Software abstrakt spezifiziert, konstruiert und dokumentiert wird. Häufig werden dazu Modelle in der sog. Unified Modeling Language (UML) erstellt. Aus diesen formalen Modellen kann dann über Modelltransformationen automatisiert Software-Code in einer gewählten Programmiersprache generiert werden. Sowohl das erzeugte Software-Modell als auch der erzeugte -Code können bereits in diesem frühen Entwicklungsstadium über sog. Model- bzw. Software-in-the-Loop-Modelle abgesichert werden. Während der E/E-Entwicklung werden unterschiedliche Artefakte erzeugt. Bei der Entwicklung von Platinen werden bspw. CAD-Modelle der Platine und der darauf vorzusehenden Elektronikbauteile erstellt. Diese geben die korrekte räumliche Anordnung der Bauteile und die innere Struktur der Leiterbahnen auf der Platine wider. Daraus kann automatisiert eine zweidimensionale technische Zeichnung des CAD-Modells, ein sog. Layoutplan, abgeleitet werden. Zur besseren Lesbarkeit der relativen Anordnung der Elektronikbauteile zueinander wird zudem ein Schaltplanentwurf erstellt. In diesem zweidimensionalen, symbolischen Artefakt ist die räumliche Anordnung der Komponenten nicht geometrisch korrekt, sondern vielmehr so dargestellt, dass alle Komponenten für einen menschlichen Leser gut lesbar sind. Bei der Entwicklung eingebetteter Systeme 8, die in der Entwicklung moderner mechatronischer Produkte eine exponierte Rolle spielen, verschmelzen die drei genannten Disziplinen besonders eng. Artefakte die speziell zu deren Entwicklung erstellt werden, können daher auch nur schwer einer Disziplin zugeordnet werden. So werden Regelungen durch Regelsoftware beschrieben, die auf ein Steuergerät aufgespielt wird, welches wiederum eine physische, also mechanische Repräsentation hat - genauso wie die notwendige Sensorik oder bspw. das Stellglied. Im Rahmen der Entwicklung eines funktionsfähigen Steuergeräts kommen unterschiedliche Entwurfs-, Simulations- und Absicherungsmethoden zur Anwendung. Sind die Anforderungen an das Gerät und die von ihm zu erfüllenden Funktionen definiert, kann zunächst eine Methode zum rechnergestützten Entwurf für Regelungs- und Steuerungssysteme (RCP) zum Einsatz kommen, mit welcher in der Praxis üblicherweise die Funktionalität des Geräteentwurfs überprüft wird. In der Folge muss die Interaktion des Gerätemodells mit der Umwelt schrittweise simuliert und abgesichert werden. Dazu werden mit steigendem Reifegrad erst Model-in-the-Loop- (Simulation von Software-Modell mit Regel- 7 8 Computer-Aided Design Engl. Fachbegriff: Embedded System 19

49 2 Grundlagen der Entwicklung mechatronischer Produkte strecke-modell), dann die zuvor beschriebenen Software-in-the-Loop- (Softwarecode mit Regelstrecke-Modell), danach ggf. Processor-in-the-Loop- (Softwarecode auf repräsentativem Prozessor mit Regelstrecke-Modell) und abschließend Hardware-in-the-Loop-Simulationen (reales Steuergerät mit Modell der Regelstrecke zumeist in Echtzeit) durchgeführt HIERARCHISCHE STRUKTUR DER ARTEFAKTE Im Rahmen dieser Arbeit werden Methoden betrachtet und entwickelt, die sich mit den Interdependenzen zwischen unterschiedlichen Artefakten befassen. Dafür ist insbesondere die inhaltliche und topologische Strukturierung der Artefakte von Relevanz. Daher wurden die wesentlichen Eigenschaften der typischen Artefakte aus der Mechatronik-Entwicklung im bisherigen Verlauf von Kapitel 2.2 herausgearbeitet. Der konkrete Inhalt der Artefakte spielt dabei eine untergeordnete Rolle, was zur Folge hat, dass die entwickelten Methoden für Artefakte anderer Disziplinen ebenso anwendbar sein können, solange deren inhaltliche und topologische Strukturierung den hier vorgestellten Maßgaben entspricht. Laut [LANE 2006, S. 86f] und [SOSA ET AL. 2005, S. 436] sind technische Systeme zumeist hierarchisch aufgebaut, was u. a. Vorteile für deren Montage und Modularisierung birgt. Analog dazu sind auch die Artefakte zu ihrer Beschreibung hierarchisch strukturiert wie die im bisherigen Verlauf von Kapitel 2.2 vorgestellten Artefakte. So wird bspw. in [HAUSER UND CLAUSING 1988, S. 65] von acht Hierarchieebenen in einer Anforderungsspezifikation bei Toyota berichtet, während gemäß [HO UND LI 1997, S. 587] die meisten Produktstrukturen mindestens fünf Hierarchielevel aufweisen. Laut [STASKO ET AL. 2000, S. 664] stellen Hierarchien eine der wichtigsten Informationsstrukturen in der Datenverarbeitung dar. Die Motivation hinter der hierarchischen Strukturierung ist vielfältig. Um die genannten Ziele einer verbesserten Verständlichkeit und Handhabbarkeit der Artefakte erreichen zu können, muss die Hierarchisierung einerseits eine sortierende sowie andererseits eine abstrahierende Funktion der übergeordneten Ebenen gewährleisten [PUMAIN 2006, S. 4]. Dieser Maßgabe wird auch die in [BODE UND RIEBISCH 2010, S. 186] verwendete Definition des Begriffs Hierarchie gerecht, wonach es sich bei einer Hierarchie um ein Arrangement oder eine Klassifikation verwandter Abstraktionen handelt, die entsprechend ihrer Inklusion und ihres Detailgrads über- oder untereinander rangieren. Generell sind Artefakte in der Produktentwicklung mittels Inklusionshierarchien strukturiert [LANE 2006, S. 86f], wobei die übergeordneten Elemente abstrakte Container für die untergeordneten Elemente darstellen. Die seltenen Ausnahmen bilden z. B. alphabetisch sortierte Artefakte wie Kataloge oder Abkürzungsverzeichnisse oder polyhierarchische Funktionsnetze, die in dieser Arbeit jedoch nicht betrachtet werden. In einer Inklusionshierarchie wird somit ein übergeordnetes Element aus seinen untergeordneten Elementen komponiert. Daraus folgt, dass auch die Summe der Wesensmerkmale der untergeordneten Elemente stellvertretend durch das übergeordnete Element repräsentiert wird [TUDORACHE 2006, S. 55f]. Diesem Ansatz folgend wird in [SUTINEN ET AL. 2000, S. 318] beschrieben, dass Anforderungen, die an ein in der Hierarchie untergeordnetes Element gestellt werden, unter Umständen bis auf die oberste Hierarchieebene vererbt werden können. 20

50 2 Grundlagen der Entwicklung mechatronischer Produkte Verallgemeinert werden kann somit: weist ein untergeordnetes Element ein Wesensmerkmal auf, aggregieren seine übergeordneten Elemente dieses und die aller anderen untergeordneten Kindelemente [MÄDER ET AL. 2009, S. 5]. In der Literatur wird diese Eigenschaft mit den Begriffen upward causation [RAIA 2005, S. 297] und hierarchische Transitivität bezeichnet [ABMA 2009, S. 65]. Der letztgenannte Begriff wird im weiteren Verlauf dieser Arbeit verwendet. Die hierarchische Transitivität hat für die im Rahmen dieser Arbeit entwickelten Methoden eine immense Bedeutung. Denn ebenso wie sich die Eigenschaften eines Elements innerhalb eines beliebigen Artefakts A nach oben vererben, muss auch die Abhängigkeit eines untergeordneten Elements von dessen Elternelement repräsentiert werden, sofern das untergeordnete Element (z. B. bei einer Visualisierung) nicht selbst dargestellt ist. Besteht also eine Abhängigkeit vom untergeordneten Element A 3.1. (des Artefakts A) zu einem Element B 2 (eines zweiten Artefakts B), muss diese Abhängigkeit vom übergeordneten Element A 3 (des Artefakts A) repräsentiert werden, wenn die dritte Hierarchieebene in A, in der A 3.1 enthalten ist, nicht ausgeklappt ist. Eine schematische Darstellung dieser speziellen Auswirkung der hierarchischen Transitivität ist in Abbildung 7 dargestellt, wobei der rote Pfeil die Abhängigkeit symbolisiert. Abbildung 7: Schematische Darstellung der hierarchischen Transitivität Dies kann an einem einfachen Beispiel erläutert werden. Die Anforderung Das Fahrzeug soll bei einer Vollbremsung von 100 km/h auf 0 km/h nicht mehr als 80 m Bremsweg benötigen sei der übergeordneten Kategorie der Funktionalen Anforderungen untergeordnet. Wird diese Anforderung nun an das Subsystem Bremssystem gestellt, gilt bei abstrakter 21

51 2 Grundlagen der Entwicklung mechatronischer Produkte Betrachtung ebenso, dass das Subsystem Bremssystem mindestens eine Abhängigkeit zu den Funktionalen Anforderungen aufweist VORGEHENSMODELLE IN DER PRODUKTENTWICKLUNG In der Produktentwicklung gibt es kein einheitliches Vorgehensmodell, welches über alle Firmengrenzen und Disziplinen hinweg Anwendung findet. Häufig sind die gelebten Vorgehensweisen historisch unterschiedlich gewachsen und bilden eher eine evolutionäre Weiterentwicklung anerkannter Vorgehensmodelle. Viele Organisationen haben solche etablierten Vorgehensmodelle veröffentlicht, die auf einem abstrakten Niveau beschreiben, wie Produkte mittels eines strukturierten Vorgehens schrittweise entwickelt werden können. Ziel des Kapitels 2.3 ist es, eine Auswahl dieser theoretischen Vorgehensmodelle (Kapitel 2.3.1) sowie exemplarisch die Vorgehensweisen in der industriellen Praxis (Kapitel 2.3.2) vorzustellen. Im abschließenden Kapitel 2.4 werden die Gemeinsamkeiten und Unterschiede dieser Vorgehensweisen diskutiert und Rückschlüsse auf die Bedeutung der Traceability- Modellierung gezogen THEORETISCHE VORGEHENSMODELLE In Kapitel werden für die Entwicklung mechatronischer Produkte relevante Auszüge aus drei theoretischen Vorgehensmodellen vorgestellt. Unterschiedliche Organisationen haben solche Entwicklungsmethodiken publiziert, die das strukturierte Entwickeln erleichtern sollen. Konkret werden in diesem Kapitel die Methodik nach VDI 2206, das Systems Engineering und die Entwicklungsmethodik ISO einzeln vorgestellt. VDI 2206: Entwicklungsmethodik für mechatronische Systeme [VDI-Richtlinie 2206] Der Verein Deutscher Ingenieure (VDI) hat, ergänzend zu seinen Disziplin-spezifischen Entwicklungsrichtlinien, die Richtlinie VDI 2206 publiziert. Deren Ziel ist es, die frühen Phasen der Disziplin-übergreifenden Entwicklung mechatronischer Produkte durch Bereitstellung entsprechender Methoden zu unterstützen. Der Fokus der Ausführungen liegt darin auf der Phase des Systementwurfs. Die VDI 2206 beschreibt u. a. einen sog. generischen Makrozyklus in Form eines V-Modells, der im Wesentlichen die fünf Prozessphasen Systementwurf, Modellbildung und -analyse, domänenspezifischer Entwurf, Systemintegration und Eigenschaftsabsicherung beinhaltet (siehe Abbildung 8). Die Voraussetzung zum erfolgreichen Durchlaufen dieser Prozessphasen sind die zuvor zu definierenden Anforderungen, die an das zu entwickelnde Produkt gestellt werden und an denen der Erfolg der Entwicklung später gemessen wird. Sie stellen damit die Grundlage für den Systementwurf dar. Im Rahmen des Systementwurfs wird ein Disziplin-übergreifendes Lösungskonzept entwickelt, wozu zunächst, auf Basis der abstrahierten Anforderungen, die vom Produkt zu realisierenden Funktionen identifiziert und in einer Funktionsstruktur modelliert werden. Die einzelnen Teilfunktionen werden dabei hinsichtlich ihrer Konsistenz analysiert. Anschließend 22

52 2 Grundlagen der Entwicklung mechatronischer Produkte werden den Teilfunktionen Wirkprinzipien bzw. Lösungselemente zugeordnet, um prinzipielle Lösungsvarianten ableiten und bewerten zu können. Als Ergebnis der Prozessphase Systementwurf gilt das, entsprechend der Bewertungsergebnisse ausgewählte, Lösungskonzept. Dieses kann bspw. in Form eines Verhaltensmodells modelliert werden und muss die physikalischen und logischen Wirkungsweisen sowie die Zusammenhänge zwischen den Disziplinen abbilden. Abbildung 8: In der Produktentwicklung zu durchlaufendes V-Modell als Makrozyklus [VDI- Richtlinie 2206, S. 29] Das festgelegte Lösungskonzept ist Voraussetzung und Grundlage für die darauffolgende Prozessphase des domänen- bzw., der Terminologie der Arbeit folgend, Disziplinspezifischen Entwurfs. Die Ausdetaillierungsaktivitäten, die innerhalb dieser Prozessphase in den jeweiligen Disziplinen zu erfolgen haben, werden von der VDI 2206 nicht konkret spezifiziert. Es wird jedoch empfohlen, sich an den entsprechenden Disziplin-spezifischen Richtlinien (bspw. VDI 2221 für die Mechanik oder Wasserfallmodell für die Informatik) zu orientieren. Die detaillierten Auslegungen müssen, insbesondere für die kritischen Teilfunktionen, gegen die entsprechenden Anforderungsspezifikationen abgesichert werden, um die vollständige Erfüllung der Funktionen zu gewährleisten. Dazu sind im Rahmen der begleitenden Modellbildung und -analyse die Produkteigenschaften mit Hilfe von Modellen und Simulationen zu untersuchen. In der Prozessphase Systemintegration werden die einzelnen Detaillösungen aus den Disziplinen zu einem Gesamtprodukt integriert. Dabei muss darauf geachtet werden, dass deren Zusammenwirken die gewünschte Produktfunktionalität erfüllt. Daher werden im Rahmen dieser Tätigkeiten auch fortwährend die Eigenschaftsabsicherungen durchgeführt, wobei die integrierten Detaillösungen gegen die spezifizierten Anforderungen und Funktionen verifiziert und validiert werden. Entsprechen einzelne Lösungen nicht den an sie gestellten Anforde- 23

53 2 Grundlagen der Entwicklung mechatronischer Produkte rungen, sind diese gemäß den Vorgaben des Disziplin-spezifischen Entwurfs zu modifizieren. Das Ergebnis des ggf. zu iterierenden Makrozyklus ist das vollständig definierte Produkt, wobei dessen Systemkontext und Konsistenz sichergestellt ist. Es kommt zustande, indem schrittweise digitale Artefakte (siehe Kapitel 2.2) entwickelt werden, die aufeinander aufbauen. So baut die Funktionsstruktur auf den abstrahierten Anforderungen auf, deren Teilfunktionen ihrerseits in konkrete Wirkprinzipien bzw. Lösungselemente überführt werden müssen. Auf deren Basis werden die Disziplin-spezifischen Lösungen entwickelt, die wiederum gegen die zugehörigen Anforderungen und Funktionen abgesichert werden müssen. Während der gesamten Entwicklung muss demnach nachvollzogen werden, welche Funktion welche Anforderung erfüllt, welche Funktion durch welches Lösungselement realisiert wird, welche Anforderungen an dieses Lösungselement bestehen usw. Es ist demnach eine Durchgängigkeit zwischen den einzelnen Elementen dieser digitalen Artefakte herzustellen. Systems Engineering [HASKINS 2006; Department of Defense 2001; NASA STI 2007] Aus dem Bereich der Luft- und Raumfahrt entstammt das Systems-Engineering- Vorgehensmodell für das Disziplin-übergreifende Entwickeln. Systems Engineering ist ein methodischer und strukturierter Entwicklungsansatz, der existierende und etablierte Vorgehensweisen aus verschiedenen Fachdisziplinen zu einem holistischen [SENGE 1994], iterativen Problemlösungsprozess integriert und erweitert. Im Unterschied zu anderen etablierten Vorgehensmodellen adressiert der Systems-Engineering-Ansatz nicht das Produkt, sondern das gesamte System. Der Mehrwert bei der Betrachtung des Systems, definiert als Komposition unterschiedlicher interagierender Systemelemente [HASKINS 2006, S. 1.5; Department of Defense 2001], gegenüber den einzelnen Elementen ergibt sich aus der Berücksichtigung ihrer Interaktion untereinander. Die Systemelemente können dabei im Unterschied zu anderen Vorgehensmodellen, je nach Festlegung der Systemgrenzen, neben den technischen Aspekten auch Personen, Einrichtungen, Dokumente oder Richtlinien beinhalten [NASA STI 2007]. Moderne Systems-Engineering-Ansätze betrachten außerdem die drei anerkannten Dimensionen der Nachhaltigkeit: Wirtschaftlichkeit, Ökologie und soziale Verträglichkeit [BEIER ET AL. 2012b]. Die INCOSE (International Council on Systems Engineering) definiert Systems Engineering als einen interdisziplinären Ansatz, der den Entwurf und die Anwendung eines Systems in seiner Gesamtheit betrachtet [HASKINS 2006, S. 1.5]. Das Ziel des Systems Engineerings besteht in der Realisierung von Systemen, die wohldefinierten Anforderungen genügen und diese über den gesamten Lebenszyklus des Systems erfüllen müssen [BAHILL UND GISSING 1998, S. 521]. Systems Engineering ist somit ein Entwicklungsansatz, der eine systemische Sichtweise auf das zu entwickelnde Produkt zur Entwicklungsprämisse erklärt. Formale Sprachen zur Beschreibung von Systemen (wie bspw. SysML, UML) bilden dabei die Grundlage des modellbasierten Systems Engineerings. 24

54 2 Grundlagen der Entwicklung mechatronischer Produkte Abbildung 9: Systems-Engineering-Prozess [Department of Defense 2001, S. 31] Der Systems-Engineering-Prozess (siehe Abbildung 9) sieht zunächst eine Anforderungsanalyse vor, bei welcher u. a. funktionale und nicht-funktionale Anforderungen der Kunden und zusätzlicher Stakeholder (natürliche Personen oder Organisationen) erfasst und aufbereitet werden, die validierbar und widerspruchsfrei zu sein haben. Aus den Anforderungen wird im Anschluss im Rahmen der funktionalen Analyse eine Funktionsstruktur 9 abgeleitet. Dazu wird zunächst die zu leistende Gesamtfunktion des Systems identifiziert, welche ihrerseits in konkrete Teilfunktionen heruntergebrochen wird. Darauf folgt die Identifikation und Dokumentation der zugehörigen Anforderungen zu den Teilfunktionen einerseits sowie der Abhängigkeiten zwischen den modellierten Teilfunktionen andererseits, was der sog. funktionalen Architektur des Systems entspricht. Während der folgenden Synthese-Phase werden die zuvor identifizierten Teilfunktionen in physikalische bzw. softwaretechnische Lösungselemente transformiert. Sind diese um die internen und externen Schnittstellen ergänzt, spricht man von der physikalischen Architektur des Systems. Diese bildet ihrerseits die Basis für die anschließenden detaillierenden Entwicklungen in den beteiligten Disziplinen. Abschließend werden die einzelnen Teillösungen und die integrierte Gesamtlösung des Systems gegen die Anforderungen verifiziert. Parallel zu den beschriebenen Prozessphasen erfolgt die Systemanalyse und kontrolle, in deren Rahmen u. a. das Risikomanagement, die 9 Im Systems Engineering sind für Funktionsstrukturen ebenfalls die Begriffe Logical Decomposition [NASA STI 2007] und Functional Analysis and Allocation etabliert [Department of Defense 2001] 25

55 2 Grundlagen der Entwicklung mechatronischer Produkte Fortschrittskontrolle und die Entscheidungsfindung und -dokumentation durchgeführt werden. Der Systems-Engineering-Prozess zeichnet sich zudem durch ein iteratives Vorgehen aus. Das beinhaltet, dass die während einer Prozessphase gewonnenen Erkenntnisse genutzt werden, um die Ergebnisse des vorhergehenden bzw. nachfolgenden Prozessschritts zu verfeinern oder zu modifizieren. Zu diesem Zweck ist es auch notwendig, die Abhängigkeiten zwischen den einzelnen Elementen der generierten Artefakte zu modellieren [Department of Defense 2001]. Dazu sollen im Systems Engineering Software-Werkzeuge benutzt werden, mit denen Elemente aus unterschiedlichen Artefakten (bspw. die Anforderungen, denen das System genügt, sowie die Funktionen, die es realisieren muss, oder die Komponenten, aus denen es sich zusammensetzt) in Relation gesetzt werden. ISO 26262: Road vehicles Functional Safety Die internationale Organisation für Normung (ISO) hat im November 2011 die Norm ISO Road vehicles Functional safety in Kraft gesetzt, die ein Vorgehensmodell für die Entwicklung sicherheitsrelevanter E/E-Systeme in der Automobilbranche beschreibt. Nach dem eigenen Anspruch dieses umfassenden, zehnteiligen Rahmenwerks adressiert das darin beschriebene Vorgehensmodell alle an der Entwicklung der sicherheitskritischen E/E-Systeme beteiligten Disziplinen, die ihre Entwicklungsprozesse somit an der ISO ausrichten können. Die vorgehensspezifischen Teile der Norm lassen sich grob den Phasen eines klassischen V-Modells zuordnen (siehe Abbildung 10). Konkret handelt es sich dabei um die Teile 2 (Management der funktionalen Sicherheit) [ISO ], 3 (Konzeptphase) [ISO ], 4 (Produktentwicklung: Systemebene) [ISO ], 5 (Produktentwicklung: Hardwareebene) [ISO ], 6 (Produktentwicklung: Softwareebene) [ISO ] und 7 (Produktion, Betrieb und Außerbetriebnahme) [ISO ]. Bei der ISO wird ein besonderer Schwerpunkt auf das Risikomanagement, also die Abschätzung von Risiken und die Entwicklung geeigneter Gegenmaßnahmen, gelegt, das, im Gegensatz zu alternativen Vorgehensmodellen, in jeder Prozessphase betrachtet werden muss [ISO ; ISO ]. Die einzelnen Produkt-definierenden Prozessphasen sollen im Folgenden kurz erläutert werden. Die eigentliche Entwicklung beginnt mit der Konzeptphase, die das Ziel verfolgt, ein verbessertes Verständnis des Entwicklungsgegenstandes zu erreichen. Dazu wird dieser u. a. mittels der gestellten (gesetzlichen) Anforderungen, der zu realisierenden Funktionen, der notwendigen Schnittstellen sowie der zu betrachtenden Umgebungseinflüsse detailliert beschrieben. Dem in dieser Phase ebenfalls zu entwickelnden funktionalen Sicherheitskonzept werden ferner die relevanten Sicherheitsanforderungen und -ziele zugeordnet. [ISO ] 26

56 2 Grundlagen der Entwicklung mechatronischer Produkte Abbildung 10: Zuordnung der einzelnen Teile der ISO zum klassischen V-Modell [ISO , S. vi] Auf die Konzeptphase folgen die Phasen der Produktentwicklung auf System-, Hardwareund Softwarelevel, die ihrerseits jeweils einem miniaturisierten V-Modell folgend ablaufen. Konkret bedeutet dies, dass die Spezifikations- und Entwicklungsaktivitäten innerhalb der Prozessphasen auch verifiziert und validiert werden müssen. Die Spezifikation auf Systemlevel beinhaltet die Erarbeitung einer initialen Systemarchitektur, auf deren Basis technische Sicherheitsanforderungen in Konsistenz zum funktionalen Sicherheitskonzept elaboriert und den Komponenten der Systemarchitektur zugewiesen werden. Neben der parallel erfolgenden Festlegung unterstützender Prozesse [ISO ] erfolgt die Beschreibung von Schnittstellen, mit deren Hilfe das Systemdesign, welches die Ausgangsbasis für die Produktentwicklung auf Hardware- und Softwarelevel bildet, komplettiert wird. [ISO ] Das allgemeine Vorgehen für die Produktentwicklung auf Hardware- und Softwarelevel unterscheidet sich nicht wesentlich weder untereinander noch vom Entwicklungsvorgehen auf Systemlevel. Beide Prozessphasen, die parallel durchlaufen werden können, benötigen als Input die hardware- respektive softwaretechnischen Teilaspekte des Systemdesigns samt zugewiesenen technischen Sicherheitsanforderungen. Daraus werden zunächst Hardwarebzw. Software-spezifische Anforderungen abgeleitet, auf deren Basis wiederum das sog. Hardware Design bzw. die Software-Architektur entwickelt werden. Im Anschluss an die folgende Detailentwicklung bzw. Implementierung, für die beide gilt, dass die konkrete Um- 27

57 2 Grundlagen der Entwicklung mechatronischer Produkte setzung der Sicherheitsanforderungen nachverfolgbar dokumentiert sein muss, sind die entwickelten Detaillösungen zu verifizieren und zu validieren. [ISO ; ISO ] Sind diese Tests erfolgreich absolviert, werden die Disziplin-spezifischen Lösungen auf Systemebene integriert, wo das integrierte Systemverhalten erneut evaluiert werden muss. Nach einer anschließenden Absicherung und Bewertung der funktionalen Sicherheit des entwickelten Systems wird die Entwicklung zu Produktion und Betrieb freigegeben PRODUKTENTWICKLUNG IN DER INDUSTRIELLEN PRAXIS In Kapitel wurden theoretische Vorgehensmodelle für die Entwicklung mechatronischer Produkte vorgestellt. Die beschriebenen schrittweisen Vorgehensmodelle werden in der industriellen Praxis jedoch zumeist so nicht angewendet [NG 2006, S. 370]. In der Regel werden Teile der Vorgehensweisen so kombiniert, dass sie für das jeweilige Unternehmen und Produkt vorteilhaft sind. In diesem Kapitel sollen exemplarisch Vorgehensweisen aus der Automobilindustrie vorgestellt werden, um Gemeinsamkeiten und Unterschiede zu den theoretischen Vorgehensmodellen herausarbeiten zu können. In der Automobilindustrie sind die Organisationseinheiten häufig anhand einer Matrixform strukturiert. Eine beispielhafte Organisation ist in [KÖNIGS ET AL. 2012] beschrieben. Darin wird zwischen produktorientierten (vertikal) und systemorientierten (horizontal) Organisationeinheiten unterschieden (siehe Abbildung 11). Abbildung 11: Schematische Darstellung der Matrixorganisation bei einem Automobilhersteller [KÖNIGS ET AL. 2012, S. 925] Die produktorientierten Organisationseinheiten zeichnen u. a. für die Integration der Systeme in die Produktlinien verantwortlich. Dazu ist ein hoher koordinativer Aufwand erforderlich. Dies unterstreichen die Zahlen einer Befragung aus der industriellen Praxis, wonach Entwicklungsingenieure einen Großteil (vereinzelt bis zu 60 %) ihrer Arbeitszeit für Kommunikation mit dem Zweck der Abstimmung bzw. Koordination aufwenden [STARK ET AL. 2012, S. 20]. Der Vorteil dieser Organisationsform ist, dass die Prozesse der detaillierten Syste- 28

58 2 Grundlagen der Entwicklung mechatronischer Produkte mentwicklung und -integration größtenteils parallelisiert werden können, was die Gesamtentwicklungszeit verkürzt. Zudem können bei komplexen Entwicklungsprojekten mehrere horizontale und vertikale Linien abgedeckt werden [KÖNIGS 2012]. Die Produktentwicklung beginnt auch im industriellen Kontext mit der Beschreibung der geforderten Eigenschaften und des gewünschten Verhaltens der Fahrzeugfunktionen auf Systemlevel in Form einer textuellen Anforderungsspezifikation [SUTINEN ET AL. 2000], welche ggf. um ein graphisches Verhaltensmodell ergänzt wird [CONRAD ET AL. 2005, S. 4f]. Diese graphischen Modellierungssprachen werden zumeist zur Beschreibung des Verhaltens von großen, komplexen Systemen genutzt, wenn die korrekte Interaktion der Teilfunktionen spezifiziert wird und eine Vielzahl verknüpfter systeminterner Zustände betrachtet werden muss [CONRAD ET AL. 2005, S. 5]. In kollaborativen Entwicklungsprojekten wird die initiale Anforderungsspezifikation zudem den Zulieferern zu Abstimmungszwecken übermittelt. Ein detaillierter, kollaborativer Abstimmungsprozess auf Basis das Anforderungsaustauschformats ReqIF kann [MUTH 2012] entnommen werden. Bei der Spezifikation der Anforderungen werden diese entsprechend der bekannten Fahrzeugarchitektur partitioniert, die in der Regel dem Vorgängermodell entlehnt ist, und der jeweils zugehörigen systemorientierten Organisationseinheit zugewiesen. In der anschließenden Phase der Komponentenentwicklung arbeiten Mechanik-orientierte Organisationseinheiten dabei mit CAD-Modellen, die zusätzlich bei Bedarf mittels FEM-Analysen und Mehrkörpersimulationen ausgelegt werden. Die geometrische Absicherung dieser Modelle erfolgt mittels DMUs sowie bei ausgewählten Baugruppen mittels physischer Prototypen [WEBER 2009]. In den E/E-zentrierten Organisationseinheiten ist das Vorgehen stärker an den Systems- Engineering-Gedanken angelehnt, was sich darin manifestiert, dass Systemarchitekturen genutzt werden. Darin sind erlebbare Funktionen beschrieben, die sowohl die Partitionierung auf einzelne Funktionsträger, als auch deren Vernetzung untereinander, abbildet [WEBER 2009]. Während des Funktionsdesigns und der -implementierung kommen ausführbare Modelle zum Einsatz, wobei zunächst ein physikalisches Modell erstellt wird, das fortlaufend detailliert und abschließend in Softwarecode überführt wird [CONRAD ET AL. 2005, S. 5]. Der Absicherungsprozess erfolgt buttom-up, was bedeutet, dass zunächst einzelne Detaillösungen wie Steuergeräte mittels Hardware-in-the-Loop und dann integrierte E/E-Subsysteme gegen ihre zugehörigen Anforderungen abgesichert werden [WEBER 2009]. Die Integration und Absicherung der Funktionen des Gesamtfahrzeugs wird durch die systemorientierten Organisationeinheiten durchgeführt, da in deren Verantwortung auch die Absicherung der Gesamtfahrzeugeigenschaften liegt. Die finale Absicherung der Fahrzeugeigenschaften erfolgt in der Automobilbranche häufig mittels physischer Prototypen. 29

59 2 Grundlagen der Entwicklung mechatronischer Produkte Abbildung 12: Grober Entwicklungsprozess in der Automobilindustrie [WEBER 2009, S. 12] Der grobe Ablauf der Entwicklung orientiert sich demnach in wesentlichen Zügen am klassischen V-Modell nach VDI 2206 [WEBER 2009] (siehe Abbildung 12), welches in Kapitel beschrieben wurde. Dabei ist jedoch zu beachten, dass speziell in der Automobilbranche ein hoher Anteil an Gleichteilen verbaut wird. Daher beginnt die Anforderungsspezifikation nicht bei Null, sondern setzt auf einen existierenden Anforderungskatalog vom Vorgängerprodukt auf, der gezielt um Anforderungen an geplante Innovationen ergänzt wird. Auf abstrakte Funktionsbeschreibungen, wie bspw. von der VDI 2206 empfohlen, wird auf Gesamtfahrzeug-Level verzichtet, kann jedoch in der E/E-Entwicklung disziplinintern erfolgen. Die einzelnen Vorgehensweisen unterscheiden sich insbesondere in der Phase der Detailentwicklung in Abhängigkeit von der jeweils involvierten Disziplin. Im 3. Quartal 2010 hat das Fraunhofer IPK eine Umfrage unter deutschen Unternehmen aus der Automobilindustrie durchgeführt, deren Ergebnisse vom Verfasser dieser Arbeit bereits in Auszügen in [KÖNIGS ET AL. 2012] publiziert wurden. Ziel der Umfrage war die Erfassung von aktuellen Herausforderungen und Vorgehensweisen in der Automobilentwicklung. Fünf OEM s 10 und ein Zulieferer haben an der Umfrage teilgenommen. Die Methode der Umfrage sah ein zweistufiges Verfahren vor. Zunächst erhielten alle Ansprechpartner in den Unternehmen einen Fragebogen. Nachdem der ausgefüllte Fragebogen zurückgesandt und ausgewertet war, wurde ein ausführliches Telefoninterview durchgeführt. Die Kernergebnisse der Umfrage im Hinblick auf die verwendeten Entwicklungsphilosophien und -werkzeuge sollen im Folgenden näher vorgestellt werden. Methoden des modellbasierten Entwickelns sind in den Unternehmen unterschiedlich stark etabliert. Eine Gemeinsamkeit liegt hingegen in der starken Verbreitung von Office Produkten in allen Unternehmen, die im Rahmen der Produktentwicklung eingesetzt werden. Große 10 Original Equipment Manufacturer 30

60 2 Grundlagen der Entwicklung mechatronischer Produkte Unterschiede treten jedoch in der Anzahl der parallel verwendeten spezialisierten Softwarewerkzeuge, die je Unternehmen pro Entwicklungsphase eingesetzt werden, zutage (siehe Tabelle 1). Allein für das Verwalten der Anforderungen verwendet das Zuliefer-Unternehmen fünf verschiedene, während bei den OEMs je nach Unternehmen zwei bis vier unterschiedliche Werkzeuge parallel im Einsatz sind. Für die Beschreibung der Funktionen ergab sich ein ähnliches Bild: der Zulieferer nutzt auch in dieser Prozessphase fünf unterschiedliche Werkzeuge, während bei den OEMs je nach Unternehmen das Spektrum von zwei bis zu fünf Softwarelösungen reicht. Bei den hier genannten Funktionen muss jedoch berücksichtigt werden, dass es sich nicht um eine abstrakte, lösungsneutrale Beschreibung der Transformation von Eingangs- in Ausgangsgrößen im Sinne bspw. der VDI 2206 handelt, sondern um eine textuelle Beschreibung der für den Kunden erlebbaren Fahrzeugfunktionen (wie bspw. Infotainment), die eher einer erweiterten Anforderungsspezifikation entsprechen 11. Die größten Unterschiede zwischen den befragten Unternehmen traten hingegen bei der Modellierung des Verhaltens von Systemen auf: abhängig vom Unternehmen variierte die Anzahl der genutzten Werkzeuge von eins bis zu acht. Über ein solches breites Spektrum verfügt nicht einmal das Zuliefer-Unternehmen, das auch für diese Phase der Produktentwicklung fünf verschiedene Werkzeuge einsetzt. Prozessphase Tabelle 1: Unternehmen Zulieferer OEM1 OEM2 OEM3 OEM4 OEM5 Anforderungen Funktionen Verhalten 5 3 8? 1 6 Anzahl verwendeter Modellierungswerkzeuge je Unternehmen und Prozessphase Die Ergebnisse unterstreichen den Trend zu modellbasiertem Entwickeln, wodurch die Durchgängigkeit und Wiederverwendbarkeit der Entwicklungsdaten erhöht werden soll, auch wenn die Unternehmen unterschiedlich stark auf den Einsatz modellbasierter Werkzeuge vertrauen. Es konnte festgestellt werden, dass MATLAB/Simulink sich als Quasi-Standard für die Simulation dynamischen Systemverhaltens in der deutschen Automobilindustrie etabliert hat. Ganzheitliche und damit auch Disziplin-übergreifende Ansätze (wie bspw. Systems Engineering) werden bei den OEMs derzeit fast gar nicht gelebt. Eine umfassende, Disziplinübergreifende System-Modellierung zur Orchestrierung der Entwicklung ist nicht verbreitet, allerdings war zum Zeitpunkt der Umfrage bei einigen Unternehmen die Einführung übergreifender Werkzeuge zur Unterstützung der frühen Entwicklungsphasen in Planung. Eine ganzheitliche Modellierung der Systemarchitektur (z. B. mit SysML) wurde lediglich bei dem befragten Zulieferunternehmen praktiziert. 11 Diese Aussage steht somit nicht im Widerspruch zu den vorherigen Ausführungen, wonach eine Funktionsbeschreibung im Sinne der VDI 2206 auf Gesamtfahrzeug-Level nicht erfolgt. 31

61 2 Grundlagen der Entwicklung mechatronischer Produkte 2.4. ZUSAMMENFASSUNG, DISKUSSION UND SCHLUSSFOLGERUNGEN Den theoretischen und praktischen Vorgehensweisen ist gemein, dass sie im Wesentlichen der abstrahierten Sequenz aus Entwurf, disziplininterner Detailentwicklung und Integration & Absicherung folgen, obgleich nicht immer jede einzelne Prozessphase der theoretischen Modelle im Detail durchlaufen wird. Gemein ist den Vorgehensweisen ferner, dass im Rahmen des Entwicklungsprozesses eine Vielzahl an digitalen Artefakten erarbeitet wird (vgl. [EIGNER UND STELZER 2009, S. 78f; CHEN 2010]). Diese können sich in Abhängigkeit des zu entwickelnden Produkts sowie des Unternehmens in ihrem Typ, ihrer konkreten Struktur und ihrem Entwicklungszweck 12 unterscheiden. Zudem werden Artefakte, auch innerhalb eines Unternehmens, häufig in unterschiedlichen Software-Werkzeugen modelliert. Die am häufigsten verwendeten Artefakte - eine Auswahl der relevantesten Artefakttypen wurde in Kapitel 2.2 vorgestellt - liegen dabei in einer Inklusionshierarchie vor (siehe Kapitel 2.2.6). Alle Vorgehensmodelle basieren dabei darauf, dass im nachgelagerten Prozessschritt ein Artefakt entwickelt wird, das auf dem Inhalt des im vorhergehenden Prozessschritt definierten Artefakts basiert bzw. dieses in einem neuen Kontext weiter detailliert, konkretisiert, evaluiert oder integriert. Es bestehen somit zwischen den Artefakten der Produktentwicklung inhaltliche Abhängigkeiten [MOHAN ET AL. 2008, S. 922; EIGNER UND STELZER 2009, S. 79], die aber derzeit nicht umfassend nachverfolgt werden [NG 2006, S. 373]. Dadurch kann es zu einer Isolierung der Entwicklungsinhalte in den Artefakten kommen, obgleich diese dasselbe ingenieurtechnische Problem adressieren. Dieses Phänomen wird dadurch verstärkt, dass hochspezialisierte Entwickler in der Regel mit Spezialsoftware arbeiten, wodurch das derart generierte Produktwissen auf eine geringe Anzahl von Personen beschränkt bleibt [CHEN 2010]. Daraus folgt, dass jeder Entwickler eine individuelle Sicht auf das Produkt hat, die seinem Spezialwissen entspricht. Dadurch ist eine umfassende Betrachtung von Entwicklungsproblemen durch den gleichzeitigen Bedarf an benötigtem Spezialwissen und generalisiertem Produktverständnis häufig schwierig. Im schlimmsten Fall bilden sich zwischen den einzelnen Artefakten Inkonsistenzen, weil die Zusammenhänge zwischen ihnen nicht ersichtlich sind. Auch in dem beschriebenen industriellen Vorgehen stehen die einzelnen Artefakte zueinander in Relation. Insbesondere der Zuweisung der Anforderungen auf verschiedene Systeme kommt dabei eine große Bedeutung für die spätere Absicherung zu. Daher wird das Nachverfolgen der Abhängigkeiten von Anforderungen zu anderen Artefakten auch als Qualitätsmerkmal des Anforderungsmanagements interpretiert [International Organisation for Standardization 2009, S. 14]. Normalerweise werden im industriellen Kontext jedoch, falls überhaupt, Anforderungen, Testfälle und (Sub-)Systeme miteinander verknüpft, um die Absicherung zu unterstützen [BEIER ET AL. 2013]. 12 Beim Systems Engineering wird bspw. der Betrachtungsrahmen der Modellierung durch die Berücksichtigung von Personen, Einrichtungen etc. am breitesten gefasst, während bei der ISO die Betrachtung der Risiken und die Ableitung von entsprechenden Gegenmaßnahmen im Fokus stehen. 32

62 2 Grundlagen der Entwicklung mechatronischer Produkte Eine umfassende Modellierung der inhaltlichen Abhängigkeiten zwischen den Artefakten ist jedoch wünschenswert [NG 2006, S. 372], zumal dadurch auch in Industrieprojekten, bspw. durch die Identifikation von Inkonsistenzen [SUTINEN ET AL. 2000; DIEHL ET AL. 2008] oder die Abschätzung von Änderungsauswirkungen [MARTIN UND ISHII 2002], Synergien erzeugt werden können [CONRAD ET AL. 2005, S. 7]. So wird in [DIEHL ET AL. 2008] und [HASKINS 2006, S. 4.8] empfohlen, die modellierten Funktionen mit den Elementen der Produktstruktur zu verknüpfen. In [ULRICH 1995, S. 419] wird dieses Schema, bei dem die Funktionen eines Produkts seinen physischen Komponenten zugeordnet werden, als eigenständiges Artefakt namens Produktarchitektur behandelt. Daher sollten die inhaltlichen Abhängigkeiten zwischen den Elementen der Artefakte in einem sinnvollen Maße 13 explizit modelliert werden. Die Methode, die dieses Vorgehen behandelt, wird Traceability genannt und wird im weiteren Verlauf dieser Arbeit detailliert behandelt. 13 Die geeignete Granularität, in welcher die Abhängigkeiten zwischen den Artefakten modelliert werden müssen, richtet sich nach den Nutzenpotentialen, die sich aus deren Verwendung ergeben, und dem zur Modellierung benötigten Aufwand. 33

63

64 3. TRACEABILITY-GRUNDLAGEN In Kapitel 2 wurde dargestellt, dass die Entwickler im Rahmen der Produktentwicklung - unabhängig vom gewählten Vorgehensmodell - eine Vielzahl von Artefakten erzeugen. Der Anspruch an diese Artefakte ist es, in ihrer Gesamtheit das zu kreierende Produkt möglichst genau zu beschreiben. Da häufig ein Artefakt auf dem im vorherigen Prozessschritt modellierten Inhalt aufbaut, können zwischen den einzelnen Elementen der Artefakte inhaltliche Abhängigkeiten bestehen (schematische Darstellung siehe Abbildung 13). Bei einer KFZ- Klimaanlage, ein Beispielprodukt welches in dieser Arbeit gelegentlich zu Veranschaulichungszwecken verwendet wird, folgt aus der Anforderung Klimasystem soll Innentemperatur erfassen eine Funktion Messen der Innentemperatur, die wiederum durch einen Temperatursensor in der Produktstruktur realisiert wird. Abbildung 13: Schematische Darstellung der Abhängigkeiten zwischen unterschiedlichen Artefakten der Produktentwicklung 35

65 3 Traceability-Grundlagen Für einen Ingenieur ist daher es zur Erfüllung seiner Tätigkeit notwendig, diese aus dem Entwicklungsablauf resultierenden inhaltlichen Abhängigkeiten zu verstehen. Dies gilt einerseits für Abhängigkeiten, die aus vor- und nachgelagerten Entwicklungsphasen bspw. Beschränkungen des möglichen Lösungsraums bedeuten. Andererseits müssen ebenfalls Abhängigkeiten berücksichtigt werden, die sich durch parallel stattfindende Entwicklungen während derselben Prozessphase ergeben (bspw. durch Festlegungen von Entwicklern aus anderen Disziplinen, die einen direkten Einfluss auf das eigene Entwicklungsobjekt haben). Vereinfacht gesagt, beschäftigt sich die Methode Traceability mit dem expliziten Modellieren dieser Abhängigkeiten sowie deren Begleitprozessen. In diesem Kapitel wird daher zunächst eine Einführung in die Traceability-Thematik (Kapitel 3.1) gegeben, worin die Notwendigkeit erklärt, Begrifflichkeiten definiert und die Ursprünge der Traceability erläutert werden. In Kapitel 3.2 werden daraufhin die einzelnen Phasen der Traceability-Modellierung vorgestellt und diskutiert. Der aktuelle Stand von Wissenschaft und Technik hinsichtlich der beiden Phasen Planung von Traceability und Erfassung von Tracelinks, die im weiteren Verlauf der Arbeit nicht im Fokus stehen, wird in den Kapiteln 3.3 respektive 3.4 vorgestellt, während die existierenden Software-Werkzeuge und Methoden zur Modellierung und Verwaltung von Traceability-Modellen in Kapitel 3.5 dargelegt werden. In Kapitel 3.6 wird das selbst entwickelte Traceability-Werkzeug ModelTracer vorgestellt. Die Ausführungen zu den Grundlagen der Traceability werden abschließend in Kapitel 3.7 zusammengefasst EINFÜHRUNG IN DIE TRACEABILITY-MODELLIERUNG Um nachvollziehen zu können, warum die Einführung von Traceability für die Entwicklung mechatronischer Systeme unter Umständen sinnvoll ist, müssen zunächst deren Wesensmerkmale verstanden werden. Daher wird zunächst in Kapitel die Notwendigkeit von Traceability motiviert und umrissen, in welchen Szenarien ihre Anwendung hilfreich ist. Anschließend wird in Kapitel die wesentliche Terminologie eingeführt und diskutiert, bevor in Kapitel die chronologischen Ursprünge und die Weiterentwicklungen der Methode Traceability vorgestellt werden MOTIVATION DER NOTWENDIGKEIT VON TRACEABILITY Systeme bestehen laut Definition aus einer Anzahl an Teilsystemen und Elementen, die miteinander in Beziehung stehen, durch eine Systemgrenze von der Umwelt abgegrenzt werden können [EHRLENSPIEL 2007, S. 20] und mindestens einem Zweck dienen [HASKINS 2006, S. 1.5]. Mechatronische Produkte beinhalten Systeme und können selbst als solche betrachtet werden, wobei Beziehungen zwischen den einzelnen, beinhalteten Teilsystemen immer stärker vernetzt werden und deren Anzahl zunimmt [BERTSCHE ET AL. 2009, S. 3]. Berücksichtigt man, dass die Komplexität 14 eines Systems von der Anzahl und Unterschiedlichkeit sowohl der konstituierenden Teilsysteme als auch der Abhängigkeiten untereinander ab- 14 Eine ausführliche und differenzierte Betrachtung der unterschiedlichen Facetten des Begriffs Komplexität kann [SCHUH 2005] und [LINDEMANN ET AL. 2009] entnommen werden. 36

66 3 Traceability-Grundlagen hängt 15 [LANE 2006, S. 81f; EHRLENSPIEL 2007, S. 36; WEILKIENS 2008, S. 10], kann festgehalten werden, dass mechatronische Systeme immer komplexer werden [ABRAMOVICI 2005; TRETOW ET AL. 2008, S. 36; BERTSCHE ET AL. 2009, S. 3]. Gleiches gilt für das Entwicklungssystem großer OEM s hinsichtlich der Entwicklungsprozesse, der Organisationsstrukturen und IT-Bebauung (siehe auch Kapitel 2.3). Allein die Organisation einer Kollaboration über Zeitzonen, Sprachbarrieren und Kontinente hinweg stellt eine enorme Herausforderung dar. Um die Zusammenhänge zwischen den genannten komplexen Einzelgebilden besser verstehen zu können, hilft es, deren Interdependenzen explizit abzubilden [MOHAN ET AL. 2008, S. 922]. Dies ist besonders relevant vor dem Hintergrund, dass mechatronische Systeme zwingend von Entwicklern aus den unterschiedlichen Disziplinen Mechanik, Elektrik, Elektronik und Software gemeinsam entwickelt werden müssen. Das Kritische an den heterogenen Entwicklungsteams sind die verschiedenen Vorgehensweisen und die unterschiedlichen Terminologien, die in den jeweiligen Disziplinen über Jahre hinweg entstanden sind und sich bewährt haben, im Rahmen der gemeinsamen Entwicklung jedoch integriert werden müssen. Traceability hilft auch hier, eine gemeinsame Sicht auf das zu entwickelnde System zu schaffen, indem Objekte miteinander in Relation gesetzt werden, auch wenn sie in den Disziplinen unterschiedlich bezeichnet oder betrachtet werden. Traceability ist also kein Selbstzweck, sondern unterstützt das Disziplin-übergreifende Systemverständnis [JARKE UND POHL 1993, S. 32; PINHEIRO 2003; MOHAN ET AL. 2008, S. 922; BODE UND RIEBISCH 2009, S. 88]. Sie hilft zusätzlich dem Management, Entscheidungen fundiert zu treffen, und den Entwicklern, diese nachvollziehen zu können [CHEN 2010, S. 505; RIEBISCH ET AL. 2011, S. 12]. Das liegt u. a. daran, dass die Methode Traceability eine gute und vergleichsweise schlanke Vorgehensweise darstellt, um vormals isolierte Modelle und Werkzeuge inhaltlich koppeln zu können. Die Abhängigkeiten zwischen den im Rahmen der Produktentwicklung kreierten Artefakten (bspw. Anforderungen, Funktionen, Produktstrukturen), die meist nur implizit durch das Wissen der Entwickler repräsentiert sind, müssen dazu mit Hilfe von informationstechnischen Objekten, sog. Tracelinks, explizit modelliert werden [VAN GORP ET AL. 2006]. Aus diesen Gründen wird Traceability von einer Vielzahl von Standards und Modellierungsrichtlinien aus unterschiedlichen Disziplinen, wie bspw. MIL-STD-498, MIL-STD-2167A (vgl. [RAMESH ET AL. 1997, S. 397]), IEEE/EIA 12207, IEEE Std. 1219, ISO 9000ff, ISO 15504, ISO/IEC oder der ISO 26262, verlangt (vgl. [GOTEL UND FINKELSTEIN 1994, S. 94; AIZENBUD-RESHEF ET AL. 2006, S. 516; WINKLER UND PILGRIM 2010, S. 544]). Ihre Implementierung wird in der Softwareentwicklung als Maß für die Systemqualität [WINKLER UND PILGRIM 2010, S. 544] und die Prozessreife gewertet [AIZENBUD-RESHEF ET AL. 2006, S. 516]. Mit diesem Wissen lässt sich nachvollziehen, warum das US Verteidigungsministerium ca. 4% seines Entwicklungsbudgets für Traceability verwendet [RAMESH ET AL. 1997, S. 398]. Ein wesentlicher Nutzen von Traceability besteht darin, dem Kunden gegenüber nachweisen zu 15 WEBER erweitert diese Definition um drei weitere Dimensionen: die Anzahl der Varianten eines Produkts, die Anzahl der an der Entwicklung beteiligten Disziplinen und die organisatorischen Strukturen [WEBER 2005, S. 1788]. 37

67 3 Traceability-Grundlagen können, dass einerseits alle Anforderungen in Funktionen umgesetzt [MOHAN UND RAMESH 2007, S. 976] und andererseits keine nicht-geforderten, und damit unnötigen, Funktionen implementiert wurden [RAMESH ET AL. 1997, S. 398]. Das größte Hindernis auf dem Weg zu einer breiteren Akzeptanz von Traceability im industriellen Systems-Engineering-Kontext ist das unausgeglichene Verhältnis zwischen notwendigem Aufwand (ergo Kosten) und dem daraus erzielbaren Nutzen [AIZENBUD-RESHEF ET AL. 2006, S. 519]. So wird in [RAMESH ET AL. 1997, S. 410] von Entwicklungsprojekten berichtet, bei denen die generierten Kosten für Traceability die erwarteten Aufwände deutlich überstiegen. Daher muss es der Anspruch an die Traceability-Forschung sein, zum einen das Erzeugen und Warten der Traceability-Daten effizienter zu ermöglichen und zum anderen den ableitbaren Nutzen aus diesen Daten zu erhöhen. Letztgenannte Herausforderung ist das zentrale Anliegen der vorliegenden Arbeit. Doch trotz dieser bestehenden Herausforderungen, sollte Traceability im Rahmen der Entwicklung komplexer technischer Systeme bereits heute praktiziert werden. Diese Überzeugung bringt das folgende Zitat aus [STEVENS ET AL. 1998, S. 345] sehr gut auf den Punkt: Moderne Systeme sind umfangreich, komplex und kompliziert 16 zu entwickeln. Man benötigt Disziplin, Organisation, Traceability, Planung und eine Zuordnung der Verantwortlichkeiten um ein effizientes Entwickeln zu ermöglichen. In der Vergangenheit wurden in der Forschung unterschiedliche Aspekte der Traceability betrachtet (siehe Kapitel 3.1.3), die in ihrer jeweiligen Definition Berücksichtigung fanden. Diese Vielzahl an Betrachtungsweisen hat dazu geführt, dass sich bisher keine einheitliche Traceability-Definition in der Wissenschaft etabliert hat [WINKLER UND PILGRIM 2010]. Eine Auswahl existierender Begriffsdefinitionen soll in Kapitel vorgestellt und diskutiert werden, auf deren Grundlage eine Definition für den weiteren Verlauf der Arbeit abgeleitet werden soll TRACEABILITY-GRUNDBEGRIFFE UND -DEFINITIONEN Eine recht allgemeine Definition des Begriffs Traceability ist im Standard Glossary of Software Engineering Terminology der IEEE aufgeführt. Danach ist Traceability das Ausmaß, in dem eine Beziehung zwischen zwei oder mehr Produkten des Entwicklungsprozesses etabliert werden kann [IEEE Computer Society 1990, S. 78]. In [EDWARDS 1992] wird Traceability hingegen als Technik beschrieben, um Relationen zwischen den Artefakten Anforderungen, Design und finaler Implementierung eines Softwaresystems zu erreichen. Eine ähnliche Definition wird in [ARNOLD UND BOHNER 1993, S. 293] vorgeschlagen, wo Traceability als Fähigkeit beschrieben wird, um auf Grundlage von spezifischen Abhängigkeiten zu bestimmen, welche Elemente mit anderen Elementen in Relation stehen. Im Kontext des Anforderungsmanagements wird Traceability hingegen deutlich eingegrenzter aus Sicht der Anforderungen bzw. der zugehörigen Anforderungsspezifikation definiert. In 16 Kompliziertheit ist (im Unterschied zur Komplexität) ein Maß für die subjektive Schwierigkeit bei der Behandlung von technischen Systemen [EHRLENSPIEL 2007, S. 36] 38

68 3 Traceability-Grundlagen diesem Zusammenhang bezeichnet Requirements Traceability die Fähigkeit, den Lebenszyklus einer Anforderung sowohl in Richtung eines fortschreitenden Prozesses 17, bis hin zum Softwarecode, als auch in entgegengesetzter Richtung, zu ihren Ursprüngen 18, zu beschreiben und nachzuvollziehen [GOTEL UND FINKELSTEIN 1994, S. 94]. Auch in [PINHEIRO UND GOGUEN 1996] wird eine Definition in Bezug auf die durchgängige Nachverfolgbarkeit von Anforderungen vorgeschlagen. Darin wird Requirements Traceability etwas unkonkret als Fähigkeit beschrieben, das gegenseitige Hinterlassen von Spuren zwischen Anforderungen und anderen Elementen der Software-Entwicklungsumgebung zu definieren, zu erfassen und zu verfolgen. Diese Zentrierung der Definition des Begriffs Traceability auf das Artefakt Anforderungen wird in [SPANOUDAKIS UND ZISMAN 2005] nicht vorgenommen. Dafür werden darin die Aspekte Sichtenbildung und Abstraktionslevel erstmals berücksichtigt. Traceability wird daher als Fähigkeit definiert, beliebige Artefakte, die im Rahmen der Softwareentwicklung kreiert wurden, in Relation zu setzen, um das System aus unterschiedlichen Perspektiven und auf unterschiedlichen Abstraktionsleveln zu beschreiben. Dieser Verallgemeinerung auf eine Nachverfolgbarkeit zwischen beliebigen Artefakten der Softwareentwicklung folgen auch AIZENBUD-RESHEF ET AL.: sie prägen dafür den Terminus Model Traceability, der primär den Kontext modellbasierte Softwareentwicklung adressiert und eine beliebige Beziehungen zwischen Artefakten des Softwareentwicklungszyklus beschreibt [AIZENBUD-RESHEF ET AL. 2006, S. 516]. Aus dieser Vielzahl unterschiedlicher Definitionen, die alle die Softwareentwicklung adressieren, lässt sich eine Definition ableiten, die auch für die Entwicklung mechatronischer Systeme gültig ist. Für den weiteren Verlauf der Arbeit soll daher folgende Definition des Begriffes Traceability Gültigkeit haben: Traceability ist eine Methode zur Unterstützung der Entwicklung mechatronischer 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 Artefakten, wird ebenfalls mit dem Begriff Traceability beschrieben. Für das explizite, rechentechnische Dokumentieren der Abhängigkeiten zwischen zwei Elementen werden sog. Tracelinks verwendet [CLELAND-HUANG ET AL. 2003, S. 797]. Sie entsprechen den in [HESSE UND MAYR 2008, S. 388] definierten Anforderungen an Referenzen, keine strukturbildende Objekteinbettung darzustellen, sondern lediglich einen Verweis aus dem referenzierenden Element heraus zum referenzierten Element. Tracelinks werden dabei durch Software-Objekte repräsentiert, die üblicherweise das eindeutige Identifizieren der beiden verknüpften Elemente erlauben [VAN GORP ET AL. 2006]. Zusätzlich wird in [CLELAND- 17 Engl. Fachbegriff: Forward Traceability; eine Verallgemeinerung hin zu einem beliebigen Ausgangsartefakt ist in [IEEE ] beschrieben 18 Engl. Fachbegriff: Backward Traceability; eine Verallgemeinerung hin zu einem beliebigen Ausgangsartefakt ist in [IEEE ] beschrieben 39

69 3 Traceability-Grundlagen HUANG ET AL. 2003, S. 797] zwischen direkten und indirekten Tracelinks unterschieden. Demnach sind zwei Elemente A und C über einen indirekten Tracelink verbunden, wenn mindestens ein weiteres Element B notwendig ist, um A und C zu verbinden: A B C. Ein direkter Tracelink hingegen verbindet die zwei Elemente A und C ohne ein weiteres Zwischenelement: A C. Tracelinks können eine Vielzahl weiterer Eigenschaften und Metadaten enthalten, die es ermöglichen, detaillierte Analysen durchzuführen oder deren Entstehung zu dokumentieren [RAMESH UND JARKE 2001; EGYED UND GRÜNBACHER 2005; AIZENBUD-RESHEF ET AL. 2006]. Eine Auswahl der weiteren Ausprägungsmöglichkeiten wird in Kapitel vorgestellt. Im folgenden Kapitel werden jedoch zunächst die Ursprünge und die chronologische Weiterentwicklung der Traceability vorgestellt URSPRUNG UND ZEITLICHE WEITERENTWICKLUNG DER TRACEABILITY Die Methode Traceability entstammt ursprünglich dem Bereich des Anforderungsmanagements in der Softwareentwicklung. Dazu wurde im Jahre 1978 erstmals ein Softwarewerkzeug, das Requirements Tracing Tool, zum Umgang mit Tracelinks veröffentlicht [PIERCE 1978]. In den folgenden Jahren wurde weiter im gleichen thematischen Kontext geforscht. Zu den herausragenden Veröffentlichungen aus dem Umfeld Traceability im Anforderungsmanagement der Softwareentwicklung zählen u. a. [RAMESH UND EDWARDS 1993; GOTEL UND FINKELSTEIN 1994; PINHEIRO UND GOGUEN 1996; RAMESH ET AL. 1997; PINHEIRO 2003; EGYED 2003]. Dabei wird neben dem Verknüpfen der Anforderungen untereinander auch die Verknüpfung von Anforderungen mit anderen Artefakten betrachtet. In [RAMESH UND EDWARDS 1993] wird anhand eines akademischen Software-Projektes studiert, inwieweit durch die durchgängige Nachverfolgung von Anforderungen zu unterschiedlichen Ausgangsgrößen, wie bspw. Hardware, Software-Code, Anleitungen und Prozeduren, deren tatsächliche Berücksichtigung und Umsetzung verbessert werden kann. In [GOTEL UND FINKELSTEIN 1994] werden Ergebnisse einer Studie sowie ein Framework zum Thema Anforderungstraceability vorgestellt. In [PINHEIRO UND GOGUEN 1996] wird mit TOOR (Traceability of Object-Oriented Requirements) ein Werkzeug vorgestellt, mit welchem Anforderungen durch nutzer-definierbare Relationen zu Spezifikationen, Code und anderen Entwicklungsartefakten verknüpft werden können. Eine theoretische Übersicht zum Thema Requirements Traceability wird in [RAMESH ET AL. 1997] bereitgestellt. Darin werden neben Definitionen, allgemeinen Zielen und Herausforderungen sowie dem damaligen Stand der Technik auch ein eigenes Framework und die Ergebnisse einer Fallstudie vorgestellt. Eine noch ausführlichere und gut strukturierte theoretische Abhandlung kann dem Buchkapitel [PINHEIRO 2003] entnommen werden. Auch EGYED betrachtet Traceability zwischen Anforderungen und einer Vielzahl anderer Artefakte der Softwareentwicklung. Dabei wird ein Ansatz zum automatischen Vorschlagen und Validieren potentieller Tracelinks vorgestellt [EGYED 2003]. Dieser Ansatz wird in [EGYED UND GRÜNBACHER 2005] dahingehend erweitert, dass eine Werkzeug-unterstützte Methode prä- 40

70 3 Traceability-Grundlagen sentiert wird, bei der zunächst Entwickler manuell Tracelinks identifizieren müssen, auf deren Grundlage dann weitere Tracelinks automatisch generiert werden können. Neben der Fokussierung auf das Artefakt Anforderungen fand eine Erweiterung des Ansatzes auf die modellbasierte Entwicklung beliebiger Software-Artefakte statt. Traceability wurde demnach nicht mehr von der Vorstellung begrenzt, Anforderungen untereinander zu verknüpfen bzw. ausschließlich diese in das Zentrum der Traceability-Betrachtungen zu rücken. Eine Auswahl der herausragenden Publikationen zu dieser Thematik wird im Folgenden vorgestellt. In [NEJMEH ET AL. 1989] werden die Möglichkeiten erörtert, mittels Traceability Lebenszyklusobjekte derselben bzw. unterschiedlicher Entwicklungsphasen zu verknüpfen. Diese Idee unterstützen auch PFLEEGER UND BOHNER, wobei darin vier exemplarische Software-Artefakte (Anforderungen, Analyse, Design, Code) mit der Zielsetzung einer besseren Wartbarkeit verknüpft werden [PFLEEGER UND BOHNER 1990]. In [LINDVALL UND SANDAHL 1996] wird neben einer, mit Beispielmodellen veranschaulichten, Klassifizierung von Software-Traceability auf Basis der jeweiligen Charakteristika der zu verknüpfenden Objekte (Element, Relation, Use Case oder Element im Kontext einer Hierarchie) auch ein Ansatz zur hierarchischen Vererbung von Tracelinks innerhalb eines Artefaktes vorgestellt. CLELAND-HUANG ET AL. stellen das Konzept Event-based Traceability vor, bei dem das Traceability-Modell 19 aktuell gehalten wird, indem im Falle der Änderung eines Elementes eine sog. Event Engine alle jeweils verantwortlichen Bearbeiter der direkt verknüpften Elemente identifiziert und über die Änderung in Kenntnis setzt. Durch diesen Ereignis-basierten Mitteilungsservice soll der Aufwand zur Pflege der Traceability-Daten über den Lebenszyklus hinweg minimiert werden [CLELAND- HUANG ET AL. 2003]. Ein Überblicksartikel über den Stand der Anwendung und Technik sowie offene Forschungsfragen im Bereich Traceability in der Softwareentwicklung wird in [SPANOUDAKIS UND ZISMAN 2005] geliefert. Dabei werden unterschiedliche Typisierungen von Tracelinks, verschiedene Methoden zu deren Erzeugung, Verwaltung und Nutzung betrachtet. Die Erweiterung des Traceability-Ansatzes über das Artefakt Anforderungen hinaus auf jedwede Art von Modellen bzw. Artefakten, die im Rahmen der Produktentwicklung kreiert werden, wird bei [AIZENBUD- RESHEF ET AL. 2006] bereits im Titel deutlich, wo der allgemeinere Begriff Model Traceability benutzt wird. Die Veröffentlichung bietet eine Einführung, einen Überblick über den Stand der Technik sowie eine kritische Diskussion offener Herausforderungen der Thematik. Zu Letzteren werden insbesondere die mangelhafte Integration der Werkzeuge sowie das Fehlen eines einheitlichen Traceability-Metamodels für die modellbasierte Softwareentwicklung gezählt. Unabhängig von den unterschiedlichen historischen Ausgangspunkten hinsichtlich der Traceability-Betrachtungen, wurden auch theoretische Überlegungen zum Umgang mit die- 19 Der Begriff Traceability-Modell bezeichnet die Gesamtheit aus betrachteten Artefakten und ihrer, die gegenseitigen Abhängigkeiten beschreibenden, Tracelinks (in Anlehnung an [PINHEIRO 2003, S. 106]). 41

71 3 Traceability-Grundlagen sen Daten und deren Integration in einen Traceability-Prozess publiziert. Eine Übersicht zu den Phasen dieses Prozesses wird in Kapitel 3.2 vorgestellt 3.2. PHASEN DER TRACEABILITY-MODELLIERUNG Hinsichtlich der Aufteilung der einzelnen Traceability-bezogenen Aktivitäten gibt es unterschiedliche Vorschläge, wie diese zu klassifizieren sind. Ausgewählte Konzepte aus der Literatur werden an dieser Stelle vorgestellt. In [SCHWARZ ET AL. 2010, S. 473] wird das differenzierteste Konzept vorgestellt. Es wird in sechs verschiedene Traceability-Phasen unterschieden, die im Folgenden kurz vorgestellt werden. 1. Traceability-Definition: Festlegung der möglichen Elementtypen und Relationstypen für das Traceability-Datenmodell. 2. Traceability-Identifikation: Entdeckung der eigentlichen Abhängigkeit zwischen zwei Elementen als mentale Leistung. 3. Traceability-Erfassung: softwaretechnische Erfassung der Tracelinks in Form von Datenstrukturen. 4. Traceability-Pflege: Aktualisierung und Modifikation von bereits existierenden Traceability-Modellen, um der dynamischen Produktevolution gerecht zu werden. 5. Traceability-Erkennung: Automatische algorithmische Erkennung von noch nicht erkannten Abhängigkeiten zwischen zwei Elementen. 6. Traceability-Verwendung: Anwendung und Nutzung von bereits modellierten Traceability-Modellen in einem konkreten Szenario. Bei [PINHEIRO 2003] wird hingegen in drei Phasen unterschieden: die Definition, die Produktion und die Extraktion. Dabei beinhaltet die Produktion die Phasen 2 und 3 aus [SCHWARZ ET AL. 2010, S. 473], die Extraktion entspricht der Phase 5 während die Phasen Verwendung und Pflege keine Berücksichtigung finden. In [WINKLER UND PILGRIM 2010, S. 539] wird in vier Phasen unterschieden: Planung (entspricht der Phase Traceability-Definition aus [SCHWARZ ET AL. 2010, S. 473]), Erfassung (das die Phasen 2, 3 und 5 aus [SCHWARZ ET AL. 2010, S. 473] beinhaltet), Nutzung und Pflege. Da im Rahmen dieser Arbeit Traceability für die Entwicklung mechatronischer Produkte behandelt wird, darf die automatische Erkennung von Tracelinks nicht als erzeugender Prozess klassifiziert werden. Aufgrund der Unterschiede zur Software-Entwicklung (siehe Kapitel 3.4.2) muss in der Mechatronik die endgültige Entscheidung über das Anlegen eines Tracelinks durch menschliche Expertise von Entwicklern gefällt werden. Daher können Algorithmen in der Mechatronik am sinnvollsten genutzt werden, um Vorschläge zu generieren, die fehlende oder falsche Tracelinks bereits existierender Traceability-Modelle aufzeigen. Aber auch diese Vorschläge müssen anders als in der Software-Entwicklung schlussendlich von einem Experten bewertet werden. Dieser Prozess des Identifizierens von Fehlern im Traceability-Modell entspricht am ehesten einem Pflegeprozess. Daher wird die Phase 42

72 3 Traceability-Grundlagen Traceability-Erkennung im Rahmen dieser Arbeit im Widerspruch zur Auffassung von [WINKLER UND PILGRIM 2010, S. 539] der Traceability-Pflege zugerechnet. Abgesehen von dieser Zuordnung der Phase Traceability-Erkennung orientieren sich die Ausführungen in der vorliegenden Arbeit an der Klassifizierung laut [WINKLER UND PILGRIM 2010, S. 539]. Es wird somit in vier Lebenszyklusphasen der Traceability-Modellierung unterschieden: die Planung von Traceability (beinhaltet die Phase 1 aus [SCHWARZ ET AL. 2010, S. 473]), die Erfassung (beinhaltet die Phasen 2 und 3 aus [SCHWARZ ET AL. 2010, S. 473]), die Verwendung und die Pflege (beinhaltet die Phasen 4 und 5 aus [SCHWARZ ET AL. 2010, S. 473]) der Tracelinks. Hauptgegenstand der vorliegenden Arbeit ist die Vorstellung und Diskussion einer Vielzahl von Möglichkeiten aus der oben genannten Phase Verwendung von Traceability-Modellen. Theoretische Grundlagen der Phasen Traceability-Planung, Tracelink-Erfassung und -Pflege sollen im Folgenden kurz vorgestellt werden PLANUNG VON TRACEABILITY Bei der Planung müssen verschiedene Eigenschaften der gewünschten Traceability- Methode festgelegt werden. Grundsätzlich sind diese Optionen zu klären, bevor mit der eigentlichen Erfassung der Tracelinks begonnen werden kann. Unter anderem ist zu spezifizieren, zwischen welchen Artefakten die Abhängigkeiten modelliert werden sollen, welche Datenstruktur die Artefakte haben können und welche Ausprägung die Tracelinks haben dürfen. Ebenso muss die Kopplung mit den Autorenwerkzeugen sowie eventuelle Schreibrechte in diesen und der Speicherort der Tracelinks definiert werden. Aber auch die angestrebte Granularität der Traceability-Modellierung ist projektspezifisch festzulegen. Im später folgenden Kapitel 3.5 wird erläutert, welche der hier vorgestellten Eigenschaften von welchen der existierenden Traceability-Werkzeuge angeboten wird. Eine zusammenfassende Übersicht mit einer Zuordnung von ausgewählten Werkzeugen zu den im Folgenden erläuterten Eigenschaften wird in Tabelle 2 auf Seite 62 gegeben TRACEABILITY-EIGENSCHAFTEN Die wesentlichen Traceability-Eigenschaften, die bei der Planung berücksichtigt und spezifiziert werden müssen, werden im Folgenden kurz erläutert. Akquisition der Artefakte. Bei der Akquisition der Artefakte können zwei verschiedene Strategien gewählt werden. Integrative Traceability-Werkzeuge importieren bzw. synchronisieren die Artefakte aus den verwendeten Autorenwerkzeugen [POHL 1996, S. 91; HOFFMANN ET AL. 2004, S. 304; VAN GORP ET AL. 2006, S. 55]. Nicht-integrative Traceability-Werkzeuge 43

73 3 Traceability-Grundlagen sind hingegen so konzipiert, dass sie die Modellierung von Tracelinks zwischen Artefakten unterstützen, die hauptsächlich im Werkzeug selbst aufgebaut werden. Können also beispielsweise die Anforderungen aus DOORS zum Verknüpfen direkt in das Traceability-Werkzeug geladen werden, läge ein integrativer Ansatz vor. Müssten die Anforderungen vor dem Verknüpfen erst im Traceability-Werkzeug nachmodelliert werden, wäre dieses ein nicht-integratives Werkzeug. In [AIZENBUD-RESHEF ET AL. 2006, S. 523] wird die derzeit unzureichende Integration der Autorenwerkzeuge als eine der wesentlichen Herausforderungen zur stärkeren Verbreitung von Traceability bewertet. Manipulierbarkeit der Artefakte. Einige Traceability-Werkzeuge sehen einen schreibenden Zugriff auf die Artefakte selbst und damit auf das Autorenwerkzeug vor. Andere Traceability- Werkzeuge erlauben nur einen lesenden Zugriff auf die Artefakte, um deren Modifikation ausschließlich im eigentlichen Autorenwerkzeug zu forcieren. Kann im Traceability-Werkzeug der Inhalt einer Anforderung verändert werden, so realisiert dieses einen schreibenden Zugriff auf die Artefakte des Autorenwerkzeugs. Kann die Anforderung jedoch nur im Autorenwerkzeug (wie bspw. DOORS), aber nicht im Traceability- Werkzeug modifiziert werden, erlaubt letzteres nur einen lesenden Zugriff auf die Artefakte. Duplikation der Artefakte. Die zu verknüpfenden Artefakte können entweder Originaldaten sein, die im Autorenwerkzeug genutzt werden und erzeugt wurden. Alternativ können kopierte Daten verwendet werden, die im entsprechenden Traceability-Werkzeug zum Zweck der Traceability-Modellierung erzeugt wurden. Das Nutzen von Originaldaten reduziert das Risiko von Daten-Inkonsistenzen, erfordert jedoch eine funktionierende IT-Integration zwischen den Autorenwerkzeugen und dem Traceability-Werkzeug. Speicherort der Tracelinks. In Abhängigkeit von der konkreten Implementierung des Traceability-Ansatzes können die Tracelinks an verschiedenen Stellen gespeichert und verwaltet werden: zentral in einem separaten Modell oder verteilt in den Artefakten im jeweiligen Autorenwerkzeug [International Organisation for Standardization 2009, S. 12; WINKLER UND PILGRIM 2010]. Die verteilte Verwaltung von Tracelinks wird in [AIZENBUD-RESHEF ET AL. 2006, S. 518] durchaus kritisch betrachtet, da dadurch die Möglichkeit einer gemeinsamen Analyse aller Tracelinks eingeschränkt, der Integrationsaufwand bei der Ergänzung neuer Artefakte und Werkzeuge stark erhöht und die Sichtbarkeit der Tracelinks verhindert wird. Dies ist dann der Fall wenn bspw. der Tracelink ausschließlich im Quellartefakt 20 gespeichert ist und er somit nicht mehr vom Zielartefakt aus identifiziert werden kann. Genau diese Verfügbarkeit der Traceability-Informationen für alle Entwickler ist jedoch eine zentrale Forderung in [BURGAUD 2006]. Traceability-Schema. Tracelinks sollten über alle produktrelevanten Artefakte hinweg und damit entlang aller Phasen der Produktentstehung modelliert werden [RAMESH ET AL. 1997, S. 401]. Dennoch ist es weder sinnvoll noch effizient, alle Artefakte untereinander zu ver- 20 Gerichtete Tracelinks verlaufen von einer Quelle (bzw. einem Quellelement) in einem Quellartefakt zu einem Ziel (bzw. einem Zielelement) in einem Zielartefakt. 44

74 3 Traceability-Grundlagen knüpfen. Unterschiedliche Vorschläge, welche Artefaktpaarungen miteinander verknüpft werden müssen, sind in der Literatur zahlreich beschrieben: so wird in [ULRICH 1995, S. 419] empfohlen, Funktionen mit Bauteilen zu verknüpfen, während [SUTINEN ET AL. 2000, S. 317] empfiehlt, Anforderungen mit Bauteilen und diese wiederum mit Testfällen zu verlinken. Generell sollte diese Entscheidung spezifisch für jedes Entwicklungsprojekt getroffen werden [CLELAND-HUANG ET AL. 2003, S. 798]. Ein Traceability-Schema liegt vor, wenn für das Traceability-Werkzeug ein Metamodell beschrieben wird, in dem spezifiziert ist, welche Art von Tracelinks zwischen welchen Artefaktoder gar Elementpaarungen zulässig sind [SPANOUDAKIS UND ZISMAN 2005; WINKLER UND PILGRIM 2010, S. 535]. So wäre es bspw. denkbar, dass ein Traceability-Schema vorgibt, dass nur funktionale Anforderungen mit Funktionen verknüpft werden dürfen, während nichtfunktionale Anforderungen mit Elementen der Produktstruktur zu verknüpfen sind. In [DRIVALOS ET AL. 2008] wird dieser Ansatz weitergedacht, was zu dem Vorschlag einer Traceability-Metamodelling-Language führt. Generell stellt die Nutzung eines Traceability- Schemas eine Restriktion der Modellierungsflexibilität dar. Dies muss jedoch kein Nachteil sein, da es andererseits eine größere Unterstützung bei der Modellierung und Interpretation des Traceability-Modells ermöglicht. Traceability-Typ. Mit der Traceability-Modellierung wird immer ein bestimmter Zweck verfolgt. In Abhängigkeit von diesem Zweck muss zwischen zwei Traceability-Typen ausgewählt werden, die sich durch ihren Informationsgehalt unterscheiden. Qualitative Traceability ermöglicht ausschließlich die Identifikation von verknüpften Elementen, während bei der quantitativen Traceability ermittelt werden kann, wie stark ein bestimmter Wert des verknüpften Elements beeinflusst wird [SUTINEN ET AL. 2002]. Bei der quantitativen Traceability werden dem Entwickler mehr Informationen bereitgestellt, jedoch ist der erforderliche Modellierungsaufwand deutlich höher. Des Weiteren ist quantitative Traceability schwieriger zu managen [SUTINEN ET AL. 2000, S. 320]. Granularität der Modellierung. Bei der Traceability-Modellierung können unterschiedliche Detaillierungslevels gewählt werden [RAMESH ET AL. 1997, S. 402]. Diese Entscheidung hat erheblichen Einfluss sowohl auf den erforderlichen Modellierungsaufwand als auch auf die späteren Nutzungspotentiale. Die angestrebte Granularität muss im Unternehmen strategisch festgelegt werden, um zu verhindern, dass unterschiedlich detailliert modelliert wird, was entweder unnötig hohen Modellierungsaufwand zur Folge hat oder die spätere Nutzung limitiert, wenn nicht ausreichend detailliert modelliert wurde [CIMITILE ET AL. 1999, S. 212]. Das Spektrum der möglichen Granularität der Traceability-Modellierung reicht dabei von einer Verknüpfung auf oberster Hierarchieebene der Artefakte über deren Elemente bis zum Parameterlevel, in dem einzelne physikalische Attribute der Elemente konkretisiert werden (siehe Abbildung 14). Die spezifische Ausprägung der Modellierungsgranularität richtet sich dabei nach dem Traceability-Zweck. So kann durch eine Verknüpfung auf Artefaktebene u. a. eine Art Metamodell der Abhängigkeiten zwischen den Produkt-beschreibenden Artefakten erzeugt werden, wie es bspw. vom Werkzeug Reqtify (siehe Kapitel 3.5.2) angeboten wird, während über eine Verknüpfung auf Parameterebene z. B. ein, in den Anforderungen 45

75 Hierarchische Ebene Detaillierungsgrad 3 Traceability-Grundlagen spezifizierter, Wert zum Reaktionsverhalten eines Systems mit dem entsprechenden Simulationsergebnis des zugehörigen Verhaltensmodells verknüpft werden kann. Eine Abwägung der zu wählenden Modellierungsgranularität muss immer vor dem Hintergrund ökonomischer Randbedingungen erfolgen [LINDVALL UND SANDAHL 1996; WINKLER UND PILGRIM 2010, S. 535]. hoch Artefakt 1 1..* consists of abstrakt Mögliche Modellierungsgranularität Artefakt Artefakt * Hierarchical Relation Element 1 has Element Element niedrig 0..* detailliert Parameter Parameter Parameter Abbildung 14: Mögliche Granularitäten in der Traceability-Modellierung Unterstützte Datenstrukturen. Im Rahmen der Entwicklung mechatronischer Produkte sind Ingenieursdaten in der Regel in Form von Listen oder Baumhierarchien strukturiert. Eine besondere Form der Verknüpfung zwischen den Elementen kann aber auch zu Poly- Hierarchien (ein Kindelement gehört zu mehreren Elternelementen) oder zu Netzstrukturen führen. Es muss sichergestellt sein, dass das gewählte Traceability-Werkzeug die benötigten Datenstrukturen importieren und verarbeiten kann TRACELINK-EIGENSCHAFTEN Neben den allgemeinen Eigenschaften des Traceability-Konzepts muss auch über die konkrete Ausprägung der zu erstellenden Tracelinks entschieden werden. Dabei gibt es unterschiedliche Kategorien, die bei der Auswahl betrachtet werden müssen [MARCUS ET AL. 2005, S. 57]. Über viele dieser Kategorien gibt es in der Literatur keine einheitliche, inhaltliche Klassifizierung und Terminologie, weswegen diese für die vorliegende Arbeit in diesem Kapitel vorgenommen wird. Die Unterschiedlichkeit der verwendeten Terminologie wird in folgendem Beispiel besonders offenbar. In [PFLEEGER UND BOHNER 1990] wird vorgeschlagen, Tracelinks, die Elemente desselben Artefaktes verbinden, als vertikal zu bezeichnen, während horizontale Tracelinks Elemente unterschiedlicher Artefakte verbinden. Dieselben Attribute werden Tracelinks in [NEJMEH ET AL. 1989] zugeschrieben, allerdings mit umgekehrter Bedeutung. NEJMEH ET AL. schlagen vor, Tracelinks als vertikal zu bezeichnen, wenn sie Elemente unterschiedlichen 46

76 3 Traceability-Grundlagen Typs verbinden, während Tracelinks zwischen Elementen gleichen Typs mit horizontal bezeichnet werden. Auch in [WINKLER UND PILGRIM 2010] wird zwischen horizontaler und vertikaler Traceability unterschieden. Es wird vorgeschlagen, die Klassifizierung auf Grundlage der Zugehörigkeit der jeweiligen zu verbindenden Elemente zu Projektphasen oder Abstraktionslevels vorzunehmen. Die Untersuchung dieser unterschiedlichen Definitionen ergibt, dass es zumindest zwei unterschiedliche Bedeutungen gibt, die, im Kontext der Traceability, in die Begriffe horizontal und vertikal hinein interpretiert werden. Zum einen soll die chronologische Prozessphase berücksichtigt werden, welche die zu betrachtenden Elemente adressieren. Die andere Bedeutung beschreibt die Zugehörigkeit zum Datenartefakt. So unglücklich es ist, beide Kriterien mit denselben Termini zu beschreiben, so relevant und notwendig ist deren Berücksichtigung und Betrachtung. Aus diesem Grund werden im Folgenden ausgewählte Eigenschaften von Tracelinks und eine entsprechende Terminologie vorgestellt, die u. a. diese beiden Kriterien separat berücksichtigen. Prozessphasen-Kontext. Um zu beschreiben, ob ein Tracelink zwei Elemente derselben Prozessphase verbindet, wird die Kategorie Prozessphasen-Kontext eingeführt. Adressieren beide Elemente dieselbe Prozessphase, spricht man von Phasen-internen Tracelinks. Entstammen die beiden verknüpften Elemente unterschiedlichen Prozessphasen, ist also das erste Elemente beispielsweise eine Anforderung und das Zweite eine Funktion, spricht man von Phasen-übergreifenden Tracelinks. Gibt es unterschiedliche Artefakte entlang des Entwicklungsprozesses, die Anforderungsspezifikationen beinhalten, werden die Tracelinks, welche diese miteinander verknüpfen, als phasen-intern klassifiziert. Artefakt-Kontext. Unabhängig davon muss unterschieden werden, ob die zu verknüpfenden Elemente in einem oder unterschiedlichen Artefakten verwaltet werden. Um Elemente, die ausschließlich in einem einzigen Artefakt verwaltet werden, zu verknüpfen, müssen Artefaktinterne Tracelinks modelliert werden. Werden hingegen Elemente aus unterschiedlichen Artefakten verknüpft, spricht man von Artefakt-übergreifenden Tracelinks. Werden Abhängigkeiten zwischen Anforderungen desselben Anforderungsmodells modelliert, bestünden zwischen den entsprechenden Anforderungen Artefakt-interne Tracelinks. Werden hingegen Abhängigkeiten zwischen Anforderungen zweier verschiedener Spezifikationen oder Abhängigkeiten zwischen den beiden Artefakten Anforderungsspezifikation und realisierenden Funktionen modelliert, wären diese Tracelinks Artefakt-übergreifend. Semantik der Tracelinks. Tracelinks können beliebig viele Attribute aufweisen [CLELAND- HUANG ET AL. 2003, S. 797]. Unstrittig ist die Notwendigkeit, dem Tracelink bei zentraler Tracelink-Verwaltung ein Mindestmaß an IT-Eigenschaften zuzuweisen: einen eindeutigen Identifizierer (UID 21 ) sowie die beiden UID s der Elemente, die er verbindet [MARCUS ET AL. 2005, S. 56; BODE UND RIEBISCH 2009, S. 90; AIZENBUD-RESHEF ET AL. 2006, S. 518]. Zusätzliche Attribute können bspw. Richtung und Stärke der Tracelinks sein [SOSA ET AL. 2005, 21 Engl: unique identifier 47

77 3 Traceability-Grundlagen S. 438; KOH ET AL. 2012]. Darüber hinaus können Tracelinks eine unterschiedlich stark ausgeprägte Semantik aufweisen. Einige Traceability-Ansätze sehen in der Verwendung von typisierten Tracelinks sogar eine Notwendigkeit [MARCUS ET AL. 2005, S. 56; SUTINEN ET AL. 2000, S. 317]. Bei den typisierten Ausprägungen gibt es ein breites Spektrum möglicher Bedeutungen. In der Literatur wurde keine einheitliche Festlegung hinsichtlich der möglichen Tracelink-Typen erreicht [BODE UND RIEBISCH 2009, S. 89]. So werden in [AIZENBUD-RESHEF ET AL. 2006] folgende fünf Tracelink- Bedeutungen vorgeschlagen: satisfies, justifies, describes, depends on und validates. In [SCHWARZ ET AL. 2010, S. 483] können Tracelinks neun unterschiedliche Bedeutungen aufweisen, wobei depends on die einzige Überschneidung mit den zuvor Genannten darstellt. Andere Veröffentlichungen schlagen weitere Möglichkeiten vor: drei [BIANCHI ET AL. 2000], vier [RAMESH UND JARKE 2001], fünf [GÖKNIL ET AL. 2010, S. 41], acht [SPANOUDAKIS UND ZISMAN 2005], 16 [FASOLINO UND VISSAGGIO 1999, S. 63] oder sogar 50 Tracelink-Typen [RAMESH UND JARKE 2001] bzw. 18 Tracelink-Typen in fünf übergeordneten Kategorien [POHL 1996, S. 84]. Alle genannten Ansätze zur Semantik der Tracelinks adressieren Traceability im Kontext Software-Entwicklung. Durch die unterschiedlichen Möglichkeiten im Rahmen der Software- Entwicklung automatisiert Tracelinks zu erfassen (wie in Kapitel ausführlich beschrieben), können diese in Abhängigkeit des jeweils genutzten Erfassungsverfahrens mit geringem Aufwand entsprechend typisiert werden. Wenn beispielsweise bei der Durchführung von Testszenarien zur Überprüfung einer Anforderung erfasst werden kann, welche verwendeten Pakete, Klassen, Methoden oder Variablen während der Ausführung dieser Szenarien angesprochen werden, kann zwischen diesen und der jeweiligen Anforderung automatisch ein Tracelink mit der Typisierung satisfies generiert werden. Aus den in Kapitel 3.4 dargelegten Schwierigkeiten, im mechatronischen Kontext ebenfalls automatisiert Tracelinks zu erfassen, folgt ein erhöhter Aufwand für die Typisierung von Tracelinks in der Mechatronik, die daher in der Regel manuell zu erfolgen hätte. Das angestrebte Verhältnis aus Aufwand und Nutzen der Traceability müsste somit neu bewertet werden. Dennoch wird in [SOSA ET AL. 2005, S. 438] ein Traceability-Ansatz für die Entwicklung mechatronischer Produkte vorgestellt, der ebenfalls fünf unterschiedliche Tracelink-Typen verwendet, die zusätzlich mit einem Kritikalitätswert hinsichtlich der Gesamtfunktionalität ergänzt werden. Ein anderer vielversprechender Ansatz, dessen Ausprägung im Traceability- Schema spezifiziert werden muss, besteht darin, für alle möglichen Artefaktpaarungen jeweils eine eingeschränkte Teilmenge an typisierten Tracelinks zur Auswahl zu stellen. So werden in [GÖKNIL ET AL. 2010, S. 41] für die Artefaktpaarung Anforderungen und Systemarchitektur die beiden Tracelink-Typen AllocatedTo bzw. Satisfies zur Auswahl gestellt. Die meisten Traceability-Ansätze für die Mechatronik verzichten jedoch gänzlich darauf, den Tracelinks eine Semantik zuzuweisen [GÖKNIL ET AL. 2008, S. 59]. Diese untypisierten Tracelinks erhalten demnach eine generische Bedeutung, die anzeigt, dass die beiden verknüpften Elemente sich gegenseitig beeinflussen [JARRATT ET AL. 2004, S. 5; VAN GORP ET 48

78 3 Traceability-Grundlagen AL. 2006, S. 51]. Diese Wahl wird für die in den folgenden Kapiteln präsentierten eigenen Traceability-Ansätze ebenfalls getroffen. Eine formale Unterscheidung muss zusätzlich zwischen hierarchischen Relationen, also der Verbindung von Eltern- und zugehörigem Kindelement, und Tracelinks getroffen werden (vgl. [WEILKIENS 2008; WINKLER UND PILGRIM 2010, S. 538]), da diese unterschiedlich behandelt werden müssen. Dies wird besonders im Rahmen der Ausführungen zur Traceability- Visualisierung in Kapitel 5 relevant und daher zu einem späteren Zeitpunkt näher diskutiert ERFASSUNG VON TRACELINKS Der enorme Aufwand, der notwendig ist, um Tracelinks vollständig zu erfassen, ist eines der großen Hindernisse auf dem Weg zu einer besseren Akzeptanz der Traceability-Methode. Für die Anwendung in der Entwicklung mechatronischer Produkte gibt es derzeit wenige Methoden, die eine Verringerung des Modellierungsaufwands ermöglichen. Eine kurze Klassifizierung der existierenden Methoden zur Modellierungsunterstützung wird in Kapitel vorgestellt MODELLIERUNGSUNTERSTÜTZUNG Unter dem Begriff regelbasierte Erfassung können alle Methoden zusammengefasst werden, bei denen konkrete Regeln auf die Artefakte angewandt werden, um automatisch Abhängigkeiten zwischen ihnen abzuleiten und diese als Tracelinks zu erfassen [WINKLER UND PILGRIM 2010]. Eine Weiterentwicklung dieses Ansatzes stellt die Überführung in Assistenzsysteme dar, die, unter Abarbeitung einer strukturierten Vorgehensweise, konkrete Elementpaarungen zur Verknüpfung vorschlagen und somit die mögliche Anzahl von Elementkombinationen einschränken. Ein weiterer Ansatz ist die Wiederverwendung von Teilen bestehender Traceability-Modelle, was bei inhaltlich ähnlichen Entwicklungsprojekten sinnvoll ist und daher primär im Rahmen adaptiver Entwicklungen zum Tragen kommt. Die Wiederverwendungsstrategie kann mit Template-Ansätzen weiterentwickelt werden, wo einmal modellierte, explizite Logiken genutzt werden, um generische Modelle zu erstellen, die bei Bedarf zu konkreten neuen Modellen ausgeprägt werden können. Einige Methoden der regelbasierten Erfassung entstammen ursprünglich der Software- Entwicklung und werden in dem folgenden Kapitel näher erläutert TRACELINK-ERFASSUNG IN DER SOFTWARE-ENTWICKLUNG In der Software-Entwicklung existieren für die automatisierte Identifikation und Pflege von Tracelink-Informationen 22 verschiedene Methoden, um Abhängigkeiten zwischen den teilweise heterogenen Artefakten des Entwicklungsprozesses ableiten zu können. Zu diesen Artefakten gehören etwa Anforderungsdokumente, Klassenmodelle, Quellcode, Test Cases sowie eine Vielzahl weiterer Dokumentationen wie bspw. Handbücher. Die verwendeten Me- 22 Dieser Prozess wird im Englischen mit dem Fachausdruck tracelink retrieval bezeichnet. 49

79 3 Traceability-Grundlagen thoden oder Algorithmen unterscheiden sich dabei in Abhängigkeit der zugrundeliegenden Typen von Artefakten. Für die Ableitung von inhaltlichen Abhängigkeiten zwischen Dokumenten, die in natürlicher Sprache beschrieben sind (Anforderungen, Handbücher, Code-Reviews etc.), finden Algorithmen aus dem Gebiet des Information Retrieval (IR) Anwendung, um semantische Zusammenhänge zu analysieren [LUCIA ET AL. 2007; WINKLER 2009]. Die technische Grundlage bildet hierbei das Indizieren von Dokumenten nach Schlagwörtern und das Durchführen von komplexen Abfragen unter Verwendung von Ähnlichkeitsmetriken oder Wahrscheinlichkeiten. Zu den verwendeten Methoden zählen etwa das Latent Semantic Indexing (LSI) [DEERWESTER ET AL. 1990], das Vector Space Model (VSM) oder die Verwendung probabilistischer Netzwerke (PN). [ANTONIOL ET AL. 2002; OLIVETO ET AL. 2010] Eine konsistente Verwendung von Begriffen in Anforderungsbeschreibungen und der Gebrauch von Namenskonventionen bei der Vergabe von Bezeichnern im Quellcode ermöglichen eine Schlagwort-basierte Indizierung z. B. von Methodennamen, um Beziehungen zwischen natürlich-sprachlichen Artefakten und Entwurfsartefakten (wie bspw. UML- Klassendiagramme und Quellcode) herzustellen [CLELAND-HUANG ET AL. 2007]. Abhängigkeiten zwischen Entwurfsartefakten können ebenfalls erkannt werden, wenn die Nomenklatur zwischen Modellierung und Programmierung konsistent ist oder der Quellcode dynamisch vom Modell erzeugt wird. Die Methoden des Information Retrieval eignen sich somit sowohl für die Untersuchung von Beziehungen zwischen, als auch innerhalb von natürlich-sprachlichen Artefakten und Entwurfsartefakten [ANTONIOL ET AL. 2002; OLIVETO ET AL. 2010; LUCIA ET AL. 2007]. Abhängigkeiten innerhalb des Quellcodes eines Softwareprojekts können üblicherweise durch die integrierte Entwicklungsumgebung (IDE), mit der das Softwareprojekt erstellt wird, erfasst werden. Änderungen oder Löschungen von Bezeichnern (von Paketen, Klassen, Methoden oder Variablen) werden sofort an die entsprechenden Stellen des Quellcodes propagiert, an denen sie verwendet werden. Diese durch die Programmierung vorhandenen Abhängigkeiten lassen weiterhin Schlüsse auf Abhängigkeiten zwischen Anforderungen zu. Eine beispielhafte Implementierung ist das Programm TraceAnalyzer, welches zwischen zwei Anforderungen A und B, die durch Tracelinks mit den Elementen CA und CB des Quellcodes zusammenhängen, eine Abhängigkeit annimmt, wenn CA und CB ebenfalls voneinander abhängen. [EGYED UND GRÜNBACHER 2005] Eine weitere Methode, um Abhängigkeiten zwischen Anforderungen und Quellcode automatisiert zu erfassen, ist die Durchführung von Testszenarien für Anforderungen bei gleichzeitiger Observation der verwendeten Pakete, Klassen, Methoden und Variablen während der Ausführung dieser Szenarien. Diese Methode generiert während des Durchlaufs eines Testszenarios Tracelinks zwischen Anforderungen und Quellcode sowie sog. footprint-graphen. Überschneiden sich footprints von Testszenarien zur Verifikation unterschiedlicher Anforderungen, kann daraus außerdem auf Abhängigkeiten zwischen diesen Anforderungen geschlossen werden. [EGYED UND GRÜNBACHER 2005] 50

80 3 Traceability-Grundlagen ERFASSUNG VON TRACELINKS AM BEISPIEL EINES MECHATRONISCHEN ASSISTENZSYSTEMS In den folgenden Absätzen wird beschrieben, in welcher Form Tracelinks zwischen den Artefakten, die bei der Entwicklung eines Embedded Systems erstellt werden müssen, modelliert werden. Diese Ausführungen erfolgen am Beispiel eines hinsichtlich Umfang und Anzahl der beschriebenen Artefakte vereinfachten Assistenzsystems zur Toten-Winkel-Warnung eines KFZ. Eine symbolische Übersicht der verwendeten Artefakte und ihr Zusammenhang ist in Abbildung 15 dargestellt. Abbildung 15: Traceability zwischen den Artefakten zur Beschreibung des Toten-Winkel- Assistenzsystems Zu Beginn der Entwicklung werden die Anforderungen an den Toten-Winkel-Warner sowie dessen zu realisierende Funktionen erfasst 23. Anforderungen sind bspw. Soll bei entgegenkommenden Fahrzeugen nicht warnen oder Soll bei Regen und Nebel keine Falschmeldungen produzieren, während mögliche Funktionen Position der umgebenden Fahrzeuge 23 Detaillierte Ausführungen zum allgemeinen Entwicklungsvorgehen können auch Kapitel 2.3 entnommen werden. 51

81 3 Traceability-Grundlagen detektieren sowie Relative Geschwindigkeit der umgebenden Fahrzeuge ermitteln lauten. Das Wissen um die Zusammenhänge, welche Anforderungen durch welche Funktion realisiert wird, basiert auf der Expertise der Entwickler. Die Funktionsverantwortlichen zeichnen daher für das Modellieren der Tracelinks zwischen diesen beiden Artefakten verantwortlich. Da in beiden Artefakten natürlich-sprachliche Beschreibungen mit ähnlichem Vokabular verwendet werden, können unterstützende Tracelink-Vorschläge durch Methoden des Information Retrieval erzeugt werden, die jedoch von den Experten abschließend bewertet werden müssen. Des Weiteren müssen den Anforderungen Testfälle zugeordnet werden, sobald Erstere weit genug heruntergebrochen sind, dass eine konkrete Prozedur zu deren Verifikation beschrieben werden kann. Ist dies erfolgt werden zwischen der Anforderung und den zugehörigen Testfällen Tracelinks durch den verantwortlichen Testingenieur erstellt. Auf Basis der Funktionsstruktur wird anschließend überlegt, welche physischen Komponenten zur Umsetzung des Toten-Winkel-Warners benötigt werden. Neben der Warn-LED, die in den Außenspiegel integriert wird, sind dies insbesondere die Sensorik zur Erfassung der Fahrzeug-Umgebung sowie das Steuergerät, auf dem die logische Verarbeitung der Sensor- Signale erfolgt. Diese genannten Elemente werden in die Produktstruktur aufgenommen und mit den jeweils zugehörigen Funktionen vom Systemarchitekten mit Tracelinks verknüpft. Für die Regelung des Toten-Winkel-Warners wird kein eigenes Steuergerät entwickelt, sondern ein bereits für das Fahrzeug vorgesehenes, zugekauftes Gerät mitgenutzt. Die geometrische Integration der Warn-LED und deren Verkabelung muss jedoch im CAD-Model der Baugruppe Außenspiegel erfolgen. Daher ist auch, sofern dies nicht bereits durch die Nutzung eines integrierten PLM-Werkzeugs automatisch gegeben ist, das jeweilige CAD-Model mit dem zugehörigen Element der Produktstruktur über einen Tracelink zu verbinden. Um das logische Verhalten des Assistenzsystems zu konzipieren und es im übergeordneten Systemkontext zu simulieren, wird ein Verhaltensmodell (hier bspw. ein Regelungsmodell) entworfen. Die darin abgebildeten Funktionen werden mit ihrer jeweiligen Entsprechung in der Funktionsstruktur verknüpft. Dies erfolgt durch den Regelungstechniker, der das Verhaltensmodell des Toten-Winkel-Warners entwirft. Für Funktionen des Verhaltensmodells wird anschließend ein Software-Modell erzeugt (bspw. mittels gerichteter Blockschalt-Graphen in MATLAB/Simulink). Dabei verknüpft der Software-Entwickler die Objekte des Modells mit der zugehörigen Repräsentation im Regelungsmodell. Mit Hilfe der modellierten Tracelinks kann nun ermittelt werden, welche Anforderungen an das Software-Modell bestehen und mit welchen Testprozeduren diese zu verifizieren sind. Letztere spielen für die im Folgenden beschriebenen Simulationsverfahren eine wesentliche Rolle. Das Software-Modell kann nun genutzt werden, um das Verhalten des Assistenzsystem-Konzepts in diesem frühen Entwicklungsstadium mit Hilfe einer Model-in-the-Loop-Simulation zu bewerten. Sobald das Modell den Anforderungen genügt, kann daraus über die entsprechenden Toolboxen automatisch Software-Code generiert werden. Die Erstellung der Tracelinks zwischen Software-Modell und Code erfolgt ebenfalls automatisch. Die Korrektheit der Code-Generierung wird in der Folge durch eine Software-in-the-Loop-Simulation abgesichert. Ist diese bestätigt, wird der 52

82 3 Traceability-Grundlagen Code auf das reale Steuergerät geflasht, um mittels einer Hardware-in-the-Loop-Simulation das Verhalten der gesamten Steuergerätefunktion gegenüber dem Umgebungsmodell abzusichern. Dazu müssen die verwendeten Stimuli-Daten auch die in den Testfällen definierten Prüf-Szenarien abbilden. Bei der Durchführung dieser automatisierten Testszenarien können zudem automatisch Tracelinks zwischen den Testfällen und den Code-Fragmenten (Pakete, Klassen, Methoden, Variablen o. Ä.) generiert werden, die von den Szenarien verwendet werden (in Abbildung 13 nicht abgebildet). Zusammenfassend kann festgehalten werden, dass in der Software-Entwicklung eine Vielzahl von Methoden existiert, die es ermöglichen, automatisiert Abhängigkeiten zwischen den teilweise heterogenen Artefakten des Entwicklungsprozesses zu identifizieren. Somit können die Tracelink-Informationen mit einem vergleichsweise geringen menschlichen Aufwand erzeugt werden. An obigem Beispiel konnte aufgezeigt werden, dass dies ist im Kontext der Entwicklung mechatronischer Systeme eher die Ausnahme ist, weswegen die Erfassung von Tracelinks dort ein Vorgang ist, der vorwiegend auf menschlicher Expertise basiert [WINKLER UND PILGRIM 2010, S. 535]. Das folgende Kapitel 3.5 gibt einen Überblick über ausgewählte Werkzeuge und Methoden zur Modellierung von Traceability-Daten, wie sie momentan im industriellen Kontext angeboten bzw. in der Forschung erprobt werden WERKZEUGE UND METHODEN ZUR TRACEABILITY-MODELLIERUNG - STAND DER WISSENSCHAFT UND TECHNIK In Forschung und industrieller Anwendung existieren zahlreiche Werkzeuge, die zur Herstellung einer durchgängigen Nachverfolgbarkeit sowie zur Analyse der modellierten Tracelinks einen Beitrag leisten können. Eine, primär auf die Modellierung und Verwaltung der Tracelinks bezogene, Auswahl dieser Methoden und Werkzeugfunktionalitäten wird in diesem Kapitel vorgestellt. Existierende Methoden und Werkzeugfunktionalitäten hinsichtlich der gewinnbringenden Verwendung von Traceability-Daten, deren Visualisierung und der Unterstützung von Änderungsabschätzungen werden in den entsprechenden thematischen Kapiteln 4.1, 5.2 bzw. 6.3 vorgestellt. Die in Kapitel 3.5 vorgestellte Auswahl der Software-Werkzeuge gliedert sich nach dem ursprünglichen Zweck der Werkzeuge. Einige der Werkzeuge dienen primär der Erfassung und Verwaltung von Anforderungen, andere der Verwaltung von Produktstruktur-bezogenen Daten, sog. Product-Lifecycle-Management 24 -Werkzeuge. Diese beiden Klassen von Werkzeugen werden im industriellen Kontext auch häufig genutzt, ohne dass mit ihnen Traceability- Daten erzeugt werden. Die dritte Werkzeug-Klasse in diesem Kapitel bilden Spezial- Werkzeuge, deren Funktionalitäten auf Traceability-Daten beruhen und damit ohne selbige nicht sinnvoll genutzt werden können. Doch zunächst soll eine gängige Methode zur Erfassung und Verwaltung von Traceability-Daten vorgestellt werden. 24 Akronym: PLM 53

83 Artefakt B Artefakt A Element A1 Element A1.1 Element A1.2 Element A2 Element A2.1 Element B1 Element B1.1 Element B1.2 Element B2 Element B2.1 Element B3 Element B3.1 3 Traceability-Grundlagen Abhängigkeitsmatrizen Eine verhältnismäßig verbreitete Methode zur Analyse komplexer Systeme ist die Verwendung von Abhängigkeitsmatrizen. Abhängigkeitsmatrizen sind eine Repräsentationsform, mit der Traceability-Modelle in tabellarischer Form dargestellt werden können. Die linke Spalte und die oberste Zeile der Matrix repräsentieren dabei die Elemente der zu betrachtenden Artefakte. Besteht eine Abhängigkeit zwischen zwei Elementen, nimmt die Zelle, in der sich die Zeile und die Spalte, welche die beiden Knoten repräsentieren, schneiden, den Boole schen Wert True an. Zellen, die keine Abhängigkeit repräsentieren, nehmen entsprechend den Wert False an. [GHONIEM ET AL. 2004; YASSINE 2004, S. 2] Artefakt A Artefakt B Element A1 Element A1.1 Element A1.2 Element A2 Element A2.1 Element B1 Element B1.1 Element B1.2 Element B2 Element B2.1 Element B3 Element B3.1 X X X X X X X X X X DSM X X X X X X X X X X X MDM DMM x.. Tracelinks Abbildung 16: Unterscheidung der Abhängigkeitsmatrizen DSM, DMM und MDM Schon im Jahr 1962 wurde in [STEWARD 1962] das Konzept der Abhängigkeitsmatrizen vorgestellt. In späteren Jahren wurden die Möglichkeiten der Repräsentation von Traceability- Daten in Matrixform erweitert. Generell kann zwischen Matrizen unterschieden werden, in denen in Zeilen und Spalten jeweils entweder Elemente eines Artefaktes, sog. Intra-Domain Matrizen, oder zweier Artefakte, sog. Inter-Domain Matrizen, betrachtet werden (vgl. [MAURER 2007; LINDEMANN ET AL. 2009]). Für Intra-Domain Abhängigkeitsmatrizen, mit denen die Struktur von (mechatronischen) Systemen betrachtet wird, hat sich auch der Begriff Design Structure Matrix (DSM) etabliert [STEWARD 1981, S. 71; PIMMLER UND EPPINGER 1994; BROWNING 2001; YASSINE 2004]. Für Inter-Domain Matrizen wurde hingegen auch der Begriff Domain Mapping Matrices (DMM) eingeführt [DANILOVIC UND BÖRJESSON 2001]. Werden die beiden Matrizenformen durch algorithmische Verrechnung ineinander überführt, spricht man 54

84 3 Traceability-Grundlagen von Multiple-Domain Matrizen (MDM) (siehe Abbildung 16, Tracelinks sind durch X gekennzeichnet) [MAURER 2007]. Für diese Matrizen gibt es zahlreiche Algorithmen zur Analyse von Systemeigenschaften wie z. B. das Partitioning oder das Clustering. Eine ausführliche Beschreibung dieser Methoden sowie eine Diskussion der Vor- und Nachteile von Abhängigkeitsmatrizen kann Kapitel 4.1 entnommen werden. Der größte Nachteil bei der Erfassung von Tracelinks mittels Abhängigkeitsmatrizen ist die begrenzte Kapazität hinsichtlich der Anzahl der zeitgleich darstellbaren Elemente [JARRATT ET AL. 2004, S. 10]. Des Weiteren ist es schwierig, Tracelinks über mehrere Artefakte hinweg nachzuverfolgen [WINKLER UND PILGRIM 2010, S. 542]. Bei einer Anwendungsstudie in der Automobilindustrie wurde festgestellt, dass es nicht praktikabel ist, die notwendige Menge an Informationen in die DSM einzupflegen, wodurch diese außerdem äußerst schwierig zu handhaben würde [ALMEFELT ET AL. 2006, S. 129] TRACEABILITY-BASIERTE SPEZIAL-WERKZEUGE LOOMEO Kommerzielle Softwareunterstützung zur Erstellung und Verwaltung von DSM, DMM und MDM existiert z. B. in Form des Werkzeugs LOOMEO, das von der Firma Teseon GmbH angeboten wird. Die theoretischen Grundlagen dieser Software wurden am Lehrstuhl für Produktentwicklung der Technischen Universität München gelegt. Mit LOOMEO können zum einen die Artefakte selbst und zum anderen auch die Tracelinks zwischen einem oder mehreren Artefakten modelliert und verwaltet werden (siehe Abbildung 17). Die Software bietet darüber hinaus Funktionalitäten zum Ermitteln von Clustern, um die Modularisierung von Systemen zu unterstützen (Näheres dazu siehe Kapitel 4.1.1). [MAURER 2007; TESEON GmbH 2012]. Abbildung 17: Befüllen der Abhängigkeitsmatrizen DSM (links) und DMM (rechts) in LOOMEO 55

85 3 Traceability-Grundlagen LOOMEO ist ein nicht-integratives Werkzeug, das keine Modellierungsunterstützung bietet und die Verwendung von kopierten Daten erfordert. Die in LOOMEO erzeugten Daten werden auch im Werkzeug selbst zentral gespeichert, wobei dafür kein Traceability-Schema zugrunde liegt. Mit LOOMEO kann sowohl eine qualitative als auch eine quantitative Traceability erreicht werden, bei welcher Abhängigkeiten jedoch nicht bis auf Parameterlevel nachverfolgt werden können. Es unterstützt Datenstrukturen in Form von Listen und Hierarchien. Die erzeugten untypisierten Tracelinks können sowohl Phasen-intern als auch -übergreifend sowie Artefakt-intern und -übergreifend ausgeprägt werden. [KÖNIGS ET AL. 2012] Cambridge Advanced Modeller Am Engineering Design Center in Cambridge wurde das Werkzeug Cambridge Advanced Modeller (CAM) entwickelt. Der CAM ist eine Software-Plattform zur Modellierung und Analyse von Systemabhängigkeiten. Dazu bietet der CAM eine Vielzahl sog. Toolboxen an. Mit diesen Toolboxen können die Traceability-Modelle mittels einer DSM erzeugt, Prozessmodelle generiert, eine Systemarchitektur abgeleitet oder die Auswirkungen von Änderungen abgeschätzt werden. Zur Generierung der Traceability-Modelle kann der Nutzer zudem mehrere sog. Workbooks anlegen, um jeweils eine beliebige Anzahl von DSM s in einer MDM zu bündeln (siehe Abbildung 18) und somit Abhängigkeiten zwischen mehreren Artefakten abbilden zu können. [KELLER ET AL. 2005; WYNN ET AL. 2009; WYNN ET AL. 2010a] Abbildung 18: Workbook im CAM zur Verknüpfung zweier DSM s (hier Anforderungs- und Funktions-DSM) in einer MDM 56

86 3 Traceability-Grundlagen Beim CAM handelt es sich um ein nicht-integratives Werkzeug, das keine Modellierungsunterstützung bietet und die Verwendung von kopierten Daten erfordert. Die im CAM erzeugten Daten werden im Werkzeug selbst zentral gespeichert. Dem CAM liegt kein Traceability- Schema zugrunde. Mit dem CAM können beide Traceability-Typen realisiert werden: qualitative und quantitative. Hinsichtlich der Granularität ist eine Nachverfolgung bis auf Parameterlevel nicht möglich. Es werden die Datenstrukturen Listen, Hierarchien und Netze unterstützt. Mit dem CAM können typisierte Tracelinks erzeugt werden, die bei den CAM-internen Methoden primär Phasen- und Artefakt-intern genutzt werden. [KÖNIGS ET AL. 2012] ToolNet [VAN GORP ET AL. 2006; ROSENAUER 2008] Im Rahmen eines Forschungsprojekts wurde von DaimlerChrysler und EADS CRC Deutschland das serviceorientierte Werkzeug ToolNet entwickelt. ToolNet integriert existierende kommerzielle Tools aus dem Ingenieursbereich wie z. B. DOORS oder Matlab mit Hilfe von speziell entwickelten Adaptern, die über einen gemeinsamen Nachrichtenbus kommunizieren. ToolNet akquiriert Modellinformationen aus proprietären Datenquellen und erlaubt deren manuelle Verknüpfung sowie die Verwaltung dieser Traceability-Informationen in einer Datenbank. Das Werkzeug unterstützt somit eine qualitative Traceability, bei der ein Nachverfolgen auf Parameter-Ebene nicht vorgesehen ist. Als Datenstrukturen können Listen, Hierarchien und Netze betrachtet werden. Die einzelnen Elemente werden paarweise durch semantisch typisierte Tracelinks verbunden, die Artefakt-übergreifend sowohl Phasen-intern als auch -übergreifend manuell modelliert werden können. METUS [ID-Consult GmbH 2012; TRETOW ET AL. 2008] Das Werkzeug METUS von ID-Consult bietet Funktionalitäten, um die beiden hierarchischen Artefakte Funktionsstruktur und Produktstruktur sowie Abhängigkeiten zwischen deren einzelnen Komponenten zu modellieren und zu verwalten. Der Erfüllungsgrad jeder Komponente kann in einer Abhängigkeitsmatrix gewichtet modelliert werden, wobei die Summe pro Funktion den Wert eins ergeben muss. Zusätzlich können die einzelnen Elemente attribuiert werden. Die modellierten Tracelinks dienen dem Ziel, das System hinsichtlich spezifischer Parameter zu analysieren. Dazu werden über die hierarchischen und Artefaktübergreifenden Relationen z. B. die Kosten je Funktion oder das Gewicht je Produktmodul aggregiert. Um den Aufwand für das Nachmodellieren der Artefakte zu reduzieren, bietet METUS eine Teamcenter-Integration an. Abgesehen von dieser Schnittstelle beruht METUS auf einer nicht-integrativen Artefaktakquise und einem starren Traceability-Schema. Unterstützt werden die Datenstrukturen Liste und Hierarchie. Die Artefakte werden mittels untypisierter Phasen- und Artefakt-übergreifender Tracelinks verknüpft, mit deren Hilfe sowohl qualitative als auch quantitative Traceability realisiert werden kann. 57

87 3 Traceability-Grundlagen ANFORDERUNGSMANAGEMENT-WERKZEUGE Rational DOORS Das Werkzeug Rational DOORS von IBM wurde ursprünglich konzipiert, um Anforderungen in großem Umfang in einer Datenbank objekt-orientiert zu verwalten. Strukturiert wird die Datenbank mithilfe von nutzerbezeichneten Projekten. Innerhalb der Projekte können sog. Formal Modules angelegt und gespeichert werden. Ein Formal Module entspricht dabei inhaltlich einer Spezifikation und kann hierarchisch aufgebaut werden. Jedes Datum innerhalb des Formal Modules (bspw. Anforderung, Bild usw.) wird als Objekt samt eindeutiger Identifikationsnummer verwaltet und kann Attribute zugewiesen bekommen. [PLETTE 2009; ABMA 2009; IBM Corp. 2012b] Zwischen den einzelnen Objekten der Datenbank können manuell gerichtete Verweise, also Tracelinks, erzeugt werden (siehe Abbildung 19). Alle Tracelinks samt ihrer zugehörigen Attribute werden im sog. Link Module gespeichert. Rational DOORS bietet Funktionalitäten, um die Tracelinks manuell oder semi-automatisch zu erfassen. [ABMA 2009; IBM Corp. 2012b] Abbildung 19: Erzeugung eines Tracelinks durch Auswahl des Quellelements (links) und des Zielelements (rechts) im Formal Module Rational DOORS basiert auf einer Client-Server-Architektur, die eine gleichzeitige Verwendung durch mehrere Nutzer erlaubt [ABMA 2009]. In Abhängigkeit von der Rolle des jeweiligen Nutzers können Sichten konfiguriert werden, um die Auswahl der dargestellten Informationen anzupassen [PLETTE 2009]. Die Software unterstützt den Datenaustausch u. a. über das Format ReqIF (Requirements Interchange Format) sowie die Open Services for Lifecycle Collaboration (OSLC) Spezifikation [IBM Corp. 2012b]. Rational DOORS ist ein primär nicht-integratives Werkzeug, das als Modellierungsunterstützung die Wiederverwendung von Modulen vorsieht. Zur Modellierung der Tracelinks kann auf die Originaldaten zugegriffen werden. Die in Rational DOORS erzeugten Daten werden im Werkzeug selbst zentral gespeichert, ohne dass intern ein Traceability-Schema zugrunde liegt. Mit Rational DOORS kann qualitative Traceability realisiert werden, mit welcher jedoch nicht bis auf Parameterlevel nachverfolgt werden kann. Es werden die Datenstrukturen Listen und Hierarchien unterstützt. Mit Rational DOORS können untypisierte, primär Phasen- 58

88 3 Traceability-Grundlagen interne jedoch sowohl Artefakt-interne als auch -übergreifende Tracelinks erzeugt werden. [KÖNIGS ET AL. 2012] Reqtify [Geensoft 2010a, 2010b; POHL UND SCHEEL 2004] Der ursprüngliche Ansatz hinter dem Werkzeug Reqtify, so wie es vor der Übernahme durch Dassault Systèmes von der Firma Geensoft vermarktet wurde, adressiert die qualitative Erfassung von Abhängigkeiten zwischen unterschiedlichen Anforderungsspezifikationen sowie verwandten Dokumenten wie bspw. Testfallbeschreibungen. Reqtify sieht vor, dass die typisierten Tracelinks nicht in einer separaten Anwendung verwaltet, sondern verteilt als Referenzen in den Originalartefakten gespeichert werden. Die Referenzen verweisen dabei auf Elemente anderer Artefakte (womit Artefakt-übergreifende Tracelinks vorliegen), die primär für Phasen-interne aber auch -übergreifende Betrachtungen genutzt werden. Für das Modellieren der Tracelinks steht ein nutzerkonfigurierbares Traceability-Schema zur Verfügung. Da dies optional zu verwenden ist, und das Werkzeug zunächst keine starren Vorgaben hinsichtlich der verknüpfbaren Artefakttypen und Detaillevel macht, wird es in der Zusammenfassung in Kapitel als Werkzeug ohne Traceability-Schema klassifiziert. Eine Nachverfolgbarkeit auf Parameterlevel ist nicht möglich. Reqtify unterstützt die Datenstrukturen Liste und Hierarchie PLM-WERKZEUGE Die Grundfunktionalität von PLM-Werkzeugen ist das Erzeugen und Verwalten verschiedener Artefakte (wie bspw. Anforderungen oder Produktstrukturen). Eine Methode zur Erfassung und Verwaltung der Abhängigkeiten zwischen diesen Artefakten wäre eine naheliegende und gewinnbringende Weiterentwicklung für PLM-Werkzeuge. Daher wurden sie vor einigen Jahren folgerichtig um Grundfunktionalitäten für das Verknüpfen von Artefakten erweitert. Solche Verknüpfungsfunktionalitäten werden heute in kommerziell angebotenen PLM- Systemen, wie z. B. Enovia V6 von Dassault Systèmes und Teamcenter von Siemens PLM offeriert. V6 R2011x [Dassault Systèmes 2011, 2012a, 2012b; VORSATZ 2012] Die V6-Suite von Dassault Systèmes bietet den integrierten Systementwicklungsansatz RFLP an. Er basiert darauf, innerhalb der V6-Werkzeuge ENOVIA 25 und CATIA 26 die Originalartefakte Anforderungs- (R) und Funktionsmodell (F), logisches und dynamisches Verhaltensmodell (L) sowie das physikalische Geometriemodell (P) zu entwerfen. Die Modelle werden aufeinander aufbauend entwickelt. Inhaltliche Abhängigkeiten innerhalb und zwischen den Artefakten werden mittels typisierbarer und zum Teil benennbarer Tracelinks explizit 25 Produktdatenmanagement-Werkzeug aus der V6-Suite von Dassault Systèmes 26 3D-CAD- und CAx-Werkzeug aus der V6-Suite von Dassault Systèmes 59

89 3 Traceability-Grundlagen modelliert. Werden die Tracelinks auf Parameterlevel modelliert, können durch die Verbindung von Verhaltensmodell und physikalischem Modell um Geometrieinformationen angereicherte Verhaltenssimulationen durchgeführt werden. Auf konkrete Parameterwerte innerhalb der Anforderungsspezifikation kann nicht verlinkt werden, sondern nur auf deren textuelle Beschreibung. Das Modellieren der Tracelinks erfolgt je nach Artefakttyp entweder über ein Dialogfenster (siehe Abbildung 20) oder über eine Drag & Drop Funktionalität (bspw. innerhalb der Verhaltensmodelle). Abbildung 20: Darstellung der Erfassung eines Tracelinks zwischen Verhaltensmodell und korrespondierendem Produktstrukturelement in V6 Die modellierten Tracelinks, die dem zugrunde liegenden Traceability-Schema entsprechen müssen, werden in der Datenbank der V6-Suite zentral verwaltet. V6 unterstützt die Datenstrukturen Listen, Hierarchien und Netze zur Modellierung einer qualitativen Traceability. Die Philosophie hinter dem RFLP-Ansatz beruht darauf, dass sowohl Phasen-interne und -übergreifende als auch Artefakt-interne und -übergreifende Tracelinks erzeugt werden. Teamcenter 9.1 [Siemens PLM Software Inc. 2012; Siemens Industry Software GmbH & Co. KG 2012] Siemens PLM bietet mit seinem PLM-Werkzeug Teamcenter ebenfalls Verknüpfungsmechanismen an. Insbesondere das Modul Systems Engineering and Requirements Management stellt Funktionalitäten bereit, um eine Traceability zwischen Anforderungen, funktionalen Strukturen, Verhaltensmodellen, Produktstrukturen (siehe Abbildung 21) und ggf. weiteren Artefakten herzustellen. Dabei können einzelne Artefakte auch in externen Werkzeugen modelliert und über eine Schnittstelle in Teamcenter integriert werden. Daraus folgt, dass die Tracelinks in Teamcenter sowohl Artefakt-intern und -übergreifend als auch Phasen-intern und -übergreifend ausgeprägt werden können. 60

90 3 Traceability-Grundlagen Abbildung 21: Grundlegendes Verknüpfungskonzept des Systems-Engineering-Ansatzes in Teamcenter 9.1 [Siemens PLM Software Inc. 2012, S. 1 43] Die gerichteten und typisierbaren Tracelinks müssen dabei, ausgehend von einzeln anzuwählenden Elementen, Menü-basiert angelegt und im Werkzeug selbst zentral gespeichert werden. Einen Unterstützungsmechanismus für das Modellieren gibt es, abgesehen von der Wiederverwendbarkeit existierender Lösungen, nicht. Teamcenter liegt kein Traceability- Schema zugrunde. Mit der angebotenen qualitativen Traceability kann bis auf Parameterlevel nachverfolgt werden, wobei Teamcenter die Datenstrukturen Listen, Hierarchien und Netze unterstützt. [KÖNIGS ET AL. 2012] Abbildung 22: Integrierte Systementwicklung unter Verwendung von Traceability im Mechatronics Concept Designer [Siemens PLM Software Inc. 2010, S. 1] 61

91 3 Traceability-Grundlagen Mit dem Mechatronics Concept Designer bietet Siemens PLM zusätzlich eine auf Teamcenter und NX 27 basierende Software-Funktionalität zur integrierten Systemkonzeption an. Dabei werden textuelle Anforderungen, Funktionsstrukturen, physikbasierte Verhaltensmodelle sowie 3D-Geometrie- und zeitabhängige Kinematikmodelle integriert und miteinander verknüpft entwickelt. [Siemens PLM Software Inc. 2010] ZUSAMMENFASSUNG Neben den dargelegten Werkzeugen bieten noch weitere Lösungen Funktionalitäten zur Traceability-Modellierung an. Beispielhaft zu nennen sind kommerzielle Werkzeuge aus dem Umfeld der Softwareentwicklung wie IBM Rational RequisitePro, Borland Caliber oder Top- Team Analyst. Auf deren detaillierte Beschreibung wird an dieser Stelle, aufgrund ihres geringen Verbreitungsgrades in der Entwicklung mechatronischer Systeme, verzichtet. Die wesentlichen Traceability-relevanten Eigenschaften der vorgestellten Werkzeuge sind in Tabelle 2 zusammenfassend dargestellt. Akquisition der Artefakte Duplikation der Artefakte Speicherort der Tracelinks Traceability Schema Granularität der Modellierung Traceability-Typ Unterstützte Datenstrukturen Traceability Eigenschaften 4 4 integrativ nicht-integrativ R T V N D L C M 5 3 Originaldaten kopierte Daten D R T V N L C M 7 1 zentral verteilt D L C M T V N R 2 6 ja nein M V D R L C T N 3 6 Parameterlevel nicht bis auf Parameterlevel M T V D R L C V N 8 3 qualitativ quantitativ D R L C M T V N L C M Listen Hierarchien Polyhierarchien Netze D R L C M T V N D R L C M T V N C T V N Tracelink Eigenschaften 7 6 Phaseninterübergreifend Phasen- D: Rational DOORS R: Reqtify D R L C T V N R L M T V N L: LOOMEO 5 7 Artefaktinterübergreifend M: METUS Artefakt- C: CAM D L C T V D R L M T V N T: Teamcenter V: V6 typisiert untypisiert R C T V N D L M V N: ToolNet Prozessphasen- Kontext Artefakt-Kontext Semantik der Tracelinks Tabelle 2: Übersicht der Traceability-relevanten Eigenschaften ausgewählter Werkzeuge 27 3D-CAD-Modellierungswerkzeug von Siemens PLM 62

92 3 Traceability-Grundlagen Alle in Kapitel 3.5 vorgestellten Ansätze zielen auf eine Verbesserung der Modellkonsistenz und der Informationsdurchgängigkeit in der Entwicklung ab. Zusammenfassend kann jedoch festgehalten werden, dass bei den vorgestellten Werkzeugen sehr unterschiedliche Lösungen für das Erfassen und Verwalten von Tracelinks gewählt wurden. Auch die Ausprägung der Tracelinks selbst, die verknüpfbaren Artefakte und die Granularität ihrer Elemente kann unterschiedlich gewählt werden. Eines ist jedoch offensichtlich: für die spätere Verwendung der erzeugten Traceability-Modelle im Bereich der Mechatronik bieten die vorgestellten Werkzeuge entweder keine oder nur eine sehr geringe Anzahl an Funktionalitäten an. Generell gibt es für die geringe Verbreitung der Traceability-Methode in der industriellen Praxis zwei wesentliche Gründe, die ihre großen Potentiale überlagern: der hohe Aufwand, der für die manuelle Erstellung der Tracelinks investiert werden muss [WALDERHAUG ET AL. 2009] und der unklare Nutzen, der aus diesem Aufwand gezogen werden kann [AIZENBUD- RESHEF ET AL. 2006; EGYED ET AL. 2007, S. 117; MEYER ET AL. 2008; WINKLER UND PILGRIM 2010, S. 557]. Kern und Hauptanliegen der vorliegenden Arbeit ist es daher, ein breites Spektrum an Nutzenpotentialen für Traceability-Modelle aufzuzeigen. Dafür werden eine Reihe innovativer Methoden erarbeitet, mit deren Hilfe, unter der Voraussetzung bereits existierender Traceability-Modelle, die Entwicklung mechatronischer Produkte unterstützt werden kann. Um die Methoden umsetzen und evaluieren zu können, wurde zunächst das prototypische Traceability-Werkzeug ModelTracer implementiert, welches im folgenden Kapitel 3.6 vorgestellt wird TRACEABILITY-MODELLIERUNGSWERKZEUG MODELTRACER Das prototypische Traceability-Werkzeug ModelTracer 28 bildet das technologische Fundament für die im weiteren Verlauf dieser Arbeit vorgestellten Forschungsergebnisse. Die Motivation hinter der Implementierung des Werkzeugs ModelTracer war wie erwähnt die technologische Verfügbarkeit einer Plattform zur Evaluierung der entwickelten Traceability- Methoden an einem Software-Prototyp. Die technologischen und funktionalen Eigenschaften des Werkzeugs werden in diesem Kapitel komprimiert dargestellt. Für eine detailliertere Beschreibung des Werkzeugs sei auf [BORNATH 2011] verwiesen. Im ModelTracer können die Artefakte, zwischen denen eine Nachverfolgbarkeit hergestellt werden soll, aus unterschiedlichen Autorenwerkzeugen geladen werden. Der ModelTracer ist somit ein integratives Traceability-Werkzeug, in dem die Traceability-Informationen generiert und verwaltet werden sollen. Eine Modifikation der integrierten Inhalte ist dabei weder gewünscht noch technologisch möglich. Der Import beliebiger Original-Artefakte aus den führenden Autorenwerkzeugen wird mit Hilfe des in der Entwicklung befindlichen, konfigurierbaren Mapping-Tools ISYMAP durchgeführt. Durch die zusätzliche Fokussierung auf gängige Datenaustauschformate wie bspw. das Requirements Interchange Format (ReqIF) soll eine 28 vormals ISYFMU 63

93 3 Traceability-Grundlagen Offenheit und Austauschbarkeit hinsichtlich der angebundenen Softwarewerkzeuge erreicht werden. Diese Forderung nach Schnittstellen, die eine Datenintegration mit den in der Systementwicklung genutzten Autorenwerkzeugen erlaubt, ist auch in [HOFFMANN ET AL. 2004, S. 304] formuliert. Die eindeutigen Identifizierer, die den Elementen in den jeweiligen Autorenwerkzeugen zugewiesen wurden, werden auch im ModelTracer weiterverwendet und in der MySQL- Datenbank des ModelTracers, ebenso wie die erfassten Tracelinks, zentral abgespeichert. Der Hintergrund dieses Vorgehens ist es, Änderungen an den Originalartefakten jederzeit detektieren und ggf. synchronisieren zu können. Damit erfüllt der ModelTracer zwei Forderungen von [AIZENBUD-RESHEF ET AL. 2006], wonach Traceability-Informationen nicht in den Originalartefakten verwaltet, sondern eineindeutige Identifizierer zu den referenzierten Originalelemente in den Traceability-Spezialwerkzeugen vorgehalten werden sollen. Das Werkzeug ModelTracer unterstützt eine qualitative Traceability, mit welcher bis auf Artefakt- und Elementlevel nachverfolgt werden kann. Es kann die Datenstrukturen Listen, Hierarchien und Netze verarbeiten. Die modellierbaren Tracelinks sind generell typisierbar, aber im Rahmen dieser Arbeit ausschließlich untypisiert. Sie können sowohl Phasen-intern als auch -übergreifend sowie Artefakt-intern oder -übergreifend modelliert werden. Somit wird das in Abbildung 23 dargestellte Modellierungskonzept, bei dem Artefakte aus beliebigen Phasen der Produktentwicklung miteinander verknüpft werden können, durch den ModelTracer vollumfänglich unterstützt. Abbildung 23: Modellierungskonzept des Werkzeugs ModelTracer 64

94 3 Traceability-Grundlagen Das Werkzeug ModelTracer wurde in der integrierten Entwicklungsumgebung Eclipse mit der Programmiersprache Java implementiert. Ihm liegt kein starres Traceability-Schema zugrunde. Der ModelTracer basiert im Wesentlichen auf dem in Abbildung 24 dargestellten Datenmodell. Darin wird deutlich, dass das zu entwickelnde Produkt aus digitalen Artefakten besteht, die wiederum aus einzelnen Elementen aufgebaut sind. Diese Elemente können untereinander hierarchische Relationen aufweisen und über Tracelinks mit anderen Elementen verknüpft sein. Abbildung 24: Datenmodell des ModelTracers Die Basisfunktionalität des ModelTracers erlaubt das paarweise Laden von Artefakten in einer hierarchischen Listenansicht. In dieser Ansicht (siehe Abbildung 25) können zwischen beliebigen Elementpaaren per Ziehen & Ablegen 29 Tracelinks modelliert werden. Der erfasste Tracelink wird anschließend durch ein Dreieck-Symbol am jeweiligen Element sowie, beim Überfahren von einem der beiden verknüpften Elemente, durch eine gestrichelte Linie symbolisiert. Die Liste der verfügbaren Artefakte für das Produkt wird in der linken Spalte der Benutzeroberfläche angezeigt. 29 Engl. Fachbegriff: Drag & Drop 65

95 3 Traceability-Grundlagen Abbildung 25: Screenshot des Werkzeugs ModelTracer Um die notwendigen Aufwände für das Erfassen der Tracelinks zu reduzieren, wurde unter anderem die Methode EcoTracing entwickelt [BORNATH 2011; STARK UND FIGGE 2011]. Diese Modellierungsunterstützung beruht auf den in Kapitel 2.2 beschriebenen hierarchischen und transitiven Eigenschaften der Produkt-beschreibenden Artefakte. Daraus folgt, dass bei einer verworfenen Elementkombination (siehe rotes Kreuz zwischen A1 und B1 in Abbildung 26) keines der jeweiligen Kindelemente eine inhaltliche Abhängigkeit zum jeweils komplementären Elternelement aufweist und demzufolge nicht überprüft werden muss. Wird die inhaltliche Abhängigkeit einer Elementkombination hingegen bestätigt (siehe grünes Häkchen zwischen A1 und B2 in Abbildung 26), wird allen Kindelementen ein Status zugewiesen, demzufolge diese im Anschluss durch die Methode zur Prüfung vorgeschlagen werden. Abbildung 26: Schematische Darstellung der EcoTracing-Methode 66

96 3 Traceability-Grundlagen Sind besagte Kindelemente alle überprüft worden und wurde bei mindestens einem von ihnen eine Abhängigkeit bestätigt, kann der Tracelink für die Elementkombination der Eltern formal aufgehoben werden, da er nun durch die Verknüpfung zum Kind repräsentiert wird. Dies dient der Vermeidung redundanter Informationen und der Informationseffizienz beim späteren Visualisieren der Traceability-Informationen. Insgesamt sind mit der Modellierungsunterstützung EcoTracing erhebliche Effizienzsteigerungen beim Erfassen der Tracelinks erzielbar [STARK UND FIGGE 2011; KÖNIGS ET AL. 2012]. Der ModelTracer bietet somit Funktionalitäten, um Artefakte aus verteilten heterogenen Autorensystemen zu akquirieren und zwischen diesen Tracelinks zu modellieren. Der integrative Ansatz des Werkzeugs zielt darauf ab, dass die Entwickler stets auf aktuellen Daten arbeiten und der ModelTracer in unterschiedlichen Entwicklungsumgebungen eingesetzt werden kann. Ein Hindernis für eine Anwendbarkeit des Werkzeugs ist die aktuell geringe Anzahl an unterstützten Datenaustauschformaten. Die Fertigstellung des konfigurierbaren Mapping-Tools ISYMAP wäre aus diesem Grund ein großer Schritt in Richtung einer verbreiterten Einsetzbarkeit des ModelTracers. Sollte der ModelTracer über das Stadium eines Prototyps weiterentwickelt werden, müsste für eine kommerzielle Nutzung ein deutlich breiteres Spektrum an Schnittstellen angeboten werden ZUSAMMENFASSUNG UND DISKUSSION In Kapitel 3 wurde zunächst eine Einführung in die theoretischen Grundlagen der Traceability gegeben sowie ihre Notwendigkeit begründet. Aus den Darstellungen zum Stand der Technik und den Ausführungen aus der Fachliteratur kann entnommen werden, dass es zwar ein breites Spektrum an Software-Werkzeugen und Methoden für die Traceability gibt, diese aber hauptsächlich aus zwei Gründen nicht umfassend gelebt werden. In [GOTEL UND FINKELSTEIN 1994] und [GOTEL 1996] sind die Ergebnisse einer ausführlichen Studie publiziert, in welcher die Ursachen für die mangelhafte Verbreitung der Traceability analysiert werden. Zu den genannten Ursachen zählen u. a. die zu formalen Traceability- Methoden, die nicht einfach auf existierende Unternehmensprozesse adaptiert werden können sowie Schwierigkeiten, die für die Etablierung des Traceability-Prozesses notwendigen Informationen zu beschaffen. Zusätzlich stehen den Verantwortlichen häufig zu wenige Ressourcen zur Verfügung. Besonders betont wird jedoch, dass zwischen dem äußerst aufwändigen Erfassen und Aktualisieren der Tracelinks und deren späterer Verwertung ein großes Ungleichgewicht besteht (vgl. [EGYED ET AL. 2007, S. 116; WINKLER UND PILGRIM 2010]). Die Motivation für Entwickler, Traceability-Methoden und -Werkzeuge in ihren Entwicklungsprojekten anzuwenden, kann intrinsischer oder extrinsischer Natur sein. Eine extrinsische Motivation kann beispielsweise eine gesetzliche Bestimmung, die in Kapitel genannten Standards oder eine qualitätssichernde Maßnahme sein. Ein echter Fortschritt für die Akzeptanz von Traceability wäre jedoch eine Steigerung der intrinsischen Motivation bei den Entwicklern. Dafür müssen in der Forschung mehrere Herausforderungen aufgegriffen werden. 67

97 3 Traceability-Grundlagen Zum einen muss den Entwicklern das Erfassen der Tracelinks deutlich erleichtert werden. Zum anderen muss allen an der Traceability Beteiligten verständlich sein, welchen Nutzen das Praktizieren dieser Methode hat. Ziel dieser Arbeit ist es daher, das Ungleichgewicht zugunsten der Verwertung zu verändern. Dazu sollen innovative Methoden zur Nutzung der Traceability-Informationen entwickelt und evaluiert werden, um die intrinsische Motivation der Entwickler zu unterstützen. Im folgenden Kapitel wird daher untersucht, inwieweit existierende Traceability-Modelle genutzt werden können, um etablierte Methoden der Produktentwicklung zu unterstützen. 68

98 4. TRACEABILITY-BASIERTE UNTERSTÜTZUNG ETABLIERTER METHODEN DER PRODUKTENTWICKLUNG Viele Unternehmen erkennen keinen ausreichenden Nutzen in der Traceability, welcher die aufwändige Modellierung der Tracelinks zwischen den Produkt-relevanten Artefakten rechtfertigen würde [AIZENBUD-RESHEF ET AL. 2006; WINKLER 2008]. Daher entscheiden sich nur wenige Unternehmen, die dazu gesetzlich nicht verpflichtet sind, dafür, Traceability zu praktizieren. Und die Unternehmen, welche Traceability praktizieren, nutzen diese häufig nur zu reinen Dokumentationszwecken [BEIER ET AL. 2013]. Die Forschungsfrage, die in diesem Kapitel behandelt wird, adressiert somit die Verwendung von Verknüpfungsinformationen zur rechentechnischen Unterstützung etablierter Methoden der Produktentwicklung. Dazu wird in Kapitel 4.1 eine Auswahl etablierter Methoden vorgestellt sowie Möglichkeiten aufgezeigt, wie diese durch Anreicherung mit Traceability-Daten den Entwicklungsprozess für mechatronische Produkte unterstützen können. Für die Auswahl der Methoden wurde ein breites Portfolio etablierter Entwicklungsmethoden untersucht und hinsichtlich der drei Kriterien Etabliertheit im industriellen Kontext, Grad der Automatisierbarkeit der Methode durch Traceability-Daten sowie notwendiger Modellierungsaufwand für die benötigten Traceability-Daten bewertet. Die Methoden, die bei dieser Bewertung am besten abschnitten, werden im folgenden Verlauf des Kapitels vorgestellt. Zu jeder vorgestellten Methode werden in Kapitel 4.1 zusätzlich bereits existierende Traceability-basierte Lösungen aus Forschung und industrieller Anwendung vorgestellt, um den aktuellen Stand der Technik und Anwendung abzubilden. In Kapitel 4.2 wird für eine ausgewählte Methode exemplarisch die prototypische Implementierung beschrieben, um deren rechentechnische Unterstützung aufzuzeigen und die Wirksamkeit der Unterstützung zu belegen. Das Kapitel schließt mit der Diskussion der vorgestellten Ergebnisse und den Möglichkeiten für deren Anwendbarkeit in der ingenieurtechnischen Praxis (Kapitel 4.3). Die in diesem Kapitel vorgestellten Methoden wurden durch den Autor dieser Arbeit entwickelt. Die prototypische Implementierung des House-of-Quality-Werkzeugs erfolgte im Rahmen der vom Autor betreuten Diplomarbeit von Philipp Goerisch [GOERISCH 2010]. Teile der 69

99 4 Traceability-basierte Unterstützung etablierter Methoden der Produktentwicklung vorgestellten Ergebnisse wurden zudem in [BEIER ET AL. 2011] und [BEIER ET AL. 2013] publiziert TRACEABILITY-UNTERSTÜTZBARE METHODEN FÜR DIE PRODUKTENTWICKLUNG UND IHRE UMSETZUNG IM STAND DER WISSENSCHAFT UND TECHNIK Viele Teilprozesse der Entwicklung mechatronischer Produkte können durch spezialisierte Methoden (wie bspw. Fehlermöglichkeits- und Einflussanalyse (FMEA), Quality Function Deployment (QFD) und Fehlerbäume) unterstützt werden. Dennoch wird die überwiegende Mehrzahl dieser Methoden in der industriellen Praxis selten angewandt. Das liegt zum einen am notwendigen Aufwand, aber auch daran, dass zur Durchführung dieser Methoden durch Experten Know-How über die Zusammenhänge des Systems beigesteuert werden muss. [FRICKE ET AL. 2000, S. 174] Berücksichtigt man, dass Tracelinks diese Zusammenhänge explizit abbilden, kann diesem Hindernis begegnet werden. Schließlich ergänzt jeder Entwickler das im Traceability-Modell enthaltene Wissen, wenn er einen Tracelink erzeugt und damit die Abhängigkeit zwischen zwei Elementen bestätigt. Auf diese Art und Weise aggregiert das Traceability-Modell ein umfassendes, reproduzierbares Expertenwissen hinsichtlich der Zusammenhänge eines Systems [MOHAN UND RAMESH 2007; AHMAD ET AL. 2012]. Es erscheint daher sinnvoll, das bei der Ausführung der spezialisierten Methoden benötigte Systemwissen über die im Traceability-Modell explizit abgebildeten Systemzusammenhänge bereitzustellen, um die entsprechenden Teilschritte rechentechnisch zu unterstützten. Dadurch können die Methoden effizienter ausgeführt werden [BARNETT UND RAJA 1995, S. 24] und die Entwickler können sich stärker auf das kreative Produzieren neuer Lösungen, anstatt auf das Reproduzieren von Vorhandenem konzentrieren. Für alle vorgestellten Methoden wird idealisierend postuliert, dass das Traceability-Modell vollständig und korrekt erzeugt wurde [WINKLER UND PILGRIM 2010, S. 541]. Idealisierungen sind bei der Modellbildung üblich: in [STACHOWIAK 1973, S. 132] wird diese, allen Modellen immanente Eigenschaft mit dem Begriff Verkürzungsmerkmal bezeichnet (siehe Kapitel 2.1). Diese postulierte Idealisierung birgt jedoch das Risiko, dass sowohl fälschlicherweise modellierte als auch fehlende Tracelinks zu Fehlern in den Ergebnissen der Methoden führen können, da diese Fehler u. U. in die Methoden übernommen werden. In der Praxis werden die Traceability-Modelle nicht immer der Idealisierung entsprechen. Daher sollten die Entwickler den Ergebnissen der vorgestellten Methoden, wie allen automatisiert generierten Informationen, nicht blind vertrauen. Andererseits ergibt sich durch die vermehrte Anwendung der Traceability-Daten auch die Chance, deren Plausibilität kontinuierlich zu überprüfen. Beschäftigen sich mehr Anwender häufiger mit dem Inhalt der Traceability-Daten, steigt die Wahrscheinlichkeit, dass fehlerhaft modellierte und fehlende Tracelinks entdeckt werden. Bei den folgenden Ausführungen werden ausgewählte Methoden vorgestellt, deren Durchführung durch Traceability-Modelle unterstützt werden kann, sowie deren aktuelle Umset- 70

100 4 Traceability-basierte Unterstützung etablierter Methoden der Produktentwicklung zung im Stand der Wissenschaft und Technik diskutiert. Dabei wird zwischen Produkt- und Prozess-bezogenen Methoden unterschieden PRODUKT-BEZOGENE METHODEN UND IHRE UNTERSTÜTZBARKEIT DURCH TRACEABILITY-INFORMATIONEN Eine bereits gut erforschte Möglichkeit, Traceability-Modelle zu nutzen, bietet die Analyse und Restrukturierung von Produktstrukturen (siehe Abbildung 27). Dabei wird die Struktur der Tracelinks innerhalb des Artefakts Produktstruktur mittels einer Traceability-Matrix abgebildet und analysiert. Für die automatische Analyse dieser Matrizen existiert eine Vielzahl unterschiedlicher Algorithmen (z. B. Matrix-Clustering, -Partitioning, -Tearing oder -Banding). Abbildung 27: Analyse und Restrukturierung von Produktstrukturen mittels Clustering in einer Traceability-Matrix [LINDEMANN ET AL. 2009, S. 90] Für das Modularisieren von Systemen in Subsysteme bietet sich die Methode Clustering 30 an, um stark vernetzte Systembereiche zu identifizieren, die sich unter Umständen für eine Modularisierung anbieten. Das Clustering ist generell zur Betrachtung von zeitlich statischen Fragestellungen geeignet. Dabei ist das Ziel, Spalten und Zeilen so zu arrangieren, dass zwischen den gebildeten Clustern bzw. Modulen ein Minimum an Interaktionen existiert. Das bedeutet im Hinblick auf die Repräsentation in der DSM, dass möglichst viele Markierungen innerhalb der Cluster liegen sollen [YASSINE 2004; KELLER ET AL. 2006, S. 64; LINDEMANN ET AL. 2009]. Weitere Algorithmen zur Systemanalyse mittels Abhängigkeitsmatrizen werden detailliert in [YASSINE 2004] diskutiert. LOOMEO von der TESEON GmbH, der Cambridge Advanced Modeller (CAM) und METUS von der ID-Consult GmbH sind Software-Werkzeuge für eine solche Analyse und Restrukturierung von Produktstrukturen. Dazu nutzt LOOMEO Traceability-Matrizen, um zunächst die Tracelinks aufzunehmen. Dann wird das Abhängigkeitsmuster mit Hilfe von Analyse- 30 Ein Cluster bzw. Modul nimmt entsprechend die Form eines Quadrates innerhalb der DSM ein. Die Elemente, deren Diagonalelemente sich innerhalb des Quadrates befinden, bilden das Cluster. 71

101 4 Traceability-basierte Unterstützung etablierter Methoden der Produktentwicklung Techniken ermittelt und durch Restrukturierung der Matrix optimiert [MAURER 2006; MAURER 2007; TESEON GmbH 2012]. Der CAM ist eine Software-Plattform, bei der das Vorgehen analog zu LOOMEO erfolgt. Spezielle Toolboxen erlauben das Modellieren von Produktstrukturen mittels Traceability-Matrizen und die Synthese von Produktarchitekturen [JARRATT ET AL. 2004; WYNN ET AL. 2010a; Cambridge EDC 2012; WYATT ET AL. 2012]. Bei der Software METUS können die Artefakte Funktionen, Subfunktionen, Komponenten und Module jeweils in einer Listenstruktur und Tracelinks zwischen deren Elementen modelliert werden. Die Tracelinks werden von verschiedenen Analysealgorithmen genutzt, um beispielsweise die Kosten oder das Gewicht des betrachteten Produkts zu optimieren. Um den Aufwand für das Modellieren zu reduzieren, bietet METUS optional eine PLM-Integration an [ID-Consult GmbH 2012; TRETOW ET AL. 2008]. Auch Teamcenter 9.1 bietet eine Analyse-Funktionalität an, die der von METUS sehr ähnlich ist. Zusätzlich dazu können für zwei wählbare Artefaktstrukturen Coverage Analysen 31 konfiguriert und durchgeführt werden, wobei bspw. überprüft wird, ob jedem Element der einen Struktur mindestens ein Element der verknüpften Struktur zugeordnet ist [Siemens PLM Software Inc. 2012]. Das Ziel der Methode Quality Function Deployment (QFD) ist das Übersetzen von häufig subjektiv geprägten Kundenwünschen in objektive Entwicklungskriterien [ROSENTHAL 1992]. Durch die Wichtung der Kundenwünsche und die Zuordnung zu Produkteigenschaften kann definiert werden, welche Produkteigenschaften mit Priorität zu entwickeln sind [REILLY 1999]. Die Zuordnung zwischen Kundenwünschen, die üblicherweise in Anforderungen repräsentiert sind, und Produkteigenschaften, die entweder über Funktionen, Verhaltensmodelle oder Elemente der Produktstruktur repräsentiert werden, kann über Traceability-Informationen erfolgen. QFD wurde ursprünglich im Jahr 1966 von Dr. Yoji Akao entwickelt [AKAO 1994]. Sullivan beschreibt, wie die Wirksamkeit der Methode durch ihren Einsatz seit 1972 bei Mitsubishi Heavy Industries Shipyard demonstriert werden konnte [SULLIVAN 1986]. Die drei Hauptziele der Methode sind laut [AKAO 1994, S. 339]: die Priorisierung der Kundenwünsche, die Übertragung der Kundenwünsche in technische Charakteristika und Spezifikationen sowie das Herstellen von Produkten hoher Qualität durch Ausrichtung der Entwicklung auf die Kundenzufriedenheit. Zusätzlich dient QFD aber auch als Kommunikationsmittel zwischen den unterschiedlichen Fachabteilungen: so werden für Ingenieure technische Parameter festgelegt, für das Marketing die Kundenwünsche zum Ausdruck gebracht und das Management kann allgemeine Strategien daraus ableiten [HAUSER UND CLAUSING 1988]. 31 Die Methode Coverage Analyse wird auf Seite 76 detailliert beschrieben. 72

102 4 Traceability-basierte Unterstützung etablierter Methoden der Produktentwicklung In der ersten Phase des QFD wird das sog. House of Quality (HoQ) beschrieben, was zugleich auch das am stärksten verbreitete Element der gesamten Methode ist. Die grundlegende Maxime hinter dem HoQ lautet, dass Produkte so gestaltet sein sollten, dass sie den Wünschen der Kunden Rechnung tragen [BARNETT UND RAJA 1995, S. 31]. Zu diesem Zweck werden den Kundenwünschen Produkteigenschaften zugeordnet, um sicherzustellen, dass einerseits alle Kundenwünsche adressiert werden und andererseits die Produkteigenschaften je nach Relevanz priorisiert werden können [HAUSER UND CLAUSING 1988]. Es müssen also Elementen des Artefakts Anforderungen, welches die Kundenwünsche in Form von Kundenanforderungen beinhaltet, Elemente des Artefakts Funktionen, welches im hier ausgeführten Kontext exemplarisch die Produkteigenschaften repräsentiert 32, zugeordnet werden. Diese Zuordnung kann aus den modellierten Tracelinks abgeleitet werden. Im Wesentlichen können die Schritte des HoQ wie folgt zusammengefasst werden: 1. Erfassung und Auflistung der Kundenwünsche, 2. Priorisierung der gelisteten Kundenwünsche auf einer vordefinierten Skala, 3. Bewertung des eigenen Produkts sowie derer des Wettbewerbs hinsichtlich des Erfüllungsgrades der gelisteten Kundenwünsche, 4. Erfassung und Auflistung der Produkteigenschaften, welche die Kundenwünsche erfüllen, 5. Zuordnung der Produkteigenschaften zu den Kundenwünschen, die sie erfüllen, in einer Relationsmatrix und Bewertung des Erfüllungsgrades auf einer vordefinierten Skala, 6. Bewertung des eigenen Produkts sowie derer des Wettbewerbs hinsichtlich der erzielten technischen Werte je Produkteigenschaft, 7. Festlegung von technischen Zielwerten für die Entwicklung des eigenen Produkts, 8. Bewertung des Grades der gegenseitigen Beeinflussung der Produkteigenschaften in einer Korrelationsmatrix - dem Dach des House of Quality, 9. Berechnung und Zuweisung von Prioritäten für jede Produkteigenschaft auf Basis der Priorität der Kundenwünsche und des Erfüllungsgrades in der Relationsmatrix. Der hauptsächliche Mehrwert des HoQ besteht darin, die Qualität des Produktes zu steigern, indem es stark an den Kundenwünschen ausgerichtet wird [HAUSER UND CLAUSING 1988]. Es führt zusätzlich dazu, dass unterschiedliche Menschen aus einem Unternehmen gemeinsam und in eine Richtung denken [HAUSER UND CLAUSING 1988]. 32 Alternativ können die Produkteigenschaften auch durch Verhaltensmodelle oder Attribute der Produktstruktur abgebildet werden (siehe Seite 72). Durch die Festlegung auf das Artefakt Funktionen und dessen lösungsneutrale Prägung können im Sinne des PDD-Ansatzes von WEBER UND DEUBEL nur die Eigenschaften des Produkts betrachtet werden. Für eine zusätzliche Zuordnung der Produktmerkmale - im Sinne der PDD - müsste das Artefakt Produktstruktur samt der enthaltenen Attribute (wie bspw. geometrische Abmessungen, Material etc.) den Anforderungen gegenübergestellt werden. (Vgl. dazu [WEBER UND DEUBEL 2003, S. 1]) 73

103 4 Traceability-basierte Unterstützung etablierter Methoden der Produktentwicklung Bei [GOTEL UND FINKELSTEIN 1994, S. 95] ist beschrieben, wie etablierte Methoden wie bspw. das HoQ genutzt werden können, um Traceability-Informationen zu erzeugen und damit die Tracelink-Modellierung zu unterstützen. Die vorgeschlagene Vorgehensweise ist somit umgekehrt zur hier vorgeschlagenen Vorgehensweise. Dennoch werden damit die potentiellen Synergien zwischen Traceability und HoQ-Methode unterstrichen. Eine tatsächliche softwaretechnische Implementierung eines HoQ-Assistenten in einem Traceability-Werkzeug ist nichtsdestotrotz weder in einem akademischen Prototyp noch in einer kommerziellen Software erfolgt. Der einzig bekannte Versuch einer solchen Kombination bildet die AID-Methode, die in [HOLLEY ET AL. 2010, S. 1117] vorgestellt wird. Dabei werden drei Matrizen (DSM, MDM und QFD) aufgebaut. Die tatsächliche Kopplung von Abhängigkeitsmatrix und QFD-Matrix besteht ausschließlich darin, dass die Komponenten aus der DSM in die QFD-Matrix importiert werden. Eine Nutzung der Traceability-Informationen, also der Informationen über die Zusammenhänge zwischen den einzelnen Komponenten, findet nicht statt. Im industriellen Umfeld ist die Fehlermöglichkeits- und Einflussanalyse (FMEA) 33 die am stärksten verbreitete Zuverlässigkeitsmethode [BERTSCHE ET AL. 2009, S. 8]. In einer Anwenderstudie des Fraunhofer IPT erklärten ca. 60 % der 180 befragten Unternehmen, die FMEA zur Risikobewertung einzusetzen; der mit Abstand höchste Wert [ZENTIS ET AL. 2011]. Die FMEA dient der systematischen Dokumentation von möglichen Fehlern und der Abschätzung ihrer Auswirkungen bereits während der Entwicklung [RHEE UND ISHII 2003; HAFFNER 2005]. Sie wird vor allem bei Neuentwicklungen von sicherheitsrelevanten Bauteilen eingesetzt. Dabei liefert die FMEA Anforderungen für die Testplanung und Fehlerbehandlung. Darüber hinaus hilft sie, bei überwachten mechatronischen Systemen Maßnahmen zur Fehlerentdeckung und -beherrschung zu identifizieren [WOLTERECK 2004, S. 14]. Es gibt eine Vielzahl verschiedener Arten der FMEA, wie beispielsweise die System-FMEA, die Konstruktions-FMEA oder die Fertigungs-FMEA. Im Rahmen dieser Arbeit orientieren sich die Ausführungen an der System-FMEA nach VDA 4.2, die das technische Sicherheitskonzept um Maßnahmen zur Fehlerentdeckung (Überwachung, Diagnose), Fehlerbehandlung und Fehlervermeidung ergänzt [WOLTERECK 2004, S. 10]. Das Ziel der FMEA ist es, für die betrachteten Systeme alle möglichen Ausfallarten zu identifizieren. Darüber hinaus sollen deren Ausfallursachen und Ausfallfolgen aufgezeigt werden. Das Bewerten des möglichen Ausfallrisikos über die Risikoprioritätszahl (RPZ) und die Festlegung von Optimierungsmöglichkeiten schließt die FMEA ab. 33 Engl.: Failure Mode and Effects Analysis 74

104 4 Traceability-basierte Unterstützung etablierter Methoden der Produktentwicklung Nach [BERTSCHE ET AL. 2009, S. 8] läuft die FMEA in fünf Schritten ab: 1. Erstellung einer hierarchischen Systemstruktur aus Systemelementen, 2. Beschreibung der Funktionen und der Funktionsstruktur, 3. Durchführung der Fehleranalyse, d. h. Ermittlung von möglichen Fehlern, Fehlerursachen und Fehlerfolgen, 4. Risikobewertung im FMEA-Formblatt sowie 5. Systemoptimierung mit dem Ziel der Fehlervermeidung bzw. Risikoreduzierung. Die notwendigen Eingangsinformationen können aus den Artefakten Produktstruktur (Schritt 1), Funktionsstruktur (Schritt 2), Fehlerbaum und Auflistung der Entdeckungsmaßnahmen (jeweils Schritt 3) sowie der Auflistung der Vermeidungsmaßnahmen (Schritt 5) entnommen werden. Für sicherheitsrelevante Systeme müssen diese Informationen zwingend erhoben und betrachtet werden. Das Traceability-Modell leistet bei der FMEA den Beitrag, die Zuordnung der Elemente zwischen den einzelnen Artefakten zu definieren und damit das zeitaufwändige Befüllen des FMEA-Formblatts zu unterstützen (Schritt 4). Somit können alle relevanten Informationen für die FMEA-Analyse automatisch aus den schon erstellten Modellen gefiltert, weitergeleitet und wiederverwendet werden. Abbildung 28: Unterstützung der FMEA-Methode durch Traceability In Abbildung 28 ist das Konzept einer Traceability-Unterstützung für eine vereinfachte FMEA schematisch dargestellt 34. Aus Gründen der Übersichtlichkeit ist die Bewertung der drei Grö- 34 Die prototypische Implementierung dieses Konzeptes erfolgte im Rahmen des Verbundprojektes ISYPROM durch einen Forschungspartner, weshalb dieser im Rahmen dieser Arbeit nicht vorgestellt wird. 75

105 4 Traceability-basierte Unterstützung etablierter Methoden der Produktentwicklung ßen Auftretungswahrscheinlichkeit der Ausfallursache (A), Bedeutung der Ausfallauswirkung (B) und Entdeckungswahrscheinlichkeit der Ausfallursache (E) in diesem Schema nicht vorgesehen. Prinzipiell müssen diese Werte natürlich bestimmt werden, um durch Multiplikation von A*B*E die RPZ zu erhalten. Sind diese Werte bereits definiert und im System abgelegt, können sie ebenfalls über Tracelinks identifiziert und automatisch in das FMEA- Formblatt integriert werden. Abbildung 28 stellt dar, wie die für eine Durchführung einer FMEA notwendigen Daten mittels Traceability automatisch aggregiert und dem entsprechenden FMEA-Formblatt hinzugefügt werden. Im konkreten Beispiel soll der Ausfall von Funktion F2 bewertet werden. Der Nutzer wählt also zunächst aus der Funktionsliste die Funktion F2 aus. Über die Tracelinks zwischen den Artefakten Funktionsliste und Fehlerbaum, werden daraufhin die Fehler identifiziert, die zu einem Ausfall von F2 führen. Es wird daher im Traceability-Modell nach Verknüpfungen von F2 zu Elementen des Artefakts Fehlerbaum gesucht. In diesem Fall wird ein modellierter Tracelink gefunden, der zum Fehler Err8 führt. Der Fehler Err8 kann also einen Ausfall der Funktion F2 verursachen. Im nächsten Schritt wird bestimmt, durch welche Entdeckungsmaßnahmen dieser Fehler Err8 festgestellt und durch welche Maßnahmen er vermieden werden kann. Besteht zwischen dem Artefakt Fehlerbaum und den Artefakten Entdeckungs- und Vermeidungsmaßnahmen eine durchgängige Nachverfolgbarkeit, können über die entsprechenden Tracelinks die Elemente EM2 sowie VM1 und VM2 identifiziert werden. Alle identifizierten Elemente können somit nach der Auswahl der zu betrachtenden Funktion automatisch das FMEA-Formblatt befüllen. Damit beschränkt sich die manuelle Tätigkeit für die Entwickler auf die Auswahl der Funktion sowie die jeweilige Bewertung der Faktoren A, B und E. Ziel der Methode Coverage Analyse 35 ist es, Probleme innerhalb der Modellkette zu detektieren, indem Elemente identifiziert werden, die nicht mit vordefinierten anderen Artefakten verknüpft sind [PAIGE ET AL. 2008; WALDERHAUG ET AL. 2009; WINKLER UND PILGRIM 2010, S. 540f]. Auch die Methode Coverage Analyse entspringt ursprünglich der Software- Entwicklung. In [MACMILLAN UND VOSBURGH 1986] wird erstmals vorgeschlagen, den Anforderungen mit Hilfe einer Traceability-Matrix Softwarefunktionen zuzuordnen. Ziel dieser Zuordnung soll es sein, einen Completeness Indicator zu generieren, um erfassen zu können, ob alle Anforderungen durch Softwarefunktionen adressiert wurden. Mittels einer Coverage Analyse können unterschiedliche Fragestellungen überprüft werden. So lässt sich einerseits die externe Validität des Produktes feststellen, also ob jede Funktion des Produktes mit mindestens einer Anforderung verknüpft ist. Damit kann verifiziert werden, dass das Produkt einerseits die erforderlichen Funktionen realisiert und andererseits keine ungewünschten Funktionalitäten beinhaltet, die dessen Preis unnötig erhöhen. Es kann ebenfalls überprüft werden, ob alle essentiellen Anforderungen mit einem Testfall verknüpft sind, um deren adäquate Umsetzung evaluieren zu können [SUTINEN ET AL. 2000, S. 324]. 35 auch Orphan Analysis genannt 76

106 4 Traceability-basierte Unterstützung etablierter Methoden der Produktentwicklung In den genannten Beispielen werden die Tracelinks zwischen den Artefaktpaaren Anforderungen und Funktionsstruktur bzw. Testfälle genutzt, um die Plausibilität des Produktes zu prüfen. Auch für weitere Artefaktpaarungen sind sinnhafte Coverage Analysen denkbar, deren Durchführung, vorbehaltlich eines bereits existierenden Traceability-Modells, keinerlei zusätzlichen Aufwand bedeuten. Dennoch werden diese Methoden in der Entwicklung mechatronischer Produkte kaum angewandt. Die einzige Ausnahme stellen moderne Anforderungsmanagement-Werkzeuge wie bspw. Reqtify, IBM Rational DOORS und IBM Rational RequisitePro dar. Mit diesen können einzelnen Anforderungen Testfälle zugewiesen und deren Vollständigkeit automatisiert abgeprüft werden. Beim Werkzeug Reqtify, das ursprünglich von der Firma Geensoft entwickelt wurde, aber nach der Übernahme durch Dassault Systèmes aktuell in deren V6-Suite integriert wird, werden die Tracelinks über Verweise in der ursprünglichen Anforderungsspezifikation gespeichert. Bei der Coverage Analyse wird dann geprüft, welcher Anteil der Anforderungen einen entsprechenden Verweis auf einen Testfall aufweist. [Geensoft 2010a] Das Werkzeug IBM Rational DOORS bietet die Möglichkeit, Filter auf die Datensätze anzuwenden. Diese Filter können durch den Nutzer detailliert konfiguriert werden. In Kombination mit den vorgesehenen Traceability-Spalten bieten die Filter die Möglichkeit, eine einfache Coverage Analyse durchzuführen, indem nur Elemente mit bzw. ohne Tracelink dargestellt werden. [IBM Corp. 2012b] In der Matrixansicht von IBM Rational RequisitePro können zwei Artefakte geladen werden, für deren Überprüfung konfigurierbare Filter definierbar sind. So kann bspw. analysiert werden, ob es ein Element gibt, dass nicht mindestens einen Tracelink zum anderen Artefakt aufweist. Diese Funktionalität ist jeweils nur für eine bestimmte Artefaktpaarung möglich. Dennoch kann mit dieser Filterfunktion eine Coverage Analyse durchgeführt werden. [IBM Corp. 2011] PROZESS-BEZOGENE METHODEN UND IHRE UNTERSTÜTZBARKEIT DURCH TRACEABILITY-INFORMATIONEN Bei der bereits genannten Methode Matrix-Partitioning, die hauptsächlich genutzt wird, um mittels einer DSM Prozess- oder Tätigkeitsartefakte zu betrachten, werden Zeilen und Spalten derart manipuliert, dass möglichst wenige Markierungen oberhalb der Diagonalen erscheinen oder diese zumindest möglichst nah an der Diagonalen positioniert sind. Dies wird u. a. genutzt, um Prozesse in parallele, serielle und gekoppelte Abfolgen aufteilen zu können [YASSINE 2004]. Eine andere Methode adressiert die Unterstützung bei der Erstellung von Fortschrittsberichten. Fortschrittsberichte müssen derzeit in vielen Unternehmen regelmäßig generiert werden, um gegenüber dem Management darzustellen, wie der aktuelle Entwicklungsstand im jeweiligen Entwicklungsbereich ist. Dieses Vorgehen wird in der Literatur auch mit dem Begriff Progress Monitoring bezeichnet. Das stellt einerseits für die Ersteller der Berichte einen großen Aufwand dar. Andererseits sind diese zumeist auf die Informationen angewiesen, die ihnen der entsprechende Entwicklungsverantwortliche übermittelt, wodurch eine subjektive 77

107 4 Traceability-basierte Unterstützung etablierter Methoden der Produktentwicklung Verzerrung des tatsächlichen Entwicklungsstandes durch den Informationslieferanten nicht ausgeschlossen werden kann. Ein weiteres Defizit der praktizierten Vorgehensweise ist die mangelnde Aktualität der Daten. Bei einem manuellen Prozess müssen aus unterschiedlichen Quellen Daten zusammengetragen und dann für eine Gesamtübersicht ausgewertet und aufbereitet werden. Dieser Prozess kann unter Umständen Tage beanspruchen. Zum Zeitpunkt der Präsentation der Ergebnisse sind diese Daten möglicherweise bereits nicht mehr aktuell. Ein Fortschrittsbericht sollte jedoch auf aktuellen Daten basieren [WINKLER UND PILGRIM 2010, S. 543]. Da die Erstellung der Fortschrittsberichte kein kreativer Prozess ist, sondern primär die Aggregation von existierenden Informationen erfordert, sollte er umfassend rechentechnisch unterstützt werden. Das Kernziel der Methode Progress Monitoring ist es, das Management dazu zu befähigen, zu jedem beliebigen Zeitpunkt Übersichten zum aktuellen Entwicklungsstand zu generieren objektiv und ohne zusätzlichen menschlichen Aufwand. Dabei werden die Traceability-Daten hauptsächlich als Daten-Aggregator genutzt [RAMESH UND EDWARDS 1993; SUTINEN ET AL. 2000, S. 324; LAGO ET AL. 2009]. Das grundsätzliche Konzept des Progress Monitorings sieht vor, dass der Status eines Elements (im Beispiel in Abbildung 29 interessiert der Status von X1 in Artefakt X) aus den aktuellen Status aller verknüpften Elemente abgeleitet werden kann. Über die Traceability-Daten kann identifiziert werden, mit welchen Elementen in Artefakt Y das zu betrachtende Element X1 verknüpft ist und welchen Status diese aktuell aufweisen. Im Beispiel in Abbildung 29 sind die Elemente Y1 und Y2 mit X1 verknüpft. Aus den beiden aggregierten Status 36 von Y1 und Y2 (mittlerer Status gelb bzw. optimaler Status grün ) ergibt sich für X1 somit der Status gelb. Abbildung 29: Schematisches Konzept des Traceability-unterstützten Progress Monitorings Wesentliche Voraussetzung für die Einsetzbarkeit dieser Methode ist die Integrierbarkeit der Daten aus den Autorensystemen im Traceability-Werkzeug. Durch diese Datenintegration ist es möglich, auf die im Autorensystem verwalteten aktuellen Statusinformationen der Elemente zuzugreifen. Die Auswertung und Aufbereitung der Statusinformationen (nach zuvor definierbaren Kriterien) ist der Anspruch der Methode Progress Monitoring. Maßgeblich für die Ausprägung der Methode ist die unternehmensspezifische Definition von Kriterien, unter 36 Vereinfachend wurde im betrachteten Beispiel allen Elementen ein Status entsprechend einer gängigen Ampel-Skala zugewiesen. 78

108 4 Traceability-basierte Unterstützung etablierter Methoden der Produktentwicklung welchen Voraussetzungen der Status von Elementen eines Artefaktes geändert bzw. festgesetzt wird. Diese Kriterien müssen im Datenmodell des Traceability-Werkzeugs abgebildet sein. Üblicherweise werden beispielsweise Anforderungen als erfüllt betrachtet, wenn alle Testfälle mit denen sie abgeprüft werden, erfolgreich bestanden wurden. In diesem Fall müssten Tracelinks zwischen den Anforderungen und ihren Testfällen modelliert sein. Weisen alle Testfälle, die mit einer bestimmten Anforderung verlinkt sind, den Status erfolgreich bestanden auf, wird der Anforderung der Status erfüllt zugewiesen. Analoge Zusammenhänge sind ebenfalls zwischen anderen Artefakten modellierbar. So kann bspw. unter dem Postulat, dass für die vollständige Fertigstellung einer Funktion alle beitragenden Bauteile freigegeben sein müssen, auch ein Progress Monitoring zwischen Funktionsstruktur und Produktstruktur durchgeführt werden. Voraussetzung dafür wäre auch hier, dass die aktuellen Status der Bauteile im Autorensystem (bspw. PLM) verwaltet werden. In Abbildung 30 ist schematisch dargestellt, wie mit Hilfe des Traceability-basierten Progress Monitorings der aktuelle Status einer Anforderung automatisiert ermittelt werden kann. Dazu müssen die Status der zugehörigen Testfälle aggregiert werden, die im führenden Autorensystem verwaltet werden. Um den Status der Anforderung A1.1 zu ermitteln, wird diese zunächst vom Nutzer aus der Anforderungsstruktur ausgewählt. Daraufhin wird im Traceability- Modell überprüft, ob es eine Verknüpfung von A1.1 zu Elementen des Artefakts Testfälle gibt. Mit Hilfe der modellierten Tracelinks zwischen den beiden Artefakten wird identifiziert, dass die beiden Testfälle TF1.1 und TF2 zur Erfüllung von A1.1 erfüllt sein müssen. Aus dem Autorensystem, welches die Testfälle verwaltet, sind die jeweiligen Status von TF1.1 und TF2 verfügbar. Da im dargestellten Beispiel beide Testfälle erfolgreich absolviert wurden (in der Abbildung durch eine grüne Ampel symbolisiert) wird A1.1 ebenfalls der Status erfüllt zugewiesen (ebenfalls durch eine grüne Ampel symbolisiert). Anforderungen A A1 A1.1 A2 A3 Testfälle TF TF1 TF2 TF3 TF1.1 TF1.2 Abbildung 30: Ermittlung des Status einer Anforderung mittels Traceability Mit dem Traceability-basierten Progress Monitoring kann somit jederzeit der aktuelle Status jeder beliebigen Anforderung ermittelt werden. Dieses kontinuierliche Überwachen aktueller Entwicklungsstände kann prinzipiell zwischen allen Artefaktpaarungen erfolgen, die über Tracelinks miteinander verbunden sind. Eine solche Funktionalität zum Überwachen und Berichten des Projektfortschritts für das Projektmanagement wird in der Literatur als besonders sinnhaft für Traceability-Werkzeuge empfohlen [RAMESH ET AL. 1997, S. 408; DUAN UND 79

109 4 Traceability-basierte Unterstützung etablierter Methoden der Produktentwicklung CLELAND-HUANG 2006, S. 8; International Organisation for Standardization 2009, S. 12; WINKLER UND PILGRIM 2010, S. 554]. Für viele große Unternehmen (hier vereinfachend auf die Gruppe der OEM reduziert) stellt die Integration von Zulieferunternehmen in den Entwicklungsprozess eine besondere Herausforderung dar. Besonders in der frühen Phase der OEM-Zulieferer-Kommunikation, in der eine enge Abstimmung über die konkrete Spezifikation des späteren Produktes erfolgen muss, besteht sowohl beim Zulieferer als auch beim OEM großer Handlungsbedarf [ALMEFELT ET AL. 2006, S. 130]. In der aktuell gelebten Praxis erfolgt der Informationsaustausch wenig spezifisch und wenig modellbasiert. So wurde im Rahmen der in Kapitel beschriebenen Studie ein Fall berichtet, bei dem der OEM die Spezifikation ausgedruckt an den Zulieferer geschickt hat. Motivation für dieses Vorgehen war der Schutz des geistigen Eigentums. Der Zulieferer hat diese Spezifikation anschließend durch Scannen und Texterkennung wieder digitalisiert, um sie mit viel Aufwand wieder in den ursprünglichen Zustand zu überführen. Zulieferunternehmen berichten weiterhin von unnötig ausführlichen Spezifikationen, bei denen nur ein geringer Anteil der Dokumentation den eigentlichen Vertragsgegenstand adressiert. Dies ist für beide Parteien negativ, da zum einen der OEM mehr Produktwissen preisgibt als nötig wäre und andererseits der Zulieferer den zusätzlichen Aufwand betreiben muss, die relevanten Informationen aus der Spezifikation herauszufiltern. Ein Werkzeug zum Datenaustausch mit Zulieferunternehmen muss es also ermöglichen, die für das zu entwickelnde System relevanten Daten aus den zu betrachtenden Artefakten herauszufiltern. Die dazu notwendigen Informationen über die Systemzusammenhänge sind im Traceability-Modell gespeichert. Mit ihrer Hilfe können die Elemente aller Artefakte identifiziert werden, die für zur Spezifikation des zu entwickelnden Systems benötigt werden und daher an den Zulieferer kommuniziert werden sollten. Abbildung 31: Schematische Darstellung OEM-Zulieferer-Kommunikation mittels Traceability 80

110 4 Traceability-basierte Unterstützung etablierter Methoden der Produktentwicklung In Abbildung 31 ist ein solches Vorgehen schematisch dargestellt. Dabei wird über die Tracelinks ermittelt, welche Daten aus den Artefakten Funktionen und Anforderungen für das vom Zulieferer zu entwickelnde Element der Produktstruktur P2 relevant sind. Im dargestellten Beispiel sind das die Funktionen F1 und F3 sowie die Anforderungen R1 und R3.1. Um die Elemente in ihrem Kontext zu belassen und damit für den Zulieferer interpretierbar zu gestalten, werden jeweils noch alle Eltern- und Kindelemente der identifizierten Elemente ergänzt, womit auch der hierarchischen Transitivität der Artefakte Rechnung getragen wird. Diese Auswahl an Daten wird durch den OEM dem Zulieferer zur Verfügung gestellt. Das Zulieferunternehmen erhält alle für die Entwicklung notwendigen Informationen in verarbeitbarer Form, womit ein unnötiges Filtern und Transformieren der Daten entfällt. Der OEM seinerseits reduziert die Risiken für sein geistiges Eigentum, da ausschließlich die relevanten Daten kommuniziert werden. Das Nutzen von Traceability-Modellen zur Unterstützung der OEM-Zulieferer-Kommunikation ist bisher weder in Forschung noch industrieller Praxis dokumentiert ZUSAMMENFASSUNG UND DISKUSSION Ziel der vorangegangenen Ausführungen war es, exemplarisch zu verdeutlichen, dass durch die Verwendung von Traceability-Modellen die Produktentwicklung an vielen Stellen unterstützt werden kann. Dazu wurde eine Auswahl an Entwicklungsmethoden vorgestellt und erläutert, wie diese durch Traceability-Modelle unterstützt werden können. Um möglichen Anwendern eine Auswahl für deren ingenieurmäßige Nutzbarkeit zu erleichtern, werden im Folgenden für einige Methoden die Stufen der notwendigen Modellierungsgranularität (siehe Kapitel 3.3.1) je verwendetem Artefakt benannt. Dazu werden in Abbildung 32 etablierte Methoden aufgelistet und aufgezeigt, zwischen welchen Artefakttypen und auf welcher Granularitätsebene Tracelinks modelliert werden müssen, um die Durchführung der entsprechenden Methode informationstechnisch unterstützen zu können. Die entsprechenden Ziffern für die notwendige Modellierungsgranularität sind in Abbildung 32 als Symbol jedem Artefakt zugeordnet: Stufe 1 Artefaktebene Stufe 2 Elementebene Stufe 3 Parameterebene. Dabei bedeutet ein halbtransparentes Symbol, dass diese Modellierungsgranularität unter Umständen sinnhaft ist, aber nicht notwendigerweise so detailliert praktiziert werden muss. 81

111 4 Traceability-basierte Unterstützung etablierter Methoden der Produktentwicklung Abbildung 32: Stufenmodell der Traceability-Granularität je Artefakt zur Unterstützbarkeit ausgewählter Entwicklungsmethoden In [HOFFMANN ET AL. 2004, S. 304; International Organisation for Standardization 2009, S. 5] und [WINKLER UND PILGRIM 2010, S. 540f] ist die Notwendigkeit beschrieben, Traceability- Werkzeuge mit zusätzlichen Funktionalitäten zu versehen, um beispielsweise die Durchführung von Coverage Analysen, des Progress Monitorings oder auch des House of Quality zu unterstützen. Dennoch ist mit Ausnahme der Coverage Analysen eine konkrete Beschreibung und Ausprägung solcher Methoden sowie eine softwareseitige Umsetzung derselben im Stand der Technik bisher nicht dokumentiert. In diesem Kapitel wurden nunmehr Konzepte entwickelt und beschrieben, wie eine Vielzahl etablierter Methoden der Produktentwicklung, darunter die oben genannten, durch Traceability-Informationen teilautomatisiert werden können. Die softwaretechnische Implementierung dieser Methoden würde deren Durchführung deutlich effizienter machen, die Produktentwicklung somit punktuell unterstützen und die Akzeptanz von Traceability in der industriellen Praxis stärken. Im folgenden Kapitel 4.2 wird daher exemplarisch die konkrete Ausdetaillierung und softwaretechnische Umsetzung der Traceability-Unterstützung für die Methode House of Quality ausführlich beschrieben. Die Methode House of Quality wurde ausgewählt, da sie im eingangs geschilderten Bewertungsverfahren den höchsten Wert aller betrachteter Entwicklungsmethoden erhielt. 82

112 4 Traceability-basierte Unterstützung etablierter Methoden der Produktentwicklung 4.2. DETAILLIERUNG UND PROTOTYPISCHE IMPLEMENTIERUNG DER METHODE TRACEABILITY-UNTERSTÜTZTES HOUSE OF QUALITY Um die Wirksamkeit der Methode Traceability-unterstütztes House of Quality zu verifizieren, wurde diese als Funktionalität des Traceability-Prototyen ModelTracer implementiert. Die Detaillierung der Methode sowie deren konkrete Umsetzung in der Software werden im Folgenden schrittweise vorgestellt. Als Beispielprodukt dient dabei ein Modell eines Fahrrads, wobei für das House of Quality nur die Artefakte Anforderungen (beinhalten die Kundenwünsche) und Funktionsstruktur (repräsentiert die Produkteigenschaften) betrachtet werden müssen. Laut [BARNETT UND RAJA 1995, S. 28] ist für eine Managementsicht die Reduzierung der House-of-Quality-Methode auf die Kennwerte Priorisierung der Kundenwünsche und deren Erfüllungsgrad ausreichend. Dieser Vorschlag wird hier aufgegriffen. Ziel der folgenden House-of-Quality-Methode ist demnach weniger ein Vergleich mit den Konkurrenzprodukten des Wettbewerbs, sondern primär ein Darstellung der Berücksichtigung relevanter Kundenwünsche. Daraus kann ein Priorisierungsvorschlag für das Management abgeleitet werden, um Ressourcen entsprechend allokieren zu können [BARNETT UND RAJA 1995, S. 28]. In [HORVATH UND RUDAS 2007] wird allgemein ein starker Bedarf für eine derartige Entscheidungsunterstützung formuliert, da die im PLM-Umfeld gängigen Lösungen die vorhandenen Interdependenzen zwischen den Objekten nicht abbilden. Diese Aussage wird durch [RIEBISCH ET AL. 2011, S. 11] gestützt, wo die explizite Darstellung von Abhängigkeiten als notwendige Voraussetzung für eine fundierte Entscheidungsfindung postuliert wird. Daher wird bei den Ausführungen im Rahmen der vorliegenden Arbeit auf die Priorisierung der Kundenwünsche und deren Erfüllungsgrad fokussiert. Setzt man voraus, dass die Kundenwünsche bereits im Anforderungsmodell und die Produkteigenschaften in der Funktionsstruktur erfasst sind, ist es sinnvoll, für diese Artefakte keine erneute Auflistung sondern eine Auswahlmöglichkeit vorzusehen. Damit kann das in Kapitel beschriebene allgemeine Vorgehen auf die im Folgenden ausgeführten Schritte angepasst werden. Für jeden einzelnen dieser sieben Schritte wird zudem die Umsetzung in dem entwickelten Software- Prototypen sukzessive anhand von Screenshots vorgestellt. 83

113 4 Traceability-basierte Unterstützung etablierter Methoden der Produktentwicklung Schritt 1: Auswahl des Artefakts, in welchem die Anforderungen dokumentiert sind Der erste Schritt der Methode beinhaltet die Auswahl der Kundenwünsche durch den Nutzer. Dies ist notwendigerweise eine Tätigkeit, die auf der Expertise der Entwickler beruht und nicht automatisiert erfolgen kann. Im vorliegenden Beispiel werden die Kundenwünsche, wie häufig auch in der industriellen Realität, im Anforderungsartefakt verwaltet. Daher muss in der Bedienoberfläche des Prototyps im Reiter Artefakte zunächst das Artefakt Anforderungen selektiert werden. Dazu wird das Drop-Down-Menü aufgeklappt und das Artefakt Anforderungsliste selektiert. Daraufhin baut sich in der linken Hälfte der graphischen Oberfläche der hierarchische Anforderungsbaum auf (siehe linke Hälfte der Abbildung 33). Abbildung 33: Auswahl des Kundenwünsche-Artefakts (hier: Anforderungsliste) Schritt 2: Auswahl des Artefakts, in welchem die realisierenden Produkteigenschaften dokumentiert sind In Schritt 2 ist das Artefakt auszuwählen, in welchem die Produkteigenschaften dokumentiert sind, die diese Anforderungen umsetzen sollen. Generell können die Produkteigenschaften in verschiedenen Artefakten verwaltet werden. Die konkrete Entscheidung liegt auch an der Art der zu betrachtenden Eigenschaften. Stehen beispielsweise Materialeigenschaften oder das Volumen des Produkts im Vordergrund, würde es sich anbieten diese Informationen dem PLM-System zu entnehmen. Aus diesem Grund obliegt es dem Nutzer, das jeweils geeignete Artefakt auszuwählen. Da im dargestellten Beispiel lediglich allgemeine Eigenschaften des Beispielproduktes Fahrrad betrachtet werden, welche im Artefakt Funktionsstruktur beschrieben sind, wird dieses selektiert. Dazu wird das Drop-Down-Menü auf der rechten Seite der Bedienoberfläche aufgeklappt und das Artefakt Funktionsstruktur ausgewählt. Daraufhin baut sich in der rechten 84

114 4 Traceability-basierte Unterstützung etablierter Methoden der Produktentwicklung Hälfte der graphischen Oberfläche automatisch die hierarchische Funktionsstruktur auf (siehe Abbildung 34). Abbildung 34: Auswahl des Produkteigenschaften-Artefakts (hier: Funktionsstruktur) Schritt 3: Auswahl der konkret zu betrachtenden Anforderungen In der industriellen Praxis wird eine große Anzahl an Anforderungen verwaltet. Nicht jede der Anforderungen entspricht dabei einem Kundenwunsch. Im Rahmen des HoQ sollen jedoch ausschließlich Kundenwünsche betrachtet werden. Um unnötigen Mehraufwand zu vermeiden, müssen daher im folgenden Schritt 3 die konkret zu betrachtenden Anforderungen aus dem Artefakt Anforderungsliste ausgewählt werden. Dieser Auswahlprozess ist eine bewusste menschliche Entscheidung und daher ebenfalls eine nicht automatisierbare Tätigkeit. Dazu müssen in der hierarchischen Anforderungsliste (in der linken Hälfte der graphischen Oberfläche) die konkreten, zu betrachtenden Anforderungen durch das Setzen eines Häkchens ausgewählt werden (siehe linke Box in Abbildung 35). Schritt 4: Zuordnung der Funktionen zu den Anforderungen In der Theorie müssen nun den Anforderungen manuell Produkteigenschaften zugeordnet werden, die diese erfüllen. Es ist also durch den Entwickler festzulegen, welche Funktionen die jeweilige Anforderung realisieren. Da diese Zuordnung im Traceability-Modell, über Tracelinks zwischen den Anforderungen und Funktionen, bereits dokumentiert ist, wird die- 85

115 4 Traceability-basierte Unterstützung etablierter Methoden der Produktentwicklung ser Schritt automatisch durch den Software-Prototyp durchgeführt. Dazu wird für jede ausgewählte Anforderung im Traceability-Modell automatisch nach Verknüpfungen zu Elementen des Artefakts Funktionsstruktur gesucht. Alle identifizierten Elemente werden in der dargestellten hierarchischen Struktur automatisch durch Markierung mit einem Häkchen selektiert (siehe Schritt 4 in der rechten Box in Abbildung 35). Ist diese Zuordnung nicht korrekt, kann der Nutzer fehlende Funktionen durch das Setzen eines Häkchens manuell ergänzen oder überflüssige Funktionen durch Deselektion entfernen. Schritt 3 Schritt 4 Abbildung 35: Manuelle Auswahl der zu betrachtenden Anforderungen (Schritt 3 linke Box) und automatische Zuordnung von Funktionen (Schritt 4 rechte Box) Schritt 5: Wichtung der ausgewählten Anforderungen auf vordefinierter Skala Die ausgewählten Anforderungen können für den späteren Charakter des Produktes eine unterschiedliche Wichtigkeit haben. Daher müssen zunächst die ausgewählten Anforderungen gewichtet werden, um im späteren Verlauf der HoQ-Methode die einzelnen Funktionen priorisieren zu können. Für die Wichtung der Anforderungen ist eine konfigurierbare Skala mit einheitlichen Werten im Datenmodell des House of Quality Assistenten vordefiniert. Für diese und alle folgenden Aktivitäten muss der Nutzer in den Reiter House of Quality wechseln. Darin wird bereits eine automatisch vorbereitete Matrix angezeigt, die alle selektierten Anforderungen (in der linken Spalte) und Funktionen (in der oberen Zeile) enthält (siehe Abbildung 36). Ferner ist bereits automatisch den Anforderungen jeweils der vordefinierbare Standardwert für deren Wichtung und den Funktionen jeweils der vordefinierbare Standardwert für den Erfüllungsgrad der zugeordneten Anforderung zugewiesen worden. 86

116 4 Traceability-basierte Unterstützung etablierter Methoden der Produktentwicklung Zellen in denen Anforderungen nicht-verknüpften Funktionen gegenüber stehen bleiben hingegen leer. Anschließend kann der Nutzer über ein Drop-Down Menü jeder Anforderung einen Wichtungswert auf der vordefinierten Skala zuweisen (in diesem Beispiel: weniger wichtig, wünschenswert, wichtig, sehr wichtig oder essentiell ), sofern der bereits zugewiesene Standardwert nicht korrekt ist (siehe Abbildung 36). Standardmäßig hat der Prototyp jeder Anforderung zunächst automatisch den mittleren Wert wichtig zugewiesen. Dieser Wichtungswert bildet einen der Faktoren für die spätere Ermittlung der Funktionspriorisierung und wird daher im Datenmodell des Prototyps gespeichert. Abbildung 36: Wichtung ausgewählter Anforderungen auf vordefinierter fünfstufiger Skala Schritt 6: Bewertung des Erfüllungsgrades der Funktionen hinsichtlich der jeweiligen Anforderung auf vordefinierter Skala Sind alle Anforderungen korrekt gewichtet, muss für jedes Elementpaar mit einem Tracelink der Erfüllungsgrad manuell festgelegt werden. Der Erfüllungsgrad gibt an, inwieweit die Produkteigenschaft zur Erfüllung der jeweiligen Anforderung beiträgt. Auch für diese Bewertung ist zunächst eine Skala zu definieren. Im Prototyp wurde eine vierstufige Skala realisiert. Jedem Elementpaar muss somit einer der vier Werte keine Verknüpfung, 1 (also geringer Erfüllungsgrad), 2 (mittlerer Erfüllungsgrad) oder 3 (hoher Erfüllungsgrad) zugewiesen werden (siehe Abbildung 37). 87

117 4 Traceability-basierte Unterstützung etablierter Methoden der Produktentwicklung Je höher der Erfüllungsgrad einer Funktion für die korrespondierende Anforderung, umso höher sollte sie bewertet werden. Deswegen stellt auch der Erfüllungsgrad einen weiteren Faktor für die spätere Priorisierung dar. Im dargestellten Beispiel erhalten alle Elementpaare, die durch einen Tracelink verbunden sind, zunächst den Standardwert 1. Allen Elementpaaren, die nicht durch einen Tracelink verbunden sind, wird, wie bereits beschrieben, der Standardwert keine Verknüpfung zugewiesen. Die Zelle erscheint daraufhin leer. Abbildung 37: Bewertung des Erfüllungsgrades auf vordefinierter vierstufiger Skala Schritt 7: Berechnung von Priorisierungsvorschlägen für alle Funktionen Abschließend erfolgt die Ermittlung eines Vorschlages zur Priorisierung der einzelnen Produktfunktionen. Dieser Schritt ist eines der Hauptziele der Methode House of Quality. Auf Grundlage dieser Bewertung wird ersichtlich, wie groß der Beitrag jeder Funktion für die Realisierung der gewünschten Kundenanforderungen ist. Leisten Funktionen einen überdurchschnittlich hohen Beitrag, kann ihnen im weiteren Verlauf der Entwicklung daraufhin eine höhere Priorität zugewiesen werden. Um den Wert für den Beitrag zur Erfüllung von Kundenanforderungen zu ermitteln, werden für jede Funktion die mathematischen Produkte spaltenweise aufsummiert, die sich aus der Multiplikation der Wichtung des Kundenwunsches und des Erfüllungsgrades der Elementpaarung ergeben. Die für jede Funktion automatisch berechnete Summe wird im Prototyp in der Zeile Auswertung ausgegeben. Den Funktionen werden außerdem, absteigend nach der Bewertung sortiert, Platzierungen zugewiesen. Diese Platzierungen, die in der Zeile Ranking aufgeführt sind (siehe Abbildung 38), stellen den eigentlichen Priorisierungsvorschlag für die Entscheidungsträger in der Entwicklung dar. 88

118 4 Traceability-basierte Unterstützung etablierter Methoden der Produktentwicklung Abbildung 38: Ermittlung von Priorisierungsvorschlägen für die Produktfunktionen Abschießend kann das entwickelte House of Quality abgespeichert werden, um es ggf. zu einem späteren Zeitpunkt wiederverwenden zu können. Zusammenfassend kann festgehalten werden, dass das vorgestellte Beispiel belegt, wie eine Unterstützung der Methode House of Quality durch Nutzung von Traceability-Daten erfolgen kann. Der manuelle Aufwand für die Durchführung der Methode kann dadurch stark verringert werden. Abbildung 39 verdeutlicht, welche wesentlichen Schritte durch die Traceability- Informationen automatisiert unterstützt werden können. Abbildung 39: Wesentliche Schritte der House-of-Quality-Methode und deren Unterstützbarkeit durch Traceability-Informationen 89

119 4 Traceability-basierte Unterstützung etablierter Methoden der Produktentwicklung Der wissenschaftliche Fokus der Arbeit liegt auf den Betrachtungen bzgl. Artefaktübergreifender Tracelinks. Daher wurde die Bewertung der gegenseitigen Beeinflussung der Produkteigenschaften, wie sie in der Theorie über das sog. Dach des House of Quality umgesetzt werden kann, im Prototyp nicht berücksichtigt. Dafür müsste das Dach des House of Quality gezeichnet werden und darin die Artefakt-internen Tracelinks zwischen den Produkteigenschaften, also hier den Funktionen, aufgenommen werden. Da diese Informationen generell im Traceability-Modell enthalten sind, ist eine zukünftige softwaretechnische Umsetzung dieser Erweiterung technologisch möglich. Für einen allgemeinen Nachweis der Unterstützbarkeit der Methode House of Quality war sie im Rahmen der vorliegenden Arbeit jedoch nicht notwendig. Fehlende, weil nicht-verknüpfte Elemente können im Prototyp zwar aus einer Liste des Modells ausgewählt werden. Die derart impliziert modellierte Verknüpfung wird aktuell jedoch nicht dokumentiert. In einer Weiterentwicklung des Prototyps könnten diese Tracelink- Kandidaten einer Liste der wahrscheinlich fehlenden Verknüpfungen hinzugefügt werden, um das Know-How der Entwickler durchgängig zu nutzen ZUSAMMENFASSUNG UND DISKUSSION In Kapitel 4.1 wurde geschildert, wie durch das Nutzen von Traceability-Modellen Produktund Prozess-bezogene Methoden in der Entwicklung mechatronischer Produkte eingesetzt werden können. Über ein Bewertungsschema wurden die Methoden untereinander verglichen. Die als besonders geeignet bewertete Methode House of Quality wurde im Rahmen eines Prototyps implementiert, um deren Wirksamkeit zu verifizieren. Zu diesem Zweck wurde die prototypische Implementierung der Methode mit Hilfe eines Beispielprodukts verifiziert. Somit ist die Forschungsfrage eindeutig zu bejahen: durch das Nutzen von Traceability- Informationen kann eine Vielzahl von Methoden zur Entwicklung mechatronischer Produkte zumindest teilweise rechentechnisch unterstützt werden. Dadurch können diese Methoden effizienter angewendet sowie potentielle Fehler durch manuelle Datenakquise vermieden werden. Die beschriebene Unterstützung etablierter Entwicklungsmethoden mit Traceability-Informationen bietet somit große Nutzenpotentiale und verbessert zudem die Durchgängigkeit und Konsistenz der Modellierung. Das größte Risiko eines solchen Vorgehens besteht darin, dass eventuelle Fehler im Traceability-Modell, durch das automatische Weiterleiten der Daten, auch die Ergebnisse der Methoden verfälschen. Um dem entgegenzuwirken, sollten alle Traceability-unterstützten Softwarelösungen Funktionalitäten zur manuellen An- und Abwahl von Elementen vorsehen. Demgegenüber steht jedoch der große Vorteil, dass durch den verbreiteten Einsatz von Traceability-Daten entlang des Entwicklungsprozesses einerseits Entwicklern deren Mehrwert verdeutlicht und andererseits, durch das regelmäßige Beschäftigen mit den Daten, deren Plausibilität ständig kontrolliert wird. Dadurch erfährt Traceability eine höhere Akzeptanz im Unternehmen und die modellierten Daten bleiben auf einem aktuellen Stand. Je plausibler der Mehrwert von Traceability für die Produktentwicklung dargestellt werden kann, umso wahrscheinlicher wird deren tatsächliche Anwendung in der ingenieurtechnischen Praxis. 90

120 4 Traceability-basierte Unterstützung etablierter Methoden der Produktentwicklung Die entwickelten Ergänzungen zu den bestehenden Methoden und der Prototyp wurden zudem im Rahmen von Industrieworkshops potentiellen Anwendern vorgestellt. Das erste Feedback aus der Industrie ist positiv. In einem nächsten Schritt wären die Methoden im industriellen Einsatz zu validieren. Zudem sollten zukünftige Forschungsaktivitäten zum einen die generelle Unterstützbarkeit weiterer Methoden evaluieren. Neben den in Kapitel vorgeschlagenen Produktbezogenen Methoden ist auch eine Ausweitung der Betrachtung etwa auf Prozess- und Komplexitätskennzahlen vorstellbar. Erforscht werden sollte auch die Rückspiegelung von manuellen Änderungen am Tracelink-Modell während der Durchführung der beschriebenen Methoden. Nutzt man diese Informationen im Sinne einer Qualitätskontrolle des vorhandenen Traceability-Modells, erfährt dieses eine kontinuierliche, implizite Wartung. Generell ist es vorstellbar, dass alle Methoden der Produktentwicklung, zu deren Durchführung Wissen über die Zusammenhänge zwischen Entwicklungsdaten benötigt wird, zu einem gewissen Grad durch eine Auswertung des Traceability-Modells unterstützt werden können. Ein Aspekt, der in dieser Betrachtung bisher ausgeblendet wurde, ist die Unterstützung des Änderungsmanagements durch Traceability-Modelle. Eine detaillierte Betrachtung dieser spezifischen Ingenieursaktivität erfolgt in den Kapiteln 6 und 7 der vorliegenden Arbeit. Die erläuterten Lösungskonzepte erlauben es, die Produktentwicklung punktuell zu unterstützen. In [HOFFMANN ET AL. 2004, S. 303f; International Organisation for Standardization 2009, S. 5] und [WINKLER UND PILGRIM 2010, S. 543] wird zusätzlich gefordert, dass Traceability-Werkzeuge Produktentwicklung auch durchgängig, mittels einer nutzerfreundlichen, graphischen Repräsentation der Tracelinks zur Erleichterung des Systemverständnisses, unterstützen sollen. Diesen Aspekt des Nutzens von Traceability durch graphische Aufbereitung behandelt das folgende Kapitel 5. 91

121

122 5. GRAPHISCHE DARSTELLUNG VON TRACEABILITY- MODELLEN Wie in Kapitel 3.1 dargestellt wurde, zielt Traceability darauf ab, das Wissen um die Zusammenhänge zwischen verschiedenen Produkt-beschreibenden Artefakten zu explizieren. In Kapitel 2.3 wurde zudem erläutert, dass im Rahmen der Produktentwicklung Artefakte von unterschiedlichen Disziplinen erzeugt werden, die derzeit zum Teil isoliert betrachtet werden. Die Besonderheit und Mächtigkeit der Mechatronik liegt jedoch im symbiotischen Zusammenspiel der drei beteiligten Disziplinen. Deren Teillösungen müssen daher präzise interagieren und ihre inhaltlichen und technischen Schnittstellen den Entwicklern bereits früh während der Entwicklung gewahr sein. Es ist demnach essentiell, dass bei den jeweiligen Entwicklern ein ausgeprägtes Verständnis um die Zusammenhänge zwischen den verschiedenen Disziplin-spezifischen Artefakten gegeben ist. In Abbildung 40 ist eine exemplarische Auswahl der Artefakte dargestellt, die generiert werden müssen, um ein Toter-Winkel-Warnsystem für ein KFZ zu entwickeln. An diesem mechatronischen Beispielsystem wird ersichtlich, dass es einerseits Artefakte gibt, die für alle drei entwickelnden Disziplinen relevant sind (hier: Anforderungen und Funktionsstruktur). Andererseits wird auch eine Vielzahl Disziplin-spezifischer Artefakte erstellt (hier bspw. Software-Code und Produktstruktur). Die wesentlichen Charakteristika dieser Artefakte müssen jedoch auch für die Entwickler aus anderen Disziplinen erkennbar sein. Durch die explizite Modellierung der Tracelinks zwischen den Artefakten wäre es dem Funktionsverantwortlichen für die Tote-Winkel-Warnung möglich, auf einen Blick nachzuvollziehen, welches generelle Konzept für die Regelung des Assistenzsystems ausgewählt wurde und wie dessen operatives Verhalten in der Simulation prognostiziert wird (im Bespiel in Abbildung 40 repräsentiert durch das Verhaltensmodell). Ferner könnte er überprüfen, wie das darin enthaltene Teilsystem zur Ansteuerung der Warn-LED softwareseitig realisiert wurde (Software-Code) und ob dessen Komplexität durch die freien Kapazitäten des gewählten Steuergeräts (Produktstruktur) überschlägig abgedeckt werden kann. Mit diesem umfassenden Wissen, um das Zusammenspiel der gewählten Lösungen kann der Funktionsverantwortliche nun eine Aussage hinsichtlich der Erfüllung der an das Assistenzsystem gestellten Anforderungen treffen und bei Konflikten frühzeitig Gegenmaßnahmen einleiten. 93

123 5 Graphische Darstellung von Traceability-Modellen Abbildung 40: Abbildung der Zusammenhänge zwischen den Artefakten eines Toter-Winkel- Warnsystems und deren Disziplin-Zugehörigkeit Um die im Traceability-Modell dokumentierten Informationen für die Entwickler effizient nutzbar zu machen, müssen diese möglichst eingängig abgebildet werden. Denn durch das Sehen, einem wesentlichen Teil des kognitiven Systems, können mehr Informationen aufgenommen werden, als durch alle anderen Sinne zusammen [WARE 2004]. Welche technologischen Möglichkeiten für die visuelle Repräsentation von relationalen Datensätzen, wie es Traceability-Modelle sind [KELLER ET AL. 2006], existieren und welche besonderen Anforderungen dabei im Kontext der Entwicklung mechatronischer Produkte zu beachten sind, wird in diesem Kapitel diskutiert. Die primäre Forschungsfrage dieses Kapitels behandelt den Zusammenhang zwischen der konkreten visuellen Aufbereitung der Traceability-Informationen und deren Lesbarkeit durch die Anwender. Das Ziel ist es dabei, eine neuartige Visualisierungsform zu entwickeln, die ein möglichst effizientes Arbeiten mit Traceability-Modellen erlaubt. Die Kernaufgabe des in diesem Kapitel zu konzipierenden Visualisierungskonzepts ist somit die Unterstützung beim Finden eines beliebigen, digitalen Entwicklungsobjektes und seiner Verknüpfungen zu anderen Elementen auf Basis von Traceability-Informationen. Das gesamte Kapitel 5 behandelt daher die Möglichkeiten und Potentiale der Datenvisualisierung von Traceability-Informationen. Kapitel 5.1 gibt zunächst eine Übersicht der Grundlagen zum Thema Datenvisualisierung in Bezug auf Traceability-Modelle. In Kapitel 5.2 werden anschließend existierende Methoden und Werkzeuge zur Visualisierung von Traceability-Informationen gegliedert nach Repräsentationsform vorgestellt, verglichen und diskutiert, woraus in Kapitel 5.3 eine Hypothese abgeleitet wird. Aufbauend auf dieser Hypothese wird in Kapitel 5.4 ein innovatives Visualisierungskonzept hergeleitet und detailliert. Die Eignung der entwickelten Anordnung der Artefakte, wie sie dem Visualisierungskonzept zugrunde liegt, und damit auch die Validität der Hypothese, wird in Kapitel 5.5 evaluiert. Auf Basis der 94

124 5 Graphische Darstellung von Traceability-Modellen Ergebnisse dieser Nutzerstudie wird das Visualisierungskonzept in Kapitel 5.6 weiterentwickelt sowie ein adäquates Interaktionskonzept abgeleitet. Die Implementierung dieser beiden Konzepte im Prototyp Ariadne s Eye wird in Kapitel 5.7 beschrieben. Eine vergleichende Evaluierung von Ariadne s Eye mit einer etablierten Anordnungsform wird in Kapitel 5.8 vorgestellt. Das abschließende Kapitel 5.9 fasst die dargelegten Inhalte zur Traceability- Visualisierung zusammen. Die in diesem Kapitel vorgestellten konzeptionellen und methodischen Inhalte wurden durch den Autor dieser Arbeit entwickelt. Die prototypische Implementierung des Visualisierungswerkzeugs Ariadne s Eye erfolgte im Rahmen der Studienarbeit von Robert Müller [MÜLLER 2011]. Auszüge des Visualisierungskonzepts wurden zudem in [BEIER ET AL. 2012a; KÖNIGS ET AL. 2012] und [BEIER ET AL. 2012b] publiziert GRUNDLAGEN DER INTERAKTIVEN, VISUELLEN REPRÄSENTATION VON TRACEABILITY-MODELLEN Um eine geeignete Visualisierung von Traceability-Modellen zu erreichen, müssen einige theoretische Grundlagen beachtet werden. In Kapitel werden jedoch zunächst die Motivation und die Notwendigkeit zur visuellen Repräsentation von Traceability-Modellen beschrieben. Im anschließenden Kapitel werden dann die notwendigen Begrifflichkeiten sowie Grundlagen aus der Informationsvisualisierungstheorie erläutert, bevor in Kapitel Anforderungen an ein Visualisierungskonzept für die Abbildung von Traceability- Informationen für die Entwicklung mechatronischer Systeme zusammengefasst werden MOTIVATION UND NOTWENDIGKEIT DER VISUELLEN REPRÄSENTATION VON TRACEABILITY-MODELLEN Die Hauptmotivation hinter der intuitiven, visuellen Aufbereitung von Traceability- Informationen ist der Bedarf, Entwickler bei dem Erfassen komplexer Systemzusammenhänge zu unterstützen, indem deren Interpretation erleichtert wird [DUAN UND CLELAND-HUANG 2006; DIEHL ET AL. 2008; PAVLOPOULOS ET AL. 2008, S. 8; LANDESBERGER ET AL. 2010]. Eine Studie, deren Ergebnisse in [KELLER ET AL. 2006, S. 63] beschrieben sind, verdeutlicht, dass Anwender Schwierigkeiten haben, die Produktkomplexität zu verstehen. Daher brauchen sie leicht zugängliche, intuitive Modelle, die die Systemzusammenhänge aufzeigen. Laut [JOHNSON ET AL. 2006] ist die Visualisierung gar essentiell für das Lösen komplexer Probleme. Diese These wird in [STACHOWIAK 1980, S. 53] unterstrichen, wonach allen Erkenntnisprozessen ein Abbildungsprozess zugrunde liegt. Der Vorteil der visuellen Darstellung von Inhalten liegt darin, dass Nutzer bildliche Inhalte sehr schnell erfassen können [SHNEIDERMAN 1996, S. 337]. In [LINOS ET AL. 1994] wird in einer experimentellen Studie belegt, dass die Abbildung der Abhängigkeiten zwischen Programmelementen dabei hilft, das Programm zu verstehen. Das Ziel der visuellen Anordnung 37 ist es dabei, die Informationen leicht lesbar, verständlich und nutzbar aufzubereiten [PURCHASE 1998, S. 80]. Da Entwick- 37 Engl.: Layout 95

125 5 Graphische Darstellung von Traceability-Modellen lung eine primär menschliche Aufgabe ist [FINKELSTEIN UND FINKELSTEIN 1983], dient die Informationsvisualisierung somit der menschlichen Entscheidungsfindung [WARE 2004; ARIAS- HERNÁNDEZ ET AL. 2011, S. 51]. In [SUTINEN ET AL. 2000, S. 325] wurde im Rahmen einer Industriestudie festgestellt, dass besonders die Generierung einer für alle Entwicklungsbeteiligten gemeinsamen Sicht auf das Produkt und dessen Zusammenhänge ein Mehrwert der Traceability-Visualisierung ist. Die Tatsache, dass eine Änderung in einer Disziplin Auswirkungen auf das gesamte System haben kann [BUUR UND ANDREASEN 1989, S. 155], verdeutlicht die Notwendigkeit, die Interdependenzen zu verstehen, um die Produktqualität wahren zu können [DUAN UND CLELAND- HUANG 2006, S. 5]. Mittels der Visualisierung von Traceability-Modellen kann also ein Werkzeug für die explizite Abbildung der Systemzusammenhänge geschaffen werden, das für Laien und Experten aus unterschiedlichen Disziplinen gleichermaßen nutzbar ist. Eine solche Visualisierungsunterstützung von Traceability-Daten wäre für eine Vielzahl von Entwicklungstätigkeiten und -entscheidungen eine Hilfe. An dieser Stelle seien beispielhaft zwei hypothetische Entwicklungsszenarien beschrieben, um plastisch zu veranschaulichen, wozu diese Informationen konkret genutzt werden können. Abbildung 41: Identifikation der Steuergeräte für die Funktion "Toter-Winkel-Warnung" Im ersten Szenario möchte ein Entwickler der Steuergeräte-Funktion Toter-Winkel- Warnung in Erfahrung bringen, auf welche physischen Steuergeräte sein Code später aufgespielt wird. Dies ist wichtig, um berücksichtigen zu können, welche Hardware- Voraussetzungen zur Funktionsrealisierung gegeben sein werden und wie die partitionierten Teile des Codes orchestriert werden können. Dazu öffnet der Funktionsentwickler das Traceability-Visualisierungswerkzeug und lässt sich die Artefakte Funktionsstruktur und Produktstruktur anzeigen. Er identifiziert die von ihm zu entwickelnde Funktion Toter-Winkel- Warnung und schaut, mit welchen Steuergeräten diese in der Produktstruktur verknüpft ist. Aus Abbildung 41 wird ersichtlich, dass die Funktion auf die beiden Steuergeräte AX23-E9 sowie BSH-98T gespielt werden wird. 96

126 5 Graphische Darstellung von Traceability-Modellen Da die Hardware-Spezifika konkret der RAM-Speicher des Steuergeräts AX23-E9 für die Funktionsrealisierung besonders kritisch ist, muss der Entwickler ferner prüfen, welche weiteren Funktionen von diesem Steuergerät unterstützt werden. Daher überprüft er mittels des Traceability-Visualisierungswerkzeugs, zu welchen weiteren Funktionen das Steuergerät AX23-E9 Tracelinks aufweist. Er erkennt, dass zusätzlich die Funktion Außenspiegel verstellen von dem Steuergerät realisiert wird (siehe Abbildung 42). Abbildung 42: Identifikation der vom Steuergerät AX23-E9 zu realisierenden Funktionen Da der Software-Code beider Funktionen auf das Steuergerät aufgespielt wird, müssen dessen Hardware-Ressourcen von beiden Funktionen geteilt werden. Um abschätzen zu können, welche Kapazitäten auf dem Steuergerät noch verfügbar sind, muss er in Erfahrung bringen, welche Kapazitäten durch die Funktion Außenspiegel verstellen bereits allokiert sind. Da der Funktionsentwickler nun weiß, mit welchem seiner Kollegen er in Kontakt treten muss, kann er mit diesem nun klären, welche Teile seiner Funktion vom Steuergerät AX23- E9 umgesetzt werden können und welche ggf. auf das Steuergerät BSH-98T geschoben werden müssen. Im zweiten Szenario möchte sich ein Entwickler einer mechanischen Baugruppe informieren, welche Anforderungen hinsichtlich mechanischer Belastbarkeit an diese gestellt werden. Dazu lässt er sich die Verknüpfungen zwischen der besagten Baugruppe und den Anforderungen im Traceability-Visualisierungswerkzeug anzeigen, wodurch er einen umfassenden Überblick über die geforderte Belastbarkeit erhält. Da ihm bei einer Anforderung hinsichtlich der gewünschten Biegesteifigkeit unklar ist, unter welchen Bedingungen diese getestet werden soll, blendet er zudem das Artefakt ein, in dem die Testfälle beschrieben sind. Mittels des Tracelinks zwischen der Biegesteifigkeitsanforderung und dem zugehörigen Testfall identifiziert er den verantwortlichen Testingenieur und kann mit diesem die Details des Testverfahrens besprechen. 97

127 5 Graphische Darstellung von Traceability-Modellen Wie in beiden Szenarien angedeutet, kann die Visualisierung neben der Unterstützung zur Verständnisbildung auch als Kommunikationsmittel in der Entwicklung genutzt werden [JARRATT ET AL. 2004, S. 11]. Dafür ist neben der gemeinsamen Sicht auf die Produktdaten besonders die rollenspezifische visuelle Aufbereitung der Daten wünschenswert, die laut [MARCUS ET AL. 2005, S. 57] zusätzlich bei der Entwicklung komplexer Produkte unterstützt. Deren Vorteil ist es, dass bspw. einem Anforderungsmanager ein anderer, für ihn relevanter Ausschnitt der Daten selektiert und angezeigt wird als einem Simulationsexperten. Dieser Vorgang der kontext-sensitiven Datenselektion wird in der Informationsvisualisierung mit dem Begriff Sichtenbildung bezeichnet. Dennoch ist es laut [ALMEFELT ET AL. 2006, S. 127] notwendig, die Daten im Kontext des Gesamtsystems einzuordnen. In der in [ALMEFELT ET AL. 2006] beschriebenen Studie wurde ermittelt, dass dadurch bessere Produkte entstehen, als wenn Entwickler ausschließlich ihren isolierten Teil des Gesamtsystems betrachten würden. Das ist von besonderer Relevanz, da mechatronische Produkte nicht monolithisch sind. Sie entstehen, indem unterschiedliche Disziplinen, Perspektiven und Detaillevel zur Systementwicklung beitragen [VAN GORP ET AL. 2006, S. 50] (siehe Kapitel 2.3). Zumal bei großen Entwicklungsprojekten Informationen aus unterschiedlichen Datenquellen und Werkzeugen integriert werden müssen [MOHAN UND RAMESH 2007, S. 968], die nicht für jeden Entwickler zugänglich sind. Traceability-Modelle verwalten diese heterogenen Informationen [POHL 1996, S. 78], die allen Entwicklern zugänglich gemacht werden sollten. Oder um eine Analogie von [BURGAUD 2006, S. 2] aufzugreifen: die Traceability-Visualisierung hilft jedem Entwickler, sein Puzzleteil in das große Ganze einzuordnen TERMINOLOGIE UND THEORETISCHE GRUNDLAGEN DER INFORMATIONSVISUALISIERUNG Es gibt unterschiedliche Forschungsgebiete, die sich mit der Visualisierung und Analyse komplexer Sachverhalte beschäftigen. Das Forschungsgebiet zum analytischen Abwägen mittels der Unterstützung interaktiver, visueller Werkzeuge wird unter dem Begriff Visual Analytics zusammengefasst [THOMAS UND COOK 2005]. In [ARIAS-HERNÁNDEZ ET AL. 2011, S. 52] wird derselbe Begriff konkretisiert, als eine Wissenschaft, die sich damit befasst, mittels computergestützter, mathematischer und statistischer Ansätze sehr große Datensätze zu verarbeiten, um damit menschliche Interaktion mit visueller, interaktiver Informationsrepräsentation zum Zweck der individuellen und kollaborativen Analyse und Entscheidungsfindung zu unterstützen. Verwandte Begriffe sind die Informationsvisualisierung, das Graphzeichnen und die Graphvisualisierung. Laut [SCHULZ UND SCHUMANN 2006, S. 166] konzentriert sich das Graphzeichnen auf das Optimieren von Node-Link 38 -Layouts, die Informationsvisualisierung auf das Arbeiten mit Hierarchien, großen Strukturen, unterschiedlichen Sichten und Interaktionsmöglichkeiten, während die Graphvisualisierung beide Ansätze kombiniert. Die Visualisierung von Traceability-Daten entspricht somit weder den Definitio- 38 Mit einem Node-Link-Layout können relationale Datensätze visualisiert werden, indem die Elemente über Knoten (engl.: Nodes) und ihre inhaltlichen Abhängigkeiten über verbindende Kanten (engl.: Links) abgebildet werden. 98

128 5 Graphische Darstellung von Traceability-Modellen nen von Visual Analytics noch von Graphzeichnen oder Informationsvisualisierung im klassischen Sinn, da nicht primär die abstrakte Erkennung und Aufbereitung von Datenmustern im Vordergrund steht, sondern vielmehr auch die Bedeutung jedes einzelnen Elementes relevant ist. Dennoch können einzelne Methoden der genannten Forschungsrichtungen für diesen Anwendungsfall appliziert werden. Die zugrundeliegende Datenstruktur der Traceability-Modelle besteht aus einem relationalem Datenmodell, welches die Zusammenhänge zwischen einzelnen Elementen von Artefakten untereinander und zueinander abbildet [VAN GORP ET AL. 2006, S. 50]. Das entspricht der Definition eines Graphen als einer abstrakten Struktur, die eine Menge von Objekten (hier: Elemente der Artefakte) zusammen mit den zwischen diesen Objekten bestehenden Verbindungen (hier: Verknüpfungen) repräsentiert [WARE 2004; SOSA ET AL. 2005, S. 437; LANDESBERGER ET AL. 2010]. Die folgenden Definitionen sind an die Ausführungen zur Graphentheorie von [TESCHL 2008, S ] angelehnt. Mathematisch kann ein Graph G wie in Formel ( 1 ) beschrieben werden, ( ) [ ] ( 1 ) wobei N die die Menge der Knoten und L die Menge der Kanten von G bilden (vgl. [LANDESBERGER ET AL. 2010]). Graphen, deren Kanten eine Richtung zugewiesen bekommen, werden als gerichtete Graphen bezeichnet, während Graphen, deren Kanten kein solches Attribut aufweisen, ungerichtete Graphen heißen [SCHULZ UND SCHUMANN 2006, S. 168]. Können Graphen ohne Überkreuzungen von Kanten gezeichnet werden, werden sie als planare Graphen bezeichnet [KELLER ET AL. 2006]. Ein Graph heißt gewichtet 39, wenn jeder Kante N ein Gewicht zugeordnet ist. Gewichtete Graphen werden häufig durch sog. Force-directed-Layouts 40 angeordnet, bei denen zwischen den Elementen je nach Gewicht entweder eine Anziehung oder eine Abstoßung vorgegeben wird [LANDESBERGER ET AL. 2010]. Ein Graph, in dem je zwei Knoten durch genau einen Weg verbunden sind, der also keinen Kreisschluss beinhaltet, heißt Baum 41 [TESCHL 2008, S. 208]. Kann in einem Baum ein Knoten als Wurzelknoten ausgezeichnet werden - ein Knoten, der also keinen übergeordneten, sondern nur untergeordnete Knoten hat - spricht man von einem Wurzelbaum. Ein weiteres Merkmal eines Wurzelbaums ist, dass jeder seiner Knoten zusammen mit den untergeordneten Knoten und den dazugehörigen Kanten selbst wieder einen Wurzelbaum bildet [TESCHL 2008, S. 210]. Ein Wurzelbaum stellt einen Sonderfall eines Baums dar. Wurzelbäume wer- 39 Synonym auch: bewerteter Graph 40 Der bekannteste Algorithmus zur Berechnung von Force-Directed-Graphen ist der Fruchterman- Reingold-Algorithmus [FRUCHTERMAN UND REINGOLD 1991]. 41 Englischer Fachbegriff: Tree 99

129 5 Graphische Darstellung von Traceability-Modellen den häufig zur Abbildung von Hierarchien eines Artefaktes genutzt 42, wobei die Anzahl der Knoten auf dem direkten Weg vom Wurzelknoten zu einem beliebigen untergeordneten Knoten die Hierarchieebene dieses Elements angibt [LANDESBERGER ET AL. 2010]. Im weiteren Verlauf der Arbeit wird im Kontext von Wurzelbäumen bzw. Hierarchien für übergeordnete Elemente der Begriff Elternelement 43 und für untergeordnete Elemente der Begriff Kindelement 44 verwendet. Für die visuelle Repräsentation von Graphen können sowohl Node-Link-Diagramme 45 als auch Abhängigkeitsmatrizen verwendet werden [GHONIEM ET AL. 2004; KELLER ET AL. 2006, S. 62]. In der industriellen Anwendung sind zudem hauptsächlich Listen (ggf. mit Verweisen) verbreitet [PINHEIRO 2003; WINKLER 2008; ABMA 2009; WINKLER UND PILGRIM 2010, S. 542], die zwar nicht den gesamten Graphen, aber dennoch ein Artefakt samt der verknüpften Elemente anzuzeigen vermögen. Zur visuellen Abbildung von Traceability-Modellen sind somit drei Repräsentationsformen in Betracht zu ziehen (siehe Abbildung 43), die in Kapitel vergleichend bewertet werden: Node-Link-Diagramme, Abhängigkeitsmatrizen und Listen. Abbildung 43: Repräsentationsformen für die Traceability-Visualisierung - Liste (links), Abhängigkeitsmatrix (mitte) und Node-Link-Diagramm Zur Abbildung von hierarchischen Strukturen 46 werden in der Informationsvisualisierung hauptsächlich zwei verschiedene Techniken genannt: Space-filling- und Node-Link- Diagramme [SEDLMAIR ET AL. 2009, S. 175; LANDESBERGER ET AL. 2010] (siehe Abbildung 44). Bei Node-Link-Methoden, die auch explizit genannt werden, ist zwischen zwei benachbarten Knoten immer eine Kante eingezeichnet, welche deren hierarchische Relation spezifi- 42 Detailliertere Information zur Abbildung von Hierarchien folgen in Kapitel 5.4 auf Seite Synonyme aus der Fachliteratur: Vater, Vorfahre, Vorgänger, sowie in engl.: Parent, Ancestor 44 Synonyme aus der Fachliteratur: Sohn, Nachkomme, Nachfolger, sowie in engl.: Child, Descendant 45 Synonym auch: Entity-Relationship-Diagramm 46 In [EADES UND FENG 1996, S. 101] wird für Graphen mit rekursiver, hierarchischer Struktur auch der Begriff Clustered Graph eingeführt. 100

130 5 Graphische Darstellung von Traceability-Modellen ziert. Bei den Space-filling-Methoden, die auch implizit genannt werden, gibt es unterschiedliche Formen, die Knoten zu repräsentieren wie bspw. Linien, Rechtecke, Zylinder oder Kreissegmente. Die hierarchische Relation der Elemente wird dabei über die geometrische Ausrichtung oder Verschachtelung der Elemente zueinander ausgedrückt (bspw. durch Einschluss oder Überschneidung). [SCHULZ UND SCHUMANN 2006, S. 167] Für Graphen, die sowohl hierarchische als auch generische Relationen, also beispielsweise Artefakt-interne Relationen beinhalten, wurde in [LANDESBERGER ET AL. 2010] der Begriff Compound Graph (siehe Abbildung 44, Tracelinks in rot) eingeführt, wobei eingeräumt wird, dass diese in der Forschung bisher nicht ausführlich untersucht wurden. Abbildung 44: Darstellung eines Space-filling- (links), eines Node-Link-Diagramms (mitte) und eines Compound Graphen (rechts) Die wahrscheinlich bekannteste Ausprägung einer Space-filling Methode ist die Treemap. Dabei werden rechteckige Formen entsprechend ihrer hierarchischen Relation ineinander geschachtelt [LANDESBERGER ET AL. 2010]. Das Wurzelelement definiert also die äußeren Abmessungen und wird im Fall von bspw. drei Elementen zweiter Ebene in drei Segmente aufgeteilt, deren Flächen wiederum durch die jeweils eigenen Kindelemente segmentiert werden usw 47. Laut [LANDESBERGER ET AL. 2010] liegt der größte Vorteil der Treemaps in der guten Ausnutzung der Bildschirmfläche, während der größte Nachteil in der aufwändig zu lesenden Hierarchie liegt. Außerdem ist das Beschriften einzelner Knoten häufig nicht möglich. Der wesentlichste Kritikpunkt ist jedoch deren schlechte Lesbarkeit [STASKO ET AL. 2000, S. 689; BARLOW UND NEVILLE 2001, S. 134], weshalb sie im Rahmen dieser Arbeit nicht weiter in Betracht gezogen werden. Weitere prominente Vertreter hierarchischer Graphen werden u. a. in [STASKO ET AL. 2000, S. 664; SCHULZ UND SCHUMANN 2006, S. 167] und [LANDESBERGER ET AL. 2010] aufgelistet Der zugrundeliegende sog. Slice-and-Dice-Algorithmus wurde in [JOHNSON UND SHNEIDERMAN 1991] erstmalig vorgestellt. 48 Unter den Node-Link-Diagrammen zählen dazu u. a. das VGC-Layout, der Windows Explorer, hyperbolische Bäume, Edge Bundling, 3D Kegelbäume oder MagicEye View (eine 3D-Erweiterung der hyperbolischen Bäume). Zu den Space-filling-Layouts zählen neben den Treemaps u. a. Sunburst, Icicle Plot und Beamtree Layouts. 101

131 5 Graphische Darstellung von Traceability-Modellen Innerhalb der hierarchischen Graphen gibt es weitere Klassifizierungen. Werden die Kindelemente auf einer konzentrischen Kreisbahn verteilt um das Elternelement angeordnet, spricht man von radialen Layouts. Anordnungen, bei denen Elemente gleicher hierarchischer Ebene entlang einer gemeinsamen Linie angeordnet sind, heißen hingegen Achsenorientiert. [SCHULZ UND SCHUMANN 2006, S. 167; LANDESBERGER ET AL. 2010] Für die Gruppe der Node-Link-Diagramme werden in [LANDESBERGER ET AL. 2010] zusätzlich noch weitere Unterklassen vorgeschlagen: Constraint-based Layouts heißen alle Anordnungskonzepte, bei denen die Positionierung der Knoten durch vordefinierte Regeln bestimmt ist. Dazu gehören u. a. das horizontale oder vertikale Ausrichten von Knoten; Mechanismen zur Verhinderung von Knotenüberlappungen 49 oder zum gezielten Ausrichten der Kanten. Ein Sonderfall der Constraint-based Layouts sind die Layered Layouts, bei denen die Knoten gleicher hierarchischer Ebene auf einer gemeinsamen horizontalen Linie positioniert werden. Layered Layouts sind somit auch immer Achsen-orientiert. Bei Multi-scale Ansätzen wird zunächst lediglich ein Teil des kompletten Graphen angezeigt, wobei die feingranulareren Strukturen bei Bedarf ebenenweise eingeblendet werden können. Ziel der weiteren Ausführungen ist es, auf Basis dieser theoretischen Grundlagen ein Visualisierungskonzept für Traceability-Daten zu entwickeln. Dabei werden die unterschiedlichen beschriebenen Möglichkeiten der Visualisierung für hierarchische Graphen vergleichend analysiert. Zudem muss den spezifischen Anforderungen, die sich aus dem Kontext der Entwicklung mechatronischer Produkte ergeben, Rechnung getragen werden. Eine Herleitung dieser Anforderungen erfolgt im folgenden Kapitel ANFORDERUNGEN AN DIE TRACEABILITY-VISUALISIERUNG AUS SICHT DER PRODUKTENTWICKLUNG Aus Kapitel 2 sind verschiedene Facetten der Vorgehensweisen beim Entwickeln mechatronischer Produkte bekannt. Möchte man diese durch das Visualisieren von Traceability-Daten unterstützen, muss herausgearbeitet werden, welche Besonderheiten sich aus diesem Kontext ergeben. Im Rahmen der Produktentwicklung wird eine Vielzahl unterschiedlicher Artefakte erstellt. Dabei ist die Anzahl und der Typus der Artefakte nicht immer gleich, sondern kann in Abhängigkeit des Unternehmens variieren. Daher wird die Forderung von [SCHWARZ ET AL. 2010, S. 474] unterstützt, wonach das Visualisierungskonzept nicht auf spezifische Artefakttypen zugeschnitten, sondern auf unterschiedliche Arten von Artefakten übertragbar sein soll. Relevant für die Visualisierung ist zudem die große Menge an Daten, deren Integration sowie die visuelle Unterscheidung der Artefakte [PAVLOPOULOS ET AL. 2008, S. 6]. 49 Fachbegriff: Okklusion 102

132 5 Graphische Darstellung von Traceability-Modellen Häufig handelt es sich bei den Artefakten um komplexe und hierarchische Datensätze (siehe Kapitel 2.2). Laut [HO UND LI 1997, S. 587] haben bspw. die meisten Produktstrukturen mindestens fünf Hierarchielevel. Daher muss auch die hierarchische Struktur der einzelnen Artefakte im Graphen repräsentiert sein [CHEN 2010, S. 508], da dadurch deren Verständnis erheblich erleichtert wird [STASKO ET AL. 2000, S. 686]. Konkret bedeutet das, Nutzer müssen dazu in die Lage versetzt werden, Eltern-Kind- und Geschwister-Relationen sofort zu erkennen [BARLOW UND NEVILLE 2001, S. 132]. In [MARCUS ET AL. 2005, S. 58] wird daher empfohlen, das Visualisierungslayout an den Artefakten auszurichten und nicht, wie etwa bei Forcedirected Ansätzen, an den Tracelinks. Ferner besteht die Notwendigkeit, dass bei der Visualisierung komplexer Datensätze eine Selektion und Reduzierung der angezeigten Daten durch den Nutzer möglich sein muss. In Kapitel wurde erläutert, dass Elternelemente die Eigenschaften ihrer Kindelemente repräsentieren, was mit dem Begriff hierarchische Transitivität bezeichnet wird. Auch für die graphische Abbildung der Tracelinks zwischen den Elementen der Artefakte ist diese Eigenschaft von großem Vorteil. Sie unterstützt den generellen Anspruch an die Darstellung, so wenig redundante Informationen wie möglich anzuzeigen. Wenn ein Nutzer also die unteren Hierarchieebenen eines Artefakts nicht angezeigt bekommen möchte, was aus Gründen der Informationseffizienz ein plausibles Szenario ist, müssen die angezeigten Elternelemente die Abhängigkeiten der nicht-sichtbaren Kindelemente widerspiegeln. Es muss demnach berücksichtigt werden, dass Nutzer während der Nutzung des Visualisierungswerkzeugs einzelne Hierarchieebenen des betrachteten Artefakts nach Bedarf dynamisch auf- und zuklappen können. Daher ist eine statische Zuweisung der Tracelinks zu einzelnen Elementen nicht erstrebenswert. Vielmehr ist eine Lösung zu bevorzugen, bei der die Tracelinks von der jeweils detailliertesten eingeblendeten Hierarchieebene repräsentiert werden. Eine redundante Abbildung von Tracelinks durch hierarchisch übergeordnete Elemente, welche die jeweilige Eigenschaft stellvertretend repräsentieren, ist zu vermeiden. Andererseits muss gewährleistet sein, dass in Situationen, in denen nur höhere Hierarchieebenen sichtbar sind, diese die Tracelinks ihrer nicht-sichtbaren Kindelemente auch visuell durch dargestellte Tracelinks repräsentieren. Das Visualisierungswerkzeug muss also die hierarchische Transitivität der Artefakte berücksichtigen. In Kapitel wurde zudem darauf aufmerksam gemacht, dass die selektierten Daten im Kontext dargestellt bleiben müssen, um die Verständlichkeit des Graphen nicht zu mindern. Ferner sind insbesondere bei großen Datenmengen die Interaktionsmöglichkeiten mit den Datensätzen relevant [SCHULZ UND SCHUMANN 2006, S. 166] und daher auf die Besonderheiten der Produktentwicklung abzustimmen. Die konkrete Ausprägung des Interaktionskonzeptes erfolgt in Kapitel 5.6. Eine wesentliche Besonderheit ergibt sich ferner aus der Notwendigkeit, die Abhängigkeiten zwischen mehreren hierarchischen, ggf. Disziplin-spezifischen Artefakten abzubilden 50. Es 50 siehe dazu auch detaillierte Ausführungen auf Seite

133 5 Graphische Darstellung von Traceability-Modellen müssen also zeitgleich hierarchische, Artefakt-interne und Artefakt-übergreifende Relationen visuell abgebildet werden. Im Folgenden sind die wesentlichen Anforderungen an das Visualisierungskonzept, die sich aus dem Kontext der Produktentwicklung ergeben, zusammenfassend aufgelistet. Anforderungen aus der Produktentwicklung an das Visualisierungskonzept Hierarchische, Artefakt-interne und Artefakt-übergreifende Relationen zeitgleich abbilden Flexible Artefaktanzahl zulassen Flexible Artefakttypen zulassen Einzelne Artefakte müssen hierarchisch abbildbar sein Hierarchische Transitivität der Artefakte berücksichtigen Selektion und Reduzierung angezeigter Daten zulassen Elemente stets im hierarchischen Kontext darstellen Interaktionsmöglichkeiten vorsehen Alle genannten Anforderungen sollen helfen, die Kernforderung, die in [PINHEIRO 2003] kurz und prägnant zusammengefasst ist, zu befriedigen. Diese lautet sinngemäß: Möchte man erreichen, dass die Visualisierung der Traceability-Modelle genutzt wird, muss diese darauf ausgerichtet sein, die Entwickler tatsächlich zu unterstützen [PINHEIRO 2003] HERAUSFORDERUNGEN BEI DER GRAPHISCHEN ABBILDUNG VON TRACEABILITY-MODELLEN STAND DER WISSENSCHAFT UND TECHNIK Trotz der großen Potentiale, die sich aus der eingängigen Visualisierung von Traceability- Informationen zur Abbildung von dokumentiertem Systemwissen ergeben, bieten kommerzielle Werkzeuge diese Funktionalität kaum an [WINKLER UND PILGRIM 2010, S. 558]. Eine Auswahl dieser existierenden Werkzeuge aus Forschung und Praxis, mit denen Traceability- Modelle abgebildet werden können, soll in Kapitel vorgestellt und diskutiert werden. In dem darauffolgenden Kapitel werden wissenschaftliche Studien zum Vergleich der etablierten Traceability-Repräsentationsformen Liste, (Abhängigkeits-)Matrix und Node-Link- Diagramm ausgewertet. In Kapitel werden abschließend die vorgestellten Informationen zusammenfassend diskutiert EXISTIERENDE WERKZEUGE ZUR VISUALISIERUNG VON TRACEABILITY- INFORMATIONEN In Kapitel wurde erläutert, dass die Ursprünge der Traceability im Anforderungsmanagement liegen. Daher haben auch Werkzeuge, deren primärer Zweck die Verwaltung von Anforderungen ist, zuerst Funktionalitäten zur Visualisierung von Anforderungen angeboten. Und auch die ISO/IEC TR 24766:2009 [International Organisation for Standardization 2009] empfiehlt in der Richtlinie zum Anforderungsmanagement, dass die Tracelinks in Anforde- 104

134 5 Graphische Darstellung von Traceability-Modellen rungsmanagement-werkzeugen graphisch visualisiert werden sollen. Die Traceability- Visualisierungsfunktionalitäten einiger Werkzeuge werden im Folgenden exemplarisch vorgestellt. IBM Rational DOORS [IBM Corp. 2012b; ABMA 2009; PLETTE 2009] Das Werkzeug Rational DOORS verfügt über eine Vielzahl an Möglichkeiten, Tracelinks zu visualisieren. Die elementarste Variante ist das Einblenden von Pfeilsymbolen für jeden Tracelink neben dem verknüpften Element in einer Listenansicht. Dies erfolgt in DOORS im sog. formal module, wobei maximal zwei Tracelinks pro Element angezeigt werden können. Die Pfeilsymbole geben die Richtung des Tracelinks an und stellen Hyperlinks zu den verknüpften Artefakten dar. In der Listenansicht können ebenfalls indirekte Tracelinks angezeigt werden. Abgebildet wird dabei jeweils der Bezeichner des verknüpften Elements ohne weitere hierarchische Kontextinformation (siehe Abbildung 45, links oben). Zusätzlich zu dem beschriebenen formal module verfügt das Werkzeug über zwei weitere Repräsentationsformen. Die grid view genannte Repräsentationsform stellt eine matrixbasierte Visualisierung dar. Die Zeilen und Spalten der Matrix geben jeweils die Elemente eines Artefaktes wieder. Die hierarchische Position der verknüpften Elemente innerhalb eines Artefakts kann dabei, ebenso wie im formal module, ausschließlich der dem Bezeichner vorangestellten Nummerierung entnommen werden. Besteht zwischen zwei Elementen ein Tracelink, werden die beiden Bezeichner, die entsprechende Zeile und Spalte und die kreuzende Zelle hervorgehoben (siehe Abbildung 45, rechts oben). Filter, die im formal module gesetzt werden können, werden für die grid view übernommen. Das kann in der grid view jedoch zu einer Situation führen, dass Elemente unterer Ebenen herausgefiltert sind und deren Tracelinks, durch die Nicht-Berücksichtigung der hierarchischen Transitivität in DOORS, von den sichtbaren Elternelementen nicht repräsentiert werden [ABMA 2009]. Die dritte angebotene Repräsentationsform wird graph mode genannt. Dabei können die Tracelinks zwischen jeweils zwei Artefakten dargestellt werden. Die beiden Artefakte werden als Wurzelbäume dargestellt, wobei Elemente gleicher hierarchischer Ebene auf einer vertikalen Linie angeordnet sind (vertikales Constraint-based Layout). Der Wurzelknoten des Quellartefakts ist dabei am linken, der Wurzelknoten des Zielartefaktes am rechten Rand der Anordnung platziert. Zwischen beiden Artefakten sind die Tracelinks als orthogonale Kanten gezeichnet (siehe Abbildung 45, unten). Alternativ kann auch der sog. Traceability Explorer genutzt werden, welcher ein zu änderndes Element und alle direkt verknüpften Elemente in einem Node-Link-Diagramm anzeigt. Ein erhebliches Defizit dieser Visualisierungswerkzeuge sind die stark begrenzten Interaktionsmöglichkeiten, die im Wesentlichen auf ein farbliches Hervorheben ausgewählter Elemente und ein Verschieben des gesamten Graphen beschränkt sind. Damit sind Elementbezeichner bereits ab einer vergleichsweise geringen Anzahl von Elementen in einem Artefakt nicht mehr lesbar, was ein häufiges Umschalten in die grid view erzwingt. 105

135 5 Graphische Darstellung von Traceability-Modellen Abbildung 45: Traceability-Visualisierungsmöglichkeiten in DOORS Zusätzlich zu den DOORS-eigenen Visualisierungswerkzeugen gibt es das kostenpflichtige Add-On TraceLine. TraceLine verfügt über eine Browser-basierte graphische Oberfläche zur Visualisierung der Traceability-Informationen. Es kann eine beliebige Anzahl von DOORSnativen Artefakten in einem Node-Link-Diagramm dargestellt werden. Jedes Artefakt wird in einer separaten Spalte dargestellt. Die Elemente sind dabei nicht ihrem hierarchischen Level entsprechend angeordnet, sondern werden in Form einer flachen Liste abgebildet (siehe Abbildung 46). Der hierarchische Kontext der einzelnen Elemente ist somit nicht direkt sichtbar. TraceLine verfügt über eine große Anzahl an Interaktionsmöglichkeiten, wodurch auch vergleichsweise große Datenmengen gehandhabt werden können. Zusätzlich können die erstellten Sichten auch in HTML sowie nach MS Visio und Mindjet MindManager exportiert werden. [integrate systems engineering ltd. 2013] 106

136 5 Graphische Darstellung von Traceability-Modellen Abbildung 46: Visualisierung verknüpfter Elemente in TraceLine, wobei diese spaltenweise nach Artefakten sortiert sind Reqtify [Geensoft 2010a, 2010b; POHL UND SCHEEL 2004] Bei der Software Reqtify ist zu berücksichtigen, dass sie unlängst von Dassault Systèmes übernommen wurde. Alle hier getroffenen Aussagen beziehen sich auf den ursprünglichen Funktionsumfang, wie sie u. a. vom ehemaligen Anbieter Geensoft publiziert wurden, da derzeit keine konkreten Aussagen über die zukünftigen Funktionalitäten sowie ggf. die Integration in die V6-Suite von Dassault Systèmes bekannt sind. Hinsichtlich der Visualisierung von Tracelinks sind unterschiedliche Funktionalitäten zu nennen. Eine Besonderheit stellt die Möglichkeit zur Modellierung der Abhängigkeiten zwischen den zu verknüpfenden Artefakten dar. Dies erfolgt mit dem sog. Konfigurations-Editor, bei dem die zu betrachtenden Artefakte durch den Nutzer in die gewünschte Beziehung gesetzt werden können. Dazu werden die Artefakte als Knoten angezeigt und der Nutzer kann die Kanten zwischen diesen modellieren, sodass als Modellierungsergebnis ein Node-Link- Diagramm das Traceability-Schema des konkreten Projektes anzeigt. Das eigentliche Modellieren der Tracelinks auf Elementebene erfolgt in den Quelldokumenten mittels Verweisen. Für die Funktionalität steht somit die Repräsentationsform Liste mit Verweisen zur Verfügung. Für das Auswerten und Überwachen der modellierten Tracelinks wird zusätzlich ein Node- Link-Diagramm angeboten. Dabei werden alle Elemente eines Artefakts in einer vertikalen Liste aufgeführt. Die Artefaktlisten werden, entsprechend ihrer im Konfigurations-Editor spezifizierten Reihenfolge, sequentiell horizontal angeordnet. Bei dieser Funktionalität können Nutzer ein Element auswählen, woraufhin alle über Artefakt-übergreifende Tracelinks direkt und indirekt verknüpften Elemente entlang der Sequenz visuell hervorgehoben werden. Zusätzlich können Abhängigkeiten im Rahmen einer Reporting-Funktion ebenfalls in eine Abhängigkeitsmatrix überführt werden. 107

137 5 Graphische Darstellung von Traceability-Modellen Abbildung 47: Visualisierungsoptionen in Reqtify [ChiasTek Sales 2011] Die Visualisierungsoptionen sind in Reqtify vielfältig. Besonders die Funktionalität zur Modellierung des Traceability-Schemas mittels eines Node-Link-Diagramms ist eine Besonderheit. In Bezug auf das Layout des Graphen mittels der horizontal gestaffelten Listen ist positiv anzumerken, dass dadurch eine hohe Informationsdichte erreicht und eine flexible Anzahl an Artefakten abgebildet werden kann. Auch die Abbildung der hierarchischen Position eines Elements ist durch Einrückung innerhalb der Liste gegeben. Die Übersichtlichkeit dieser Anordnung geht jedoch verloren, sobald Artefakte nicht nur sequentiell in Beziehung stehen, sondern beispielsweise Kreisschlüsse bilden oder eine tiefe hierarchische Struktur aufweisen. Im letztgenannten Fall können zwischen zwei aufeinanderfolgenden Elementen mehrere Hierarchieebenen liegen, wodurch die hierarchische Position des unteren Elements nur schwer zu erkennen wäre. Ein erhebliches Manko ist jedoch die Nichtberücksichtigung der Visualisierung von Artefakt-internen Tracelinks. Hinsichtlich der Interaktionsmöglichkeiten ist anzumerken, dass das Fehlen von Skalierungsmechanismen für Projekte mit großen Datenmengen das Risiko einer Informationsüberfrachtung birgt. DEPNET [OUERTANI 2008; OUERTANI UND GZARA 2008] In [OUERTANI 2008; OUERTANI UND GZARA 2008] wird das Traceability-Visualisierungswerkzeug DEPNET vorgestellt. DEPNET erstellt auf Basis von Traceability-Daten ein Node- Link-Diagramm, bei dem Knoten die Elemente (hier Ressourcen, Aktivitäten, Anforderungen oder Bauteile) und Kanten die Abhängigkeiten zwischen diesen repräsentieren. Den Kanten können ferner Werte zugewiesen werden, die im Diagramm wiedergegeben werden (siehe Abbildung 48). Es werden keine Hierarchieinformationen abgebildet und Objekte aus unterschiedlichen Artefakten werden visuell nicht differenziert. 108

138 5 Graphische Darstellung von Traceability-Modellen Abbildung 48: Visualisierung mit DEPNET [OUERTANI UND GZARA 2008, S. 11] METUS [ID-Consult GmbH 2012] In der Software METUS von ID-Consult können die Abhängigkeiten zwischen den beiden hierarchischen Artefakten Funktionsstruktur und Produktstruktur, neben der Matrixansicht, in der diese modelliert werden, auch in einem Node-Link-Diagramm abgebildet werden. Das Visualisierungsschema sieht dabei vor, dass sich der Wurzelbaum der Funktionsstruktur von links nach rechts aufbaut, während der Produktstrukturbaum von rechts nach links detailliert wird. Beide Artefakte können jeweils mehrere Hierarchieebenen haben, wobei alle Elemente einer Ebene entlang einer gemeinsamen vertikalen Linie positioniert werden. Abbildung 49: Abbildung der Tracelinks mittels Node-Link-Diagramm in METUS [ID-Consult GmbH 2012] 109

139 5 Graphische Darstellung von Traceability-Modellen Die jeweils detailliertesten Ebenen stehen sich direkt gegenüber (siehe die beiden mittleren Spalten in Abbildung 49). Zwischen diesen beiden Detailebenen werden die Tracelinks zwischen Funktionen (linker Baum) und Produktstruktur (rechter Baum) eingezeichnet. Die Gewichtung der Tracelinks wird über deren unterschiedliche Grauwerte abgebildet. Das Visualisierungsschema der Software ist sehr starr. Eine Abbildung einer unterschiedlichen Anzahl von Artefakten ist nicht möglich. Gleiches gilt für die Abbildung von Artefaktinternen Tracelinks sowie Tracelinks zu Elementen höherer hierarchischer Ebenen. LOOMEO [MAURER 2006; TESEON GmbH 2012] Die Software LOOMEO der TESEON GmbH bietet unterschiedliche Repräsentationsformen für Traceability-Modelle an. Da die Tracelinks zunächst in Abhängigkeitsmatrizen modelliert werden, stellen diese die erste Repräsentationsform dar. Dafür können DSM, DMM oder MDM verwendet werden. Eine Alternative ist die Visualisierung mittels Node-Link-Diagramm. Diese kann in einem Force-directed-Layout ausgeprägt werden, wodurch u. a. die optional mögliche Wichtung der Tracelinks repräsentiert werden kann. Zusätzlich werden Interaktionsmöglichkeiten wie das Reduzieren eines Graphen auf die direkt benachbarten Knoten eines auswählbaren Elementes angeboten. In dieser reduzierten Ansicht ist es außerdem möglich, die Auswahl an Knoten in ihrer hierarchischen Struktur anzusehen. Abbildung 50: Visualisierung der Traceability-Informationen in LOOMEO in den Repräsentationsformen Matrix (links) und Node-Link-Diagramm (rechts) LOOMEO bietet zudem eine Anzahl von Interaktionsmöglichkeiten für die Node-Link-Ansicht an. Dennoch weist das Node-Link-Visualisierungskonzept Defizite auf. Hierarchische Strukturen können nur in einer Filteransicht für reduzierte Graphen abgebildet werden. Bei einer großen Anzahl von Elementen aus mehreren Artefakten ist der Graph nur sehr schwer lesbar, da es auch zu Überlagerungen der Knoten kommen kann (siehe Abbildung 50). Eine Erweiterung der Visualisierungsoptionen für LOOMEO wird in [DIEHL ET AL. 2008] und [DIEHL 2009] beschrieben. Darin wird eine sog. 3D-MECHGRAPH vorgestellt. Es werden ver- 110

140 5 Graphische Darstellung von Traceability-Modellen tikal verlaufende Tracelinks zwischen drei Artefakten visualisiert, die jeweils auf einer horizontalen, halbtransparenten Ebene platziert und im Force-directed-Layout angeordnet sind. IBM Rational RequisitePro [IBM Corp. 2011, 2012a] In Rational RequisitePro von IBM können Traceability-Informationen auf zwei Arten visualisiert werden. Die erste Möglichkeit besteht in einer Matrix ( Traceability Matrix view ), wobei deren Spalten und Zeilen entweder dasselbe Artefakt oder zwei verschiedene Artefakte widerspiegeln können. Über Pfeile in den Matrixzellen wird die Richtung des Tracelinks abgebildet. Indirekte Verknüpfungen zwischen den beiden Artefakten werden über halbtransparente Pfeile ausgedrückt (siehe Abbildung 51). Abbildung 51: Visualisierung der Tracelinks in der Traceability Matrix view von Rational RequisitePro [IBM Corp. 2012a] Die zweite Möglichkeit ist eine hierarchische Liste ( Traceability Tree view ), wobei den einzelnen Elementen ausschließlich direkt verknüpfte Elemente aus allen verfügbaren Artefakten in beliebiger Anzahl zugeordnet sind. Beide Repräsentationsformen weisen jedoch Defizite auf. In der Matrixansicht können nur entweder Artefakt-interne Tracelinks für ein Artefakt oder Artefakt-übergreifende Tracelinks für zwei unterschiedliche Artefakte visualisiert werden. In der Listenansicht kann hingegen der hierarchische Kontext der verknüpften Elemente nicht angezeigt werden. Teamcenter 9.1 [Siemens PLM Software Inc. 2012] In der Traceability view von Teamcenter kann ein Objekt aus einer hierarchischen Listenstruktur ausgewählt werden. Ist diese Auswahl abgeschlossen, werden in der sog. complying object pane (siehe linke Seite der Abbildung 52), die Bezeichner und Objekttypen aller verknüpften Objekte im hierarchischen Kontext listenartig ausgegeben. Eine Alternative 111

141 5 Graphische Darstellung von Traceability-Modellen zur Repräsentation der Tracelinks bietet die Traceability Matrix (siehe rechte Seite der Abbildung 52), in welcher die Artefakt-internen Tracelinks zwischen Anforderungen dargestellt werden können. Neben der Beschränkung auf Artefakt-interne Tracelinks ist die begrenzte Eignung zur Visualisierung des hierarchischen Kontexts (insbesondere in der Kopfzeile) das größte Defizit der Matrixansicht. Abbildung 52: Traceability-Visualisierung in Teamcenter 9.1 mittels Liste (links) und Traceability-Matrix [Siemens PLM Software Inc. 2012] V6 R2011x [Dassault Systèmes 2011, 2012a, 2012b] Beim sog. RFLP -Ansatz der V6-Suite von Dassault Systèmes werden die Tracelinks je nach Artefakt unterschiedlich visualisiert. Die Abhängigkeiten zwischen Funktionen und innerhalb der Verhaltensmodelle werden durch Kanten eines Node-Link-Diagramms repräsentiert (siehe Abbildung 53, rechts oben). Besteht ein Tracelink zu einer Anforderung, wird dies durch ein standardisiertes Symbol neben dem Elementbild angezeigt (siehe Abbildung 53, rechts unten). Artefakt-übergreifende Tracelinks können zudem im Struktur-Baum in, jeweils nach Tracelink-Typen geordneten, Unterordnern visualisiert (siehe Abbildung 53, links) oder für auswählbare Artefaktpaare listenartig über einen sog. Traceability Report ausgegeben werden. Alternativ können für ein selektiertes Element aus einem der beiden Artefakte Anforderungen und Funktionen die jeweiligen Artefakt-internen und -übergreifenden Tracelinks auch in einem Node-Link-Diagramm abgebildet werden (Näheres siehe Kapitel 7.1). Durch das starre Traceability-Schema von V6 ist die Anzahl der verknüpfbaren und visualisierbaren Artefakte vordefiniert. Eine weiterführende Komplettansicht, in der sowohl Artefakt-interne und -übergreifende Tracelinks zwischen beliebigen Artefakten abgebildet wären, ist in V6 nicht implementiert. 112

142 5 Graphische Darstellung von Traceability-Modellen Abbildung 53: Traceability-Visualisierung in V6 als Kante im Node-Link-Diagramm (oben rechts), Symbol (unten rechts) und Liste im Produktstruktur-Baum (links) Graphische Modellierungswerkzeuge für die Systementwicklung Auch bei Werkzeugen, bei denen eine vordefinierte Menge an graphischen Bausteinen, die z. B. Diagramme aus standardisierten Modellierungssprachen repräsentieren, eine grafische Entwicklungsumgebung für Systemingenieure anbieten 51, können zwischen diesen Bausteinen Abhängigkeiten definiert werden. Je nach implementierter Modellierungskonvention können dies hierarchische, Artefakt-interne oder -übergreifende Relationen sein. Üblicherweise wird mit dem Modellierungswerkzeug ein Node-Link-Diagramm generiert, bei dem die genannten vordefinierten Bausteine (also die Elemente) als rechteckige Knoten und die Zusammenhänge zwischen diesen (also die Relationen) als zumeist gerade und rechtwinklig verlaufende Kanten abgebildet werden. [Sparx Systems Pty Ltd. 2011; StarUML 2012; IBM Corp. 2012c; microtool GmbH 2012] Der Anwendungszweck dieser Lösungen liegt jedoch nicht in der Visualisierung von bestehenden Traceability-Informationen, sondern vielmehr in der Bereitstellung einer graphischen Schnittstelle zur originären Systemmodellierung. Das zugrundeliegende Visualisierungskonzept wurde daher auch nicht auf die Anforderungen der Traceability-Visualisierung zugeschnitten. 51 Beispiele für solche graphischen Modellierungswerkzeuge sind u. a. Enterprise Architect von Sparx Systems', StarUML, Rational Rhapsody von IBM, objectif von microtool etc. 113

143 5 Graphische Darstellung von Traceability-Modellen Übersicht der Werkzeuge zur Visualisierung von Traceability-Informationen Die folgende Tabelle 3 gibt eine Übersicht über die detailliert vorgestellten sowie weitere Werkzeuge zur Visualisierung von Traceability-Informationen und ordnet deren jeweils angebotene Repräsentationsform tabellarisch zu. Werkzeugname Matrix Node-Link Liste IBM Rational DOORS [IBM Corp. 2012b; ABMA 2009; PLETTE 2009] Reqtify [Geensoft 2010a, 2010b; POHL UND SCHEEL 2004] DEPNET [OUERTANI 2008; OUERTANI UND GZARA 2008] METUS [ID-Consult GmbH 2012] LOOMEO [MAURER 2006; TESEON GmbH 2012] (Force-directed) - IBM Rational RequisitePro [IBM Corp. 2011, 2012a] Teamcenter 9.1 [Siemens PLM Software Inc. 2012] V6 R2011x [Dassault Systèmes 2011, 2012a, 2012b] Cambridge Advanced Modeller [WYNN ET AL. 2010a; Cambridge EDC 2012] (Force-directed) - ASK-Graphview [ABELLO ET AL. 2006] Hierarchical Edge Bundles [HOLTEN 2006; HOLTEN ET AL. 2007] ZAME [ELMQVIST ET AL. 2008] TraceViz [MARCUS ET AL. 2005] Tabelle 3: Werkzeuge zur Traceability-Visualisierung und deren Repräsentationsformen In [AHMAD ET AL. 2012] wird ebenfalls ein Werkzeug vorgestellt, bei dem mehrere Artefakte in einem Force-directed-Graphen integriert dargestellt werden können. Bei der Anwendung des Werkzeugs im Rahmen einer Studie wurde beobachtet, dass die Nutzer aufgrund der gerin- 114

144 DOORS Reqtify METUS LOOMEO RequisitePro Teamcenter V6 5 Graphische Darstellung von Traceability-Modellen gen Übersichtlichkeit der Daten sehr häufig zwischen den Filteransichten einzelner Artefakte hin und her wechseln mussten. Diese Beobachtung untermauert, dass im Force-directed-Layout sowohl die Abgrenzung zwischen den Artefakten als auch deren interne Struktur schwer lesbar sind. Die These wird auch von ABELLO ET AL. gestützt, welche die Nutzung von Algorithmen wie Force-directed generell für Baumstrukturen als wenig sinnvoll einschätzen [ABELLO ET AL. 2006, S. 673]. Ein Grund für die mangelnde Eignung des Force-directed-Layouts ist u. a. die Vernachlässigung von Kantenüberschneidungsproblemen [DUNNE UND SHNEIDERMAN 2009, S. 3]. Die vorgestellten Lösungen zur Visualisierung von Traceability-Informationen decken ein breites Spektrum an Funktionalitäten ab. Viele Visualisierungslösungen beachten dabei jedoch die Grundregeln der Informationsvisualisierung nicht hinreichend. Zudem wird keine der Lösungen allen in Kapitel formulierten Anforderungen gerecht (siehe Tabelle 4, wobei folgende Legende gilt:..anforderung erfüllt ( )..Anforderung mit Einschränkungen erfüllt ( - )..Anforderung kaum erfüllt -..Anforderung nicht erfüllt). Werkzeugname Anforderungen aus der Produktentwicklung Hierarchische, Artefakt-interne und Artefaktübergreifende Relationen zeitgleich abbilden ( ) - - ( - ) ( - ) ( - ) ( - ) Flexible Artefaktanzahl zulassen - ( ) ( ) ( ) ( - ) Flexible Artefakttypen zulassen ( ) - Einzelne Artefakte müssen hierarchisch abbildbar sein Hierarchische Transitivität der Artefakte berücksichtigen Selektion und Reduzierung angezeigter Daten zulassen Elemente stets im hierarchischen Kontext darstellen ( ) ( ) ( ) - ( ) ( ) ( ) ( ) ( - ) ( ) ( ) Interaktionsmöglichkeiten vorsehen ( - ) ( - ) ( - ) ( - ) ( - ) ( ) Tabelle 4: Erfüllungsgrad der Anforderungen für die vorgestellten Visualisierungsfunktionen Ein häufig auftretendes Defizit wird auch in [CHEN 2010] genannt, wonach die meisten Werkzeuge lediglich die Visualisierung von zwei Artefakten zulassen. Das ist u. a. deswegen problematisch, weil häufig Informationen aus einer Vielzahl unterschiedlicher Artefakte aggregiert werden müssen, um deren Kontext nachvollziehen zu können [ŠTORGA ET AL. 2010]. 115

145 5 Graphische Darstellung von Traceability-Modellen Dieses Defizit der geringen Flexibilität hinsichtlich der darzustellenden Anzahl an Artefakten ist auch den gängigen Visualisierungen mittels Abhängigkeitsmatrizen immanent. So ist es zwar mittels MDM generell möglich, eine beliebige Anzahl von Artefakten auch in Matrixform zu visualisieren, deren Lesbarkeit nimmt jedoch mit wachsender Größe und damit auch Artefaktanzahl stark ab. [JARRATT ET AL. 2004, S. 10; ALMEFELT ET AL. 2006, S. 129; WINKLER 2008, S. 59] Eine in [MARCUS ET AL. 2005] vorgestellte Analyse existierender Traceability- Visualisierungskonzepte kommt zu dem Schluss, dass häufig nicht die eigentliche Aufgabe dieser Werkzeuge, nämlich das Unterstützen von Systemverständnis, bei deren Implementierung im Fokus stand. Deswegen sind die visualisierten Informationen meist nicht leicht zu lesen. Viele Lösungen ignorieren zudem, dass die Daten auf Basis der Artefakte gruppiert werden sollten [MARCUS ET AL. 2005]. Die obige Analyse stützt diese These. Es ist daher nachvollziehbar, dass Entwickler in Entwicklungsprojekten, bei denen Traceability praktiziert wurde, zum Teil äußerst kritisches Feedback hinsichtlich der Visualisierung geäußert haben [GHONIEM ET AL. 2004; ALMEFELT ET AL. 2006, S. 122; KELLER ET AL. 2006, S. 66; WINKLER 2008, S. 59]. Eine vergleichende Studie der drei geschilderten Repräsentationsformen (Liste, Matrix und Node-Link-Diagramm) an einem konkreten ingenieurtechnischen Anwendungsfall, die im Verlauf dieser Arbeit in Kapitel 7.3 beschrieben wird, unterstützt diese Defizitanalyse. Im folgenden Kapitel werden drei existierende Studien zum Vergleich der Repräsentationsformen aus der Literatur vorgestellt und diskutiert. Ziel dieser Analyse ist es, eine geeignete Repräsentationsform für die Visualisierung von Traceability-Informationen zur Entwicklung mechatronischer Produkte auszuwählen ANALYSE VERGLEICHENDER STUDIEN DER REPRÄSENTATIONSFORMEN ZUR VISUALISIERUNG VON TRACEABILITY-INFORMATIONEN Jede der drei möglichen Repräsentationsformen, Liste, Matrix oder Node-Link-Diagramm, hat spezifische Vor- und Nachteile [AIZENBUD-RESHEF ET AL. 2006, S. 517; WINKLER 2008, S. 58], weswegen ihre Verwendung je nach Anwendungsfall mehr oder minder angezeigt sein kann. Ziel dieses Kapitels ist es, die für eine Verwendung im Rahmen der Produktentwicklung am besten geeignete Repräsentationsform auszuwählen. Dazu werden veröffentlichte Vergleichsstudien und Argumentationen zu den Charakteristika der Repräsentationsformen analysiert und im Hinblick auf den Anwendungsfall diskutiert, um anschließend eine belastbare Auswahl vornehmen zu können. In der Literatur sind unterschiedliche Präferenzen und Auffassungen zu den jeweiligen Repräsentationsformen dokumentiert. Häufig genannt ist dabei die Auffassung, dass strukturierte Informationen wie Traceability-Modelle nicht rein textuell ausgegeben, sondern graphisch im Sinne eines Node-Link-Diagramms wiedergegeben werden sollten [POHL 1996, S. 90; KEIM 2002, S. 103; SCHULZ UND SCHUMANN 2006, S. 166; SCHWARZ ET AL. 2010, S. 477]. 116

146 5 Graphische Darstellung von Traceability-Modellen WARE unterstützt diese Forderung, indem er darauf verweist, dass Verbundenheit ein sehr mächtiges Gruppierungsprinzip darstellt mächtiger als bspw. geometrische Nähe, Farbe, Größe oder Form [WARE 2004, S. 191]. Daher bieten sich die Kanten in einem Node-Link- Diagramm an, um den Zusammenhang zwischen Elementen zu versinnbildlichen. In [WINKLER UND PILGRIM 2010, S. 543] wird zudem angeführt, dass Node-Link-Diagramme auch durch ihre große Bekanntheit in der modellbasierten Entwicklung, durch ihre Flexibilität in der konkreten Ausprägung und durch die Möglichkeit, lokale und globale Informationen gleichzeitig zu transportieren, zur Visualisierung von Traceability-Informationen geeignet sind. Die große Freiheit beim Layout der Node-Link-Diagramme wird auch in [KELLER ET AL. 2006, S. 65] als wesentlicher Vorteil angeführt, weil es somit möglich ist, die Aufmerksamkeit des Nutzers auf spezielle Aspekte des Graphen zu lenken. Für die Repräsentationsform Liste wird in [JOHNSON UND SHNEIDERMAN 1991, S. 285] als Manko angeführt, dass nur wenige Knoten auf einmal abgebildet werden können und dass es für Nutzer schwierig ist, zwischen diesen eine kognitive Orientierung über die jeweilige hierarchische Struktur zu etablieren. Laut [WINKLER 2008, S. 59] ist zudem zu beachten, dass der Nutzer lediglich den lokalen Kontext eines Elements innerhalb des Artefakts sowie die entsprechend verknüpften Tracelinks zu sehen bekommt, was auf Kosten des Überblicks innerhalb des Artefakts geht. Dies widerspricht jedoch der Anforderung von [ŠTORGA ET AL. 2010], wonach sowohl Quell- als auch Zielelement im lokalen Kontext wiedergegeben werden müssen. Der große Vorteil der Repräsentationsform Matrix ist das Vermeiden von Überlappungen unabhängig von der Dichte der abzubildenden Verknüpfungen [LANDESBERGER ET AL. 2010]. Dennoch weisen auch Matrizen Defizite auf. So wird in [WINKLER 2008, S. 59] vor allem bemängelt, dass Matrizen zum einen bei Datenvolumina in realistischen Entwicklungsumfängen schlicht zu groß und damit unlesbar werden und zum anderen die räumliche Entfernung zwischen Element und Tracelink hinderlich ist. Dies wird durch die Beobachtungen in [HOLTEN 2006, S. 743] und [LANDESBERGER ET AL. 2010] gestützt, in denen Matrizen für die Abbildung von Abhängigkeiten als wenig intuitiv eingeschätzt werden, was den Nutzern das Nachverfolgen von Abhängigkeitspfaden erschwert. In [KELLER ET AL. 2006, S. 66] haben erfahrene Entwickler die Matrix-basierte Methode sogar als untauglich für Ingenieure bewertet. Diese Einschätzung wird auch in [ABELLO ET AL. 2006, S. 669] geteilt, wo angemahnt wird, dass Matrix-basierte Ansätze sehr abstrakt sind und Entwickler Schwierigkeiten haben, den Kontext zum Gesamtsystem herzustellen. [GHONIEM ET AL. 2004; HOLTEN 2006, S. 743] und [KELLER ET AL. 2006, S. 66] bewerten daher für Aufgaben, bei denen ein Abhängigkeitspfad über mehrere Elemente nachverfolgt werden muss, Node-Link-Diagramme als den Matrizen überlegen. Neben diesen abwägenden aber wenig methodischen Betrachtungen zur Eignung der jeweiligen Repräsentationsform auf Basis deren Stärken und Schwächen, sind wissenschaftliche Studien zu deren Vergleich zu konsultieren. Generell sind jedoch nur wenige wissenschaftliche Untersuchungen veröffentlicht, welche die benannten Repräsentationsformen für die Vi- 117

147 5 Graphische Darstellung von Traceability-Modellen sualisierung von Traceability-Informationen vergleichend untersuchen. Die drei wesentlichen Studien zu diesem Thema werden im Folgenden vorgestellt und diskutiert. GHONIEM ET AL. Die bekannteste Studie zum Vergleich der beiden Repräsentationsformen Matrix und Node- Link-Diagramm wurde von GHONIEM ET AL. veröffentlicht. Dazu mussten die Studienteilnehmer sieben generische Aufgaben (wie bspw. das Identifizieren benachbarter Knoten, das Zählen von Knoten oder das Zählen von Kanten) ausführen, die unterschiedliche Aspekte der Lesbarkeit einer Visualisierung adressieren. Lesbarkeit wird dabei so definiert, dass je schneller und korrekter eine Aufgabe mit einer Repräsentation erfüllt werden kann, desto lesbarer ist sie für den Nutzer. [GHONIEM ET AL. 2004] [GHONIEM ET AL. 2005] Die Aufgaben mussten mit zufällig erzeugten Abhängigkeitsmodellen, deren Elementbeschriftung 52 ausschließlich aus Ziffern bestand, also intentionell keine tiefere semantische Bedeutung hatte, ausgeführt werden. Dafür wurden neun verschiedene Modelle generiert: mit drei unterschiedlichen Elementanzahlen n (20, 50 und 100) und jeweils drei unterschiedlichen Dichten d (0,2, 0,4 und 0,6), die entsprechend Formel ( 2 ) berechnet wird ( 2 ) wobei die Anzahl der Verknüpfungen angibt. Alle sieben Aufgaben mussten von allen Studienteilnehmern für beide Repräsentationsformen ausgeführt werden. Durch die unterschiedliche Natur der gestellten Aufgaben und den generischen Charakter der Elementbezeichner (zufällige Nummerierung), der in der Praxis nicht vorkommt, sind die Ergebnisse differenziert zu interpretieren. Allgemeingültig ist jedoch die Erkenntnis, dass bei Artefakten mit geringer Elementanzahl Node-Link-Diagramme den Matrizen hinsichtlich der Lesbarkeit deutlich überlegen sind. Werden die Modelle größer und steigt deren Dichte, so ist die Lesbarkeit der Repräsentationsformen von der Art der gestellten Aufgabe abhängig. Für die Aufgabe Path_Finding, bei der zwischen zwei gegebenen Elementen der kürzeste Pfad gefunden werden muss, war die Node-Link-Darstellung geeigneter, während bei den anderen Aufgaben die Matrixdarstellung zu überzeugen wusste. Die Übertragbarkeit der Ergebnisse auf das Anwendungsgebiet der Traceability in der Produktentwicklung ist jedoch nur bedingt gegeben. So ist zu bedenken, dass von den sieben in der Studie gestellten Aufgaben, lediglich die Aufgaben Path_Finding (s.o.) und Find_Neighbour, bei der für zwei gegebene Elemente ein gemeinsamer Nachbar identifiziert werden muss, eine gewisse Relevanz im Umfeld des Systems Engineerings haben. Für Aufgaben, bei denen bspw. die Elemente gezählt werden mussten, ist das eher nicht zutreffend. Interessanterweise schneidet die Node-Link-Darstellung bei den beiden Aufgaben 52 Engl. Fachbegriff: Label 118

148 5 Graphische Darstellung von Traceability-Modellen Path_Finding und Find_Neighbour, wo man sich zu einem gewissen Grad inhaltlich mit den Graphen befassen musste, besser als bzw. gleich gut wie die Matrixdarstellung ab. Ein weiteres Defizit in Bezug auf die Aussagekraft im Kontext der Mechatronik stellt der gewählte Anordnungsalgorithmus dar, bei dem weder eine hierarchische Beziehung der Elemente untereinander noch die zeitgleiche Darstellung multipler Artefakte vorgesehen ist. Das wären jedoch Mindestvoraussetzungen für eine Anwendbarkeit im Systems Engineering. Zusätzlich muss kritisiert werden, dass kein Anordnungsalgorithmus genutzt wurde, welcher die Anzahl der Überschneidungen minimiert, was für die Lesbarkeit des Node-Link-Diagramms sicherlich förderlich gewesen wäre. Als wesentliche Erkenntnis aus dieser Studie bleiben demnach: für die betrachteten entwicklungsrelevanten Aufgaben ist die Repräsentationsform Node-Link-Diagramm der Matrixdarstellung mindestens ebenbürtig, an ein Interaktionskonzept für eine Node-Link-Darstellung muss die Anforderung formuliert werden, die Anzahl der angezeigten Knoten durch den Nutzer verringern zu können, um eine gute Lesbarkeit zu gewährleisten. KELLER ET AL. Das beschriebene Manko der mangelnden Übertragbarkeit einer solchen Studie auf die Produktentwicklung haben KELLER ET AL. zum Anlass genommen, eine Studie durchzuführen, die im Kontext von Produktmodellen die Lesbarkeit der beiden Repräsentationsformen Matrix und Node-Link-Diagramm untersucht. Dazu wurden ähnlich wie bei [GHONIEM ET AL. 2004] die Knotenanzahl (22, 50) der gerichteten Graphen variiert, wobei diese jeweils eine semantische Bedeutung aufwiesen. Jeder Studienteilnehmer musste sechs Aufgaben jeweils mit beiden Repräsentationsformen lösen. Die Lesbarkeit wurde auch hier über die Parameter Zeit und Fehlerrate bestimmt. [KELLER ET AL. 2006] Die Ergebnisse der Studie zeigen, dass die Faktoren Modellgröße, Aufgabentyp, Repräsentationsform und Vorwissen einen signifikanten Einfluss auf die Antwortzeit haben. Für die Fehlerrate hingegen konnte ein signifikanter Einfluss nur für die Faktoren Aufgabentyp und Repräsentationsform nachgewiesen werden. Da die gewählten Modelle im Vergleich zur Studie in [GHONIEM ET AL. 2004] eher klein waren, war für die Mehrzahl der Aufgaben die Node-Link-Darstellung besser lesbar. Besondere Vorteile gegenüber der Matrixdarstellung wurden auch bei dieser Studie für die Aufgabe Path_Finding, bei der zwischen zwei gegebenen Elementen der kürzeste Pfad gefunden werden muss, nachgewiesen. Bei den Untersuchungen in [KELLER ET AL. 2006] wurde ebenfalls darauf verzichtet, einerseits die Verknüpfungen zwischen mehr als einem Artefakt und andererseits deren hierarchische Struktur zu betrachten. Auch die Entscheidung, die Elemente innerhalb der Matrix alphabetisch zu sortieren, eine Eigenschaft, die innerhalb der Node-Link-Darstellung keine äquivalente Entsprechung finden konnte, erscheint aus Gründen der Vergleichbarkeit der Repräsentationsformen zweifelhaft. 119

149 5 Graphische Darstellung von Traceability-Modellen Allgemein zeigt diese Studie, dass: die Eignung der Repräsentationsform signifikant vom Modelltyp und der Aufgabenstellung abhängt, für Graphen mit einem zugrundeliegenden semantischen Kontext der Knoten, was im Anwendungsszenario der Produktentwicklung die Norm ist, Node-Link- Diagramme den Matrizen überlegen sind. LI UND MAALEJ In [LI UND MAALEJ 2012] wird die Eignung der Repräsentationsformen Matrix, Node-Link- Diagramm, Liste und Hyperlink 53 für vier spezifische Aufgabentypen untersucht. Bei den vier Aufgabentypen wurde zwischen Management-, Design-, Implementations- und Testaufgaben unterschieden. Die Studie wurde dadurch motiviert, dass vorangegangene Untersuchungen zu dem Ergebnis kamen, die Wahl der geeigneten Repräsentationsform ist abhängig von der durchzuführenden Aufgabe [GOTEL UND FINKELSTEIN 1994; GHONIEM ET AL. 2004; MARCUS ET AL. 2005; KELLER ET AL. 2006]. Das Ziel und damit die zentrale Forschungsfrage der vergleichenden Studie waren daher, zu bestimmen, welche Repräsentationsform im Kontext der vier Aufgabe jeweils am besten geeignet ist. Im Rahmen der Studie mussten zu diesem Zweck 24 Studienteilnehmer, gleich verteilt in eine Experimentier- und eine Kontrollgruppe, jeweils die vier genannten Aufgaben erfüllen. Dabei wurde der Experimentiergruppe die Repräsentationsform jeweils vorgegeben, während sich die Teilnehmer aus der Kontrollgruppe vor der Durchführung jeder Aufgabe für eine, aus ihrer Sicht am besten geeignete, Repräsentationsform entscheiden mussten. Während der Durchführung der Aufgaben wurde die notwendige Bearbeitungszeit gemessen, während im Anschluss die subjektive Einschätzung der Visualisierungseignung abgefragt wurde. Die Autoren räumen ein, dass die Forschungsfrage durch die vorgelegte Studie nicht in vollem Umfang eindeutig beantwortet werden konnte. Generell wurden alle Repräsentationsformen als verständlich wahrgenommen. Hinsichtlich der subjektiv empfundenen Eignung wurden die Matrix- und die Node-Link- signifikant besser bewertet als die Hyperlink- Repräsentation. Im Hinblick auf den Informationswert der Visualisierung wurden das Node- Link-Diagramm bei der Designaufgabe 54 und die Matrix bei der Managementaufgabe 55 am 53 Die Unterscheidung von Listen- und Hyperlink-Repräsentation ist in der Literatur nicht unumstritten. So wird argumentiert, dass es sich bei der Hyperlink-Repräsentation lediglich um eine Erweiterung einer Liste um den Interaktionsmechanismus Sprungfunktion handelt. Dieser Argumentation folgend wird auch im Rahmen dieser Arbeit die Hyperlink-Visualisierung nicht als eigenständige Repräsentationsform betrachtet. 54 Die Designaufgabe sah vor, dass Komponenten identifiziert werden mussten, die eine Anforderung erfüllen. Ferner sollte die Fortpflanzung einer Änderung bewertet werden. 120

150 5 Graphische Darstellung von Traceability-Modellen positivsten bewertet. Die uneinheitlichen Ergebnisse bei der Zeitmessung führen die Autoren auf subjektive Faktoren (hauptsächlich Vorwissen und Fähigkeiten) bei den Studienteilnehmern zurück. Der betrachtete Prozess und das genutzte Beispiel sind der Softwareentwicklung entlehnt. Die Übertragbarkeit auf die Produktentwicklung ist aufgrund der unterschiedlichen Natur der Artefakte zumindest fragwürdig. Des Weiteren ist in der Studie beschrieben, dass mehrere Artefakte in einer Dimension durchmischt wurden (so enthalten bspw. die Zeilen der Matrix undifferenziert die vier Artefakte work items, test cases, code und model ). Die Artefakte wurden somit visuell nicht differenziert und waren nicht hierarchisch strukturiert. Die Autoren räumen ebenfalls ein, dass ein Manko ihrer Untersuchung in dem geringen Umfang des betrachteten Beispiels liegt. Insgesamt liegen demnach einige Faktoren vor, welche die Gültigkeit und Übertragbarkeit dieser Studienergebnisse auf den in dieser Arbeit betrachteten Sachverhalt begrenzen. Relevant ist hingegen die Erkenntnis, dass die Nutzer-Akzeptanz stark vom Layout des Graphen abhängt. In diesem Zusammenhang wird konkret der wiederholte Wunsch der Studienteilnehmer nach einer geeigneten Darstellung der Artefakte und Relationen (z. B. in Form einer hierarchischen Top-Down-Struktur) genannt. Dies entspricht einer der in Kapitel formulierten Kernanforderungen an das zu entwickelnde Visualisierungskonzept ZUSAMMENFASSUNG UND DISKUSSION Die Ergebnisse der Stand-der-Technik-Analyse aus Kapitel verdeutlichen, dass es bereits eine Vielzahl existierender Visualisierungswerkzeuge gibt. Keines trägt jedoch den spezifischen Anforderungen der Produktentwicklung, die in Kapitel beschrieben wurden, Rechnung. Selbst bzgl. der Wahl der geeignetsten Repräsentationsform gibt es fundamental unterschiedliche Auffassungen. Tabelle 5 veranschaulicht, dass keine der in Kapitel vorgestellten Studien einen Graphen betrachtet, der den wesentlichen Anforderungen aus der Produktentwicklung genüge tut. Hierarchische Relationen werden sogar in keiner der Studien betrachtet. Berücksichtigt man ferner, dass alle Studien den Schluss nahe legen, die Eignung einer Repräsentationsform hänge vom Aufgabentyp ab, erscheint deren Auswahl nicht trivial. Daher empfiehlt es sich, auch dokumentierte Praxiserfahrungen mit Abhängigkeitsmatrizen zu berücksichtigen, die gezeigt haben, dass Anwender diese als sehr abstrakt [GHONIEM ET AL. 2005] und wenig intuitiv [HOLTEN 2006, S. 743; LANDESBERGER ET AL. 2010] empfinden bzw. deren Nutzung als für Entwickler wenig geeignet beschrieben haben [KELLER ET AL. 2006, S. 66]. Andererseits kommt es bei Node-Link-Diagrammen von dichten Graphen häufig zu Okklusionsproblemen, was deren Lesbarkeit einschränkt [GHONIEM ET AL. 2004]. 55 Die Managementaufgabe sah vor, dass der Fortschritt der Implementierung und des Testens überwacht werden sollten. Ferner mussten offene Aktivitäten geplant werden. 121

151 5 Graphische Darstellung von Traceability-Modellen Studie Mehrere Artefakte betrachtet? Hierarchische Relationen visualisiert? Semantik der Knotenlabel relevant? GHONIEM ET AL & KELLER ET AL LI UND MAALEJ 2012 ( 56 ) - Tabelle 5: Relevanz der Studien bzgl. der Anforderungen 57 aus der Produktentwicklung Dennoch belegen die vorgestellten Studien, auch wenn deren Validität für den Kontext der Entwicklung mechatronischer Produkte durch das Nicht-Berücksichtigen von hierarchischen Strukturen und multiplen Artefakten eingeschränkt werden muss, dass für entwicklungsrelevante Aufgaben Node-Link-Diagramme tendenziell besser als Matrizen abschneiden. Dies wird durch die Theorie gestützt, wonach kognitiv Knoten mit Elementen 58 und Kanten mit Relationen assoziiert werden [WARE 2004]. Daher können Node-Link-Diagramme als prädestiniert für die Traceability-Visualisierung angenommen werden. Somit erscheint für eine Visualisierung, die den in Kapitel formulierten Anforderungen Rechnung trägt, eine Node-Link-Repräsentation am ehesten geeignet. Damit ergibt sich für die Visualisierung von Artefakt-übergreifenden Traceability-Informationen die wissenschaftliche Herausforderung, ein adäquates Layout für eine Node-Link-Repräsentation samt entsprechendem Interaktionskonzept zu entwickeln, um die Abhängigkeiten zwischen einer beliebigen Anzahl an hierarchischen Artefakten eingängig darzustellen. Ziel des Visualisierungskonzeptes soll es sein, die gespeicherten Traceability-Informationen möglichst effizient erfassen zu können. Das dies notwendig ist, belegt die Analyse in [CHEN 2010, S. 505], wonach die ungenügende Art der Visualisierung von Traceability-Informationen einer der beiden Hauptgründe ist, warum Traceability in der Praxis so selten angewandt wird HYPOTHESE 1 ZUR VERBESSERTEN LESBARKEIT VON TRACEABILITY- MODELLEN IN NODE-LINK-DIAGRAMMEN Die Schlussfolgerungen aus der Stand-der-Technik-Analyse sowie insbesondere die Erkenntnisse aus dem Vergleich der Repräsentationsformen führen zu der Vermutung, dass die Art der Anordnung der Informationsobjekte innerhalb eines Node-Link-Diagramms einen wesentlichen Einfluss auf die Nutzbarkeit der Traceability-Visualisierung hat. Da als wesentliches Manko für die Lesbarkeit von Node-Link-Diagrammen die häufige Überschneidung von Visualisierungsobjekten genannt wird, ist ein Anordnungskonzept zu entwi- 56 Es werden zwar mehrere Artefakte betrachtet, diese jedoch nicht durchgängig visuell getrennt, sodass bspw. in der Matrix alle Artefakte in einer gemeinsamen Zeile bzw. Spalte aufgelistet sind. 57 Legende:..Anforderung erfüllt ( )..Anforderung mit Einschränkungen erfüllt -..Anforderung nicht erfüllt 58 Im Original: Entitäten 122

152 5 Graphische Darstellung von Traceability-Modellen ckeln, bei dem dieser Effekt durch räumliche Trennung der Artefakte reduziert wird. Dies soll zu einer verbesserten Lesbarkeit des visualisierten Graphen führen. Daher wird für die Forschungsfrage in diesem Kapitel folgende Hypothese formuliert: Ein Node-Link-Anordnungskonzept für Compound Graphen, bei dem die Überschneidung von Visualisierungsobjekten durch räumliche Trennung von Artefakten und Tracelinks reduziert wird, kann die Lesbarkeit des abgebildeten Traceability-Modells hinsichtlich Fehlerfreiheit und Geschwindigkeit signifikant verbessern. Es wird somit im weiteren Verlauf dieses Kapitels zunächst darum gehen, ein für die Traceability-Visualisierung geeignetes Node-Link-Anordnungskonzept zu entwickeln, bei dem die Überschneidung der Visualisierungsobjekte reduziert ist. Anschließend ist dessen Lesbarkeit hinsichtlich Fehlerfreiheit und Geschwindigkeit vergleichend zu evaluieren HERLEITUNG DES INTERAKTIVEN TRACEABILITY-VISUALISIERUNGSKONZEPTS ARIADNE S EYE Im folgenden Kapitel wird die Entwicklung des innovativen Visualisierungskonzepts Ariadne s Eye erläutert, das die Überschneidungen von Visualisierungsobjekten reduziert. Für den adressierten Anwendungsfall zielt das zu konzipierende Visualisierungskonzept im Kern auf die Unterstützung bei der Suche nach einem beliebigen, digitalen Entwicklungsobjekt und all seiner Verknüpfungen zu anderen Elementen. Die informationstechnologische Grundlage zum Identifizieren dieser Elemente stellen dabei Traceability-Informationen dar. Die Entwicklung erfolgt auf Basis der theoretischen Grundlagen, der Anforderungen aus der Mechatronik sowie der Erkenntnisse aus dem Vergleich der Repräsentationsformen, wie sie im bisherigen Kapitel 5 ausgeführt wurden. Der Anspruch an das Visualisierungskonzept Ariadne s Eye kann dabei mit den Gedanken von WARE zusammengefasst werden, wonach der Nutzer über seine Fragestellung nachdenken können soll, anstatt über die graphische Oberfläche nachdenken zu müssen, die ihm dazu zur Verfügung gestellt wird [WARE 2004]. Die Stand-der-Technik-Analyse in Kapitel ergab, dass Anwender bei einigen Node- Link-Anordnungen Schwierigkeiten hatten, Elemente problemlos ihren zugehörigen Artefakten zuzuordnen. [WARE 2004] und [STASKO ET AL. 2000, S. 684] empfehlen dazu, Informationen, die einer gemeinsamen Kategorie angehören, über eine einheitliche Farbgebung zu codieren. Die Kategorie im Kontext der Produktentwicklung entspricht der Zugehörigkeit von Elementen zu einem Artefakt. Eine zweite Option besteht darin, wie in Kapitel erläutert wurde, Artefakten eine feste topographische Struktur zuzuweisen. Dadurch kann der Nutzer aus der Position innerhalb der Struktur schließen, welchem Artefakt ein Element zugeordnet ist und Gruppierungen zwischen den Knoten erkennen [DUNNE UND SHNEIDERMAN 2009, S. 5]. Für die Realisierung im Visualisierungskonzept werden beide Optionen aufgegriffen. In [SCHULZ UND SCHUMANN 2006, S. 167] wird empfohlen, für Aufgaben, bei denen der Inhalt der Knoten im Vordergrund steht, explizite Layouts zu bevorzugen. Dabei müssen nach [JOHNSON UND SHNEIDERMAN 1991, S. 284], zusätzlich zu den hierarchischen Informationen, auch den einzelnen Knoten Informationen (sog. Labels) angeheftet werden. Dabei ist es 123

153 5 Graphische Darstellung von Traceability-Modellen wichtig, dass die Labels eindeutig und verständlich sind [DUNNE UND SHNEIDERMAN 2009, S. 4]. Im Kontext der Produktentwicklung entspricht dies den Elementbezeichnern. Daraus folgt für das Visualisierungskonzept, dass alle Elemente eines Artefakts mit denselben Farben codiert und, sofern das Artefakt hierarchisch aufgebaut ist, seine beschrifteten Knoten in einer festen expliziten Wurzelbaumstruktur angeordnet werden. Durch die Wurzelbaumstruktur sind alle Elemente in ihrem hierarchischen Kontext dargestellt, wobei Elemente gleicher hierarchischer Ebene auf einer gemeinsamen Linie angeordnet werden (siehe Abbildung 54). Diese Entscheidung für ein Constraint-based Layout genügt der Anforderung, die Hierarchie leicht interpretierbar zu gestalten. Laut [SCHULZ UND SCHUMANN 2006, S. 167] sind radiale Layouts eine Alternative für die Visualisierung der hierarchischen Strukturen. Die Eignung des gewählten Achsen-orientierten Layouts wird in Kapitel 5.5 im Rahmen einer vergleichenden Nutzerstudie u. a. mit einem in der Produktentwicklung weniger verbreiteten radialen Layout verglichen. Abbildung 54: Wurzelbaum in einem Constraint-based Layout Die größte Herausforderung beim Abbilden von Compound Graphen liegt darin, dass zwei Arten von Relationen (hierarchische und Tracelinks) zeitgleich und für den Nutzer jederzeit leicht unterscheidbar abgebildet werden müssen, sodass dieser weiterhin die Struktur des Graphen (mit mehreren Abstraktionsleveln) ohne Mehraufwand erkennen kann [LANDESBERGER ET AL. 2010]. Laut [LANDESBERGER ET AL. 2010] steckt die Forschung zum Zeichnen solch komplexer Graphen noch in den Kinderschuhen. In [SCHULZ UND SCHUMANN 2006, S. 170] wird empfohlen, die hierarchischen Strukturen als festes Grundmuster und die Tracelinks andersfarbig darüber zu zeichnen. Diese Empfehlung wird im Visualisierungskonzept aufgegriffen und um die Forderung erweitert, dass beide Arten von Relationen möglichst räumlich getrennt positioniert werden sollen, um Okklusionsprobleme zu minimieren. Gelingt dies, wird auch die Hypothese aus [MUNZNER 1997, S. 7] widerlegt, wonach sich bei Compound Graphen hierarchische Relationen und Tracelinks unvorteilhaft überlagern. Das Visualisierungskonzept unterstützt somit für diese beiden Relationsarten die Anforderung von [PURCHASE 1998, S. 85], wonach die Anzahl der Kantenüberschneidungen, als wichtigstes ästhetisches und die Lesbarkeit beeinflussendes Kriterium, minimiert werden soll. Je konkreter ein Tracelink modelliert wird, also je hierarchisch tiefer die verknüpften Knoten im Artefakt angesiedelt sind, desto aussagekräftiger und hilfreicher ist die Information, die er transportiert [BIANCHI ET AL. 2000; EGYED ET AL. 2007]. Auch wenn eine maximale Granularität der Tracelink-Modellierung u. a. aus ökonomischer Sicht nicht immer sinnvoll sein mag 124

154 5 Graphische Darstellung von Traceability-Modellen [CIMITILE ET AL. 1999; LINDVALL UND SANDAHL 1998b], ist dennoch die Mehrzahl der Tracelinks auf hierarchisch tieferen Ebenen modelliert. In Kapitel 3.6 wurde ferner beschrieben, wie durch die Anwendung der EcoTracing Methode explizite Verknüpfungen von Elternelementen aufgelöst werden, sobald mindestens eines ihrer Kindelemente eine Verknüpfung zum selben Referenzelement aufweist. Es muss demnach berücksichtigt werden, dass die Tracelink-Anzahl bis zu einem gewissen Grad 59 steigt, je tiefer die betrachtete Hierarchie ist. Für die Ausnahme von dieser Regel (also tiefe Hierarchieebenen, die aufgrund ihrer großen Spezialisierung nicht häufig verknüpft werden), werden Interaktionsmechanismen vorgesehen, die ein bedarfsgerechtes Ausblenden der Ebene durch den Anwender ermöglicht (Detaillierung siehe Kapitel 5.6). Das Visualisierungskonzept trägt der ebenenweise wachsenden Tracelink-Anzahl dadurch Rechnung, dass die jeweils tiefsten Ebenen der betrachteten Artefakte einander zugewandt angeordnet werden. Dadurch werden die hierarchischen Artefaktgraphen kaum durch Artefakt-übergreifende Tracelinks überlagert. Durch diese konzeptionelle Festlegung kann auch die hierarchische Transitivität der Artefakte genutzt werden. Diese führt im Hinblick auf die Visualisierung dazu, dass höhere Ebenen die Tracelinks unterer, aktuell nicht-sichtbarer Ebenen repräsentieren müssen. Der Traceability-Graph bleibt somit, unabhängig von der Anzahl der ausgeklappten Ebenen, lesbar. Zusätzlich ist gewährleistet, dass Tracelinks unabhängig von der hierarchischen Ebene, an der sie modelliert wurden, vollständig repräsentiert werden können. In [CHEN 2010, S. 506] ist weiterhin die Forderung formuliert, Tracelinks zu einer Vielzahl von Artefakten abbilden zu können. Diese Anforderung ergibt sich auch aus dem Anwendungskontext der Mechatronik, wie in Kapitel dargelegt wurde. Das Visualisierungskonzept muss demnach flexibel hinsichtlich der betrachtbaren Artefaktanzahl sein sowie zusätzlich ermöglichen, dass die Artefakte beliebig untereinander verknüpft sein können. Es muss also eine Lösung gefunden werden, die es einerseits erlaubt, eine beliebige und flexible Anzahl von Artefakten abzubilden, und andererseits gewährleistet, dass die untersten Hierarchieebenen dieser Artefakte einander immer zugewandt sind. Eine Anordnung der Artefakte, bei der die jeweils untersten Hierarchieebenen auf einer gemeinsamen Kreisbahn positioniert sind, genügt diesen Anforderungen. Dabei kann die Kreisumgebung entsprechend der Anzahl der Artefakte in gleich große Segmente aufgeteilt werden. Sind also n Artefakte darzustellen, werden ausgehend vom Kreismittelpunkt n Segmente gebildet, die jeweils einen Winkel α von umfassen. Für die Anzahl von vier Artefakten ist das in Abbildung 55 exemplarisch dargestellt. 59 Die konkrete Ausprägung der Hierarchieebene mit der höchsten Tracelink-Anzahl kann nicht pauschaliert festgelegt werden, da dies stark von dem jeweils gewählten Kompromiss zwischen inhaltlicher Genauigkeit und ökonomischen Erwägungen (siehe Kapitel 3.4) und somit der Unternehmensstrategie abhängt. 125

155 5 Graphische Darstellung von Traceability-Modellen Abbildung 55: Anordnung der Artefakte auf einer segmentierten, gemeinsamen Kreisbahn Für die feste topographische Struktur der Artefakte wurde eine Wurzelbaumstruktur gewählt. Aus der konzentrischen Anordnung der Artefakte ergibt sich die Option, die Knoten einer Hierarchieebene nicht entlang einer Geraden, sondern entlang eines Kreisbogens anzuordnen. Die Wurzelbaumstruktur ergäbe sich somit zu einer Dreiecksform, wobei die Elemente der untersten hierarchischen Ebene auf einem Kreisbogen angeordnet sind, deren Sekante die Seite des Dreiecks bildet. Die Elemente höherer Ebenen befinden sich auf konzentrischen Kreisbögen, die mit jeder nächsthöheren Ebene weiter vom Mittelpunkt entfernt sind. Das Wurzelelement als höchste Hierarchieebene bildet die Spitze des Dreiecks auf dem konzentrischen Kreisbogen, der vom Kreismittelpunkt am weitesten entfernt liegt (siehe Abbildung 56). Abbildung 56: Hierarchieebenen eines Wurzelbaums auf konzentrischen Kreisbögen 126

156 5 Graphische Darstellung von Traceability-Modellen Die konkrete Ausprägung der einzelnen Visualisierungsobjekte für das entwickelte Schema zur Anordnung der flexiblen Anzahl hierarchischer Artefakte soll im Folgenden dargelegt werden. Eine geeignete Orientierung dafür bietet WARE mit der von ihm geschilderten visuellen Grammatik 60 für Node-Link-Diagramme [WARE 2004], die auf den aus der Psychologie entlehnten Gestaltprinzipien basiert. Es werden Empfehlungen gegeben, die darauf beruhen, welche spezifische visuelle Umsetzungsmöglichkeit für welche kognitiven Assoziationen geeignet ist. Um die Lesbarkeit der Datenstruktur in Ariadne s Eye zu unterstützen, wurden daher die in Tabelle 6 aufgelisteten visuellen Ausprägungen für die einzelnen Grammatikregeln festgelegt. Graphischer Code Empfohlene Semantik Ausprägung in Ariadne s Eye Geschlossene Kontur Knoten bzw. Element Element Form der geschlossenen Kontur Farbe des umschlossenen Objekts Größe des umschlossenen Objekts Verbindende Linie Qualität der verbindenden Linien Räumliche Nähe Elementtyp Elementtyp Elementwert Beziehung zwischen Elementen Typ der Beziehung zwischen den Elementen Elementgruppen Kreis (Ausnahme: Knoten mit ausgeblendeten Kindelementen werden als Dreiecke dargestellt.) Alle Elemente eines Artefakts werden in derselben Farbe codiert. Alle Elemente eines hierarchischen Levels weisen dieselbe Kreisgröße auf; Elemente höherer hierarchischer Level werden mit größeren Kreisen gezeichnet Verbindende Linien werden zur Codierung von hierarchischen Relationen und von Tracelinks verwendet. Die Unterscheidung zwischen hierarchischen Relationen und Tracelinks erfolgt über eine unterschiedliche Farbcodierung. Elemente eines Artefakts werden innerhalb einer festen, dreieckigen Struktur räumlich gruppiert. Tabelle 6: Ausprägung der visuellen Grammatik im Visualisierungskonzept Ariadne's Eye Die detaillierte Erläuterung des Interaktionskonzepts, mit dem u. a. der Anforderungen nach einer Möglichkeit zur Selektion und Reduzierung der angezeigten Daten begegnet wird, erfolgt in Kapitel Im englischen Original: visual grammar 127

157 5 Graphische Darstellung von Traceability-Modellen 5.5. EVALUIERUNG DES VISUALISIERUNGSKONZEPTS ARIADNE S EYE: NUTZERSTUDIE LESBARKEIT DER ANORDNUNG In diesem Kapitel wird mittels einer vergleichenden empirischen Nutzerstudie untersucht, ob das entwickelte Visualisierungskonzept Ariadne s Eye im Vergleich zu zwei gängigen Anordnungskonzepten besser lesbar ist. Damit soll die in Kapitel 5.3 formulierte Hypothese verifiziert und die vorgestellten, grundlegenden Festlegungen für das Traceability- Visualisierungskonzept Ariadne s Eye evaluiert werden. Die zwei untersuchten Vergleichskonzepte nutzen zur Anordnung der hierarchischen Artefakte einerseits ein radiales, das sog. Balloon-Tree Layout und andererseits ein vertikales Tree-Layout in Spalten. Beide sind geeignet, um damit hierarchische Compound Graphen abzubilden. In einigen Veröffentlichungen wird angemahnt, dass Nutzerstudien zwar essentiell zum Vergleich von Visualisierungskonzepten sind [GHONIEM ET AL. 2004, S. 2; SCHULZ UND SCHUMANN 2006, S. 169], aber dennoch eher eine Seltenheit darstellen [BERTINI ET AL. 2011, S. 2211] und daher verstärkt durchgeführt werden sollten [NORTH 2006; HOLTEN UND VAN WIJK 2009]. Die in diesem Kapitel vorgestellte Nutzerstudie zum Vergleich dreier Anordnungskonzepte von Traceability-Informationen stellt damit einen wesentlichen Forschungsbeitrag dar. Das Ziel der Nutzerstudie ist die Beantwortung der Forschungsfrage dieses Kapitels, ob das Anordnungskonzept einen Einfluss auf die Lesbarkeit der Node-Link- Anordnung hat. Im Rahmen dieser Studie wurden den Probanden vergleichsweise einfache Informationsgewinnungsaufgaben gestellt (bspw. Finden eines Knotens, Zählen der Relationen für einen spezifischen Knoten etc.), bei denen der eigentliche Inhalt des Graphen nicht im Vordergrund steht. Trotzdem lagen dem Graphen drei hierarchische Artefakte des hypothetischen Beispielprodukts PKW-Klimaanlage zugrunde, womit sich diese Nutzerstudie von den drei in Kapitel vorgestellten Studien wesentlich unterscheidet, bei denen ausschließlich nichthierarchische und visuell nicht differenzierte Artefakte betrachtet wurden (siehe Ergebnisse in Tabelle 5). Der Anspruch an die Studie war es, die allgemeine Lesbarkeit dreier Node- Link-Anordnungskonzepte miteinander zu vergleichen. Dazu wurden wie in [PURCHASE ET AL. 1997, S. 12] und [GHONIEM ET AL. 2004, S. 2] für Papier-und-Stift-Studien zur Messung von Verständnis und Lesbarkeit empfohlen, Lösungszeit und Korrektheit der Antworten analysiert. Damit sollte überprüft werden, ob das mit der Entwicklung von Ariadne s Eye verfolgte Ziel erreicht wurde, durch räumliche Trennung von hierarchischen Relationen und Tracelinks sowie durch die Verringerung von Okklusionsproblemen eine bessere Lesbarkeit des Graphen zu ermöglichen STUDIENTEILNEHMER UND -MATERIALIEN An der Studie haben 21 Probanden teilgenommen (20 männlich, eine weiblich, Durchschnittsalter 28,54 Jahre). 20 Studienteilnehmer waren studentische Hilfswissenschaftler o- der wissenschaftliche Mitarbeiter mit ingenieurtechnischer Vorbildung. Eine Person hatte keine ingenieurtechnische Vorbildung. 128

158 5 Graphische Darstellung von Traceability-Modellen Allen drei Node-Link-Diagrammen lag dasselbe Traceability-Modell zugrunde, um eine Gleichheit hinsichtlich der Modellkomplexität und Graphendichte nach [GHONIEM ET AL. 2004] zu gewährleisten. Für das selbst entwickelte hypothetische Beispielprodukt einer PKW- Klimaanlage waren drei Artefakte abgebildet: Anforderungen, Funktionen und Produktstruktur. Die Anforderungen waren in vier, die Funktionen und die Produktstruktur jeweils in drei Hierarchieebenen strukturiert. Insgesamt bestand das Modell aus 179 Relationen und 97 Elementen, die jeweils mit einem eindeutigen Identifizierer (wie bspw. P Verdichtungssteuerung ) bezeichnet waren. Alle Artefakte wurden miteinander verknüpft, wobei die Tracelinks nicht zufällig verteilt wurden, sondern die tatsächlichen inhaltlichen Abhängigkeiten widerspiegelten. In dem ersten Vergleichskonzept waren die hierarchischen Artefakte als vertikales Tree Layout angeordnet (wie es beispielsweise die Lösungen in METUS und zum Teil in Reqtify anbieten), wobei die drei Artefakte spaltenähnlich, horizontal versetzt positioniert wurden. Entsprechend der chronologischen Reihenfolge im Entwicklungsprozess waren die Artefakte in der folgenden Reihenfolge von links nach rechts angeordnet: Anforderungen, Funktionen und Produktstruktur (siehe Abbildung 57). Das hatte zur Folge, dass Tracelinks, die Anforderungen mit Elementen der Produktstruktur verbanden, das Artefakt Funktionen durchlaufen konnten. Abbildung 57: Anordnungskonzept im vertikalen Tree Layout 129

159 5 Graphische Darstellung von Traceability-Modellen Im zweiten Vergleichskonzept waren die hierarchischen Artefakte in einem sog. Balloon-Tree Layout angeordnet. Darin waren die hierarchisch untergeordneten Knoten radial um den jeweils übergeordneten Elternknoten positioniert. Die drei Wurzelknoten der Artefakte wurden auf den Eckpunkten eines imaginären Dreiecks angeordnet: die Anforderungen links, die Funktionen oben rechts und die Produktstruktur unten rechts (siehe Abbildung 58). Abbildung 58: Anordnungskonzept im Balloon-Tree Layout Im Visualisierungskonzept Ariadne s Eye waren die Artefakte achsenorientiert angeordnet, wobei bei allen Artefakten die Elemente gleicher hierarchischer Ebene auf einem gemeinsamen Kreisbogen lagen. Je höher die Hierarchieebene, desto weiter entfernt lag ein Element vom Kreismittelpunkt. Das Artefakt Anforderungen war oben links, das Artefakt Funktionen oben rechts und das Artefakt Produktstruktur unten rechts außerhalb des gemeinsamen Kreises positioniert (siehe Abbildung 59). Artefakt-übergreifende Tracelinks verliefen somit durch das Kreisinnere. 130

160 5 Graphische Darstellung von Traceability-Modellen Abbildung 59: Anordnungskonzept Ariadne s Eye Die drei obigen Anordnungskonzepte sind hier stark verkleinert dargestellt. Zudem sind sie im Sinne einer besseren Lesbarkeit modifiziert abgebildet: die Strichstärke der Tracelinks sowie die Schriftgröße der Label ist leicht erhöht worden. Im Original wurden die drei Anordnungskonzepte auf DIN A1 geplottet, wobei die Elemente jeweils mit derselben Schriftgröße beschriftet wurden und die Knoten dieselbe Größe und Farbe hatten. Alle drei beschriebenen Node-Link-Diagramme wurden jeweils in der Software Adobe Illustrator gezeichnet. Eine größere Darstellung der Graphen, welche die ursprünglichen Proportionen widerspiegelt, jedoch auf DIN A4 skaliert wurde, kann dem Anhang A2 (Seite 296ff) entnommen werden. Der vollständig vorbereitete Graph wurde den Studienteilnehmern in allen drei Visualisierungsformen jeweils auf einem DIN A1 Blatt ausgedruckt bereitgestellt. Zum Nachverfolgen der Tracelinks wurde ein Lineal zur Verfügung gestellt, das lang genug war, um die jeweils entferntesten Elemente verbinden zu können. Darüber hinaus standen den Studienteilnehmern als Hilfsmittel zusätzlich ein Stift und selbstklebende Pfeilmarker zur Verfügung. Vor Beginn der Studie haben die Studienteilnehmer eine schriftliche Einführung in Traceability-Grundlagen erhalten, um sich mit dem Themengebiet vertraut zu machen. Jeder Teilnehmer wurde danach befragt, ob der Inhalt vollständig verstanden wurde und erhielt die Möglichkeit, bei Bedarf Fragen an den Versuchsleiter zu richten. Die durchzuführenden Aufgaben wurden ebenfalls schriftlich auf einem Ausdruck bereitgestellt. Auf diesem sollten die Teilnehmer ihre Antworten in Form der jeweiligen Identifizierer aller Lösungselemente sowie optional Kommentare in einem Freitextfeld notieren. Der Einführungstext sowie die Aufgabenblätter sind dem Anhang A2 (ab Seite 291) zu entnehmen. 131

161 5 Graphische Darstellung von Traceability-Modellen STUDIENDESIGN Die vorgestellte vergleichende, deskriptive Nutzerstudie dient der Evaluierung der Lesbarkeit des entwickelten Visualisierungskonzepts Ariadne s Eye. Dazu muss die induktiv hergeleitete Hypothese aus Kapitel 5.3 verifiziert werden. Dies geschieht, indem eine Nullhypothese abgeleitet wird, die anschließend zu falsifizieren ist. Die Hypothesen für die Lesbarkeit von Traceability-Informationen in Node-Link-Diagrammen lauten: Hypothese 1 H 1 : Ein Node-Link-Anordnungskonzept für Compound Graphen, bei dem die Überschneidung von Visualisierungsobjekten durch räumliche Trennung von Artefakten und Tracelinks reduziert wird, kann die Lesbarkeit des abgebildeten Traceability-Modells hinsichtlich Fehlerfreiheit und Geschwindigkeit signifikant verbessern. Nullhypothese H 1-0 : Ein Node-Link-Anordnungskonzept für Compound Graphen, bei dem die Überschneidung von Visualisierungsobjekten durch räumliche Trennung von Artefakten und Tracelinks reduziert wird, kann die Lesbarkeit des abgebildeten Traceability-Modells hinsichtlich Fehlerfreiheit und Geschwindigkeit nicht verbessern. Die unabhängigen Variablen der Nutzerstudie sind einerseits das Anordnungskonzept, das jeweils zur Visualisierung des Traceability-Modells verwendet wird, sowie die Aufgabenart. Die abhängigen Variablen hingegen sind die ermittelten Lösungselemente je Aufgabe sowie die benötigte Lösungszeit. Die Messgrößen, die zur Evaluierung der Hypothese genutzt werden, sind die Korrektheit der ermittelten Lösungselemente im Vergleich zur SOLL-Lösung 61 und die zugehörige Lösungszeit, die zu deren Ermittlung aufgewandt werden musste. Zusätzlich waren die Studienteilnehmer angehalten, ihre individuelle Präferenz bezüglich eines Anordnungskonzepts zu notieren. Zur Durchführung der Studie wurden klassische Aufgaben zur Ermittlung der Lesbarkeit von Graphen auf den ingenieurtechnischen Kontext adaptiert. Das war notwendig, da bei den klassischen Lesbarkeitsstudien das Layout eines Graphen bewertet wird, der die Zusammenhänge zwischen Elementen eines einzelnen Artefaktes repräsentiert. Der in Kapitel dargelegte ingenieurtechnische Anwendungsfall erfordert jedoch eine visuelle Repräsentation, welche die Darstellung der Abhängigkeiten zwischen mehreren hierarchischen Artefakten erlaubt. Von besonderer Bedeutung ist dabei zusätzlich, dass der hierarchische Kontext einzelner Elemente vom Nutzer effizient identifiziert werden kann. Daher müssen die Aufgaben für die Studie derart gestaltet sein, dass sowohl die Orientierung innerhalb der hierarchischen Struktur als auch die Navigation zwischen mehreren Artefakten Berücksichtigung finden. 61 Die SOLL-Lösung wurde vor dem Beginn der Studie vom Autor dieser Arbeit ermittelt. Sie kann aus dem bereitgestellten Traceability-Modell objektiv ermittelt werden. 132

162 5 Graphische Darstellung von Traceability-Modellen Im Folgenden ist dargelegt, wie die klassischen Aufgabenstellungen zur Ermittlung der Lesbarkeit (vgl. [GHONIEM ET AL. 2004; KELLER ET AL. 2006]) adaptiert wurden, um dem ingenieurtechnischen Kontext Rechnung zu tragen. Knoten finden: Das Suchen und Identifizieren eines spezifischen Knotens ist ein wichtiger und häufig genutzter Interaktionsmechanismus bei der Nutzung von Graphen. Um den gesuchten Knoten innerhalb eines Node-Link-Graphen zu finden, muss die gesamte Graphenfläche abgesucht werden. In der vorliegenden Studie wurde dieses klassische Vorgehen leicht modifiziert. Um die Lesbarkeit der hierarchischen Anordnung bewerten zu können, wurde den Probanden zusätzlich zum Knoten-Bezeichner der jeweilige hierarchische Pfad ausgehend vom Wurzelknoten beschrieben. Eine Aufgabenstellung könnte somit vorsehen, die funktionale, stoffliche Anforderung A Physiologische Verträglichkeit im Graphen zu identifizieren. Kanten finden: Das Suchen und Identifizieren einer Kante zwischen zwei gegebenen Knoten ist ebenfalls eine klassische Aufgabe zur Bewertung der Lesbarkeit eines Graphen. Im Rahmen dieser Studie wurde die Aufgabe leicht angepasst, um dem ingenieurtechnischen Kontext Rechnung zu tragen. Ausgehend von einem zuvor gefundenen Knoten mussten alle Knoten identifiziert werden, die direkt über eine Kante mit diesem verbunden waren. Denkbar wäre somit eine Aufgabe, bei der ausgehend von der zuvor identifizierten funktionalen Anforderung A Physiologische Verträglichkeit alle verknüpften Funktionen identifiziert werden müssten. Kanten zählen: Das Zählen der Kanten eines Knotens ist ebenfalls eine weit verbreitete Aufgabe, um die Übersichtlichkeit des Layouts zu bewerten. Diese Aufgabe wurde im Rahmen dieser Studie nicht modifiziert. Das Studiendesign sah vor, dass die Aufgaben von allen Studienteilnehmern in derselben Reihenfolge bearbeitet werden, wobei die Abfolge des je Aufgabe zu verwendenden Anordnungskonzepts gleichverteilt variiert war. Im Nachgang erfolgte der Abgleich der ermittelten Lösungselemente mit der SOLL-Lösung, um deren Korrektheit zu ermitteln. Für die Bearbeitung der Aufgaben gab es keine zeitliche Begrenzung. Während der Bearbeitung war es den Studienteilnehmern gestattet, Fragen an den Studienleiter zu richten DURCHFÜHRUNG Mit der Studie wurde begonnen, sobald der jeweilige Studienteilnehmer den einführenden Text gründlich gelesen hatte und seine offenen Fragen beantwortet wurden. Die Studienteilnehmer signalisierten dem Studienleiter jeweils den Beginn und das Beenden jeder Aufgabe, sodass dieser das zeitliche Intervall zwischen beiden Ereignissen messen konnte. Jedem Studienteilnehmer wurde vor dem Beginn einer Teilaufgabe mitgeteilt, mit welchem Anordnungskonzept die folgende Aufgabe zu bearbeiten ist. Die Aufteilung war dabei so gewählt, dass jeder Studienteilnehmer mit jedem Anordnungskonzept genau eine Aufgabe bearbeitet. Die Studienteilnehmer hatten dabei die folgenden Aufgaben zu bearbeiten: 133

163 5 Graphische Darstellung von Traceability-Modellen Aufgabe 1: Bitte suchen Sie die Anforderung Geräuschfreier Dauerbetrieb und markieren Sie diese! (Anforderung funktionale Anforderung mechanische Anforderung Geräuschfreier Dauerbetrieb) Welche Funktionen dritter Ebene F 1.x.x sind mit der Anforderung Geräuschfreier Dauerbetrieb direkt verknüpft? Bitte markieren und notieren Sie deren Identifizierer! Die Eltern dieser Funktionen sind Funktionen zweiter Ebene F 1.x. Mit welchen Produktstrukturelementen sind diese Funktionen zweiter Ebene F 1.x direkt verknüpft? Bitte markieren und notieren Sie deren Identifizierer! Aufgabe 2: Bitte suchen Sie die Anforderung Gesetzliche Anforderung und markieren Sie diese! (Anforderung nicht-funktionale Anforderung technische Randbedingung Gesetzliche Anforderung) Welche Produktstrukturelemente sind mit dieser Anforderung direkt verknüpft? Bitte markieren und notieren Sie deren Identifizierer! Welche Funktionen sind mit dieser Anforderung direkt verknüpft? Bitte markieren und notieren Sie deren Identifizierer! Aufgabe 3: Bitte suchen und markieren Sie die Funktion Luft kühlen sowie alle Kinder dieser Funktion! (Funktionen Luft kühlen) Wie viele direkte Verknüpfungen zu anderen Modellen hat die Funktion Luft kühlen a) zur Produktstruktur: b) zu den Anforderungen: Wie viele direkte Verknüpfungen haben alle Kindelemente der Funktion Luft kühlen zusammenaddiert a) zur Produktstruktur: b) zu den Anforderungen: Aufgabe 4: Bitte geben Sie an, welche Darstellungsform Sie am komfortabelsten hinsichtlich ihrer Benutzbarkeit empfanden. Darstellungsform-Nummer: Fragen, die während der Bearbeitung der Aufgabe vom Studienleiter geklärt wurden, sind in die Bearbeitungszeit eingeflossen. Fragen hinsichtlich der Korrektheit der Lösung wurden 134

164 5 Graphische Darstellung von Traceability-Modellen nicht beantwortet, um die Ergebnisse der Messung nicht zu beeinflussen. Im Anschluss an die Bearbeitung der drei Aufgaben wurde jeder Studienteilnehmer gebeten, eine Wahl des individuell bevorzugten Anordnungskonzepts zu treffen. Nach Möglichkeit sollte die Wahl begründet werden. Aus den geschilderten Rahmenbedingungen ergeben sich eine Reihe von Charakteristika der Nutzerstudie, die in Tabelle 7 zusammengefasst sind. Hypothese Studienart Ein Node-Link-Anordnungskonzept für Compound Graphen, bei dem die Überschneidung von Visualisierungsobjekten durch räumliche Trennung von Artefakten und Tracelinks reduziert wird, kann die Lesbarkeit des abgebildeten Traceability-Modells hinsichtlich Fehlerfreiheit und Geschwindigkeit signifikant verbessern. Empirische, vergleichende Nutzerstudie unter Laborbedingungen Anzahl der Teilnehmer 21 Analyseeinheit Methode zur Datenerfassung Untersuchungsobjekt Zur Bewertung der Lesbarkeit der Anordnungskonzepte werden jeweils die Werte für die Korrektheit der ermittelten Lösungselemente, die Bearbeitungszeit sowie die individuelle Präferenz der Nutzer ermittelt. Das Tracelink-Modell, dessen graphische Ausprägung in drei Node-Link-Anordnungen und die SOLL-Lösung der Lösungselemente sind im Vorlauf zur Studie erarbeitet worden. Die jeweiligen IST-Lösungselemente werden von den Studienteilnehmern im Rahmen der Studie ermittelt, die ebenfalls das individuell bevorzugte Anordnungskonzept auswählen. Die notwendige Zeit zur Bearbeitung der Aufgaben wird vom Studienleiter gemessen. Der Abgleich zwischen SOLL- und IST-Lösungen erfolgt durch den Studienleiter im Nachgang zur Studie. Anordnungskonzept Ariadne s Eye zur Visualisierung von Traceability-Modellen Analysemethoden Anordnungskonzept-bezogener Vergleich der IST- Lösungselemente, die vom jeweiligen Studienteilnehmer ermittelt wurden, mit der SOLL-Lösung, und der Lösungszeiten. Zusätzlich additive Auswertung der individuellen Anordnungskonzept-Präferenzen. Tabelle 7: Charakteristika der Nutzerstudie "Lesbarkeit der Anordnungskonzepte" 135

165 Anordnungskonzept 5 Graphische Darstellung von Traceability-Modellen ERGEBNISSE UND AUSWERTUNG Im Rahmen der quantitativen Auswertung werden zunächst die Messgrößen Korrektheit der ermittelten Lösungselemente (in Form von Fehleranzahl) und Lösungszeit in Abhängigkeit des Anordnungskonzepts (AK1: vertikales Tree Layout AK2: Balloon-Tree Layout AK3: A- riadne s Eye) und jeder einzelnen Aufgabe betrachtet. Die folgende Tabelle 8 gibt die Mittelwerte für diese beiden Messgrößen an. In Abbildung 60 ist zudem der Boxplot 62 für die erfasste Lösungszeit angegeben. Die konkreten Einzelwerte je Studienteilnehmer sind dem Anhang A2 (Seite 299) zu entnehmen. Aufgabe 1 Aufgabe 2 Aufgabe 3 Mittlere Fehleranzahl Mittlere Lösungszeit [in s] Mittlere Fehleranzahl Mittlere Lösungszeit [in s] Mittlere Fehleranzahl Mittlere Lösungszeit [in s] AK1 0,86 358,71 2,43 498,00 6,14 295,00 AK2 1,43 334,71 1,71 353,29 5,00 285,57 AK3 0,29 363,86 1,00 429,29 5,00 166,71 Tabelle 8: Mittelwerte der Messwerte Fehleranzahl und Lösungszeit Abbildung 60: Boxplot der Studienergebnisse für die Messgröße Lösungszeit 62 Das deutsche Äquivalent zu dem etablierten Begriff Boxplott lautet Kastengraphik. 136

166 5 Graphische Darstellung von Traceability-Modellen Den Ergebnissen kann entnommen werden, dass mit dem Anordnungskonzept Ariadne s Eye (AK3) in allen drei Aufgaben durchschnittlich die geringste Anzahl an Fehlern begangen wurde. Die statistische Untersuchung, ob das Anordnungskonzept einen signifikanten Einfluss auf die Messgrößen hat, erfolgt zunächst in Abhängigkeit der Aufgabe. Dazu wird für jede Aufgabe eine einfaktorielle Varianzanalyse (ANOVA) mittels der Software SPSS vorgenommen. In Tabelle 9 sind die Irrtumswahrscheinlichkeiten p in Abhängigkeit der Aufgabe dargestellt. p (Aufgabe 1) p (Aufgabe 2) p (Aufgabe 3) Lösungszeit 0,900 0,187 0,042 Fehleranzahl 0,157 0,423 0,956 Tabelle 9: Ergebnisse der Varianzanalyse je Aufgabe Es ist ersichtlich, dass sowohl bei Aufgabe 1 als auch bei Aufgabe 2 das Anordnungskonzept keinen signifikanten Einfluss auf Lösungszeit und Fehleranzahl hat, da die Irrtumswahrscheinlichkeit p jeweils deutlich über 5% liegt. Bei Aufgabe 3 hingegen ist der Einfluss des gewählten Anordnungskonzeptes auf die Lösungszeit signifikant (Irrtumswahrscheinlichkeit 4,2%). Aus diesem Grund werden für Aufgabe 3 die drei Anordnungskonzepte paarweise mittels Varianzanalyse gegeneinander abgeprüft. Die ermittelten Ergebnisse für die Irrtumswahrscheinlichkeiten und somit der Signifikanzanalyse sind in Tabelle 10 aufgeführt. AK1 & AK2 AK1 & AK3 AK2 & AK3 Lösungszeit 0,881 0,016 0,026 Tabelle 10: Ergebnisse der Varianzanalyse für Aufgabe 3 je Anordnungskonzeptpaarung Die Ergebnisse belegen, dass die Nutzer für das Bearbeiten von Aufgabe 3 mit dem Anordnungskonzept Ariadne s Eye (AK3) signifikant weniger Zeit benötigen als mit den beiden alternativen Anordnungskonzepten. Die Auswertung der individuellen Präferenz hinsichtlich eines Anordnungskonzepts ergab, dass zwei Drittel der Studienteilnehmer die Visualisierung mittels Ariadne s Eye bevorzugen (siehe Tabelle 11). AK1 AK2 AK3 Anzahl Studienteilnehmer Anteil 14,29% 19,05% 66,67% Tabelle 11: Verteilung der individuellen Anordnungskonzept-Präferenz der Studienteilnehmer DISKUSSION UND SCHLUSSFOLGERUNG Die Ergebnisse der Nutzerstudie belegen eindeutig, dass die Nullhypothese falsifiziert werden kann: durch die räumliche Anordnung in Ariadne s Eye wurden durchschnittlich am wenigsten Fehler begangen und zumindest für die Bearbeitung von Aufgabe 3 war die notwendige Lösungszeit signifikant kürzer als bei den beiden Alternativanordnungen. Zudem hat die 137

167 5 Graphische Darstellung von Traceability-Modellen große Mehrheit der Studienteilnehmer das Anordnungskonzept Ariadne s Eye qualitativ am besten bewertet. Der eigentliche Neuwert der Nutzerstudie ist die wissenschaftliche Betrachtung zur Visualisierung von Zusammenhängen zwischen mehreren hierarchischen Artefakten. Die Validität der vorgestellten Studie wird jedoch von einigen Faktoren eingeschränkt. Da die Untersuchung in dieser Studie nur für die starre Anzahl von drei Artefakten erfolgt ist, konnte ein möglicher Einfluss der Artefaktanzahl nicht betrachtet werden. Dennoch sollte dieser Zusammenhang auch für verschiedene Artefaktanzahlen zukünftig wissenschaftlich evaluiert werden. Hinsichtlich der Realitätsnähe der Nutzerstudie ist anzumerken, dass sich die Ausprägung der Artefakte bzgl. Umfang und Komplexität von der industriellen Praxis unterscheidet. Ein Manko in Bezug auf die Aussagekraft der Ergebnisse liegt in der Natur der Aufgabe 3. Während die Aufgaben 1 & 2 verhältnismäßig nah an einem späteren Anwendungsfall eines Visualisierungswerkzeugs orientiert wurden, handelt es sich bei Aufgabe 3 primär um eine Zählaufgabe, um die Übersichtlichkeit zu überprüfen. Für eine Bestätigung der besseren Nutzbarkeit im ingenieurtechnischen Kontext wäre daher ein besseres Abschneiden von Ariadne s Eye in den beiden anderen Aufgaben 1 & 2 wünschenswert gewesen. Da für diese beiden Aufgaben jedoch keine signifikanten Ergebnisse abgeleitet werden konnten, sollten zukünftige Nutzerstudien in Betracht ziehen 1. eine größere Anzahl an Teilnehmern zu gewinnen sowie 2. die einzelnen Unteraktivitäten innerhalb der Aufgaben (wie bspw. Knoten finden, Kanten nachverfolgen etc.) konkret zu analysieren, um eine bessere Aussagekraft bezüglich der spezifischen Stärken und Schwächen der Anordnungskonzepte zu erzielen. Da die Ergebnisse bezüglich der Lösungszeit zwischen den drei Aufgaben zu stark variieren, kann die Hypothese nur eingeschränkt verifiziert werden, auch wenn das einzig signifikante Ergebnis für Ariadne s Eye spricht. Mit Ariadne s Eye begingen die Teilnehmer zudem bei allen drei Aufgaben durchschnittlich die wenigsten Fehler, jedoch ist dieser Einfluss der unabhängigen Variable Anordnungskonzept auf die Fehleranzahl nicht signifikant. Auf Grundlage dieser Ergebnisse wird geschlussfolgert, dass das Anordnungskonzept Ariadne s Eye für eine Anwendung zur Visualisierung von Traceability-Modellen im mechatronischen Kontext gut geeignet ist. Daher werden die Erkenntnisse dieser Nutzerstudie sowie das aus ihr gewonnene Anwenderfeedback genutzt, um das Anordnungskonzept weiterzuentwickeln und anschließend in einem Software-Prototyp zu implementieren WEITERENTWICKLUNG DES VISUALISIERUNGSKONZEPTS An dem in der Nutzerstudie verwendeten Entwurf für das Anordnungskonzept Ariadne s Eye ist ersichtlich, dass die Flächennutzung ineffizient ist. Dies wird insbesondere durch die große Fläche im Kreisinneren deutlich, wodurch die dadurch verlaufenden Geraden (als Repräsentation der Tracelinks) unnötig lang werden. Das wurde auch von den Studienteilnehmern 138

168 5 Graphische Darstellung von Traceability-Modellen als Manko angemerkt. Daher gilt es, im Rahmen der weiteren Verfeinerung des Visualisierungskonzeptes Ariadne s Eye die Flächennutzung zu verbessern (Kapitel 5.6.1), weitere Modifikationen an den Visualisierungsobjekten vorzunehmen (Kapitel 5.6.2), um eine eingängigere Lesbarkeit zu ermöglichen, sowie ein Interaktionskonzept für den Software- Prototypen zu entwickeln (Kapitel 5.6.3). Diese Arbeiten werden in diesem Kapitel beschrieben VERBESSERUNG DER EFFIZIENZ DER FLÄCHENNUTZUNG Während der grundsätzliche Ansatz der beschriebenen räumlichen Trennung der unterschiedlichen Visualisierungsobjekte gute Ergebnisse erbrachte, offenbart die gewählte Anordnung zwei wesentliche Defizite. Zum einen sind die Elemente gleicher hierarchischer Ebene auf einem gemeinsamen Kreisbogen angeordnet. Verbreiteter und damit eingängiger ist jedoch eine Anordnung dieser Elemente entlang einer Geraden. Zum anderen erscheint die Flächennutzung wie oben ausgeführt wenig effizient. Es wird daher im weiteren Verlauf dieses Kapitels geprüft, ob das Anordnungskonzept dahingehend weiterentwickelt werden kann, dass beide Defizite behoben werden. Eine Alternative zur Anordnung auf einer Kreisbahn, welche deren generelle Vorteile erhält, ist die Anordnung der Artefakte auf den Seiten eines n-ecks, wobei n der Anzahl der Artefakte entspricht. Die Verwandtheit dieser beiden Anordnungsformen wird deutlich, wenn man betrachtet, in welchem Fall das n-eck zu einem Kreis wird. Für eine belastbare Aussage zum Vergleich der beiden Anordnungsstrategien werden in diesem Kapitel jeweils die folgenden Fragestellungen verglichen: Wie viele potentielle Überschneidungen von Elementbeschriftungen ergeben sich? Welcher Anteil der abgebildeten Visualisierungsobjekte würde bei identischer Zoomstufe nicht auf die Zeichnungsfläche passen? Wie stark wird die Zeichnungsfläche ausgenutzt? Welchen Wert hat die durchschnittliche Tracelink-Länge zwischen zwei Knoten unterschiedlicher Artefakte? Diese Fragestellungen werden exemplarisch mit einer vergleichsweise großen Anzahl an fiktiven Elementen (211 Elemente auf sieben hierarchischen Ebenen) pro Artefakt für jeweils drei und vier Artefakte betrachtet. Im Rahmen dieser Arbeit werden lediglich die grundlegenden mathematischen Zusammenhänge sowie die konkreten Ergebnisse präsentiert. Durchschnittliche Tracelink-Länge zwischen zwei Knoten unterschiedlicher Artefakte Die Motivation hinter dieser Betrachtung ist trivial. Je kürzer die durchschnittliche Tracelink- Länge zwischen zwei Knoten unterschiedlicher Artefakte, desto stärker kann ein Nutzer den Graphen vergrößern, ohne diesen translatorisch verschieben zu müssen. Muss der Graph dennoch verschoben werden, ist der Weg zu minimieren, um Zeit und Aufwand für die Interaktion zu verringern. 139

169 5 Graphische Darstellung von Traceability-Modellen Für die mathematische Betrachtung ist eine Reihe von Vereinfachungen notwendig: Es werden für alle Artefakte nur die Elemente der untersten hierarchischen Ebene (Blattelemente) betrachtet. Der Abstand zwischen zwei benachbarten Blattelementen desselben Artefakts wird auf 1 normiert. Es wird angenommen, dass jedes Blattelement mit allen Blattelementen der anderen Artefakte verknüpft ist. Daraus ergeben sich die in Abbildung 61 dargestellten vereinfachten Schemata für die vier Untersuchungsobjekte. Die grundlegenden trigonometrischen Beziehungen innerhalb der Gebilde sind exemplarisch im Dreieck eingezeichnet, wobei a die Länge des Tracelinks repräsentiert. Abbildung 61: Schematische Darstellung der trigonometrischen Zusammenhänge für die Anordnungen Kreis und n-eck mit jeweils drei (linke Spalte) bzw. vier Artefakten Da für die unterste hierarchische Ebene die Anzahl der Knoten auf k = 60 festgelegt und den äußersten Knoten jeweils ein normierter Abstand von 1 zur Kante zugewiesen wird, ergibt sich die Kantenlänge beim n-eck zu 61. Verallgemeinert beträgt die Kantenlänge somit k+1. Für den betrachteten Fall von drei Artefakten und somit einer Anordnung der Artefakte auf den Seiten eines gleichseitigen Dreiecks (alle Innenwinkel ) kann die allgemeine Länge a eines Tracelinks nach folgender Formel ( 3 ) berechnet werden 140

170 5 Graphische Darstellung von Traceability-Modellen ( ) ( 3 ) Unter Berücksichtigung der Achsensymmetrie des gleichseitigen Dreiecks ist es hinreichend, die Verknüpfungen zwischen zwei Artefakten zu betrachten und deren aufsummierte Länge durch die Anzahl ihrer Verknüpfungen zu teilen. Die Anzahl der Verknüpfungen zwischen n Artefakten mit jeweils k Elementen berechnet sich durch ( ). Für den betrachteten Fall von drei Artefakten, bei dem jedoch nur die Verknüpfungen zwischen zwei Artefakten betrachtet werden, ergibt sich die Anzahl der Verknüpfungen somit zu. Damit berechnet sich die durchschnittliche Tracelink-Länge im gleichseitigen Dreieck für die variablen Seitenlängen b und c nach Formel ( 4 ) ( ( )) ( 4 ) Somit ergibt sich für den Fall der Abbildung von drei Artefakten mit jeweils 60 Blattelementen in einem gleichseitigen Dreieck die durchschnittliche Tracelink-Länge zu 36,89. Werden im n-eck vier Artefakte mit jeweils k = 60 Blattelementen abgebildet, muss das geometrische Grundkonstrukt entsprechend zu einem Quadrat mit der Kantenlänge k+1 transformiert werden. Da die Innenwinkel im Quadrat alle betragen, werden die jeweiligen Tracelink-Längen a auf Basis des Satzes des Pythagoras berechnet. Dabei ist als Besonderheit darauf zu achten, dass im Fall des gegenüberliegenden Artefakts die Länge der Ankathete gleich der Kantenlänge k+1 ist. Damit berechnet sich die durchschnittliche Tracelink- Länge im Quadrat für die variablen Seitenlängen b und c wie in Formel ( 5 ) dargestellt. ( ) ( ( ) ( ) ) ( ( ) ) ( 5 ) Somit ergibt sich für den Fall der Abbildung von vier Artefakten mit jeweils 60 Blattelementen in einem Quadrat die durchschnittliche Tracelink-Länge zu 53,21. Für die Analysen mit dem geometrischen Grundkonstrukt Kreis werden ebenfalls jeweils drei und vier Artefakte derselben Strukturierung wie beim n-eck betrachtet. Daraus ergibt sich, dass auf dem Kreisbogen, der den Winkel umspannt, k = 60 Blattelemente positioniert werden. Der spitze Winkel, den die Radien einschließen, die zu zwei benachbarten Blattelementen desselben Artefakts laufen, hat den Wert ( ). Um vergleichbare Verhältnisse zum n-eck herzustellen, wird der Radius des Kreises so bemessen, dass der vertikale Abstand zwischen den beiden imaginären benachbarten Knoten bei und ( ) auf 1 normiert wird. Der Kreisradius berechnet sich somit aus. Die Länge des zugehörigen Kreisbogens definiert daraufhin den Abstand zwischen allen weiteren benachbarten Blattelementen, sodass deren Knoten radial äquidistant auf dem Kreisbo- 141

171 Artefaktanzahl 5 Graphische Darstellung von Traceability-Modellen gen angeordnet sind. Für die beiden betrachteten Fälle ergeben sich für die Radien der Wert 29,12 (n = 3) respektive 38,83 (n = 4). Die Positionen der Blattelemente P ji im Artefakt A j können, unter Berücksichtigung der mit dem Kreiswinkel aufsteigende Reihenfolge der n Artefakte, nach Formel ( 6 ) berechnet werden { } { ( ( ) ( ) ) ( ( ) ( ) )} ( 6 ) Die Distanz zwischen zwei Blattelementen unterschiedlicher Artefakte wird nach Formel ( 7 ) mittels deren Positionen P a {x a y a } und P b {x b y b } in einem kartesischen Koordinatensystem berechnet, dessen Ursprung im Kreismittelpunkt positioniert ist (siehe Abbildung 61). ( ) ( ) ( ) ( 7 ) Durch die symmetrische Natur der Kreisanordnung ist es hinreichend, die durchschnittliche Länge der Tracelinks ausgehend von allen Elementen eines Artefakts zu jeweils allen Elementen der anderen Artefakte zu untersuchen. Berechnet wird die durchschnittliche Länge der Tracelinks entsprechend Formel ( 8 ) durch die Aufsummierung aller Tracelink-Längen dividiert durch deren Anzahl. ( ( ( ))) ( 8 ) ( ) Für die beiden betrachteten Ausprägungen mit dem Grundkonstrukt Kreis ergeben sich somit die Werte 44,69 (für n = 3 und k = 60) respektive 60,34 (für n = 4 und k = 60). Zusammenfassend kann somit festgehalten werden, dass die durchschnittliche Länge der Tracelinks beim geometrischen Grundkonstrukt n-eck kürzer ist als beim Kreis (siehe rechte Spalte in Tabelle 12). Kreis n-eck n = 3 44,69 36,89 n = 4 60,34 53,21 Tabelle 12: Vergleichende Übersicht der durchschnittlichen Tracelink-Längen Für die Überprüfung der verbleibenden drei Fragestellungen Label-Überschneidungen 63, Randüberlauf 64 und Flächennutzung 65, wurden die in Abbildung 62 dargestellten Schemata in 63 Die Anzahl der Elemente, bei denen sich Teile der Bezeichner überlagern. 64 Die Anzahl der Elemente, deren Knoten oder Bezeichner ganz oder teilweise außerhalb der vorgesehenen Zeichenfläche positioniert werden. 65 Anteil der Zeichenfläche, der mit Artefaktinformationen befüllt ist. 142

172 Überschneidungen von Elementbeschriftungen Alle Elementbeschriftungen wurden zum Zwecke einer einfachen Lesbarkeit horizontal orientiert. Beim Grundkonstrukt Kreis wird deutlich, dass sich die Label umso stärker annähern, je kleiner der Abstand zu den Werten des Kreisinnenwinkels von 90 und 270 wird. Insgesamt ergeben sich für die gewählten Ausprägungen die in Tabelle 13 dargestellten Überschneidungswerte. Artefaktanzahl 5 Graphische Darstellung von Traceability-Modellen Adobe Illustrator erstellt. Darin sind in jedem Schema alle die Parameter Schriftgröße und Länge der Label, Anzahl sowie Abstand zwischen benachbarten Elementen und Hierarchieebenen gleich. Abbildung 62: Übersicht der Anordnungsschemata mit fiktiven Artefakthierarchien Kreis n-eck n = / 633 = 22,9% 0 / 633 = 0% n = 4 87 / 844 = 10,3% 0 / 844 = 0% Tabelle 13: Übersicht der Werte für die Label-Überschneidungen 143

173 Artefaktanzahl Während es bei der Kreisanordnung insbesondere im Fall von drei Artefakten zu starken Überschneidungen kommt, tritt dieses Problem in der n-eck Anordnung im Rahmen der Untersuchung gar nicht auf. Somit weist die Anordnung im n-eck deutlich bessere Werte bezüglich der Vermeidung von Label-Überschneidungen auf. Überlauf der Visualisierungsobjekte über die Zeichnungsfläche Diese Untersuchung dient dem Ziel zu ermitteln, welche Anordnungsform besser skalierbar ist, ohne dass dabei Visualisierungsobjekte aus der Zeichnungsfläche hinauslaufen. Aus der Abbildung der Schemata wird ersichtlich, dass dieses Problem vermehrt bei der Kreis- Anordnung mit drei Artefakten auftritt. Konkret ergeben sich für den untersuchten Fall die in Tabelle 14 angegebenen Werte. Artefaktanzahl 5 Graphische Darstellung von Traceability-Modellen Kreis n-eck n = 3 11 / 633 = 1,7% 0 / 633 = 0% n = 4 0 / 844 = 0% 0 / 844 = 0% Tabelle 14: Übersicht der Werte zum Überlauf der Visualisierungsobjekte Obwohl bei der Untersuchung mit der Kreis-Anordnung bei vier Artefakten kein Überlauf der Visualisierungsobjekte stattfand, ist mit bloßem Auge ersichtlich, dass die Label der Wurzelelemente bedeutend näher am Rand der Zeichnungsfläche liegen als bei der n-eck Anordnung. Beim Vergrößern der Ansicht würden diese Objekte also eher die Zeichnungsfläche verlassen als beim n-eck. Daher ergibt auch diese Untersuchung hinsichtlich des Überlaufs der Visualisierungsobjekte einen Vorteil der n-eck Anordnung. Flächennutzung Der letzte Bewertungsaspekt untersucht die Ausnutzung der verfügbaren Zeichnungsfläche. Je effizienter diese ausgenutzt wird, umso mehr Information kann über die Anordnung transportiert werden. Daher ist das Ziel einen möglichst großen Wert für die Flächennutzung zu erreichen. Zur Ermittlung dieser Werte wurde keine mathematische Untersuchung vorgenommen, sondern lediglich die Zeichnungsfläche jeweils in zehn Spalten und Zeilen segmentiert und die Zellen gezählt, die Visualisierungsobjekte enthalten. Die Ergebnisübersicht in Tabelle 15 zeigt, dass die Werte für die Flächennutzung bei der Anordnungsform Kreis geringfügig besser sind. Kreis n-eck n = 3 51% 46% n = 4 72% 68% Tabelle 15: Übersicht der Werte zur Flächennutzung 144

174 5 Graphische Darstellung von Traceability-Modellen Zusammenfassend kann festgestellt werden, dass die Anordnungsform n-eck bei den untersuchten Kriterien durchschnittliche Tracelink-Länge, Label-Überschneidungen und Überlauf der Visualisierungsobjekte die besseren Werte erzielt. Lediglich bei der Flächennutzung schneidet die Anordnungsform Kreis geringfügig besser ab. Aus diesen Gründen und weil die Lesbarkeit der Beschriftungen höher zu bewerten ist als die Informationsdichte wird entschieden, das Anordnungskonzept Ariadne s Eye so zu modifizieren, dass fortan ein n-eck das Grundkonstrukt bildet MODIFIKATION DER VISUALISIERUNGSOBJEKTE Auch die Visualisierungsobjekte selbst müssen im Sinne einer besseren Lesbarkeit der Darstellung weiterentwickelt werden. So kann die Verständlichkeit der hierarchischen Artefaktstruktur unterstützt werden, indem die Knotengröße die jeweilige hierarchische Zugehörigkeit eines Knotens impliziert [WARE 2004]. Übergeordnete Knoten erhalten daher eine größere Knotengröße als ihre Kindelemente. Zusätzlich bekommen Knoten mit nicht-ausgeklappten Kindelementen im Unterschied zu anderen Knoten kein Kreissymbol, sondern ein Dreiecksymbol zugewiesen, damit Nutzer leicht erkennen können, wo Artefaktzweige aktuell nicht eingeblendet sind. Mit diesen Modifikationen kann die Einordnung einzelner Knoten in ihren hierarchischen Artefakt-Kontext verstanden werden. Zu diesem Zweck bleiben die übergeordneten Elemente auch immer sichtbar. Selektierte Knoten und Tracelinks werden über eine veränderte Farbgebung hervorgehoben. Des Weiteren werden hierarchische Relationen und Tracelinks durch unterschiedliche Farben differenziert. Um beim Aus- und Einklappen von Artefaktzweigen (siehe Kapitel 5.6.3) die Orientierung innerhalb des Artefakts zu erhalten, bleibt die Sortierung der sichtbaren Elemente starr. Konkret werden dazu jeweils die Kinder eines Elternelements alphabetisch sortiert über alle Hierarchieebenen hinweg. Die Label werden jeweils auf der dem n-eck-mittelpunkt abgewandten Seite des Knotens angeordnet, um Überlagerungen mit den Artefakt-übergreifenden Tracelinks zu vermeiden. Knoten höherer hierarchischer Ebene werden zusätzlich vertikal verschoben, sollten sie andernfalls ein Label eines ihrer Kindknoten überlagern. Eine schematische Darstellung des beschriebenen, weiterentwickelten Konzepts von Ariadne s Eye ist in Abbildung 63 dargestellt. Die Summe dieser Modifikationen trägt den Anregungen der Nutzerstudie Rechnung und berücksichtigt Empfehlungen aus der Theorie der Informationsvisualisierung. Ebenso wichtig ist jedoch die Fragestellung, wie ein potentieller Nutzer mit dem Visualisierungswerkzeug interagieren kann. Daher wird im folgenden Kapitel das Interaktionskonzept zur späteren Implementierung von Ariadne s Eye hergeleitet. 145

175 5 Graphische Darstellung von Traceability-Modellen Abbildung 63: Schematische Darstellung des Konzepts von Ariadne s Eye HERLEITUNG EINES INTERAKTIONSKONZEPTS FÜR ARIADNE S EYE Die Kernaufgabe eines Visualisierungswerkzeugs im Kontext der Traceability ist die Unterstützung beim Finden eines beliebigen, digitalen Entwicklungsobjektes und beim Anzeigen all seiner Verknüpfungen zu anderen Elementen. Um diese Aufgabe möglichst effizient zu erfüllen, müssen einige Grundregeln der Informationsvisualisierung befolgt werden. Laut [AHLBERG UND SHNEIDERMAN 1994] und [SHNEIDERMAN 1996, S. 337] folgen alle Informationssuchaufgaben einem dreistufigen Prozess, dem sog. Information Seeking Mantra : zunächst Übersicht geben, dann Zoomen und Filtern ermöglichen, und zuletzt nach Bedarf Detailinformation anzeigen. Zeitgleich muss das Konzept gewährleisten, dass während dieses Prozesses die sog. Mental Map 66 erhalten bleibt [EADES 1991], damit die Nutzer nicht die Orientierung im Diagramm verlieren. Generell empfiehlt [MARCUS ET AL. 2005] den Nutzer durch ein breites Spektrum an Interaktionstechniken dazu zu befähigen, im abgebildeten Graphen zu schmökern 67. Diese Kopplung der Visualisierung mit Interaktionstechniken steigert die Effizienz der visuellen Analyse [FEKETE UND PLAISANT 2002]. Die konkrete Ausprägung der Interaktionstechniken für das Visualisierungskonzept wird im Folgenden erörtert. 66 Mental Map ist ein etablierter Begriff in der Informationsvisualisierung, mit dem die mentale Repräsentation logischer und anderer Zusammenhänge bezeichnet wird [EADES 1991]. 67 Im engl. Original browse 146

176 5 Graphische Darstellung von Traceability-Modellen Die Nutzerbefähigung zur Umsetzung des Information Seeking Mantra ist dabei die Mindestanforderung an das zu entwickelnde Interaktionskonzept. Ergänzend dazu wird für hierarchische Graphen empfohlen, bei großen Datenmengen zunächst nicht alle Hierarchieebenen aufzuklappen, sondern als Ausgangspunkt zunächst einige Detailebenen unsichtbar zu belassen, die bei Bedarf vom Nutzer interaktiv geöffnet werden können [EADES UND HUANG 2000, S. 158; SCHULZ UND SCHUMANN 2006, S. 170; SEDLMAIR ET AL. 2009, S. 176; LANDESBERGER ET AL. 2010]. In [ELMQVIST ET AL. 2008, S. 216] wird diese Funktionalität treffend hierarchische Aggregation genannt. Dafür muss unter Beibehaltung der Kontextinformation die Möglichkeit bestehen, sowohl einzelne Artefaktzweige [EADES UND HUANG 2000, S. 164], als auch ganze Artefakt-Hierarchieebenen auf- und zuzuklappen [ABELLO ET AL. 2006, S. 674]. Gleichzeitig ist aufgrund der hierarchischen Transitivität der Artefakte zu berücksichtigen, dass Elternknoten die Tracelinks ihrer einklappenden Kindknoten übernehmen bzw. diese an ihre ausklappenden Kindknoten übergeben müssen. Zusätzlich wird in [ABELLO ET AL. 2006, S. 672] empfohlen, einen Höchstwert für die Knotenanzahl der untersten Hierarchieebene festzulegen. Ist dieser Höchstwert überschritten, kann entweder die gesamte Ebene eingeklappt oder bspw. nicht jedes Element beschriftet werden. Eine Reduzierung der Schriftgröße ist hingegen nicht sinnvoll, da, wie in [DUNNE UND SHNEIDERMAN 2009, S. 4] treffend festgestellt wird, das Label entweder lesbar oder ausgeblendet sein sollte. Wesentlich für das Auf- und Zuklappen von Artefaktteilen ist, dass sich die Ansicht dabei nur geringfügig verändert, um die Mental Map zu erhalten [ABELLO ET AL. 2006, S. 674]. Gleiches gilt für das Skalieren von Graphen, wo auf die Beibehaltung der Proportionen geachtet werden muss [EADES 1991, S. 4]. Es ist notwendig, den Graphen skalierbar zu gestalten, um große Datensätze handhaben zu können [FEKETE UND PLAISANT 2002; WEAVER 2008, S. 163]. Im Interaktionskonzept von Ariadne s Eye können daher sowohl der gesamte Graph als auch nur die Label skaliert werden. Von einer Implementierung sog. Verzerrungstechniken 68, bei denen ein kleiner, geschlossener Teil des Graphen isoliert vergrößert werden kann [LANDESBERGER ET AL. 2010], sind im Prototyp von Ariadne s Eye zunächst vorgesehen. Für eine zukünftige Realisierung empfähle sich beispielsweise der wahrscheinlich prominenteste Vertreter der Verzerrungstechniken: die Fisheye Linse 69 von [FURNAS 1986]. Bei den genannten Skalierungsansätzen gilt es darauf zu achten, eine ausgewogene Balance zwischen Übersicht und Lesbarkeit von Detailinformationen zu wahren [SCHULZ UND SCHUMANN 2006, S. 170]. 68 Methoden, bei denen beliebige, lokale Regionen des Graphen verzerrt werden können, um in einem ausgewählten Bereich des Graphen eine große Anzahl an Detailinformationen darzustellen. Diese werden auch als Fokus+Kontext-Sichten bezeichnet [MUNZNER 1997, S. 3; KEIM UND SCHNEIDEWIND 2005, S. 1769]. 69 Die Fisheye Linse zeigt Objekte in der Nähe des Cursors in großer Detailtiefe, ohne dabei das Anzeigen des globalen Kontextes zu vernachlässigen, der in zunehmend geringerer Detailtiefe angezeigt wird [FURNAS 1986, S. 16]. 147

177 5 Graphische Darstellung von Traceability-Modellen Sollten Visualisierungsobjekte durch das Skalieren aus der Zeichnungsfläche hinauslaufen, muss es dem Nutzer möglich sein, den aktuell abgebildeten Fokus auf den Graph manuell zu verschieben. Um neben der Hierarchietiefe der Artefakte auch deren dargestellte Anzahl flexibel bestimmen zu können, werden die verfügbaren Artefakte in Reitern aufgelistet, die jeweils über Checkboxen an- bzw. abgewählt werden können. Um die Assoziativität der Objekte zu verbessern, weisen die Reiter dieselbe Farbe wie die Knoten des Artefakts auf. Wird ein Artefakt ein- bzw. ausgeblendet, passt sich der Graph automatisch an, indem er die n-eck Anordnung entsprechend in ein (n+1)- bzw. (n-1)-eck transformiert. Das hinzugefügte Artefakt ist (bis zu einer vordefinierten Elementanzahl) bereits ausgeklappt. Liegt die Anzahl der Elemente ab einer Hierarchieebene über dem vordefinierten Schwellwert, wird das Artefakt nur bis zur nächst höheren Hierarchieebene ausgeklappt, sodass alle Elemente auf der Zeichnungsfläche lesbar bleiben. Die Anzahl der anzeigbaren Artefakte ist nicht begrenzt. Neben den Artefakten müssen auch die einzelnen Visualisierungsobjekte (also hier die Elemente der Artefakte und die Tracelinks) selektierbar sein. Dies geht wie u. a. von [WEAVER 2008, S. 168] gefordert, mit einem farblichen Hervorheben 70 des selektierten Objekts einher. Wird in Ariadne s Eye ein Knoten selektiert, werden er und alle seine Kanten (hierarchische Relationen und Tracelinks) farblich hervorgehoben. Zur Selektion mehrerer Objekte muss die Strg-Taste gedrückt gehalten werden 71. Das im Information Seeking Mantra angemahnte Filtern wird in Ariadne s Eye über eine Suchfunktion realisiert. Dies ist eine Funktionalität, die bei vielen Visualisierungswerkzeugen vernachlässigt ist [WINKLER UND PILGRIM 2010, S. 544], obwohl das Finden gesuchter Informationen in der Praxis laut [KEIM 2002, S. 101] und [STARK ET AL. 2012] eine besondere Herausforderung darstellt. Die Suche in Ariadne s Eye erfordert die Eingabe des gesuchten Text-Strings in der Suchmaske. Alle Elemente, deren Bezeichner diesen String enthalten, werden farblich hervorgehoben. In gleicher Weise werden alle Elternelemente markiert, wenn sie das Suchkriterium selbst nicht erfüllen, jedoch deren, die Kinder aktuell nicht sichtbar sind, den gesuchten String im Bezeichner haben. Alle anderen Knoten werden ausgegraut dargestellt. Eine solche Funktionalität wurde u. a. in [STASKO ET AL. 2000, S. 689] und [SEDLMAIR ET AL. 2009, S. 177] vorgeschlagen. Zusätzlich zu dieser Ansicht wird ein Fenster am Bildrand geöffnet, in dem die aktuellen Suchtreffer aufgelistet sind. Zusätzlich sieht Ariadne s Eye weitere Interaktionsmechanismen vor (Übersicht in Tabelle 16), welche die Lesbarkeit des Node-Link-Diagramms verbessern. So wird, wenn mit dem Mauszeiger darüber gefahren wird, bei Knoten deren vollständiger Bezeichner und bei Tracelinks die Bezeichner der beiden verknüpften Elemente farblich hervorgehoben. Diese Funktionalität wird in [STASKO ET AL. 2000, S. 688], als Erfahrung aus einer Nutzerstudie, empfohlen. Zugleich relativiert diese Funktion die Bedenken aus [MARCUS ET AL. 2005, S. 57], worin behauptet wird, dass Node-Link-Diagramme nicht geeignet sind, um Detailin- 70 Engl. Fachbegriff: Highlighting 71 Alternative Ansätze zur Multiselektion wie z. B. das Hotbox- oder das Lasso-Verfahren aus [MCGUFFIN UND JURISICA 2009, S. 939] wurden nicht implementiert. 148

178 5 Graphische Darstellung von Traceability-Modellen formationen anzuzeigen. Des Weiteren kann der Nutzer jederzeit die ursprüngliche Ansicht des Graphen wiederherstellen, indem die 100%-Schaltfläche am unteren Bildrand gedrückt wird. Interaktion Interaktionsbefehl Konsequenz in Ariadne s Eye Auf- / Zuklappen Skalieren Verschieben An- / Abwahl von Artefakten Selektion Mehrfach- Selektion Suche Tooltip Ursprüngliche Ansicht Doppelklick mit linker Maustaste auf Elternknoten Scrollrad Strg + Scrollrad Linke Maustaste gedrückt halten + Maus bewegen Anklicken der Checkbox Anklicken mit linker Maustaste Strg + Anklicken mit linker Maustaste Strg + F oder Klicken in Suchfeld und Eingabe von Zeichenstring Verweilen mit Mauszeiger Klicken des 100%-Knopfs Die untergeordneten Kindelemente werden auf- bzw. zugeklappt Gesamtes Diagramm wird proportional skaliert Schriftgröße wird skaliert Gesamtes Diagramm wird translatorisch verschoben. Transformation der n-eck Anordnung in ein (n+1)- bzw. (n-1)-eck Knoten: der selektierte Knoten sowie alle seine Kanten werden farblich hervorgehoben. Kante: nur die selektierte Kante wird farblich hervorgehoben. Die Regeln der einfachen Selektion werden additiv angewandt. Alle Elemente (und deren unsichtbare Kinder), deren Bezeichner den Zeichenstring enthalten, werden farblich hervorgehoben. Alle anderen Elemente werden ausgegraut. Knoten: Der vollständige Bezeichner des Knotens wird farblich hervorgehoben dargestellt. Kante: Die vollständigen Bezeichner der beiden verknüpften Knoten werden farblich hervorgehoben dargestellt. Die Ausgangsansicht wird automatisch wieder hergestellt. Tabelle 16: Übersicht der wesentlichsten Interaktionsmechanismen und ihrer IT-Umsetzung Wichtig ist bei allen umgesetzten Interaktionen, dass für den Nutzer der hierarchische Kontext der Modellelemente [ABELLO ET AL. 2006, S. 673] und die Mental Map [EADES 1991, S. 2] erhalten bleiben. Daher wird für die Kalkulation der Graphenanordnung in [LANDESBERGER ET AL. 2010] angeregt, zuerst die Anordnung der Elemente in der Artefakthierarchie zu berücksichtigen und daran die Positionierung der Tracelinks auszurichten. Dies ist in Ariadne s Eye sowohl durch die starre Positionierung der Artefakte am n-eck als auch deren gleichbleiben- 149

179 5 Graphische Darstellung von Traceability-Modellen de hierarchische Repräsentation umgesetzt, die von allen Interaktionsmechanismen (mit Ausnahme der An- und Abwahl ganzer Artefakte) nicht grundlegend geändert werden. Das vorgestellte Interaktionskonzept für Ariadne s Eye erfüllt somit sechs von sieben in [SHNEIDERMAN 1996, S. 337] geforderten Kernfunktionalitäten für Visualisierungswerkzeuge (lediglich das chronologische Abspeichern der Interaktionsaktivitäten wird nicht unterstützt) und das Information Seeking Mantra vollständig IMPLEMENTIERUNG DES PROTOTYPS ARIADNE S EYE Dieses Kapitel beschreibt, wie die entwickelten Visualisierungs- und Interaktionskonzepte prototypisch im Traceability-Visualisierungswerkzeug Ariadne s Eye implementiert sind. Zur technischen Umsetzung wurde dafür das Framework JUNG2 72 Version verwendet. Das Framework bietet Möglichkeiten zur Umsetzung verschiedener Arten von Graphen. Die Bibliothek bietet viele etablierte Methoden der Graphentheorie an. So werden diverse Standard- Layout-Algorithmen, Plug-Ins zur Interaktion mit oder Editierung von Graphen sowie Möglichkeiten zu deren optischer Anpassung bereitgestellt. Der offene Quellcode und die vollständige API-Dokumentation erlauben zudem die Adaption der bereitgestellten Lösungen zur Integration in eigene Layout-Algorithmen. Durch die Wahl des Frameworks JUNG2 erfolgte die Implementierung von Ariadne s Eye in Java. Die abzubildende Datenbasis wird direkt der MySQL-Datenbank des ModelTracers (siehe Kapitel 3.6) entnommen. Der Datenbankzugriff seitens Java wird durch den MySQL- JDBC-Connector und das ORM-Framework Hibernate realisiert. Abgebildet werden die Objekte Element, hierarchische Relation und Tracelink. Zum objektrelationalen Datenmapping wurden Java-Klassen implementiert, die direkt für die Instanziierung des JUNG2-Graphen verwendet werden können. Das Kernstück von Ariadne s Eye bildet eine Klasse, in der folgende Schritte abgearbeitet werden: Laden der Konfigurationsdatei mit den Datenbank-Zugangsdaten, Auslesen aller für die Visualisierung relevanten Datenbank-Daten, Konstruktion des JUNG2-Graphen, Vorbereitung des passenden Layouts in Abhängigkeit der geladenen Daten, Anpassung der optischen Komponenten und Zuweisung der Interaktionsfunktionen, Aufbau und Anzeige der Benutzeroberfläche. Um das Programm Ariadne s Eye starten zu können, muss der MySQL-Datenbankserver gestartet sein. Die notwendigen Konfigurationen sind in einer XML-Datei abgelegt. Beim Start des Programms werden die Artefakte und ihre Tracelinks aus der Datenbank ausgelesen und bis zur vordefinierten Hierarchietiefe angezeigt. Der erzeugte Graph wird anschließend auf die Größe des Fensters skaliert. 72 Das Akronym JUNG steht für das seit Januar 2010 existierende OpenSource Projekt Java Universival Network/Graph. 150

180 5 Graphische Darstellung von Traceability-Modellen Zum besseren Verständnis potentieller ingenieurtechnischer Einsatzmöglichkeiten von Ariadne s Eye wird dessen Anwendung im Folgenden am Beispiel von Aufgabe 1 der Nutzerstudie aus Kapitel 5.5 anhand von Screenshots des Werkzeugs beschrieben. Vergrößerte Darstellungen der abgebildeten Screenshots können dem Anhang A3 (Seite 300ff) entnommen werden. Die übergeordnete Zielstellung für die beschriebene Aufgabe liegt darin, dass der zuständige Anforderungsingenieur für das Produkt KFZ-Klimaanlage überprüfen will, welche Funktionen betroffen wären, wenn die funktionale Anforderung Geräuschfreier Dauerbetrieb zu Gunsten einer minimal zulässigen Geräuschentwicklung gelockert wird. Die Identifikation der von dieser Änderung betroffenen Funktionen möchte der Anforderungsingenieur mit Ariadne s Eye durchführen. Dazu muss er zunächst den Datenbankserver und das Programm Ariadne s Eye starten. Die daraufhin geöffnete Startansicht in Ariadne s Eye ist in Abbildung 64 dargestellt. Abbildung 64: Startansicht der KFZ-Klimaanlage in Ariadne s Eye Der Anforderungsingenieur muss im nächsten Arbeitsschritt die gesuchte funktionale Anforderung Geräuschfreier Dauerbetrieb identifizieren. Dazu klickt er in die Suchmaske (mittig in der Befehlsleiste unten) und gibt den String geräusch ein. Alle Elemente, die diesen 151

181 5 Graphische Darstellung von Traceability-Modellen String enthalten, werden farblich hervorgehoben, während die Knoten und Bezeichner aller nicht relevanten Elemente ausgegraut werden (siehe Abbildung 65). Der Anforderungsingenieur wählt die gesuchte Anforderung (linkes Artefakt in Abbildung 65) aus den Treffern aus und selektiert diese mittels Mausklick. Abbildung 65: Visuelle Hervorhebung der Suchergebnisse Da Ariadne s Eye alle verknüpften Elemente farblich hervorhebt (siehe Abbildung 66), erkennt der Anforderungsingenieur auf einen Blick, welche Funktionen von der angedachten Lockerung der Anforderung betroffen sind. 152

182 5 Graphische Darstellung von Traceability-Modellen Abbildung 66: Automatisches Hervorheben der verknüpften Funktionen Die Organisationsstruktur der Klimaanlagen-produzierenden Firma sieht vor, dass es für jede Funktion zweiter Hierarchieebene einen verantwortlichen Funktionsentwickler gibt. Daher möchte der Anforderungsingenieur nun in Erfahrung bringen, welche übergeordneten Funktionen zweiter Ebene zu den identifizierten Funktionen dritter Ebene gehören, um sich mit den jeweiligen Verantwortlichen abstimmen zu können. Über die hierarchischen Relationen in Ariadne s Eye identifiziert er leicht die übergeordneten Funktionen und markiert diese (siehe Abbildung 67). Anschließend informiert er die beiden verantwortlichen Funktionsentwickler über die geplante Änderung und diskutiert zum besseren gemeinsamen Verständnis die daraus resultierenden Implikationen. 153

183 5 Graphische Darstellung von Traceability-Modellen Abbildung 67: Multiselektion der beiden übergeordneten Funktionen zweiter Hierarchieebene Anhand dieses ingenieurtechnischen Anwendungsbeispiels wurde aufgezeigt, dass das Visualisierungswerkzeug Ariadne s Eye eine erhebliche Unterstützung für Entwickler bieten kann. Im geschilderten Beispiel ist es dem Anforderungsingenieur gelungen, mit Hilfe von A- riadne s Eye unkompliziert die von einer Änderung potentiell betroffenen Funktionen zu identifizieren. Dadurch ist es ihm möglich, vor der Änderungsentscheidung die Funktionsverantwortlichen zu ermitteln und mit denen die ingenieurtechnischen Implikationen der angedachten Änderung zu erörtern. Der beschriebene Prozess zur Identifikation der übergeordneten Funktionen dauerte bei der Durchführung zur Erstellung der Screenshots mit Ariadne s Eye insgesamt 17 Sekunden. Derselbe Prozess konnte im Rahmen der Nutzerstudie mit Papier und Stift von dem schnellsten Probanden in ca. 180 Sekunden bearbeitet werden. Obwohl diese beiden Messmethoden nicht vergleichbar sind, verdeutlicht das Verhältnis beider Bearbeitungszeiten dennoch das Potential von Ariadne s Eye bei der im Ingenieursalltag permanent durchzuführenden Informationsbeschaffung Siehe Ergebnisse der Untersuchungen zum Aufwand der Informationsbeschaffung von [KEIM 2002] und [STARK ET AL. 2012] 154

184 5 Graphische Darstellung von Traceability-Modellen 5.8. VERGLEICHENDE EVALUIERUNG DER LESBARKEIT: ARIADNE S EYE VS. FORCE-DIRECTED-LAYOUT Ein häufig verwendetes Anordnungskonzept für Traceability-Informationen in Node-Link- Diagrammen sind Force-directed-Layouts (siehe Stand der Technik in Kapitel 5.2.1). In dem folgenden Kapitel soll evaluiert werden, wie die Lesbarkeit des entwickelten Anordnungskonzepts Ariadne s Eye im Vergleich zu einem etablierten Force-directed-Layout abschneidet. Als Evaluierungsmethode werden die sog. Lesbarkeitsmetriken aus [DUNNE SHNEIDERMAN 2009] genutzt, die im Folgenden kurz vorgestellt werden. Laut [DUNNE UND SHNEIDERMAN 2009, S. 1] sind die Lesbarkeitsmetriken ein Maß für die Verständlichkeit des gezeichneten Graphen. In Tabelle 17 ist erklärt, welchen Sachverhalt die jeweiligen Metriken beschreiben. UND Metrik Knoten-Überlagerung Kanten-Überschneidung Kanten-Tunnel Bezeichner-Überlagerung Beschreibung Berühren oder überlagern sich die Flächen für die Symbole der Knoten, wird von einer Knoten-Überlagerung gesprochen. Berühren oder schneiden sich die Linien zur Repräsentation von Kanten, wird von einer Kanten-Überschneidung gesprochen. Überlagert eine Beschriftung eines Knotens eine Kante, läuft diese also unter diesem hindurch, wird von einem Kanten- Tunnel gesprochen. Berühren oder Überlagern sich die Flächen für die Bezeichner der Knoten, wird von einer Bezeichner-Überlagerung gesprochen. Tabelle 17: Beschreibung der Lesbarkeitsmetriken nach [DUNNE UND SHNEIDERMAN 2009] In [SCHULZ UND SCHUMANN 2006, S. 171] wird empfohlen, zwischen diesen Metriken abzuwägen und zu priorisieren, da sie teilweise widersprüchlich sein können. In einer Studie wurde nachgewiesen, dass Kanten-Überschneidungen einen besonders negativen Einfluss auf die Verständlichkeit des Node-Link-Diagramms haben [PURCHASE ET AL. 1997, S. 13]. Diese Forderung nach einer Minimierung der Kanten-Überschneidungen wird auch in [FERRARI UND MEZZALIRA 1969] unterstützt. Diese Ergebnisse sind allerdings nur bedingt übertragbar, da bei den genannten Untersuchungen nur die Relationen innerhalb eines Artefakts untersucht wurden. Laut [MUTZEL 2000] können Kanten-Überschneidungen unter bestimmten Umständen sogar zu einer besseren Verständlichkeit beitragen. Daher muss an dieser Stelle genauer hinterfragt werden, unter welchen Bedingungen Kanten-Tunnel negative Auswirkungen auf die Lesbarkeit des Graphen haben. Generell kann es in einem Compound Graphen zu drei Arten von Kanten-Tunneln kommen. Es können sich zwei hierarchische Relationen, zwei Tracelinks oder ein Tracelink und eine hierarchische Relation schneiden. Die hierarchischen Relationen haben einen großen Einfluss auf die Verständlichkeit, da mit ihrer Hilfe die zugehörigen Eltern- und Kindelemente identifiziert und kognitiv interpretiert werden. Dadurch wird die Kontextinformation erzeugt, 155

185 5 Graphische Darstellung von Traceability-Modellen wo sich das Element inhaltlich in den Gesamtgraphen einordnet. Eine Überschneidung dieser Kanten sollte also vermieden werden, um Missinterpretationen der Kontextinformationen auszuschließen. Das Nachverfolgen von Tracelinks ist ebenfalls wichtig. Allerdings ist die kognitive Belastung dabei geringer, da nur der eine Knoten am Ende des Tracelinks interpretiert werden muss. Zudem kann dieses vergleichsweise einfache Nachverfolgen durch farbliches Hervorheben des Tracelinks und seiner beiden Endelemente kompensiert werden (siehe Kapitel 5.6.3). Innerhalb einer Hierarchie ist dies zwar generell auch möglich, allerdings müsste dabei eine deutlich größere Zahl an Visualisierungsobjekten hervorgehoben werden (Eltern- und Kindelemente), was dem Grundsatz der visuellen Informationseffizienz widerspricht. Es wird also zusammenfassend festgehalten, dass Überschneidungen unter Beteiligung von hierarchischen Relationen zu vermeiden sind, während sich überschneidende Tracelinks toleriert werden können, da diese nicht gleich erheblich sind. Für den im Folgenden beschriebenen Vergleich der beiden Anordnungsalgorithmen wurde ein Beispielprodukt eines Fahrrads mit drei hierarchischen Artefakten (Anforderungen, Funktionen und Produktstruktur) entwickelt. Die Knoten eines Artefakts haben dieselbe Farbe, während ihre Größe den jeweiligen hierarchischen Status widerspiegelt. Diese beiden Attribute waren bei den untersuchten Force-directed-Layouts im Stand der Technik nicht gegeben, sodass die im Folgenden dargestellte Variante des Force-directed-Layouts bereits leichter zu interpretieren ist als die etablierten Lösungen. Der Graph des entwickelten Produktmodells hat insgesamt 65 Knoten und 123 Kanten (davon 79 Tracelinks). In beiden Layouts wurde die Schriftgröße auf 22 Pixel festgesetzt. Für das Force-directed-Layout wurde ein dynamischer Fruchterman-Reingold-Algorithmus 74 genutzt, der nach 700 Iterationen gestoppt wurde. In Abbildung 68 sind beide Layouts für diesen Graphen abgebildet. 74 Der Fruchterman-Reingold-Algorithmus wurde in der Konfiguration Repulsion = 0,75 und Attraction = 0,75 spezifiziert. 156

186 5 Graphische Darstellung von Traceability-Modellen Abbildung 68: Abbildung der Vergleichslayouts Force-directed (oben) und Ariadne's Eye 157

187 5 Graphische Darstellung von Traceability-Modellen Der erste Eindruck bei der Betrachtung den beiden Graphen veranschaulicht zwei Dinge: zum einen ist das Diagramm in der Anordnung Ariadne s Eye deutlich größer und zum anderen ist die hierarchische Struktur und Anzahl der Artefakte im Force-directed-Layout (trotz der implementierten Zusatzattribute Knotenfarbe und -größe) nicht einfach zu erfassen. Diese Eindrücke werden größtenteils von den Ergebnissen der Lesbarkeitsmetriken gestützt, die in Tabelle 18 abgebildet sind. Force-directed Ariadne s Eye Platzbedarf (unskaliert) 1580 px * 850 px 2100 px * 2000 px Knoten-Überlagerungen 0 0 Kanten-Tunnel Bezeichner-Überlagerungen 17 0 Kanten-Überschneidungen Tracelink-Tracelink Hierarchie-Tracelink Hierarchie-Hierarchie ~ Tabelle 18: Ergebnisse des Vergleichs der Lesbarkeitsmetriken Die quantitativen Ergebnisse verdeutlichen, dass das Force-directed-Layout zwei Vorteile gegenüber Ariadne s Eye aufweist. Der erste Vorteil ist, dass es deutlich weniger Zeichnungsfläche benötigt. Der relativ große Flächenbedarf von Ariadne s Eye ist bei der Konzeption bewusst in Kauf genommen worden. Er ist primär durch die große Fläche innerhalb des n-ecks bedingt. Diese ist jedoch notwendig, um die Visualisierungsobjekte räumlich trennen zu können, was laut Nutzerstudie in Kapitel 5.5 tendenziell eine bessere Lesbarkeit des Diagramms zur Folge hat. Eine Reduzierung der Fläche wäre relativ einfach möglich, indem beispielsweise darauf verzichtet würde, alle Seiten des n-ecks gleich lang zu zeichnen. Die Optimierung des Flächenbedarfs ist jedoch nicht Gegenstand dieser Arbeit, zumal zunächst untersucht werden muss, ob dies keine negativen Auswirkungen auf die Lesbarkeit des Graphen hervorruft. Die einzige Lesbarkeitsmetrik, bei welcher das Force-directed-Layout im Vergleich besser abschneidet, und damit der zweite Vorteil gegenüber Ariadne s Eye, ist die geringere Anzahl an Überschneidungen von Artefakt-übergreifenden Tracelinks. In der Einführung der Lesbarkeitsmetriken wurde bereits diskutiert, welche Bedeutung diese Metrik hat. Es wurde jedoch festgestellt, dass die Überschneidungen von Tracelinks gegenüber Überschneidungen unter Beteiligung von hierarchischen Relationen weniger bedeutend sind. Überlagerungen von Knotensymbolen sind in beiden Anordnungen nicht aufgetreten. Dies ist primär auf die geringe Anzahl an Elementen zurückzuführen. In allen anderen untersuchten Lesbarkeitsmetriken schneidet Ariadne s Eye deutlich besser ab als das Force-directed- Layout. Weniger bedeutend hinsichtlich der Aussagekraft der Ergebnisse sind dabei die Kan- 158

188 5 Graphische Darstellung von Traceability-Modellen ten-tunnel, da dieses Problem durch ein interaktives Hervorheben der Kante erheblich an Bedeutung verliert. Die Überlagerungen der Bezeichner und die Überschneidungen unter Beteiligung der hierarchischen Relationen sind hingegen sehr relevant, da sie die Interpretation des Graphen und insbesondere der Kontextinformation direkt beeinträchtigen. Ariadne s Eye schneidet bei diesen Metriken deutlich besser ab. Daher ist die Schlussfolgerung valide, dass Ariadne s Eye einen besser verständlichen Graphen zeichnet als der etablierte Forcedirected-Algorithmus ZUSAMMENFASSUNG UND DISKUSSION In Kapitel 5 wurde ein innovatives Konzept zur Visualisierung von Traceability-Informationen entwickelt und evaluiert. Zunächst wurde dazu der allgemeine Bedarf erläutert. Dieser manifestiert sich auch in den Ergebnissen einer Studie in der Automobilindustrie, wonach eine Artefakt-übergreifende Übersicht der Systeminterdependenzen explizit gewünscht ist [ALMEFELT ET AL. 2006, S. 122]. Das deckt sich mit den Ergebnissen einer weiteren Industrieumfrage, in der 87 % der befragten Ingenieure angab, sich verbesserte Informationssuchmechanismen zu wünschen, da relevante Informationen derzeit entweder nicht rechtzeitig oder in der falschen Form bereitgestellt werden [STARK ET AL. 2012]. Für eine solche Anwendung im industriellen Umfeld der Entwicklung mechatronischer Systeme wurden anschließend Anforderungen an ein Visualisierungswerkzeug für Traceability- Informationen abgeleitet. Die darauffolgende Stand-der-Technik-Analyse offenbarte, dass keines der verfügbaren Werkzeuge diesen Anforderungen genügt. Daraufhin wurde die Hypothese entwickelt, dass ein Anordnungskonzept, bei dem die unterschiedlichen Arten von Visualisierungsobjekten räumlich getrennt angeordnet werden, diesen Anforderungen besser genügt. Ein solches Anordnungskonzept wurde auf Grundlage der Informationsvisualisierungstheorie entwickelt und mit Hilfe einer Nutzerstudie evaluiert. Das Ergebnis der Evaluation indiziert, dass eine räumliche Trennung der Visualisierungsobjektarten tendenziell bessere Ergebnisse hinsichtlich der Lesbarkeit von Node-Link- Diagrammen erbringt. Auf Basis der Erkenntnisse der Nutzerstudie und theoretischer Grundlagen wurde das Anordnungskonzept weiterentwickelt und um ein Interaktionskonzept ergänzt. Diese Ergebnisse flossen in die prototypische Implementierung des Traceability-Visualisierungswerkzeugs Ariadne s Eye ein. Eine weiterführende Evaluierung des Werkzeugs Ariadne s Eye ergab, dass ein damit gezeichneter Traceability-Graph bessere Werte bei den Lesbarkeitsmetriken nach [DUNNE UND SHNEIDERMAN 2009] erzielt als eine etablierte Force-directed-Anordnung. Zusätzlich zeigen die Ergebnisse, dass die Hypothese aus [MUNZNER 1997, S. 7], wonach sich bei 2D-Visualisierungen hierarchische Relationen und Tracelinks immer überschneiden würden, nicht haltbar ist. Die zentrale Forschungsfrage, ob ein Anordnungskonzept, bei dem die unterschiedlichen Arten von Visualisierungsobjekten räumlich getrennt angeordnet werden, eine bessere Lesbarkeit von Node-Link-Diagrammen ermöglicht, kann somit bejaht werden, was auch der wesentliche Forschungsbeitrag dieses Kapitels ist. Aber auch die Nutzerstudie zur Evaluierung der Visualisierungslösung stellt einen eigenen Forschungsbeitrag dar, da de- 159

189 5 Graphische Darstellung von Traceability-Modellen ren Durchführung für Visualisierungswerkzeuge in der Literatur aufgrund ihrer Seltenheit gefordert werden [NORTH 2006; HOLTEN UND VAN WIJK 2009; BERTINI ET AL. 2011, S. 2211]. Das entwickelte Visualisierungswerkzeug Ariadne s Eye adressiert somit die in Kapitel 5.1 erläuterten, industrierelevanten Herausforderungen. Das primäre Anliegen von Ariadne s Eye ist es, für beliebige, digitale Entwicklungsobjekte bei der Suche nach Verknüpfungen zu anderen Elementen zu unterstützen. Durch explizite Abbildung von Systemzusammenhängen wird zudem das Erzeugen von Systemverständnis bei den anwendenden Entwicklern erleichtert. Ariadne s Eye kann damit bei Bedarf in den meisten Prozessen der Produktentwicklung unterstützend eingesetzt werden, auch wenn es keinen direkten, messbaren Mehrwert im Sinne einer Wertschöpfung kreiert. Ein exemplarisches Anwendungsszenario wurde am Beispiel einer KFZ-Klimaanlage in Kapitel 5.7 vorgestellt. Darin wurde beschrieben, wie ein Anforderungsingenieur die potentiell von einer Anforderungsänderung betroffenen Funktionen identifiziert. Durch das Erkennen dieser Funktionen kann der Anforderungsingenieur die jeweiligen Funktionsverantwortlichen identifizieren, um mit diesen die Implikationen der Änderung zu besprechen. Die Funktionsverantwortlichen ihrerseits können daraufhin mittels A- riadne s Eye die zu ändernden Bauteile bestimmen, um ggf. deren Anpassungskonstruktion anzustoßen. Zwei Aspekte begrenzen die Validität der Forschungsergebnisse: erstens wurden lediglich Graphen mit, im Vergleich zur industriellen Praxis, geringem Umfang untersucht und zweitens wurde der Fokus nur auf Artefakt-übergreifende Tracelinks gelegt. Dennoch erhielt Ariadne s Eye bei der initialen Vorstellung im Rahmen von Industrieworkshops sehr positives Feedback sowohl hinsichtlich des Graphen-Layouts als auch des Bedarfs nach einer solchen Visualisierungslösung. Die weiteren Schritte sollten daher darauf abzielen, die entwickelte Lösung im industriellen Rahmen zu evaluieren und das Konzept hinsichtlich der Abbildung von Artefakt-internen Tracelinks zu erweitern, sofern letzteres erforderlich ist. Zukünftige Weiterentwicklungen zur Verbesserung des Visualisierungswerkzeugs könnten darüber hinaus die Wirksamkeit technischer Funktionalitäten zur räumlichen Annäherung von Geschwisterknoten (bspw. durch Simulation von Federkräften [EADES UND HUANG 2000, S. 167]) sowie das Bündeln von Tracelinks wie in [HOLTEN 2006] und [HOLTEN ET AL. 2007] adressieren. Wie in Kapitel adressiert, ist zudem die Implementierung von Fokus + Kontext-Sichten (bspw. durch Fisheye Lens, Bifocal Displays oder Magic Lense Filter) denkbar. Eine Anregung, die auf das erhaltene Industriefeedback zurückzuführen ist, betrifft die Beschränkung der Abbildung auf Nutzer-auswählbare Subgraphen einzelner Artefakte, wie es auch in [SCHULZ UND SCHUMANN 2006, S. 170] angedacht ist. Hintergrund dieses Vorschlags sind die teilweise enormen Hierarchietiefen von Artefakten, die im industriellen Umfeld Verwendung finden, bei gleichzeitiger Konzentrierung der Tracelinks auf tiefere Ebenen. Generell ist dies eine interessante Forschungsfrage, da somit ein Großteil des nicht-relevanten Graphen nicht abgebildet werden müsste, was zu einer verbesserten Informationseffizienz führen würde. Zu beantworten wäre dabei jedoch zunächst, wie mit Tracelinks auf höheren und damit nicht länger sichtbaren Hierarchieebenen verfahren wird. Diese müssen jedoch 160

190 5 Graphische Darstellung von Traceability-Modellen berücksichtigt werden, da sie nach den Regeln der hierarchischen Transitivität nicht einfach auf den Subgraph vererbt werden können. Es bleiben somit einige Forschungsfragen für zukünftige Untersuchungen offen. Dennoch kann zusammenfassend festgestellt werden, dass das Konzept Ariadne s Eye einen wertvollen Beitrag für die Visualisierung von Traceability-Informationen in Node-Link-Diagrammen liefert. Die folgenden Kapitel 6 und 7 beschreiben, wie Ariadne s Eye in einem konkreten Anwendungsszenario, dem Änderungsmanagement, visuelle Unterstützung bieten kann. 161

191

192 6. TRACEABILITY-BASIERTE IMPACT-ANALYSE-METHODE FÜR DIE ENTWICKLUNG MECHATRONISCHER PRODUKTE In Kapitel 5 wurde erläutert, dass die Visualisierung von Traceability-Daten hilft, Systemzusammenhänge eingängiger zu erfassen. Die Abbildung der Tracelinks hilft Entwicklern, die Verbindungen zu anderen Teilen des Systems und relevante Schnittstellen besser zu verstehen [LINOS ET AL. 1994; SUTINEN ET AL. 2002, S. 1; EGYED UND GRÜNBACHER 2005; KELLER ET AL. 2005, S. 2]. Dieses Systemverständnis ist auch der Erfolgsschlüssel zu einem erfolgreichen Änderungsmanagement [RAJLICH 2000, S. 72; BOHNER 2002, S. 264; ECKERT ET AL. 2004, S. 20; HOLTEN ET AL. 2007, S. 47], weil die Entwickler dadurch die Auswirkungen der Änderung frühzeitig abschätzen können. Unter anderem aus diesem Grund wird Traceability ebenfalls als eine wichtige Methode für eine konsistente Systemevolution und damit das Änderungsmanagement erachtet [POHL 1996, S. 77; RAMESH ET AL. 1997, S. 407; MOHAN ET AL. 2008, S. 922]. Change is certain, progress not E. H. Carr (zit. n. [FRICKE ET AL. 2000, S. 170]) Änderungen sind nicht die Ausnahme in der Produktentwicklung sie sind die Regel [CLARK UND FUJIMOTO 1991; FRICKE ET AL. 2000, S. 169]. Sie sind ein elementarer Bestandteil der Produktentwicklung, da sie den aktuellen Entwicklungsstand evolutionär verbessern oder verfeinern [EVBUOMWAN ET AL. 1996, S. 302], indem das Produkt an neue Notwendigkeiten oder Anforderungen angepasst wird [ECKERT ET AL. 2004, S. 1]. Es ist nicht ungewöhnlich, dass im Verlauf des Entwicklungsprozesses mehr als die Hälfte aller Systemanforderungen geändert werden, bevor das Produkt in Betrieb genommen wird [SUTINEN ET AL. 2004, S. 189]. Beim Umgang mit Änderungen sind die Herausforderungen vielschichtig. Einige dieser Schwierigkeiten sind auf menschliche Faktoren, wie das unabsichtliche Nutzen unterschiedlicher Datensätze sowie fehlende oder sogar falsche Entscheidungen zurückzuführen [ECKERT ET AL. 2004, S. 9]. Ein elementares Defizit liegt in der Kommunikationskultur begründet. So werden bei Änderungen häufig die betroffenen Entwickler nicht rechtzeitig informiert [FRICKE ET AL. 2000, S. 172], was u. a. daran liegt, dass die betreffenden Personen nur mit großem Aufwand identifiziert werden können [ECKERT ET AL. 2004, S. 9]. Zusätzlich wurde in einer Fallstudie, bei der Entwickler und Manager befragt wurden, ermittelt, dass ca. 163

193 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte 30% aller Arbeitsaufwände auf Änderungen zurückzuführen sind [FRICKE ET AL. 2000, S. 170]. Diese große Menge an Änderungsaktivitäten birgt das Risiko, Entwicklungsprojekte zu verlangsamen, weshalb eine große Notwendigkeit besteht, Änderungsprozesse effektiv zu managen [WYNN ET AL. 2010b, S. 1692]. Das verdeutlicht die Potentiale für eine bessere informationstechnische Unterstützung des Änderungsprozesses. Von besonderer Bedeutung ist dabei das Phänomen, dass sich die Auswirkungen einer Änderung nicht ausschließlich auf direkt betroffene Elemente beschränken, sondern deren Änderung wiederum die Ursache für weiterführende Anpassung sind [SUTINEN ET AL. 2002, S. 1; ECKERT ET AL. 2004, S. 1]. Aufgrund der Schwierigkeit, diese Auswirkungen für das zu entwickelnde Produkt abzuschätzen, wird deren Analyse bspw. in der ISO für die Entwicklung sicherheitsrelevanter Fahrzeugfunktionen zwingend vorgeschrieben [ISO ]. Das Phänomen der propagierenden Auswirkungen einer Änderung wird als Änderungsfortpflanzung 75 und die analytische Betrachtung von deren Auswirkung als Auswirkungsanalyse 76 bezeichnet. Im weiteren Verlauf dieses Kapitels werden diese Mechanismen detailliert betrachtet, definiert und im Kontext des Systems Engineerings diskutiert. Selbst erfahrene Entwickler konnten in empirischen Studien nicht alle von einer Änderung betroffenen Elemente vollständig vorhersagen [LINDVALL UND SANDAHL 1998a, S. 26]. Berücksichtigt man zudem, dass durch die wachsende Anzahl und Frequenz von Änderungen sowie die steigende Komplexität mechatronischer Produkte, deren erfolgreiches Management zunehmend wichtiger wird [WYNN ET AL. 2010b, S. 1691], so ist eine informationstechnische Hilfestellung für die Entwickler dringend angezeigt. Zumal es enorme Aufwände erfordert, die Konsistenz zwischen den einzelnen Artefakten im Unternehmen im Änderungsfall zu erhalten [EIGNER UND STELZER 2009, S. 79]. Auch in der industriellen Produktentwicklung ist diese Fragestellung von großer Bedeutung, weshalb unter anderem CONRAD ET AL. davon berichten, dass bei Daimler untersucht wird, wie Tracelinks zwischen unterschiedlichen Artefakten genutzt werden können, um Änderungen effizient zu managen [CONRAD ET AL. 2005, S. 5]. Ändert sich ein Element, sind Elemente, die mit diesem über Tracelinks verknüpft sind, potentiell von der Fortpflanzung dieser Änderung betroffen [HORVATH UND RUDAS 2007, S. 4]. Die Änderungsfortpflanzung erfolgt somit entlang der vorher modellierten Tracelinks 77 [ECKERT ET AL. 2004, S. 2]. Das Traceability-Modell kann also genutzt werden, um die Auswirkungen von Änderungen prospektiv abzuschätzen [EDWARDS 1992; GÖKNIL ET AL. 2008, S. 59]. Dabei ist zu beachten, dass die endgültige Bewertung, ob sich eine Änderung entlang eines Tracelinks tatsächlich fortpflanzt, sowie die Beurteilung, wie umfangreich die verknüpften Artefakte betrachtet werden müssen, einer menschlichen Entscheidung obliegen 75 Engl: change propagation 76 Engl: impact analysis 77 Voraussetzung für eine Auswirkungsanalyse ist somit ein vollständig und korrekt modelliertes Traceability-Modell [LINDVALL UND SANDAHL 1998b, S. 40; CIMITILE ET AL. 1999, S. 212]. 164

194 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte [ECKERT ET AL. 2004, S. 17; RIVIERE ET AL. 2003, S. 8f]. Dieser zweistufige Prozess ist in Abbildung 69 schematisch dargestellt: Schritt 1, also die Identifikation aller potentiell von der Änderung betroffenen Elemente, kann dabei über die Traceability-Informationen erfolgen, während Schritt 2, also die tatsächliche Bewertung, ob das vorgeschlagene Element betroffen ist, in der Mechatronik nur auf Basis menschlicher Expertise erfolgen kann. Abbildung 69: Zweistufiger Prozess zur Identifikation potentiell betroffener Elemente (Schritt 1) und deren manuelle Bewertung (Schritt 2) Mithilfe des Traceability-basierten Änderungsmanagements wird für die beteiligten Verantwortlichen das Systemverständnis (durch explizites Aufzeigen der Zusammenhänge) erleichtert und somit die Entscheidungsfindung unterstützt [BODE UND RIEBISCH 2009, S. 87]. So können das Verständnis und die Antizipation, wie sich eine Änderung in einem spezifischen Fall auf das Produkt auswirken werden, den nicht notwendigen Teil des Änderungsaufwands substantiell verringern [WYNN ET AL. 2010b, S. 1699]. Eine Methode zur Abschätzung der Auswirkung von Änderungen würde daher für viele Unternehmen eine große Unterstützung darstellen, da diese es ermöglicht, Änderungsalternativen frühzeitig zu bewerten und damit ökonomische Risiken zu reduzieren [PFLEEGER UND BOHNER 1990, S. 320; PINHEIRO 2003, S. 99; WEBER 2007, S. 85f]. Seit den 1980er Jahren wurden Ansätze in der Softwareentwicklung vorgestellt, bei denen Traceability-Daten genutzt wurden, um die Auswirkung der Änderung eines einzelnen Elements auf andere Elemente abzuschätzen [Rome Air Development Center 1986]. Ziel dieser Ansätze ist es, all jene Elemente zu identifizieren, die von der Änderung betroffen sind, um die ansonsten notwendige Überprüfung aller Elemente zu vermeiden. Diese Ansätze sind umso wirksamer, je vollständiger die Menge der zu Recht identifizierten Elemente und je geringer der Anteil der zu Unrecht identifizierten Elemente ist. Vor diesem Hintergrund ist es notwendig, bestehende Ansätze aus diesem Umfeld zu analysieren und an die Spezifika der Mechatronik anzupassen. Dieses Kapitel behandelt daher die Forschungsfrage der Herleitung und Evaluierung eines Algorithmus zur Identifikation von 165

195 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte Elementen, die direkt oder indirekt von einer Änderung betroffen sind, für die Entwicklung mechatronischer Produkte. Zunächst werden dazu in Kapitel 6.1 einige Grundlagen zum Thema Änderungsmanagement vorgestellt. Im anschließenden Kapitel 6.2 werden die theoretischen Grundlagen einer Methode zur Traceability-basierten Änderungsabschätzung (Impact Analyse) vorgestellt. Existierende Impact-Analyse-Ansätze des Standes der Wissenschaft und Technik werden daraufhin in Kapitel 6.3 betrachtet und analysiert. Aus den Erkenntnissen der vorherigen Ausführungen wird in Kapitel 6.4 eine Hypothese bzgl. einer Impact Analyse für die Entwicklung mechatronischer Produkte abgeleitet, bevor in Kapitel 6.5 ein entsprechender Impact-Analyse-Algorithmus entwickelt wird. Die Wirksamkeit des Algorithmus wird dabei hinsichtlich der Vollständigkeit der korrekt ermittelten Elemente und deren Anteil an der Gesamtmenge der ermittelten Elemente bewertet. Zur Überprüfung dieser Forschungsfrage werden in Kapitel 6.6 die Ergebnisse einer Nutzerstudie präsentiert. Im abschließenden Kapitel 6.7 wird die Unterstützbarkeit der Mechatronik durch eine adaptierte Impact-Analyse-Methode zusammenfassend diskutiert GRUNDLAGEN DES ÄNDERUNGSMANAGEMENTS IM SYSTEMS ENGINEERING Das Beherrschen von Änderungen im Rahmen des Systems Engineerings ist keine triviale Herausforderung. Denn im Gegensatz zur vorwärts gerichteten Neuentwicklung ist das Änderungsmanagement durch eine Vielzahl bereits existierender Restriktionen, die durch die vorhandenen Lösungen vorgegeben sind, äußerst anspruchsvoll [PFLEEGER UND BOHNER 1990, S. 321]. Die Ergebnisse einer Anwenderstudie von BROWN, bei der nur 12% der befragten Unternehmen die Auswirkungen einer Änderung abschätzen konnten, unterstreichen diese Aussage [BROWN 2006]. Vor dem Hintergrund, dass allein Anforderungen während des Entwicklungsprozesses permanent geändert und hinzugefügt werden [ALMEFELT ET AL. 2006, S. 123], ist dieses Ergebnis bedenklich. Eine besondere Relevanz erhält das Management von Änderungen, da diese sowohl Entwicklungszeit und -kosten als auch -qualität stark beeinflussen [STERMAN 2000; WECK UND BOUNOVA 2007, S. 7]. Die Änderungskosten beinhalten dabei u. a. die Anpassungskonstruktion von Hardware und Software, die Adaptierung der Fertigungsprozesse, Änderungen im operativen Vorgehen und erneute Zertifizierungen [WECK UND BOUNOVA 2007, S. 7]. Dabei können übersehene Abhängigkeiten von einem geänderten Element später im Prozess zu sehr kostenintensiven Nacharbeiten führen [KELLER ET AL. 2005, S. 1]. Generell kann festgehalten werden: je später die Notwendigkeit einer Änderung erkannt wird, desto teurer können die entsprechenden Anpassungen werden [ECKERT ET AL. 2004, S. 7; EIGNER UND STELZER 2009, S. 16]. Im Rahmen dieser Arbeit lehnt sich die Bedeutung des Begriffes Änderungsmanagement an die Definition von TERWIESCH UND LOCH an, wonach das Änderungsmanagement ein Prozess ist, bei dem Modifikationen oder Erweiterungen an Artefakten vorgenommen werden, die an einem Punkt des Produktlebenszyklus bereits freigegeben waren [TERWIESCH UND LOCH 1999]. Dabei kann die Modifikation auch die Ursachen Hinzufügen und Löschen von Inhalten beinhalten. 166

196 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte Für den Ablauf des Änderungsprozesses selbst gibt es unterschiedliche Vorgehensmodelle. Für die weiteren Ausführungen innerhalb dieser Arbeit wird das Modell aus [JARRATT ET AL. 2004] übernommen, das in Anlehnung an die ISO [ISO 10007:2003] entwickelt wurde: Schritt 1: Schritt 2: Schritt 3: Schritt 4: Schritt 5: Identifikation der Notwendigkeit einer Änderung, Bewertung der potentiellen Auswirkungen dieser Änderung, Freigabe der Änderung, Umsetzung der Änderung, Überprüfung der Änderung. Dabei ist Schritt 2, die Bewertung der potentiellen Auswirkungen dieser Änderung, die kritischste Phase in jedem Änderungsprozess [JARRATT ET AL. 2004]. Aus diesem Grund wird im weiteren Verlauf dieses Kapitels der Schwerpunkt der Betrachtungen auf der Fragestellung liegen, inwiefern die Analyse der Auswirkungen potentieller Änderungen auch bei mechatronischen Produkten durch Traceability-Informationen unterstützt werden kann. Die unterschiedlichen Phasen des Änderungsprozesses sollten ebenfalls in der informationstechnischen Repräsentation, also innerhalb der Softwarewerkzeuge, eine Entsprechung finden. So können Datensätze in dem, in der Industrie verbreiteten, Werkzeug IBM DOORS folgende Status zugewiesen bekommen: new, in review, approved, on hold, rejected, applied [IBM Corp. 2012b]. Dabei kann die Notwendigkeit für anfallende Änderungen je nach Prozessphase unterschiedlich sein. In [ECKERT ET AL. 2004, S. 6] ist eine Übersicht möglicher Änderungsgründe aufgeschlüsselt nach Prozessphasen beschrieben. Für die Spezifikation von Anforderungen wurden im Rahmen einer Studie bei einem Automobil-OEM bspw. folgende Gründe festgestellt [ALMEFELT ET AL. 2006, S. 123]: Erworbenes Wissen durch die Entwicklungsarbeit, Feststellung der Widersprüchlichkeit von Anforderungen, Technische Schwierigkeiten bei der Erfüllung ambitionierter Anforderungen, Möglichkeiten für Synergien, Unerwartete Forderungen nach Kostenersparnissen, Neue gesetzliche Anforderungen oder Veränderte Marktsituation u. a. bedingt durch unerwartete Wettbewerbssituation oder Kundenpräferenzen. Die Gründe für Änderungen werden häufig genutzt, um die Änderungsarten zu klassifizieren. So schlagen ECKERT ET AL. eine Klassifizierung vor, die einerseits in initiierte Änderungen, bedingt durch neue Kundenanforderungen und -bedürfnisse, sowie andererseits in entstehende Änderungen, die notwendig werden, um Schwachstellen im technischen System zu beheben, unterscheidet [ECKERT ET AL. 2004, S. 2]. 167

197 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte Unabhängig vom Grund der Änderung kann die Änderung eines Elements jedoch eine Kette oder ein Netzwerk an weiteren Änderungen notwendig machen [FRICKE ET AL. 2000, S. 170]. Dabei ist auch die Reihenfolge der Änderungen zu beachten [REN ET AL. 2004, S. 437]. Diese Fortpflanzung der Auswirkung einer Änderung wird bspw. von MARTIN UND ISHII im Kontext einer Automobilplattform beschrieben, wo die Änderung von funktionalen Anforderungen eine Vielzahl von Änderungen physischer Komponenten erforderlich machte [MARTIN UND ISHII 2002]. In komplexen Systemen, wo die einzelnen Subsysteme stark miteinander vernetzt sind, aber von unterschiedlichen Entwicklerteams erarbeitet werden, basieren Designentscheidungen einzelner Komponenten häufig auf Annahmen und Entscheidungen aus anderen Entwicklungsteams. Daher kann die Modifikation eines Subsystems auch die Änderung der Annahmen, der Modelle und schließlich der Lösungsausprägung anderer Entwickler erzwingen [WYNN ET AL. 2010b, S. 1692]. Aus diesem Grund ist darauf zu achten, dass alle Entwicklungsteams die Änderungskette nachvollziehen können und die Kommunikation zwischen den Teams unterstützt wird, damit diese auf aktueller Datenbasis arbeiten, um unnötige Mehrarbeit und Kosten zu reduzieren [FRICKE ET AL. 2000, S. 172]. In der Praxis sind diese Rahmenbedingungen meist nicht gegeben. JARRATT ET AL. und ECKERT ET AL. beschreiben jeweils ihre Beobachtungen der Änderungsprozesse in einem Unternehmen. Dabei wurden selbst erfahrene Entwickler von den Auswirkungen einzelner Änderungen überrascht, weil ihnen die Verknüpfungen einzelner Subsysteme zum restlichen Produkt nicht vollständig klar waren [JARRATT ET AL. 2004; ECKERT ET AL. 2004]. Diese Erkenntnisse ähneln den Beobachtungen von BIANCHI ET AL.: die von den Entwicklern als von der Änderung betroffen identifizierten Elemente waren zu einem überwiegenden Teil korrekt, jedoch nicht vollständig bestimmt worden [BIANCHI ET AL. 2000]. Dennoch haben FRICKE ET AL. und BIANCHI ET AL. in ihren Studien beobachtet, dass die Abschätzung der Auswirkungen von Änderungen in der industriellen Praxis zumeist auf Basis des Wissens und der Erfahrung einzelner Experten beruht [FRICKE ET AL. 2000, S. 174; BIANCHI ET AL. 2000]. Für diesen Vorgang gibt es aktuell kaum Softwareunterstützung, sodass diese Bewertung von den Experten manuell vorgenommen werden muss [ARNOLD UND BOHNER 1993, S. 295; JARRATT ET AL. 2004, S. 3]. Zukünftige Vorgehensmodelle und Werkzeuge sollten Entwickler daher bei Änderungen unterstützen [NG 2006, S. 372]. Da bei dieser Tätigkeit im Wesentlichen entschieden werden muss, welche Elemente aufgrund der Änderung angepasst werden müssen, gilt es zunächst, alle potentiell betroffenen Elemente zu identifizieren und anschließend die Notwendigkeit ihrer Modifikation zu bewerten [SOSA ET AL. 2005, S. 444]. Dabei muss berücksichtigt werden, dass jede Änderung fallspezifisch betrachtet werden muss [ECKERT ET AL. 2004, S. 13; WYNN ET AL. 2010b, S. 1700]. Für die informationstechnische Unterstützung ist es essentiell, eine elementare Erkenntnis zu berücksichtigen, die im Rahmen dieser Arbeit als valide postuliert wird: Änderungen pflanzen sich entlang der Tracelinks fort [SOSA ET AL. 2005, S. 444; EGYED ET AL. 2007, S. 122; WYNN ET AL. 2010b, S. 1693]. 168

198 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte Nutzt man die Traceability-Informationen für die Bewertung der Auswirkungen von Änderungen, wird das Änderungsmanagement unabhängiger vom Wissen einzelner Experten [AIZENBUD-RESHEF ET AL. 2006, S. 516]. Die Studien von FRICKE ET AL. und MOHAN ET AL. belegen jedoch, dass Entwickler in der Praxis derzeit keine ausreichende IT-Unterstützung bei der Bewertung von Änderungsauswirkungen erfahren [FRICKE ET AL. 2000, S. 174; MOHAN ET AL. 2008, S. 923]. Einige ERP-, PDM-, und PLM-Systeme bieten zwar grundlegende Funktionalitäten für das Änderungsmanagement an, jedoch umfassen diese keine Unterstützung für eine Auswirkungsanalyse [JARRATT ET AL. 2004, S. 3]. Aus der beschriebenen wesentlichen Bedeutung des Änderungsmanagements, der Schwierigkeit, die Folgen einer Änderung manuell korrekt abzuschätzen, und der mangelhaften Unterstützung durch derzeit verfügbare Softwarelösungen, lässt sich ein großer Bedarf an informationstechnischer Unterstützung für die Auswirkungsanalyse von Änderungen ableiten [LINDEMANN ET AL. 1998; HUANG UND MAK 1999; HUANG ET AL. 2003; JARRATT ET AL. 2004]. Die theoretischen Grundlagen für eine solche informationstechnische Unterstützung von Impact Analysen werden im folgenden Kapitel 6.2 vorgestellt THEORETISCHE GRUNDLAGEN DER IMPACT ANALYSE Bei der Entwicklung mechatronischer Produkte werden je nach Entwicklungsphase unterschiedliche Elemente in Artefakten zusammengefasst (siehe Kapitel 2.2). Die Gesamtmenge aller entwickelten Artefakte beschreibt wiederum umfassend das Produkt. Zentrales Anliegen der Auswirkungsanalyse im Änderungsfall ist jedoch die Zuordnung einzelner Elemente in die Kategorien betroffen bzw. nicht betroffen (siehe Abbildung 70), um den unnötigen Aufwand für die spätere Überprüfung nicht-betroffener Elemente zu minimieren. Abbildung 70: Schematische Darstellung der beiden Elementkategorien "betroffen" und "nicht betroffen" Die Analyse der Auswirkungen von Änderungen wird in der Literatur und daher auch im weiteren Verlauf der Arbeit als Impact Analyse bezeichnet. Einige der in der Literatur beschriebenen Definitionen werden im Folgenden diskutiert. 169

199 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte DEFINITIONEN ZUR IMPACT ANALYSE Erstmalig wurde dieses Vorgehen im Jahre 1986 als Untersuchung von Auswirkungen oder Ergebnissen einer Änderung am System beschrieben, um die Bestandteile der Änderung zu determinieren. [Rome Air Development Center 1986]. Diese noch recht vage Beschreibung wurde 1987 von PFLEEGER präzisiert. Es handele sich bei der Impact Analyse um [ ] eine Beurteilung der vielen Risiken, die mit einer Änderung einhergehen, u. a. eine Abschätzung der Auswirkungen auf Ressourcen, Aufwände und den Zeitplan [PFLEEGER 1987, S. 433]. Die Definition von ARNOLD UND BOHNER aus dem Jahr 1993 nimmt dann erstmals explizit Bezug auf die mögliche Nutzung von Tracelinks sowie die Identifikation von betroffenen Bauteilen. Laut ihrer Definition ist die Impact Analyse eine Aktivität, um zu identifizieren, entweder was zu modifizieren ist, um eine Änderung zu erreichen, oder was die potentiellen Konsequenzen dieser Änderung sind, wobei zur Identifikation der zu ändernden Elemente u. a. Tracelinks genutzt werden können [ARNOLD UND BOHNER 1993, S. 292]. Eine komprimierte und generische Formulierung schlagen QUEILLE ET AL. vor, die unter einer Impact Analyse die Aufgabe verstehen, die Auswirkungen einer Serie von Änderungen an einem System abzuschätzen [QUEILLE ET AL. 1994, S. 234]. BOHNER UND ARNOLD konkretisieren die Formulierung ihrer Definition aus dem Jahr 1993, indem sie den Begriff Entitäten wählen und von potentiellen Auswirkungen sprechen. Demnach identifiziert eine Impact Analyse alle Entitäten eines Systems, die potentiell von einer vorgeschlagenen Änderung betroffen wären [BOHNER UND ARNOLD 1996]. Inhaltlich ähnlich ist die Definition von FASOLINO UND VISSAGGIO. Demnach werden bei der Impact Analyse die Auswirkungen einer Änderungsanfrage als Grundlage für Abschätzungsaktivitäten erarbeitet. Das Hauptziel der Impact Analyse ist demzufolge die Identifikation von Elementen, die von dem Änderungsvorschlag betroffen wären [FASOLINO UND VISSAGGIO 1999, S. 58]. Die Definition aus [ABMA 2009] erweitert diese Beschreibung um die explizite Berücksichtigung von indirekten Folgen einer Änderung. Die Impact Analyse ist darin als eine Methode definiert, bei der alle Elemente identifiziert werden sollen, die als direkte oder indirekte Folge einer vorgeschlagenen Änderung geändert werden müssen. Viele Autoren betonen die Notwendigkeit, bei der Impact Analyse die Auswirkungen nicht nur innerhalb eines Artefakts, sondern ebenfalls auf alle weiteren relevanten Produktbeschreibenden Artefakte zu betrachten [PFLEEGER UND BOHNER 1990, S. 322; LINDVALL UND SANDAHL 1998b, S. 38; CIMITILE ET AL. 1999, S. 220; BIANCHI ET AL. 2000; SUTINEN ET AL. 2000, S. 316]. In ihrem technischen Report ISO/IEC TR 24766:2009 geht die International Organisation for Standardization noch einen Schritt weiter, indem sie feststellt, das primäre Ziel von Traceability wäre die Befähigung zu einer Artefakt-übergreifenden Impact Analyse [International Organisation for Standardization 2009, S. 16]. Auch wenn die aufgeführten Definitionen sich auf die Änderungen von Artefakten zur Beschreibung von Softwaresystemen beziehen, kann die Methode der Impact Analyse ebenfalls auf das Systems Engineering übertragen werden, da auch in dessen Verlauf eine Vielzahl Produkt-beschreibender Artefakte entwickelt werden, deren Elemente über Tracelinks miteinander verknüpft sind. Für den weiteren Verlauf der Arbeit wird Impact Analyse, ange- 170

200 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte lehnt an die vorgestellten Ausführungen aus [BOHNER UND ARNOLD 1996] und [ABMA 2009], so definiert, dass darunter eine Methode verstanden wird, bei welcher alle Elemente der Produkt-beschreibenden Artefakte eines Systems identifiziert werden, die potentiell von einer vorgeschlagenen Änderung direkt oder indirekt betroffen wären. Dabei erfolgt die Identifizierung der Elemente auf Basis von Tracelinks GRUNDBEGRIFFE DER MENGENLEHRE Im Kern handelt es sich bei der Impact Analyse um die Herausforderung, alle von einer Änderung potentiell betroffenen Elemente zu identifizieren. Die Gesamtmenge der Elemente aller für die Änderung relevanten Artefakte muss demnach in je eine Teilmenge der betroffenen und der nicht-betroffenen Elemente aufgeteilt werden. Für die mathematische Beschreibung dieser Zuordnung wird auf Begrifflichkeiten und Zeichen der Mengenlehre zurückgegriffen, die im Folgenden kurz erläutert werden. Die Ausführungen orientieren sich an [JENSEN 1967] und [DEISER 2010]. Eine Menge A, die sich aus einer Anzahl n einzelner Elemente a 1,.., a n zusammensetzt, wobei n Є N, wird durch A = {a 1,...,a n } beschrieben. Die Zugehörigkeit eines Elements zu einer Menge wird durch das Elementprädikat Є symbolisiert. Bei der Impact Analyse muss die Zugehörigkeit von Elementen aus mehreren Artefakten zur Teilmenge der betroffenen bzw. nicht betroffenen Elemente betrachtet werden. Diese generischen Artefakte werden im Folgenden durch die Mengen A und B repräsentiert, wobei jeweils A = {a 1,...,a n } und B = {b 1,...,b n }. Graphische Beschreibung Symbolische Beschreibung Verbale Beschreibung A B Eine Menge A wird Teilmenge einer Menge B genannt, wenn jedes Element von A auch Element von B ist. A B Die Schnittmenge von A und B ist die Menge der Elemente, die sowohl in A als auch in B enthalten sind. A B Die Vereinigungsmenge der zwei Mengen A und B enthält alle Elemente, die in der einen oder in der anderen Menge enthalten sind Tabelle 19: Grundbegriffe der Mengenlehre 171

201 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte Aufgrund des immensen Umfangs der bei der Impact Analyse zu betrachtenden Entwicklungsdaten, müssen die Entwickler dabei informationstechnisch unterstützt werden. Zu diesem Zweck müssen Methoden bereitgestellt werden, die potentiell betroffene Elemente vorschlagen. Dafür gibt es Klassifikationsmodelle, welche für jedes Element eine Vorhersage produzieren und diese formell einer Klasse zuordnen: {positive negative}. Positive repräsentiert dabei die Teilmenge der Elemente, welche der Algorithmus als potentiell von einer Änderung betroffen klassifiziert. Unter den vorgeschlagenen Elementen können sich Elemente befinden, die nicht von einer Änderung betroffen sind. Ebenso ist es theoretisch möglich, dass Elemente betroffen sind, die nicht in dem Vorschlag enthalten sind. Demzufolge ergeben sich vier mögliche Teilmengen (siehe Abbildung 71), in welche die Elemente der betrachteten Artefakte eingestuft werden können und die für den weiteren Verlauf der Arbeit von immenser Bedeutung sind: True positive (TP) = Elemente, die korrekterweise identifiziert wurden, False positive (FP) = Elemente, die fälschlicherweise identifiziert wurden, True negative (TN) = Elemente, die korrekterweise nicht identifiziert wurden und False negative (FN) = Elemente, die fälschlicherweise nicht identifiziert wurden. Abbildung 71: Teilmengen der identifizierten und tatsächlich betroffenen Elemente METRIKEN ZUR MESSUNG DER QUALITÄT VON IMPACT ANALYSEN Auf Basis dieser vier Teilmengen haben sich verschiedene Metriken zur Bewertung der Ergebnisqualität von Impact Analysen etabliert. LINDVALL UND SANDAHL haben ein Maß zur Messung der Effektivität von Impact Analysen definiert, die auf dem Vergleich der als potentiell betroffen identifizierten Elemente (Vereinigungsmenge aus TP und FP), zu den tatsächlich geänderten Elementen (Vereinigungsmenge aus TP und FN) beruht [LINDVALL UND SANDAHL 1998b]. Daraus kann unter Berücksichtigung der vier eingeführten Teilmengen der Quotient 172

202 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte abgeleitet werden. Je näher der Quotient sich dem Zahlenwert 1 nähert, desto effizienter ist die Impact Analyse. Ist der Zahlenwert deutlich größer als 1 bedeutet dies, dass eine Vielzahl an Elementen identifiziert werden, deren tatsächliche Änderung jedoch nicht notwendig ist. Die dargestellte Metrik betrachtet also die Fragestellung, wie korrekt die relevanten Elemente durch die entsprechende Impact Analyse identifiziert werden. Eine Schwäche dieser Metrik ist die Vernachlässigung der Fragestellung, ob alle zu ändernden Elemente durch die Impact Analyse vollständig identifiziert wurden. Diese Fragestellung sollte aber nicht ausgeblendet werden, da insbesondere hinsichtlich des Änderungsmanagements die Vollständigkeit von größerer Bedeutung als die Korrektheit ist [EGYED ET AL. 2007, S. 9]. Andere Metriken betrachten die Ergebnisse von Impact Analysen differenzierter. So wurden u. a. von FAWCETT Metriken eingeführt, die sowohl Aussagen hinsichtlich Korrektheit als auch Vollständigkeit erlauben [FAWCETT 2004]: Der Parameter Recall 78 ergibt sich aus dem Verhältnis der Anzahl der korrekterweise identifizierten Elemente und der Vereinigungsmenge der relevanten (also von der Änderung betroffenen) Elemente: Der Parameter Recall ist somit eine Messgröße für die Leistungsfähigkeit des Algorithmus, die relevanten Elemente vollständig zu identifizieren. Der Parameter Precision 79 ergibt sich aus dem Verhältnis der Anzahl der korrekterweise identifizierten Elemente und der Vereinigungsmenge aller identifizierten Elemente: Der Parameter Precision ist daher eine Metrik, um die Leistungsfähigkeit des Algorithmus hinsichtlich der Relevanz der gelieferten Ergebnisse zu bewerten. Der Parameter Accuracy berechnet sich aus dem Verhältnis der Vereinigungsmenge der korrekt klassifizierten Elemente zur Vereinigungsmenge aller Elemente: Der Parameter Accuracy ist somit eine Messgröße für die Leistungsfähigkeit des Algorithmus, die Elemente korrekt zu klassifizieren. Im folgenden Kapitel werden bereits existierende, in der Literatur beschriebene Impact- Analyse-Methoden sowie Studien zu deren Wirksamkeit weitestgehend chronologisch vorgestellt. 78 Der Parameter Recall wird in der Literatur auch mit den Synonymen true positive rate, hit rate oder sensitivity bezeichnet. 79 Der Parameter Precision wird in der Literatur auch mit den Synonymen positive predictive value oder specificity bezeichnet. 173

203 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte 6.3. EXISTIERENDE IMPACT-ANALYSE-ANSÄTZE - STAND DER WISSENSCHAFT Die Ursprünge der Impact Analyse liegen in der Softwareentwicklung. Daher werden in Kapitel zunächst die existierenden Ansätze aus dieser Disziplin vorgestellt. In Kapitel werden anschließend existierende Impact-Analyse-Ansätze für die Entwicklung technischer Systeme vorgestellt, bevor in Kapitel die vorgestellten Ansätze gemeinsam diskutiert werden IMPACT ANALYSE IN DER SOFTWAREENTWICKLUNG Pfleeger & Bohner 1990 [PFLEEGER UND BOHNER 1990] In [PFLEEGER UND BOHNER 1990] ist ein Vorgehen zur Impact Analyse in der Software- Entwicklung beschreiben, für welches sowohl Artefakt-interne als auch -übergreifende Tracelinks betrachtet werden müssen. Dabei werden vier Software-Artefakte betrachtet Anforderungen, Entwurf, Code und Test die in genau dieser logischen Sequenz betrachtet werden müssen. Konkret bedeutet dies, dass die Artefakt-übergreifenden Tracelinks ausschließlich unidirektional auf das logisch folgende Artefakt zeigen. Bei der beschriebenen Impact Analyse werden alle Artefakte als nicht-hierarchische Listen betrachtet, was nicht der Realität entspricht. Des Weiteren wird davon ausgegangen, dass jede Änderung von einer Anforderung ausgeht. Wie das Vorgehen adaptiert werden muss, wenn ein Element eines anderen Artefakts eine Änderung initiiert, ist nicht beschrieben. Auch der Umgang mit den Artefakt-internen Tracelinks erscheint wenig differenziert betrachtet. Turver & Munro 1994 [TURVER UND MUNRO 1994] TURVER UND MUNRO unterstreichen die Notwendigkeit, Änderungsauswirkungen auf Basis aller System-relevanten Artefakte insbesondere abstrakter Dokumentationen abzuschätzen. In dem vorgeschlagenen Ansatz wird die hierarchische Struktur der Artefakte berücksichtigt, was einerseits eine wesentliche Neuerung darstellt, und andererseits, wie in Kapitel beschrieben, von besonderer Relevanz für diese Arbeit ist. TURVER UND MUNRO schlagen vor, dass alle zu betrachtenden textuellen Software-Artefakte (bspw. Datenflussdiagramme oder Spezifikationen) in Form einer Baumstruktur hierarchisch aufgebaut werden und unter einem gemeinsamen Topknoten Bibliothek zusammengeführt werden. Es ergibt sich somit pro System ein einziger Baum, der alle relevanten Artefakte beinhaltet. In dem Baum werden jedem Blatt sog. Themen zugewiesen. Behandeln unterschiedliche Blätter das gleiche Thema, wird zwischen beiden Blättern ein Tracelink gesetzt. Die Identifikation der betroffenen Elemente erfolgt im Wesentlichen dadurch, dass zunächst alle Blätter bestimmt werden, die ein zu änderndes Thema beinhalten. Alle Elternelemente dieser Blätter, bis hin zur obersten Hierarchieebene, werden dann der Teilmenge der betroffenen Elemente hinzugefügt. Dadurch ergibt sich die Notwendigkeit, Tracelinks nur auf der untersten Ebene eines Artefaktes zu modellieren. Bei der Beschreibung des Umgangs mit der Hierarchie der Artefakte bzw. 174

204 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte der Frage, wie sich die Änderung entlang der hierarchischen Strukturen fortpflanzt, gibt es einige Unklarheiten. So wird zwar die transitive Natur der Artefakte eingeräumt, andererseits pflanzt sich die Änderung nur in Richtung des obersten Knotens fort. Dipartimento di Informatica, Università di Bari ab 1994 [ABBATTISTA ET AL. 1994; FASOLINO UND VISSAGGIO 1999; CIMITILE ET AL. 1999; BIANCHI ET AL. 2000] Eine Forschergruppe des Dipartimento di Informatica der Università di Bari hat eine Vielzahl von Arbeiten veröffentlicht, die sich mit der Impact Analyse im Rahmen von Softwareentwicklungsprozessen befassen. In [ABBATTISTA ET AL. 1994] wurde untersucht, wie die Ergebnisse einer Impact Analyse in Abhängigkeit von der bereitgestellten Analyseunterstützung variieren. Die Ergebnisse zeigen, dass die Impact Analyse mit Hilfe des bereitgestellten Traceability-Werkzeugs vollständiger und signifikant korrekter ausfällt als unter der ausschließlichen Verwendung der Standard-Dokumentation, wobei dafür andererseits mehr Zeit benötigt wird. In [FASOLINO UND VISSAGGIO 1999] und [CIMITILE ET AL. 1999] wird ein neuartiges Impact- Analyse-Vorgehen vorgestellt. Dabei wird eine Top-Down-Vorgehensweise beschrieben, bei der zuerst die abstrakten Elemente (wie bspw. Anforderungen oder Spezifikationen), die von der Änderung betroffen sein könnten, durch den Entwickler identifiziert werden müssen. In einem zweiten Schritt werden daraufhin alle Elemente identifiziert, welche über Tracelinks mit den zuvor bestimmten Elementen verbunden sind und auf die sich somit die Änderung potentiell fortpflanzen kann. Die Vereinigungsmenge aus beiden Schritten sind die potentiell betroffenen Elemente. Besonders kontrovers an dem beschriebenen Vorgehensmodell ist die Annahme, dass sich Änderungen nur in die Richtung fallender Abstraktheit fortpflanzen können. Aber auch die unscharfe Abtrennung der zu adressierenden Elemente zwischen dem ersten und dem zweiten Analyseschritt kann als Schwachpunkt der Vorgehensweise gesehen werden. In [BIANCHI ET AL. 2000] wird die Forschungsfrage behandelt, welchen Einfluss die Granularität der modellierten Traceability-Modelle auf die Qualität der Ergebnisse der Impact Analyse hat. Die Ergebnisse der Studie belegen, dass die Größe der Teilmengen, die im Rahmen der Impact Analyse identifiziert werden, von der Granularität des Traceability-Modells abhängen. So sind die notwendigen Aufwände zur Durchführung der Impact Analyse bei einem feingranularen Traceability-Modell wesentlich größer, die Anzahl der auftretenden Fehler ist jedoch geringer. BIANCHI ET AL. empfehlen daher, bei jeder Impact Analyse fallspezifisch zu entscheiden, welche Granularität zum Erreichen der gewünschten Ergebnisse notwendig ist [BIANCHI ET AL. 2000]. Lindvall & Sandahl ab 1996 [LINDVALL UND SANDAHL 1996, 1998b] LINDVALL UND SANDAHL unterstreichen in ihren Betrachtungen die Notwendigkeit, bei der Impact Analyse alle systembezogenen Artefakte zu betrachten. Thematisch untersucht der Beitrag, wie in einem Software-entwickelnden Industrieunternehmen Impact Analysen tatsächlich durchgeführt werden. Sie stellen dabei fest, dass die Entwickler hauptsächlich versu- 175

205 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte chen, durch persönliche Kommunikation mit erfahrenen Experten, die betroffenen Elemente zu identifizieren, anstatt die existierende Traceability-Dokumentation zu nutzen. Die Entwickler zeigten sich dabei überzeugt, dass durch das Vorgehen auf Basis des Erfahrungswissens alle betroffenen Elemente identifiziert würden. Die Ergebnisse der Studie widersprechen dieser Vermutung jedoch. Daher wird in [LINDVALL UND SANDAHL 1998b] die Notwendigkeit betont, auch im industriellen Umfeld eine Traceability-basierte Impact Analyse zu praktizieren, um eine vollständige Prognose der zu ändernden Elemente zu ermöglichen. Cleland-Huang & Chang & Christensen 2003 [CLELAND-HUANG ET AL. 2003] CLELAND-HUANG ET AL. konzentrieren sich in ihren Betrachtungen auf die Evolution der Software-Artefakte während der Entwicklungszeit. Konkret stellen die Autoren eine neue Impact- Analyse-Methode vor, die auf Ereignis-basierten Benachrichtigungen beruht. Dieser Ansatz verfolgt das Ziel, das kontinuierliche Veralten der Traceability-Daten über die Entwicklungszeit zu verhindern. Technologisch wird das erreicht, indem jede Veränderung an einem Element als ein Ereignis an einen Eventserver kommuniziert wird. Dieser leitet daraufhin die Benachrichtigung an alle verantwortlichen Entwickler von Elementen, die über Tracelinks mit dem geänderten Element verknüpft sind, weiter. Der Neuwert der vorgestellten Methode liegt in der Übertragung des Ereignis-basierten, automatisierten Benachrichtigungsmechanismus auf das Anwendungsszenario der Traceability im Änderungsmanagement. Alle vormaligen Ansätze postulieren, dass jedes Element, welches als von einer Änderung betroffen identifiziert wird, auch aktualisiert wird. Göknil & Kurtev & van den Berg 2008 [KURTEV ET AL. 2007; GÖKNIL ET AL. 2008; GÖKNIL ET AL. 2011] Die Ausführungen in [GÖKNIL ET AL. 2008] betrachten ausschließlich die Änderungsauswirkungen innerhalb des Anforderungsmanagements. Es wird also nur das Artefakt Anforderungen betrachtet, wobei mögliche Änderungsszenarien auf die Modifikation, das Hinzufügen und das Löschen entweder von Anforderungsbeschreibungen oder Tracelinks beschränkt werden. Als Grundlage der Impact-Analyse-Methode wird ein Metamodel definiert, das vier mögliche Arten der semantischen Relationen zwischen Anforderungen vorsieht. Entlang dieser Artefakt-internen Tracelinks erfolgt die Impact Analyse. In Abhängigkeit von der Art der Änderung (s.o.) und der Tracelinks definieren die Autoren Regeln, wie eine Änderung propagiert wird und welche Auswirkungen sich ergeben. Das Vorgehen wird an einem sehr kleinen und abstrakten Beispiel evaluiert, sodass dessen Wirksamkeit und Effizienz, wie auch die Autoren einräumen, nicht abschließend bewertet werden können IMPACT ANALYSE BEI DER ENTWICKLUNG MECHATRONISCHER SYSTEME Ho & Li (1997) [HO UND LI 1997] Die Ausführungen in [HO UND LI 1997] betrachten primär Fragen der Hierarchie von Produktstrukturen. Konkret wird mittels mathematischer Betrachtungen eines abstrakten Strukturbeispiels u. a. untersucht, ob die Hierarchietiefe eines Elements innerhalb der Produktstruktur 176

206 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte einen Einfluss auf die Wahrscheinlichkeit hat, von einer Änderung betroffen zu sein. Dabei kommen sie zu dem Ergebnis, dass die Hierarchietiefe eines Elements innerhalb der Produktstruktur lediglich einen vernachlässigbaren Einfluss hat. Betrachtet werden ausschließlich die Änderungspfade innerhalb eines hierarchischen Artefakts, die sich entlang der hierarchischen Relationen fortpflanzen. Mögliche Effekte durch andere Artefakt-interne oder -übergreifende Relationen werden nicht diskutiert. Für die Änderungsfortpflanzung entlang hierarchischer Relationen werden, abgesehen davon, dass Kinderelemente potentiell von einer Änderung des Elternelements betroffen sein können, keine Aussagen getroffen. Engineering Design Center, University of Cambridge ab 2004 [CLARKSON ET AL. 2004; ECKERT ET AL. 2004; JARRATT ET AL. 2004; KELLER ET AL. 2005; GIFFIN ET AL. 2009; WYNN ET AL. 2010b; Cambridge EDC 2012; AHMAD ET AL. 2012; KOH ET AL. 2012] Am Cambridge Engineering Design Center hat eine Forschungsgruppe die Change Prediction Method (CPM) entwickelt und im Werkzeug Cambridge Advanced Modeller (CAM) implementiert, um Auswirkungen von Änderungen analysieren und prognostizieren zu können. Bei der Anwendung der CPM werden zunächst die Abhängigkeiten zwischen den einzelnen Elementen der Produktstruktur in einer Abhängigkeitsmatrix modelliert. In einem nächsten Schritt werden jeder erfassten Abhängigkeit zwei Werte zugewiesen: die Wahrscheinlichkeit, mit der sich eine Änderung vom Quellelement auf das verknüpfte Zielelement fortpflanzt, und ein Wert, der die Stärke der Auswirkung angibt. Als Ergebnis kann für jedes zu ändernde Element ein probabilistischer Änderungspfad berechnet werden. Insgesamt wird jedoch empfohlen, mit der CPM maximal 50 Elemente zu betrachten [CLARKSON ET AL. 2004]. Ein generelles Defizit dieser Vorgehensweise ist die Tatsache, dass die Werte für die Wahrscheinlichkeit und Stärke der Änderungsfortpflanzung für das Produkt allgemein gelten sollen. Änderungen sind jedoch immer fallspezifisch zu betrachten [AHMAD ET AL. 2012], womit die Aussagekraft dieser pauschalierten Werte für einen konkreten Änderungsfall fraglich ist. Für die Methode Information Structure Framework (ISF) wurde die CPM weiterentwickelt und prototypisch in dem sog. CMSA 80 -Werkzeug implementiert [AHMAD ET AL. 2012]. Das Ziel der ISF ist es, ausgehend von einer Änderung eine Checkliste mit zu überprüfenden Objekten zu erstellen. Dazu sieht sie vor, dass zunächst vier Artefakte modelliert werden: nicht hierarchisch strukturierte Anforderungen, eine Funktionsstruktur, eine Produktstruktur und ein Prozessartefakt. Alle vier Artefakte werden für die Methode separat modelliert, genauso wie die Tracelinks innerhalb und zwischen diesen Artefakten. Für die Artefakt-übergreifenden Tracelinks gibt es die Vorgabe, dass nur Vorgänger- und Nachfolger-Artefakt (in der oben genannten Reihenfolge) verknüpft werden können. Auch in der ISF muss zudem ein Wert für die Wahrscheinlichkeit eine Änderungsfortpflanzung definiert werden. Diese Werte werden 80 Akronym für Change Management Support Approach, das eine Toolbox für den CAM darstellt 177

207 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte von der CPM genutzt, um unter Berücksichtigung der indirekten Abhängigkeiten zu berechnen, wie wahrscheinlich das Propagieren der betrachteten Änderung ist. Die ISF-Methode stellt somit ein Werkzeug zur Unterstützung der Artefakt-übergreifenden Impact Analyse dar. Die große Anzahl zu modellierender Artefakte, die nicht aus Autorenwerkzeugen eingelesen werden können, macht diese jedoch sehr aufwändig. Durch das starre Vorgehensschema wird das Erstellen aller vier Artefakte jedoch zwingend vorgegeben. Positiv zu bewerten ist, dass die Funktionen und die Produktstruktur teilweise hierarchisch aufgebaut werden können. Warum dies nicht auch für die Anforderungen möglich ist und welche Auswirkungen die hierarchischen Relationen auf die Änderungsfortpflanzung haben, wird nicht ausgeführt. In [KOH ET AL. 2012] wird eine weitere CPM-basierte Impact-Analyse-Methode beschrieben. Bei der sog. CPM-HoQ Methode geht es darum, die Auswirkungen von unterschiedlichen Änderungsvarianten hinsichtlich deren Einfluss auf die Erfüllung von Anforderungen zu bewerten. Dazu müssen fünf Matrizen manuell befüllt werden. Die CPM-HoQ sieht vor, die Abhängigkeiten innerhalb und zwischen den Artefakten Anforderungen, Änderungsalternativen und Produktelementen zu erfassen. Eine Aussage hinsichtlich des notwendigen Aufwands zur Durchführung der Methode wird nicht gegeben. Ebenso wenig wird beschrieben, wie die Entwickler damit umgehen, dass der gesamte Modellierungsaufwand dem Ziel dient, die von ihnen anfangs abgeschätzten Werte, wie gut welche Änderungsalternative welche Anforderung erfüllt, mittels eines automatisch berechneten Werts zu revidieren. Reddi & Moon (2009) [REDDI UND MOON 2009] In [REDDI UND MOON 2009] wird dargelegt, wie unterschiedlich sich Änderungen in Abhängigkeit des Änderungstyps fortpflanzen können. Die betroffenen Elemente werden gemeinsam mit ihren wesentlichen Eigenschaften aufgelistet. Dazu müssen Disziplin-übergreifende Teams für das vorliegende System wesentliche Eigenschaften sowie Tracelinks modellieren. Der Ansatz adressiert fertig entwickelte Produkte und damit ausschließlich Änderungen nach dem Produktionsbeginn. Bei der Modellierung der Abhängigkeiten müssen unterschiedliche Änderungstypen berücksichtigt werden. Zunächst müssen für jedes Element bzw. jede Eigenschaft die Abhängigkeiten, der entsprechende Änderungstyp und die Wahrscheinlichkeit der Änderungsfortpflanzung zu jeweils allen anderen Komponenten und Eigenschaften modelliert werden. Das Ergebnis der Methode ist die Auflistung der betroffenen Elemente in Abhängigkeit vom eingegebenen Änderungstyp. Eine Schnittstelle zu Autorensystemen existiert genauso wenig wie eine belastbare Aussage hinsichtlich der notwendigen Aufwände zur Durchführung der Methode. Zudem wird nicht theoretisch untermauert, warum der Änderungstyp über alle Analyseschritte jeweils gleich bleiben kann. 178

208 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte Fei & James & Owodunni & Tang (2011) [FEI ET AL. 2011a] In [FEI ET AL. 2011a] wird ein Ansatz vorgestellt, der auf einer Kombination mehrerer Abhängigkeitsmatrizen beruht und um eine Ontologie-basierte Wissensverwaltungskomponente ergänzt wurde, deren Ziel es ist, bestehende Änderungen mit der gespeicherten Änderungshistorie abzugleichen. Die Methode gliedert sich in drei wesentliche Schritte: Modellierung des Systems durch drei Artefakte 81, Auswirkungsanalyse mittels Abhängigkeitsmatrizen und wissensbasierte Lösung von Entwicklungskonflikten. Die vorgestellte Artefakt-übergreifende Methode überzeugt durch die Verwendung gängiger Notationen bzw. Softwarewerkzeuge, was einer tatsächlichen Anwendung im industriellen Kontext zuträglich ist. Es wird jedoch nicht begründet, warum nur bei den Komponenten die Artefakt-internen Relationen modelliert werden und warum ausschließlich diese als auslösendes Änderungselement vorgesehen sind. Interessant wäre ferner, ob das permanente Formalisieren des Wissens dauerhaft von den Entwicklern akzeptiert wird. Dennoch stellt die vorgestellte Impact-Analyse-Methode einen innovativen Mehrwert zum Stand der Technik dar. Alternative Impact-Analyse-Ansätze, auf die an dieser Stelle nicht detailliert eingegangen wird, sind u. a. [OLLINGER UND STAHOVICH 2004], [KÖHLER ET AL. 2008], [KOCAR UND AKGUNDUZ 2010] sowie [YANG UND DUAN 2012]. Für eine ausführliche Aufstellung aktueller Impact-Analyse-Ansätze wird zusätzlich auf [JARRATT ET AL. 2011] verwiesen ZUSAMMENFASSUNG UND DISKUSSION EXISTIERENDER IMPACT-ANALYSE- ANSÄTZE Die Analyse des Standes der Wissenschaft hat ergeben, dass zum Teil sehr unterschiedliche Begrifflichkeiten für die Teilmengen verwendet werden, die von den Impact-Analyse- Methoden identifiziert werden. Da diese Teilmengen jedoch für die Ausführungen im weiteren Verlauf der Arbeit von immenser Bedeutung sind, ist zunächst eine einheitliche Festlegung dieser Begrifflichkeiten notwendig. Aufgrund der sinnvoll differenzierten Inhalte der Impact-Analyse-Teilmengen wird die Terminologie an die in [BOHNER 2002] eingeführten Begriffe angelehnt. Für eine sinnhafte Anwendung im Systems Engineering muss deren Bedeutung leicht angepasst werden, sodass fortan folgende, im Rahmen der Arbeit oft verwendete Festlegung gilt: Starting Impact Set (SIS) bezeichnet die Teilmenge an Elementen, welche den Ursprung der Änderung bilden, demzufolge zu ändern sind und somit als Ausgangspunkt für die Impact Analyse dienen, 81 Funktionale Anforderungen (in einem SysML Blockdefinitionsdiagramm), Modell der physikalischen Interaktionen (in einem SysML Aktivitätsdiagramm) und Produktgeometrie (in einem CAD-System) 179

209 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte Candidate Impact Set (CIS) bezeichnet die Teilmenge an Elementen, die von der Änderung potentiell betroffen sind und auf Basis des SIS durch eine Impact Analyse identifiziert wurden (enthält somit alle TP + FP; vgl. Seite 172), False-Positive Impact Set (FPIS) bezeichnet die Teilmenge an Elementen, die fälschlicherweise dem CIS zugeordnet wurden, jedoch nicht tatsächlich betroffen sind (enthält somit alle FP), Discovered Impact Set (DIS) bezeichnet die Teilmenge, in der alle Elemente vereint sind, die bei der Impact Analyse nicht identifiziert wurden, damit kein Teil des CIS sind, aber trotzdem von der Änderung betroffen sind (enthält somit alle FN), Actual Impact Set (AIS) bezeichnet die Teilmenge an Elementen, die aufgrund der durchgeführten Änderung tatsächlich modifiziert werden mussten (enthält somit alle TP + FN). Inhaltlich ergab die Literaturanalyse, dass wesentliche Teilaspekte der Impact-Analyse- Ansätze durchaus unterschiedlich behandelt wurden. Einige dieser Aspekte wie bspw. Anzahl und Art der zu betrachtenden Artefakte sowie der Umgang mit deren hierarchischer Struktur werden im Folgenden vergleichend diskutiert und analysiert. Obwohl eine Vielzahl der vorgestellten Impact-Analyse-Methoden aus dem Bereich der Software-Entwicklung stammt, sind viele der Erkenntnisse auf die Mechatronik übertragbar. So sollten in beiden Fällen alle Produkt-relevanten Artefakte betrachtet werden [FEI ET AL. 2011b]. Die Mehrheit der vorgestellten Ansätze wie bspw. die ursprüngliche CPM, berücksichtigt jedoch lediglich ein einzelnes Artefakt, was einer umfassenden Unterstützung des Änderungsmanagements abträglich ist, da, wie in Kapitel 6.1 beschrieben, allein durch Änderungen von Anforderungen ein erheblicher Anteil aller Änderungsvorgänge in anderen Artefakten verursacht wird. Diese Szenarien würden somit nicht berücksichtigt. Eine Besonderheit der Mechatronik liegt hingegen in der Art der Bewertung der Änderungsfortpflanzung. Kann (analog zu den Mechanismen der Tracelink-Modellierung) in der Software-Entwicklung die Fortpflanzung einer Änderung teilweise automatisiert bewertet werden, ist dies in der Mechatronik ein manueller Prozess, der auf der Erfahrung von Experten beruht. Vor diesem Hintergrund ist kritisch zu hinterfragen, ob die vollständige Parametrisierung der Traceability-Modelle zielführend ist, zumal deren Erstellung einen erheblichen manuellen Aufwand erfordert. Neben der aufwändigen Entscheidung, ob sich eine Änderung entlang eines Tracelinks fortpflanzt, müssen die bewertenden Experten beispielsweise bei der CPM zusätzlich quantitativ festlegen, wie wahrscheinlich und wie stark eine solche Fortpflanzung ausfällt. Diese Entscheidung ist jedoch nicht für einen konkreten Änderungsfall zu treffen, wie es in der Theorie empfohlen wird, sondern für alle potentiell möglichen Fälle gemittelt. Die durch dieses stochastische Vorgehen entstehende Unschärfe der Prognose auf die Wirksamkeit der Methode ist bislang nicht evaluiert worden. Diesem Risiko wird in [REDDI UND MOON 2009] begegnet, indem unterschiedliche Änderungsarten definiert und unterschiedliche Werte je Art festgelegt werden können. 180

210 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte Diese Herausforderung unterstreichen auch die Ergebnisse der Anwenderstudie in [AHMAD ET AL. 2012], wo zum Einen festgestellt wird, dass die konkreten Auswirkungen von Änderungen fallspezifisch untersucht werden müssen und zum Anderen ein interaktiver Aufbau eines Änderungspfades unter Einbeziehung der Entwickler einem automatisch generierten Pfad vorzuziehen ist. Dies wird unter anderem damit begründet, dass die Nutzer ein größeres Verständnis für die Änderung entwickeln, wenn sie ihre Auswirkungen schrittweise selbst beurteilen. In der Softwareentwicklung sind viele Artefakte nicht hierarchisch aufgebaut. Die Nichtberücksichtigung der hierarchischen Strukturierung der Artefakte kann daher für Vorgehensweisen der Software-Entwicklung toleriert werden. Aber auch keiner der vorgestellten Ansätze aus dem mechatronischen Umfeld spezifiziert konkret, wie mit hierarchischen Relationen in mehreren Artefakten umzugehen ist. Diese Fragestellung muss jedoch adressiert werden, wenn die Impact Analyse auf das Systems Engineering übertragen werden soll, da hier die meisten Artefakte in Inklusionshierarchien aufgebaut sind. Laut [HO UND LI 1997, S. 587] haben die meisten Produktstrukturen sogar mindestens fünf Hierarchielevel. Dadurch ergeben sich Fragestellungen wie bspw. mit auftretenden Wechselwirkungen innerhalb und zwischen den hierarchischen Artefakten umzugehen ist. Bei den meisten vorgestellten Vorgehensweisen lautet die Antwort auf diese Fragestellung entweder, dass sich Änderungen ausschließlich unidirektional in Richtung der Artefakte fortpflanzen, die später in der Entwicklung modelliert werden, oder dieses Problem wird überhaupt nicht betrachtet. Wird eine multidirektionale Wechselwirkung methodisch zugelassen, muss ebenfalls die Notwendigkeit einer maximalen Anzahl an Iterationszyklen diskutiert werden. Die einzigen dahingehenden Aussagen in der Literatur schlagen vor, dass der Änderungspfad azyklisch sein sollte, was jedoch den Beobachtungen in [WECK UND BOUNOVA 2007] und [GIFFIN ET AL. 2009] widerspricht. Wie erwähnt setzen sich nur sehr wenige Impact-Analyse-Ansätze in der Literatur mit der hierarchischen Natur der Artefakte auseinander. Lediglich [HO UND LI 1997] und [TURVER UND MUNRO 1994] liefern konkrete Ansätze. Diese beschränken sich jedoch in [HO UND LI 1997] auf mathematische Betrachtungen hinsichtlich des Einflusses von Hierarchietiefe und Kommunalität eines Elements in einer Produktstruktur. Eine Aussage, ob Änderungen sich in anderen Artefakten ähnlich ausbreiten oder wie mit mehreren betrachteten Artefakten umzugehen ist, wird nicht gegeben. TURVER UND MUNRO gehen bei ihren Betrachtungen auf die hierarchische Natur mehrerer zu betrachtender Artefakte ein. Allerdings schreibt ihr Vorgehensmodell eine Modellierung der Tracelinks ausschließlich auf der untersten möglichen Ebene eines Artefaktes vor [TURVER UND MUNRO 1994]. Das widerspricht jedoch der Anforderung einer möglichst flexiblen Granularität der Modellierung, wie sie zumindest im Bereich der Entwicklung mechatronischer Produkte vorzusehen ist, da hier die notwendigen manuellen Modellierungsaufwände deutlich größer sind als in der Software-Entwicklung (siehe Kapitel 3.4). Der Ansatz in [HO UND LI 1997] erlaubt zwar Änderungen auf einer höheren hierarchischen Ebene, es ist aber nicht beschrieben, wie sich diese Änderung auf direkte Elternelemente und über Artefakt-interne Tracelinks verknüpfte Elemente auswirkt. 181

211 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte Ferner unterscheidet sich das Entwicklungsvorgehen in der Industrie von den in der Theorie beschriebenen (siehe Kapitel 2.3). Eine Aussage, welche Artefakte betrachtet werden müssen, ist daher unternehmensspezifisch festzulegen, weshalb die Impact-Analyse-Methode hinsichtlich der Artefakttypen flexibel sein muss. Zudem ist die Mehrzahl der erstellten Artefakte hierarchisch aufgebaut. Eine umfassende Impact-Analyse-Methode für die Entwicklung mechatronischer Systeme muss demzufolge die folgenden hergeleiteten Anforderungen adressieren: Die betrachteten Artefakte sollen hierarchisch aufgebaut sein können, Die Anzahl der betrachteten Artefakte soll flexibel sein, Der Typ der betrachteten Artefakte soll flexibel sein, Die Abfolge der betrachteten Artefakte soll flexibel sein, Es sollen sowohl Artefakt-interne als auch Artefakt-übergreifende Tracelinks betrachtet werden können. In Tabelle 20 ist schematisch dargestellt, inwieweit die vorgestellten Methoden diesen Anforderungen genügen. Methode Hierarchie betrachtet AF 82 - typ flexibel AFanzahl flexibel AFsequenz flexibel AF-interne & -übergreifende Tracelinks Pfleeger & Bohner Turver & Munro ( ) ( ) ( ) - Università di Bari - ( ) - Cleland-Huang & Chang & Christensen Göknil & Kurtev & van den Berg Ho & Li CPM ( ) ( ) Reddi & Moon Fei & James & Owodunni & Tang ( ) Tabelle 20: Erfüllungsgrad der vorgestellten Ansätze hinsichtlich der Anforderungen aus der Mechatronik 82 Akronym AF steht hier für Artefakt 182

212 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte Keine der Methoden wird allen Anforderungen gerecht. Daher befassen sich die folgenden Kapitel mit der Entwicklung einer Impact-Analyse-Methode, die den hergeleiteten Anforderungen der Mechatronik Rechnung trägt. Das Ziel einer solchen Methode muss es zudem sein, eine änderungsspezifische Sicht auf den Graphen des Gesamtsystems zu generieren, um die Anzahl der manuell zu bewertenden Elemente zu reduzieren HYPOTHESE 2 ZUR IMPACT ANALYSE FÜR DIE ENTWICKLUNG MECHATRONISCHER PRODUKTE Es scheint möglich, eine Methode zu entwickeln, welche, unter Berücksichtigung der Erkenntnisse aus der Software-Entwicklung sowie der Besonderheiten der Entwicklung mechatronischer Produkte, eine wirksame Impact Analyse auch im mechatronischen Kontext erlaubt. Das führt zu der folgenden Hypothese: Mittels einer Tracelink-basierten Impact-Analyse-Methode zwischen mehreren hierarchischen, ein mechatronisches Produkt beschreibenden Artefakten, können die von einer Änderung betroffenen Elemente dieser Artefakte identifiziert werden. Die Herleitung einer solchen Impact-Analyse-Methode ist im Kapitel 6.5 beschrieben. Die Verifikation der Hypothese erfolgt mittels einer vergleichenden, deskriptiven Nutzerstudie, deren Ergebnisse in Kapitel 6.6 vorgestellt werden HERLEITUNG EINER IMPACT-ANALYSE-METHODE FÜR DIE ENTWICKLUNG MECHATRONISCHER PRODUKTE Die theoretischen Grundlagen, die bisher existierenden Methoden sowie die Anforderungen an eine Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte wurden im bisherigen Verlauf des Kapitels 6 aufgezeigt. Es wurde dargelegt, dass eine automatische Bewertung, ob ein Element von einer Änderung tatsächlich betroffen ist, in diesem Kontext weder sinnvoll noch möglich ist. Der Anspruch an eine solche Methode muss es demnach sein, eine möglichst korrekte und vollständige Menge an Elementen zu identifizieren, die von einer Änderung potentiell betroffen sein können, um den bewertenden Experten ein effizientes Arbeiten zu ermöglichen. Der Vollständigkeit ist dabei eine höhere Priorität gegenüber der Korrektheit einzuräumen GRUNDANNAHMEN ZUR IMPACT-ANALYSE-METHODE Bei der Impact Analyse erfolgt die Identifikation der betroffenen Elemente generell über Tracelinks, deren Vollständigkeit und Korrektheit hier als idealisierte Grundlage der Methode vorausgesetzt wird. Es ist zu berücksichtigen, dass die Tracelinks auf jeder hierarchischen Ebene eines jeden Artefakts modelliert sein können, um den Entwicklern eine möglichst große Flexibilität bei der zu wählenden Granularität einzuräumen. Des Weiteren kann das zu ändernde Element ebenfalls einer beliebigen hierarchischen Artefaktebene angehören. 183

213 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte HIERARCHISCHE TRANSITIVITÄT BEI DER IMPACT ANALYSE Es muss betrachtet werden, wie sich die hierarchischen Relationen bei einer Impact Analyse verhalten. Dabei muss ausgehend von einem Element zwischen den beiden Relationsarten unterschieden werden, die einerseits zu einem hierarchisch höheren sowie andererseits zu einem hierarchisch tieferen Element führen. Um zu klären, über welche der beiden Relationsarten sich eine Änderung potentiell fortpflanzt, muss erneut auf die hierarchische Transitivität der involvierten Artefakte eingegangen werden. In Kapitel wurde dargelegt, dass Elternelemente mindestens die Vereinigungsmenge aller Eigenschaften ihrer Kinder enthalten. Sie repräsentieren die Eigenschaften ihrer Kinder auf einer abstrakteren Ebene. Wird die Eigenschaft eines Elementes geändert, ändert sich somit die entsprechende Eigenschaft des Elternelements automatisch mit. Eine separate Betrachtung des Elternelements ist demzufolge nicht zwingend notwendig 83. Es kann notwendig werden, dass auch andere Eigenschaften, die das Elternelement repräsentiert, modifiziert werden müssen. Auslöser dafür wären bspw. die Änderung eines weiteren Kindelements oder die Änderung eines Elements, welches über einen Tracelink direkt mit dem betreffenden Elternelement verbunden ist und somit die Änderung direkt auf das Elternelement propagiert. Diese Szenarien werden in der Impact-Analyse-Methode separat erfasst. Ferner ist zu berücksichtigen, dass Elternelemente ebenfalls alle Links ihrer Kinder tragen (auch wenn diese eventuell formell aufgelöst wurden, wie bei der Methode EcoTracing in Kapitel 3.6 beschrieben). Ein paralleles Verfolgen dieser Links würde jedoch lediglich redundante Informationen liefern, weshalb auch aus diesem Grund keine separate Betrachtung der Elternelemente notwendig wird. Zusammenfassend kann daher festgehalten werden, dass sich Änderungen, durch die Transitivität der Artefakte, über hierarchische Relationen nicht automatisch von einem konkreteren zu einem abstrakteren Element fortpflanzen. Umgekehrt beinhalten die Kindelemente unterschiedliche Teilmengen der Eigenschaften des Elternelements. Wird eine Eigenschaft des Elternelements geändert, kann in einem qualitativen Traceability-Modell nicht automatisiert detektiert werden, welches der Kindelemente diese Eigenschaft repräsentiert. Daraus folgt, dass alle Kindelemente bezüglich der Änderung überprüft werden müssen sie werden daher alle der Menge der potentiell betroffenen Elemente (CIS) hinzugefügt. Aus der Berücksichtigung der hierarchischen Transitivität ergibt sich somit eine Variation der Vorgehensweise (siehe Abbildung 72): hierarchische Relationen in Richtung zunehmender Abstraktheit propagieren keine Änderungen (Elternelemente sind nicht betroffen), während hierarchische Relationen in Richtung abnehmender Abstraktheit Änderungen propagieren (alle Kindelemente sind potentiell von der Änderung betroffen und müssen geprüft werden). 83 Bei der beschriebenen KFZ-Klimaanlage würde bspw. eine Änderung eines Verbindungskabels keine automatische Änderung der gesamten übergeordneten Baugruppe Klimasteuerung erforderlich machen. Wird das Verbindungskabel geändert, ändern sich die entsprechenden Eigenschaften der Klimasteuerung (Gewicht etc.) vielmehr automatisch mit. 184

214 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte Abbildung 72: Propagieren einer Änderung entlang hierarchischer Relationen (geändertes Element jeweils rot grundiert) BERÜCKSICHTIGUNG DER FLEXIBLEN TRACELINK-MODELLIERUNGSTIEFE BEI DER IMPACT ANALYSE Wie in Kapitel 3.4 beschrieben, ist es den Entwicklern freigestellt, ob sie die Tracelinks immer bis zur tiefsten Hierarchieebene eines Artefaktes ausmodellieren oder ob es ggf. ausreichend ist, für bestimmte Artefakte oder Teilsysteme auf einer höheren Artefaktebene zu verbleiben. Angenommen wird jedoch eine Top-Down-Vorgehensweise bei der Modellierung der Tracelinks (siehe Kapitel 3.6). Dadurch kann es vorkommen, dass Tracelinks, die ein konkretes Element betreffen, tatsächlich nicht von diesem, sondern aufgrund der wenig granularen Tracelink-Modellierung von einem seiner Elternelemente ausgehen (siehe Kapitel 2.2.6). Wäre das betreffende Element samt all seiner Geschwisterelemente hinsichtlich dieser Abhängigkeit schon überprüft (und damit verknüpft) worden, wäre der Tracelink zum Elternelement hingegen bereits aufgelöst (siehe Kapitel 5.4). Es muss demzufolge bei jedem Element E, das im Rahmen der Impact Analyse als potentiell von einer Änderung betroffen identifiziert wird, überprüft werden, ob eventuell von einigen seiner Elternknoten Tracelinks ausgehen. Werden diese übergeordneten Tracelinks gefunden, müssen sie betrachtet werden, da bisher nicht überprüft wurde, ob diese eigentlich E adressieren. Die derart identifizierten Elternelemente E Par sind nicht notwendigerweise selbst von der Änderung betroffen, müssen also nicht der Teilmenge CIS hinzugefügt werden, sondern propagieren nur die Änderung über die Tracelinks, die eventuell für E relevant sein könnten. Solche Elemente, die nicht selbst von der Änderung betroffen sind, sondern berücksichtigt werden, weil über einen von ihnen getragenen Tracelink die Änderung propagieren könnte, werden fortan Propagates genannt. Damit wird das Vorgehen zur Durchführung der Impact Analyse, wie in Abbildung 73 abgebildet, erweitert: das betroffene Element E (hier die Anforderung A1.1.2) hat ein verknüpftes Elternelement E Par (hier A1.1), dessen Tracelink die Änderung auf die Funktion F1.2 propagiert (wird damit CIS hinzugefügt), obwohl A1.1.2 selbst nicht mit F1.2 verknüpft ist. 185

215 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte Abbildung 73: Propagieren einer Änderung über verknüpftes Elternelement IMPACT-ANALYSE-METHODE FÜR DIE ENTWICKLUNG MECHATRONISCHER PRODUKTE Wird im Rahmen der Produktentwicklung ein Element geändert, müssen Auswirkungen auf andere Elemente desselben und anderer Artefakte betrachtet werden [AHMAD ET AL. 2012]. In Kapitel 6.1 wurde der Ablauf eines typischen Änderungsprozesses vorgestellt und erläutert, warum insbesondere die Identifikation und Bewertung der potentiell von der Änderung betroffenen Elemente dabei kritisch sind. In demselben Kapitel wurde beschrieben, dass die Notwendigkeit einer Änderung durch eine Vielzahl unterschiedlicher Gründe bedingt sein kann, was wiederum zu einem breiten Spektrum verschiedener Änderungsarten führt. Ferner können Änderungen Auswirkungen auf Elemente mehrerer Artefakte aus verschiedenen Disziplinen haben. Aufgrund dieser großen Vielfalt potentieller Änderungsszenarien besteht in der Literatur die einhellige Auffassung, dass jede Änderung fallspezifisch betrachtet [ECKERT ET AL. 2004, S. 13; WYNN ET AL. 2010b, S. 1700] und die endgültige Bewertung, ob ein verknüpftes Element von einer Änderung betroffen ist, einer menschlichen Entscheidung obliegen muss [ECKERT ET AL. 2004, S. 17; RIVIERE ET AL. 2003, S. 8f]. Weiterführende Ausführungen zum Thema Änderungsmanagement in Theorie und Praxis können [LINDEMANN UND REICHWALD 1998] bzw. [KALAWSKY ET AL. 2009] entnommen werden. In der konkreten Entscheidungssituation müssen die Entwickelnden zunächst abschätzen, ob das zu bewertende Element von der Änderung des Quellelements beeinflusst wird, mit dem es über einen Tracelink verbunden ist. Ist dies nicht der Fall, braucht dieses Zielelement nicht weiter betrachtet zu werden, wird der Menge der nicht-betroffenen Elemente zugeordnet und die Entscheidung dokumentiert. Ist das Zielelement jedoch von der Änderung des Quellelements betroffen, müssen die Entwickler entscheiden, ob die Beeinflussung innerhalb tolerabler Grenzen verläuft, und somit die Funktionalität oder die Qualität des späteren Produkts nicht beeinträchtigt, oder ob diese Grenzen durch die Änderung überschritten werden. Verläuft die Änderung in tolerablen Grenzen braucht das Zielelement nicht geändert zu werden und die obig genannten Schritte sind zu wiederholen. Muss das Zielelement jedoch tatsächlich geändert werden, ist es der Menge der betroffenen Elemente zuzuordnen. Die Entwickler müssen dann beraten, in welcher Form die Änderung vorzunehmen ist und die Änderungsaktivitäten planen. Ein Vergleich möglicher Änderungsalternativen zur Evaluierung unterschiedlicher Lösungsalternativen ist ebenfalls möglich und üblich. In jedem Fall ist die Be- 186

216 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte gründung der Entscheidung zu dokumentieren und die Aufforderung zur Änderung dem entsprechenden Verantwortlichen zuzuweisen. Da die Änderung wie beschrieben über mehrere Artefakte aus unterschiedlichen Disziplinen propagieren kann, sind bei umfassenderen Änderungsszenarien Experten aus unterschiedlichen Disziplinen bei der Entscheidungsfindung zu konsultieren. In den vorangegangen Kapiteln wurde beschrieben, welche Besonderheiten bei der Impact Analyse von mechatronischen Systemen zu beachten sind. Dazu wurde in Kapitel zunächst diskutiert, warum Impact Analysen in der Mechatronik primär auf menschlicher Expertise beruhen. Ferner wurde festgestellt, dass in der Entwicklung mechatronischer Systeme hauptsächlich hierarchische Artefakte generiert werden, weswegen die Besonderheiten der hierarchischen Artefakt-Strukturierung bei einer Impact-Analyse-Methode für die Mechatronik speziell berücksichtigt werden müssen. Aus diesem Grund trägt die Impact-Analyse-Methode der hierarchischen Transitivität der Artefakte Rechnung, sodass Änderungen nur entlang hierarchischer Relationen in Richtung steigender Detaillierung propagiert werden (siehe Kapitel 6.5.2). Da die Erfassung der Tracelinks in der Mechatronik ein manueller Prozess ist, werden Tracelinks in der Praxis häufig nicht bis auf die detaillierteste Artefaktebene modelliert. Eine Impact-Analyse-Methode für die Mechatronik muss daher zusätzlich die Flexibilität der Traceability-Modellierungstiefe berücksichtigen. Aus diesem Grund wurde in Kapitel eine Vorgehensweise erarbeitet, welche es ermöglicht, dass trotz unterschiedlich detailliert modellierter Tracelinks alle potentiell betroffenen Elemente von der Impact- Analyse-Methode identifiziert werden. Werden alle genannten Spezifika berücksichtigt, ergeben sich die folgenden Schritte zur Durchführung einer Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte: 1. Festlegung der zu betrachtenden Artefakte. Die Anzahl der Artefakte ergibt sich zu n ( N). Der Zähler i ( N) für die Anzahl der durchlaufenen Impact-Analyse-Stufen ergibt sich zu Identifikation des zu ändernden Elements E. 3. Ergänze E zur Menge der Propagates: Menge aus Elementen, welche die Änderung potentiell propagieren, weswegen deren Tracelinks im weiteren Verlauf der Analyse nachverfolgt werden müssen. 4. Identifikation aller E Par : Elternelemente von E, die einen Tracelink aufweisen. Ergänze alle E Par zur Menge Propagates. 5. Identifikation aller Kindelemente E Child von E. Alle E Child können potentiell von der Änderung betroffen sein. 6. Manuelle Bewertung aller E Child durch Experten. Ist ein E Child von der Änderung betroffen, wird es zu den Teilmengen TP und Propagates hinzugefügt und aus der Menge E Child entfernt. Ist ein E Child nicht betroffen, wird es der Teilmenge FP hinzugefügt, aus der Menge E Child entfernt und nicht weiter betrachtet. 7. Vergleich. Bei negativem Ergebnis wird die Impact Analyse beendet. Bei positivem Ergebnis wird die Impact Analyse mit dem nächsten Schritt fortgesetzt. 187

217 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte 8. Identifikation aller Elemente E Linked : Elemente die über einen Tracelink mit einem Propagate verknüpft sind. Sind keine E Linked vorhanden, ist die Impact Analyse beendet. 9. Manuelle Bewertung aller E Linked durch Experten. Ist ein E Linked von der Änderung betroffen, wird es zu der Teilmenge TP hinzugefügt. Ist ein E Linked nicht betroffen, wird es der Teilmenge FP hinzugefügt, aus der Menge E Linked entfernt und nicht weiter betrachtet. 10. Die Menge der verbliebenen E Linked ergibt sich zu E. 11. Initialisierung der Mengen Propagates, E Linked, E Child und E Par. 12. Inkrementelle Erhöhung von i. 13. Wiederholung aller Schritte beginnend bei Schritt 3. In einem algorithmischen Ablaufdiagramm kann die beschriebene Methode, wie in Abbildung 74 dargestellt, beschrieben werden. Bei dem abgebildeten Ablaufdiagramm ist (aus Gründen der besseren Lesbarkeit) die Entscheidung, ob ein Element von der Änderung betroffen ist, nur für jeweils ein Element einer Kategorie dargestellt. Abbildung 74: Algorithmisches Ablaufdiagramm der entwickelten Impact-Analyse-Methode 188

218 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte Diese Entscheidung und die direkt daraus resultierende Folgeaktivität (beide im Ablaufdiagramm durch ein gelbes Sternsymbol markiert) müssen in der tatsächlichen Umsetzung jedoch solange wiederholt werden, bis alle Elemente der jeweiligen Kategorie bewertet wurden. Erst danach kann die folgende Aktivität ohne Sternsymbol begonnen werden. Diese beiden Zyklen aus Betroffenheitsentscheidung und direkt resultierender Folgeaktivität sind daher in einer Schleife zu implementierten, was jedoch die Übersichtlichkeit des Diagramms zu stark eingeschränkt hätte ZUSAMMENFASSUNG UND DISKUSSION In den vorherigen Kapiteln wurde eine Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte vorgestellt, die sowohl den bisherigen etablierten Methoden aus der Software-Entwicklung als auch den Besonderheiten der Mechatronik (Transitivität der Artefakte und Flexibilität der Traceability-Modellierung) Rechnung trägt. Allgemein wird empfohlen, die ermittelten Elemente, die potentiell von einer Änderung betroffen sind, zu einem möglichst frühen Zeitpunkt zu betrachten. Idealerweise erfolgt dies zwischen den einzelnen Stufen der Impact Analyse, um dadurch die Anzahl der zu betrachtenden Elemente signifikant zu reduzieren schließlich propagiert ein verworfenes Element keine Änderung in den nächsten Iterationszyklus. Ungeachtet dessen kann der Zeitpunkt für die manuelle Bewertung flexibel gewählt werden: es können auch zunächst alle Stufen der Impact Analyse durchlaufen werden, um erst ganz am Ende alle als potentiell betroffen identifizierten Elemente (CIS) zu bewerten. Vorgeschlagen wird die Durchführung einer solchen Impact Analyse im Rahmen von Designreviews. Dort sind die entsprechenden Experten aus unterschiedlichen Disziplinen versammelt, die über potentielle Auswirkungen der Änderung auf ihre jeweiligen Subsysteme befinden können. Nur auf Basis dieser Expertise ist eine holistische Betrachtung der Änderungsfacetten und damit eine fundierte Entscheidungsfindung hinsichtlich der Änderungsalternativen möglich. Natürlich ist es nicht ratsam, jede triviale Änderung in einer solchen Expertenrunde betrachten zu lassen. Die dafür aufgebrachten Ressourcen würden den Nutzen zweifellos übersteigen. Für essentielle Änderungen mit erheblichen, nicht lokal begrenzten Auswirkungen erscheint eine Konsultation unterschiedlicher Experten aber sinnvoll. Dieses Vorgehen ermöglicht es, die Auswirkungen richtig abschätzen, alle Beteiligten frühzeitig über die Änderung informieren, deren Folgen ggf. begrenzen und diesbezüglich klare Vereinbarungen treffen zu können. In einem nächsten Schritt muss die Wirksamkeit des entwickelten Impact-Analyse- Algorithmus evaluiert werden. Diese Bewertung erfolgt mittels einer Nutzerstudie, deren Inhalt im folgenden Kapitel vorgestellt wird. 189

219 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte 6.6. NUTZERSTUDIE WIRKSAMKEIT DES IMPACT-ANALYSE-ALGORITHMUS Ziel der vorgestellten Nutzerstudie ist es, die Hypothese aus Kapitel 6.4 zu verifizieren, um somit die vorgestellte Impact-Analyse-Methode evaluieren und Aussagen hinsichtlich ihrer Wirksamkeit und Gültigkeit treffen zu können. Dazu wird eine vergleichende, deskriptive Nutzerstudie und ihre Ergebnisse vorgestellt, bei der die Teilnehmer für ein gegebenes Beispielmodell eines Fahrrads sowohl ein eigenes Tracelink-Modell aufbauen als auch unabhängig davon die von einer Änderung betroffenen Elemente dieses Modells benennen müssen STUDIENTEILNEHMER UND -MATERIALIEN An der Studie haben 19 Probanden teilgenommen (alle männlich, Durchschnittsalter 28,8 Jahre). Die Teilnehmer waren studentische Hilfswissenschaftler und wissenschaftliche Mitarbeiter der Fachrichtungen Mechatronik, Maschinenbau, Informationstechnik im Maschinenwesen, Informatik, Wirtschaftsingenieurwesen und Telematik. Alle Studienteilnehmer hatten zudem eine ingenieurtechnische Vorbildung. Die Durchführung der ersten Aufgabe, das Modellieren der Tracelinks, erfolgte am Rechner mit Hilfe des EcoTracing-Prototyps (siehe Kapitel 3.6). Für die Bearbeitung eines weiteren Aufgabenkomplexes erhielten die Studienteilnehmer für jede der drei darin beinhalteten Aufgaben einen Ausdruck, auf dem drei hierarchische Artefakte in Listenform ohne Tracelink- Informationen aufgeführt waren. Auf den Ausdrucken sollten jeweils die von einer Änderung betroffenen Elemente der drei Artefakte markiert werden. Die Produkt-beschreibenden, hierarchischen Artefakte Anforderungen, Funktionen und Produktstruktur des Beispielprodukts Fahrrad waren in Vorbereitung der Studie erstellt worden und wurden den Studienteilnehmern bereits komplett zur Verfügung gestellt. Das Anforderungsmodell beinhaltet 13 Anforderungen auf drei Hierarchieebenen, die Funktionsstruktur 20 Funktionen auf drei Hierarchieebenen und die Produktstruktur 29 Bauteile und Baugruppen ebenfalls auf drei Hierarchieebenen. Eine Übersicht der unverknüpften Artefakte kann Anhang A4 (Seite 304) und des verknüpften Gesamtmodells Anhang A1 (Seite 288) entnommen werden. Auf dem Ausdruck war die jeweilige Aufgabenstellung beschrieben, das geänderte Element farblich hervorgehoben. Die Elemente, die von der Änderung betroffen sind, sollten von den Studienteilnehmern mit einem Stift per Kreuz markiert werden. Vor Beginn der Studie haben alle Studienteilnehmer einen erläuternden Text mit einem einfachen Beispiel erhalten, der in die Thematik der Traceability-Modellierung sowie die Methode und das Werkzeug EcoTracing einführt. Auch zu den Inhalten der Modelle haben Studienteilnehmer detaillierte schriftliche und mündliche Erläuterungen erhalten. Nach der Durchführung der Aufgabenstellung wurden alle Studienteilnehmer gebeten, ihre Anmerkungen in einem Freitextfeld festzuhalten. 190

220 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte STUDIENDESIGN Das Studiendesign sah vor, dass jeder Studienteilnehmer zunächst für das vorgegebene Produktmodell ein Tracelink-Modell erzeugt. Analog zum Entwicklungsvorgehen in der Mechatronik wurden die Studienteilnehmer dabei angehalten, die Tracelinks so detailliert wie möglich zu modellieren, wobei die Wahl der Granularität schlussendlich freigestellt war. Der zweite Aufgabenblock sah vor, dass die Studienteilnehmer pro Aufgabe für ein vorgegebenes zu änderndes Element alle betroffenen Elemente der drei Artefakte manuell benennen müssen. Dazu wurden jeweils drei Änderungsaufgaben vorgegeben. Die Studienteilnehmer mussten in allen drei Aufgaben jeweils alle von der entsprechenden Änderung betroffenen Elemente markieren, wobei ihnen keine rechentechnische Unterstützung zur Verfügung stand. Bei den drei Aufgaben ging die Änderung jeweils von Elementen unterschiedlicher Artefakte aus. Die Reihenfolge der drei Aufgaben wurde so variiert, dass sich eine Gleichverteilung ergibt, um eine Beeinflussung der Ergebnisse durch eventuelle Lern- oder Erschöpfungseffekte minimieren zu können (within-subject Design). Für die Bearbeitung der Aufgaben gab es keine zeitliche Begrenzung. Während der Bearbeitung war es den Teilnehmern gestattet, Fragen an den Studienbetreuer zu richten. Im Nachgang wurde überprüft, ob die jeweils subjektiv als von der Änderung betroffen festgelegten Elemente, also das jeweils subjektiv identifizierte AIS, sich mit Hilfe der beschriebenen Impact-Analyse-Methode aus dem zugehörigen, in der vorherigen Aufgabe nach subjektivem Verständnis erzeugten Traceability-Modell ergeben hätten und somit in der Menge der als potentiell betroffenen identifizierten Elemente (CIS) enthalten waren. Aus den somit bestimmten Teilmengen für SIS, CIS, FPIS, DIS und AIS 84 können dann die Parameter Recall, Precision und Accuracy (siehe Kapitel 6.2.3) berechnet werden. Die vorgestellte vergleichende, empirische Nutzerstudie mit Innersubjekt-Faktor unter kontrollierten Bedingungen dient der Bestimmung der Wirksamkeit des Impact-Analyse- Algorithmus im mechatronischen Kontext. Zu diesem Zweck muss die deduktiv hergeleitete Hypothese aus Kapitel 6.4 verifiziert werden. Dies geschieht, indem in eine Nullhypothese abgeleitet wird, die dann zu falsifizieren ist. Die Hypothesen für die Wirksamkeit des Impact- Analyse-Algorithmus im mechatronischen Kontext lauten: Hypothese 2 H 2 : Mittels einer Tracelink-basierten Impact-Analyse-Methode zwischen mehreren hierarchischen, ein mechatronisches Produkt beschreibenden, Artefakten können von einer Änderung betroffene Elemente dieser Artefakte identifiziert werden. ( ) ( ) 84 Für die konkrete Definition dieser Teilmengen sei auf Seite 179 verwiesen. 191

221 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte Nullhypothese H 2-0 : Mittels einer Tracelink-basierten Impact-Analyse-Methode zwischen mehreren hierarchischen, ein mechatronisches Produkt beschreibenden, Artefakten können keine von einer Änderung betroffenen Elemente dieser Artefakte identifiziert werden. ( ) ( ) Die unabhängige Variable der Studie ist die Vorgehensweise zur Bestimmung der betroffenen Elemente mit zwei möglichen Ausprägungen: einerseits der Impact-Analyse-Algorithmus zur Ableitung des CIS auf Grundlage der zuvor subjektiv modellierten Tracelinks und andererseits das manuelle Bestimmen des subjektiven AIS durch die Studienteilnehmer. Die abhängigen, polytom diskreten Variablen ergeben sich somit zu dem algorithmisch ermittelten CIS respektive dem manuell bestimmten AIS. Zur Evaluierung der Wirksamkeit der Impact-Analyse-Methode werden unterschiedliche Messgrößen bei deren Durchführung erhoben: die Parameter Recall, Precision und Accuracy, wie sie in Kapitel beschrieben sind. Die Impact Analyse erfolgt an einem beispielhaften Produktmodell eines Fahrrads und wird von mehreren Probanden separat bearbeitet. Der entscheidende Parameter zur Überprüfung der Hypothese ist dabei Recall, der die Inklusion vom manuell bestimmten AIS in dem von der Impact-Analyse-Methode generierten CIS anzeigt GRUNDANNAHMEN Zwei Grundannahmen liegen der Studie zugrunde: 1. Jeder Studienteilnehmer modelliert das Tracelink-Modell, entsprechend seinem mentalen Modell des Beispielprodukts, subjektiv korrekt und vollständig. 2. Jeder Teilnehmer markiert in jeder Aufgabe jeweils die Elemente, die tatsächlich von einer Änderung betroffen sind, korrekt und vollständig, entsprechend seinem subjektiven, mentalen Modell des Beispielprodukts. Den zwei Postulaten kann entnommen werden, dass der subjektive Einfluss der Studienteilnehmer auf die Ergebnisse nicht unerheblich ist, da für die korrekte Ausführung der Aufgaben ein grundlegendes Verständnis des Beispielprodukts Fahrrad gegeben sein muss. Auf dieses Risiko wird im Rahmen der Ergebnisauswertung (siehe Kapitel 6.6.5) und -diskussion (siehe Kapitel 6.6.6) näher eingegangen DURCHFÜHRUNG Mit der Studie wurde begonnen, sobald jeder Studienteilnehmer die einführenden Texte gründlich gelesen hatte, das Verständnis von Modellinhalten sowie EcoTracing erklärt wurde, die Funktionsweise des EcoTracing-Prototypen am Computer mit einem einfachen, eingän- 192

222 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte gigen Beispiel ausprobiert wurde und die Teilnehmer keine offenen Fragen mehr vorgebracht haben. Die konkrete Aufgabenstellung zur Erstellung des Tracelink-Modells zwischen den drei Artefakten Anforderungen, Funktionsstruktur und Produktstruktur lautete: Erstellen Sie ein vollständiges Abhängigkeitsmodell für das Fahrradbeispiel. Laden Sie hierzu nacheinander die Kombinationen Anforderungsliste-Funktionsstruktur, Funktionsstruktur-Produktstruktur und Anforderungsliste-Produktstruktur in den EcoTracer und arbeiten Sie diese vollständig ab. Im direkten Anschluss bearbeiteten die Studienteilnehmer eine Aufgabe, die für diese Auswertung unbedeutend ist, aber dazu beitrug, dass die Probanden die konkreten Tracelinks weniger präsent memorieren konnten. Danach wurden jedem Teilnehmer drei Aufgaben gestellt, bei denen jeweils bestimmt werden musste, welche Elemente von einer konkreten Änderung betroffen sind. Die wörtliche Aufgabenstellung dafür lautete in allen drei Aufgaben: Markieren Sie in allen drei Artefaktlisten jedes Element, welches Ihrer Meinung nach von der Änderung des hervorgehobenen Elements betroffen ist, mit einem Kreuz. Aus den geschilderten Rahmenbedingungen ergeben sich eine Reihe von Charakteristika der Nutzerstudie, die in Tabelle 21 zusammengefasst sind. Hypothese Studienart Mittels einer Tracelink-basierten Impact-Analyse-Methode zwischen mehreren hierarchischen, ein mechatronisches Produkt beschreibenden Artefakten, können von einer Änderung betroffene Elemente dieser Artefakte identifiziert werden. Vergleichende, deskriptive Nutzerstudie im within-subject Design unter Laborbedingungen Anzahl der Teilnehmer 19 Analyseeinheit Methode zur Datenerfassung Zur Bewertung der Wirksamkeit der Impact-Analyse-Methode werden die Werte für die Parameter Recall, Precision und Accuracy aus den Teilmengen SIS, CIS, FPIS, DIS und AIS berechnet. Das Tracelink-Modell und die tatsächlich betroffenen Elemente (AIS) werden jeweils von den Probanden definiert. Der Ursprung der Änderung (SIS) ist durch die Aufgabenstellungen vorgegeben. Die Teilmengen CIS, FPIS, DIS werden nachträglich aus dem Tracelink-Modell, dem SIS und dem AIS abgeleitet. 193

223 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte Untersuchungsobjekt Analysemethoden Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte Teilnehmerspezifischer Vergleich der Elemente, die einerseits manuell dem AIS zugewiesen und sich andererseits über die Impact-Analyse-Methode aus dem gegebenen SIS sowie dem erzeugten Tracelink-Modell ergeben. Sind die Elemente, die über die Impact-Analyse-Methode bestimmt wurden, im AIS enthalten, ist die Nullhypothese falsifiziert. Tabelle 21: Charakteristika der Nutzerstudie Wirksamkeit des Impact-Analyse-Algorithmus ERGEBNISSE UND AUSWERTUNG Wie in Kapitel beschrieben, hängt die Validität der Ergebnisse stark vom subjektiven Verständnis des Beispielproduktes je Studienteilnehmer ab. Es stellt somit eine Störvariable dar. Daher ist es notwendig, eine qualitative Selektion der Ergebnisse vorzunehmen, um den Einfluss der Störvariablen subjektives Produktverständnis auf ihre Aussagekraft zu begrenzen. Aus diesem Grund wurden Kriterien definiert, die zu einem Ausschluss der jeweiligen Studienergebnisse von der Auswertung führen: I. Der Teilnehmer artikuliert im Verlauf der Studie signifikante Defizite im sprachlichen Verständnis; oder II. Der Teilnehmer hat eine Aufgabe während der Bearbeitung abgebrochen; oder III. Die Anzahl der markierten Elemente des AIS lag deutlich außerhalb der statistischen Standardabweichung, was die Plausibilität der Ergebnisse stark in Frage stellt. Das Ausschlusskriterium I führte dabei zur Nichtberücksichtigung aller Teilaufgaben, während bei den Kriterien II und III jeweils nur die betroffene Teilaufgabe nicht berücksichtigt wurde. In Tabelle 22 ist die Häufigkeit der Anwendung der jeweiligen Ausschlusskriterien abgebildet. Ausschlusskriterium I. II. III. Ausschlusshäufigkeit Tabelle 22: Häufigkeit der Anwendung der jeweiligen Ausschlusskriterien Die Auswertung der restlichen Teilaufgaben erbrachten je Proband die in Tabelle 24 dargestellten Teilmengen für TP, FP, TN und FN, wobei die nicht berücksichtigten Ergebnisse ausgegraut sind. Die Kriterien für eine Zuordnung eines Elements in die jeweilige Teilmenge sind in Tabelle 23 beschrieben. 194

224 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte TP TN FP FN Das betreffende Element ist sowohl in der Menge, der manuell als betroffen markierten (AIS), als auch in der Menge, der durch den Impact-Analyse-Algorithmus als potentiell betroffenen identifizierten (CIS), Elemente enthalten. Das betreffende Element ist weder in der Menge, der manuell als betroffen markierten (AIS), noch in der Menge, der durch den Impact-Analyse-Algorithmus als potentiell betroffenen identifizierten (CIS), Elemente enthalten. Das betreffende Element ist nicht in der Menge, der manuell als betroffen markierten (AIS), aber in der Menge, der durch den Impact-Analyse-Algorithmus als potentiell betroffenen identifizierten (CIS), Elemente enthalten. Das betreffende Element ist in der Menge, der manuell als betroffen markierten (AIS), aber nicht in der Menge, der durch den Impact-Analyse-Algorithmus als potentiell betroffenen identifizierten (CIS), Elemente enthalten. Tabelle 23: Zuordnungskriterien der Elemente Auf Basis der Teilmengen von TP, FP, TN und FN können nach den Formeln aus Kapitel die Metriken Recall, Precision und Accuracy berechnet werden: Die Übersicht über die aggregierten Ergebnisse der Nutzerstudie pro Teilnehmer und Teilaufgabe sind in Tabelle 24 dargestellt. 195

225 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte Proband Aufgabe TP FP FN TN Precision Recall Accuracy ,44 1,00 0, ,28 1,00 0, ,15 1,00 0, ,27 0,80 0, ,23 0,75 0, ,36 0,67 0, ,11 0,22 0, ,80 0,67 0, ,09 0,50 0, ,26 0,64 0, ,16 0,83 0, ,40 0,50 0, ,34 0,71 0, ,35 0,80 0, ,40 0,50 0, ,17 0,44 0, ,30 0,75 0, ,22 0,71 0, ,75 0,50 0, ,44 0,57 0, ,60 0,75 0, ,40 0,50 0, ,56 0,50 0, ,56 0,63 0, ,27 1,00 0, ,19 0,80 0, ,13 1,00 0, ,12 0,60 0, ,21 0,83 0, ,50 0,22 0, ,16 1,00 0, ,42 0,67 0, ,50 0,50 0, ,73 0,67 0, ,50 0,78 0, ,33 0,67 0, ,17 1,00 0, ,18 0,75 0, ,14 1,00 0, ,23 1,00 0, ,20 0,86 0,61 Tabelle 24: Ergebnisse der Nutzerstudie pro Teilnehmer und Teilaufgabe 196

226 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte Die Ergebnisse zeigen, dass die Impact-Analyse-Methode für alle Probanden in allen Aufgaben relevante Treffer erzeugt hat. Hinsichtlich der Vollständigkeit der Elemente, die tatsächlich von einer Änderung betroffen sind, also dem Parameter Recall, ergibt sich ein statistischer Mittelwert von 71,4 % bei einer Standardabweichung von 20,7 %. Aus den Einzelwerten in Tabelle 24 wird ersichtlich, dass in der überwiegenden Zahl der Aufgaben die entwickelte Impact-Analyse-Methode die meisten der als betroffen bewerteten Elemente identifiziert hat. Dennoch wurden nur bei neun Teilaufgaben alle AIS vollständig identifiziert. Mögliche Fehlerursachen werden in Kapitel diskutiert. Interessant ist jedoch die Auswertung eines aggregierten Modells. Unter einem aggregierten Modell wird im Rahmen der Auswertung dieser Studie ein Modell verstanden, welches lediglich Tracelinks und AIS-Elemente enthält, die von mindestens drei Teilnehmern identisch modelliert bzw. markiert wurden, wodurch der subjektive Einfluss der Ergebnisse reduziert werden soll. Bemerkenswert ist, dass für ein solches aggregiertes Modell der Recall-Wert der Impact- Analyse-Methode 100 % beträgt. Die Impact-Analyse-Methode identifiziert also auf Basis der modellierten Tracelinks alle als betroffen bewerteten Elemente. Für die Bewertung der Methode sind ferner die Parameter Precision und Accuracy interessant. Diese sind notwendig, um betrachten zu können, wie leistungsfähig die Methode hinsichtlich der Relevanz und der Korrektheit der erzeugten Treffer funktioniert. Aus dem Precision-Wert ist das Verhältnis der korrekt identifizierten zu allen identifizierten Elementen ablesbar. In der Nutzerstudie ergab sich für die Precision ein statistischer Mittelwert von 33,2 % bei einer Standardabweichung von 18,2 % über alle Teilnehmer und Teilaufgaben. Aus dem Accuracy-Wert ist das Verhältnis der korrekt klassifizierten (betroffen und nicht betroffen) zu allen Elementen ablesbar. In der Nutzerstudie ergab sich für die Accuracy ein statistischer Mittelwert von 74,5 % bei einer Standardabweichung von 16,7 % über alle Teilnehmer und Teilaufgaben. Eine Übersicht der Mittelwerte und zugehöriger Standardabweichung (SD) für die genannten Parameter, aufgeschlüsselt nach Teilaufgaben und Gesamtaufgabe, ist in Tabelle 25 dargestellt. Aufgabe Precision SD Recall SD Accuracy SD ,9 % 18,8 % 68,0 % 23,2 % 85,0 % 12,1 % ,7 % 16,9 % 74,8 % 19,0 % 62,5 % 17,5 % ,1 % 17,1 % 72,0 % 18,5 % 74,3 % 11,6 % Gesamt 33,2 % 18,2 % 71,4 % 20,7 % 74,5 % 16,7 % Tabelle 25: Übersicht der Mittelwerte und Standardabweichungen für die Messgrößen Precision, Recall und Accuracy 197

227 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte DISKUSSION UND SCHLUSSFOLGERUNG HINSICHTLICH DER WIRKSAMKEIT DES IMPACT-ANALYSE-ALGORITHMUS Trotz der qualitätssichernden Maßnahmen, die zum Ausschluss der Ergebnisse einzelner Teilaufgaben bzw. ganzer Probanden führten, ist nicht auszuschließen, dass subjektive Fehler der Studienteilnehmer bei der Modellierung, dem Verständnis oder der schriftlichen Erfassung dazu geführt haben, dass einzelne Elemente fälschlicherweise entweder im AIS enthalten sind oder nicht verlinkt wurden. Unterstützt wird diese These dadurch, dass zum einen alle Tracelink-Modelle unterschiedlich sind, zum anderen jedoch durch das aggregierte Modell 100% der betroffenen Elemente identifiziert wurden. Da auch in einer industriellen Anwendung mehrere Entwickler für die Erstellung und Wartung des Traceability-Modells verantwortlich zeichnen, ist dieses, von subjektiven Einzelmeinungen unabhängige, Aggregationsergebnis für eine spätere Anwendung sehr relevant. Zur Interpretation der in Kapitel vorgestellten Ergebnisse wird im Folgenden ein Klassifikationsschema genutzt, das auf den in [HAYES ET AL. 2006, S. 11] beschriebenen Intervallen zur Bewertung der Parameter Precision und Recall beruht. Das Klassifikationsschema ist in Tabelle 26 wiedergegeben. Parameter Akzeptabel Gut Exzellent Precision 20% - 29% 30% - 49% 50% - 100% Recall 60% - 69% 70% - 79% 80% - 100% Tabelle 26: Klassifikationsschema zur Interpretation der Parameter Precision und Recall (nach [HAYES ET AL. 2006, S. 11]) Die Ergebnisse für den Parameter Recall zeigen, dass durchschnittlich 71,4 % der als von einer Änderung betroffenen bewerteten Elemente mit Hilfe der entwickelten Impact-Analyse- Methode identifiziert wurden. Gemäß des Klassifikationsschemas in Tabelle 26 ist dies ein guter Wert. Gleiches gilt für den Precision-Wert von 33,2 %. Der Anspruch für jede Impact-Analyse-Methode muss dennoch sein, alle von einer Änderung betroffenen Elemente zu identifizieren. Denn schon das Übersehen einzelner Komponenten kann durch deren verspätet bemerkten Änderungsbedarf sehr kostspielig werden. Für das Nichterreichen der 100%-Marke bei einigen Teilaufgaben können verschiedene Einflussfaktoren eine Rolle spielen. Daher wird im Folgenden untersucht, wodurch die Abweichung von dem angestrebten Recall-Wert zustande kam. Zu diesem Zweck wurden die Ergebnisse der einzelnen Studienteilnehmer im Detail analysiert. Es gibt hauptsächlich drei Gründe, die zu einer Abweichung zwischen den manuell als tatsächlich betroffen markierten (AIS) und den über Impact-Analyse-Algorithmus und jeweiliges Tracelink-Modell als potentiell betroffen identifizierten (CIS) Elementen führten: I. Die Studienteilnehmer haben zusätzlich zu den konkreten Elementen, die von ihnen als von der Änderung betroffen markiert wurden, auch deren jeweiliges Elternelement 198

228 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte II. III. markiert 85. Die übergeordneten Elemente werden jedoch vom Algorithmus nicht automatisch als betroffen erfasst (Begründung siehe Kapitel 6.5.2). Daraus folgt, dass manuell als betroffen markierte, übergeordnete Elemente in der Auswertung als fälschlicherweise nicht betroffen (FN) gewertet werden mussten. Zwischen zwei inhaltlich abhängigen Elementen wurde ein offensichtlicher Tracelink nicht modelliert 86. In solch eindeutigen Fällen ist das Postulat 1 des korrekten Tracelink-Modellierens aus Kapitel gebrochen. Dennoch mussten die fälschlicherweise nicht verknüpften Elemente in der Auswertung als FN gewertet werden. Es wurden Elemente als betroffen eingestuft, bei denen eindeutig keine Änderung notwendig ist 87. In diesem Fall ist das Postulat 2 aus Kapitel gebrochen, wonach, basierend auf dem subjektiven, mentalen Modell, ausschließlich betroffene Elemente markiert werden dürfen. Auch in diesem Fall mussten die markierten Elemente bei der Auswertung dennoch der Klasse FN hinzugefügt werden. Die beiden letztgenannten Gründe II und III basieren auf subjektiven Fehlbewertungen der Studienteilnehmer. Sie sind dem Studiendesign immanent und stellen die Wirksamkeit des Algorithmus somit nicht in Frage. Grund I hingegen adressiert den inhaltlichen Aufbau des Impact-Analyse-Algorithmus und damit dessen Wirksamkeit. Die inhaltliche Analyse der einzelnen Probandenergebnisse hat jedoch die in Kapitel dargelegte Argumentation gestützt: werden die untergeordneten Elemente geändert, ändern sich aufgrund der immanenten Merkmalsrepräsentation ebenso die entsprechenden Eigenschaften der übergeordneten Elemente, weshalb deren separate Anpassung nicht notwendig ist. Der einzige Fall, in dem dieses Vorgehen fraglich war, ist das Hinzufügen einer neuen Funktionalität wie in Aufgabe 1 der Studie. Bei dieser Aufgabe wäre es erforderlich, für das geforderte automatische Einschalten der Beleuchtung eine Sensorik zur Ermittlung der aktuellen Lichtverhältnisse zu ergänzen. Da eine solche Sensorik vorher in der Produktstruktur nicht enthalten war, konnte sie auch nicht über die modellierten Tracelinks identifiziert werden. Daher haben viele Studienteilnehmer die übergeordnete Kategorie P1.7 Sonstige Komponenten als betroffen markiert. Doch selbst in dem geschilderten Fall wäre die Markierung des Elements P1.7.3 Beleuchtung hinreichend gewesen. Es ist davon auszugehen, dass der für die Beleuchtung zuständige Entwickler (über die Tracelink-Informationen) von der geänderten Anforderung einer automatischen Beleuchtung erfahren hätte und somit eine Beleuchtung mit integrierter Sensorik gewählt hätte. Es wäre also keine andere bestehende Sonstige Komponente von der Änderung betroffen gewesen. Daher ist auch in dem ge- 85 So wurden z. B. bei der geforderten Änderung von einer hydraulischen zu einer pneumatischen Federgabel nicht nur P1.2.1 hydraulische Federgabel und P1.2.4 Steuersatz als konkret betroffene Baugruppen, sondern zudem das übergeordnete System P1.2 Steuereinheit markiert. 86 Bei einem Studienteilnehmer war bspw. die Funktion F1.6 Federung / Dämpfung weder mit der konkreten Anforderung A1.4.1 Unebenheiten im Gelände und im Fahrbelag ausgleichen noch mit der übergeordneten Anforderung A1.4 geländetaugliche Federung und Übersetzung verknüpft. 87 Bei der geforderten Änderung die Beleuchtung am Fahrrad automatisch einzuschalten wurde das Bauteil P1.1 Rahmen als betroffen markiert. Dies ist inhaltlich nicht nachzuvollziehen. 199

229 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte schilderten Fall des Hinzufügens einer neuen Funktionalität ein generelles Überprüfen des übergeordneten Elements nicht zielführend. Werden alle Elemente, die wegen Grund I fälschlicherweise in der Menge der manuell als betroffen markierten Elemente (AIS) enthalten waren, und aus den erläuterten Gründen über den Algorithmus nicht identifiziert werden konnten, als korrekterweise nicht betroffen (TN) gewertet, ergeben sich für die Impact-Analyse-Methode leicht veränderte Ergebnisse. In Tabelle 27 sind die von Grund I bereinigten Ergebnisse zusammengefasst. Die aus den geschilderten Gründen II und III falsch bewerteten Elemente, sind in den bereinigten Ergebnissen jedoch weiterhin enthalten, weil das subjektive Verständnis der Probanden nicht nachträglich in Frage gestellt werden kann. Aufgabe Precision SD Recall SD Accuracy SD ,9 % 18,8 % 90,1 % 21,4 % 86,7 % 12,5 % ,7 % 16,9 % 86,9 % 12,6 % 64,9 % 18,6 % ,1 % 17,1 % 86,7 % 18,1 % 76,1 % 11,6 % Gesamt 33,2 % 18,2 % 88,0 % 18,0 % 76,4 % 17,0 % Tabelle 27: Übersicht der bereinigten Mittelwerte und Standardabweichungen für die Messgrößen Precision, Recall und Accuracy Die bereinigten Ergebnisse beeinflussen die Precision-Werte nicht. Sie bleiben unverändert, da zu ihrer Berechnung weder FN noch TN herangezogen werden. Die Accuracy-Werte hingegen verbessern sich leicht. Der Accuracy-Mittelwert für die Gesamtaufgabe beträgt bei den bereinigten Ergebnissen 76,4 %. Am deutlichsten verändert sich die Werte für den Parameter Recall. Der bereinigte Recall-Mittelwert von 88,0 % ist gemäß des Klassifikationsschemas in Tabelle 26 ein exzellenter Wert. Da als betroffen bewertete Elemente über den Impact-Analyse-Algorithmus identifiziert wurden, kann die Nullhypothese, wonach sich mittels der Impact-Analyse-Methode keine betroffenen Elemente identifizieren lassen, als falsifiziert betrachtet werden. Die Tatsache, dass im Rahmen der Studie 88,0 % der betroffenen Elemente identifiziert wurden, bestätigt eindeutig die Hypothese 2, wonach über die Impact-Analyse-Methode betroffene Elemente identifiziert werden. Dennoch kann die Wirksamkeit der entwickelten Impact-Analyse- Methode zunächst nur eingeschränkt festgestellt werden, da der angestrebte Recall-Wert von 100 % nicht erreicht wurde. Neben den zuvor beschriebenen Gründen I bis III sind dafür Studien-immanente Ursachen verantwortlich, die im Folgenden diskutiert werden. Die Auswertung der Ergebnisse offenbarte einen starken subjektiven Einfluss der Teilnehmer auf die erzeugten Tracelink-Daten. Dieser subjektive Charakter der konkreten Modellausprägung wird dadurch unterstrichen, dass alle 19 erzeugten Tracelink-Modelle unterschiedlich sind. Vor diesem Hintergrund war es methodisch die korrekte Wahl, die angegebenen AIS 200

230 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte nicht gegen ein Tracelink-SOLL-Modell zu vergleichen, sondern sowohl AIS als auch Tracelink-Modell jeweils auf Basis desselben subjektiven mentalen Modells abzugleichen. Ein Vergleich mit einem SOLL-Modell erscheint nur sinnvoll, wenn sowohl AIS als auch Tracelink-Modell von Personen mit einem annähernd identischen Verständnis des Produkts erzeugt werden. Solche Voraussetzungen sind hingegen bei langjährigen Experten eines Unternehmens gegeben, wodurch diese ein allgemein gültiges Traceability-Modell generieren können. Ein nächster Schritt in Richtung einer industriellen Anwendbarkeit sollte daher sein, diese Expertise im Rahmen einer industriellen Evaluierung zu nutzen. Ein weiterer möglicher Einflussfaktor betrifft die Tatsache, dass im Rahmen der Studie ausschließlich Artefakt-übergreifende Tracelinks betrachtet wurden. Da dennoch exzellente Werte für den Parameter Recall erzielt wurden, insbesondere beim aggregierten Modell, stellt sich die Frage der Notwendigkeit für die Einbeziehung von Artefakt-internen Tracelinks für die Anwendung der Impact-Analyse-Methode. Dies ist eine separate Forschungsfrage, die im Rahmen dieser Arbeit nicht behandelt wird, aber dennoch ein hohes Erkenntnispotential beinhaltet. Für die Bewertung der Precision-Werte, mit einem statistischen Mittelwert von 33,2 %, muss berücksichtigt werden, dass die identifizierten Teilmengen auf den einzelnen Stufen Impact- Analyse-Methode nicht bewertet und somit gefiltert wurden, wie eigentlich zur Aufwandsreduzierung in der Methodenbeschreibung vorgesehen. Eine solche Bewertung hätte eine ausreichende fachliche Eignung aller Studienteilnehmer zum Treffen fundierter Änderungsentscheidungen vorausgesetzt, die zuvor nicht geprüft werden konnte. Zudem hätte eine solche Bewertung der Zwischenergebnisse durch die Studienteilnehmer den subjektiven Einfluss auf die Ergebnisse weiter erhöht, was für deren Aussagekraft abträglich gewesen wäre. Daher wurden bei der automatischen Bestimmung des CIS über den Algorithmus für alle Zwischenergebnisse, unabhängig von deren Relevanz, im nächsten Schritt weitere verknüpfte Elemente identifiziert. Dadurch generiert jedes FP-Element automatisch eine Vielzahl weiterer FP-Elemente, was den Precision-Wert insgesamt negativ beeinflusst. Vor demselben Hintergrund muss auch das Ergebnis für den Parameter Accuracy betrachtet werden. Der statistische Mittelwert von 76,4 % kann deutlich verbessert werden, wenn zwischen den einzelnen Impact-Analyse-Stufen eine Bewertung des CIS durch Experten erfolgt. Die Diskussion der Studienergebnisse verdeutlicht, dass bei ihrer Interpretation eine Vielzahl von Einflussfaktoren betrachtet werden müssen, deren Berücksichtigung insbesondere den Wert für die Vollständigkeit der identifizierten Elemente jeweils stark beeinflusst (siehe Tabelle 28). In Anbetracht der diskutierten Gründe, welche die Studienergebnisse negativ beeinflusst haben, jedoch dem Studiendesign immanent waren, und der Tatsache, dass bei dem aggregierten Modell, welches den subjektiven Charakter der Ergebnisse reduziert, ein Recall-Wert von 100 % erreicht wurde, kann die entwickelte Impact-Analyse-Methode als wirksam betrachtet werden. 201

231 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte Einzelergebnisse aller Studienteilnehmer Bereinigte Einzelergebnisse aller Studienteilnehmer Aggregiertes Modell Recall 71,4 % 88,0 % 100 % Tabelle 28: Vollständigkeit der durch den Impact-Analyse-Algorithmus identifizierten Elemente in Abhängigkeit der Fehlerinterpretation Hinsichtlich der Realitätsnähe der Aufgabenstellung ist anzumerken, dass diese inhaltlich an industrielle Aufgabenstellungen angelehnt ist, Umfang und Komplexität der Artefakte jedoch deutlich geringer waren ZUSAMMENFASSUNG UND DISKUSSION Ziel von Kapitel 6 war es, die Unterstützbarkeit des Änderungsmanagements durch die Verwendung von Traceability-Informationen zu untersuchen. Dazu wurden zunächst die theoretischen Grundlagen zum Thema Änderungsmanagement betrachtet und es erfolgte eine kontroverse Auseinandersetzung mit den in der Literatur dokumentierten Ansätzen für Impact Analysen aus den Disziplinen Softwaretechnik und Mechatronik. Auf Basis dieser Erkenntnisse wurde die Hypothese formuliert, dass eine Impact-Analyse-Methode für mechatronische Produkte auf Basis Artefakt-übergreifender Traceability-Informationen wirksam wäre. Um diese Forschungsfrage zu untersuchen, wurden die Spezifika, die sich aus der Struktur und der Art der Modellierung von Artefakten in der Mechatronik ergeben, herausgearbeitet und in spezifische Anforderungen an eine entsprechende Impact-Analyse-Methode überführt. Anschließend erfolgte die Herleitung eines geeigneten, übertragbaren Impact-Analyse- Algorithmus. Die Überprüfung der Wirksamkeit dieses Algorithmus und damit auch die Evaluierung der Forschungsfrage wurde mittels einer Nutzerstudie durchgeführt, in deren Verlauf die Studienteilnehmer zunächst ein Traceability-Modell für die vorbereiteten Produktartefakte erstellen und in der Folge für vorgegebene Änderungsszenarien die potentiell betroffenen Elemente identifizieren mussten. Die Überprüfung der Wirksamkeit des Algorithmus ergab eine sehr hohe Übereinstimmung zwischen den von den Teilnehmern manuell und den vom Algorithmus automatisch identifizierten Elementen. Dies trifft insbesondere auf ein aggregiertes Modell zu, bei dem nur Elemente als betroffen gewertet wurden, die von mindestens drei Probanden identifiziert wurden, womit der subjektive Einfluss durch Unterschiede im Produktverständnis reduziert wird. Für dieses aggregierte Modell erzielte der Impact-Analyse-Algorithmus eine Übereinstimmung von 100 %. Vor diesem Hintergrund kann die Forschungsfrage mit ja beantwortet werden: eine Impact-Analyse-Methode für mechatronische Produkte auf Basis Artefaktübergreifender Traceability-Informationen ist wirksam. Weitere Forschungsarbeiten in diesem Kontext sollten sich auf die Untersuchung der Notwendigkeit und Kombinierbarkeit von Artefakt-internen Tracelinks für den entwickelten Im- 202

232 6 Traceability-basierte Impact-Analyse-Methode für die Entwicklung mechatronischer Produkte pact-analyse-algorithmus fokussieren. Diese Fragestellung wurde weder im Rahmen dieser Studie noch von anderen Wissenschaftlern bisher betrachtet. Eine abstraktere Forschungsfrage betrifft zudem den inhaltlichen Zusammenhang zwischen den unterschiedlichen Artefakttypen, die für eine Impact Analyse in Betracht gezogen werden sollten. Konkret wäre diesbezüglich zu untersuchen, welche Artefakt- und Tracelink-Typen für welchen Änderungsfall betrachtet werden müssen und welche Artefakt-Kombinationen ggf. ignoriert werden können. Ein derart geartetes Metamodell der mechatronischen, Traceability-basierten Impact Analyse könnte den erforderlichen Aufwand für deren Durchführung erheblich reduzieren und hätte somit auch eine hohe industrielle Relevanz. Mit diesen Erkenntnissen könnte der vorgestellte Impact-Analyse-Algorithmus insbesondere im Hinblick auf die notwendige Iterationsanzahl und die zu betrachtenden Artefakt- und Tracelink-Typen weiter verfeinert werden. Zusammenfassend kann festgehalten werden, dass die entwickelte Impact-Analyse-Methode hinsichtlich ihrer Wirksamkeit vielversprechende Ergebnisse geliefert hat. Dennoch ist eine weiterführende Unterstützung der Entwickler bei der Analyse von Änderungsauswirkungen notwendig. Dies betrifft insbesondere die Art der Informationsbereitstellung, die sowohl für eine Anwendung in einem Expertengremium, als auch für einen breiteren Einsatz durch Entwicklungsingenieure verschiedener Spezialisierungen geeignet sein muss. Diese Fragestellung einer geeigneten visuellen Aufbereitung der Impact-Analyse-Methode wird im folgenden Kapitel 7 adressiert. 203

233

234 7. SOFTWARE-PROTOTYP ZUR VISUELLEN IMPACT ANALYSE Im vorherigen Kapitel wurde ein übertragbarer Impact-Analyse-Algorithmus für die Anwendung in der Entwicklung mechatronischer Produkte vorgestellt und erfolgreich evaluiert. Die Visualisierung dieser Systemzusammenhänge ist im Änderungsfall als Kommunikationsmedium besonders wichtig [PFLEEGER UND BOHNER 1990, S. 326; KELLER ET AL. 2005, S. 1; DIEHL ET AL. 2008]. Die Notwendigkeit eines solchen Kommunikationsmediums unterstreichen die Erkenntnisse aus [EHRLENSPIEL 2007, S. 139], wonach die Anzahl erforderlicher Änderungen wächst, wenn in einem Unternehmen Defizite im Informationsaustausch existieren. Ziel von Kapitel 7 ist es daher, eine möglichst geeignete Form der visuellen Assistenz für die softwaretechnische Implementierung des Impact-Analyse-Algorithmus zu konzipieren und diese prototypisch umzusetzen. Dazu werden in Kapitel 7.1 zunächst existierende Visualisierungen für Impact Analysen im mechatronischen Kontext vorgestellt und diskutiert. Auf Basis dieser Erkenntnisse und der Ergebnisse aus Kapitel 5.2 wird eine Hypothese formuliert, welche Repräsentationsform für die visuelle Umsetzung einer Impact Analyse zu bevorzugen wäre. Diese Hypothese wird anschließend in Kapitel 7.3 mittels einer Nutzerstudie evaluiert. Auf Grundlage der Ergebnisse der Nutzerstudie und der in Kapitel identifizierten Mechatronik-Spezifika wird in Kapitel 7.4 ein Konzept für eine geeignete Impact-Analyse-Visualisierung hergeleitet. Die Umsetzung dieses Konzepts in einem softwaregestützten Assistenzsystem zur Impact Analyse wird in Kapitel 7.5 beschrieben. Das Kapitel schließt mit einer zusammenfassenden Bewertung und Diskussion hinsichtlich der Entwicklungsunterstützung durch das vorgestellte Assistenzsystem zur Impact Analyse im mechatronischen Kontext (Kapitel 7.6). Die in diesem Kapitel vorgestellten konzeptionellen und methodischen Inhalte wurden durch den Autor dieser Arbeit entwickelt. Die prototypische Implementierung des Impact-Analyse- Werkzeugs erfolgt im Rahmen der Diplomarbeit von Robert Müller [MÜLLER 2013]. 205

235 7 Software-Prototyp zur visuellen Impact Analyse 7.1. STAND DER WISSENSCHAFT UND TECHNIK FÜR DIE VISUELLE UNTERSTÜTZUNG VON IMPACT ANALYSEN In der Entwicklung mechatronischer Produkte kommt eine Vielzahl spezialisierter Software- Werkzeuge zum Einsatz (siehe Kapitel 2.3.2). Einige dieser Werkzeuge bieten ebenfalls Unterstützung für das Änderungsmanagement an, zum Teil sogar unter dem Begriff Impact Analyse. Ziel dieses Kapitels ist es, eine Auswahl der für das Änderungsmanagement relevanten Funktionen dieser Werkzeuge vorzustellen. Dazu werden die Mechanismen zur Identifikation der potentiell betroffenen Elemente sowie die Umsetzung der visuellen Assistenz des jeweiligen Werkzeugs kurz vorgestellt. LOOMEO [MAURER 2006; TESEON GmbH 2012] Wie in Kapitel geschildert, bietet das Werkzeug LOOMEO für die Impact Analyse im Wesentlichen die zwei Visualisierungsmöglichkeiten Abhängigkeitsmatrix und Force-directed Node-Link-Diagramm. In beiden Fällen werden jedoch nur Elemente identifiziert, die direkt über ausgehende Tracelinks mit dem zu ändernden Element verbunden sind [LINDEMANN ET AL. 2009]. Aspekte wie eine Änderungsfortpflanzung über hierarchische Strukturen werden nicht betrachtet, da dem Werkzeug insgesamt kein Impact-Analyse-Algorithmus zugrunde liegt. Aus diesem Grund hat die Ermittlung der betroffenen Elemente, wenn sie über die Iterationstiefe der direkt verknüpften Elemente hinausgehen soll, auch manuell zu erfolgen. IBM Rational DOORS [IBM Corp. 2012b; ABMA 2009; PLETTE 2009] Wird ein Element in DOORS geändert, werden alle seine Tracelinks als sog. suspect links mit einem Fragezeichen-Symbol markiert. Es kann eine separate Spalte erzeugt werden, welche die entsprechenden änderungsverdächtigen Tracelinks anzeigt. Des Weiteren kann abgefragt werden, welches Element aus welchem Artefakt, den Status suspect verursacht hat. Die als suspect markierten Tracelinks müssen in der Folge manuell geprüft und ggf. zurückgesetzt werden. Nutzt man das in DOORS enthaltene change proposal system, wird eine Gruppe definiert, die über alle Änderungsanfragen informiert wird. Ausschließlich Mitgliedern dieser Gruppe obliegt es dann, Änderungen zuzulassen oder abzulehnen. Ferner kann mit DOORS eine manuelle Tracelink-Analyse über den Analysis-Wizard durchgeführt werden, wobei ausgehend von einem ausgewählten Artefakt alle Elemente in einer definierbaren, gerichteten Verknüpfungstiefe in nach Verknüpfungstiefe sortierten Spalten ausgegeben werden. Dazu müssen zuvor fünf Konfigurationsschritte durchlaufen werden (siehe Abbildung 75). Eine weitere Möglichkeit zur visuellen Impact Analyse bietet der sog. Traceability Explorer, welcher das zu ändernde Element und alle direkt verknüpften Elemente in einem Node-Link-Diagramm anzeigt. DOORS bietet somit ein breites Spektrum an Möglichkeiten zur Visualisierung verknüpfter Elemente. Alle angebotenen Funktionalitäten zielen auf eine manuelle Analyse der Auswirkung von Änderungen, wobei jeweils nur direkte Links zwischen zwei Elementen zur Identifikation der potentiell betroffenen Elemente genutzt werden. [IBM Corp. 2012b] 206

236 7 Software-Prototyp zur visuellen Impact Analyse Abbildung 75: Konfigurationsschritte (oben) und listenartige Visualisierung der Ergebnisse des Analysis-Wizards (unten) in DOORS Change Prediction Method [CLARKSON ET AL. 2004; ECKERT ET AL. 2004; KELLER ET AL. 2005; GIFFIN ET AL. 2009; JARRATT ET AL. 2011; AHMAD ET AL. 2012; KOH ET AL. 2012] Wie in Kapitel erwähnt wurde, verfügt auch der Cambridge Advanced Modeller über eine Funktionalität zur Impact Analyse. Die theoretische Grundlage dieser Change Prediction Method (CPM) wurde in Kapitel detailliert vorgestellt. Die Methode betrachtet primär 207

237 7 Software-Prototyp zur visuellen Impact Analyse das Artefakt Produktstruktur, wobei für jede Elementkombination (also jede Zelle der Matrix) die Wahrscheinlichkeit und die Stärke der Betroffenheit gerichtet modelliert werden muss [ECKERT ET AL. 2004; WYNN ET AL. 2010b]. Zur Identifikation von potentiell betroffenen Elementen werden ausschließlich diese beiden Informationen verwendet. Die Ergebnisse der CPM können sowohl in einer Abhängigkeitsmatrix als auch in einem Force-directed- Diagramm visualisiert werden [KELLER ET AL. 2005] (siehe Abbildung 76). Abbildung 76: Visualisierung der CPM-Ergebnisse mittels Abhängigkeitsmatrix (links) und Force-directed-Diagramm (nach [KELLER ET AL. 2005, S. 6,8]) Reqtify [Geensoft 2010a, 2010b; POHL UND SCHEEL 2004] Im Programm Reqtify werden, analog zu dem Vorgehen in DOORS, alle ausgehenden Tracelinks eines geänderten Elements visuell hervorgehoben und semantisch mit dem Attribut suspect versehen. Dabei wird die zuvor in einem Metamodell definierte, gerichtete Beeinflussungsabfolge der Artefakte berücksichtigt. Die direkt verknüpften Elemente anderer Artefakte können einerseits in einem Node-Link-Diagramm mittels spaltenförmig sortierter Listen (siehe Abbildung 47 in Kapitel 5.2.1) und andererseits einem separaten Impact- Analyse-Fenster, in dem sowohl die über eingehende als auch über ausgehende Links verknüpften Elemente getrennt aufgelistet sind (siehe Abbildung 77), visualisiert werden. Zusätzlich können Abhängigkeiten im Rahmen einer Reporting-Funktion ebenfalls in eine Abhängigkeitsmatrix überführt werden. Ein darüber hinausgehender konkreter Algorithmus zur Ermittlung potentiell von der Änderungsfortpflanzung betroffener Elemente ist nicht hinterlegt. [Geensoft 2010b, 2010a] 208

238 7 Software-Prototyp zur visuellen Impact Analyse Abbildung 77: Impact Analyse in Reqtify mit getrennter Auflistung eingehend (links) und ausgehend verknüpfter Elemente [Claytex Services Limited 2012] IBM Rational RequisitePro [IBM Corp. 2011, 2012a] Die bestehenden Visualisierungsfunktionalitäten des Werkzeugs (siehe Kapitel 5.2.1) können genutzt werden, um die verknüpften Elemente zu identifizieren. So kann eine Liste generiert werden, die ausschließlich jene Elemente aufführt, die mit dem zu ändernden Element direkt verknüpft sind. Über die Matrix-Visualisierung können auch die indirekt verknüpften Elemente identifiziert werden, allerdings nur für jeweils ein Artefaktpaar. Eine übersichtliche Darstellung der Änderungsfortpflanzung über mehr als zwei Artefakte hinweg ist mit den vorgesehenen Visualisierungstechniken hingegen nicht möglich. [IBM Corp. 2011] V6 R2011x [Dassault Systèmes 2011, 2012a, 2012b; VORSATZ 2012] In ENOVIA können die modellierten Tracelinks zwischen jeweils zwei Artefakten listenartig ausgegeben werden. In dem sog. VPM Functional Logical Editor der CATIA-Umgebung können die Tracelinks zwischen auswählbaren Elementen sowohl mittels eines Node-Link- Diagramms als auch über eine Liste abgebildet werden. Im sog. RFLP-Navigator können zudem ausgehend von einem selektierten Element (aus einem der beiden Artefakte Anforderungen oder Funktionen) sowohl die Verknüpfungen innerhalb desselben Artefakts als auch zu Elementen des jeweils anderen Artefakts mittels eines Node-Link-Diagramms abgebildet werden. Der zugehörige Verknüpfungsbaum baut sich entsprechend der Verknüpfungstiefe 209

239 7 Software-Prototyp zur visuellen Impact Analyse von links nach rechts auf (siehe Abbildung 78). In allen genannten Fällen werden keine hierarchischen Relationen, sondern ausschließlich direkte Verknüpfungen zwischen zwei Elementen berücksichtigt. [VORSATZ 2012] Abbildung 78: Abbildung eines Abhängigkeitspfades zwischen Anforderungen und Funktionen im RFLP-Navigator mittels Node-Link-Diagramm [VORSATZ 2012, S. 48] Zusammenfassend können aus der Analyse des Standes von Technik und Anwendung drei Kernaussagen abgeleitet werden: 1. Es gibt ein breites Spektrum an Visualisierungsmöglichkeiten, die über die Abbildung von Tracelinks eine Impact Analyse rudimentär unterstützen können. Alle drei Repräsentationsformen (Liste, Matrix, Node-Link-Diagramm) finden dabei Anwendung. 2. Einen komplexen Impact-Analyse-Algorithmus, der unter Berücksichtigung der Anforderungen aus dem mechatronischen Kontext automatisch potentiell betroffene Elemente identifiziert, bietet keines der vorgestellten Werkzeuge. Die ausschließliche Berücksichtigung von direkten Verknüpfungen, wie sie von allen vorgestellten Werkzeugen praktiziert wird, ist jedoch nicht ausreichend, da Änderungen sich auch auf Elemente fortpflanzen können, die nicht direkt miteinander verknüpft sind [JARRATT ET AL. 2004, S. 1; KELLER ET AL. 2005, S. 1; GIFFIN ET AL. 2009, S. 6] (siehe auch Ausführungen zur hierarchischen Transitivität in Kapitel 2.2.6). 3. Keines der Werkzeuge verfügt über eine Software-geführte Unterstützung der Entwickler bei der Bewertung der einzelnen zu prüfenden Elemente. In der obigen Analyse existierender Werkzeuge hat sich keine visuelle Repräsentationsform herauskristallisiert, die für eine Impact Analyse eindeutig zu präferieren wäre. Zudem gibt es keine vergleichenden Studien hinsichtlich dieser speziellen Ingenieurstätigkeit. Daher kann auf Basis der Analyse des Standes von Anwendung und Technik keine zu bevorzugende Repräsentationsform ausgewählt werden HYPOTHESE 3 ZUR GRAPHISCHEN UNTERSTÜTZUNG DER ARTEFAKT- ÜBERGREIFENDEN IMPACT ANALYSE Die Analyse bestehender Softwarelösungen in Kapitel 7.1 hat ergeben, dass es derzeit keine Lösung gibt, die einen Artefakt-übergreifenden Impact-Analyse-Algorithmus mittels graphischer Repräsentation des Änderungspfades umfassend und Assistenz-basiert realisiert. Es gibt einerseits die theoretischen, nicht visuell unterstützten 88 Impact-Analyse-Algorithmen 88 Eine Ausnahme bildet das zuvor vorgestellte CPM-Werkzeug, welches auch über eine Visualisierungskomponente verfügt 210

240 7 Software-Prototyp zur visuellen Impact Analyse aus dem akademischen Umfeld (siehe Kapitel 6.3) und andererseits die graphischen Ansätze, bei denen sich Änderungen ausschließlich über direkte Verknüpfung zweier Elemente fortpflanzen (siehe Kapitel 7.1). Eine Kombination von umfassendem Algorithmus mit einer geeigneten graphischen Repräsentation ist derzeit nicht vorhanden. Um eine Implementierung des entwickelten Impact-Analyse-Algorithmus potentiellen Nutzern adäquat bereitstellen zu können, muss auch die Fragestellung, welche Repräsentationsform für dessen visuelle Realisierung am besten geeignet ist, beantwortet werden. Dazu muss an die Argumentation aus Kapitel 5.2 erinnert werden, wo auf Basis einer Literaturanalyse die Repräsentationsform Node-Link-Diagramm als besser lesbar, als die beiden Alternativen Abhängigkeitsmatrix und Liste qualifiziert wurde. Die darin formulierten Einwände gegen die Repräsentationsform Matrix, namentlich die Kritik an dem primär für industrielle Anwender zu hohen Abstraktionsgrad sowie der enorme Platzbedarf bei gleichzeitiger Visualisierung mehrerer Artefakte, bleiben auch für den Anwendungsfall einer Impact Analyse valide. Gleiches gilt, mit einer hohen Wahrscheinlichkeit, auch für die in den allgemeinen Vergleichsstudien ermittelten schlechten Werte für die Repräsentationsform Liste. Daraus ergibt sich für dieses Kapitel die folgende Hypothese: Bei der Analyse von modellübergreifenden Änderungen können die Auswirkungen auf betroffene Elemente durch graphische Darstellung des Traceability- Modells in Form eines Node-Link-Diagramms schneller und korrekter beurteilt werden, als bei einer Darstellung in einer der beiden alternativen Repräsentationsformen Abhängigkeitsmatrix und Liste. Zur Verifikation der Hypothese und somit zur Ermittlung der am besten geeigneten Repräsentationsform, wird eine Nutzerstudie durchgeführt, deren konkrete Ausprägung im folgenden Kapitel beschrieben wird. Die Studienergebnisse werden anschließend genutzt, um auf ihrer Basis einen Softwareprototyp zur Unterstützung von Impact Analysen zu implementieren NUTZERSTUDIE ZUM VERGLEICH DER ANWENDUNGSEFFIZIENZ DREIER VISUALISIERUNGSKONZEPTE FÜR DAS ÄNDERUNGSMANAGEMENT Dieses Kapitel untersucht die zuvor formulierte Hypothese hinsichtlich der Forschungsfrage, welche visuelle Repräsentation des Traceability-Modells für den Anwendungsfall der Artefakt-übergreifenden Impact Analyse von den Entwicklern am effizientesten genutzt werden kann. Ziel dieser Untersuchung ist es, die passende Repräsentationsform für die Implementierung des vorgestellten Impact-Analyse-Algorithmus in einem visuellen Assistenzsystem auszuwählen. Zu diesem Zweck wird eine Nutzerstudie durchgeführt, in deren Rahmen die drei gängigen visuellen Repräsentationsformen (Matrix, Liste und Node-Link-Diagramm) verglichen werden. Sowohl die durchzuführenden Aufgaben, als auch die Struktur der Artefakte, spiegeln dabei den Kontext Impact-Analyse im Bereich Systems Engineering wider. In dieser Kontext-Berücksichtigung besteht der wesentliche Unterschied zu den bereits in Kapitel vorgestellten Studien [GHONIEM ET AL. 2004; KELLER ET AL. 2006] und [LI UND MAALEJ 2012]. 211

241 7 Software-Prototyp zur visuellen Impact Analyse Konkret bedeutet die Kontext-Berücksichtigung, dass sich die gestellten Aufgaben an einer realen Aufgabe aus der Produktentwicklung orientieren und dass die Inhalte mehrerer hierarchisch strukturierter Artefakte sowie die zwischen diesen modellierten Artefaktübergreifenden Tracelinks einen tatsächlichen Produktbezug haben. Das in der Praxis notwendige Orientieren und Navigieren im Datenkontext wird somit in dieser Nutzerstudie nachempfunden. Bei den Aufgabenstellungen in [GHONIEM ET AL. 2004] und [KELLER ET AL. 2006] wurden einfache Informationsgewinnungsaufgaben gestellt (Finden eines Knotens, Zählen der Relationen für einen spezifischen Knoten etc.), bei denen der eigentliche Inhalt des Traceability-Modells nicht analysiert werden muss. Die Aussagekraft ihrer Untersuchungen ist somit für eine Anwendung im Rahmen einer ingenieurtypischen Tätigkeit begrenzt. Bei der hier vorgestellten Nutzerstudie wird durch die Formulierung der Aufgabenstellung der konkrete Anwendungsfall des Änderungsmanagements betrachtet STUDIENTEILNEHMER UND MATERIALIEN An der Studie haben 21 Versuchspersonen teilgenommen (17 männlich, vier weiblich, Durchschnittsalter 28,5 Jahre). 20 Studienteilnehmer waren studentische Hilfswissenschaftler oder wissenschaftliche Mitarbeiter, eine Person hatte eine kaufmännische Ausbildung abgeschlossen. 13 Personen verfügten über eine ingenieurtechnische Vorbildung, während sieben Studienteilnehmer eine informationstechnische, mathematische oder psychologische Vorbildung aufwiesen. Allen drei Repräsentationen lag dasselbe Traceability-Modell zugrunde, um eine Gleichheit hinsichtlich der Modellkomplexität und Graphendichte nach [GHONIEM ET AL. 2004] zu gewährleisten. Für das selbst entwickelte hypothetische Beispielprodukt eines Pedelecs waren drei Artefakte abgebildet: Anforderungen, Funktionen und Produktstruktur. Alle drei Artefakte waren jeweils in vier Hierarchieebenen strukturiert. Insgesamt bestand das Modell aus 135 Elementen, die jeweils mit einem eindeutigen Identifizierer bezeichnet waren, 106 hierarchischen Relationen und 423 Tracelinks. Eine auf DIN A4 skalierte Variante der Abbildung der entwickelten Pedelec-Artefakte kann Anhang A1 (Seite 290) entnommen werden 89. Alle Artefakte waren miteinander verknüpft, wobei die Tracelinks nicht zufällig verteilt wurden, sondern die tatsächlichen inhaltlichen Abhängigkeiten widerspiegelten. In der Repräsentationsform Liste waren alle Elemente eines Artefakts in einer eindimensionalen (keine Einrückungen) Liste aufsteigend nach ihrer hierarchischen Ordnung in einer Spalte sortiert. Die hierarchische Zugehörigkeit der Elemente konnte der Nummerierung der Identifizierer entnommen werden. Jedes Element belegte eine Zeile der Liste. Rechts neben jeder Zelle waren die jeweils zugehörigen verknüpften Elemente aufgeführt (siehe Abbildung 79; rechts: zwei vergrößerte Ausschnitte der Liste). 89 Anhang A5 enthält auf Seite 330 zudem eine Darstellung der unverknüpften Artefakte in Listenform. 212

242 7 Software-Prototyp zur visuellen Impact Analyse Abbildung 79: Pedelec-Produktmodell in der Repräsentationsform Liste Die Grundlagen der Repräsentationsform Abhängigkeitsmatrix wurden bereits in Kapitel 3.5 detailliert erläutert. Im Rahmen der Nutzerstudie wurde die Abhängigkeitsmatrix so konfiguriert, dass alle drei Artefakte jeweils horizontal in der Kopfzeile als auch vertikal in der ersten Spalte der Matrix aufgetragen waren. Die Segmente, in denen sich identische Artefakte gegenüberstanden, waren leer, da Artefakt-interne Tracelinks im Rahmen dieser Studie nicht betrachtet wurden. Die ungerichteten Tracelinks zwischen zwei Elementen unterschiedlicher Artefakte waren jeweils in beiden möglichen Zellen durch ein Kreuz markiert, um die Lesbarkeit zu erleichtern (siehe Abbildung 80; rechts: zwei vergrößerte Ausschnitte der Matrix). Wurde eines dieser Kreuze durch den Nutzer angeklickt, wurden die beiden zugehörigen Identifizierer farblich hervorgehoben. Abbildung 80: Pedelec-Produktmodell in der Repräsentationsform Abhängigkeitsmatrix 213

243 7 Software-Prototyp zur visuellen Impact Analyse Die dritte Repräsentationsform war das Node-Link-Layout Ariadne s Eye, das in Kapitel 5 detailliert hergeleitet und vorgestellt wurde. Wurde in Ariadne s Eye ein Element selektiert, wurden alle benachbarten Knoten und die vorhandenen Artefakt-übergreifenden Tracelinks farblich hervorgehoben (siehe Abbildung 81; rechts: zwei vergrößerte Ausschnitte). Abbildung 81: Pedelec-Produktmodell im Node-Link-Layout Ariadne s Eye Die Konzipierung der Studie zielte bewusst darauf ab, in allen drei Repräsentationsformen vergleichbare Visualisierungsobjekte und Interaktionsmöglichkeiten vorzusehen. Dazu wurden einige in Kapitel vorgestellten Interaktionsfunktionalitäten von Ariadne s Eye deaktiviert (bspw. die Suche). Allen Repräsentationsformen war gemein, dass die Zugehörigkeit zu einem Artefakt durch Einfärbung der entsprechenden Elemente symbolisiert war. Zudem indizierte neben der Nummerierung der Identifizierer auch die Größe der Beschriftung die hierarchische Zugehörigkeit jedes Elements. Um ganze Artefakte ein- oder auszublenden, waren in allen drei Repräsentationsformen entsprechende Checkboxen vorgesehen. Eine Übersicht über die konkrete Ausprägung der wesentlichen Visualisierungsobjekte und der Interaktionsmöglichkeiten je Repräsentationsform sind in Tabelle 29 dargelegt. 214

244 7 Software-Prototyp zur visuellen Impact Analyse Liste Matrix Ariadne s Eye Anforderungen: blau Anforderungen: blau Anforderungen: blau Artefakt-Farbe Funktionen: rot Funktionen: rot Funktionen: rot Produktstruktur: grün Produktstruktur: grün Produktstruktur: grün Farbe selektierter Elemente gelb gelb gelb Mehrfach- Selektion Strg + linke Maustaste Strg + linke Maustaste Strg + linke Maustaste Skalieren Strg + Scrollrad Strg + Scrollrad Strg + Scrollrad Verschieben Scrollrad drücken Scrollrad drücken Scrollrad drücken Artefakt ein- und ausblenden Checkbox Checkbox Checkbox Tabelle 29: Ausprägung der Visualisierungsobjekte und Interaktionsmöglichkeiten je Repräsentationsform Für die Durchführung der Studie wurde allen Teilnehmenden derselbe PC mit Windows XP (SP3), Intel Core 2 Duo CPU (2,66GHz je Kern) und 2GB RAM zur Verfügung gestellt. Die Anwendungen für die Repräsentationsformen Liste und Matrix wurden in Microsoft Excel 2007 und Ariadne s Eye in Java 6 (Update 13) realisiert. Die Interaktionsfunktionalitäten in MS Excel wurden mit der Programmiersprache Visual Basic for Applications implementiert. Für das Aufzeichnen der Maus- und Tastatur-Interaktionen, zur Ermittlung der motorischen Belastung, ist die freie Software Mousotron genutzt worden. Die von den Probanden verwendete Oberfläche wurde parallel vom Studienleiter mittels Teamviewer 7 als Remote- Desktop beobachtet. Neben der Protokollierung der Maus- und Tastatur-Interaktionen wurden am Rechner des Studienleiters zeitgleich die Zeiten für die zu bearbeitenden Teilschritte protokolliert. Vor Beginn der Studie waren die Teilnehmenden aufgefordert, ein vorbereitetes Dokument zu lesen, in welchem die Grundlagen der Traceability, des entwickelten Beispielmodells und des Impact-Analyse-Algorithmus textuell und visuell beschrieben sind (siehe Anhang A4 ab Seite 304). Der Umgang mit den Artefakten und den Interaktionsfunktionalitäten wurde daraufhin in den jeweiligen Anwendungen für alle drei Repräsentationsformen an drei generischen hierarchischen Artefakten am PC geübt. Die konkret zu bearbeitenden Aufgaben und Teilaufgaben hatten die Studienteilnehmer den bereitgestellten, ausgedruckten Aufgabenblättern zu entnehmen. Die Lösungen der einzelnen Teilaufgaben wurden durch den jeweiligen Studienteilnehmer schriftlich auf dem Ausdruck festgehalten. Zu diesem Zweck enthielt der Ausdruck eine Tabelle, in der neben der konkreten Aufgabenstellung der fünf Teilaufgaben auch leere Zellen für die Ergebnisse enthalten waren. Je nach der zu ermittelnden Ergebnisklasse (SIS oder CIS) waren die entsprechenden, nicht zu befüllenden Zellen ausgegraut (siehe Abbildung 82). Die Spalte mit der benötigten Lösungszeit wurde im Nachgang durch den Studienleiter ausgefüllt. 215

245 7 Software-Prototyp zur visuellen Impact Analyse Abbildung 82: Für die Nutzerstudie bereitgestelltes Lösungsblatt Zusätzlich zu den zu ermittelnden Lösungselementen der Impact Analyse wurde jeder Studienteilnehmer gebeten, nach dem Beenden jeder Aufgabe zwei Fragebögen 90 auszufüllen. Die Fragebögen wurden den Studienteilnehmern ebenfalls in ausgedruckter Form bereitgestellt. Der originale Einführungstext, die Aufgabenblätter und die beiden Fragebögen sind dem Anhang A5 (Seite 316ff) zu entnehmen STUDIENDESIGN Die vorgestellte vergleichende, empirische deskriptive Nutzerstudie dient der Evaluierung dreier Repräsentationsformen hinsichtlich deren Eignung für die visuelle Unterstützung des vorgestellten Traceability-basierten Impact-Analyse-Algorithmus. Dazu muss die induktiv hergeleitete Hypothese aus Kapitel 7.2 verifiziert werden. Dies geschieht, indem eine Nullhypothese abgeleitet wird, die anschließend zu falsifizieren ist. Die Hypothesen für die Eignung der Repräsentationsform Node-Link-Diagramm zur visuellen Assistenz bei einer Traceabilitybasierten Impact Analyse lauten: 90 Die inhaltlichen Details zu den Fragebögen werden auf Seite 217f beschrieben. 216

246 7 Software-Prototyp zur visuellen Impact Analyse Hypothese 3 H 3 : Bei der Analyse von modellübergreifenden Änderungen können die Auswirkungen auf betroffene Elemente durch graphische Darstellung des Traceability-Modells in Form eines Node-Link-Diagramms schneller und korrekter beurteilt werden, als bei einer Darstellung in einer der beiden alternativen Repräsentationsformen Abhängigkeitsmatrix und Liste. Nullhypothese H 3-0 : Bei der Analyse von modellübergreifenden Änderungen können die Auswirkungen auf betroffene Elemente durch graphische Darstellung des Traceability-Modells in Form eines Node-Link-Diagramms nicht schneller und korrekter beurteilt werden, als bei einer Darstellung in einer der beiden alternativen Repräsentationsformen Abhängigkeitsmatrix und Liste. Die unabhängige Variable der Nutzerstudie ist die Repräsentationsform, welche jeweils zur Visualisierung des Traceability-Modells verwendet wird. Die abhängigen Variablen sind hingegen die ermittelten Lösungselemente je Aufgabe sowie die benötigte Lösungszeit. Die Messgrößen, die zur Evaluierung der Hypothese genutzt werden, sind die Korrektheit der ermittelten Lösungselemente im Vergleich zur SOLL-Lösung und die respektive Lösungszeit, die zu deren Ermittlung aufgewandt wurde. Zusätzlich wurden im Rahmen der Nutzerstudie als abhängige Variablen die Interaktionsintensität sowie jeweils die Belastung durch und die Attraktivität der Repräsentationsart durch zwei normierte Fragebögen ermittelt. Das Studiendesign sieht vor, dass jeder Studienteilnehmer manuell jeweils drei vergleichbar komplexe Impact-Analyse-Aufgaben auf Basis des in Kapitel 6.5 vorgestellten Algorithmus bearbeiten muss. Für jede Aufgabe steht dazu eine andere Repräsentationsform zur Verfügung (within-subject Design). Jede Aufgabe besteht aus fünf Teilaufgaben, die zum Teil unterschiedlicher Natur sind. So befassen sich jeweils die Teilaufgabe 1 mit dem Suchen eines Elements innerhalb der Hierarchie, die Teilaufgaben 2 & 4 mit dem hierarchischen Identifizieren der jeweiligen Eltern- und Kindelemente und die Teilaufgaben 3 & 5 mit dem Nachverfolgen der, von den identifizierten Elementen ausgehenden, Tracelinks zu anderen Artefakten. Die Reihenfolge der zu verwendenden Repräsentationsformen wurde je Aufgabe gleichverteilt variiert, um Lern- und Ermüdungseffekte auszugleichen. Die Anzahl der Studienteilnehmer wurde für die drei unterschiedlichen Abarbeitungsreihenfolgen ebenfalls gleich gehalten. Daraus ergibt sich ein vollständiges, einfaktorielles Studiendesign. Nach der Bearbeitung jeder Aufgabe waren die Studienteilnehmer aufgefordert, jeweils einen AttrakDiff- und einen NASA-Task-Load-Index 91 -Fragebogen auszufüllen. Beide Fragebögen entstammen dem Wissenschaftsgebiet der sog. Useability Evaluation. Der AttrakDiff-Fragebogen in Anlehnung an [HASSENZAHL ET AL. 2003] dient dazu, die wahrgenommene hedonische und pragmatische Qualität einer entwickelten Lösung für den Nutzer zu bewerten. Dies wird ermittelt, indem die Probanden der entwickelten Lösung jeweils 91 Akronym: TLX 217

247 7 Software-Prototyp zur visuellen Impact Analyse einen Wert auf einer siebenstufigen Skala zwischen zwei gegensätzlichen Wortpaarungen (bspw. menschlich technisch) zuweisen. Insgesamt müssen 27 Wortpaarungen bewertet werden. Aus diesen Werten kann die Lösung hinsichtlich der folgenden vier Kriterien bewertet werden: hedonische Qualität bzgl. Identifikation mit der Lösung (HQ-I), hedonische Qualität bzgl. Stimulation durch die Lösung (HQ-S) sowie pragmatische Qualität (PQ) und Attraktivität (AT) der Lösung. Der NASA-TLX-Fragebogen [HART UND STAVELAND 1998] dient der Bewertung von Lösungen oder Aktivitäten hinsichtlich der durch diese erzeugten, subjektiv empfundenen Belastung für den Nutzer. Dabei wird der getesteten Lösung für sieben Dimensionen (wie bspw. mentale oder physische Belastung) ein Wert auf einer elfstufigen Skala zwischen den Extremwerten sehr gering (Wert = 0) und sehr hoch (Wert = 10) zugewiesen. Im Rahmen der Nutzerstudie dient der NASA-TLX-Fragebogen dazu, die Belastung der Probanden durch die jeweilige Repräsentationsform zu ermitteln. Daher müssen alle Nutzer nach Beendigung jeder der drei Aufgaben den NASA-TLX-Fragebogen ausfüllen. Sicherheitshalber wurden sie zuvor darauf hingewiesen, dass die Fragen die Art der Repräsentation adressieren und nicht den Lösungsalgorithmus. Da dieser jedoch in allen drei Aufgaben unverändert ist, würde sich ein dadurch bedingter Fehler ausgleichen. Der Abgleich der von den Teilnehmern ermittelten Lösungselemente mit der SOLL-Lösung erfolgte im Nachgang der Studie. Für die Bearbeitung der Aufgaben gab es keine zeitliche Begrenzung. Während der Bearbeitung war es den Studienteilnehmern gestattet, Fragen an den Studienleiter zu richten DURCHFÜHRUNG Mit der Studie wurde begonnen, nachdem der jeweilige Studienteilnehmer die einführenden Texte bzgl. der Traceability-Grundlagen und dem Impact-Analyse-Algorithmus gründlich gelesen und die Funktionsweise der drei Repräsentationslösungen am Computer mit einem einfachen, generischen Beispiel verinnerlicht hatte. Das Verständnis der Aufgabenstellung musste durch das Bearbeiten einer Aufgabe mit einem generischen Beispielprodukt von jedem Studienteilnehmer unter Beweis gestellt werden. Während der Einführung konnten die Probanden jederzeit Fragen hinsichtlich der in der Einführung behandelten Themen und Software-Anwendungen an den Studienleiter richten. Sobald der Studienteilnehmende sein Verständnis bekundete, hat der Versuchsleiter mit den zu untersuchenden Aufgaben begonnen. Die zu verwendende Software-Repräsentation wurde durch den Studienleiter jeweils vor Beginn aller drei Aufgaben vorbereitet. In jeder der drei Aufgaben (und somit mit jeder der drei Software-Repräsentationen) waren die Studienteilnehmer angehalten, mittels einer vereinfachten Version des entwickelten Impact-Analyse-Algorithmus, die von einer Änderung eines vorgegebenen Ausgangselements (SIS) potentiell betroffenen Elemente (CIS) zu identifizieren. Zur Identifikation des Ausgangselements (SIS) mussten dessen Identifizierer und Bezeichner genutzt werden. Diese Analyse erfolgte anhand des zuvor entwickelten Traceability-Modells eines Pedelecs. Zu jedem Zeitpunkt stand den Studienteilnehmern dafür eine schematische Beschreibung der 218

248 7 Software-Prototyp zur visuellen Impact Analyse einzelnen Teilschritte der Methode in Form eines Ausdrucks zur Verfügung (siehe Anhang A5 auf Seite 319), in welcher die durchzuführenden fünf Teilaufgaben detailliert (inkl. eines Beispiels) beschrieben waren: 1. Identifizieren Sie bitte das mit Identifizierer und Bezeichner vorgegebene Startelement. 2. Identifizieren Sie bitte alle über- und untergeordneten Elemente des Startelements in demselben Partialmodell Identifizieren Sie bitte zu allen Elementen aus den Teilschritten 1 und 2 alle direkt verknüpften Elemente der anderen Partialmodelle. 4. Identifizieren Sie bitte alle über- und untergeordneten Elemente der in Teilschritt 3 identifizierten Elemente in dem jeweils selben Partialmodell. 5. Identifizieren Sie bitte zu allen Elementen aus den Teilschritten 3 und 4 alle direkt verknüpften Elemente der anderen Partialmodelle. Wenn alle vom Studienteilnehmer identifizierten Elemente auf dem Lösungsblatt notiert waren, hat der Studienleiter die benötigte Zeit notiert, während der Teilnehmer zunächst den NASA-TLX- und anschließend den AttrakDiff-Fragebogen ausgefüllt hat. Eine schematische Übersicht der im Rahmen der Nutzerstudie durchgeführten Aktivitäten je Teilnehmer ist in Abbildung 83 dargestellt. 92 Im Rahmen der Nutzerstudie wurden die Artefakte mit Partialmodell bezeichnet. 219

249 7 Software-Prototyp zur visuellen Impact Analyse Abbildung 83: Schematische Übersicht des Studienablaufs je Teilnehmer Aus den geschilderten Rahmenbedingungen ergeben sich eine Reihe von Charakteristika der Nutzerstudie, die in Tabelle 30 zusammengefasst sind. Hypothese Studienart Bei der Analyse von modellübergreifenden Änderungen, können die Auswirkungen auf betroffene Elemente durch graphische Darstellung des Traceability-Modells in Form eines Node- Link-Diagramms schneller und korrekter beurteilt werden als bei einer Darstellung in einer der beiden alternativen Repräsentationsformen Abhängigkeitsmatrix und Liste. Vergleichende, empirische Nutzerstudie im within-subject Design unter Laborbedingungen 220

250 7 Software-Prototyp zur visuellen Impact Analyse Anzahl der Teilnehmer 21 Analyseeinheit Methoden zur Datenerfassung Untersuchungsobjekt Analysemethoden Ermittelt werden die benötigte Lösungszeit, die Korrektheit der identifizierten Elemente, die Attraktivität der Repräsentationslösung, die durch diese empfundene Belastung sowie die tatsächlich erfolgte Nutzung der Eingabegeräte. Die Korrektheit der von jedem Studienteilnehmer ermittelten Menge potentiell betroffener Elemente (CIS) wird nachträglich über den Abgleich mit dem SOLL-CIS ermittelt. Die benötigte Lösungszeit für die einzelnen Teilaufgaben wird durch den Studienleiter erfasst. Die Werte zur Attraktivität der jeweiligen Repräsentationslösung werden aus den Werten des AttrakDiff- Fragebogens ermittelt. Die empfundene Belastung durch die jeweilige Repräsentationslösung wird aus den Angaben im NASA-TLX-Fragebogen abgeleitet. Die erfolgte Nutzung der Eingabegeräte wird durch eine Logging-Software protokolliert. Eignung der Repräsentationsformen für die entwickelte Impact-Analyse-Methode Vergleich der CIS-Elemente zwischen SOLL- und individuell ermittelter IST-Lösung, der benötigten Lösungszeit, der AttrakDiff- und der NASA-TLX-Werte sowie der Eingabegerätnutzung in Abhängigkeit von der Repräsentationsform. Ergeben sich für die Darstellungsform Node-Link-Diagramm vorteilhafte Werte, ist die Nullhypothese falsifiziert. Tabelle 30: Übersicht der Charakteristika der Nutzerstudie ERGEBNISSE UND AUSWERTUNG Im Rahmen der Nutzerstudie müssen eine Reihe von abhängigen Variablen betrachtet werden, um eine belastbare Aussage hinsichtlich der Eignung von Ariadne s Eye für eine Impact Analyse im Vergleich zu den beiden alternativen Repräsentationsformen ableiten zu können. Die Ergebnisse zu den jeweils betrachteten Messgrößen werden im Folgenden vorgestellt. Die detaillierten Messwerte je Studienteilnehmer können Anhang A5 entnommen werden (ab Seite 331). Benötigte Lösungszeit Bei den Betrachtungen hinsichtlich der Lösungszeit können die Ergebnisse neben den Repräsentationsformen auch nach den einzelnen Teilaufgaben (Ta) differenziert werden. Dar- 221

251 7 Software-Prototyp zur visuellen Impact Analyse aus können u. U. Aussagen hinsichtlich einer Korrelation zwischen der Art der Teilaufgaben 93 und der Eignung der Repräsentationsformen abgeleitet werden. Die tabellarische Übersicht der Ergebnisse über alle Studienteilnehmer, aufgeschlüsselt nach Teilaufgaben (Ta) und Repräsentationsform, ist in Tabelle 31 dargestellt. Darin sind jeweils die Mittelwerte (MW) sowie die Standardabweichungen (SD) angegeben, wobei der jeweils kürzeste Mittelwert durch fette Schrift hervorgehoben ist. In Abbildung 84 ist die Ergebnisverteilung als Boxplot abgebildet. Liste Matrix Node-Link Startelement suchen Hierarchisches Identifizieren Tracelinks nachverfolgen Zeit_Ta1 [s] Zeit_Ta2 [s] Zeit_Ta4 [s] Zeit_Ta3 [s] Zeit_Ta5 [s] MW 18,62 18,62 18,90 SD 9,22 12,07 19,38 MW 36,52 47,95 29,52 SD 18,82 45,63 13,44 MW 151,57 106,38 91,81 SD 102,88 43,49 49,77 MW 73,90 67,71 61,62 SD 45,71 46,80 27,28 MW 142,55 104,90 106,29 SD 120,02 71,61 54,56 Gesamtaufgabe [min] MW 6,94 5,76 5,14 SD 3,14 2,01 1,65 Tabelle 31: Übersicht der Lösungszeiten je Teilaufgabe und Repräsentationsform Es wird ersichtlich, dass die Repräsentationsformen für die einzelnen Teilaufgaben unterschiedlich gut geeignet zu sein scheinen. Bei den mittleren Lösungszeiten für die Suche des Startelements (Ta 1) gibt es zwischen den Repräsentationsformen so gut wie keinen Unterschied. Lediglich die Streuung der Lösungszeiten zwischen den einzelnen Teilnehmern ist beim Node-Link-Diagramm deutlich höher, was u. a. mit der ungewohnten Art der Visualisierung im Vergleich zu Liste und Matrix erklärt werden kann. Beim hierarchischen Identifizieren der jeweiligen Eltern- und Kindelemente (Ta 2 & 4) führt die Verwendung des Node-Link- Diagramms am schnellsten zu Ergebnissen, während für das Nachverfolgen der Tracelinks (Ta 3 & 5) sowohl Node-Link-Diagramm als auch Matrix gute Ergebnisse erbrachten. 93 Ta 1: Suchen eines Elements innerhalb der Hierarchie; Ta 2 & 4: hierarchisches Identifizieren der jeweiligen Eltern- und Kindelemente; Ta 3 & 5: Nachverfolgen der, von den identifizierten Elementen ausgehenden, Tracelinks zu anderen Artefakten. 222

252 7 Software-Prototyp zur visuellen Impact Analyse Abbildung 84: Boxplot für die Lösungszeiten je Teilaufgabe und Repräsentationsform Die Gesamtaufgabe, und damit der vornehmlich zu untersuchende Anwendungsfall einer Impact Analyse, wird mit der Repräsentationsform Node-Link-Diagramm durchschnittlich am schnellsten bearbeitet. Um die Aussagekraft dieser Ergebnisse zu bewerten, müssen deren Signifikanzniveaus ermittelt werden. Dazu wird für jede Teilaufgabe eine einfaktorielle Varianzanalyse (ANOVA) mittels der Software SPSS vorgenommen. In Tabelle 32 sind die F- Teststatistiken und die Irrtumswahrscheinlichkeiten (p) in Abhängigkeit der Teilaufgaben dargestellt (Konfidenzintervall 95%), wobei die beiden Signifikanz implizierenden Irrtumswahrscheinlichkeiten (p < 0,05) durch fette Schrift hervorgehoben sind. Liste Matrix Node-Link F (2, 60) p Startelement suchen Hierarchisches Identifizieren Tracelinks nachverfolgen Ta1 0,003 0,997 Ta2 2,083 0,133 Ta4 4,091 0,022 Ta3 0,471 0,627 Ta5 0,850 0,432 Gesamtaufgabe 3,183 0,049 Tabelle 32: Ergebnisse der einfaktoriellen Varianzanalyse für die Lösungszeit je Teilaufgabe 223

253 7 Software-Prototyp zur visuellen Impact Analyse Die einfaktorielle Varianzanalyse über alle drei Repräsentationsformen ergab einen signifikanten Einfluss der Repräsentationsform auf die benötigte Zeit für die Gesamtaufgabe (p = 0,049) sowie auf die Lösungszeit für das hierarchische Identifizieren in Teilaufgabe 4 (p = 0,022). Für das hierarchische Identifizieren in Teilaufgabe 2 ist der Wert knapp nicht mehr tendenziell signifikant 94 (p = 0,133). Für die weiteren Teilaufgaben hat die Repräsentationsform keinen signifikanten Einfluss auf die benötigte Lösungszeit. Diese Ergebnisse lassen den Schluss zu, dass eine auf der Repräsentationsform Node-Link- Diagramm basierende Impact Analyse eine signifikant kürzere Bearbeitungszeit erfordert als Impact Analysen auf Basis einer der beiden anderen Repräsentationsformen Liste oder Matrix. Korrektheit der ermittelten Lösungselemente Aus der Differenz der von den Teilnehmern jeweils identifizierten IST-Elemente mit den im Vorlauf zur Studie ermittelten SOLL-Elementen wird die Anzahl der Fehler ermittelt. Als Fehler gelten Elemente, die entweder fälschlicherweise als potentiell betroffen (FP) oder fälschlicherweise als nicht betroffen (FN) klassifiziert wurden. Die Aussagekraft dieser Ergebniskategorie ist differenziert zu betrachten, da es der Aufgabenstruktur immanent ist, dass bereits in den Teilaufgaben 2 oder 3 begangene Fehler zwingend zu einer Vielzahl weiterer Fehler in den Teilaufgaben 4 & 5 führen. Aus diesem Grund muss ebenfalls mit einer vergleichsweise hohen Standardabweichung der Ergebnisse gerechnet werden. Die tabellarische Übersicht der Ergebnisse für den Mittelwert (MW) und die Standardabweichung (SD) der ermittelten Fehler, aufgeschlüsselt nach Repräsentationsform, ist Tabelle 33 zu entnehmen, wobei der jeweils beste Wert durch fette Schrift hervorgehoben ist. Liste Matrix Node-Link Fehler FP FN MW 1,48 0,57 0,71 SD 3,54 2,40 1,59 MW 1,62 0,57 1,00 SD 4,06 1,29 2,47 Tabelle 33: Übersicht der Fehler (FP und FN) je Repräsentationsform Die Ergebnisse zeigen, dass bei der Durchführung der Impact Analyse mit der Repräsentationsform Matrix durchschnittlich die wenigsten und mit der Repräsentationsform Liste durchschnittlich die meisten Fehler begangen wurden. Um die Aussagekraft dieser Ergebnisse zu bewerten, müssen deren Irrtumswahrscheinlichkeiten über eine Varianzanalyse ermittelt werden (siehe Tabelle 34). 94 Bei einer Irrtumswahrscheinlichkeit in dem Intervall [5 %,10 %] wird von einer tendenziellen Signifikanz gesprochen. 224

254 7 Software-Prototyp zur visuellen Impact Analyse Liste Matrix Node-Link F (2, 60) p FP 0,715 0,493 FN 0,722 0,490 Tabelle 34: Ergebnisse der einfaktoriellen Varianzanalyse für die begangenen Fehler Die einfaktorielle Varianzanalyse (Irrtumswahrscheinlichkeit < 5 %) über alle drei Repräsentationsformen ergab keinerlei signifikanten Einfluss der Repräsentationsform auf die begangenen Fehler für die Gesamtaufgabe weder für die fälschlicherweise als potentiell betroffen (FP) noch für die fälschlicherweise als nicht betroffen (FN) klassifizierten Elemente. Daher muss festgehalten werden, dass die Repräsentationsform keinen signifikanten Einfluss auf die Korrektheit der mit ihr erzielbaren Ergebnisse hat. Attraktivität der Repräsentationslösung Durch die Bereitstellung von AttrakDiff-Fragebögen sollte die Attraktivität der jeweiligen Repräsentationsformen vergleichend bewertet werden. Abgefragt wurden der Struktur des Fragebogens entsprechend die vier Dimensionen hedonische Qualität bzgl. Identifikation mit der Lösung (HQ-I), hedonische Qualität bzgl. Stimulation durch die Lösung (HQ-S) sowie pragmatische Qualität (PQ) und Attraktivität (AT). Die Auswertung der Fragebögen ergab für die vier Dimensionen die in Tabelle 35 dargestellten Mittelwerte (MW) und Standardabweichungen (SD) je Repräsentationsform. Je höher der angegebene Wert ist (Maximum = 7), umso attraktiver wird die Lösung wahrgenommen. Die jeweils besten Werte je Dimension sind durch fette Schrift hervorgehoben. Die statistische Verteilung der Einzelwerte ist dem Boxplot in Abbildung 85 zu entnehmen. Liste Matrix Node-Link PQ HQ-I HQ-S AT MW 3,64 4,11 4,79 SD 0,95 0,93 1,08 MW 3,46 4,27 4,98 SD 0,72 0,70 0,81 MW 3,05 3,67 4,98 SD 0,80 0,64 0,61 MW 3,00 4,05 4,91 SD 0,92 1,00 0,77 Tabelle 35: Übersicht der Ergebnisse der vier Dimensionen des AttrakDiff-Fragebogens in Abhängigkeit der Repräsentationsform 225

255 7 Software-Prototyp zur visuellen Impact Analyse Abbildung 85: Boxplot der Subskalen des AttrakDiff-Fragebogens je Repräsentationsform Die Ergebnisse zeigen, dass die Repräsentationsform Node-Link-Diagramm in allen vier Dimensionen im Durchschnitt die besten Werte aufweist, während die Listenrepräsentation die schlechtesten Werte erzielt. Zur eingängigen Darstellung der Bedeutung der Werte HQ und PQ gibt es zudem eine etablierte Darstellungsmethode (siehe Abbildung 86). Der Wert für HQ ergibt sich aus dem arithmetischen Mittel der beiden Werte HQ-S und HQ-I. Dabei werden beide Achsen in jeweils drei Intervalle aufgeteilt, sodass neun Segmente entstehen, denen teilweise selbsterklärende Attribute zugeordnet sind. Beide Achsen sind jeweils in die Intervalle [1..3], [3..5] und [5..7] unterteilt. Für die zu bewertende Anwendung bzw. Bedienoberfläche ist daher ein möglichst hoher Wert in beiden Dimensionen und demnach eine Positionierung im oberen rechten Segment anzustreben. Die Einordnung der drei Repräsentationsformen in diese Darstellung ist in Abbildung 86 wiedergegeben. 226

256 7 Software-Prototyp zur visuellen Impact Analyse Abbildung 86: Diagrammartige Übersicht der AttrakDiff-Ergebnisse zu den Dimensionen HQ und PQ Alle drei Repräsentationsformen sind im zentralen, neutralen Segment angeordnet. Durch die relative Nähe aller drei Repräsentationsformen zur imaginären Diagonalen des Diagramms wird die Interpretation der Ergebnisse erleichtert. Alle Lösungen erzielten somit jeweils ähnliche Werte hinsichtlich ihrer pragmatischen und hedonischen Qualität. Die Repräsentationsform Node-Link-Diagramm liegt jedoch deutlich am nächsten zum angestrebten Segment mit dem Attribut begehrt, was eine pragmatische Nutzung mit hohem Spaßfaktor ausdrücken würde. Die Repräsentationsform Liste hingegen wurde von den Studienteilnehmern am schlechtesten bewertet, was bedeutet, dass sie im Durchschnitt als wenig praktikabel und wenig angenehm in der Nutzung evaluiert wurde. Zur Bewertung der Signifikanz der AttrakDiff-Ergebnisse wurde eine erneute Varianzanalyse durchgeführt. Die Ergebnisse für die Irrtumswahrscheinlichkeiten (p) in sind Tabelle 36 zusammengefasst. Liste Matrix Node-Link F (2, 60) p PQ 7,202 0,002 HQ-I 21,653 0,000 HQ-S 42,99 0,000 AT 23,545 0,000 Tabelle 36: Ergebnisse der einfaktoriellen Varianzanalyse für die Attraktivität der Repräsentationslösungen Die einfaktorielle Varianzanalyse (Irrtumswahrscheinlichkeit < 5 %) über alle drei Repräsentationsformen ergab, dass die Repräsentationsform einen signifikanten Einfluss auf die pragmatische Qualität der angebotenen Lösung hat. Auf die Dimensionen hedonische Quali- 227

257 7 Software-Prototyp zur visuellen Impact Analyse Liste Matrix Node-Link tät und Attraktivität der Anwendung hat die Repräsentationsform gar einen höchst signifikanten Einfluss. Da in allen vier Dimensionen die Node-Link-Lösung am besten bewertet wurde, kann festgehalten werden, dass die in Ariadne s Eye realisierte Repräsentation, für den Anwendungsfall einer Impact Analyse, sowohl hinsichtlich der hedonischen und pragmatischen Qualität als auch bezüglich der Attraktivität signifikant besser geeignet ist als die beiden alternativen Repräsentationsformen Liste und Matrix. Wahrgenommene Belastung der Nutzer durch die Repräsentationsform Ziel der Befragung mittels des NASA-TLX-Fragebogens war es, die wahrgenommene Belastung der Studienteilnehmer durch die Repräsentationsform zu ermitteln. Dazu wurden die Mittelwerte (MW) und die Standardabweichungen (SD) gemittelt über alle sieben Dimensionen in Abhängigkeit der Repräsentationsform berechnet (siehe Tabelle 37). Je höher der Wert ist, umso höher fällt die wahrgenommene Belastung aus (Minimum = 0; Maximum = 10). Der Wert für die geringste wahrgenommene Belastung ist in fetter Schrift dargestellt. Die statistische Verteilung der Einzelwerte ist dem Boxplot in Abbildung 87 zu entnehmen NASA- TLX MW 4,84 4,05 3,66 SD 1,46 1,80 1,39 Tabelle 37: Ergebnisse des NASA-TLX-Fragebogens für die wahrgenommene Belastung Abbildung 87: Boxplot für die wahrgenommene Belastung je Repräsentationsform Die geringste Belastung nehmen die Studienteilnehmer durchschnittlich mit der Node-Link- Anwendung wahr, wobei sich dabei, trotz der ungewohnten Natur des Ariadne s Eye Layouts, die Einschätzungen aller Studienteilnehmer am meisten ähneln. Die Liste-Anwendung 228

258 7 Software-Prototyp zur visuellen Impact Analyse wird von den Studienteilnehmern hingegen durchschnittlich als am meisten belastend empfunden. Um die Aussagekraft dieser NASA-TLX-Ergebnisse bewerten zu können, wird eine einfaktorielle Varianzanalyse (ANOVA) durchgeführt. In Tabelle 38 sind die Irrtumswahrscheinlichkeiten (p) dargestellt. Liste Matrix Node-Link F (2, 60) p NASA-TLX 3,084 0,053 Tabelle 38: Ergebnisse der Varianzanalyse zur wahrgenommenen Belastung (NASA-TLX) Die einfaktorielle Varianzanalyse über alle drei Repräsentationsformen ergab, dass die Repräsentationsform knapp keinen signifikanten Einfluss (Irrtumswahrscheinlichkeit < 5 %) auf die Attraktivität der angebotenen Lösung hat. Da eine Signifikanz lediglich um 0,3 % verfehlt wurde, kann jedoch von einem tendenziell signifikanten Einfluss gesprochen werden, der mit einer größeren Anzahl von Studienteilnehmern erneut verifiziert werden müsste. Das Ergebnis der Untersuchung mittels NASA-TLX-Fragebogen ist somit, dass die Node-Link-Lösung für den Anwendungsfall einer Impact Analyse als am wenigsten belastende Repräsentationsform wahrgenommen wird. Nutzungsintensität der Eingabegeräte Maus und Tastatur Bei der für die Bearbeitung der Aufgabenstellung notwendigen motorischen Belastung wurden über ein im Hintergrund laufendes protokollierendes Softwareprogramm die Größen ausgeführte Mausclicks, Tastaturanschläge, zurückgelegte Mausstrecke und gescrollte Mauszeilen protokolliert. In Tabelle 39 sind die daraus ermittelten Mittelwerte (MW) und Standardabweichungen (SD) angegeben, wobei die jeweils besten Werte durch fette Schrift hervorgehoben sind. Liste Matrix Node-Link Anzahl Mausclicks Anzahl Tastaturanschläge Mausstrecke [m] Scrollen [Zeilen] MW 29,10 30,38 36,52 SD 15,44 9,72 14,70 MW 15,10 12,48 13,57 SD 8,35 5,78 6,46 MW 9,10 8,09 11,19 SD 6,85 2,34 4,50 MW 676,57 166,43 20,95 SD 286,88 121,99 21,18 Tabelle 39: Ergebnisse für die motorische Belastung durch Nutzung der Eingabegeräte Die Ergebnisse lassen keinen eindeutigen Rückschluss darauf zu, welche Repräsentationsform hinsichtlich der motorischen Belastung zu bevorzugen wäre. So mussten mit der Re- 229

259 7 Software-Prototyp zur visuellen Impact Analyse präsentationsform Liste durchschnittlich die wenigsten Mausclicks ausgeführt werden, während mit der Repräsentationsform Matrix durchschnittlich am wenigsten Tastaturanschläge erfolgten und die zurückgelegte Mausstrecke am kürzesten war. Mit der Repräsentationsform Node-Link-Diagramm wiederum mussten die mit Abstand wenigsten Mauszeilen gescrollt werden. Um zu ermitteln ob die Repräsentationsform einen signifikanten Einfluss auf die Nutzungsintensität der Eingabegeräte hat, wurde für alle vier gemessenen Größen eine Varianzanalyse durchgeführt. Die daraus ermittelten Werte für die Irrtumswahrscheinlichkeit sind in Tabelle 40 angegeben. Liste Matrix Node-Link F (2, 60) p Anzahl Mausclicks 1,810 0,172 Anzahl Tastaturanschläge 0,752 0,476 Mausstrecke 2,170 0,123 Scrollen 76,664 0,000 Tabelle 40: Ergebnisse der Varianzanalyse für die Nutzungsintensität der Eingabegeräte Aus den Ergebnissen der einfaktoriellen Varianzanalyse wird ersichtlich, dass die Repräsentationsform keinen signifikanten Einfluss auf die Messgrößen ausgeführte Mausclicks, Tastaturanschläge sowie zurückgelegte Mausstrecke hat. Lediglich die Anzahl der gescrollten Mauszeilen wird offenbar höchst signifikant von der Repräsentationsform beeinflusst. Es ist somit festzuhalten, dass die Repräsentationsform lediglich auf eine Interaktionsform einen signifikanten Einfluss hat: das Scrollen mit dem Mausrad. Die Tatsache, dass bei der Node-Link-Anwendung die mit Abstand geringsten Mauszeilen gescrollt werden mussten, bestätigt den über den NASA-TLX-Fragebogen ermittelten Befund hinsichtlich der gefühlten Belastung. Auf Basis der Ergebnisse des NASA-TLX-Fragebogens sowie der Analyse für die Nutzungsintensität der Eingabegeräte kann somit festgehalten werden, dass die auf Ariadne s Eye basierende Node-Link-Anwendung den Nutzer bei der Durchführung einer Impact Analyse am wenigsten belastet. Freies Feedback der Studienteilnehmer Die im Rahmen der Nutzerstudie gestellten Aufgaben wurden von den Teilnehmern sehr heterogen bewertet: während einige diese als leicht oder verständlich bewerteten, hatten andere Teilnehmer Schwierigkeiten bei der Bearbeitung und haben sie dementsprechend als zu komplex bzw. zu abstrakt empfunden. Auch das Feedback zu den einzelnen Repräsentationsanwendungen fiel heterogen aus. Die Anwendung der Repräsentationsform Liste wurde von den Teilnehmern hauptsächlich negativ (13 Nennungen) bzw. neutral (7) eingeschätzt. An positivem Feedback wurde die gute Übersichtlichkeit der Tracelinks je Element in der rechten Spalte genannt, die allerdings 230

260 7 Software-Prototyp zur visuellen Impact Analyse bei der tatsächlichen Bearbeitung der Aufgabe nicht genutzt wurde. Dies überrascht, da diese Funktionalität die Standardlösung vieler kommerzieller Werkzeuge ist (siehe Kapitel 5.2.1). Kritisch angemerkt wurde hauptsächlich das notwendige übermäßige Scrollen (8 Nennungen) und die geringe Übersichtlichkeit der Darstellung an sich (6). Die Anwendung der Repräsentationsform Matrix wurde durchschnittlich positiver bewertet. Die Mehrheit der Studienteilnehmer schätzten die Anwendung neutral (14) ein, einige bewerteten sie als positiv (4). Als meistgenannter Vorteil wurde die kompakte bzw. übersichtliche Darstellung (insgesamt 10 Nennungen) der Tracelinks angemerkt. Die Kritik, welche am häufigsten genannt wurde, adressiert die vertikale Beschriftung (7) in der Kopfzeile der Matrix. Am positivsten wurde durchschnittlich die Node-Link-basierte Anwendung Ariadne s Eye bewertet. Neun Teilnehmer empfanden die Anwendung als neutral, während 12 Teilnehmer eine positive Bewertung abgaben. Der Hauptkritikpunkt war die teilweise schwierige Lesbarkeit (8) der Node-Link-Darstellung, wobei insbesondere die Überschneidungen von Knotenlabels negativ angemerkt wurden. Andererseits wurde die Anwendung von sieben Teilnehmern als schön oder angenehm eingeschätzt, während vier Teilnehmer diese gar als intuitiv bzw. selbsterklärend bezeichneten. Die Bewertung der Studienteilnehmer über das freie Feedback im Kommentarfeld deckt sich somit mit den Einschätzungen, die über den AttrakDiff-Fragebogen strukturiert erfasst wurden DISKUSSION UND SCHLUSSFOLGERUNG Resümierend kann festgehalten werden, dass bei der Durchführung einer Impact Analyse die Repräsentationsform auf viele der untersuchten abhängigen Variablen einen signifikanten Einfluss hat. So wurde nachgewiesen, dass die Durchführung der Impact Analyse mit der Node-Link-Anwendung signifikant schneller möglich ist, als mit den beiden alternativen Repräsentationsformen. Damit kann die Nullhypothese, wonach die Repräsentationsform keinen Einfluss auf die benötigte Lösungszeit und erzielte Korrektheit hat, als falsifiziert betrachtet werden. Da jedoch kein signifikanter Einfluss der Repräsentationsform auf die Korrektheit der ermittelten Lösungselemente nachgewiesen werden konnte, kann die korrespondierende Hypothese nur eingeschränkt bestätigt werden. Nichtsdestotrotz erscheint die Visualisierungsanwendung Ariadne s Eye für Impact Analysen deutlich besser geeignet zu sein, als die alternativen Repräsentationsformen Liste oder Matrix. Das belegen, neben der reduzierten benötigten Bearbeitungszeit, die Ergebnisse der weiteren ausgewerteten abhängigen Variablen. Auf die Attraktivität der Anwendung, die mittels des AttrakDiff-Fragebogens erfasst wurde, konnte ein sehr signifikanter Einfluss der Repräsentationsformen nachgewiesen werden, wobei die Anwendung Ariadne s Eye deutlich am besten bewertet wurde. Die wahrgenommene Belastung durch die Anwendung, die mittels NASA-TLX-Fragebogen ermittelt wurde, war in der Node-Link-Anwendung durchschnittlich am geringsten bei einem nachgewiesenen tendenziell signifikanten Einfluss der Reprä- 231

261 7 Software-Prototyp zur visuellen Impact Analyse sentationsform. Bei der Bewertung der Interaktionsintensität der Eingabegeräte ergab sich kein derart eindeutiges Bild. Der einzig signifikante Einfluss der Repräsentationsformen wurde beim Scrollen mit dem Mausrad festgestellt, wobei diese Art der Gerätenutzung beim Arbeiten mit Ariadne s Eye mit Abstand am wenigsten vonnöten war. Auch beim direkten Feedback der Studienteilnehmer hat die Anwendung Ariadne s Eye am besten abgeschnitten, da sie durchschnittlich die positivsten Bewertungen erhalten hat. Durch die Ergebnisse der hier präsentieren Nutzerstudie konnte nachgewiesen werden, dass für den Anwendungsfall einer Impact Analyse die visuelle Repräsentation der Traceability- Informationen am adäquatesten mittels einer Node-Link-Anwendung erfolgt. Zu berücksichtigen ist jedoch, dass diese Aussage auf die konkrete Ausprägung des Node-Link-Diagramms im Layout von Ariadne s Eye begrenzt ist. Für andere Node-Link-Layouts müssen die Ergebnisse kritisch hinterfragt und ggf. erneut evaluiert werden. Außerdem ist die vergleichsweise geringe Anzahl an Studienteilnehmern ein Faktor, der die externe Validität der Studie limitiert, obgleich die Varianzanalyse diese Unsicherheit bei der Berechnung der Irrtumswahrscheinlichkeit berücksichtigt. Dennoch ist für weiterführende Untersuchungen eine größere Anzahl an Studienteilnehmern vorzusehen. Unabhängig davon sind die gewonnenen Erkenntnisse der Studie für eine kommerzielle Implementierung als Unterstützungswerkzeug für das Änderungsmanagement relevant. Insbesondere wenn berücksichtigt wird, dass die Mehrheit der aktuell verfügbaren Werkzeuge, auf den beiden alternativen Repräsentationen Liste oder Matrix basiert. Für jedwede Impact- Analyse-Anwendung muss jedoch immer berücksichtigt werden, dass das Maß an Unterstützung nicht das Risiko kompensieren kann, welches allen vorgestellten Traceability-basierten Methoden immanent ist: in der Analyse verwendete fehlerhafte Tracelinks können zu fehlerhaften Ergebnissen in der Anwendung der Methoden führen. Daher sollte im mechatronischen Kontext die endgültige Entscheidung über die Betroffenheit eines Elementes einem erfahrenen Entwickler obliegen. Was die informationstechnische Unterstützung jedoch leisten kann, ist die Vorauswahl und visuelle Aufbereitung der potentiell betroffenen Elemente, um die Entwickler von diesen Tätigkeiten zu entlasten und die eigentliche Bewertung effizient zu gestalten. In diesem Sinne soll das Traceability-Visualisierungskonzept Ariadne s Eye zu einem visuellen Impact-Analyse-Assistenzwerkzeug weiterentwickelt werden. Die Herleitung und konkrete Ausprägung dieses Werkzeugs wird im folgenden Kapitel 7.4 vorgestellt INTERAKTIONS- UND VISUALISIERUNGSKONZEPT FÜR EINEN DIALOGBASIERTEN IMPACT-ANALYSE-ASSISTENTEN Gegenstand des Kapitels 7.4 ist die Herleitung und Entwicklung eines Interaktions- und Visualisierungskonzepts zur visuellen Unterstützung bei Analysen der modellübergreifenden Auswirkungen von Änderungen. Ein entsprechendes Werkzeug kann die beteiligten Entwickler dabei unterstützen, die Konsequenzen einer konkreten Änderung abzuschätzen und auf dieser Basis unterschiedliche Änderungsalternativen zu bewerten. Die Grundlagen für das 232

262 7 Software-Prototyp zur visuellen Impact Analyse Konzept bilden dabei einerseits der in Kapitel 6 entwickelte Impact-Analyse-Algorithmus und andererseits das in Kapitel 5 entwickelte Visualisierungskonzept Ariadne s Eye. Dazu werden zunächst im folgenden Kapitel Anforderungen an das Interaktions- und Visualisierungskonzept formuliert. Die zur Erfüllung der Anforderungen notwendigen Funktionalitäten sowie die daraus folgenden konzeptionellen Festlegungen für die Implementierung des Impact-Analyse-Assistenten werden in Kapitel beschrieben ANFORDERUNGEN AN DEN DIALOGBASIERTEN IMPACT-ANALYSE-ASSISTENTEN Die in Kapitel 5 herausgearbeiteten Anforderungen an das Traceability-Visualisierungskonzept Ariadne s Eye (wie bspw. flexible Anzahl und Art der darzustellenden Artefakte oder vorzusehende Interaktionsmechanismen wie Skalieren und Verschieben etc.) behalten auch für die visuelle Unterstützung der Impact Analyse ihre Gültigkeit. Zusätzlich dazu werden in diesem Kapitel Anforderungen abgeleitet und formuliert, die speziell für eine visuelle Nutzerunterstützung bei der Durchführung einer Impact Analyse benötigt werden. Eine allgemeine Anforderung an den zu entwickelnden Impact-Analyse-Assistenten betrifft dessen einfache Bedienbarkeit, damit dieser auch von Nicht-Experten genutzt werden kann [PARVAN ET AL. 2010]. Der Hintergrund ist, dass Änderungen an eine Vielzahl von Entwicklungsbeteiligten mit unterschiedlichem Hintergrund kommuniziert werden müssen [ECKERT ET AL. 2004, S. 19], darunter sowohl stark spezialisierte Entwickler als auch Projektmanager [WYNN ET AL. 2010b, S. 1700]. Dazu ist ein eingängiger und iterativer Bewertungsmechanismus für die zu betrachtenden Elemente vorzusehen. Der Assistent soll dabei ein schrittweises, strukturiertes Vorgehen realisieren, da dadurch bessere Ergebnisse bei der Impact Analyse erzielt werden [BIANCHI ET AL. 2000]. Dazu müssen jedem zu betrachtenden Element einer der drei möglichen Zustände zugewiesen werden können. Neben der Bestätigung und der Verneinung einer Änderungsauswirkung auf das betrachtete Element muss eine Entscheidung zudem zurückgestellt werden können, um sie zu einem späteren Zeitpunkt treffen zu können. Wird ein Element zurückgestellt, sollen die Entscheidungen für alle durch dessen Änderung potentiell betroffenen Folgeelemente ebenfalls zurückgestellt werden. Zurückgestellte Entscheidungen sollten dabei vom Assistenzsystem nach einem vollständigen Durchlauf aller zu bewertenden Elemente automatisch wieder aufgerufen werden. Irrtümliche Eingaben sowie die daraus resultierenden Zustandsänderungen nachfolgender Elemente müssen widerrufbar sein. Eine Impact Analyse soll erst als beendet betrachtet werden, wann alle potentiell betroffenen Elemente bewertet wurden. Ein Pausieren und Fortsetzen der Impact Analyse soll hingegen jederzeit möglich sein. Der Dialog zur Eingabe der Änderungsentscheidung ist in räumlicher Nähe zum betrachteten Element zu positionieren, ohne dabei die Lesbarkeit der für die Kontexterfassung relevanten Visualisierungsobjekte (Bezeichner, Tracelink und Pfad zum Wurzelknoten) zu überdecken. Die Befehlseingabe soll u. a. über Shortcuts möglich sein, um eine zügige Abarbeitung ohne zwingend notwendige Verwendung des Interaktionsgeräts Maus zu ermöglichen. Um den ak- 233

263 7 Software-Prototyp zur visuellen Impact Analyse tuellen Stand der Bearbeitung anzuzeigen, ist eine schematische Darstellung des aktuellen Bearbeitungsfortschritts vorzusehen. Ist das zu ändernde Element im Traceability-Visualisierungswerkzeug Ariadne s Eye identifiziert und selektiert, soll der Impact-Analyse-Assistent direkt aus Ariadne s Eye heraus gestartet werden können. Im Assistenzwerkzeug soll daraufhin eine automatische Identifikation und schrittweise Vorauswahl der potentiell betroffenen Elemente (CIS) erfolgen [LANDESBERGER ET AL. 2010]. Alle nicht in die Impact Analyse involvierten Elemente sollen reduziert dargestellt werden, um die Informationsdichte zu minimieren. Das aktuell zu betrachtende sowie das die Änderung potentiell verursachende Element sind in der Darstellung hervorzuheben, um ein eingängiges Erfassen von Quell- und Zielelement ohne Suchaufwand zu gewährleisten. Ferner soll zu jeder Zeit der Kontext des aktuell zu bewertenden Elements angezeigt werden. Dafür müssen die hierarchische Einordnung von Quell- und Zielelement innerhalb des jeweiligen Artefakts, gemäß der Anforderungen von [FURNAS 1986] und [ABELLO ET AL. 2006], sowie der bisherige Änderungspfad abgebildet werden. Dadurch kann leichter nachvollzogen werden, was diese Änderung ursprünglich verursacht hat [ALMEFELT ET AL. 2006, S. 127]. Ebenso sind die bereits bewerteten Elemente entsprechend des ihnen zugewiesenen Status farblich zu markieren, um eine globale Übersicht über den bisherigen Entscheidungsprozess zu ermöglichen. Ist ein zu überprüfendes Element bewertet worden, soll der Assistent automatisch zu dem nächsten zu bewertenden Element springen, wobei zur Erhaltung der Mental Map nicht die Artefakte sondern das Dialogfenster neu zu positionieren ist. Das Vorgehen ist derart zu gestalten, dass die inhaltlichen Sprünge innerhalb der Artefakte minimiert werden. Vorzusehen ist ferner eine Funktionalität zum manuellen Inkludieren von einzelnen, nicht-erfassten Elementen in die Impact Analyse, da die gewünschte Vollständigkeit des Traceability-Modells zwar ein theoretisches Postulat, aber in der Praxis nur schwerlich zu erreichen ist [WINKLER UND PILGRIM 2010, S. 545]. Analog dazu müssen auch irrtümlich inkludierte Elemente durch den Anwender abwählbar sein. Zur späteren Nachvollziehbarkeit des Änderungspfads soll für jede Entscheidung und die konkrete Ausprägung der gewünschten Änderung [WYNN ET AL. 2010b, S. 1701] eine Begründung textuell dokumentiert werden können [MAUS UND WEBER 2005, S. 227]. Diese Begründung sollte dem jeweiligen Tracelink, der zu änderndes und zu überprüfendes Element miteinander verbindet, informationstechnisch angehangen werden [PAVLOPOULOS ET AL. 2008, S. 4; BODE UND RIEBISCH 2009, S. 90]. Diese Anforderung nach einem Mechanismus für einen Wissenstransfer wurde auch von industriellen Anwendern gestellt [JARRATT ET AL. 2004, S. 11]. Aus diesem Grund ist für jede Entscheidung ein Kommentarfeld vorzusehen. Änderungen an einem einzelnen Element können, durch dessen Verknüpfung zu unterschiedlichen Elementen, mehrere Ursachen haben, die sich in unterschiedlichen Änderungspfaden manifestieren (siehe Abbildung 88). Das Assistenzsystem muss daher Mehrfachbewertungen einzelner Elemente zulassen, sofern die Änderung von einem anderen Element ausgeht, als bei der vorhergehenden Bewertung betrachtet wurde. 234

264 7 Software-Prototyp zur visuellen Impact Analyse Anforderungen A1 A1.1 A1.1.1 A1.1.2 A1.2 Funktionen F1 F1.1 F1.2 F1.3 Produktstruktur P1 P1.1 P2.1 P2.1.1 Änderungspfad 2 Änderungspfad 1 Abbildung 88: Schematische Darstellung der Notwenigkeit von Mehrfachbewertungen Die im Rahmen der Impact Analyse generierten Informationen sollen zu jeder Zeit speicherbar und wieder aufrufbar sein. Wird eine Analyse fortgesetzt, soll der Assistent an der letzten vor dem Beenden betrachteten Position wieder einsetzen. Zusätzlich dazu sollen die Meta- Informationen Autor, zu änderndes Startelement, Beschreibung der Änderung, Änderungstyp, Erstellungsdatum und Änderungsdatum bei Beginn jeder neuen Impact Analyse erfasst und gespeichert werden, um die Datensätze mehrerer Impact Analysen desselben Produkts zuordnen zu können. Ein potentielles Anwendungsszenario für den Impact-Analyse-Assistenten ist ein Design Review 95, in dem Experten unterschiedlicher Disziplinen die jeweiligen Änderungsentscheidungen treffen. Das Ziel eines solchen Design Reviews wäre es demnach, die von der Änderung tatsächlich betroffenen Elemente vollständig zu identifizieren. Die eigentliche Umsetzung der Änderungen an den Elementen erfolgt in einem Folgeprozess durch die für das jeweilige Element verantwortlich zeichnenden Entwickler. Denen müssen die Ergebnisse der Impact Analyse somit in einem gängigen Format bereitgestellt werden. Die während der Impact Analyse aggregierten Informationen sollten daher extrahierbar sein [SHNEIDERMAN 1996, S. 340] und bspw. über einen Report für den späteren Gebrauch nutzbar gemacht werden. Dieser Report hat alle für eine weitere Umsetzung der Änderung relevanten Informationen zu enthalten, muss leicht interpretierbar sein und in einem Disziplin-übergreifend etablierten Datenformat abgespeichert werden FUNKTIONALES KONZEPT FÜR EINEN DIALOGBASIERTEN IMPACT-ANALYSE- ASSISTENTEN Das Traceability-Visualisierungswerkzeug Ariadne s Eye soll um einen separaten Modus ergänzt werden, bei dem ein dialogbasiertes Assistenzwerkzeug die Durchführung von Impact Analysen unterstützt. Im Folgenden ist ausgeführt, wie das funktionale Konzept dieses Assistenzwerkzeugs gestaltet sein soll, um den Anforderungen aus Kapitel gerecht zu werden. 95 Alternativ kann der Impact-Analyse-Assistent auch in Design Change Meetings oder vergleichbaren Situationen genutzt werden. 235

265 7 Software-Prototyp zur visuellen Impact Analyse Konzept zur Informationsvisualisierung Der ingenieurtechnische Zweck einer Impact Analyse besteht darin, die Auswirkungen einer Änderung eines Quellelements auf dessen verknüpfte Zielelemente zu evaluieren. Dazu muss für eine große Anzahl an Elementpaaren sukzessive entschieden werden, ob ein aktuell betrachtetes Quellelement seine Änderung auf das aktuell betrachtet Zielelement propagiert. Daher müssen insbesondere diese beiden aktuell zu betrachtenden Objekte sowie deren Verknüpfung jeweils visuell hervorgehoben werden. Zusätzlich sind die zum eingängigen Verständnis des Artefaktkontexts notwendigen Elternelemente (entlang der beiden Pfade zum Wurzelknoten) innerhalb des jeweiligen Artefakts sowie der bisher durchlaufene Änderungspfad visuell hervorzuheben. Ferner sind Knoten und Bezeichner von Elementen, die im Rahmen der Impact Analyse keine Relevanz haben, im Sinne einer Informationsreduzierung auszugrauen und die Knoten bereits bewerteter Elemente über Zuweisung einer entsprechenden, eingängigen Farbcodierung zu kennzeichnen. Die daraus abgeleiteten Festlegungen hinsichtlich der konkreten Ausprägung der Visualisierungsobjekte sind Tabelle 41 zu entnehmen. Visualisierungsobjekt Knoten Kante Bezeichner Startelement (SIS) Blau - Schwarz Zielelement Gelb, blaue Kontur; Größe +30 px - Blau; 120 pt Quellelement Dunkelgrau - Schwarz; 100 pt Tracelink zwischen Quellund Zielelement - Rot; 13 px - Elternelemente des Zielelements Dunkelgrau Dunkelgrau Blau; Erhöhte Schriftgröße Elternelemente des Quellelements Dunkelgrau Dunkelgrau Schwarz; Erhöhte Schriftgröße Noch nicht bewertetes Element (CIS) Betroffenes Element (AIS) Dunkelgrau Hellgrau Schwarz Rot Dunkelgrau Hellgrau Manuell ergänztes, betroffenes Element (DIS) Selektiert: gelb Bewertet: rot - Dunkelgrau; Normale Schriftgröße Nicht-betroffenes Element (FPIS) Element-Bewertung verschoben (weiterhin CIS) Nicht zu betrachtende Elemente Grün Hellgrau Hellgrau Dunkelgrau Hellgrau Schwarz Hellgrau Hellgrau Hellgrau 236

266 7 Software-Prototyp zur visuellen Impact Analyse Visualisierungsobjekt Knoten Kante Bezeichner Bisheriger Änderungspfad SIS: blau AIS: rot blau Dunkelgrau; Normale Schriftgröße Tabelle 41: Festlegungen zu den Ausprägungen der Visualisierungsobjekte Der Anforderung nach dem Erhalt der Mental Map folgend, verbleibt das Layout der Artefakte und der Tracelinks statisch, während die Positionierung des Dialogfensters dynamisch erfolgt. Bei der Neupositionierung des Dialogfensters wird eine räumliche Nähe zu dem zu bewertenden Element angestrebt, ohne dabei relevante Kontextinformationen zu überlagern. Die Berechnung der Positionierung des Dialogfensters erfolgt daher auf Basis der existierenden Informationen über den Verlauf des spezifischen Tracelinks (Mittelpunkt und Steigung), den statischen Mittelpunkt des gesamten Traceability-Modells, die Koordinaten des Zielelements und die fixe Größe des Dialogfensters. Da Anwender unter Umständen weitere Informationen aus dem Traceability-Graphen zur Entscheidungsfindung betrachten wollen, ist das Dialogfenster zudem per Maus verschiebbar gestaltet. Das Dialogfenster an sich besteht aus drei Schaltflächen jeweils eine je zuweisbarem Status sowie einem Freitextfeld für die Eingabe der Entscheidungsbegründung. Sobald eine der Schaltflächen ausgewählt wird, gilt die Bewertung als abgeschlossen. Der zugewiesene Status und der Inhalt des Kommentarfeldes werden gespeichert und der Assistent springt automatisch zur Bewertung des nächsten Elements. Konzept zum Programmablauf Jede visuell unterstützte Impact Analyse beginnt, indem das zu ändernde Element in Ariadne s Eye gesucht, identifiziert und selektiert wird. Durch einen Rechtsklick auf den entsprechenden Elementknoten erscheint ein Kontextmenü, aus dem der Befehl Start Impact Analysis aufgerufen wird. Es öffnet sich ein Dialogfenster, in dem zunächst die Metadaten der Impact Analyse einzugeben sind, die auf Seite 240 näher spezifiziert werden. Ist die Metadaten-Eingabe beendet, öffnet sich der eigentliche Impact-Analyse-Assistent, wobei im Hintergrund eine automatische Vorabberechnung der Teilmenge CIS erfolgt, sodass deren visuelle Hervorhebung (Details siehe Tabelle 41) bereits in der Startansicht zur Anwendung kommt. Das abstrakte Vorgehen zur Ermittlung der für die Impact Analyse relevanten Teilmengen kann Kapitel entnommen werden. Für die Implementierung wurden leichte Anpassungen vorgenommen, die im Wesentlichen auf eine bessere informationstechnische Umsetzbarkeit zielen, an dieser Stelle jedoch vernachlässigt werden können. An die Durchführung der Impact Analyse wurde die Anforderung formuliert, ein strukturiertes Vorgehen mit einer minimierten Anzahl an inhaltlichen Sprüngen zu realisieren. Dies wird einerseits dadurch ermöglicht, dass das schrittweise Vorgehen einem vorgegebenen Muster folgt, und somit reproduzierbar ist, und zum anderen sich die Abarbeitungsreihenfolge der Elemente an der hierarchischen Nähe der Elemente orientiert. Sind bspw. mehrere Kinder eines Elternelementes (wie F1.1.1 und F1.1.2 in Abbildung 89) mit einem geänderten Quellelement verknüpft, werden diese Geschwister direkt nacheinander bewertet, bevor andere 237

267 7 Software-Prototyp zur visuellen Impact Analyse potentiell betroffene und damit zu überprüfende Elemente betrachtet werden (wie F oder F1.7.2), um den kognitiv bereits hergestellten hierarchischen Kontext des gemeinsamen Elternelements zu erhalten. Sind demnach alle in Abbildung 89 orange unterlegten Elemente zu betrachten, würden die beteiligten Geschwisterpaare direkt aufeinanderfolgend bewertet werden. Daraus ergibt sich die in Abbildung 89 dargestellte und durch die Ziffern symbolisierte Abarbeitungsabfolge. Sind alle verknüpften Zielelemente bewertet, müssen die Auswirkungen des nächsten Quellelements 96 überprüft werden. Die Abarbeitungsreihenfolge der Quellelemente erfolgt daher analog zur beschriebenen hierarchischen Sortierung der Zielelemente. Abbildung 89: Traversierende Abarbeitungsreihenfolge der Elemente eines Artefakts in Abhängigkeit der hierarchischen Nähe Bei der eigentlichen Bewertungsaktivität ist zu entscheiden, ob sich die Änderung des Quellelements auf das aktuell zu betrachtende Zielelement auswirkt. Ist die diesbezügliche Entscheidung gefallen, wird eine kurze Begründung in das Freitextfeld für Kommentare eingegeben und anschließend die entsprechende Schaltfläche angeklickt. In Abhängigkeit der erfolgten Entscheidung sind dabei die drei möglichen Fälle anwählbar: 96 Elemente, für die in einer vorherigen Stufe der Impact Analyse entschieden wurde, dass sie von der Änderung betroffen sind, werden in nachfolgenden Stufen ebenfalls zu Quellelementen. 238

268 7 Software-Prototyp zur visuellen Impact Analyse Impacted: Das aktuell betrachtete Element ist von der Änderung des vorgehenden Elements selbst betroffen. Das Element wird der Menge der tatsächlich betroffenen Elemente (AIS) hinzugefügt und durch rote Einfärbung visuell als betroffen markiert. Die auf dem Änderungspfad folgenden Elemente verbleiben in der Menge der potentiell betroffenen Elemente (CIS). Der Status bestätigt für das betrachtete Zielelement, das verursachende Quellelement sowie der dazugehörige Kommentar werden abgespeichert. Not impacted: Das aktuell betrachtete Element ist von der Änderung des vorgehenden Elements selbst nicht betroffen. Das Element wird der Menge der fälschlicherweise identifizierten Elemente (FPIS) hinzugefügt und durch grüne Einfärbung visuell als nicht betroffen markiert. Die auf dem Änderungspfad folgenden Elemente werden ebenfalls der Menge der FPIS zugeordnet (insofern sie nicht über Änderungspfade anderer Elemente noch als potentiell betroffen klassifiziert sind). Der Status verworfen für das betrachtete Zielelement, das verursachende Quellelement sowie der dazugehörige Kommentar werden abgespeichert. Postpone: Da das aktuell betrachtete Element augenblicklich nicht bewertet werden kann, wird ihm sowie allen folgenden Elementen desselben Änderungspfades formell der Status verschoben zugewiesen, was inhaltlich bedeutet, dass sie weiterhin als potentiell betroffen (CIS) behandelt werden. Sind alle weiteren CIS bewertet worden, werden die Elemente des Status` verschoben zur erneuten Bewertung aufgerufen. Ein Sonderfall ist die manuelle Ergänzung eines einzelnen Elements als von der Änderung betroffen durch den Anwender. Dies erfolgt über einen Rechtsklick auf das entsprechende Element, in dessen Folge ein Kontextmenü erscheint, mit welchem dem Element der Status betroffen zugewiesen werden kann. In diesem Fall wird das Element der Menge der tatsächlich betroffenen Elemente (AIS) hinzugefügt, durch rote Einfärbung visuell als betroffen markiert. Zusätzlich wird geprüft, ob von ihm ausgehend weitere potentiell betroffene Elemente identifiziert werden können, welche ihrerseits der Menge der CIS hinzuzufügen sind. Das manuelle Exkludieren erfolgt analog zum Inkludieren ebenfalls über einen Rechtsklick auf das entsprechende Element sowie die Auswahl des entsprechenden Befehls in einem Kontextmenü. Um die geforderte Mehrfachbewertung einzelner Elemente zu ermöglich, ist es zwingend erforderlich, dass die Impact Analyse gerichtet erfolgt. Wird für jede Entscheidung das die Änderung verursachende Quellelement abgespeichert, kann das Programm ermitteln, ob die Änderung des Zielelements vom gleichen Vorgängerelement verursacht wird. Ist dies der Fall, ist eine erneute Überprüfung nicht notwendig. Geht die Änderung von einem anderen Quellelement aus, ist eine Überprüfung zwingend erforderlich. Aus diesem Grund müssen zu jeder Elementbewertung neben dem Kommentar auch die Daten zum Vorgängerelement gespeichert werden. Eine entsprechende Erweiterung am Datenmodell des Assistenzsystems ist vorzunehmen (siehe Erläuterungen zu Abbildung 90). Nach jeder abgeschlossenen Bewertung eines Elements erfolgt eine automatische Neuberechnung und, sofern notwendig, eine visuelle Anpassung der Status aller dadurch betroffe- 239

269 7 Software-Prototyp zur visuellen Impact Analyse nen Elemente. Diese iterative Bewertungsprozedur wird für jedes durch den Algorithmus identifizierte Element der CIS wiederholt, bis alle Elemente entweder bestätigt oder verworfen sind. Wenn dieser Status erreicht ist, wird der Nutzer über das Ende der Impact Analyse informiert. Konzept zur informationstechnischen Datenverwaltung Ein geeignetes Konzept zur Datenverwaltung wird benötigt, um sicherzustellen, dass sowohl der hohe investierte Aufwand informationstechnisch gesichert wird, als auch die dokumentierten Entscheidungen für eine spätere Weiterverwendung in folgenden Ingenieursprozessen nutzbar gemacht werden. Um die einmal eingegebenen Daten zu sichern, führt jedes Schließen des Impact-Analyse- Assistenten zum automatischen Speichern des zu diesem Zeitpunkt vorliegenden Bearbeitungsstands. Zudem können vormals begonnene und bereits abgeschlossene Impact Analysen aus dem Assistenten heraus verwaltet werden. Dazu bietet das Werkzeug ein separates Dialogfenster mit einer tabellarischen Übersicht der in der Datenbank erfassten Impact Analysen samt zugehöriger Metadaten und Bearbeitungsstatus (in Prozent). Aus dem Dialogfenster heraus können diese Datensätze geladen oder gelöscht sowie in einen Report exportiert werden. Wird eine bereits begonnene Impact Analyse geladen, öffnet sich der Impact- Analyse-Assistent in der letzten gespeicherten Ansicht und fragt die Bewertung für das in der Reihenfolge nächste noch nicht bewertete Element ab. Dazu notwendig ist die Erfassung von Metadaten: Produkt, zu änderndes Startelement (werden vom Assistenten automatisch erfasst), Autor, Beschreibung der Änderung und Änderungstyp (sind vom Anwender manuell einzugeben), sowie Erstellungs- und Änderungsdatum (werden vom Programm automatisch erfasst). Die genannten Metadaten werden in der Klasse ImpactAnalysis gespeichert. Die weiter oben geforderte Erfassung des Vorgängerelements zur Ermöglichung einer Mehrfachbewertung von Elementen wird über die Klasse ImpactAnalysisElement realisiert. Darin wird über das Attribut elementsource vom Typ Element zu jedem bewerteten Element das Vorgängerelement gespeichert. Zusätzlich trägt die Klasse noch das Attribut startelement, worüber aus allen betrachteten Elementen das Startelement identifiziert werden kann, das Attribut analysislevel, als Information über die aktuelle Iterationstiefe, sowie die Attribute comment und impactstate, welche die Informationen zur jeweiligen Bewertung enthalten. In der Klasse ImpactAnalysisState wird der Status der jeweiligen Elementbewertung abgelegt, wobei neben den drei beschriebenen Möglichkeiten Bestätigung (ACCEPTED), Ablehnung (DECLINED) und Verschieben (POSTPONED) noch der Zustand UNREVIEWED vorgesehen ist, der zunächst allen Elemente standardmäßig zugewiesen wird und angibt, dass diese noch nicht zur Bewertung vorgeschlagen wurden. Der in diesem Zusammenhang beschriebene Sonderfall der manuellen Ergänzung eines betroffenen Elements wird datentechnisch über die Klasse ImpactAnalysisElementAdditional realisiert. Daraus ergibt sich das in Abbildung 90 dargestellte Datenmodell für den Impact-Analyse- Assistenten, das eine Erweiterung des ModelTracer-Datenmodells (siehe Kapitel 3.6) ist. 240

270 7 Software-Prototyp zur visuellen Impact Analyse Abbildung 90: Datenmodell für den Impact-Analyse-Assistenten Ferner erlaubt das Programm das Ausleiten eines Reports mit den bisherigen Ergebnissen der durchgeführten Impact Analyse (nicht bewertete und verschobene Elemente sind nicht enthalten). Der Report in Form einer Excel-Datei beinhaltet neben den entsprechenden Metadaten der Analyse zwei Tabellenblätter. Auf einem Tabellenblatt sind alle betroffenen Elemente, auf dem anderen Tabellenblatt alle nicht betroffenen Elemente alphabetisch sortiert aufgelistet. Zu jedem bewerteten Element werden in weiteren Spalten zusätzlich die Informationen Bezeichner, Identifizierer und Artefakt jeweils von Ziel- und zugehörigem Quellelement sowie der eingegebene Kommentar zur Entscheidungsbegründung ausgegeben. Alle an dieser Stelle aufgeführten administrativen Funktionen werden über Befehle in einer Toolbar angeboten. Die Summe der beschriebenen Funktionalitäten ermöglicht es dem Impact-Analyse-Assistenten, den in Abbildung 91 dargestellten abstrakten Programmablauf an- 241

271 7 Software-Prototyp zur visuellen Impact Analyse zubieten. Die konkrete Umsetzung der Funktionen als prototypisches Werkzeug wird in dem folgenden Kapitel 7.5 beschrieben. Abbildung 91: Ablaufdiagramm des Impact-Analyse-Assistenten auf Basis des funktionalen Konzepts 7.5. PROTOTYPISCHE IMPLEMENTIERUNG DES DIALOGBASIERTEN IMPACT- ANALYSE-ASSISTENTEN In diesem Kapitel werden einige Umsetzungsdetails des Impact-Analyse-Assistenten sowie dessen funktionaler Ablauf am entwickelten Prototyp beschrieben. Dazu wird ein einfaches Beispiel einer Impact Analyse anhand der drei Artefakte (Anforderungen, Funktionen und Produktstruktur) des Produktmodells Pedelec, welches auch in der Nutzerstudie in Kapitel 6.6 verwendet wurde, erläutert. Der Impact-Analyse-Assistent basiert auf dem vorgestellten Visualisierungswerkzeug Ariadne s Eye und setzt daher auf dem gleichen informationstechnischen Fundament auf. Daher wurde auch der Assistent als JUNG2-Graph in Java implementiert, wobei das Traceability- Modell der MySQL-Datenbank entnommen wird, die über den ModelTracer befüllt werden kann (siehe Kapitel 3.6), und deren Zugriff über das ORM-Framework Hibernate realisiert wird. Auf dem umgekehrten Weg erfolgt auch das Schreiben der erfassten Impact-Analyse- Daten in die Datenbank. Das in der Datenbank hinterlegte Datenmodell ist in Kapitel beschrieben und in Abbildung 90 dargestellt. Der Impact-Analyse-Assistent wird als separater Visualisierungsmodus aus Ariadne s Eye heraus gestartet. In dem betrachteten Pedelec-Beispiel soll die Anforderung der vierten Hierarchieebene A Motorunterstützung ab 25 km/h abschalten geändert werden, weil zukünftig nur 242

272 7 Software-Prototyp zur visuellen Impact Analyse eine Unterstützung durch den Elektromotor bis zu einer Geschwindigkeit von 20 km/h geleistet werden soll. Es wird daher in Ariadne s Eye über die Suchfunktion die genannte Anforderung identifiziert und selektiert sowie über einen Rechtsklick auf das Element das Kontextmenü zum Starten der Impact Analyse angewählt (siehe Abbildung 92). Abbildung 92: Starten des Impact-Analyse-Assistenten aus Ariadne's Eye Ist der Befehl Start impact analysis angewählt, öffnet sich ein Dialogfenster, in das die in Kapitel erläuterten Metadaten einzugeben sind. Als Beschreibung der Änderung wird Begrenzung der Motorunterstützung auf 20 km/h und als Änderungstyp Modifikation funktionale Anforderung an Motor eingegeben (siehe Abbildung 93). 243

273 7 Software-Prototyp zur visuellen Impact Analyse Abbildung 93: Eingabe der Metadaten für die startende Impact Analyse Über die Schaltfläche Start Impact Analysis wird der Bewertungsvorgang gestartet. Im Hintergrund ermittelt der Impact-Analyse-Assistent daraufhin automatisch die Maximalmenge der potentiell betroffenen Elemente (CIS). Alle sichtbaren Elemente werden visuell aufbereitet, entsprechend der Festlegungen aus dem funktionalen Konzept (siehe Tabelle 41 auf Seite 237), sodass alle CIS-Knoten dunkelgrau und zugehörige Bezeichner schwarz eingefärbt werden. Der Knoten des die Änderung verursachenden Startelements A Motorunterstützung ab 25 km/h abschalten wird für die gesamte Dauer der Analyse blau und sein Bezeichner schwarz eingefärbt. Das erste Element, für welches entschieden werden muss, ob es von der Änderung betroffen ist, ist die verknüpfte Funktion vierter Hierarchieebene F Geschwindigkeit / Drehzahl messen. Der Knoten dieses Zielelements wird daher gelb eingefärbt, sein Bezeichner wird vergrößert in blauer Schrift dargestellt und der verbindende, und damit die Änderung potentiell propagierende, Tracelink rot hervorgehoben (siehe Abbildung 94). Ferner werden die Knoten (dunkelgrau) und Bezeichner (schwarz bzw. blau) der beiden zugehörigen Wurzelpfade zum erleichterten Erfassen der hierarchischen Kontexte von Quell- und Zielelement farblich codiert. Unabhängig von der Maximalgeschwindigkeit, bei welcher die Motorunterstützung abgeschaltet werden soll, muss die aktuelle Geschwindigkeit des Pedelecs erfasst werden. Daher wird in das Kommentarfeld Geschwindigkeit muss weiterhin erfasst werden eingetragen und die Schaltfläche Not impacted betätigt. Die betrachtete Funktion selbst verbleibt trotz der Ablehnung im CIS-Status (dunkelgrau), weil sie noch über die Änderung eines anderen CIS-Elements betroffen sein könnte. Alle nur über sie verknüpften vormaligen CIS-Elemente (hier: P1.9.2 Anschluss Drehzahlsensor ) können nun nicht länger von der Änderung betroffen sein, weswegen sie der FPIS-Menge zugewiesen (grüner Knoten) und nicht geprüft werden müssen. 244

274 7 Software-Prototyp zur visuellen Impact Analyse Abbildung 94: Bewertung der Betroffenheit einer verknüpften Funktion Der Impact-Analyse-Assistent springt daraufhin zum nächsten zu betrachtenden Element, der Funktion F Abschalten des Motors ab 25 km/h. Diese Funktion muss aufgrund der neu definierten Maximalgeschwindigkeit angepasst werden. Aus diesem Grund wird der Kommentar Geänderte Anforderung: Maximalgeschwindigkeit auf 20 km/h reduzieren eingegeben und die Schaltfläche Impacted betätigt. Eine am Design Review teilnehmende Expertin bemerkt daraufhin, dass die Funktion F Zur Tretkraft proportionalen Motorantrieb zuschalten fälschlicherweise nicht verknüpft ist (DIS) und daher der Impact Analyse manuell hinzugefügt werden muss, da die konkrete Realisierung unter Umständen angepasst werden muss. Dies erfolgt über die Selektion der Funktion (gelber Knoten) und Auswahl des Kontextmenüs über einen Rechtsklick (siehe Abbildung 95), woraufhin der entsprechende Knoten rot und der Bezeichner dunkelgrau markiert werden. Abbildung 95: Manuelles Hinzufügen einer fälschlicherweise nicht identifizierten Funktion In den folgenden Schritten wird das Bauteil P1.8.2 Drehzahlsensor abgelehnt, da es unverändert benötigt wird. Auch hier werden alle ausschließlich darüber verknüpften Elemente, die 245

275 7 Software-Prototyp zur visuellen Impact Analyse somit nicht weiter von der Änderung betroffen sein können, aus der Menge der CIS entfernt und mit grünen Knoten markiert. In der weiteren Folge werden die Anforderungen A Darf auf Radwegen genutzt werden, A Keine Versicherungspflicht in D/EU, A Keine Helmpflicht in D/EU, A Kann ohne weitere Erlaubnis gefahren werden und A Keine Zulassungspflicht in D/EU als von der Änderung nicht betroffen abgelehnt (Begründung für alle: zulässige Höchstgeschwindigkeit weiterhin unterschritten ). Damit verbleiben drei Elemente der Produktstruktur, die potentiell von der Änderung betroffen sein könnten. Zunächst wird der Elektromotor P Radnabenmotor mit Generator (Kommentar: Gewählter Elektromotor auch für neue Leistungskennzahlen am besten geeignet ) und danach das Bauteil P1.9.6 Anschluss Motor (Kommentar: Motor verbleibt unverändert ) als nicht betroffen klassifiziert. Das letzte zu bewertende Bauteil P1.9.8 Motorcontroller ist hingegen von der Änderung betroffen. Der zugrunde liegende Änderungspfad, aus dem die Experten des Design Reviews entnehmen können, welche bisherigen Änderungen eine Anpassung dieses Bauteils verursachen, ist durch blau gefärbte Relationen repräsentiert. Das aktuell zu betrachtende Zielund Quellelement sowie deren jeweilige Wurzelpfade sind entsprechend der Festlegung im funktionalen Konzept ausgeprägt (siehe Abbildung 96). Abbildung 96: Motorcontroller wird als von der Änderung betroffen klassifiziert Zur Dokumentation der Änderungsentscheidung wird die Begründung Steuerung auf Abschalten der Motorunterstützung ab 20 km/h anpassen in das Kommentarfeld eingetragen und die Schaltfläche Impacted betätigt, woraufhin das Element der Menge der AIS zugeordnet wird und deren entsprechende visuelle Codierung erhält. Da somit alle CIS bewertet wurden, ist die Impact Analyse abgeschlossen. Das wird dem Nutzer über ein Pop-Up Fenster signalisiert (siehe Abbildung 97). 246

276 7 Software-Prototyp zur visuellen Impact Analyse Abbildung 97: Fenster zur Information über Abschluss der Impact Analyse Die Impact Analyse wird somit automatisch gespeichert. Sie soll abschließend in einen Excel-Report überführt werden, damit im Anschluss an das Design Review mit dessen Hilfe die jeweiligen Verantwortlichen entweder zur Anpassungsentwicklung aufgefordert (für alle betroffenen Elemente) bzw. über die Anforderungsänderung informiert (für alle nichtbetroffenen Elemente) werden können. Dazu kann entweder das Excel- oder das Öffnen- Symbol in der Toolbar betätigt werden. In diesem Beispiel hier wird das Öffnen-Symbol angewählt, wodurch eine Liste der letzten Impact Analysen inkl. jeweiliger Metadaten und Bearbeitungsstand angezeigt wird. In diesem Menü können alle vormaligen Impact Analysen verwaltet werden, indem diese geladen, gelöscht oder in einen Report gespeichert werden (siehe Abbildung 98). Im beschriebenen Beispiel wählt der Nutzer die letzte Impact Analyse aus und wählt die Schaltfläche Save Excel report an. Abbildung 98: Verwaltung bestehender Impact Analysen Die Erstellung und Ausgabe des Reports bzgl. der erfassten Daten der aktuellen Impact Analyse wird mittels der frei verfügbaren Bibliothek Java Excel API (JExcelApi) realisiert, womit ein MS Excel Dokument generiert wird. In diesem Dokument sind neben der erfassten Metadaten der Impact Analyse auch auf separaten Arbeitsblättern jeweils die tatsächlich betroffe- 247

277 7 Software-Prototyp zur visuellen Impact Analyse nen Elemente (AIS) bzw. die von den Entwicklern als nicht-betroffen klassifizierten Elemente (FPIS) listenartig aufgeführt (siehe Abbildung 99). Abbildung 99: Übersicht der nicht-betroffenen Elemente im Impact-Analyse-Report Dieser Report stellt somit die weitere Grundlage zur Information der Fachabteilungen dar, die auf Basis der jederzeit ladbaren visuellen Analyse sowie der dokumentierten Erläuterungen im Report die konkrete Anpassungsentwicklung betreiben können ZUSAMMENFASSUNG UND DISKUSSION In Kapitel 7 wurde die Entwicklung eines Dialog-basierten visuellen Impact-Analyse- Assistenten beschrieben, der den in Kapitel 6 entwickelten Algorithmus zur Änderungsabschätzung softwaretechnisch umsetzt. Dazu wurde zunächst der aktuelle Stand der Technik hinsichtlich der visuellen Unterstützbarkeit von Impact Analysen analysiert, aus dem keine zu präferierende Repräsentationsform abgeleitet werden konnte. Daher mussten die allgemeinen Erkenntnisse zur Informationsvisualisierung in der Mechatronik aus Kapitel 5.2 genutzt werden, um die Hypothese zu formulieren, dass ein Repräsentation mittels Node-Link- Diagramm für eine visuelle Impact-Analyse-Assistenz vermutlich besser geeignet ist, als die beiden alternativen Repräsentationsformen Abhängigkeitsmatrix und Liste. Diese Hypothese wurde im Anschluss mittels einer vergleichenden, empirischen Nutzerstudie verifiziert, in deren Ergebnis festgestellt werden konnte, dass eine Vielzahl der untersuchten Variablen (Bearbeitungszeit, Attraktivität der Anwendung und wahrgenommene Belastung) für das Node-Link-Diagramm im Ariadne s-eye-layout signifikant bessere Ergebnisse erbrachten als für die beiden alternativen Repräsentationsformen. Einschränkend muss festgehalten werden, dass ein Einfluss der Repräsentationsform auf die Korrektheit der ermittelten Lösungselemente nicht nachgewiesen werden konnte. Dennoch kann die For- 248

278 7 Software-Prototyp zur visuellen Impact Analyse schungsfrage dahingehend beantwortet werden, dass die Repräsentationsform einen erheblichen Einfluss auf die Eignung eines visuellen Impact-Analyse-Assistenten hat, wobei das Layout von Ariadne s Eye mit Abstand am besten geeignet ist. Auf Grundlage dieser Erkenntnis wurde daraufhin ein funktionales Interaktions- und Visualisierungskonzept für einen dialogbasierten Impact-Analyse-Assistenten entwickelt. Dazu wurden zunächst Anforderungen an einen solchen Assistenten spezifiziert, die anschließend in einem funktionalen Konzept umgesetzt wurden. Dabei wurden insbesondere Aspekte der Informationsvisualisierung, des strukturierten Ablaufs und der informationstechnischen Datenverwaltung betrachtet. Gemäß der Festlegungen von [BOHNER 2002, S. 268] verbindet der vorgestellte dialogbasierte Assistent somit ein induktives Impact-Analyse-Vorgehen, durch die automatisierte Identifikation potentiell betroffener Elemente mittels Traceability-Daten, mit einem deduktiven Impact-Analyse-Vorgehen, welches wiederum über die manuelle Bewertung der tatsächlichen Betroffenheit erfolgt. Aufbauend auf dem funktionalen Konzept wurde ein prototypisches Werkzeug implementiert, dessen Funktionalitäten und Umsetzungsdetails am Beispiel einer einfachen Impact Analyse aufgezeigt wurden. Der bewusst wenig komplex gewählte Änderungsfall diente dabei dem besseren Verständnis der allgemeinen Abläufe bei der Benutzung des Impact-Analyse- Assistenten in dessen potentieller Anwendung bei einem Design Review. Ferner wurde beschrieben, wie die konkreten Entscheidungsergebnisse in Form eines Berichts als Input für die nachfolgenden Anpassungsprozesse dienen können. Dies wäre ein potentieller Lösungsansatz für die in [STARK ET AL. 2012] festgestellten, weit verbreiteten Defizite bei der rechtzeitigen Kommunikation von nachträglichen Änderungen. Sind in den Metadaten aus den Autorenwerkzeugen zu jedem Elemente auch Informationen über deren jeweilige Autoren hinterlegt, könnte in einem nächsten Schritt ein automatisierter Workflow zur Information der betroffenen Entwickler, wie er bei [CLELAND-HUANG ET AL. 2003] angedacht wurde, bspw. über das automatische Versenden einer an alle im Report enthaltenen Element-Autoren, vorgesehen werden. Davor sollte jedoch kritisch geprüft werden, ob die Entwickler dies nicht als Informationsschwemme empfänden und wie das Versenden des Berichts an die endgültige Entscheidung zur Umsetzung einer Änderungsalternative, die häufig nicht im Design Review getroffen wird, gekoppelt werden kann. Neben den bereits in Kapitel 5.9 formulierten Verbesserungspotentialen hinsichtlich des Ariadne s-eye-layouts und den in Kapitel 6.7 beschriebenen Maßnahmen zur besseren Evaluierung des Impact-Analyse-Algorithmus, die einen direkten Einfluss auf den Impact-Analyse- Assistenten hätten, können auch Aspekte der eigentlichen Impact-Analyse-Visualisierung die Validität der Methode begrenzen. Aus den gewählten Screenshots wird bspw. ersichtlich, dass es durch die vergrößerte Schrift der Elemente entlang des Wurzelpfades in Ausnahmefällen (Bezeichner lang und Knoten horizontal annähernd auf einer Linie) zur Okklusion von Teilen der Bezeichner kommen kann. Dies ist in einer weiterführenden Entwicklung des Assistenzwerkzeugs zu verbessern. 249

279 7 Software-Prototyp zur visuellen Impact Analyse Des Weiteren wäre zu untersuchen, wie die getroffenen Festlegungen zur visuellen Kodierung der Informationsobjekte von den Anwendern bei deutlich komplexeren Änderungsszenarien und damit höheren Informationsdichten wahrgenommen werden. Zusätzlich besteht das Risiko, dass bei komplexeren Änderungen die hohe Anzahl der sequentiell zu bewertenden Elemente von den Anwendern als Belastung wahrgenommen wird. Diese Effekte sollten mittels am industriellen Umfang von Produktmodellen orientierten Untersuchungen überprüft werden. Ferner sollte zukünftig eine wissenschaftliche Evaluation der möglichen Abarbeitungsstrategien bei der Bewertung der einzelnen Elemente des CIS erfolgen. Dabei wäre zu untersuchen, ob deren Abarbeitung entsprechend der Iterationsstufen, wie sie derzeit vorgesehen und implementiert ist, gegenüber einer Strategie, bei welcher jeder Änderungspfad erst zu Ende bewertet wird, bevor der nächste betrachtet wird, kognitiv zu bevorzugen wäre. Hinsichtlich der visualisierten Informationen kann zudem erwogen werden, einzelne Artefakttypen mit existierenden Metadaten, wie bspw. dem Reifegrad eines Bauteils aus dem PLM- System für eine Managementsicht, oder der Anzeige einer stochastisch ermittelten Änderungskritikalität auf Basis historischer Daten zu erweitern. Der vorgestellte Impact-Analyse-Assistent ist in seiner derzeitigen Form bewusst intuitiv konzipiert worden, sodass er von allen Entwicklern lesend genutzt werden kann, um für sie relevante, bereits getroffene Änderungsentscheidungen visuell nachzuvollziehen. Dies ist von großer Bedeutung, wenn man berücksichtigt, dass durch eine eingängige Impact Analyse das Verständnis des betrachteten Systems verbessert wird [FASOLINO UND VISSAGGIO 1999, S. 64; REN ET AL. 2004, S. 432] und das bessere Verständnis der Ursachen und Auswirkungen von Änderungen zu besseren Produkten führt [FRICKE ET AL. 2000, S. 176]. Mit den beschriebenen Funktionalitäten des Impact-Analyse-Assistenten werden auch wesentliche Anforderungen des Teil 8 der ISO erfüllt. Demnach sollen im Rahmen einer Impact Analyse u. a. die Art der Änderung dokumentiert sowie alle betroffenen Elemente identifiziert werden [ISO ]. Durch die im Assistenten realisierte Funktionalität zur Artefakt-übergreifenden Impact Analyse ist gemäß dem technischen Report ISO/IEC TR 24766:2009 Information technology - Systems and software engineering auch das geforderte primäre Ziel von Traceability informationstechnisch umgesetzt. Zudem adressiert der Impact-Analyse-Assistent ein in [HORVATH UND RUDAS 2007] formuliertes Defizit, wonach Werkzeuge aus dem PLM-Umfeld die Entscheidungsfindung wenig unterstützen, da darin die gegenseitige Beeinflussung der Objekte nicht umfassend abgebildet wird. Aus all diesen geschilderten Gründen kann nachempfunden werden, warum laut [KELLER ET AL. 2005, S. 10] die Visualisierung von Änderungsauswirkungen im industriellen Umfeld von besonderem Interesse ist. 250

280 8. ZUSAMMENFASSUNG UND AUSBLICK Du siehst den Wald vor lauter Bäumen nicht! ist eine bekannte sprichwörtliche Metapher für den kognitiven Konflikt zwischen einer großen Anzahl an Detailinformationen und deren gleichzeitig notwendiger Einordnung in den übergeordneten Kontext. Auch in der Entwicklung mechatronischer Produkte ist diese Herausforderung zwischen notwendiger Detailinformation und Übersicht gegeben. Bei komplexen Systemen ist es selbst für erfahrene Entwickler kaum möglich, einen umfassenden Überblick über die Vielzahl digitaler Produktbeschreibender Informationsartefakte zu wahren und zu erkennen, welche dieser Informationen einen Einfluss auf ein betrachtetes Entwicklungsobjekt haben [LINDVALL UND SANDAHL 1998a, S. 26]. Daher ist es notwendig, Entwicklern eine informationstechnische Unterstützung für das Aufzeigen von Systemzusammenhängen zu geben. Neben der expliziten Abbildung der Systemzusammenhänge muss an eine solche Software-Unterstützung die Anforderung formuliert werden, bei Bedarf so detailliert wie nötig Informationen liefern zu können, ohne dabei den Kontext des Gesamtsystems zu verlieren. Dieser Kontext ergibt sich zum einen aus der Verortung im eigenen Informationsartefakt und zum anderen aus der Vernetzung mit anderen Modellen. In der vorliegenden Arbeit wurde aufgezeigt, was Traceability (als Methode zum Explizieren von Systemzusammenhängen) im Kontext der Entwicklung mechatronischer Produkte diesbezüglich leisten kann. Dazu wurden aktuelle Traceability-Lösungen aus Wissenschaft und Praxis und ihre jeweiligen Vor- und Nachteile diskutiert sowie erläutert, welche Hürden genommen werden müssen, damit der Traceability in der industriellen Praxis zum Durchbruch verholfen werden kann. Derzeit steht dem in der Praxis, neben der aufwändigen Erstellung von Traceability-Modellen, vor allem noch deren unklarer Mehrwert für die Unternehmen als häufig genanntes Hindernis entgegen. Die Nutzenpotentiale der Traceability müssen daher herausgearbeitet und für die praktische Anwendung veranschaulicht werden. Dies war das übergeordnete Ziel der vorliegenden Arbeit. Aus diesem Grund standen die wissenschaftliche Erarbeitung und Diskussion eines breiten Portfolios an Verwendungsmöglichkeiten für Traceability-Modelle und deren gewinnbringender Einsatz im Rahmen der Entwicklung mechatronischer Produkte im Zentrum der Betrachtungen. 251

281 8 Zusammenfassung und Ausblick 8.1. ZUSAMMENFASSUNG DER ERGEBNISSE DER ARBEIT Die methodische Vorgehensweise zur wissenschaftlichen Durchdringung der vorgestellten Forschungsinhalte orientierte sich an der Design Research Methodology (DRM) gemäß [BLESSING UND CHAKRABARTI 2009]. Das darin empfohlene iterative Vorgehen, aus deskriptiven und präskriptiven Untersuchungen zur Verfeinerung der Annahmen und Evaluierung der Methoden, wurde in jedem forschungsrelevanten Kapitel angewandt. Der inhaltliche Fokus dieser Kapitel und damit die zentralen Forschungsfragen der vorliegenden Arbeit adressierten die Nutzungsmöglichkeiten von Traceability-Modellen zur 1. informationstechnischen Unterstützung etablierter Methoden der Produktentwicklung, 2. visuellen Repräsentation der Systemzusammenhänge für deren erleichtertes Verständnis, 3. Abschätzung von Änderungsauswirkungen (Impact Analyse) und 4. visuellen Unterstützung bei der Durchführung von Impact Analysen. Die Kernergebnisse dieser vier Forschungsschwerpunkte sollen im Folgenden kurz zusammengefasst werden UNTERSTÜTZUNG ETABLIERTER METHODEN DER PRODUKTENTWICKLUNG DURCH TRACEABILITY In Kapitel 4 wurde untersucht, wie etablierte Methoden der Produktentwicklung durch Artefakt-übergreifende Traceability-Modelle informationstechnisch unterstützt werden können und welche Möglichkeiten bestehen, ausgewählte Produktentwicklungsprozesse damit effizienter zu gestalten. Dazu wurde für ausgewählte Methoden (wie bspw. FMEA, House of Quality, Progress Monitoring und Coverage Analyse) die Anreicherung mit Traceability- Informationen auf konzeptioneller Ebene beschrieben. Die Wirksamkeit wurde exemplarisch für eine systematisch ausgewählte Methode, das House of Quality, mittels einer prototypischen Software-Implementierung präskriptiv nachgewiesen. So ermöglicht der House-of- Quality-Prototyp den Entwicklern, die Methode mit stark reduziertem Aufwand durchzuführen: drei der sechs notwendigen Schritte konnten durch die Verwendung von Traceability- Informationen automatisiert werden. Alle in Kapitel 4 vorgestellten Methoden stellen somit ein Angebot dar, die Produktentwicklung bei unterschiedlichen ingenieurtechnischen Tätigkeiten punktuell durch Traceability- Informationen zu unterstützen. Hinsichtlich der untersuchten Forschungsfrage ist festzuhalten, dass durch das Verwenden von Traceability-Informationen ein breites Portfolio etablierter Methoden der Produktentwicklung unterstützt werden kann, um diese somit effizienter durchführen zu können GRAPHISCHE DARSTELLUNG VON TRACEABILITY-MODELLEN In Kapitel 5 der Arbeit wurde die Forschungsfrage untersucht, wie ein Visualisierungskonzept für Traceability-Informationen ausgeprägt sein muss, um eine eingängige graphische Repräsentation der Systemzusammenhänge im Kontext der Mechatronik zu ermöglichen. Dazu 252

282 8 Zusammenfassung und Ausblick wurde aus zuvor gewonnenen Rechercheerkenntnissen ein Anordnungskonzept zur visuellen Repräsentation von Artefakt-übergreifenden Tracelinks hergeleitet. Dieses Visualisierungskonzept für Artefakt-übergreifende Tracelinks wurde anschließend mittels einer empirischen Nutzerstudie deskriptiv evaluiert. Auf Basis der Studienergebnisse konnte das Traceability-Visualisierungskonzept verfeinert und in Ariadne s Eye prototypisch umgesetzt werden - einem eingängigen, interaktiven Werkzeug, mit dem Entwickler effizient den Kontext beliebiger Modellelemente und deren Abhängigkeiten zu anderen Elementen erfassen können. In einer abschließenden deskriptiven Untersuchung wurde die Visualisierung eines Traceability- Beispielmodells mittels Ariadne s Eye im Vergleich zu einem etablierten Layout-Algorithmus über anerkannte Lesbarkeitsmetriken evaluiert. Abbildung 100: Traceability-Visualisierung in Ariadne's Eye am Beispiel eines Pedelec- Modells Das Ergebnis der in Kapitel 5 untersuchten Forschungsfrage ist das interaktive Traceability- Visualisierungswerkzeug Ariadne s Eye (siehe Abbildung 100). In zwei deskriptiven Untersuchungen erzielte Ariadne s Eye signifikant bessere Ergebnisse im Vergleich zu anderen etablierten Node-Link-Layouts. Mit Ariadne s Eye steht Entwicklern ein interaktives Traceability-Visualisierungswerkzeug zur Verfügung, um für beliebige Modellelemente deren Abhängigkeiten zu anderen Systemelementen effizient identifizieren zu können. Ariadne s Eye stellt somit einen wesentlichen Beitrag dar, um Entwickler beim Verstehen komplexer Systemzusammenhänge zu unterstützen - eine in der Literatur häufig geforderte Hilfestellung. 253

283 8 Zusammenfassung und Ausblick TRACELINK-BASIERTE IMPACT-ANALYSE In Kapitel 6 lag das wissenschaftliche Augenmerk auf der Forschungsfrage, wie Traceability- Informationen genutzt werden können, um die Auswirkung von Änderungen bei mechatronischen Produktmodellen abzuschätzen. Um diese Forschungsfrage zu untersuchen, wurden zunächst die Spezifika, die sich aus der Struktur und der Art der Modellierung von Artefakten in der Mechatronik ergeben, deskriptiv untersucht und in spezifische Anforderungen an eine solche Impact-Analyse-Methode überführt. Anschließend erfolgte die präskriptive Herleitung eines übertragbaren Impact-Analyse-Algorithmus, welcher auch das wissenschaftliche Kernergebnis des Kapitels darstellt. Die Wirksamkeit dieses Algorithmus und damit auch die Evaluierung der Forschungsfrage wurden mittels einer präskriptiven Nutzerstudie untersucht. Die empirische Nutzerstudie ergab eine sehr hohe Übereinstimmung zwischen den von den Teilnehmern manuell und den vom Algorithmus automatisch identifizierten Elementen. Das Ergebnis der Untersuchungen zur Forschungsfrage dieses Kapitels lautet: die entwickelte Impact-Analyse-Methode für mechatronische Produkte auf Basis Artefakt-übergreifender Traceability-Informationen ist wirksam. Sie ermöglicht es Entwicklern, frühzeitig die potentiellen Auswirkungen einer Änderung auf andere Systemelemente abzuschätzen und somit Änderungsalternativen mit geringem Aufwand vergleichend bewerten zu können VISUELLE UNTERSTÜTZUNG BEI DER DURCHFÜHRUNG VON IMPACT ANALYSEN Aufbauend auf den Ergebnissen der Kapitel 5 und 6 wurde in Kapitel 7 untersucht, wie die Durchführung der entwickelten Impact-Analyse-Methode durch ein Dialog-basiertes Assistenzwerkzeug visuell unterstützt werden kann. Aus den Erkenntnissen einer deskriptiven Literaturrecherche wurde induktiv die Hypothese abgeleitet, dass dies auf Basis einer Node- Link-Repräsentation am besten möglich ist. Die Verifikation dieser Hypothese erfolgte mittels einer vergleichenden, empirischen Nutzerstudie, in deren Ergebnis festgestellt werden konnte, dass eine Vielzahl der untersuchten Variablen (notwendige Bearbeitungszeit, Attraktivität der Anwendung und wahrgenommene Belastung) für das Node-Link-Diagramm im Ariadne s-eye-layout signifikant bessere Ergebnisse erbrachten als die beiden alternativen Repräsentationsformen (Liste und Matrix). Die Forschungsfrage konnte somit dahingehend beantwortet werden, dass die Repräsentationsform einen erheblichen Einfluss auf die Eignung eines visuellen Impact-Analyse-Assistenten hat. Konkret war das Layout von Ariadne s Eye signifikant besser geeignet als die beiden alternativen Repräsentationsformen Liste und Matrix. Aufbauend auf dieser Erkenntnis wurde ein interaktiver Prototyp für einen Dialogbasierten Impact-Analyse-Assistenten implementiert. 254

284 8 Zusammenfassung und Ausblick Abbildung 101: Durchführung einer Impact Analyse mit dem entwickelten Dialog-basierten Assistenzwerkzeug Die Menge der potentiell betroffenen Elemente wird von dem Werkzeug auf Basis der Traceability-Informationen automatisch identifiziert und entsprechend der getroffenen Entscheidung sukzessive angepasst. Dabei werden dem Nutzer nur die notwendigen Kontextinformationen für die jeweilige Bewertung einer Änderungsfortpflanzung angezeigt (siehe Abbildung 101). Das visuelle Impact-Analyse-Assistenzwerkzeug stellt somit eine wesentliche Hilfestellung dar, mit welcher Entwickler auch für komplexe Produktmodelle schrittweise die Auswirkungen von Änderungen effizient analysieren können. Eine frühzeitige Bewertung von Änderungsauswirkungen und -alternativen wird durch das entwickelte Assistenzwerkzeug erheblich erleichtert GRENZEN DER ENTWICKELTEN METHODEN UND KORRESPONDIERENDE OFFENE FORSCHUNGSFRAGEN Alle im Rahmen der Arbeit entwickelten Methoden wurden wissenschaftlich evaluiert. Dennoch wird deren Validität durch verschiedene Aspekte begrenzt. Die wesentlichsten 97 Aspekte werden hier zusammenfassend diskutiert. Im Rahmen der Arbeit erfolgten qualitative Evaluierungen der Methoden, um deren allgemeine Wirksamkeit sowie bei den Visualisierungskonzepten ebenfalls deren Nutzerfreundlichkeit zu überprüfen. Die wirtschaftlichen Potentiale der Lösungen wurden in der Arbeit hingegen 97 Ausführlichere Ausführungen zu weiteren offenen Forschungsfragen, welche direkt die vorgestellten Methoden adressieren, sind in den Zusammenfassungen der zugehörigen inhaltlichen Kapitel (4.3, 5.9, 6.7 und 7.6) beschrieben. 255

285 8 Zusammenfassung und Ausblick nicht quantifiziert, da dies im zeitlichen Rahmen solcher Untersuchungen schwerlich möglich ist [BLESSING UND CHAKRABARTI 2009, S. 27]. Hinsichtlich des Umfangs und der Komplexität der für die Evaluierung verwendeten Produktdaten muss ferner angemerkt werden, dass diese nicht der industriellen Realität entsprechen. Daher konnten eventuelle Effekte, die sich aus einer erheblichen Vergrößerung des Datenumfangs sowie deren stärkerer Vernetzung ergeben, im Rahmen dieser Arbeit nicht im Detail betrachtet werden. Zukünftige Aktivitäten sollten daher die industrielle Anwendung der vorgestellten Methoden adressieren, um sie ggf. stärker an deren Anforderungen adaptieren zu können. In theory, there is no difference between theory and practice. But, in practice, there is. Jan L. A. van de Snepscheut (zit. n.[rosenberg UND STEPHENS 2007, S. xxvii]) Zudem wurde für alle vorgestellten Methoden postuliert, das zugrundeliegende Traceability- Modell wäre vollständig und korrekt. Dieser idealisierte Zustand ist in der Praxis de facto kaum zu erreichen [WINKLER UND PILGRIM 2010, S. 545]. Daher sollte den Ergebnissen der Methoden nicht blind vertraut werden. Vielmehr müssen diese kritisch geprüft werden - ein Vorsatz, der bei allen Modellierungsergebnissen durch die darin immanent gegebene Merkmalsreduktion geboten ist. Zusätzlich dazu sollten Traceability-Lösungen um interaktive Funktionalitäten ergänzt werden, mit welchen deren Anwender entdeckte Fehler direkt dokumentieren oder ggf. beheben können. Generell lag der Fokus im Rahmen dieser Arbeit auf wissenschaftlichen Betrachtungen bzgl. Artefakt-übergreifender Traceability. Weitere Forschungsaktivitäten sollten darauf abzielen, die Potentiale einer methodischen Erweiterung durch zusätzliche Berücksichtigung Artefaktinterner Tracelinks zu untersuchen. Diese Fragestellung ist insbesondere für die vorgestellte Traceability-basierte Impact Analyse relevant. Diesbezüglich wäre ferner zu untersuchen, welche Artefakt- und Tracelink-Typen für welchen Änderungsfall betrachtet werden müssen und welche Artefakt-Kombinationen ggf. ignoriert werden können. Ein derart geartetes Metamodell der mechatronischen, Traceability-basierten Impact Analyse könnte den erforderlichen Durchführungsaufwand erheblich reduzieren und hätte daher eine hohe industrielle Relevanz. Ein erster Schritt in Richtung eines solchen Traceability-Schemas, dessen Bestandteile durch die geplante Verwendung der Traceability-Informationen definiert werden, ist das in Kapitel vorgestellte Stufenmodell der Traceability-Granularität FAZIT Weil ihre Nutzenpotentiale unklar sind, wird Traceability in der industriellen Praxis kaum angewandt. Die übergeordnete Zielstellung der vorliegenden Arbeit war daher das Entwickeln eines breiten Portfolios an Methoden, die durch die Verwendung von Traceability-Modellen die Entwicklung komplexer mechatronischer Produkte unterstützen. Dafür wurde in Kapitel 4 für eine Vielzahl etablierter Entwicklungsmethoden vorgestellt, wie deren Durchführung durch die Anreicherung mit Traceability-Informationen informationstechnisch unterstützt werden kann. Einige dieser Funktionalitäten (wie bspw. die Coverage Ana- 256

286 8 Zusammenfassung und Ausblick lyse, das House of Quality oder das Progress Monitoring) werden von dem technischen Report ISO/IEC TR 24766:2009 Information technology - Systems and software engineering für zukünftige Systems-Engineering-Werkzeuge gefordert, um das Entwickeln komplexer technischer Systeme rechentechnisch zu unterstützen [International Organisation for Standardization 2009]. In [HOFFMANN ET AL. 2004, S. 303f; International Organisation for Standardization 2009, S. 5] und [WINKLER UND PILGRIM 2010, S. 543] wird zudem gefordert, dass Traceability-Werkzeuge Produktentwicklung auch durchgängig, mittels einer nutzerfreundlichen, graphischen Repräsentation der Tracelinks zur Erleichterung des Systemverständnisses, unterstützen sollen. Diese Forderung erfüllt das Traceability-Visualisierungswerkzeug Ariadne s Eye, welches in Kapitel 5 entwickelt und vorgestellt wurde. Ariadne s Eye befähigt Entwickler, die Artefaktübergreifenden Abhängigkeiten beliebiger Elemente zu erkennen und damit existierende Systemzusammenhänge leichter verstehen sowie die Komplexität des zu entwickelnden Produkts besser beherrschen zu können. Im Kapitel 6 wurde eine Methode entwickelt, mit deren Hilfe Änderungsauswirkungen über Tracelinks abgeschätzt werden können Diese Methode wurde in Kapitel 7 in einem Benutzer-freundlichen Dialog-basierten Assistenzwerkzeug zur visuellen Unterstützung von Impact Analysen implementiert. Damit wurde der in [STOLZ UND KRAUSE 2009, S. 39] und [HOFFMANN ET AL. 2004, S. 303f] formulierten Anforderungen an den Funktionsumfang moderner Traceability-Werkzeuge entsprochen, wonach diese Impact Analysen unterstützen müssen. Eine solche Funktionalität ist von großer Bedeutung, wenn man berücksichtigt, dass durch eine eingängige Impact Analyse das Verständnis des betrachteten Systems verbessert wird [FASOLINO UND VISSAGGIO 1999, S. 64; REN ET AL. 2004, S. 432] und das bessere Verständnis der Ursachen und Auswirkungen von Änderungen schlussendlich zu besseren Produkten führt [FRICKE ET AL. 2000, S. 176]. In der vorliegenden Arbeit wurde ein breites Spektrum an Nutzenpotentialen für die Verwendung von Traceability-Modellen in unterschiedlichen Phasen der Produktentwicklung aufgezeigt. Sie leistet somit einen wesentlichen Forschungsbeitrag auf dem Weg, die Hemmschwelle zur Einführung von Traceability in den Unternehmen weiter zu senken. 257

287

288 LITERATURVERZEICHNIS ABBATTISTA, F.; LANUBILE, F.; MASTELLONI, G.; VISAGGIO, G. (1994): An experiment on the effect of design recording on impact analysis. In: Müller, H. A. und Georges, M. (Hg.): Proceedings of the International Conference on Software Maintenance, ICSM '94, Victoria, Kanada, September 19-23, IEEE Computer Society Press: Los Alamitos, USA, S ABELLO, J.; HAM, F.; KRISHNAN, N. (2006): ASK-GraphView: A Large Scale Graph Visualization System. In: IEEE Transactions on Visualization and Computer Graphics, 12 (5), S ABMA, B. J. M. (2009): Evaluation of requirements management tools with support for TA-based change IA, Masterarbeit, University of Twente, Faculty of Electrical Engineering, Mathematics and Computer Science, Enschede, Niederlande. ABRAMOVICI, M. (2005): Quo vadis PLM? - Teil 1: Engineering Vision In: CAD- CAM Report (8). AHLBERG, C.; SHNEIDERMAN, B. (1994): Visual information seeking: tight coupling of dynamic query filters with starfield displays. In: Adelson, B., Dumais, S. und Olson, J. S. (Hg.): Proceedings of the SIGCHI conference on Human factors in computing systems, CHI 94, Boston, USA, April 24-28, ACM Press: New York, USA, S AHMAD, N.; WYNN, D. C.; CLARKSON, P. J. (2012): Change impact on a product and its redesign process: a tool for knowledge capture and reuse. In: Research in Engineering Design (published online first), S AIZENBUD-RESHEF, N.; NOLAN, B. T.; RUBIN, J.; SHAHAM-GAFNI, Y. (2006): Model traceability. In: IBM Systems Journal, 45 (3), S AKAO, Y. (1994): Development History of Quality Function Deployment. In: The Customer Driven Approach to Quality Planning and Deployment: Tokyo, Japan. ALMEFELT, L.; BERGLUND, F.; NILSSON, P.; MALMQVIST, J. (2006): Requirements management in practice: findings from an empirical study in the automotive industry. In: Research in Engineering Design, 17 (3), S ANTONIOL, G.; CANFORA, G.; CASAZZA, G.; LUCIA, A. de; MERLO, E. (2002): Recovering traceability links between code and documentation. In: IEEE Transactions on Software Engineering, 28 (10), S ARIAS-HERNÁNDEZ, R.; DILL, J.; FISHER, B.; GREEN, T. M. (2011): Visual Analytics and Human-Computer Interaction. In: interactions, 18 (1), S ARKLEY, P.; RIDDLE, S. (2005): Overcoming the traceability benefit problem. In: Proceedings of the 13th International Conference on Requirements Engineering, RE '05, Paris, Frankreich, August 29 - September 2, IEEE Computer Society Press: Los Alamitos, USA, S ARNOLD, R.; BOHNER, S. (1993): Impact analysis-towards a framework for comparison. In: Card, D. N. (Hg.): Proceedings of the Conference on Software Maintenance, 259

289 Literaturverzeichnis ICSM '93, Montréal, Kanada, September 27-30, IEEE Computer Society Press: Los Alamitos, USA, S AXENATH, B.; GIESE, H.; KLEIN, F.; FRANK, U. (2006): Systematic Requirements-Driven Evaluation and Synthesis of Alternative Principle Solutions for Advanced Mech a- tronic Systems. In: Glinz, M. und Lutz, R. (Hg.): Proceedings of the 14th IEEE International Requirements Engineering Conference, RE'06, Minneapolis, USA, September 11-15, IEEE Computer Society Press: Los Alamitos, USA, S BAHILL, A. T.; GISSING, B. (1998): Re-evaluating systems engineering concepts using systems thinking. In: IEEE Transactions on Systems, Man, and Cybernetics - Part C: Applications and Reviews, 28 (4), S BARLOW, T.; NEVILLE, P. (2001): A Comparison of 2-D Visualizations of Hierarchies. In: Andrews, K., Stevens, R. und Wong, P. Chung (Hg.): Proceedings of the IEEE Symposium on Information Visualization, InfoVis '01, San Diego, USA, Oktober 22-23, IEEE Computer Society Press: Los Alamitos, USA, S BARNETT, W. D.; RAJA, M. K. (1995): Application of QFD to the software development process. In: International Journal of Quality & Reliability Managment, 12 (6), S BEIER, G.; DAMERAU, T.; FIGGE, A.; STARK, R. (2012a): Modellbasierte Prozess- und Systemgestaltung beschleunigt Innovationen. In: KONSTRUKTON (9), S. 57f. BEIER, G.; FIGGE, A.; LEHNER, T.; METIN, A. (2011): Durchgängige Nachverfolgbarkeit in der Systementwicklung - Datendurchgängigkeit für die Entwicklung von Fahrzeugfunktionen. In: ZWF Zeitschrift für wirtschaftlichen Fabrikbetrieb, 106 (6), S BEIER, G.; FIGGE, A.; MÜLLER, R.; ROTHENBURG, U.; STARK, R. (2013): Supporting Product Development through Cross-Discipline Dependency-Modeling - Novel Approaches for Traceability-Usage. In: Lecture Notes on Information Theory, 1 (1), S BEIER, G.; ROTHENBURG, U.; WOLL, R.; STARK, R. (2012b): Durchgängige Entwicklung mit erlebbaren Prototypen - Modellbasiertes Systems Engineering. In: Digital Engineering, 11 (3), S BERTINI, E.; TATU, A.; KEIM, D. (2011): Quality Metrics in High-Dimensional Data Visualization: An Overview and Systematization. In: IEEE Transactions on Visualization and Computer Graphics, 17 (12), S BERTSCHE, B.; GÖHNER, P.; JENSEN, U.; SCHINKÖTHE, W.; WUNDERLICH, H.-J. (2009): Zuverlässigkeit mechatronischer Systeme - Grundlagen und Bewertung in frühen Entwicklungsphasen, Springer: Berlin/Heidelberg. BIANCHI, A.; FASOLINO, A.; VISAGGIO, G. (2000): An exploratory case study of the maintenance effectiveness of traceability models. In: Proceedings of the 8th International Workshop on Program Comprehension, IWPC 2000, Limerick, Irland, Juni 10-11, IEEE Computer Society: Washington, USA, S BLESSING, L. T. M.; CHAKRABARTI, A. (2009): DRM, a Design Research Methodology, Springer-Verlag London Limited: London, England. BODE, S.; RIEBISCH, M. (2009): Tracing Quality-Related Design Decisions in a Category-Driven Software Architecture. In: Liggesmeyer, P. et al. (Hg.): Software Engineering: Fachtagung des GI-Fachbereichs Softwaretechnik, Kaiserslautern, März 2-6 (143), S BODE, S.; RIEBISCH, M. (2010): Impact Evaluation for Quality-Oriented Architectural Decisions regarding Evolvability. In: Babar, M. und Gorton, I. (Hg.): Software Architecture, Bd (Lecture Notes in Computer Science), Springer Berlin / Heidelberg, S

290 Literaturverzeichnis BOHNER, S. (2002): Software change impacts - an evolving perspective. In: Proceedings of the IEEE International Conference on Software Maintenance, ICSM 02, Montréal, Kanada, Oktober 3-6, IEEE Computer Society: Washington, USA, S BOHNER, S. A.; ARNOLD, R. S. (1996): Software change impact analysis, IEEE Computer Society Press: Los Alamitos, USA. BORNATH, M. (2011): Untersuchung und prototypische Implementierung einer Methode zur effizienten Modellierung von Abhängigkeiten zwischen Partialmodellen, Studienarbeit, Technische Universität Berlin, Institut für Werkzeugmaschinen und Fabrikbetrieb, Berlin. BROWN, J. (2006): Managing Product Relationships: - Enabling Iteration and Innovation in Design, Aberdeen Group (Hg.): Boston, USA. BROWNING, T. R. (2001): Applying the Design Structure Matrix to System Decomposition and Integration Problems - A Review and New Directions. In: IEEE Transactions on Engineering Management, 48 (3), S BURGAUD, L. (2006): A Novel development framework combining requirement driven and model based engineering processes. In: Proceedings of the 4ème Conférence Annuelle d'ingénierie Système, Toulouse, Frankreich, Mai 2-4, S BUUR, J.; ANDREASEN, M. M. (1989): Design models in mechatronic product development. In: Design Studies, 10 (3), S Cambridge EDC (2012): Cambridge Advanced Modeller - CAM. https://wwwedc.eng.cam.ac.uk/cam/ (zuletzt geprüft am: ). CHEN, X. (2010): Extraction and visualization of traceability relationships between documents and source code. In: Proceedings of the IEEE/ACM international conference on Automated software engineering, ASE 10, Antwerpen, Belgien, September 20-24, ACM Press: New York, USA, S ChiasTek Sales (2011): Reqtify - Requirements Traceability and Impact Analysis. (zuletzt geprüft am: ). CIMITILE, A.; FASOLINO, A.; VISAGGIO, G. (1999): A software model for impact analysis: - a validation experiment. In: Titsworth, F. M. (Hg.): Proceedings of the Sixth Working Conference on Reverse Engineering, Atlanta, USA, Oktober 6-8, IEEE Computer Society Press: Los Alamitos, USA, S CLARK, K. B.; FUJIMOTO, T. (1991): Product Development Performance - Strategy, organization, and management in the world auto industry, Harvard Business School Press: Boston, USA. CLARKSON, P. J.; SIMONS, C.; ECKERT, C. (2004): Predicting change propagation in complex design. In: Journal of Mechanical Design, 126 (5), S Claytex Services Limited (2012): Reqtify - Requirements Traceability and Impact Analysis. (zuletzt geprüft am: ). CLELAND-HUANG, J.; BERENBACH, B.; CLARK, S.; SETTIMI, R.; ROMANOVA, E. (2007): Best Practices for Automated Traceability. In: Computer, 40, S CLELAND-HUANG, J.; CHANG, C.; CHRISTENSEN, M. (2003): Event-based traceability for managing evolutionary change. In: IEEE Transactions on Software Engineering, 29 (9), S

291 Literaturverzeichnis CONRAD, M.; FEY, I.; GROCHTMANN, M.; KLEIN, T. (2005): Modellbasierte Entwicklung eingebetteter Fahrzeugsoftware bei DaimlerChrysler. In: Informatik - Forschung und Entwicklung, 20 (1-2), S DANILOVIC, M.; BÖRJESSON, H. (2001): Participatory Dependence Structure Matrix Approach. In: Proceedings of the 3rd Dependence Structure Matrix (DSM) Intern a- tional Workshop, Cambridge, USA, Oktober DANNENBERG, J.; BURGARD, J. (2007): 2015 car innovation - Innovationsmanagement in der Automobilindustrie, Oliver Wyman (Hg.). Dassault Systèmes (2011): V6. (zuletzt geprüft am: ). Dassault Systèmes (2012a): CATIA Systems Engineering. (zuletzt geprüft am: ). Dassault Systèmes (2012b): ENOVIA VPM System Functional Logical Definition. (zuletzt geprüft am: ). DEERWESTER, S.; DUMAIS, S. T.; FURNAS, G. W.; LANDAUER, T. K.; HARSHMAN, R. (1990): Indexing by Latent Semantic Analysis. In: Journal of the American Society for Information Science, 41 (6), S DEISER, O. (2010): Einführung in die Mengenlehre. 3. Aufl., Springer: Berlin/Heidelberg. Department of Defense (2001): Systems Engineering Fundamentals, Defense Acquisition University Press: Fort Belvoir, USA. DIEHL, H. (2009): Systemorientierte Visualisierung disziplinübergreifender Entwicklungsabhängigkeiten mechatronischer Automobilsysteme, Dissertation, Technische Universität München, Fakultät für Maschinenwesen, München. DIEHL, H.; HELLENBRAND, D.; LINDEMANN, U. (2008): Transparent 3D Visualization of Mechatronic System Structures. In: Marjanovic, D. et al. (Hg.): Proceedings of the 10th International Design Conference, DESIGN 2008, Dubrovnik, Kroatien, Mai 19 22, S DÖMGES, R.; POHL, K. (1998): Adapting traceability environments to project-specific needs. In: Communications of the ACM, 41 (12), S DRIVALOS, N.; KOLOVOS, D. S.; PAIGE, R. F.; FERNANDES, K. J. (2008): Engineering a DSL for Software Traceability. In: Gašević, D., Lämmel, R. und van Wyk, E. (Hg.): Proceedings of the First International Conference on Software Language Engineering, SLE '08, Toulouse, Frankreich, September 29-30, Springer: Berlin/Heidelberg, S DUAN, C.; CLELAND-HUANG, J. (2006): Visualization and Analysis in Automated Trace Retrieval. In: Proceedings of the 1st International Workshop on Requirements Engineering Visualization, REV '06, Minneapolis, USA, September 11, IEEE Computer Society: Washington, USA, S DUNNE, C.; SHNEIDERMAN, B. (2009): Improving graph drawing readability by incorporating readability metrics: a software tool for network analysts, University of Maryland (Hg.): Maryland, USA, (Technical Report HCIL ). 262

292 Literaturverzeichnis EADES, P. (1991): Preserving the mental map of a diagram, International Institute for Advanced Study of Social Information Science: Numazu, (Research Report II AS-RR E). EADES, P.; FENG, Q.-W. (1996): Multilevel Visualization of Clustered Graphs. In: Proceedings of the 4th International Symposium on Graph Drawing, Berkeley, USA, September 18-20, Springer: Berlin/Heidelberg, S EADES, P.; HUANG, M. L. (2000): Navigating Clustered Graphs using Force-Directed Methods. In: Journal of Graph Algorithms ans Applications, 4 (3), S ECKERT, C.; CLARKSON, P. J.; ZANKER, W. (2004): Change and customisation in complex engineering domains. In: Research in Engineering Design, 15 (1), S EDWARDS, M. H. S. (1992): A Methodology for Requirements Specification and Traceability for Large Real-Time Complex Systems, Naval Surface Warfare Center (Hg.), (Technical Report). EGYED, A. (2003): A scenario-driven approach to trace dependency analysis. In: IEEE Transactions on Software Engineering, 29 (2), S EGYED, A.; GRUNBACHER, P.; HEINDL, M.; BIFFL, S. (2007): Value-Based Requirements Traceability: Lessons Learned. In: Sutcliffe, A. und Jalote, P. (Hg.): Proceedings of the 15th IEEE International Requirements Engineering Conference, New Delhi, Indien, Oktober 15-19, IEEE Computer Society Press: Los Alamitos, USA, S EGYED, A.; GRÜNBACHER, P. (2005): Supporting Software Understanding with Automated Requirements Traceability. In: International Journal of Software Engineering and Knowledge Engineering, 15 (5), S EHRLENSPIEL, K. (2007): Integrierte Produktentwicklung - Denkabläufe, Methodeneinsatz, Zusammenarbeit. 3. Aufl., Hanser: München. EIGNER, M.; STELZER, R. (2009): Product Lifecycle Management - Ein Leitfaden für Product Development und Life Cycle Management. 2. Aufl., Springer: Berlin/Heidelberg. ELMQVIST, N.; DO, T.-N.; GOODELL, H.; HENRY, N.; FEKETE, J.-D. (2008): ZAME: Interactive Large-Scale Graph Visualization. In: Proceedings of the IEEE VGTC Pacific Visualization Symposium, Kyoto, Japan, März 4-7, IEEE Computer Society Press: Los Alamitos, USA, S EVBUOMWAN, N. F. O.; SIVALOGANATHAN, S.; JEBB, A. (1996): A survey of design philosophies, models, methods and systems. In: Journal of Engineering Manufacture, 210, S FASOLINO, A. R.; VISSAGGIO, G. (1999): Improving Software Comprehension through an Automated Dependency Tracer. In: Proceedings of the 7th International Workshop on Program Comprehension, IWPC 99, Pittsburgh, USA, Mai 5-7, IEEE Computer Society Press: Washington, USA, S FAWCETT, T. (2004): ROC Graphs: Notes and Practical Considerations for Researchers, HP Laboratories (Hg.): Palo Alto, USA, (No. HPL ). FEI, G.; GAO, J.; OWODUNNI, O.; TANG, X. (2011a): A method for engineering design change analysis using system modelling and knowledge management techniques. In: International Journal of Computer Integrated Manufacturing, 24 (6), S FEI, G.; GAO, J.; OWODUNNI, O.; TANG, X. (2011b): A method for engineering design change analysis using system modelling and knowledge management techniques. In: International Journal of Computer Integrated Manufacturing, 24 (6), S

293 Literaturverzeichnis FEKETE, J.-D.; PLAISANT, C. (2002): Interactive Information Visualization of a Million Items. In: Proceedings of the IEEE Symposium on Information Visualization, InfoVis 02, Boston, USA, Oktober 28-29, IEEE Computer Society: Washington, DC, USA, S FERRARI, D.; MEZZALIRA, L. (1969): On drawing a graph with the minimum number of crossings, Istituto di Elettrotecnica ed Elettronica, Politecnico di Milano, (Technical Report 69-11). FINKELSTEIN, L.; FINKELSTEIN, A. (1983): Review of design methodology. In: IEE Proceedings of Physical Science, Measurement and Instrumentation, Management and Education - Reviews, 130 (4 - Part A), S FRICKE, E.; GEBHARD, B.; NEGELE, H.; IGENBERGS, E. (2000): Coping with changes: Causes, findings, and strategies. In: Systems Engineering, Vol. 4, No. 3, 3 (4), S FRUCHTERMAN, T.; REINGOLD, E. (1991): Graph drawing by forcedirected placement. In: Software Practice and Experience, 21 (11), S FURNAS, G. W. (1986): Generalized fisheye views. In: Mantei, M. und Smith, R. (Hg.): Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, CHI 86, Boston, USA, April 13-17, ACM Press: New York, USA, S Geensoft (2010a): Reqtify - Effective Solution for Managing Requirements Traceability and Impact Analysis across Hardware and Software Projects Lifecycle. (zuletzt geprüft am: ). Geensoft (2010b): Reqtify - Release Notes, (Nr a). GHONIEM, M.; FEKETE, J.-D.; CASTAGLIOLA, P. (2004): A Comparison of the Readability of Graphs Using Node-Link and Matrix-Based Representations. In: Proceedings of the Symposium on Information Visualization, Bd. 4, InfoVis '04, Austin, USA, Oktober 10-12, IEEE Computer Society: Washington, USA, S GHONIEM, M.; FEKETE, J.-D.; CASTAGLIOLA, P. (2005): On the readability of graphs using node-link and matrix-based representations: a controlled experiment. In: Information Visualization, 4 (2), S GIFFIN, M.; WECK, O. de; BOUNOVA, G.; KELLER, R.; ECKERT, C.; CLARKSON, P. J. (2009): Change Propagation Analysis in Complex Technical Systems. In: Journal of Mechanical Design, 131 (8), S GOERISCH, P. (2010): Analyse mechatronischer Systeme mittels modellübergreifender Abhängigkeiten - Übersicht über etablierte Methoden in der Systementwicklung und deren Unterstützbarkeit durch Abhängigkeitsmodelle, Diplomarbeit, Technische Universität Berlin, Institut für Werkzeugmaschinen und Fabrikbetrieb, Berlin. GÖKNIL, A.; KURTEV, I.; VAN DEN BERG, K. (2010): Tool support for generation and validation of traces between requirements and architecture. In: Proceedings of the Sixth European Conference on Modelling Foundations and Applications - Traceability Workshop, Paris, Frankreich, Juni 15-18, ACM Press: New York, USA (ECMFA-TW 10), S GÖKNIL, A.; KURTEV, I.; VAN DEN BERG, K. G. (2008): Change Impact Analysis based on Formalization of Trace Relations for Requirements. In: Proceedings of the 4th European Conference on Model Driven Architecture. Foundations and Applications, ECMDA Traceability Workshop, Berlin, Juni 9-12, Sintef: Trondheim, Norwegen, S

294 Literaturverzeichnis GÖKNIL, A.; KURTEV, I.; VAN DEN BERG, K. G.; VELDHUIS, J.-W. (2011): Semantics of trace relations in requirements models for consistency checking and inferen c- ing. In: Software & Systems Modeling, 10 (1), S GOTEL, O. C. Z. (1996): Contribution Structures for Requirements Engineering, Dissertation, Imperial College of Science, Technology, and Medicine, London, England. GOTEL, O. C. Z.; FINKELSTEIN, A. C. W. (1994): An Analysis of the Requirements Traceability Problem. In: Proceedings of the 1st International Conference on Requirements Engineering, ICRE '94, Colorado Springs, USA, April, IEEE Computer Society: Los Alamitos, USA, S GROTE, K.-H.; FELDHUSEN, J. (2011): Dubbel - Taschenbuch für den Maschinenbau. 23. Aufl., Springer: Berlin/Heidelberg. HAFFNER, T. (2005): Ein Modell zur Bestimmung der monetären Einsparungspotenziale bei der Durchführung einer Fehlermöglichkeits- und Einflussanalyse (FMEA), Dissertation, Universität Stuttgart, Stuttgart. HARASHIMA, F.; TOMIZUKA, M.; FUKUDA, T. (1996): Mechatronics - "What Is It, Why, and How?" - An Editorial. In: IEEE/ASME Transactions on Mechatronics, 1 (1), S HART, S. G.; STAVELAND, L. E. (1998): Development of NASA-TLX (Task Load Index) - Results of empirical and theoretical research. In: Hancock, P. A. und Meshkati, N. (Hg.): Human Mental Workload, Amsterdam: North Holland, S HASKINS, C. (2006): Systems Engineering Handbook - A guide for system life cycle processes and activities, INCOSE (Hg.). HASSENZAHL, M.; BURMESTER, M.; KOLLER, F. (2003): AttrakDiff: Ein Fragebogen zur Messung wahrgenommener hedonischer und pragmatischer Qualität. In: Ziegler, J. und Szwillus, G. (Hg.): Mensch & Computer Interaktion in Bewegung, B. G. Teubner Verlag: Stuttgart. Leipzig, S HAUSER, J. R.; CLAUSING, D. (1988): The House of Quality. In: Harvard Business Review, 66 (3), S HAYES, J.; DEKHTYAR, A.; SUNDARAM, S. (2006): Advancing candidate link generation for requirements tracing: the study of methods. In: IEEE Transactions on Software Engineering, 32 (1), S HESSE, W.; MAYR, H. C. (2008): Modellierung in der Softwaretechnik: eine Bestandsaufnahme. In: Informatik-Spektrum, 31 (5), S HO, C.-J.; LI, J. (1997): Progressive engineering changes in multi-level product structures. In: Omega International Journal of Management Science, 25 (5), S HOFFMANN, M.; KUHN, N.; WEBER, M.; BITTNER, M. (2004): Requirements for requirements management tools. In: Proceedings of the 12th IEEE International Requirements Engineering Conference, RE '04, Kyoto, Japan, September 6-10, IEEE Computer Society Press: Los Alamitos, USA, S HOLLEY, V.; YANNOU, B.; JANKOVIC, M. (2010): Towards the Predicition of multiphysic Interactions using MDM and QFD Matrices. In: Marjanovic, D. et al. (Hg.): Proceedings of the 11th International Design Conference, DESIGN 2010, Dubrovnik, Kroatien, Mai 17-20, S HOLTEN, D. (2006): Hierarchical Edge Bundles: Visualization of Adjacency Relations in Hierarchical Data. In: IEEE Transactions on Visualization and Computer Graphics, 12 (5), S

295 Literaturverzeichnis HOLTEN, D.; CORNELISSEN, B.; VAN WIJK, J. J. (2007): Trace Visualization Using Hierarchical Edge Bundles and Massive Sequence Views. In: Proceedings of the 4th IEEE International Workshop on Visualizing Software for Understanding and Analysis, VisSoft '07, Alberta, Kanada, Juni 24-25, IEEE Computer Society Press: Los Alamitos, USA, S HOLTEN, D.; VAN WIJK, J. J. (2009): A user study on visualizing directed edges in graphs. In: Olsen, D. R. und Arthur, R. B. (Hg.): Proceedings of the 27th International Conference on Human Factors in Computing Systems, Boston, USA, April 4-9, ACM Press: New York, USA. HOOD, C.; WIEBEL, R. (2005): Optimieren von Requirements Management & Engineering - Mit dem HOOD Capability Model, Springer: Berlin, New York. HORVATH, L.; RUDAS, I. J. (2007): An Approach to Processing Product Changes During Product Model Based Engineering. In: Proceedings of the International Conference on System of Systems Engineering, San Antonio, USA, April 16-18, IEEE Computer Society Press: Piscataway, USA, S HUANG, G. Q.; MAK, K. L. (1999): Current Practices of Engineering Change Management in UK Manufacturing Industries. In: International Journal of Operations & Production Management, 19 (1), S HUANG, G. Q.; YEE, W. Y.; MAK, K. L. (2003): Current practice of engineering change management in Hong Kong manufacturing industries. In: Journal of Materials Processing Technology, 139 (1), S IBM Corp. (2011): Rational RequisitePro - A requirements management tool. (zuletzt geprüft am: ). IBM Corp. (2012a): Four quadrant expectation management. (zuletzt geprüft am: ). IBM Corp. (2012b): Rational DOORS - A requirements management tool for systems and advanced IT applications. (zuletzt geprüft am: ). IBM Corp. (2012c): Rational Rhapsody family ibm.com/software/products/us/en/ratirhapfami/ (zuletzt geprüft am: ). ID-Consult GmbH (2012): Komplexität transparent gemacht: METUS. (zuletzt geprüft am: ). IEEE Computer Society (1990): Standard Glossary of Software Engineering Terminology, IEEE Computer Society Press: New York, USA. INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS IEEE : Guide to Software Requirements Specification, Februar 1984, New York, USA. integrate systems engineering ltd. (2013): TraceLine for DOORS. (zuletzt geprüft am: ). International Organisation for Standardization (2009): Information technology - Systems and software engineering - Guide for requirements engineering tool capabilities, Technical Report, (ISO/IEC TR 24766:2009). INTERNATIONAL ORGANISATION FOR STANDARDIZATION ISO 10007:2003: Quality management systems - Guidelines for configuration management, März 2009, Genf, Schweiz. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION ISO : Road vehicles - Functional Safety - Part 1: Vocabulary, November 2011, Genf, Schweiz. 266

296 Literaturverzeichnis INTERNATIONAL ORGANIZATION FOR STANDARDIZATION ISO : Road vehicles - Functional Safety - Part 2: Management of functional safety, November 2011, Genf, Schweiz. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION ISO : Road vehicles - Functional Safety - Part 3: Concept phase, November 2011, Genf, Schweiz. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION ISO : Road vehicles - Functional Safety - Part 4: Product development at the system level, November 2011, Genf, Schweiz. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION ISO : Road vehicles - Functional Safety - Part 5: Product development at the hardware level, November 2011, Genf, Schweiz. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION ISO : Road vehicles - Functional Safety - Part 6: Product development at the software level, November 2011, Genf, Schweiz. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION ISO : Road vehicles - Functional Safety - Part 7: Production and operation, November 2011, Genf, Schweiz. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION ISO : Road vehicles - Functional Safety - Part 8: Supporting processes, November 2011, Genf, Schweiz. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION ISO : Road vehicles - Functional Safety - Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses, November 2011, Genf, Schweiz. ISERMANN, R. (1999): Mechatronische Systeme - Grundlagen, Springer: Berlin/Heidelberg. JANSCHEK, K. (2010): Systementwurf mechatronischer Systeme - Methoden - Modelle - Konzepte, Springer: Berlin/Heidelberg. JARKE, M.; POHL, K. (1993): Establishing Visions in Context: Towards a Model of Requirements Processes. In: DeGross, J. I., Bostrom, R. P. und Robey, D. (Hg.): Proceedings of the 14th International Conference on Information Systems, Orlando, USA, Dezember 5-8, ACM Press: New York, USA, S JARRATT, T.; ECKERT, C.; CLARKSON, P. J. (2004): Development of a product model to support engineering change management. In: Horvath, L. und Xirouchakis P. (Hg.): Proceedings of the Fifth International Symposium on Tools and Methods of Competitive Engineering, TCME '04, Lausanne, Schweiz, April 13-17, Millpress: Rotterdam, Niederlande, S JARRATT, T. A. W.; ECKERT, C. M.; CALDWELL, N. H. M.; CLARKSON, P. J. (2011): Engineering change: an overview and perspective on the literature. In: Research in Engineering Design, 22 (2), S JENSEN, R. Björn (1967): Modelle der Mengenlehre - Widerspruchsfreiheit und Unabhängigkeit der Kontinuum-Hypothese und des Auswahlaxioms (Lecture Notes in Mathematics, 37), Springer: Berlin/Heidelberg. JOHNSON, B.; SHNEIDERMAN, B. (1991): Tree-Maps: a space-filling approach to the visualization of hierarchical information structures. In: Proceedings of the IEEE Second Conference on Visualization, VIS 91, San Diego, USA, Oktober 22-25, IEEE Computer Society Press: Los Alamitos, USA, S Johnson, C.; Moorhead, R.; Munzner, T.; Pfister, H.; Rheingans, P.; Yoo, T. S. (Hg.) (2006): NIH/NSF visualization research challenges - January 2006: Los Alamitos, USA, IEEE. IEEE, Los Alamitos, USA. 267

297 Literaturverzeichnis (2009), Kalawsky, R. S.; O'Brien, J.; Goonetilleke, T.; Grocott, C. (Hg.): Proceedings of the 7th Annual Conference on Systems Engineering Research. CSER '09, Loughborough University, UK, April 20-23, Research School of Systems Engineering: Loughborough, UK. KEIM, D. A. (2002): Information Visualization and Visual Data Mining. In: IEEE Transactions on Visualization and Computer Graphics, 8, S KEIM, D. A.; SCHNEIDEWIND, J. (2005): Scalable Visual Data Exploration of Large Data Sets via MultiResolution. In: Journal of Universal Computer Science, 11 (11), S KELLER, R.; ECKERT, C. M.; CLARKSON, P. J. (2006): Matrices or node-link diagrams: which visual representation is better for visualising connectivity models? In: Information Visualization, 5 (1), S KELLER, R.; EGER, T.; ECKERT, C.; CLARKSON, P. J. (2005): Visualising change propagation. In: Samuel, A. und Lewis, W. (Hg.): Proceedings of the 15th International Co n- ference on Engineering Design, ICED '05, Melbourne, Australien, August 15-18, Design Society, S KNIGHT, W. (2013): Buckle up for the Vehicular Zombie Apocalypse - Autonomous technology is being developed at a remarkable rate. In: MIT Technology Review (3). KOCAR, V.; AKGUNDUZ, A. (2010): ADVICE: A virtual environment for Engineering Change Management. In: Computers in Industry, 61 (1), S KOH, E. C. Y.; CALDWELL, N. H. M.; CLARKSON, P. J. (2012): A method to assess the effects of engineering change propagation. In: Research in Engineering Design, (Special issue: Change Management) 23 (4), S KÖHLER, C.; CONRAD, J.; WANKE, S.; WEBER, C. (2008): A matrix representation of the CPM/PDD approach as a means for change impact analysis. In: Marjanovic, D. et al. (Hg.): Proceedings of the 10th International Design Conference, DESIGN 2008, Dubrovnik, Kroatien, Mai 19 22, S KÖNIGS, S. (2012): Konzeption und Realisierung einer Methode zur templategestüt z- ten Systementwicklung, Dissertation, Technische Universität Berlin, Fakultät V - Verkehrs- und Maschinensysteme, Berlin. KÖNIGS, S. F.; BEIER, G.; FIGGE, A.; STARK, R. (2012): Traceability in Systems Engineering - Review of industrial practices, state-of-the-art technologies and new research solutions. In: Advanced Engineering Informatics, 26 (4), S KORFF, A. (2008): Modellierung von eingebetteten Systemen mit UML und SysML, Spektrum, Akad. Verl.: Heidelberg. KURTEV, I.; DEE, M.; GÖKNIL, A.; VAN DEN BERG, K. (2007): Traceability-based change management in operational mappings. In: Proceedings of the Third European Conference on Model Driven Architecture: Foundations and Applications, ECMDA-TW, Haifa, Israel, Juni 11-15, Sintef: Trondheim, Norwegen, S LAGO, P.; MUCCINI, H.; VAN VLIET, H. (2009): A scoped approach to traceability management. In: Journal of Systems and Software, 82 (1), S LANDESBERGER, T. von; KUIJPER, A.; SCHRECK, T.; KOHLHAMMER, J.; VAN WIJK, J. J.; FEKETE, J.-D.; FELLNER, D. W. (2010): Visual Analysis of Large Graphs. In: IEEE Transactions on Visualization and Computer Graphics, 2 (2). LANE, D. (2006): Hierarchy, Complexity, Society. In: Pumain, D. (Hg.): Hierarchy in Natural and Social Sciences (3), Springer-Verlag: Berlin/Heidelberg, S

298 Literaturverzeichnis LEEMHUIS, H. (2005): Funktionsgetriebene Konstruktion als Grundlage verbesserter Produktentwicklung, Dissertation, Technische Universität Berlin, Fakultät V für Verkehrs- und Maschinensysteme, Berlin. LI, Y.; MAALEJ, W. (2012): Which Traceability Visualization Is Suitable in This Context? - A Comparative Study. In: Hutchison, D. et al. (Hg.): Requirements Engineering: Foundation for Software Quality. Lecture Notes in Computer Science (7195), Springer Berlin Heidelberg: Berlin, Heidelberg, S LINDEMANN, U.; KLEEDORFER, R.; GERST, M. (1998): The Development Department and Engineering Change Management. In: Frankenberger, E., Badke-Schaub, P. und Birkhofer, H. (Hg.): Designers: The Key to Successful Product Development, Springer- Verlag: London, UK, S LINDEMANN, U.; MAURER, M.; BRAUN, T. (2009): Structural Complexity Management - An Approach for the Field of Product Design, Springer: Berlin/Heidelberg. LINDEMANN, U.; REICHWALD, R. (1998): Integriertes Änderungsmanagement, Springer: Berlin/Heidelberg. LINDVALL, M.; SANDAHL, K. (1996): Practical implications of traceability. In: Software Practice & Experience, 10 (26), S LINDVALL, M.; SANDAHL, K. (1998a): How well do experienced software developers predict software change. In: The Journal of Systems and Software (43), S LINDVALL, M.; SANDAHL, K. (1998b): Traceability aspects of impact analysis in objectoriented systems. In: Journal Of Software Maintenance Research And Practice, 10 (1), S LINOS, P. K.; AUBET, P.; DUMAS, L.; HELLEBOID, Y.; LEJEUNE, D.; TULULA, P. (1994): Visualizing program dependencies: An experimental study. In: Software Practice and Experience, 24 (4), S LUCIA, A. de; FASANO, F.; OLIVETO, R.; TORTORA, G. (2007): Recovering traceability links in software artifact management systems using information retrieval methods. In: ACM Transactions on Software Engineering and Methodology, 16 (4). MACMILLAN, J.; VOSBURGH, J. R. (1986): Software Quality Indicators, Defense Technical Information Center: Ft. Belvoir, USA. MÄDER, P.; GOTEL, O.; PHILIPPOW, I. (2009): Getting Back to Basics: Promoting the Use of a Traceability Information Model in Practice. In: Proceedings of 5th International Workshop on Traceability in Emerging Forms of Software Engineering, TEFSE '09, Vancouver, Kanada, Mai 18, IEEE Computer Society Press: Los Alamitos, USA. MÄDER, P.; KUSCHKE, T.; PHILIPPOW, I. (2012): Method for recovery of traceability links. Angemeldet durch Technische Universität Ilmenau am January Veröffentlichungsnr: US 2009/ A1. MARCUS, A.; XIE, X.; POSHYVANYK, D. (2005): When and how to visualize traceability links? In: Proceedings of the Third International Workshop on Traceability in Emerging Forms of Software Engineering, TEFSE 05, Long Beach, USA, November 8, ACM Press: New York, USA (TEFSE 05), S MARTIN, M. V.; ISHII, K. (2002): Design for variety: - developing standardized and modularized product platform architectures. In: Research in Engineering Design, 13, S MAURER, M. (2006): LOOMEO - Software Tool for Multi-domain Complexity Management. In: Proceedings of the 8th International Design Structure Matrix Conference, Seattle, USA, Oktober 24-26, The Boeing Company: Seattle, USA, S

299 Literaturverzeichnis MAURER, M. S. (2007): Structural Awareness in Complex Product Design, Dissertation, Technische Universität München, Fakultät für Maschinenwesen, München. MAUS, R.; WEBER, C. (2005): Documentation and enhancement of the traceability of finite-element-analysis. In: Samuel, A. und Lewis, W. (Hg.): Proceedings of the 15th International Conference on Engineering Design, Paper No , ICED '05, Melbourne, Australien, August 15-18, Design Society, S [Executive Summary]. MCGUFFIN, M.; JURISICA, I. (2009): Interaction Techniques for Selecting and Manipulating Subgraphs in Network Visualizations. In: IEEE Transactions on Visualization and Computer Graphics, 15 (6), S Meyer, B.; Nawrocki, J. R.; Walter, B. (Hg.) (2008): Balancing agility and formalism in software engineering - (CEE-SET 2007): Berlin, Springer. Springer, Berlin. microtool GmbH (2012): objectif - Das UML-Tool für modellgetriebene Entwicklung. (zuletzt geprüft am: ). Modelica Association (2013): Modelica and the Modelica Association. https://www.modelica.org/ (zuletzt geprüft am: ). MOHAN, K.; RAMESH, B. (2007): Traceability-based knowledge integration in group decision and negotiation activities. In: Decision Support Systems, 43 (3), S MOHAN, K.; XU, P.; CAO, L.; RAMESH, B. (2008): Improving change management in software development: Integrating traceability and software configuration ma n- agement. In: Decision Support Systems, 45 (4), S MÜLLER, R. (2011): Visualisierung von Partialmodellen und modellübergreifenden Abhängigkeiten im Systems Engineering, Studienarbeit, Humboldt-Universität Berlin, Institut für Informatik, Berlin. MÜLLER, R. (2013): Entwicklung eines assistenzbasierten Softwarewerkzeugs zur visuellen Unterstützung des Änderungsmanagements im Systems Engineering auf Basis von Tracelinks, Diplomarbeit, Humboldt-Universität Berlin, Institut für Informatik, Berlin. MUNZNER, T. (1997): H3: Laying Out Large Directed Graphs in 3D Hyperbolic Space. In: Proceedings of the IEEE Symposium on Information Visualization, InfoVis '97, Phoenix, USA, Oktober 20-21, IEEE Computer Society Press: Los Alamitos, USA, S MUTH, B. (2012): Anforderungsaustausch mit OMG ReqIF in der Praxis. In: ProduktDatenJournal (2), S MUTZEL, P. (2000): An alternative method to crossing minimization on hierarchical graphs. In: SIAM Journal on Optimization, 11 (4), S NASA STI (2007): Systems Engineering Handbook. 1. Aufl., National Aeronautics and Space Administration: Washington, USA. NEJMEH, B.; DICKEY, T.; WARTIK, S. (1989): Traceability Technology at the Software Productivity Consortium. In: Ritter, G. (Hg.): Proceedings of the IFIP 11th World Computer Congress, San Francisco, USA, August 28 - September 1, Elsevier Science Ltd., S NG, K. (2006): A critical analysis of current engineering design methodologies from a decision making perspective. In: Proceedings of the Second International Virtual Conference on Innovative Production Machines and Systems, I*PROMS 2006, Juli 3-14, S

300 Literaturverzeichnis NORTH, C. (2006): Toward Measuring Visualization Insight. In: IEEE Computer Graphics and Applications, 26 (3), S OLIVETO, R.; GETHERS, M.; POSHYVANYK, D.; LUCIA, A. de (2010): On the Equivalence of Information Retrieval Methods for Automated Traceability Link Recovery. In: Proceedings of the 18th IEEE International Conference on Program Comprehension, ICPC '10, Braga, Portugal, Juni 30 -Juli 2, IEEE Computer Society Press: Los Alamitos, USA, S OLLINGER, G. A.; STAHOVICH, T. F. (2004): RedesignIT A Model-Based Tool for Managing Design Changes. In: Journal of Mechanical Design, 126 (2), S O'NEAL, J.; CARVER, D. (2001): Analyzing the impact of changing requirements. In: Proceedings of the IEEE International Conference on Software Maintenance, ICSM 2001, Florenz, Italien, November 7-9, IEEE Computer Society Press: Los Alamitos, USA, S OUERTANI, M. (2008): Supporting conflict management in collaborative design: An approach to assess engineering change impacts. In: Computers in Industry, 59 (9), S OUERTANI, M.; GZARA, L. (2008): Tracking product specification dependencies in collaborative design for conflict management. In: Computer-Aided Design, 40 (7), S PAHL, G.; BEITZ, W.; FELDHUSEN, J.; GROTE, K.-H. (2007): Konstruktionslehre - Grundlagen erfolgreicher Produktentwicklung Methoden und Anwendung. 7. Aufl., Springer: Berlin/Heidelberg. PAIGE, R. F.; OLSEN, G. K.; KOLOVOS, D. S.; ZSCHALER, S.; POWER, C. (2008): Building Model-Driven Engineering Traceability Classifications. In: Proceedings of the 4th European Conference on Model Driven Architecture. Foundations and Applications, ECMDA Traceability Workshop, Berlin, Juni 9-12, Sintef: Trondheim, Norwegen, S PARVAN, M.; MAURER, M.; LINDEMANN, U. (2010): Software wizard design for complexity management application. In: Marjanovic, D. et al. (Hg.): Proceedings of the 11th International Design Conference, DESIGN 2010, Dubrovnik, Kroatien, Mai 17-20, S PAVLOPOULOS, G. A.; WEGENER, A.-L.; SCHNEIDER, R. (2008): A survey of visualization tools for biological network analysis. In: BioData Mining, 1 (1), S PFLEEGER, S.; BOHNER, S. (1990): A framework for software maintenance metrics. In: Proceedings of the Conference on Software Maintenance, San Diego, USA, November 26-29, IEEE Computer Society Press: Los Alamitos, USA, S PFLEEGER, S. Lawrence (1987): Software engineering: the production of quality software, Macmillan Publishing Co.: New York, USA. PIERCE, R. A. (1978): A requirements tracing tool. In: Jackson, S. und Lockett, J. Ann (Hg.): Proceedings of the Software Quality Assurance Workshop on Functional and Performance Issues, New York, USA, ACM Press: New York, USA, S PIMMLER, T. U.; EPPINGER, S. D. (1994): Integration analysis of product decompositions, MIT Press: Cambridge, USA. PINHEIRO, F.; GOGUEN, J. (1996): An object-oriented tool for tracing requirements. In: Proceedings of the Second International Conference on Requirements Engineering, Colorado Springs, USA, April 15-18, IEEE Computer Society Press: Los Alamitos, USA, S

301 Literaturverzeichnis PINHEIRO, F. A. C. (2003): Requirements Traceability. In: Sampaio do Prado Leite, J. C. und Doorn, J. H. (Hg.): Perspectives on Software Requirements, Springer: Berlin, S PLETTE, A. (2009): Ganzheitliches Lastenheftmanagement. IBM Rational Roadshow 2009, POHL, K. (1996): PRO-ART: Enabling Requirements Pre-Traceability. In: Proceedings of the Second IEEE International Conference on Requirements Engineering, ICRE 96, Colorado Springs, USA, April 15-18, IEEE Computer Society: Washington, USA, S POHL, M.; SCHEEL, C. (2004): Toolvorstellung Reqtify, Technische Universität Berlin (Hg.). (zuletzt geprüft am: ). PONN, J.; LINDEMANN, U. (2008): Konzeptentwicklung und Gestaltung technischer Produkte - Optimierte Produkte - systematisch von Anforderungen zu Konzepten, Springer: Berlin/Heidelberg. Pumain, D. (Hg.) (2006): Hierarchy in Natural and Social Sciences: Berlin/Heidelberg, Springer-Verlag (3). Springer-Verlag, Berlin/Heidelberg. PURCHASE, H. (1998): The effects of graph layout. In: Proceedings of the 1998 Australasian Computer Human Interaction Conference, OzCHI '98, Adelaide, Australia, November 30 - Dezember 4, IEEE Computer Society Press: Los Alamitos, USA, S PURCHASE, H.; COHEN, R.; JAMES, M. (1997): An Experimental Study of the Basis for Graph Drawing Algorithms. In: The ACM Journal of Experimental Algorithmic, 2, S. Article 4. QUEILLE, J. P.; VOIDROT, J. F.; WILDE, N.; MUNRO, M. (1994): The impact analysis task in software maintenance: a model and a case study. In: Müller, H. A. und Georges, M. (Hg.): Proceedings of the International Conference on Software Maintenance, ICSM '94, Victoria, Kanada, September 19-23, IEEE Computer Society Press: Los Alamitos, USA, S RAIA, F. (2005): Students' Understanding of Complex Dynamic Systems. In: Journal of Geoscience Education, 53 (5), S RAJLICH, V. (2000): A model and a tool for change propagation in software. In: ACM SIGSOFT Software Engineering Notes, 25 (1), S. 72. RAMESH, B.; EDWARDS, M. (1993): Issues in the development of a requirements traceability model. In: Proceedings of the International Symposium on Requirements Engineering, RE '93, San Diego, USA, Januar 4-6, IEEE Computer Society Press: Los Alamitos, USA, S RAMESH, B.; JARKE, M. (2001): Towards Reference Models for Requirements Traceability. In: IEEE Transactions on Software Engineering, 37 (1), S RAMESH, B.; STUBBS, C.; POWERS, T.; EDWARDS, M. (1997): Requirements traceability: Theory and practice. In: Ann. Softw. Eng, 3, S REDDI, K. R.; MOON, Y. B. (2009): A framework for managing engineering change propagation. In: International Journal of Innovation and Learning, 6 (5), S REILLY, N. B. (1999): The team based product development guidebook, ASQ Quality Press: Milwaukee, USA. 272

302 Literaturverzeichnis REN, X.; SHAH, F.; TIP, F.; RYDER, B. G.; CHESLEY, O. (2004): Chianti: A Tool for Change Impact Analysis of Java Programs. In: Proceedings of the 19th Annual ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications, OOPSLA '04, Vancouver, Kanada, Oktober 24-28, ACM Press: New York, USA, S RHEE, S. J.; ISHII, K. (2003): Using cost based FMEA to enhance reliability and serviceability. In: Advanced Engineering Informatics, 17 (3-4), S RIEBISCH, M.; PACHOLIK, A.; BODE, S. (2011): Towards Optimization of Design Decisions for Embedded Systems by Exploiting Dependency Relationships. In: Dagstuhl-Workshop Modellbasierte Entwicklung eingebetteter Systeme, MBEES, Schloss Dagstuhl, Februar 16-18, S RIVIERE, A.; FÉRU, F.; TOLLENAERE, M. (2003): Controlling Product related Engineering Changes in the Aircraft Industry. In: Folkeson, A. et al. (Hg.): Proceedings of the 14th International Conference on Engineering Design, ICED '03, Stockholm, Schweden, AUGUST 19-21, S. Full Paper Nr. DS31_1230FPB. Rome Air Development Center (1986): Automated Life Cycle Impact Analysis System, Air Force Systems Command (Hg.): Griffiss Air Force Base, Rome, USA, (RADC- TR ). ROSENAUER, G. B. (2008): A Standards-Based Approach to Dynamic Tool Integration Using Java Business Integration - A Redesign of the ToolNet Framework built on Enterprise Integration Standards, Diplomarbeit, ISIS Vienna Universitity of Technology, Institute of Software Technology and Interactive Systems, Wien, Österreich. ROSENBERG, D.; STEPHENS, M. (2007): Use case driven object modeling with UML - Theory and practice, Apress: Berkeley, USA. ROSENTHAL, S. R. (1992): Effective Product Design and Development - How to cut lead time and increase customer satisfaction, Irwin Professional Publ.: Chiago, USA. SCHUH, G. (2005): Produktkomplexität managen - Strategien - Methoden - Tools. 2. Aufl., Hanser: München, Wien. SCHULZ, H.-J.; SCHUMANN, H. (2006): Visualizing Graphs - A Generalized View. In: Proceedings of the Tenth International Conference on Information Visualization, Info- Vis '06, London, UK, Juli 5-7, IEEE Computer Society Press: Los Alamitos, USA, S SCHWARZ, H.; EBERT, J.; WINTER, A. (2010): Graph-based traceability: a comprehensive approach. In: Software & Systems Modeling, 9 (4), S SEDLMAIR, M.; BERNHOLD, C.; HERRSCHER, D.; BORING, S.; BUTZ, A. (2009): MostVis: An Interactive Visualization Supporting Automotive Engineers in MOST Catalog E x- ploration. In: Proceedings of the 13th International Conference on Information Visualisation, IV '09, Barcelona, Spanien, Juli 15-17, IEEE Computer Society Press: Washington, USA, S SENGE, P. M. (1994): The fifth discipline - The art and practice of the learning organization, Doubleday/Currency: New York, USA. SHNEIDERMAN, B. (1996): The eyes have it: A task by data type taxonomy for information visualizations. In: Proceedings of the IEEE Symposium on Visual Languages, Boulder, USA, September 3-6, IEEE Computer Society Press: Los Alamitos, USA, S Siemens Industry Software GmbH & Co. KG (2012): Systems Engineering und Anforderungs-Management mit Teamcenter. 273

303 Literaturverzeichnis (zuletzt geprüft am: ). Siemens PLM Software Inc. (2010): Mechatronics Concept Designer - Ein funktionsorientierter Ansatz für den Maschinen- und Anlagenbau. (zuletzt geprüft am: ). Siemens PLM Software Inc. (2012): Teamcenter 9.1: Systems Engineering Guide, (Publication Nr. PLM00038 F). SOSA, M. E.; AGRAWAL, A.; EPPINGER, S. D.; ROWLES, C. M. (2005): A Network Approach to Define Modularity of Product Components. In: Proceedings of the 17th ASME International Conference on Design Theory and Methodology, DTM, Long Beach, USA, September Bände, ASME (5a), S SPANOUDAKIS, G.; ZISMAN, A. (2005): Software Traceability: A Roadmap. In: Chang, S. K. (Hg.): Handbook of software engineering and knowledge engineering, Bd. 3, World Scientific Publishing: New Jersey, USA, S Sparx Systems Pty Ltd. (2011): Enterprise Architect. (zuletzt geprüft am: ). STACHOWIAK, H. (1973): Allgemeine Modelltheorie, Springer: Wien, Österreich. STACHOWIAK, H. (1980): Der Modellbegriff in der Erkenntnistheorie. In: Journal for General Philosophy of Science - Zeitschrift für Allgemeine Wissenschaftstheorie, 11 (1), S STARK, R.; FIGGE, A. (2011): Eco Tracing - A Systems Engineering Method for Efficient Tracelink Modelling. In: Culley, S. J. et al. (Hg.): Proceedings of the 18th International Conference on Engineering Design. Product and Systems Design, Vol. 4, ICED '11, Kopenhagen, Dänemark, August 15-18, S STARK, R.; HAYKA, H.; MÜLLER, P.; PASCH, F. (2012): Kollaboration und digitale Werkzeuge in der Entwicklung. In: Automobiltechnische Zeitschrift extra (5), S StarUML (2012): StarUML - The Open Source UML/MDA Platform. (zuletzt geprüft am: ). STASKO, J.; CATRAMBINE, R.; GUZDIAL, M.; MCDONALD, K. (2000): An evaluation of space-filling information visualizations for depicting hierarchical structures. In: International Journal of Human-Computer Studies, 53 (5), S STERMAN, J. D. (2000): Business dynamics: - Systems thinking and modeling for a complex world, Irwin/McGraw-Hill: Boston, USA. STEVENS, R.; BROOK, P.; JACKSON, K.; ARNOLD, S. (1998): Systems engineering - Coping with complexity, Prentice Hall Europe: London, England. STEWARD, D. (1962): On an Approach to the Analysis of the Structure of Large Systems of Equations. In: SIAM Review (5), S STEWARD, D. V. (1981): The Design Structure System: A Method for Managing the Design of Complex Systems. In: IEEE Transactions on Engineering Management, 28 (3), S STOLZ, P.; KRAUSE, M. (2009): Traceability im Systems Engineering - Wieso? Weshalb? Warum? In: 8. Requirements Engineering Tagung, REConf '09, München, März ŠTORGA, M.; MARJANOVIĆ, D.; PAVKOVIĆ, N.; BOJČETIĆ, N.; STANKOVIĆ, T. (2010): Improving design communication with traceable engineering design information. In: Proceedings of the Fourth International Conference on Design Computing and Cognition, DCC'10, July 08-13: Stuttgart, Germany. 274

304 Literaturverzeichnis SULLIVAN, L. P. (1986): Quality function deployment. In: Quality Progress, 19 (6), S SUTINEN, K.; ALMEFELT, L.; MALMQVIST, J. (2000): Implementation of requirements traceability in systems engineering tools. In: Proceedings of the Produktmodeller 2000, Linköping, Schweden, November 7-8, Linköping University: Linköping, Schweden, S SUTINEN, K.; ALMEFELT, L.; MALMQVIST, J. (2002): Supporting Concept Development Using Quantitative Requirements Traceability. In: Proceedings of the 12th Annual International Symposium. "Engineering 21st Century Systems: Problem Solving Through Structured Thinking", Las Vegas, USA, Juli 28 - August 1. SUTINEN, K.; GUSTAFSSON, G.; MALMQVIST, J. (2004): Computer Support for Requirements Management in an International Product Development Project. In: Proceedings of the ASME 2004 International Design Engineering Technical Conferences and Computers and Information in Engineering Conference, IDETC 04, Salt Lake City, USA, September 28 Oktober 2 (Volume 3a), S TERWIESCH, C.; LOCH, C. H. (1999): Managing the Process of Engineering Change Orders: The Case of the Climate Control System in Automobile Development. In: Journal of Product Innovation Management, 16 (2), S TESCHL, G. (2008): Mathematik für Informatiker. 3. Aufl., Springer: Berlin/Heidelberg. TESEON GmbH (2012): Loomeo. (zuletzt geprüft am: ). THOMAS, J. J.; COOK, K. A. (2005): Illuminating the path - The research and development agenda for visual analytics, IEEE Computer Society Press: Los Alamitos, USA. TRETOW, G.; GÖPFERT, J.; HEESE, C. (2008): In sieben Schritten systematisch entwickeln. In: CAD-CAM Report (8), S TUDORACHE, T. (2006): Employing Ontologies for an Improved Development Process in Collaborative Engineering, Dissertation, Technische Universität Berlin, Fakultät IV - Elektrotechnik und Informatik, Berlin. TURVER, R. J.; MUNRO, M. (1994): An early impact analysis technique for software maintenance. In: Journal of Software Maintenance: Research and Practice, 6 (1), S ULRICH, K. (1995): The role of product architecture in the manufacturing firm. In: Research Policy, 24 (3), S VAN GORP, P.; ALTHEIDE, F.; JANSSENS, D. (2006): Traceability and Fine-Grained Constraints in Interactive Inconsistency Management. In: Proceedings of the Second European Conference on Model Driven Architecture. Foundations and Applications, ECMDA Traceability Workshop, Bilbao, Spanien, Juli 10-13, Sintef: Trondheim, Norwegen, S VEREIN DEUTSCHER INGENIEURE VDI-Richtlinie 2206: Entwicklungsmethodik für mechatronische Systeme, Juni Beuth Verlag GmbH, Berlin. VEREIN DEUTSCHER INGENIEURE VDI-Richtlinie 2219: Informationsverarbeitung in der Produktentwicklung - Einführung und Wirtschaftlichkeit von EDM/PDM- Systemen, August Beuth Verlag GmbH, Berlin. VORSATZ, T. (2012): Produktentwicklung unter Verwendung des RFLP-Ansatzes mit DS CATIA V6 am Beispiel eines Fahrzeug-Heckklappenantriebes, Studienarbeit, Technische Universität Berlin, Institut für Werkzeugmaschinen und Fabrikbetrieb, Berlin. 275

305 Literaturverzeichnis WALDERHAUG, S.; STAV, E.; JOHANSEN, U.; OLSEN, G. K. (2009): Traceability in Model- Driven Software Development. In: Tiako, P. F. (Hg.): Designing software-intensive systems: Methods and principles, Information Science Reference: Hershey, S WARE, C. (2004): Information visualization - Perception for design. 2. Aufl., Morgan Kaufman: San Francisco, USA. WEAVER, C. (2008): Multidimensional Visual Analysis Using Cross-Filtered Views. In: Ebert, D. und Ertl, T. (Hg.): Proceedings of the Symposium on Visual Analytics Science and Technology, VAST '08, Columbus, USA, Oktober 21-23, IEEE Computer Society Press: Los Alamitos, USA, S WEBER, C. (2005): What Is 'Complexity'? In: Samuel, A. und Lewis, W. (Hg.): Proceedings of the 15th International Conference on Engineering Design, ICED '05, Melbourne, Australien, August 15-18, Design Society, S WEBER, C. (2007): Looking at DFX and Product Maturity from the Perspective of a New Approach to Modelling Product and Product Development Processes. In: Krause, F.-L. (Hg.): The Future of Product Development. Proceedings of the 17th CIRP Design Conference, Springer Berlin / Heidelberg, S WEBER, C.; DEUBEL, T. (2003): New theory-based concepts for PDM and PLM. In: Folkeson, A. et al. (Hg.): Proceedings of the 14th International Conference on Eng i- neering Design, Paper No. 1468, ICED '03, Stockholm, Schweden, AUGUST WEBER, J. (2009): Automotive development processes - Processes for successful customer oriented vehicle development, Springer: Berlin, New York. WECK, O. L. de; BOUNOVA, G. (2007): Change Propagation Analysis in Complex Technical Systems. Colloque d'automne du LIX 2007, Laboratoire d'informatique de l'ecole Polytechnique: Paris, Frankreich, , Paris, Frankreich. WEILKIENS, T. (2008): Systems engineering mit SysML/UML - Modellierung, Analyse, Design. 2. Aufl., Dpunkt-Verlag: Heidelberg. WERNER, H.; MUTH, M.; WEBER, C. (1997): Functional modelling using an objectoriented design system. In: Proceedings of the 11th International Conference on Engineering Design, ICED '97, Tampere, Finnland, August 19-21, S WINKLER, S. (2008): On Usability in Requirements Trace Visualizations. In: Proceedings of the International Conference on Requirements Engineering Visualization, REV '08, Barcelona, Spanien, September 8, IEEE Computer Society Press: Piscataway, USA, S WINKLER, S. (2009): Trace Retrieval for Evolving Artifacts. In: Proceedings of the ICSE Workshop on Traceability in Emerging Forms of Software Engineering, TEFSE '09, Vancouver, Kanada, Mai 18, IEEE Computer Society Press: Los Alamitos, USA, S WINKLER, S.; PILGRIM, J. (2010): A survey of traceability in requirements engineering and model-driven development. In: Software & Systems Modeling, 9 (4), S WOLTERECK, M. (2004): FMEA nach VDA Neue Aspekte einer bewährten Methode zur effizienten Analyse sicherheitsrelevanter mechatronischer Systeme. Risk.Tech Risikomanagement in der Automobilwirtschaft. TÜV Akademie: München, , München. WYATT, D. F.; WYNN, D. C.; JARRETT, J. P.; CLARKSON, P. J. (2012): Supporting product architecture design using computational design synthesis with network stru c- ture constraints. In: Research in Engineering Design, 23 (1), S

306 Literaturverzeichnis WYNN, D.; WYATT, D. F.; NAIR, S.; CLARKSON, P. (2010a): An introduction to the Cambridge Advanced Modeller. In: Proceedings of the 1st International Conference on Modelling and Management of Engineering Processes, MMEP '10, Cambridge, UK, Juli 19-20, Department of Engineering, University of Cambridge: Cambridge, UK, S WYNN, D. C.; CALDWELL, N. H. M.; CLARKSON, P. J. (2010b): Can change prediction help prioritise redesign work in future engineering systems? In: Marjanovic, D. et al. (Hg.): Proceedings of the 11th International Design Conference, DESIGN 2010, Dubrovnik, Kroatien, Mai 17-20, S WYNN, D. C.; NAIR, S.; CLARKSON, P. J. (2009): The P3 Platform - An Approach and Software System for Developing Diagrammatic Model-Based Methods in Design Research. In: Bergendahl, M. N., Grimheden, M. und Leifer, L. (Hg.): Proceedings of the 17th International Conference on Engineering Design, Bd. 2, ICED '09, Stanford, USA, August 24-27, Design Society. YANG, F.; DUAN, G.-j. (2012): Developing a parameter linkage-based method for searching change propagation paths. In: Research in Engineering Design, (Special issue: Change Management) 23 (4), S YASSINE, A. A. (2004): An Introduction to Modeling and Analyzing Complex Product Development Processes Using the Design Structure Matrix (DSM ) Method. In: Urbana, 51 (9), S ZENTIS, T.; CZECH, A.; PREFI, T.; SCHMITT, R. (2011): Technisches Risikomanagement in produzierenden Unternehmen, Apprimus Verlag: Aachen. 277

307

308 GLOSSAR Begriff Beschreibung Synonym Abhängigkeit Die Abhängigkeitsbeziehung (engl. dependency) ist eine Beziehung zwischen zwei Elementen, die beschreibt, dass ein Element ein anderes Element für seine Spezifikation oder Implementierung benötigt [WEILKIENS 2008, S. 233]. Abhängigkeitsmatrix s. Traceability-Matrix Accuracy Algorithmus Änderungsmanagement Änderungspfad Anforderung Ein Parameter zur Angabe der Korrektheit einer Treffermenge, der sich aus dem Verhältnis der Vereinigungsmenge der korrekt klassifizierten Elemente zur Vereinigungsmenge aller Elemente berechnet Endliches Set von definierten Regeln für die Lösung eines Problems mit einer endlichen Anzahl von Schritten [IEEE Computer Society 1990, S. 9] Das Änderungsmanagement ist ein Prozess, bei dem Modifikationen oder Erweiterungen an Artefakten vorgenommen werden, die an einem Punkt des Produktlebenszyklus bereits freigegeben waren [TERWIESCH UND LOCH 1999]. Gerichteter Graph aus von einer Änderung betroffenen Elementen als Repräsentation einer kausalen Änderungssequenz, wobei jedes betroffene Element über hierarchische Relationen oder Tracelinks mit genau einem Vorgänger- und Nachfolgerelement verbunden ist (mit Ausnahme des, die Änderung verursachenden, Startelements, das nur ein Nachfolgerelement hat, und des, die Änderungssequenz terminierenden, Endelements, das nur ein Vorgängerelement hat) 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 erreichen [IEEE Computer Society 1990, S. 62]. 279

309 Glossar Begriff Beschreibung Synonym Artefakt Artefakt-interner Tracelink Artefaktübergreifender Tracelink Auswirkungsanalyse Baum Blattelement Candidate Impact Set Compound Graph Constraintbased Layout Disziplin Durchgängige Nachverfolgbarkeit False negative False positive Beschreibt jegliche Art von während der Produktentwicklung erzeugten Produkt-beschreibenden Informationen (Spezifikationen, Funktionsstrukturen, Produktstrukturen etc.), unabhängig von ihrer informationstechnischen Ausführbarkeit. [CLELAND- HUANG ET AL. 2003, S. 797] Beschreibt die Abhängigkeit zwischen zwei Elementen aus dem gleichen Artefakt. Beschreibt die Abhängigkeit zwischen zwei Elementen aus unterschiedlichen Artefakten. Ein Graph, in dem je zwei Knoten durch genau einen Weg verbunden sind, der also keinen Kreisschluss beinhaltet. Element auf der untersten hierarchischen Ebene eines Artefakts Teilmenge der Elemente, die von der Änderung potentiell betroffen sind [BOHNER 2002] Graph, der sowohl hierarchische als auch generische Relationen, also beispielsweise Artefaktinterne Relationen, beinhaltet Übergeordnete Bezeichnung aller Anordnungskonzepte für Node-Link-Diagramme, bei denen die Positionierung der Knoten durch prädefinierte Regeln bestimmt ist. Abgrenzung der klassischen Fachgebiete wie Mechanik, Elektrik & Elektronik und Informationstechnik Element, welches der zu bestimmenden Teilmenge fälschlicherweise nicht zugewiesen wurde. Element, welches der zu bestimmenden Teilmenge fälschlicherweise zugewiesen wurde. Partialmodell s. Impact Analyse Tree Domäne s. Traceability 280

310 Glossar Begriff Beschreibung Synonym Fisheye Linse Force-directed Funktion Funktionsstruktur gerichteter Graph Gestaltprinzipien Gewichteter Graph Granularität Graph Hierarchie Die Fisheye Linse zeigt Objekte in der Nähe des Cursors in großer Detailtiefe, ohne dabei das Anzeigen des globalen Kontextes zu vernachlässigen, der in zunehmend geringerer Detailtiefe angezeigt wird [FURNAS 1986, S. 16] Verbreiteter Algorithmus zur Berechnung eines Graphenlayouts, bei dem zwischen den Elementen je nach Gewicht entweder eine Anziehung oder eine Abstoßung vorgegeben wird. [LANDESBERGER ET AL. 2010] Allgemeiner und gewollter Zusammenhang zwischen Eingang und Ausgang eines Systems mit dem Ziel, eine Aufgabe zu erfüllen [PAHL ET AL. 2007]. Verknüpfung von Teilfunktionen zu einer Gesamtfunktion [PAHL ET AL. 2007]. Graph, deren Kanten eine Richtung zugewiesen haben Grundlegende Empfehlungen zur Gestaltung von visuellen Repräsentationen, die auf Erkenntnissen der Psychologie basieren. [WARE 2004] Graph, bei dem allen Kanten ein Gewicht zugeordnet ist Bezeichnet im Kontext der durchgängigen Nachverfolgbarkeit den Detaillierungsgrad auf dem zwischen unterschiedlichen Artefakten Tracelinks modelliert werden [EGYED ET AL. 2007]. Während eine hohe oder feine Granularität bedeutet, dass sehr detailliert modelliert wird (z. B. zwischen Parametern unterschiedlicher Elemente), bedeutet eine geringe oder grobe Granularität, dass auf einer abstrakten Ebene modelliert wird. Abstrakte Struktur, bestehend aus einer Menge von Objekten (Knoten) und den Verbindungen zwischen diesen (Kanten) [WARE 2004; SOSA ET AL. 2005, S. 437] Ein Arrangement oder eine Klassifikation verwandter Abstraktionen, die entsprechend ihrer Inklusion und ihres Detailgrads über- oder untereinander rangieren [BODE UND RIEBISCH 2010, S. 186] 281

311 Glossar Begriff Beschreibung Synonym Hierarchische Transitivität House of Quality Impact Analyse Änderungsfortpflanzung, Auswirkungsanalyse Inklusionshierarchie Integrative Software Werkzeuge Kanten Knoten Komplexität Komponente Konsistenz Layered Layout Weist ein untergeordnetes Element ein Wesensmerkmal auf, aggregieren seine übergeordneten Elemente dieses und die aller anderen untergeordneten Kinder. Methode zur Produktgestaltung, damit diese den Wünschen der Kunden Rechnung tragen [BARNETT UND RAJA 1995, S. 31] 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. Hierarchisches Konstrukt, bei dem die übergeordneten Elemente abstrakte Container für die untergeordneten Elemente darstellen Im Kontext der durchgängigen Nachverfolgbarkeit werden Software Werkzeuge als integrativ bezeichnet, wenn mit ihnen Tracelinks zwischen Artefakten, die aus bzw. mit existierenden Autorenwerkzeugen importiert bzw. synchronisiert werden können. Repräsentation der Relationen zwischen den Elementen eines relationalen Datensatzes in einem Graphen Repräsentation der Elemente eines relationalen Datensatzes in einem Graphen Die Komplexität bezieht sich auf die Anzahl und Art der Beziehungen zwischen Elementen in einem System. [WEILKIENS 2008, S. 10] Bestandteil aus welchen ein System aufgebaut ist. Komponenten können sowohl Hard- als auch Software sein und weiter in andere Komponenten unterteilt werden [IEEE Computer Society 1990, S. 18]. Grad der Uniformität, Standardisierung und Freiheit von Widersprüchen zwischen den Artefakten bzw. Teilen eines Systems [IEEE Computer Society 1990, S. 21]. Übergeordnete Bezeichnung aller Anordnungskonzepte für Node-Link-Diagramme, bei denen Knoten gleicher hierarchischer Ebene auf einer gemeinsamen horizontalen Linie positioniert werden upward causation Verknüpfungen, Links Entitäten, Elemente 282

312 Glossar Begriff Beschreibung Synonym Lesbarkeit Mechatronik Mental Map Modell Modellieren Multi-scale Layout Nicht-integrative Software Werkzeuge Node-Link Partialmodell Phasen-interner Tracelink Die relative Leichtigkeit, mit der ein Nutzer die Information findet, die er sucht. Daher findet der Nutzer in einer besser lesbareren Darstellung die Information schneller und macht dabei weniger Fehler. [GHONIEM ET AL. 2004, S. 2] Mechatronik ist ein interdisziplinäres Gebiet, bei dem folgende Disziplinen zusammenwirken: mechanische und mit ihnen gekoppelte Systeme, elektronische Systeme, Informationstechnik. Es werden synergetische Effekte angestrebt, die mehr bein-halten als die reine Addition der Disziplinen. [ISERMANN 1999, S. 4] Etablierter Fachbegriff der Informationsvisualisierung, mit dem die mentale Repräsentation logischer und anderer Zusammenhänge bezeichnet wird [EADES 1991] Ein Modell ist ein dem Betrachtungszweck entsprechender Repräsentant seines Originals. (vgl. [STACHOWIAK 1973; PAHL ET AL. 2007]) Tätigkeit des Erstellens oder Modifizierens eines Modells Übergeordnete Bezeichnung aller Anordnungskonzepte für Node-Link-Diagramme, bei denen zunächst lediglich ein Teil des kompletten Graphen angezeigt und die feingranulareren Strukturen bei Bedarf ebenenweise eingeblendet werden können Im Kontext der durchgängigen Nachverfolgbarkeit werden Software Werkzeuge als nicht-integrativ bezeichnet, wenn mit ihnen ausschließlich Tracelinks zwischen Artefakten modelliert werden können, die in demselben Werkzeug erstellt wurden. Mit einem Node-Link-Layout können relationale Datensätze visualisiert werden, indem die Elemente über Knoten (engl.: Nodes) und ihre inhaltlichen Abhängigkeiten über verbindende Kanten (engl.: Links) abgebildet werden. Dokumente, Modelle, Code usw., die während einer Phase des Entwicklungsprozesses erstellt werden Beschreibt die Abhängigkeit zwischen zwei Elementen aus Artefakten der gleichen Prozessphase. Readability Kognitive Karte (wenig gebräuchlich) Entity relationship Artefakt 283

313 Glossar Begriff Beschreibung Synonym Phasenübergreifender Tracelink Planare Graphen Precision Produktmodell Propagates Qualitative Traceability Quantitative Traceability radiales Layout Recall Requirements Traceability Beschreibt die Abhängigkeit zwischen zwei Elementen aus Artefakten unterschiedlicher Prozessphasen. Graphen, die ohne Überkreuzungen von Kanten gezeichnet werden können 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 Gesamtmenge aller, im Rahmen der Entwicklung entstehenden, Produkt-beschreibenden Modelle (wie bspw. Anforderungen oder Geometrie- Modelle) Menge aus Elementen, welche die Änderung potentiell propagieren, weswegen deren Tracelinks im Verlauf der Impact Analyse nachverfolgt werden müssen Lässt nur die Identifikation abhängiger Elemente zu, ohne Aussagen über den Grad der Abhängigkeit treffen zu können. Lässt Aussagen über das Ausmaß der Beeinflussung eines Elements durch die Änderung eines abhängigen Elements zu [SUTINEN ET AL. 2002]. Übergeordnete Bezeichnung aller Anordnungskonzepte für Node-Link-Diagramme, bei denen Kindelemente auf einer konzentrischen Kreisbahn verteilt um das Elternelelement angeordnet sind. Ein Parameter zur Angabe der Vollständikeit einer Treffermenge, der sich aus dem Verhältnis der Anzahl der korrekterweise identifizierten Elemente zu der Vereinigungsmenge der relevanten Elemente ergibt. 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]. positive predictive value; specificity true positive rate, hit rate, sensitivity 284

314 Glossar Begriff Beschreibung Synonym Space-filling System Systems Engineering Traceability Traceability- Matrix Traceability- Modell Traceability- Schema Tracelink Methode zur Repräsentation von Graphen, wobei unterschiedliche geometrische Formen (wie bspw. Linien, Rechtecke, Zylinder oder Kreissegmente) für Knoten genutzt werden. Die hierarchische Relation der Elemente wird dabei über die geometrische Ausrichtung oder Verschachtelung der Elemente zueinander ausgedrückt (bspw. durch Einschluss oder Überschneidung). [SCHULZ UND SCHUMANN 2006, S. 167] Ein System besteht aus einer Menge von Elementen (Teilsystemen), die Eigenschaften besitzen und durch Beziehungen miteinander verknüpft sind. Ein System wird durch eine Systemgrenze von der Umgebung abgegrenzt und steht mit ihr durch Einund Ausgangsgrößen in Beziehung [ ]. [EHRLENSPIEL 2007, S. 20] Interdisziplinäre Methodik zur erfolgreichen Entwicklung von Systemen [HASKINS 2006, S. 1.5]. Traceability ist eine Methode zur Unterstützung der Entwicklung mechatronischer 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 Produkt-beschreibenden Artefakten, wird ebenfalls mit dem Begriff Traceability beschrieben. Matrix zur Dokumentation von Beziehungen zwischen zwei oder mehr Produkten (Artefakten) des Entwicklungsprozesses [IEEE Computer Society 1990, S. 78] Bezeichnet die Gesamtheit aus betrachteten Artefakten und ihrer, die gegenseitigen Abhängigkeiten beschreibenden, Tracelinks (in Anlehnung an [PINHEIRO 2003, S. 106]). Bezeichnet ein Schema, in dem für ein Traceability- Werkzeug die zur Verknüpfung erlaubten Artefakte, Elemente und Tracelinks beschrieben werden [WINKLER UND PILGRIM 2010]. Objekt, um die Beziehung zwischen zwei Elementen auszudrücken (in Anlehnung an [WINKLER UND PILGRIM 2010]). Durchgängige Nachverfolgbarkeit Abhängigkeitsmatrix Integriertes Modell Metamodell Link, Relation, Traceability Link, Trace Link, Verknüpfung 285

315 Glossar Begriff Beschreibung Synonym Tracelink- Modell Treemap True negative True positive Ungerichteter Graph Upward Causation Verknüpfung Verzerrungstechniken Wurzelbaum Wurzelknoten Bezeichnet die Gesamtheit aller Tracelinks zwischen einer festzulegenden Anzahl von Artefakten. Ist eine Teilmenge des Traceability-Modells. Space-filling Methode, bei der rechteckige Formen entsprechend ihrer hierarchischen Relation ineinander geschachtelt werden [LANDESBERGER ET AL. 2010] Element, welches der zu bestimmenden Teilmenge korrekterweise nicht zugewiesen wurde. Element, welches der zu bestimmenden Teilmenge korrekterweise zugewiesen wurde. Graph, deren Kanten keine Richtung zugewiesen haben Methoden, bei denen beliebige, lokale Regionen des Graphen verzerrt werden können, um in einem ausgewählten Bereich des Graphen eine große Anzahl an Detailinformationen darzustellen. [MUNZNER 1997, S. 3; KEIM UND SCHNEIDEWIND 2005, S. 1769] Ein Baum, in dem ein Knoten als Wurzelknoten ausgezeichnet werden kann. Ein Knoten der keinen übergeordneten, sondern nur untergeordnete Knoten hat. Abhängigkeitsmodell s. hierarchische Transitivität s. Tracelink Fokus + Kontext- Sichten root tree root node 286

316 ANHANG 287

317 Anhang Anhang A1: Verknüpfte Beispielartefakte Fahrrad, Klimaanlage und Pedelec Anhang I: Verknüpftes Beispielartefakt des Fahrrads im Visualisierungswerkzeug Ariadne s Eye 288

318 Anhang Anhang II: Verknüpftes Beispielartefakt der Klimaanlage im Visualisierungswerkzeug Ariadne s Eye 289

319 Anhang Anhang III: Verknüpftes Beispielartefakt des Pedelecs im Visualisierungswerkzeug Ariadne s Eye 290

320 Anhang Anhang A2: Material zur Studie Lesbarkeit der Anordnung Studie zur Visualisierung von Modellabhängigkeiten Im Rahmen der Entwicklung von Produkten werden viele unterschiedliche Modelle erstellt. Die bekanntesten Modelle beschreiben die Anforderungen, die ein Produkt erfüllen sollte, die Funktionen, die zur Erfüllung der Anforderungen realisiert werden sollen, und die Produktstruktur, die die geometrischen Baugruppen und teile beschreibt. Die genannten Modelle sind jeweils hierarchisch aufgebaut, was in der Regel auch in der Nummerierung der Elemente ausgedrückt wird: eine Funktion erster Ebene trägt z. B. die Nummer F1 (allgemein Fx) und eine Funktion zweiter Ebene die Nummer F1.3 (allgemein Fx.x). Anforderungen Produkt Domänenspezifischer Entwurf Abbildung 1 - Entwicklung unterschiedlicher Modelle entlang des Entwicklungsprozesses Zwischen den Modellen bestehen viele inhaltliche Zusammenhänge. So macht beispielsweise die Änderung einer bestimmten Funktion auch die Änderung der Elemente der Produktstruktur erforderlich, die diese Funktion realisieren. Zwischen den Modellen besteht also eine inhaltliche Abhängigkeit. Eine solche Abhängigkeit wird informationstechnisch durch eine Verknüpfung repräsentiert. Verbindungen, die eine Hierarchie ausdrücken wie die Verbindung zwischen Eltern- und Kinderelement (vgl. Abbildung 2: A1 A1.1), stellen keine Verknüpfung dar. Abbildung 2 - Abhängigkeiten zwischen Modellelementen: direkte (A1.1 - F1.1) und indirekte (A1.2 - P1.1) Falls Sie an dieser Stelle offene Fragen haben, zögern sie bitte nicht, diese jetzt zu stellen. 291

321 Anhang Aufgabe 1 Bitte nutzen Sie hierzu die Darstellungsform 1! Bitte suchen Sie die Anforderung Geräuschfreier Dauerbetrieb und markieren Sie diese! (Anforderung funktionale Anforderung mechanische Anforderung Geräuschfreier Dauerbetrieb) Welche Funktionen dritter Ebene F 1.x.x sind mit der Anforderung Geräuschfreier Dauerbetrieb direkt verknüpft? Bitte markieren und notieren Sie diese: F 1. F 1. F 1. F 1. F 1. Die Eltern dieser Funktionen sind Funktionen zweiter Ebene F 1.x. Mit welchen Produktstrukturelementen sind diese Funktionen zweiter Ebene F 1.x direkt verknüpft? Bitte markieren und notieren Sie diese: P P P P Zeit: Fehler: 292

322 Anhang Aufgabe 2 Bitte nutzen Sie hierzu die Darstellungsform 2! Bitte suchen Sie die Anforderung Gesetzliche Anforderung und markieren Sie diese! (Anforderung nicht-funktionale Anforderung technische Randbedingung Gesetzliche Anforderung) Welche Produktstrukturelemente sind mit dieser Anforderung direkt verknüpft? Bitte markieren und notieren Sie diese: P P Welche Funktionen sind mit dieser Anforderung direkt verknüpft? Bitte markieren und notieren Sie diese: F 1. F 1. F 1. F 1. F 1. F 1. Welche Produktstrukturelemente sind mit diesen Funktionen (und deren Eltern!) direkt verknüpft? Bitte markieren und notieren Sie diese: P 1. P 1. P 1. P 1. P 1. P 1. P 1. P 1. Zeit: Fehler: 293

323 Anhang Aufgabe 3 Bitte nutzen Sie hierzu die Darstellungsform 3! Bitte suchen und markieren Sie die Funktion Luft kühlen sowie alle Kinder dieser Funktion! (Funktionen Luft kühlen) Wieviele direkte Verknüpfungen zu anderen Modellen hat die Funktion Luft kühlen a) zur Produktstruktur: = b) zu den Anforderungen: =? Wieviele direkte Verknüpfungen haben alle Kinderelemente der Funktion Luft kühlen zusammenaddiert a) zur Produktstruktur: = b) zu den Anforderungen: =? Zeit: Fehler: 294

324 Anhang Aufgabe 4 Bitte geben Sie an, welche Darstellungsform Sie am komfortabelsten hinsichtlich ihrer Benutzbarkeit empfanden. Darstellungsform -Nummer:. Zum Abschluss bitten wir noch um drei personenbezogene Angaben: Geschlecht (m/w): Alter: Beruf / Studiengang:

325 Anhang Anhang IV: Anordnungskonzept im vertikalen Tree Layout (auf DIN A4 skaliert) 296

326 Anhang Anhang V: Anordnungskonzept im Balloon-Tree Layout (auf DIN A4 skaliert) 297

327 Anhang Anhang VI: Anordnungskonzept Ariadne s Eye (auf DIN A4 skaliert) 298

328 Anhang Lösungszeit [hh:mm:ss] Fehleranzahl Lösungszeit [hh:mm:ss] Fehler- Anordnungskonzept AK 1 AK 2 AK 3 Anordnungskonzept AK 1 AK 2 AK 3 anzahl Aufgabe 1 00:04: Aufgabe 1-00:06:45-0 Versuchsperson 1 Aufgabe 2-00:07:20-0 Versuchsperson 11 Aufgabe :10:23 0 Versuchsperson 2 Versuchsperson 3 Versuchsperson 4 Versuchsperson 5 Versuchsperson 6 Versuchsperson 7 Versuchsperson 8 Versuchsperson 9 Versuchsperson 10 Aufgabe :02:36 0 Aufgabe 3 00:05: Aufgabe 1-00:05:45-1 Aufgabe :06:00 2 Aufgabe :07:11 0 Versuchsperson 12 Aufgabe 2 00:10: Aufgabe 3 00:08: Aufgabe 3-00:05:00-4 Aufgabe :04:10 0 Aufgabe 1 00:07: Aufgabe Versuchsperson 13 Aufgabe 2-00:06:20-2 Aufgabe 3-00:03:35-6 Aufgabe :03:47 0 Aufgabe 1 00:07: Aufgabe 1-00:03:20-1 Aufgabe Versuchsperson 14 Aufgabe :05:08 0 Aufgabe :01:38 1 Aufgabe 3 00:03: Aufgabe 1-00:08:15-2 Aufgabe :11:30 0 Aufgabe :08:00 1 Versuchsperson 15 Aufgabe 2 00:13: Aufgabe 3 00:04: Aufgabe 3-00:06:50-7 Aufgabe :03:25 0 Aufgabe 1 00:05: Aufgabe 2 00:06: Versuchsperson 16 Aufgabe 2-00:05:05-3 Aufgabe Aufgabe :03:18 6 Aufgabe 1 00:05: Aufgabe 1-00:04:45-2 Aufgabe 2-00:05:40-3 Versuchsperson 17 Aufgabe :03:53 6 Aufgabe :02:19 2 Aufgabe 3 00:02: Aufgabe 1-00:06:40-0 Aufgabe :04:55 0 Aufgabe :10:52 0 Versuchsperson 18 Aufgabe 2 00:04: Aufgabe 3 00:06: Aufgabe 3-00:03:26-5 Aufgabe :08:15 0 Aufgabe 1 00:06: Aufgabe 2 00:09: Versuchsperson 19 Aufgabe 2-00:06:13-1 Aufgabe 3-00:08:00-3 Aufgabe :02:44 13 Aufgabe 1 00:04: Aufgabe 1-00:03:33-4 Aufgabe 2-00:05:05-0 Versuchsperson 20 Aufgabe :04:38 0 Aufgabe :03:05 13 Aufgabe 3 00:03: Aufgabe :04:12 0 Versuchsperson 21 Aufgabe 2 00:06: Aufgabe 3-00:02:58-7 Anhang VII: Einzelwerte der Versuchpersonen für Lösungszeit und Fehleranzahl 299

329 Anhang Anhang A3: Screenshots des Prototyps Ariadne s Eye Anhang VIII: Startansicht der KFZ-Klimaanlage in Ariadne s Eye 300

330 Anhang Anhang IX: Visuelle Hervorhebung der Suchergebnisse 301

331 Anhang Anhang X: Automatisches Hervorheben der verknüpften Funktionen 302

332 Anhang Anhang XI: Multiselektion der beiden übergeordneten Funktionen zweiter Hierarchieebene 303

333 Anhang Anhang A4: Material zur Studie Wirksamkeit des Impact-Analyse- Algorithmus 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 Anforderungen (was soll das Produkt leisten), die Funktionen (wie sollen die Anforderungen realisiert 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). Anforderungen Produkt Domänenspezifischer Entwurf 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 Klimaanlage können hierbei noch beliebig viele weitere Detaillierungen (Kindelemente), wie beispielsweise heizen, kühlen oder Luftfilter enthalten. 304

334 Anhang Die inhaltlichen Zusammenhänge zwischen den Elementen werden durch sogenannte Tracelinks gespeichert, um u.a. bei einer Änderung während der Produktentwicklung 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ängigkeitsmodell. Zu dieser Studie Abbildung 2 - Abhängigkeiten zwischen Modellelementen In dieser Studie sollen Sie das Anlegen, Überprüfen und Nutzen des Abhängigkeitsmodells durchführen. Für das relativ einfache und alltägliche Produktbeispiel eines Fahrrads, sollen Sie zunä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ängigkeitsmodell. In verschiedenen Szenarios sollen Sie die Auswirkungen von Änderungen 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 beiden 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. 305

335 Anhang Aufgabe 1 In dieser Aufgabe erlernen Sie den Umgang mit dem Softwaretool EcoTracer (Abbildung 3), sowie dem entsprechenden Viewer (Abbildung 4). Mit dem EcoTracer können Sie zwischen den Elementen zweier Teilmodelle (z.b. Anforderungen und Funktionen) Verknüpfungen anlegen. Das Programm schlägt Ihnen Schritt für Schritt Elementepaare für eine Verknüpfung vor. Sie haben in jedem Schritt die Wahl, die vorgeschlagene 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 bearbeiten (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ängigkeit 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ängigkeit 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 Elementpaar überspringen. Abbildung 3: Grafische Oberfläche des EcoTracers 306

336 Anhang Sobald Sie sich mit der Bedienung des EcoTracers vertraut gemacht haben, bekommen Sie Gelegenheit, die Funktionalitäten des Viewers (Abbildung 4) kennenzulernen. 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 dargestellt. Verknüpfungen werden nur auf der jeweils tiefstmöglichen Ebene dargestellt. Die Verknüpfungslinien befinden sich also hauptsächlich im freien Raum zwischen 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. 307

337 Anhang 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 Modellkombinationen 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ängigkeit besteht, klicken Sie auf bestätigen. Sind Sie sich sicher, dass zwischen den markierten Elementen keine Abhängigkeit 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ückzunehmen. Überlegen Sie sich ihre Interaktionen also bitte sorgfältig. Sobald Sie die Aufgabe abgeschlossen haben, geben Sie bitte Bescheid. 308

338 Anhang 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 unnö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 betroffenen Bauteile und notieren Sie die relevanten. Es genügt die Nummerierung des betroffenen Elementes zu notieren (z.b: A1.2.3). 309

339 Anhang (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 Fahrradherstellung drastisch reduziert werden. Es muss jedoch zunächst geprüft werden, ob die Funktionen und Anforderungen auch mit den neuen Bauteilen weiterhin erfüllt werden können. Hierfür identifizieren und notieren Sie bitte alle von den Bauteiländerungen 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. 310

340 Anhang 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 Elemente direkt betroffen. Ändert sich bspw. die Anforderung über das zulässige Maximalgewicht eines Fahrrads, muss häufig das Material des Rahmens angepasst werden bei der nun folgende Analyse müsste also das Element Rahmen der Produktstruktur 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üpfungen. Diesmal arbeiten Sie mit einer einfachen Listendarstellung der Anforderungen, Funktionen und Produktstruktur (enthält die Bauteile) des Fahrrads. 311

341 Anhang 312

342 Anhang 313

343 Anhang 314

344 Anhang Anhang XII: Explosionsdarstellung des Fahrrads zum erleichterten Produktverständis für die Studienteilnehmer 315

345 Anhang Anhang A5: Material zur Studie Vergleich der Anwendungseffizienz dreier Visualisierungskonzepte Studie zum Thema Auswirkungsanalyse von Änderungen in verknüpften Partialmodellen mittels verschiedener Datenvisualisierungen Vielen Dank für Ihre Teilnahme an unserer Studie zur Untersuchung verschiedener Datenvisualisierungen für die Auswirkungsanalyse zwischen verknüpften Partialmodellen! Der folgende Versuchsdurchlauf gliedert sich folgendermaßen: 1) Einführung in die Thematik und die verwendeten Applikationen 2) Drei Teilaufgaben an jeweils einer der drei verschiedenen Visualisierungsapplikationen: 1. In jeder Aufgabe wird eine sog. Impact Analyse (Auswirkungsanalyse) an einem praxisnahen Produktmodell durchgeführt. 2. Im Anschluss an jede der drei Teilaufgaben bitten wir Sie, zwei kurze Fragebögen auszufüllen. Für Zwischenfragen steht Ihnen der Versuchsleiter jederzeit gerne zur Verfügung! Bitte ausfüllen: Alter Geschlecht Abschluss bzw. Fachgebiet (wird vom Versuchsleiter ausgefüllt) Proband-Nr.: Datum: Bemerkung: 316

346 Anhang Einführung in die Thematik Im Folgenden möchten wir Ihnen einen kurzen inhaltlichen Einblick in das Themengebiet geben, aus dem die zu lösenden Aufgaben entstammen. Partialmodelle und Tracelinks Im Entwicklungsprozess eines mechatronischen Produktes entstehen verschiedene Partialmodelle, die unterschiedliche Sichtweisen auf ein System strukturiert abbilden. Diese orientieren sich in der Regel am unten abgebildeten sog. Vorgehensmodell. Am Anfang dieses Prozesses stehen zunächst (Kunden-)Anforderungen an ein zu entwickelndes Produkt. In der sich anschließenden Entwurfsphase entstehen Funktions-Modelle, um die funktionelle Realisierung der Anforderungen zu beschreiben, sowie Modelle, die die Produktstruktur im Hinblick auf Baugruppen und Bauteile abbilden. Diese Partialmodelle sind in der Regel hierarchisch strukturiert, d.h. tiefere Ebenen verfeinern höher gelegene Elemente inhaltlich bzw. höhere Ebenen gruppieren/abstrahieren tiefer gelegene Elemente. Anforderungen Produkt Domänenspezifischer Entwurf Im Produktlebenszyklus eines mechatronischen Systems können Änderungen auftreten, die zunächst Auswirkungen auf ein spezielles Partialmodell haben. So kann sich etwa eine gesetzliche Anforderung ändern, ein Bauteil des Produkts kann gegen ein anderes ausgetauscht werden oder Funktionen z.b. in der Softwarearchitektur ändern sich oder entfallen. Derartige Änderungen haben eine direkte und indirekte Auswirkung (Impact) auf Elemente anderer Partialmodelle. Zur effizienten Nachverfolgbarkeit dieser Auswirkungen werden daher Tracelinks modelliert, die Elemente modellübergreifend miteinander in eine Abhängigkeitsbeziehung setzen. Diese Verknüpfungen ermöglichen dann die Identifizierung aller betroffenen Elementen bis zu einer beliebigen Tiefe, um Änderungen von den Anforderungen bis zur Produktstruktur nachverfolgen und auswerten zu können. 317

347 Anhang Produktmodell für die Studie: E-Bike ( Pedelec ) Als praxisnahes Beispiel für die Lösung der drei Aufgaben wird in dieser Studie ein mechatronisches Produktmodell verwendet, welches die Anforderungen, Funktionen und Produktstrukturen eines Pedelecs modelliert. Diese Art der Elektrofahrräder zeichnen sich dadurch aus, dass sie gesetzlich wie ein normales Fahrrad behandelt werden. Dazu verfügen Pedelecs über eine spezielle Tretunterstützung, die eine Beschleunigung mittels Motor bis maximal 25 km/h. Bei höheren Geschwindigkeiten muss die Motorunterstützung automatisch abgeschaltet werden. Von einem normalen Fahrrad unterscheiden sich Pedelecs daher durch das Vorhandensein eines Motors, eines Akkumulators, einer Controller- Einheit sowie der nötigen Sensorik (Geschwindigkeit, Pedalkraft). Pedelecs können, über die Tretunterstützung hinaus, über eine Anfahrhilfe oder eine Nutzbremsung (Laden des Akkumulators durch Generator-Funktionalität des Motors) verfügen. Außerdem verfügen sie über die üblichen Komponenten eines normalen Fahrrades wie etwa eine Gangschaltung. Im Beispielmodell dieser Studie finden Sie die Beschreibung der Anforderungen, der Funktionsstruktur und der Produktstruktur des Pedelecs (Gangschaltung, Antrieb, Bremsen, Lenken, Tretunterstützung, Sicherheit usw.). Alle Elemente der drei Partialmodelle sind bereits durch Tracelinks miteinander verknüpft. Sämtliche Elemente verfügen über eindeutige Bezeichner, deren erstes Zeichen ein Buchstabe ist und die Zugehörigkeit zu einem Partialmodell wiedergibt. Für ein Anforderungselement vierter Ebene könnte ein Bezeichner etwa A sein, für eine Funktion dritter Ebene F1.2.4 usw. Die Nummern geben weiterhin die Zugehörigkeit zu übergeordneten Elementen an, d.h. Elemente wie etwa F1.2.1, F1.2.2, F1.2.3 wären direkte Unterelemente von F1.2. Eine Legende zu den einzelnen Produktstrukturelementen des Pedelecs liegt am Versuchsplatz aus. 318

348 Anhang Impact Analyse: Vorgehen In allen drei Teilaufgaben muss eine Impact Analyse durchgeführt werden, die von einem Startelement ausgehend anhand eines 5-schrittigen Algorithmus alle betroffenen Elemente identifiziert. Das genaue Vorgehen soll im Folgenden an einem Beispiel mit drei untereinander verknüpften Modellen (Anforderungen, Funktionen, Produktstruktur) veranschaulicht werden. Teilschritt & Erklärung Schaubild 1. Identifizieren des Startelements Das sich ändernde Ausgangselement (*) ist A1.2.1, ein Element dritter Ebene im Modell Anforderungen (gelb). 2. Identifizieren der ersten Startmenge Im Partialmodell des Startelements ( Anforderungen ) müssen nun alle über- und untergeordneten Elemente von A1.2.1 (orange) ermittelt werden, in diesem Fall A1, A1.2, A (gelb). Wichtig: Es müssen alle direkten Eltern und Kinder des Startelements gefunden werden, d.h. vom Wurzelelement bis zur untersten Ebene. Dabei sollen nicht benachbarte Elemente ermittelt werden, wie etwa A Identifizieren der ersten Auswirkungsmenge Die Startmenge aus dem vorherigen Schritt ist nun orange gekennzeichnet. Nun müssen alle Verbindungen zu den anderen beiden Partialmodellen ( Funktionen, Produktstruktur ) verfolgt werden, die von der Startmenge ausgehen (rote Linien). Im Beispiel ergeben sich die direkt verknüpften Elemente F1.2.1 und F1.2.2 aus dem Modell Funktionen sowie P1.3.1 aus dem Modell Produktstruktur (jeweils gelb). 4. Identifizieren der zweiten Startmenge Im vorherigen Schritt wurden verknüpfte Elemente in den Modellen Funktionen (F1.2.1, F1.2.2) und Produktstruktur (P1.3.1) ermittelt (orange). In diesen beiden Modellen müssen nun für jedes der gefundenen Elemente wie am Anfang alle Eltern und Kinder gefunden werden (gelb). In diesem Fall sind das die Elemente F1, F1.2, F sowie P1, P1.3 und P Identifizieren der zweiten Auswirkungsmenge Ähnlich wie in Schritt 3 müssen nun von dieser zweiten Startmenge ausgehend alle durch Tracelinks verknüpften Elemente gefunden werden (rote Linien). In diesem Fall sind die verknüpften Elemente (gelb) A1.2, A1.2.1, A und A1.2.2 (aus dem Modell Anforderungen ), F1.3 (aus dem Modell Funktionen) und P1.3.2 ( Produktstruktur ). Die Elemente P1.3 und P sind ebenfalls über Tracelinks mit Elementen aus Funktionen verbunden, jedoch selbst Teil der Startmenge. Sollte es Unklarheiten zu diesem Vorgehen geben, scheuen Sie sich bitte nicht vor Nachfragen! 319

349 Anhang Visualisierungs-Applikationen dieser Studie Jede Aufgabe muss einer anderen Visualisierung gelöst werden. Das Produktmodell des Pedelecs wird dabei auf drei verschiedene Weisen visualisiert und in einer jeweils eigenen Anwendung zur Verfügung gestellt. Visualisierung: Text/Liste In dieser Variante werden die Elemente der Produktmodelle innerhalb eines Excel-Dokuments tabellarisch in zwei Spalten untereinander gelistet. In der linken Spalte befinden sich die hierarchisch sortierten Elemente des jeweiligen Partialmodells mit Namen und Bezeichner. In der rechten Spalte sind die durch Tracelinks verknüpften Elemente aus anderen Partialmodellen sichtbar. Wird ein Element in der linken Spalte selektiert, dann werden dieses sowie alle verknüpften Elemente im Dokument gelb hinterlegt. Alle Elemente der Modelle sind farbig hinterlegt. Anforderungen sind blau, Funktionen rot und Produktstrukturen grün. Interaktionsübersicht: Selektion Element Mehrfachselektion Elemente Zoomen Verschieben Ausblenden von Partialmodellen Klick (linke Maustaste) Strg+Klick (linke Maustaste) Strg+Scrollrad Horizontale/vertikale Scrollbalken Checkbox 320

350 Anhang Visualisierung: Matrixdarstellung Die Matrixdarstellung auf Basis eines Excel-Dokuments ist eine in der mechatronischen Produktentwicklung häufig verwendete Domain Structure Matrix (DSM) bzw. Multi Domain Matrix (MDM). Die Elemente der drei Partialmodelle sind hier jeweils in der ersten Spalte und der oberen Reihe und hierarchisch sortiert angeordnet. Tracelinks zwischen Elementen werden durch ein X in den jeweiligen Zellen angezeigt, die Schnittpunkte von zwei Elementen aus zwei verschiedenen Partialmodellen sind. Die Diagonale ist leer, da keine Tracelinks innerhalb der Partialmodelle modelliert sind. Wird ein Element selektiert (gelb), werden alle durch Tracelinks (X) verknüpften Elemente anderer Partialmodelle ebenfalls gelb hinterlegt. Interaktionsübersicht: Selektion Element Mehrfachselektion Elemente Zoomen Verschieben Ausblenden von Partialmodellen Klick (linke Maustaste) Strg+Klick (linke Maustaste) Strg+Scrollrad Horizontale/vertikale Scrollbalken Checkbox 321

351 Anhang Visualisierung: Graphendarstellung In dieser Darstellung werden die Partialmodelle im Programm Ariadne s Eye in Form von Graphen abgebildet, bestehend aus Knoten und Kanten. Die hierarchisch aufgebauten Modelle werden jeweils als Baum visualisiert und gegenüber liegend angeordnet. Die Zugehörigkeit eines Elementes zu einem Modell wird außerdem analog zu den anderen Anwendungen durch die Farbe des Knotens gekennzeichnet. Die Beschriftungen der Knoten sind die Bezeichner sowie der Name des jeweiligen Elements. Tracelinks sind hier jene Kanten, die von einem Partialmodell zu einem anderen durch die Mitte der Darstellung gezeichnet sind. Wichtig: Kanten innerhalb des Partialmodells sind keine Tracelinks! Bei Selektion eines Knotens wird dieser gelb sowie die Beschriftung blau gefärbt. Alle Tracelinks, die mit diesem Knoten verbunden sind, werden blau gefärbt und die verbundenen Elemente anderer Modelle gelb. Durch Überfahren eines Knoten mit der Maus wird der vollständige Name des Elements angezeigt. Partialmodelle können durch die Checkboxen am unteren Rand des Bildschirms ausgeblendet werden. Interaktionsübersicht: Selektion Element Mehrfachselektion Elemente Zoomen Verschieben Ausblenden von Partialmodellen Klick (linke Maustaste) Strg+Klick (linke Maustaste) Strg+Scrollrad Klick (linke Maustaste)+Ziehen Checkbox 322

352 Anhang Lösen der Aufgaben - Hinweise Im Folgenden werden Sie eine kleine Einführungsaufgabe sowie drei Aufgaben anhand des anfangs beschriebenen Algorithmus lösen. Noch einige Hinweise zum Ablauf: Für jede Aufgabe steht ein Lösungsblatt zur Verfügung, in dem alle gefundenen Elemente eingetragen werden. Über jeder Aufgabe steht das Programm, mit dem die Aufgabe zu lösen ist (Text, Matrix oder Graph). Diese finden Sie im Ordner 02 Versuch : o Versuch-Text.xls o Versuch-Matrix.xls o Versuch-Graph.exe In jedem Aufgabenblatt ist das Startelement in der ersten Zeile eingetragen, von dem ausgehend der Algorithmus durchgeführt wird. Bitte geben Sie dem Versuchsleiter ein Zeichen nach Absolvierung jeder der 5 Teilschritte des Algorithmus, damit dieser die jeweilige Zeit notieren kann, die benötigt wurde. Bitte lassen Sie sich vom Umstand der Zeitmessung nicht unter Druck setzen, es kommt nicht auf die persönliche Performance an! Am Ende einer Aufgabe benötigt der Versuchsleiter noch die Daten eines Logging-Programms, welches die Anzahl der Mausklicks, die Mausstrecke, die Mausradbewegung und die Tastaturanschläge aufzeichnet. Im Anschluss an jede Aufgabe möchten wir Sie jeweils bitten, zwei kurze Fragebögen auszufüllen. Bitte machen Sie sich zunächst mit der Einführungsaufgabe auf der kommenden Seite vertraut, mit der Sie alle drei Applikationen im Hinblick - auf die gegebenen Interaktionsmöglichkeiten austesten können sowie - die Anwendung des Algorithmus üben können. Die Einführungsapplikationen befinden sich im Ordner 01 Einführung : - Einführung-Text.xls - Einführung-Matrix.xls - Einführung-Graph.exe Bei Unklarheiten fragen Sie bitte jederzeit den Versuchsleiter! 323

353 Anhang 324

354 Anhang 325

355 Anhang 326

356 Anhang Fragebogen 1 von 2 Beanspruchungshöhe der Visualisierung Geben Sie jetzt bitte an, wie hoch die Beanspruchung bei der Benutzung der Visualisierung war. Markieren sie dazu auf den folgenden Skalen bitte, in welchem Maße Sie sich in den sechs genannten Dimensionen von der soeben bearbeiteten Aufgabe beansprucht oder gefordert gesehen haben. Bitte lesen Sie die Skalenbeschriftung sorgfältig! Wenn Sie Fragen zu einer Skala haben, fragen Sie bitte. Es ist sehr wichtig, dass Ihnen die Skalen klar sind. Beispiel: gering hoch Geistige Anforderungen Wieviel geistige Anstrengung war bei der Informationsaufnahme und bei der Informationsverarbeitung erforderlich (z.b. Denken, Entscheiden, Rechnen, Erinnern, Hinsehen, Suchen )? War die Aufgabe leicht oder anspruchsvoll, einfach oder komplex, erfordert sie hohe Genauigkeit oder ist sie fehlertolerant? Körperliche Anforderungen gering hoch Wieviel körperliche Aktivität war erforderlich (z.b. ziehen, drücken, drehen, steuern, aktivieren )? War die Aufgabe leicht oder schwer, einfach oder anstrengend, erholsam oder mühselig? gering hoch Zeitliche Anforderungen Wie viel Zeitdruck empfanden Sie hinsichtlich der Häufigkeit oder dem Takt mit dem Aufgaben oder Aufgabenelemente auftraten? War die Abfolge langsam und geruhsam oder schnell und hektisch? gering hoch Ausführung der Aufgaben Wie erfolgreich haben Sie ihrer Meinung nach die vom Versuchsleiter (oder Ihnen selbst) gesetzten Ziele erreicht? Wie zufrieden waren Sie mit Ihrer Leistung bei der Verfolgung dieser Ziele? gut schlecht Anstrengung Wie hart mußten Sie arbeiten, um Ihren Grad an Aufgabenerfüllung zu erreichen? gering hoch Frustration Wie unsicher, entmutigt, irritiert, gestreßt und verärgert (versus sicher, bestätigt, zufrieden, entspannt und zufrieden mit sich selbst) fühlten Sie sich während der Aufgabe? gering hoch Augenermüdung Wie stark ist die Ermüdung Ihrer Augen im Moment? gering hoch 327

357 Anhang Fragebogen 2 von 2 Bewertung der Visualisierung Nachfolgend finden Sie Wortpaare, mit deren Hilfe Sie die Beurteilung der Anwendung vornehmen können. Sie stellen jeweils extreme Gegensätze dar, zwischen denen eine Abstufung möglich ist. Denken Sie nicht lange über die Wortpaare nach, sondern geben Sie bitte die Einschätzung ab, die Ihnen spontan in den Sinn kommt. Vielleicht passen einige Wortpaare nicht so gut auf das Produkt, kreuzen Sie aber trotzdem bitte immer eine Antwort an. Denken Sie daran, dass es keine "richtigen" oder "falschen" Antworten gibt - nur Ihre persönliche Meinung zählt! menschlich O O O O O O O technisch isolierend O O O O O O O verbindend angenehm O O O O O O O unangenehm originell O O O O O O O konventionell einfach O O O O O O O kompliziert fachmännisch O O O O O O O laienhaft hässlich O O O O O O O schön praktisch O O O O O O O unpraktisch sympathisch O O O O O O O unsympathisch umständlich O O O O O O O direkt stilvoll O O O O O O O stillos voraussagbar O O O O O O O unberechenbar minderwertig O O O O O O O wertvoll ausgrenzend O O O O O O O einbeziehend nicht vorzeigbar O O O O O O O vorzeigbar zurückweisend O O O O O O O einladend phantasielos O O O O O O O kreativ gut O O O O O O O schlecht verwirrend O O O O O O O übersichtlich abstoßend O O O O O O O anziehend mutig O O O O O O O vorsichtig innovativ O O O O O O O konservativ lahm O O O O O O O fesselnd harmlos O O O O O O O herausfordernd motivierend O O O O O O O entmutigend neuartig O O O O O O O herkömmlich widerspenstig O O O O O O O handhabbar 328

358 Anhang Feedback Wir würden uns freuen, wenn Sie uns Feedback zur Studie bzw. zu den verwendeten Visualisierungen geben würden! Studie: Text/Listen-Anwendung: Matrix-Anwendung: Graph-Anwendung: Vielen Dank für Ihre Teilnahme! 329

359 Anhang Anhang XIII: Pedelec-Artefakte Anforderungen, Funktionen, Produktstruktur 330

IPA-IAO Forschung und Praxis

IPA-IAO Forschung und Praxis IPA-IAO Forschung und Praxis Berichte aus dem Fraunhofer-Institut für Produktionstechnik und Automatisierung (IPA), Stuttgart, Fraunhofer-Institut für Arbeitswirtschaft und Organisation (IAO), Stuttgart,

Mehr

Wissensmanagement 2.0

Wissensmanagement 2.0 Dieter Spath (Hrsg.), Jochen Günther Wissensmanagement 2.0 FRAUNHOFER-INSTITUT FÜR Arbeitswirtschaft und organisation IAO Trendstudie: Dieter Spath (Hrsg.), Jochen Günther Wissensmanagement 2.0 Erfolgsfaktoren

Mehr

Diplomarbeit. Entwurf eines generischen Prozessleitstandes für Change Request Systeme

Diplomarbeit. Entwurf eines generischen Prozessleitstandes für Change Request Systeme Fakultät für Mathematik, Informatik und Naturwissenschaften Forschungsgruppe Softwarekonstruktion Diplomarbeit Entwurf eines generischen Prozessleitstandes für Change Request Systeme Development of a Generic

Mehr

Requirement Management Systeme

Requirement Management Systeme Özgür Hazar Requirement Management Systeme Suche und Bewertung geeigneter Tools in der Software-Entwicklung Diplomica Verlag Özgür Hazar Requirement Management Systeme: Suche und Bewertung geeigneter Tools

Mehr

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit IT-basierte Erstellung von Nachhaltigkeitsberichten Diplomarbeit zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen Fakultät der Leibniz Universität Hannover vorgelegt von

Mehr

Yvonne Höfer-Diehl. Hochs chulcontrolling. %ur Sicherung der Lehreffektivität

Yvonne Höfer-Diehl. Hochs chulcontrolling. %ur Sicherung der Lehreffektivität Yvonne Höfer-Diehl Hochs chulcontrolling %ur Sicherung der Lehreffektivität Verlag Dr. Kovac Hamburg 2014 XV Inhaltsverzeichnis Geleitwort Vorwort Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis

Mehr

Eliminating waste in software projects: Effective knowledge management by using web based collaboration technology Diplom.de

Eliminating waste in software projects: Effective knowledge management by using web based collaboration technology Diplom.de Frederik Dahlke Eliminating waste in software projects: Effective knowledge management by using web based collaboration technology The enterprise 2.0 concept applied to lean software development Diplom.de

Mehr

Mobile Technologien in der Assekuranz: Wie sie effektiv genutzt und im Rahmen einer Mobile- Strategie umgesetzt werden können.

Mobile Technologien in der Assekuranz: Wie sie effektiv genutzt und im Rahmen einer Mobile- Strategie umgesetzt werden können. Studienabschlussarbeit / Bachelor Thesis Marcel Altendeitering Manuskript Mobile Technologien in der Assekuranz: Wie sie effektiv genutzt und im Rahmen einer Mobile- Strategie umgesetzt werden können.

Mehr

Jörn Plönnigs. Control Network Performance Engineering

Jörn Plönnigs. Control Network Performance Engineering Beiträge aus der Informationstechnik Jörn Plönnigs Control Network Performance Engineering Qualitätsorientierter Entwurf von CSMA-Netzwerken der Automation Dresden 2007 Bibliografische Information der

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

Mehr

REPARATUR-MANAGEMENT IN DER KFZ-VERSICHERUNG

REPARATUR-MANAGEMENT IN DER KFZ-VERSICHERUNG FRAUNHOFER-INSTITUT FÜR ARBEITSWIRTSCHAFT UND ORGANISATION IAO Monika Kochanowski, Gülten Altug, Falko Kötter, Thomas Renner REPARATUR-MANAGEMENT IN DER KFZ-VERSICHERUNG EINE NUTZENUNTERSUCHUNG ZUM REPARATUR-MANAGEMENT

Mehr

Bachelorarbeit. Brennpunkt Gemeinsame Agrarpolitik. Die GAP der EU im Spannungsfeld zwischen ökonomischer Ineffizienz und Interessen der Agrarlobby?

Bachelorarbeit. Brennpunkt Gemeinsame Agrarpolitik. Die GAP der EU im Spannungsfeld zwischen ökonomischer Ineffizienz und Interessen der Agrarlobby? Bachelorarbeit Ben Witthaus Brennpunkt Gemeinsame Agrarpolitik Die GAP der EU im Spannungsfeld zwischen ökonomischer Ineffizienz und Interessen der Agrarlobby? Bachelor + Master Publishing Ben Witthaus

Mehr

Assembly Technology. des Entwicklungsprozesses

Assembly Technology. des Entwicklungsprozesses FRAUNHOFER-institut für produktionstechnologie IPT projektgruppe entwurfstechnik mechatronik Requirements Engineering Assembly Technology Ovidemporion porum quiae nemporro cone venderferia coris dio officia

Mehr

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Agile Methoden als Diagnose-Tool für den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Über mich Berufliche Erfahrung 3 Jahre Projektabwicklung 2 Jahre

Mehr

Human Capital Management

Human Capital Management Human Capital Management Raimund Birri Human Capital Management Ein praxiserprobter Ansatz für ein strategisches Talent Management 2., überarbeitete Auflage Raimund Birri Zürich, Schweiz ISBN 978-3-8349-4574-7

Mehr

Onlinehandel, Multi-Channel-Retailing, Handelsmarketing, Bekleidungsbranche, Marktsegmentierung, Conjoint-Analyse

Onlinehandel, Multi-Channel-Retailing, Handelsmarketing, Bekleidungsbranche, Marktsegmentierung, Conjoint-Analyse Philipp Andrée: Marktsegmente im Onlinehandel der Bekleidungsbranche. Entwicklung eines Marketingkonzepts für den Onlinehandel stationärer Mehrmarkenhändler der Bekleidungsbranche in Deutschland zur Erschließung

Mehr

Group and Session Management for Collaborative Applications

Group and Session Management for Collaborative Applications Diss. ETH No. 12075 Group and Session Management for Collaborative Applications A dissertation submitted to the SWISS FEDERAL INSTITUTE OF TECHNOLOGY ZÜRICH for the degree of Doctor of Technical Seiences

Mehr

Springer Spektrum, Springer Vieweg und Springer Psychologie.

Springer Spektrum, Springer Vieweg und Springer Psychologie. essentials Essentials liefern aktuelles Wissen in konzentrierter Form. Die Essenz dessen, worauf es als State-of-the-Art in der gegenwärtigen Fachdiskussion oder in der Praxis ankommt. Essentials informieren

Mehr

Datenqualitätsmanagement im Customer Relationship Management

Datenqualitätsmanagement im Customer Relationship Management Wolfgang Leußer Datenqualitätsmanagement im Customer Relationship Management Verlag Dr. Kovac Hamburg 2011 Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Abkürzungsverzeichnis XVII XIX XXI

Mehr

Modellbasiertes Konfigurationsmanagement 1 / 28

Modellbasiertes Konfigurationsmanagement 1 / 28 Vortrag Modellbasiertes Konfigurationsmanagement Subconf 2009 Munich Thomas Obermüller elego Software Solutions GmbH - 2009 Modellbasiertes Konfigurationsmanagement 1 / 28 Welcome & Outline Willkommen

Mehr

Tagungsband - 6. PLM Future Tagung und zehnjähriges Lehrstuhljubiläum 22. Oktober 2014

Tagungsband - 6. PLM Future Tagung und zehnjähriges Lehrstuhljubiläum 22. Oktober 2014 Lehrstuhl für Virtuelle Produktentwicklung Prof. Dr.-Ing. Martin Eigner Tagungsband - 6. PLM Future Tagung und zehnjähriges Lehrstuhljubiläum 22. Oktober 2014 Product Lifecycle Management - Integration,

Mehr

Internetbasierte Gästebefragung

Internetbasierte Gästebefragung Fabienne Trattner Internetbasierte Gästebefragung Neue Chancen in der Hotellerie Nachhaltige Steigerung der Gästezufriedenheit mit Hilfe des World Wide Web Diplomica Verlag Fabienne Trattner Internetbasierte

Mehr

TomR.Koch. Lean Six Sigma. Die Automobilindustrie im Wandel. Diplomica Verlag

TomR.Koch. Lean Six Sigma. Die Automobilindustrie im Wandel. Diplomica Verlag TomR.Koch Lean Six Sigma Die Automobilindustrie im Wandel Diplomica Verlag Tom R. Koch Lean Six Sigma: Die Automobilindustrie im Wandel ISBN: 978-3-8428-3118-6 Herstellung: Diplomica Verlag GmbH, Hamburg,

Mehr

Property-Driven Product Development/Design

Property-Driven Product Development/Design Seminar Virtual Engineering Property-Driven Product Development/Design Christoph Semkat Gliederung 1. Grundlagen Rechnerunterstützung Prozess der Produktentwicklung 2. Konzept Property-Driven

Mehr

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Andreas Ditze MID GmbH Kressengartenstraße 10 90402 Nürnberg a.ditze@mid.de Abstract: Data Lineage

Mehr

Einfluss von Social Media auf die Suchmaschinenoptimierung mit spezieller Betrachtung von Google+

Einfluss von Social Media auf die Suchmaschinenoptimierung mit spezieller Betrachtung von Google+ Wirtschaft Lukas Peherstorfer Einfluss von Social Media auf die Suchmaschinenoptimierung mit spezieller Betrachtung von Google+ Bachelorarbeit Peherstorfer, Lukas: Einfluss von Social Media auf die Suchmaschinenoptimierung

Mehr

PRESS RELEASE. Kundenspezifische Lichtlösungen von MENTOR

PRESS RELEASE. Kundenspezifische Lichtlösungen von MENTOR Kundenspezifische Lichtlösungen von MENTOR Mit Licht Mehrwert schaffen. Immer mehr Designer, Entwicklungsingenieure und Produktverantwortliche erkennen das Potential innovativer Lichtkonzepte für ihre

Mehr

Enterprise Social Networking: Ein Framework und ein Fachkonzept für ein Industrieunternehmen

Enterprise Social Networking: Ein Framework und ein Fachkonzept für ein Industrieunternehmen Enterprise Social Networking: Ein Framework und ein Fachkonzept für ein Industrieunternehmen Bachelorarbeit zur Erlangung des akademischen Grades Bachelor auf Science (B.Sc.) im Studiengang Wirtschaftswissenschaft

Mehr

Julian Reichwald. Modell-getriebene Unterstützung der Workflow-Abbildung in Serviceorientierten

Julian Reichwald. Modell-getriebene Unterstützung der Workflow-Abbildung in Serviceorientierten Julian Reichwald Modell-getriebene Unterstützung der Workflow-Abbildung in Serviceorientierten Software-Umgebungen Bibliografische Informationen der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet

Mehr

Rolf F. Toffel Friedrich Wilhelm Toffel. Claim-Management

Rolf F. Toffel Friedrich Wilhelm Toffel. Claim-Management Rolf F. Toffel Friedrich Wilhelm Toffel Claim-Management Dipl.-Ing. Dr. rer. pol. habil. Rolf F. Toffel Universitätsprofessor der Baubetriebswirtschaftslehre an der Technischen Universität Braunschweig

Mehr

Erfolgreich als Medical Advisor und Medical Science Liaison Manager

Erfolgreich als Medical Advisor und Medical Science Liaison Manager Erfolgreich als Medical Advisor und Medical Science Liaison Manager Günter Umbach Erfolgreich als Medical Advisor und Medical Science Liaison Manager Wie Sie effektiv wissenschaftliche Daten kommunizieren

Mehr

Alina Schneider. Erfolg in Data-Warehouse-Projekten. Eine praxisnahe Analyse von Erfolgsfaktoren und -kriterien. Diplomica Verlag

Alina Schneider. Erfolg in Data-Warehouse-Projekten. Eine praxisnahe Analyse von Erfolgsfaktoren und -kriterien. Diplomica Verlag Alina Schneider Erfolg in Data-Warehouse-Projekten Eine praxisnahe Analyse von Erfolgsfaktoren und -kriterien Diplomica Verlag Alina Schneider Erfolg in Data-Warehouse-Projekten: Eine praxisnahe Analyse

Mehr

Usability Untersuchung eines Internetauftrittes nach DIN EN ISO 9241 Am Praxisbeispiel der Firma MAFI Transport-Systeme GmbH

Usability Untersuchung eines Internetauftrittes nach DIN EN ISO 9241 Am Praxisbeispiel der Firma MAFI Transport-Systeme GmbH Markus Hartmann Usability Untersuchung eines Internetauftrittes nach DIN EN ISO 9241 Am Praxisbeispiel der Firma MAFI Transport-Systeme GmbH Diplom.de Markus Hartmann Usability Untersuchung eines Internetauftrittes

Mehr

Abbildungsverzeichnis... IX. Tabellenverzeichnis... XV. Abkürzungsverzeichnis... XIX. 1 Einleitung... 1. 1.1 Problemstellung und Motivation...

Abbildungsverzeichnis... IX. Tabellenverzeichnis... XV. Abkürzungsverzeichnis... XIX. 1 Einleitung... 1. 1.1 Problemstellung und Motivation... III Abbildungsverzeichnis... IX Tabellenverzeichnis... XV Abkürzungsverzeichnis... XIX 1 Einleitung... 1 1.1 Problemstellung und Motivation... 1 1.2 Zielsetzung und Forschungsfragen... 3 1.3 Positionierung

Mehr

Alina Schneider. Erfolg in Data-Warehouse-Projekten. Eine praxisnahe Analyse von Erfolgsfaktoren und -kriterien. Diplomica Verlag

Alina Schneider. Erfolg in Data-Warehouse-Projekten. Eine praxisnahe Analyse von Erfolgsfaktoren und -kriterien. Diplomica Verlag Alina Schneider Erfolg in Data-Warehouse-Projekten Eine praxisnahe Analyse von Erfolgsfaktoren und -kriterien Diplomica Verlag Alina Schneider Erfolg in Data-Warehouse-Projekten: Eine praxisnahe Analyse

Mehr

Wiki-basierte Dokumentation von Software-Entwicklungsprozessen

Wiki-basierte Dokumentation von Software-Entwicklungsprozessen Wiki-basierte Dokumentation von Software-Entwicklungsprozessen Erfahrungen aus der industriellen Praxis Fraunhofer IESE Kaiserslautern Inhalt Wiki-basierte Dokumentation von Software-Entwicklungsprozessen

Mehr

Universität Passau. Betriebswirtschaftslehre mit Schwerpunkt Internationales Management Prof. Dr. Carola Jungwirth. Masterarbeit

Universität Passau. Betriebswirtschaftslehre mit Schwerpunkt Internationales Management Prof. Dr. Carola Jungwirth. Masterarbeit Universität Passau Betriebswirtschaftslehre mit Schwerpunkt Internationales Management Prof. Dr. Carola Jungwirth Masterarbeit "Identifikation von Erfolgsfaktoren für eine Facebook- Recruiting-Strategie"

Mehr

Jens Drawehn, Oliver Höß SOCIAL BPM. Business Process Management Tools 2014 FRAUNHOFER VERLAG

Jens Drawehn, Oliver Höß SOCIAL BPM. Business Process Management Tools 2014 FRAUNHOFER VERLAG Jens Drawehn, Oliver Höß SOCIAL BPM Business Process Management Tools 2014 FRAUNHOFER VERLAG Impressum Alle Rechte vorbehalten. Kontaktadresse: Fraunhofer-Institut für Arbeitswirtschaft und Organisation

Mehr

Planung und Messung der Datenqualität in Data-Warehouse-Systemen

Planung und Messung der Datenqualität in Data-Warehouse-Systemen Planung und Messung der Datenqualität in Data-Warehouse-Systemen DISSERTATION der Universität St. Gallen, Hochschule für Wirtschafts-, Rechts- und Sozialwissenschaften (HSG) zur Erlangung der Würde eines

Mehr

Erfahrungsbreicht... Von der Auswahl bis zur Verwendung von Contour im Grossunternehmen.

Erfahrungsbreicht... Von der Auswahl bis zur Verwendung von Contour im Grossunternehmen. Stefan Topp Honeywell International SARL 16. Februar 2012 Erfahrungsbreicht... Von der Auswahl bis zur Verwendung von Contour im Grossunternehmen. 1 Agenda Hintergruende Der Auswahlprozess Ausrollen von

Mehr

objectif Requirements Modeller

objectif Requirements Modeller objectif Requirements Modeller Das ist neu in Version 1.1 1 Inhalt objectif Requirements Modeller das Tool für Requirements Engineering in Software- und Systementwicklung Das ist neu in Version 1.1 Seite

Mehr

Modernes Talent-Management

Modernes Talent-Management Martina Kahl Modernes Talent-Management Wegweiser zum Aufbau eines Talent-Management-Systems Diplomica Verlag Martina Kahl Modernes Talent-Management: Wegweiser zum Aufbau eines Talent-Management- Systems

Mehr

CMMI for Embedded Systems Development

CMMI for Embedded Systems Development CMMI for Embedded Systems Development O.Univ.-Prof. Dipl.-Ing. Dr. Wolfgang Pree Software Engineering Gruppe Leiter des Fachbereichs Informatik cs.uni-salzburg.at Inhalt Projekt-Kontext CMMI FIT-IT-Projekt

Mehr

BWL im Bachelor-Studiengang

BWL im Bachelor-Studiengang BWL im Bachelor-Studiengang Reihenherausgeber: Hermann Jahnke, Universität Bielefeld Fred G. Becker, Universität Bielefeld Fred G. Becker Herausgeber Einführung in die Betriebswirtschaftslehre Mit 48 Abbildungen

Mehr

Integrierte modellgestützte Risikoanalyse komplexer Automatisierungssysteme

Integrierte modellgestützte Risikoanalyse komplexer Automatisierungssysteme Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner Integrierte modellgestützte Risikoanalyse komplexer Automatisierungssysteme Dipl.-Ing. Michael

Mehr

Diplomarbeit. Fachliche Integration von Metrik-Dashboards und Dashboard-Vorlagen für bestehende Software-Projekte

Diplomarbeit. Fachliche Integration von Metrik-Dashboards und Dashboard-Vorlagen für bestehende Software-Projekte Fakultät für Mathematik, Informatik und Naturwissenschaften Forschungsgruppe Softwarekonstruktion Diplomarbeit Fachliche Integration von Metrik-Dashboards und Dashboard-Vorlagen für bestehende Software-Projekte

Mehr

Handbuch Kundenmanagement

Handbuch Kundenmanagement Handbuch Kundenmanagement Armin Töpfer (Herausgeber) Handbuch Kundenmanagement Anforderungen, Prozesse, Zufriedenheit, Bindung und Wert von Kunden Dritte, vollständig überarbeitete und erweiterte Auflage

Mehr

Analyse kritischer Erfolgsfaktoren für Enterprise Social Networking Anwendungen. Bachelorarbeit

Analyse kritischer Erfolgsfaktoren für Enterprise Social Networking Anwendungen. Bachelorarbeit Analyse kritischer Erfolgsfaktoren für Enterprise Social Networking Anwendungen Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaften

Mehr

Controlling im Mittelstand

Controlling im Mittelstand Stefan Holland-Letz Controlling im Mittelstand Entwicklung eines Controllingkonzeptes für den Mittelstand, Diskussion der Umsetzung mit betriebswirtschaftlicher Software und Vergleich mit einer empirischen

Mehr

1. Einleitung. 1.1. Ausgangssituation

1. Einleitung. 1.1. Ausgangssituation 1. Einleitung In der vorliegenden Arbeit wird untersucht, welche Faktoren den erfolgreichen Ausgang eines Supply-Chain-Projektes zwischen zwei Projektpartnern beeinflussen. Dazu werden zum einen mögliche

Mehr

POCKET POWER. Change Management. 4. Auflage

POCKET POWER. Change Management. 4. Auflage POCKET POWER Change Management 4. Auflage Der Herausgeber Prof.Dr.-Ing. GerdF.Kamiske, ehemalsleiter der Qualitätssicherung im Volkswagenwerk Wolfsburg und Universitätsprofessor für Qualitätswissenschaft

Mehr

1.1 Basiswissen komprimiert... 4 1.2 Praxiswissen Testmanagement Übersicht... 8. 2 Testprozess und Testwerkzeuge 11

1.1 Basiswissen komprimiert... 4 1.2 Praxiswissen Testmanagement Übersicht... 8. 2 Testprozess und Testwerkzeuge 11 xi 1 Einleitung 1 1.1 Basiswissen komprimiert.......................... 4 1.2 Praxiswissen Testmanagement Übersicht.............. 8 2 Testprozess und Testwerkzeuge 11 2.1 Fundamentaler Testprozess.........................

Mehr

Marc Witte. Open Innovation. als Erfolgsfaktor für KMU. Theoretische Analyse und praktische Untersuchung. Diplomica Verlag

Marc Witte. Open Innovation. als Erfolgsfaktor für KMU. Theoretische Analyse und praktische Untersuchung. Diplomica Verlag Marc Witte Open Innovation als Erfolgsfaktor für KMU Theoretische Analyse und praktische Untersuchung Diplomica Verlag Marc Witte Open Innovation als Erfolgsfaktor für KMU: Theoretische Analyse und praktische

Mehr

Lifestyle & Trends als Erfolgsfaktoren des Event-Marketings

Lifestyle & Trends als Erfolgsfaktoren des Event-Marketings Jan Bast Lifestyle & Trends als Erfolgsfaktoren des Event-Marketings Bachelorarbeit BACHELOR + MASTER Publishing Bast, Jan: Lifestyle & Trends als Erfolgsfaktoren des Event-Marketings, Hamburg, Bachelor

Mehr

Produktqualität in agilen Entwicklungsvorgehen. BITKOM Software Summit Frankfurt, 23. September 2014 Dominik Rost, Hartmut Schmitt

Produktqualität in agilen Entwicklungsvorgehen. BITKOM Software Summit Frankfurt, 23. September 2014 Dominik Rost, Hartmut Schmitt Produktqualität in agilen Entwicklungsvorgehen BITKOM Software Summit Frankfurt, 23. September 2014 Dominik Rost, Hartmut Schmitt 1 Motivation 2 Agile Entwicklungsvorgehen Status Quo vorwiegend eingesetzte

Mehr

Basiswissen Software-Projektmanagement

Basiswissen Software-Projektmanagement isql-reihe Basiswissen Software-Projektmanagement Aus- und Weiterbildung zum Certified Professional for Project Management nach isqi-standard von Bernd Hindel, Klaus Hörmann, Markus Müller, Jürgen Schmied

Mehr

Transformation von Wissen in Software

Transformation von Wissen in Software Stefan Pukallus Transformation von Wissen in Software Möglichkeiten des Einsatzes von Wissensmanagement bei der Entwicklung von Software Diplomica Verlag Stefan Pukallus Transformation von Wissen in Software:

Mehr

Hochschule Heilbronn Technik Wirtschaft Informatik

Hochschule Heilbronn Technik Wirtschaft Informatik Hochschule Heilbronn Technik Wirtschaft Informatik Studiengang Electronic Business (EB) Diplomarbeit (280000) Evaluierung und Einführung eines Web Content Management Systems bei einem internationalen und

Mehr

Customer-specific software for autonomous driving and driver assistance (ADAS)

Customer-specific software for autonomous driving and driver assistance (ADAS) This press release is approved for publication. Press Release Chemnitz, February 6 th, 2014 Customer-specific software for autonomous driving and driver assistance (ADAS) With the new product line Baselabs

Mehr

ISO 15504 Reference Model

ISO 15504 Reference Model Prozess Dimension von SPICE/ISO 15504 Process flow Remarks Role Documents, data, tools input, output Start Define purpose and scope Define process overview Define process details Define roles no Define

Mehr

Peter Meier. Die Umsetzung von Risikomanagement nach ISO 31000. - Leseprobe -

Peter Meier. Die Umsetzung von Risikomanagement nach ISO 31000. - Leseprobe - Peter Meier Die Umsetzung von Risikomanagement nach ISO 31000 Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen

Mehr

SYSTEMS ENGINEERING. Stefan Wenzel. Organisation und Methodenauswahl in der Produktentwicklung

SYSTEMS ENGINEERING. Stefan Wenzel. Organisation und Methodenauswahl in der Produktentwicklung SYSTEMS ENGINEERING Stefan Wenzel Organisation und Methodenauswahl in der Produktentwicklung Herbert Utz Verlag Wissenschaft München Bibliografische Information Der Deutschen Bibliothek Die Deutsche Bibliothek

Mehr

CeBIT 17.03.2015. CARMAO GmbH 2014 1

CeBIT 17.03.2015. CARMAO GmbH 2014 1 CeBIT 17.03.2015 CARMAO GmbH 2014 1 HERZLICH WILLKOMMEN Applikationssicherheit beginnt lange bevor auch nur eine Zeile Code geschrieben wurde Ulrich Heun Geschäftsführender Gesellschafter der CARMAO GmbH

Mehr

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing.

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. SOFTWARETECHNIK Kapitel 7 Vorgehensmodelle Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. Armin Zimmermann Inhalt Vorgehensmodelle Sequenzielle Modelle Iterative

Mehr

Erfolgreiche Unternehmensführung durch den Einsatz von Corporate Performance Management

Erfolgreiche Unternehmensführung durch den Einsatz von Corporate Performance Management Andrei Buhrymenka Erfolgreiche Unternehmensführung durch den Einsatz von Corporate Performance Management Für Unternehmen mit Business Intelligence Diplomica Verlag Andrei Buhrymenka Erfolgreiche Unternehmensführung

Mehr

Wissensmanagement in der humanitären Logistik

Wissensmanagement in der humanitären Logistik Erik Lewerenz Wissensmanagement in der humanitären Logistik Diplomica Verlag Erik Lewerenz Wissensmanagement in der humanitären Logistik ISBN: 978-3-8428-0760-0 Herstellung: Diplomica Verlag GmbH, Hamburg,

Mehr

Spannungsfeld Projektmanagement in der öffentlichen Verwaltung

Spannungsfeld Projektmanagement in der öffentlichen Verwaltung Bernhard Rapf Spannungsfeld Projektmanagement in der öffentlichen Verwaltung Die systemorientierte Fallanalyse zur Erkennung von situativen Leistungsfaktoren im Projektalltag Diplomica Verlag Bernhard

Mehr

SAPs PLM Interface für CATIA V5

SAPs PLM Interface für CATIA V5 V6 SAPs PLM Interface für CATIA V5 Durchgängige, sichere und trotzdem schlanke Geschäftsprozesse erhöhen die Wettbewerbsfähigkeit in einem immer härteren globalen Wettstreit um die Gunst der potenziellen

Mehr

Application Life Cycle Management

Application Life Cycle Management Application Life Cycle Management Konzepte von ALM Hermann Lacheiner +43 7236 3343 849 Hermann.Lacheiner@scch.at www.scch.at Das SCCH ist eine Initiative der Das SCCH befindet sich im Anwendungsorientierte

Mehr

Eine empirische Analyse für den deutschen Markt. von. Dr. Alexander Hick

Eine empirische Analyse für den deutschen Markt. von. Dr. Alexander Hick Der Einfluss von Fondsrankings und -ratings auf das Mittelaufkommen von Aktienfonds Eine empirische Analyse für den deutschen Markt von Dr. Alexander Hick Fritz Knapp Verlag Frankfurt am Main Abbildungsverzeichnis

Mehr

Praxisberichte. Plan des Vortrags. Das Rational Unified Process für die Anforderungsspezifikation

Praxisberichte. Plan des Vortrags. Das Rational Unified Process für die Anforderungsspezifikation Praxisberichte Das Rational Unified Process für die Anforderungsspezifikation Seminar in Software Engineering Spezifikationsverfahren Prof. Dr. Martin Glinz Nancy Schett Laurent Bagnoud Plan des Vortrags

Mehr

1.1 Basiswissen komprimiert... 4 1.2 Praxiswissen Testmanagement Übersicht... 8. 2 Fundamentaler Testprozess 11

1.1 Basiswissen komprimiert... 4 1.2 Praxiswissen Testmanagement Übersicht... 8. 2 Fundamentaler Testprozess 11 xiii 1 Einleitung 1 1.1 Basiswissen komprimiert.......................... 4 1.2 Praxiswissen Testmanagement Übersicht.............. 8 2 Fundamentaler Testprozess 11 2.1 Testplanung und -steuerung........................

Mehr

HANAUER H!LFE e.v. (Hrsg.) Die Entwicklung professioneller Opferhilfe

HANAUER H!LFE e.v. (Hrsg.) Die Entwicklung professioneller Opferhilfe HANAUER H!LFE e.v. (Hrsg.) Die Entwicklung professioneller Opferhilfe VS RESEARCH HANAUER H!LFE e.v. (Hrsg.) Die Entwicklung professioneller Opferhilfe 25 Jahre Hanauer Hilfe VS RESEARCH Bibliografische

Mehr

www.fh-kl.de Aktueller Einsatz von HyperWorks in der Lehre an der FH Kaiserslautern Prof. Dr.-Ing. Matthias R. Leiner

www.fh-kl.de Aktueller Einsatz von HyperWorks in der Lehre an der FH Kaiserslautern Prof. Dr.-Ing. Matthias R. Leiner Aktueller Einsatz von HyperWorks in der Lehre an der FH Kaiserslautern Prof. Dr.-Ing. Matthias R. Leiner Kompetenzzentrum für Mechatronische Systeme (KMS) Technische Mechanik, Mehrkörpersysteme, Mathematik

Mehr

Service Level Agreements in der Kontraktlogistik

Service Level Agreements in der Kontraktlogistik Simone Rechel Service Level Agreements in der Kontraktlogistik Steigerung der Servicequalität und Verbesserung der Wirtschaftlichkeit in der Logistik OPTIMUS Bibliografische Information der Deutschen Bibliothek

Mehr

Ihr Weg zu Industrie 4.0 führt über. Entwicklung 4.0. Feynsinn beraten.realisieren.schulen - 1 - FEYNSINN

Ihr Weg zu Industrie 4.0 führt über. Entwicklung 4.0. Feynsinn beraten.realisieren.schulen - 1 - FEYNSINN Ihr Weg zu Industrie 4.0 führt über Entwicklung 4.0 Feynsinn beraten.realisieren.schulen - 1 - FEYNSINN Betrifft mich Industrie 4.0 schon heute? Es ist noch ein langer Weg bis zur Einführung von Industrie

Mehr

Experience. nr.52. ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen. märz 2012

Experience. nr.52. ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen. märz 2012 ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen Experience nr.52 märz 2012 RequIREMENTs EngINEERINg Ins Schwarze treffen Ins SchwARze treffen Requirements Engineering: die Grundlagen

Mehr

Universität OLDENBURG

Universität OLDENBURG CARL VON > OSSIETZKY Universität OLDENBURG Fakultät II - Informatik, Wirtschafts- und Rechtswissenschaften Department für Informatik Föderierte ERP-Systeme auf Basis von Web Services Dissertation zur Erlangung

Mehr

Human Capital Management: Anwendbarkeit und Nutzen einer monetären Human Capital Bewertung mit der Saarbrücker Formel nach Scholz, Stein & Bechtel

Human Capital Management: Anwendbarkeit und Nutzen einer monetären Human Capital Bewertung mit der Saarbrücker Formel nach Scholz, Stein & Bechtel Michael Kock. Human Capital Management: Anwendbarkeit und Nutzen einer monetären Human Capital Bewertung mit der Saarbrücker Formel nach Scholz, Stein & Bechtel Praxisorientierte Personal- und Organisationsforschung;

Mehr

Christian Kremer. Kennzahlensysteme für Social Media Marketing. Ein strategischer Ansatz zur Erfolgsmessung. Diplomica Verlag

Christian Kremer. Kennzahlensysteme für Social Media Marketing. Ein strategischer Ansatz zur Erfolgsmessung. Diplomica Verlag Christian Kremer Kennzahlensysteme für Social Media Marketing Ein strategischer Ansatz zur Erfolgsmessung Diplomica Verlag Christian Kremer Kennzahlensysteme für Social Media Marketing: Ein strategischer

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

Grob- und Detailplanung bei der Implementierung nutzen

Grob- und Detailplanung bei der Implementierung nutzen Softwarearchitektur Grob- und Detailplanung bei der Implementierung nutzen Bereich Realisierung Aktivität Softwareinkrement realisieren Ziele Vermitteln einer Orientierungshilfe für alle Entwickler Etablierung

Mehr

Erfolgsfaktoren von Customer Relationship Management Strategien

Erfolgsfaktoren von Customer Relationship Management Strategien Klaus Sevenich Erfolgsfaktoren von Customer Relationship Management Strategien in Unternehmen Diplomica Verlag Klaus Sevenich Erfolgsfaktoren von Customer Relationship Management Strategien in Unternehmen

Mehr

Software Engineering und Projektmanagement 2.0 VO

Software Engineering und Projektmanagement 2.0 VO Software Engineering und Projektmanagement 2.0 VO Inhalte der Einheit Was ist Usability? Wieso ist Usability wichtig? Vorlesung 2009W Usability Engineering (Christoph Wimmer) Sicherheit in der Softwareentwicklung

Mehr

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Andreas Armbrecht Siemens AG Darmstadt, 01. 02. Dezember 2009 Business Unit Rail Automation Systeme der Eisenbahnautomatisierung

Mehr

Vorwort. Hermann J. Schmelzer, Wolfgang Sesselmann. Geschäftsprozessmanagement in der Praxis

Vorwort. Hermann J. Schmelzer, Wolfgang Sesselmann. Geschäftsprozessmanagement in der Praxis Vorwort Hermann J. Schmelzer, Wolfgang Sesselmann Geschäftsprozessmanagement in der Praxis Kunden zufrieden stellen - Produktivität steigern - Wert erhöhen ISBN (Buch): 978-3-446-43460-8 Weitere Informationen

Mehr

Entwicklung eines Konzeptes zur Spezifikation standardisierter Leistungsparameter im Rahmen einer industrialisierten Software-Bereitstellung

Entwicklung eines Konzeptes zur Spezifikation standardisierter Leistungsparameter im Rahmen einer industrialisierten Software-Bereitstellung Berliner Schriften zu modernen Integrationsarchitekturen herausgegeben von Prof. Dr.-Ing. habil. Andreas Schmietendorf Hochschule für Wirtschaft und Recht Berlin, FB Band 11 Florian Muhß Entwicklung eines

Mehr

Inhaltsverzeichnis. 1 Einleitung 1. 2 Einführung und Grundlagen 7

Inhaltsverzeichnis. 1 Einleitung 1. 2 Einführung und Grundlagen 7 xv 1 Einleitung 1 2 Einführung und Grundlagen 7 2.1 Die neue Rolle der IT...................................... 7 2.2 Trends und Treiber........................................ 8 2.2.1 Wertbeitrag von

Mehr

Talentmanagement mit System

Talentmanagement mit System Talentmanagement mit System Peter Wollsching-Strobel Birgit Prinz Herausgeber Talentmanagement mit System Von Top-Performern lernen Leistungsträger im Unternehmen wirksam unterstützen Der PWS-Ansatz Herausgeber

Mehr

Konfigurations management

Konfigurations management Gerhard Versteegen (Hrsg.) Guido Weischedel Konfigurations management Mit 111 Abbildungen Springer Inhaltsverzeichnis Einführung. 1.1 Allgemeines zum Thema Konfigurationsmanagement 1 1.2 Grundlagen des

Mehr

Supply Chain Management

Supply Chain Management Guntram Wette Supply Chain Management in kleinen und mittleren Unternehmen Können KMU erfolgreich ein SCM aufbauen? Diplomica Verlag Guntram Wette Supply Chain Management in kleinen und mittleren Unternehmen

Mehr

Phasen. Gliederung. Rational Unified Process

Phasen. Gliederung. Rational Unified Process Rational Unified Process Version 4.0 Version 4.1 Version 5.1 Version 5.5 Version 2000 Version 2001 1996 1997 1998 1999 2000 2001 Rational Approach Objectory Process OMT Booch SQA Test Process Requirements

Mehr

Cloud Architektur Workshop

Cloud Architektur Workshop Cloud Architektur Workshop Ein Angebot von IBM Software Services for Cloud & Smarter Infrastructure Agenda 1. Überblick Cloud Architektur Workshop 2. In 12 Schritten bis zur Cloud 3. Workshop Vorgehensmodell

Mehr

Change Management in der öffentlichen Verwaltung

Change Management in der öffentlichen Verwaltung Christian Wörpel Change Management in der öffentlichen Verwaltung Die Verwaltungsbeschäftigten im Fokus von IT-Veränderungsprozessen Diplomica Verlag Christian Wörpel Change Management in der öffentlichen

Mehr

Safer Software Formale Methoden für ISO26262

Safer Software Formale Methoden für ISO26262 Safer Software Formale Methoden für ISO26262 Dr. Stefan Gulan COC Systems Engineering Functional Safety Entwicklung Was Wie Wie genau Anforderungen Design Produkt Seite 3 Entwicklung nach ISO26262 Funktionale

Mehr

Social Media Analytics & Monitoring

Social Media Analytics & Monitoring Andreas Werner Social Media Analytics & Monitoring Verfahren und Werkzeuge zur Optimierung des ROI Andreas Werner aw@datenonkel.com Lektorat: Dr. Michael Barabas Copy-Editing: Annette Schwarz, Ditzingen

Mehr

Gliederung. Einführung Phasen Ten Essentials Werkzeugunterstützung Aktivitäten, Rollen, Artefakte Werkzeug zur patternorientierten Softwareentwicklung

Gliederung. Einführung Phasen Ten Essentials Werkzeugunterstützung Aktivitäten, Rollen, Artefakte Werkzeug zur patternorientierten Softwareentwicklung Peter Forbrig RUP 1 Gliederung Einführung Phasen Ten Essentials Werkzeugunterstützung Aktivitäten, Rollen, Artefakte Werkzeug zur patternorientierten Softwareentwicklung Peter Forbrig RUP 2 Rational Unified

Mehr

Business Intelligence für Prozesscontrolling

Business Intelligence für Prozesscontrolling Business Intelligence für Prozesscontrolling Peter Singer Business Intelligence für Prozesscontrolling Konzeption eines Business-Intelligence-Systems für subjektorientierte Geschäftsprozesse unter Beachtung

Mehr

Office-basierte CAQ-Systeme - am Beispiel der Integration von Prüfplanung, FMEA und Reklamationsmanagement. Dissertation. Doktoringenieur (Dr.-Ing.

Office-basierte CAQ-Systeme - am Beispiel der Integration von Prüfplanung, FMEA und Reklamationsmanagement. Dissertation. Doktoringenieur (Dr.-Ing. Office-basierte CAQ-Systeme - am Beispiel der Integration von Prüfplanung, FMEA und Reklamationsmanagement Dissertation zur Erlangung des akademischen Grades Doktoringenieur (Dr.-Ing.) vorgelegt der Fakultät

Mehr

Basiswissen Software- Projektmanagement

Basiswissen Software- Projektmanagement Bernd Hindel. Klaus Hörmann. Markus Müller. Jürgen Schmied Basiswissen Software- Projektmanagement Aus- und Weiterbildung zum Certified Professional for Project Management nach isqi-standard 2., überarbeitete

Mehr