Tag des Systems Engineering€¦ · Ansatz zur integrierten Verwendung von SysML Modellen in PLM 293 zur Beschreibung der funktionalen Produktarchitektur (W) Torsten Gilz, Martin

Maik MaurerSven-Olaf Schulze

SystemsEngineering

Tag des

Stuttgart 6. – 8. November 2013

Der Weg zu den technischen Systemen von morgen

Maurer, Schulze Tag des Systems Engineering

Hinweis zur CD:Die im Buch enthaltene CD steht Ihnen unterwww.downloads.hanser.de unter dem Suchbegriff „Maurer“ oderhttp://www.hanser.de/9783446439153zum Download bereit. Ihr Passwort lautet: maurer43915

Tag des Systems EngineeringStuttgart 6. – 8. November 2013

Der Weg zu den technischen Systemen von morgen

unter Mitarbeit von

Albert Albers, Matthias Behrendt, Axel Berres, Bernd Bertsche, Ralf Bongard, Anja Czaja, Andrea Denger, Marek Dittmar, Benny Drescher, Roman Dumitrescu, Moritz Eigel, Martin Eigner, David Endler, Sönke Escher, Christian Friedrich, Johannes Fritz, Jürgen Gausemeier, Karsten Giess, Torsten Gilz, Andreas Graf, Lorenzo Guerrasio, Haygazun Hayka, Maik Hofmann, Wilfried Horn, Peter Iwanek, Eckhard Jokisch, Andreas Karcher, Lydia Kaiser, Daniel Kasperek, Sven Kleiner, Herbert Klenk, Oliver Koller, Marcus Krastel, Jesko G. Lamm, Martin Langlotz, Jan Marco Leimeister, Christian Lichtenberg, Alexander Lohberg, Sebastian Maisenbacher, Maik Maurer, Jan Meyer, Martin Motzer, Florian Munker, Katrin Mutter, Hoai Nam Nguyen, Tobias Nitsche, Alexander Nyßen Gunther Reinhart, Christoph Peters, Axel Röder, Stephan Roth, Stephan Rudolph, Samira Salman, Ulrich Sendler, Dieter Scheithauer, Kenneth Schlör, Nicholas Schmitt, Stefan Schuck, Sven-Olaf Schulze, Holger Schumann, Stanko Škec, Daniel Steffen, Tilman Stehr, Mario Štorga, Adam Strożek, Utz Täuber, Jan von Tongelen, Ingo Treue, Christian Tristl, Christian Tschirner, Markus Walker, Tim Weilkiens, Olga Wiederkehr, Christian Wölfling, Robert Woll, Peter Zeiler, Christian Zingel,

Maik MaurerSven-Olaf Schulze

Die Herausgeber:Dr.-Ing. Maik Maurer, Technische Universität München, Lehrstuhl für Produktentwicklung, Boltzmannstraße 15, 85748 GarchingSven-Olaf Schulze, Gesellschaft für Systems Engineering e.V., Zeppelinstr. 71-73, 81669 München

Bibliografische Information Der Deutschen Bibliothek:Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über <http://dnb.d-nb.de> abrufbar.

ISBN: 978-3-446-43915-3 E-Book-ISBN: 978-3-446-43946-7

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutzgesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften.

Alle in diesem Buch enthaltenen Verfahren bzw. Daten wurden nach bestem Wissen erstellt und mit Sorgfalt getestet. Dennoch sind Fehler nicht ganz auszuschließen. Aus diesem Grund sind die in diesem Buch enthaltenen Verfahren und Daten mit keiner Verpflichtung oder Garantie irgendeiner Art verbunden. Autoren und Verlag übernehmen infolgedessen keine Verantwortung und werden keine daraus folgende oder sonstige Haftung übernehmen, die auf irgendeine Art aus der Benutzung dieser Verfahren oder Daten oder Teilen davon entsteht.

Dieses Werk ist urheberrechtlich geschützt. Alle Rechte, auch die der Übersetzung, des Nach-druckes und der Vervielfältigung des Buches oder Teilen daraus, vorbehalten. Kein Teil des Werkes darf ohne schriftliche Einwilligung des Verlages in irgendeiner Form (Fotokopie, Mikrofilm oder einem anderen Verfahren), auch nicht für Zwecke der Unterrichtsgestaltung – mit Ausnahme der in den §§ 53, 54 URG genannten Sonderfälle – reproduziert oder unter Verwendung elektronischer Systeme verarbeitet, vervielfältigt oder verbreitet werden.

© Carl Hanser Verlag, München 2013 Herstellung: Steffen Jörg Coverconcept & -design: Atelier Frank Wohlgemuth, BremenDruck und Bindung: Digital Print Group O. Schimek GmbH, MünchenPrinted in Germany

Tag des Systems Engineering 2013

I

Vorwort

Sehr geehrte Teilnehmer/Innen,

nach dem sensationellen Erfolg der Konferenz 2012 in Paderborn, in der wir die Teilnehmerzahl verdoppeln konnten, die Aussteller mit Ihren Werkzeugen und Dienstleistungen und die Universität mit anwendungsorientierten Exponaten ein interessantes Umfeld präsentierten, sind die Maßstäbe für 2013 neu gesetzt worden. Dies geschah nicht zuletzt durch die herausragenden Beiträge, die aus dem gesamten Spektrum des Systems Engineering kamen. In diesem Jahr hat die Universität Stuttgart die Vorbereitungen mit unterstützt, und wir sind das erste Mal eine Kooperation eingegangen. Mit dem ANSSTAND e.V. haben wir einen interessanten Partner gefunden, der sich das V-Modell®XT für die Entwicklung von Software im öffentlichen Sektor und die Behörden in die Satzung geschrieben hat. Damit hat sich das Spektrum für den Tag des Systems Engineering erweitert, und einige Beiträge als auch ein Tutorial geben einen Einblick in den neuesten Stand.

Die Beiträge in diesem Jahr sind wieder von industriellen Erfahrungsberichten als auch wissenschaftlichen Beiträgen zum Thema SE in einem ausgewogenen Mix geprägt. Mit dem Thema „Der Weg zu den technischen Systemen von morgen – The Value of Systems Engineering“ greifen wir in diesem Jahr besonders die Argumente zum Mehrwert auf, den Systems Engineering bringt. Der wirtschaftliche Nachweis und die Anpassung an die einzelnen Branchen und Firmenprozesse werden immer wichtiger. So haben in diesen Proceedings nicht nur die FAS-Arbeitsgruppe und die Themen des modellbasiertem SE einen Platz gefunden, sondern auch die neue Arbeitsgruppe zum Thema ROI. Der Wert der systematischen Vorgehensweise wird immer deutlicher und findet sich in einer Vielzahl von Anwendungen wieder. Viele Firmen aus den unterschiedlichsten Branchen informieren sich über das Systems Engineering und werden Mitglied der GfSE e.V. Auch wird die Zukunft der eingesetzten PLM Werkzeuge sich immer mehr mit dem modellbasierten und dem SE-Ansatz auseinandersetzen und somit einen ganzheitliche Unterstützung des Lebenszyklus anbieten. Mit diesem Ziel bieten wir diese Plattform für Innovationen, Denkanstöße und dem


II

Austausch auf dem Gebiet des Systems Engineering an und unterstützen damit den Wissens- und Erfahrungstransfer zwischen Industrie, Forschung und Lehre.

In diesem Sinne wünsche ich Ihnen auch diesem Jahr erfolgreiche Tage und eine interessante Lektüre zum Systems Engineering und bedanke mich bei allen Personen, die einen Beitrag eingereicht haben und den ehrenamtlichen Helfern, die diese Konferenz und diese Ausgabe ermöglicht haben.

Sven-Olaf Schulze, Vorsitzender der GfSE e.V.


III

InhaltsverzeichnisDer Konferenzband enthält wissenschaftliche Beiträge (W) und Industriebeiträge (I). Wissenschaftliche Beiträge durchliefen gegenüber den Industriebeiträgen eine intensivere Begutachtung nach wissenschaftlichen Standards.

T1 KomplexitätsbeherrschungKann man die Komplexität eines Systems messen? (I) 3 Markus Walker

Komplexitätsmanagement im Anlagenbau (I) 11 Christian Wölfling, Ingo Treue

Systems Engineering Meets Service Science – Extending the Scope 21 for Holistic Design of Product-Service-Systems Using a Telemedicine Example (W) Christoph Peters, Stanko Škec, Jan Marco Leimeister, Mario Štorga

T2 Requirements EngineeringTestautomatisierung im regulierten Umfeld orientiert am V-Modell (I) 33 Karsten Giess, Lorenzo Guerrasio, Christian Friedrich

Kunden auf die Couch! „Psychoanalyse“ für Requirements Engineers (I) 43 Ralf Bongard

Requirements-Management im agilen Umfeld mit Open-Source Tools (I) 53 Eckhard Jokisch

T3 SE Methodik 1Seiteneffekte – Ursachen, Wirkungen und Konsequenzen für 61 ein ganzheitliches Systems Engineering (W) Stephan Rudolph

Wirtschaftlichkeitsbewertung von Methoden des Systems Engineering – 71 Ein Simulationsansatz mit System Dynamics (W) Adam Stro ek, Roman Dumitrescu, Olga Wiederkehr

Adaptives SE-basiertes Rahmenwerk zur Synchronisation von 81 Teilentwicklungsprozessen (W) Christian Tristl, Herbert Klenk, Andreas Karcher


IV

T4 SE Implementierung 1Nutzen von Systems Engineering – Bewertungsoptionen bei der 93 Einführung von Systems Engineering (I) Sven-Olaf Schulze, Adam Stro ek

Funktionsorientierte Entwicklung von verteilten E/E-Funktionen (I) 103 Andreas Graf, Samira Salman

Studie: Systems Engineering in der industriellen Praxis (W) 113 Jürgen Gausemeier, Anja Czaja, Olga Wiederkehr, Roman Dumitrescu, Christian Tschirner, Daniel Steffen

T5 SE Implementierung 2Über die Rolle der Geometrie im Systems Engineering (W) 125 Martin Motzer, Stephan Rudolph

Best-Practice-Ansatz zur Erfassung und Modellierung von 135 Stakeholder-Sichten (W) Johannes Fritz, Andrea Denger

Simulation der Zuverlässigkeit von Gesamtfahrzeugfunktionen 145 am Beispiel Fahrkomfort (W) Katrin Mutter, Oliver Koller, Bernd Bertsche, Peter Zeiler, Axel Röder

T6 SE Implementierung 3Systems Engineering Return on Investment (I) 157 David Endler, Daniel Steffen, Alexander Lohberg, Florian Munker

Happy Systems Engineering – prototypische Entwicklung eines 167 elektrisch unterstützten Kinderwagens in einem Beratungsunternehmen (I) Utz Täuber

T7 Prozessgestaltung 1Folgt aus Prozessreife wirklich Produktreife? – Ein Beispiel aus der 179 Automobilindustrie (I) Jan von Tongelen, Moritz Eigel

Lebenszyklusphasenmodelle Heute (I) 187 Dieter Scheithauer


V

Von der Anforderungserfassung bis zur Funktionsstruktur – 197 Ein Systems Engineering-Vorgehen für die industrielle Praxis (I) Nicholas Schmitt, Lydia Kaiser, Roman Dumitrescu, Maik Hofmann

T8 Prozessgestaltung 2Vorgehensmodell zur modularen Einführung von 209 Systems Engineering (W) Sven Kleiner, Marcus Krastel, Martin Langlotz

Strukturbasierte Modellierung und Bewertung von 219 Entwicklungsprozessen von Produkt-Service Systemen (W) Christian Lichtenberg, Daniel Kasperek, Sebastian Maisenbacher, Maik Maurer

Unternehmensspezifische Zusammenstellung und Bewertung digitaler 229 Werkzeugketten zur Unterstützung mechatronischer Anlagenentstehungsprozesse (W) Benny Drescher, Gunther Reinhart

T9 SE Methodik 2Contextuelles BusinessCoaching® für profitable System 241 Engineering Ergebnisse (I) Kenneth Schlör

Integration der ISO 26262 mit einer qualifizierten ALM Lösung (I) 251 Stefan Schuck

HLB Entwicklungsprozess im Kontext des Systems Engineerings (W) 261 Hoai Nam Nguyen, Robert Woll, Haygazun Hayka, Rainer Stark


VI

T10 SystemarchitekturOn the Integration of Technology-Based and User-Oriented 273 Functional Architectures (W) Marek Dittmar, Stephan Roth

Funktionale Architekturen in der Systementwicklung anwenden (I) 283 Jesko G. Lamm, Alexander Lohberg, Tim Weilkiens

Ansatz zur integrierten Verwendung von SysML Modellen in PLM 293 zur Beschreibung der funktionalen Produktarchitektur (W) Torsten Gilz, Martin Eigner

T11 Modellbasierte Systementwicklung 1Was Sie schon immer über MBSE, PLM und Industrie 4.0 wissen 305 sollten (I) Ulrich Sendler, Tim Weilkiens

Modellbasiertes Systemengineering zur Qualitätsverbesserung bei der 315 Entwicklung eines automobilen Steuergerätes (I) Wilfried Horn, Jan Meyer

T12 Modellbasierte Systementwicklung 2Sind graphische Modellierungssprachen effizient? (W) 327 Axel Berres, Holger Schumann, Tobias Nitsche, Tilman Stehr, Sönke Escher

Fachdisziplinübergreifende Systemmodellierung mechatronischer 337 Systeme mit SysML und CONSENS (W) Peter Iwanek, Lydia Kaiser, Roman Dumitrescu, Alexander Nyßen

Integrative Systemmodellierung von Hardware- und Softwarekomponenten 347 in SysML am Beispiel eines innovativen Datengateways (W) Albert Albers, Florian Munker, Christian Zingel, Matthias Behrendt


VII

VeranstalterGesellschaft für Systems Engineering e.V.

HerausgeberDr.-Ing. Maik Maurer Sven-Olaf Schulze

ProgrammkomiteeDr.-Ing. R. Dumitrescu (Fraunhofer IPT) Prof. Dr.-Ing. J. Gausemeier (Heinz Nixdorf Institut) R. Kaffenberger (softwareinmotion) Prof. Dr.-Ing. U. Lindemann (TU München) Dr.-Ing. M. Maurer (TU München) Markus Reinhold (Ansstand e.V. / CoCOO) PD Dr.-Ing. habil. S. Rudolph (ISD Stuttgart) F. Scheerer (Continental Teves) S.-O. Schulze (UNITY)

Lokale Ausrichtung durchInstitut für Statik und Dynamik der Luft- und Raumfahrtkonstruktionen, Universität Stuttgart, PD Dr.-Ing. habil. S. Rudolph


VIII

Platin Sponsoren Tag des Systems Engineering 2013

IX

Tag des Systems Engineering 2013 Platin Sponsoren

X


XI


XII


XIII

UNITY – Die Managementberatung für zukunftsorientierte Unternehmensgestaltung

www.unity.de

UNITY ist die Managementberatung für zukunftsorientierte Unternehmens-gestaltung. Wir schaffen innovative Prozesse und Geschäftsmodelle – von der Konzeption bis zur Umsetzung.Seit 1995 hat UNITY mehr als 800 Projekte in der Automobilindustrie, der Fertigungsindustrie und der Gesundheitswirtschaft zum Erfolg geführt. Zu unseren Kunden zählen sowohl der renommierte Mittelstand als auch 16 der DAX-30-Unternehmen. Wir sind mit 160 Mitarbeitern an neun Stand-orten im gesamten deutschsprachigen Raum vertreten und führen weltweit Projekte durch. Unsere Kunden profi tieren insbesondere vom einzigartigen UNITY-Bera-tungsansatz: Gemeinsam mit ihnen erarbeitet UNITY maßgeschneiderte Lösungen, die ihren Erfolg nachhaltig steigern.

CONSULTING & INNOVATION


XIV


1

T1 KomplexitätsbeherrschungKann man die Komplexität eines Systems messen? (I) Markus Walker

Komplexitätsmanagement im Anlagenbau (I) Christian Wölfling, Ingo Treue

Systems Engineering Meets Service Science – Extending the Scope for Holistic Design of Product-Service-Systems Using a Telemedicine Example (W) Christoph Peters, Stanko Škec, Jan Marco Leimeister, Mario Štorga


2

Industriebeitrag Tag des Systems Engineering 2013

3

Kann man die Komplexität eines Systems messen?

Markus Walker

Schindler Aufzüge AG, R&D-ESE-SE, Zugerstrasse 13, CH-6030 Ebikon, [email protected]

Zusammenfassung: Komplexität ist in aller Munde. Es wird von Komplexitätsbeherrschung und Komplexitätsreduktion gesprochen. Systeme werden als mehr oder minder komplex wahrgenommen oder definiert. Erstaunlicherweise scheint keine standardisierte, quantifizierbare und folglich messbare Definition für Komplexität zu existieren, welche sich an den Eigenschaften eines Systems orientiert. In der Arbeitsgruppe ›Moderat-komplexe Systeme‹ (MkS) der GfSE suchten wir eine Definition, um moderat komplexe Systeme von solchen mit höherer Komplexität abzugrenzen. Dabei kam die Frage auf, wie die Komplexität eines Systems bewertet werden kann. Dieser Beitrag präsentiert die Recherche-Ergebnisse zu dieser Frage.

1 Einleitung

Bei der Entwicklung einer Definition für moderat komplexe Systeme stellte sich die Frage, wie Komplexität zu definieren ist und ob diese mittels System-Eigenschaften gemessen werden kann. Dies würde eine quantitative Abgrenzung zu komplexen Systemen erlauben. Es existieren einige Definitionen über den Begriff der Komplexität, diese aber nur in qualitativer Form. Aus pragmatischen Gründen wurde in [MkS12] ein moderat komplexes System definiert als:

»Ein MkS ist ein System, dessen Subsysteme außerhalb des Verantwortungsbereichs von Systems Engineers eine Unterstruktur erhalten. Dabei soll die Ermittlung des Verantwortungsbereichs von Systems Engineers unabhängig davon sein, ob das System innerhalb eines Unternehmens oder über eine Zulieferkette hinweg entsteht.«

Bei genauer Betrachtung baut diese Definition auf Eigenschaften der Organisation und nicht des betrachteten Systems auf. Dies ist nicht falsch. Häufig werden Eigenschaften gemessen, welche einfach messbar sind. In der Folge wird auf andere Eigenschaften geschlossen, welche kausal von den gemessenen Eigenschaften abhängig sind [SB10].

In der Arbeitsgruppe ›Moderat-komplexe Systeme‹ (MkS) der GfSE ist man überzeugt, dass weniger komplexe System mit weniger formalen Methoden entwickelt und gewartet werden können. Dies soll den Aufwand für Systems Engineering auf ein notwendiges aber hinreichendes Maß reduzieren. Diese Ansicht wird auch im Vorwort des INCOSE Systems Engineering Handbook dargelegt [Ha11]. In der Folge wird im SE Handbuch empfohlen den Lebenszyklusprozess entsprechend anzupassen, also auch auf Grund der Komplexität des Zielsystems.

Tag des Systems Engineering 2013 Industriebeitrag

4

Wenn, wie oben erwähnt, der Lebenszyklusprozess auf Grund der Systemkomplexität angepasst werden soll, wäre es hilfreich, dieses Mittels quantitativen Indikatoren begründen zu können. Immerhin wird in [Ha11] empfohlen, 10 – 20 % des Projektaufwandes für Systems Engineering einzusetzen. Die Frage ist berechtigt, wann und warum eher 10 % und wann eher 20 % des Projektaufwandes angemessen sind.

Bei der Recherche wurden viele englische Quellen benutzt. Dabei wurde angenommen, dass der englische Begriff ›complexity‹ dem deutschen Begriff ›Komplexität‹ gleich gesetzt werden kann. Insgesamt wurden mehr als 30 Definitionen, Artikel oder Bücher geprüft. Die komplette Liste der Referenzen kann beim Autor bezogen werden.

2 Definitionen

Im Systems Engineering Journal wurden in den vergangenen Jahren eine Reihe von Beiträgen zum Thema Komplexität publiziert. Dabei ging es weniger um die Begriffsdefinition als vielmehr wie mit Komplexität umzugehen sei oder wie Systems Engineering zur Bewältigung oder Reduktion von Komplexität eingesetzt werden könnte. Dazu wurde von den Autoren dargelegt was sie als komplex bewerten oder sie verwiesen auf existierende Definitionen.

In [BLTW] wird Komplexität in Bezug auf Geschäftsprozesse definiert. Als Treiber für Komplexität nennen die Autoren die Vielfältigkeit und die Anzahl der beteiligten Elemente und deren Beziehung zueinander. Komplexität von Geschäftsprozessen werde mitunter durch das Zusammenwirken von Personen aus unterschiedlichen Domänen erhöht. Dadurch würden Beziehungen und Veränderungen entstehen, welche vom Beobachter nicht immer oder manchmal nur schwer erkennbar wären. Es wird erwähnt, dass Komplexität zum Teil subjektiv wäre, das heißt von den kognitiven Eigenschaften des Betrachters abhinge. Die Beteiligung von Menschen mit unterschiedlichen Fähigkeiten, Verhalten und Zielen würden Geschäftsprozesse komplex machen.

In [CJ04] wird Komplexität in Bezug auf Engineering und zunehmend höherer Integration von technischen Systemen betrachtet. Als Komplexitätstreiber wird die heute übliche hohe Integration und die zunehmende Durchdringung aller System Elemente durch Informationstechnologie identifiziert. Weniger komplexe Systeme, wie früher üblich, seien charakterisiert durch eine Dominanz der hierarchischen Beziehungen zwischen den System Elementen. Ursache-Wirkung-Beziehungen seien direkt und offensichtlich. Bei den komplexeren Systemen seien die lateralen Beziehungen zwischen den System Elementen dominant gegenüber den hierarchischen Beziehungen. Dadurch würden Ursache-Wirkung-Beziehungen indirekt und seien nicht mehr offensichtlich. In der Folge seien Risiken schwieriger abschätzbar und Design-Entscheide oder -Änderungen beeinflussten häufig auch die anderen System Elemente. Als Eigenschaften von Komplexität werden identifiziert, die Anzahl der System Elemente, deren Interaktionsintensität, die Unterschiedlichkeit und Variabilität der System Elemente, das Umfeld des Systems und dessen Veränderung sowie vom Stakeholder anfänglich beabsichtigte und im Lebenszyklus erweiterte Anwendung des Systems.


5

In [SS11] zitieren die Autoren eine ganze Reihe von Definitionen, von eigenen Publikationen und aus anderen Veröffentlichungen. In ihrer eigenen Definition wird Komplexität als Maß definiert, welches die Schwierigkeit, den Aufwand oder benötigte Ressourcen eines Systems bestimmt, um ein anderes System effektiv zu beobachten oder mit diesem zu kommunizieren oder zu interagieren. Die Autoren kategorisieren die verschiedenen Komplexitäts-Definitionen. Diese Kategorien werden eingereiht von kognitiver oder empfundener Komplexität, über Verhaltenskomplexität, über biologischer Komplexität, zu Berechnungskomplexität. Die kognitive oder empfundene Komplexität wird assoziiert mit Schwierigkeiten eines Menschen ein System zu verstehen. Verhaltenskomplexität bezieht sich auf das zeitliche Verhalten eines Systems. Biologische Komplexität bezieht sich auf lebende Systeme, welche grundsätzlich als komplex bewertet werden. Berechnungskomplexität bezieht sich auf Probleme, welche mittels Informationstechnologie bewältigt werden können und bewertet den dazu nötigen Ressourcenbedarf wie Rechenleistung und Speicherbedarf. Die Autoren nennen die Anzahl der Objekte in einem System, die Anzahl der Arten oder Klassen der Objekte und die Anzahl und Art der Beziehungen zwischen diesen Objekten als Eigenschaften von Komplexität.

Im INCOSE Webinar 33 wird auf eine Systemkategorisierung verwiesen, welche sich zur Definition von Komplexität eignen könnte. Jack Ring [Rin11] kategorisiert damit Systeme nach deren Verhalten in deterministisch, stochastisch und nichtdeterministisch. Die Treiber dahinter sind die Anzahl der Teile, die Anzahl der Art der Teile und der Anteil der Ambiguität im System.

Der Begriff ›Komplexität‹ wird nicht nur im Systems Engineering Umfeld benutzt. Es lohnt sich also auch zu schauen, wie der Begriff in anderem Zusammenhang benutzt oder definiert wird.

In [WW07] wird mit Referenz auf die allgemeine System Theorie nach Niklas Luhmann nur zwischen komplex und trivial unterschieden. Komplex wird dabei mit permanent überraschend beschrieben. Komplexität wird als Maß der Lebendigkeit eines Systems betrachtet. Trivial nimmt Bezug auf tote und folglich deterministische Systeme. Schwierigkeiten ein Objekt zu verstehen wird von den Autoren mit Kompliziertheit assoziiert. Kompliziertheit wird als Maß der Unwissenheit bezeichnet.

In [Sim08] wird zwischen trivial, nichttrivial und komplex unterschieden. Trivial wird dabei mit synthetisch determiniert, analytisch bestimmbar, vergangenheitsunabhängig und voraussagbar assoziiert. Nichttrivial wird mit synthetisch determiniert, analytisch unbestimmbar, vergangenheitsabhängig und voraussagbar assoziiert. Komplex wird nur für lebende Systeme verwendet.

Für Software Engineering wird in [LB06] zwischen struktureller Komplexität, konzeptioneller Komplexität, und Berechnungskomplexität unterschieden. Die strukturelle Komplexität für Software Module wird in Abhängigkeit der Anzahl Code-Zeilen, der Anzahl Kontrollflüsse, der Anzahl Operatoren und Operanden oder der Anzahl Datenflüsse und Datenstrukturen gesetzt. Für Systeme, hier Software bestehend aus verschiedenen Modulen, wird die strukturelle Komplexität als Kombination der


6

genannten Eigenschaften definiert. Die konzeptionelle Komplexität wird assoziiert mit Schwierigkeiten eines Menschen den Software Code zu verstehen. Die Berechnungskomplexität nimmt Bezug auf den Ressourcenbedarf wie Rechenzeit und Speicherbedarf um die Software laufen zu lassen.

Verschiedene Glossare (Duden, IEC Glossary, WordNet, The Free Dictionary, [ISO10]) bieten Definitionen für den Begriff ›Komplexität‹. Diese sind sich recht ähnlich und nehmen Bezug auf den Beobachter und dessen Schwierigkeit das System zu verstehen. Beispielsweise [ISO10] definiert Komplexität als Schwierigkeitsgrad ein System-Design oder SW-Code aufgrund der zahlreichen System Elemente und deren Beziehungen untereinander zu verstehen oder zu prüfen.

In einer Break-off-Diskussion zwischen Teilnehmern der GfSE Arbeitsgruppen APS (Agiles Projektmanagement für System) und der MkS konnte kein Konsens für eine Definition gefunden werden.

3 Messung von Komplexität

Die Komplexität eines Systems ist offensichtlich abhängig von der Anzahl und Art der System Elementen welche interagieren als auch von der Anzahl und Art der Interaktionen zwischen diesen System Elementen und dem Umfeld des Systems. In frühen Phasen besteht das System aus Stakeholder Anforderungen. Später wird daraus ein Model welches bei der Realisierung des Systems instanziiert wird. Entsprechend der Lebenszyklusphase des Systems sind verschiedene Objekte zur Bewertung der Komplexität zu verwenden.

3.1 Für die Projekt Planung

In [War01] wird zur Quantifizierung ein Situations-Komplexität-Index vorgeschlagen. Der Situations-Komplexität-Index ist das Produkt aus der Multiplikation von Miller Index, Spreadthink Index und De Morgan Index.

Der Miller Index beziffert die Anzahl der Probleme dividiert durch 7. Georg A. Miller entdeckte, dass der Mensch in der Lage ist 7 ± 2 Probleme gleichzeitig zu behandeln.

Der Spreadthink Index quantifiziert den Konsens einer Gruppe Beteiligter. Dabei wählt jedes Mitglied der Gruppe die aus seiner Sicht fünf wichtigsten Probleme. Der Index berechnet sich aus der Summe der unterschiedlichen Probleme welche die Gruppenmitglieder auswählten dividiert durch 5.

Der De Morgan Index berücksichtig die Abhängigkeiten zwischen den einzelnen Problemen. Dazu werden die paarweisen Abhängigkeiten der Probleme gezählt und die Summe durch 10 dividiert.

Zur praktischen Anwendung des Situations-Komplexität-Index im Systems Engineering könnte man jede Stakeholder Anforderung als Problem betrachten. So ließe sich der


7

Miller Index und der De Morgan Index berechnen. Zur Berechnung des Spreadthink Index könnte man die Stakeholder Anforderungen den Stakeholdern zur Bewertung vorlegen. Dies impliziert, dass sich der resultierende Situations-Komplexität-Index im Verlauf eines Projektes verändern wird. In den meisten Fällen werden im Verlauf des Projektes neue Stakeholder, neue Anforderungen und neue Beziehungen zwischen den Anforderungen entdeckt.

3.2 Für die Bewertung von Architekturen

3.2.1 Methoden vom Software Engineering

Zur Messung der Komplexität von Software wurden verschiedene Metriken entwickelt [LB06]. Da viele Modellierungswerkzeuge ursprünglich für Software Engineering entwickelt wurden, bieten diese solche Metriken an.

Die simpelste Metrik zur Bewertung von Software Komplexität ist die Zählung der Zeilen des Source Codes. Im Model wird anstelle der Code Zeilen die Anzahl der Klassen, respektive der Objekte welche von Klassen abgeleitet wurden gezählt. An einem physischen System entspräche dies der Zählung der Teile.

Eine weitere Metrik zählt die möglichen Kontrollflüsse um Software Komplexität zu messen. Ursprünglich wurde diese Methode entwickelt, um die Verifizierbarkeit zu bewerten und die Verständlichkeit des Software Codes zu messen. Eine Anwendung im Systems Engineering in entsprechenden Modellen ist denkbar, da dort die Kontrollflüsse identifiziert werden können.

Die Halstead Metrik verrechnet die Anzahl und die Anzahl Arten von Operatoren mit der Anzahl und Anzahl Arten der Operanden. In [LB06] wird angemerkt, dass selbst für Software Code keinen Konsens bestehe, was als Operator gewertet werden müsse. Zudem hätte sich die Halstead Metrik nicht als bessere Vorhersage für Wartungsaufwand erwiesen, als das Zählen der Code Zeilen. Letzteres erzeuge aber bedeutend weniger Aufwand zur Ermittlung. Wenn bereits im Software Engineering die Kategorisierung von Operatoren und Operanden schwierig ist, wird eine Transformation dieser Methode ins Systems Engineering nicht einfach sein.

Bei der Informationsfluss Metrik werden die Anzahl Datenflüsse und die Anzahl Datenstrukturen miteinander verrechnet. Die Methodik ist in IEEE 982.1:2005 standardisiert. Datenflüsse und -strukturen sind Objekte welche in Informationstechnik vorkommen. In einem System Model würden sich passende Objekte finden, welche an Stelle der Daten und Datenstrukturen mit dieser Metrik verarbeitet werden können. Bei der Transformation auf ein physisches System stellt sich die Frage, ob Flüsse von verschiedenen physikalischen Größen gleich bewertet werden dürfen, wie dies mit Datenflüssen vorgesehen ist.

Für objektorientierte Software wird in [LB06] eine Reihe von weiteren Methoden erwähnt. Diese sind typischerweise in Modellierungswerkzeugen verfügbar und können


8

somit auch für Systemmodelle genutzt werden. Insgesamt erscheinen aber alle aus dem Software Engineering stammenden Methoden nur Teilaspekte der Komplexität zu messen. Zumindest in [LB06] gibt es keine Definition in welcher Beziehung die einzelnen Werte zueinander stehen und ob diese zu einem gesamten Komplexitäts-Wert verrechnet werden können.

3.2.2 Methoden aus dem DARPA META Programm

Das DARPA META Programm verlangte neben anderen Zielen auch die Definitionen wie Komplexität gemessen werden kann, welche über das Zählen von Source-Code-Zeilen und Zahl der Teile des Systems hinausgeht.

The Boeing Company bestätigte in [Boe11] die Machbarkeit einer Komplexitäts-Metrik. Um die Komplexität zu messen wurde eine Kombination von mehreren Messwerten vorgeschlagen. Diese beinhalten die Anzahl Knoten und die Anzahl Kanten im Model. Weiter wird der Vernetzungsgrad auf Basis der Anzahl Knoten und Kanten berücksichtig. Der Informationsgehalt der Knoten wird in einer normalisierten Form eingerechnet. Schließlich wird ein Clusterkoeffizient der Knoten bestimmt, welcher als Maß für die Kohäsion des Knoten-Kanten-Netzwerkes dient. Die genannten Werte werden gewichtet aufsummiert. Die Gewichtungen wurden in einem Kalibrierungsprozess ermittelt, welcher neben Expertenmeinungen auch Daten aus früheren Projekten berücksichtigte.

Die United Technology Corporation machte in [UTC11] einen Vorschlag, welcher zwischen struktureller und dynamischer Komplexität unterscheidet. Die strukturelle Komplexität bezieht sich dabei auf die physischen Elemente und deren Interfaces zueinander. Die Komplexität setzt sich dabei aus der Summe der Komplexität der beteiligten Elemente plus der gewichteten Summe der Komplexität der benutzten Interfaces zusammen. Die Gewichtung wird durch die Graph Energie des Netzwerkes der Elemente bestimmt. Die dynamische Komplexität soll als Shannon-Entropie berechnet werden. Die dazu nötige Matrix soll von Experten durch Analyse des Systems aufgebaut werden.

Beide vorgeschlagenen Methoden zur Messung von Komplexität setzen Zugriff auf große Mengen und eine Vielzahl von verschiedenen Daten voraus. Dies wird wahrscheinlich nur praktikabel sein, wenn das Ziel-System in einem integrierten Model beschrieben ist.

4 Fazit

Es gibt verschiedene Definitionen für den Begriff ›Komplexität‹. Die Definitionen wurden wahrscheinlich eher zur qualitativen Beschreibung von Systemen entwickelt.

Für einige Domänen gibt es praktisch anwendbare Definitionen und Metriken zur Bestimmung von Komplexität. Zur praktischen Anwendung im Systems Engineering


9

wären Verbesserungen wünschenswert. Eine Transformation der etablierten Messmethoden aus dem Software Engineering scheint teilweise möglich.

Die beschriebenen Metriken sind von der Vollständigkeit der Systembeschreibung (Anforderungen oder Architekturbeschreibung) abhängig. Dabei stellt sich die Frage welche Detailtiefe eine Beschreibung erzielen muss. Dies dürfte davon abhängig sein, ob man die benötigten System Elemente einkaufen kann oder ob diese erst zu entwickeln sind. Es ist aber auch abhängig von der Menge an implizitem Wissen welches vorausgesetzt werden kann. Eine Metrik welche auf eine Blackbox angewandt werden könnte würde diese Frage erheblich vereinfachen. Eine Komplexitäts-Metrik für eine Blackbox würde wahrscheinlich die minimal nötige Komplexität dieser Blackbox definieren, was eine hervorragende Benchmark darstellen würde.

Dieser Beitrag kann keinen Anspruch auf Vollständigkeit erheben, da hierfür in einigen Bereichen weitere und tiefere Analysen nötig wären.

Bei der Verifikation des Literaturverzeichnisses stieß der Autor auf einen Beitrag [SM13] welcher am INCOSE International Symposium 2013 präsentiert wurde. Darin wird eine Literaturanalyse zum Thema Messung von Komplexität präsentiert. Obige Schlussfolgerungen entstanden unabhängig von [SM13].

5 Literaturverzeichnis

[BLTW] Biemans, F.P.M.; Lankhorst, M.M.; Teeuw, W.B.; van de Wetering, R.G.: Dealing with the complexity of business systems architecting. In Systems Engineering Vol. 4, No. 2, 2001, S. 118 ff. Wiley Periodicals, Inc.

[Boe11] Stuart, D.; Mattikalli, R., DeLaurentis, D.; Shah, J.: META II – Complexity and Adaptability – Final Report. 2011. http://cps-vo.org/file/2646/download/10018, besucht 14. August 2013

[CJ04] Calvano, C.N.; John, P.: Systems engineering in an age of complexity. In Systems Engineering Vol. 7, No. 1, 2004, S. 25 ff. Wiley Periodicals, Inc.

[Ha11] Haskins, C. (Ed.). (2011). Systems Engineering Handbook: A Guide for System Life-Cycle Processes and Activities v. 3.2.2, International Council on Systems Engineering (INCOSE), San Diego, USA.

[ISO10] ISO/IEC/IEEE 24765:2010 Systems and software engineering — Vocabulary. First edition 2010-12-15.

[LB06] Laird, L.M.; Brennan, M.C.: Measuring Complexity. In Software Measurement and Estimation. 2006, S. 54 ff. John Wiley & Sons, Inc.

[MkS12] Eisenring, S.; Frikart, M.; Gerritsen, W.; Krainer, C.; Lamm, J.G.; Mettauer, A.; Walker, M.; Zollinger, M.: Auf dem Weg zu einem Leitfaden im Systems Engineering für moderat-komplexe Systeme. In Maurer, M., Schulze, S.O. (Hrsg.), Tag des Systems Engineering, Paderborn, 7.-9. November 2012, S. 33–42. Carl Hanser Verlag, München.

[Rin11] Ring, J.: Resilient Systems Engineering, Präsentation am 24. Januar 2011für INCOSE_IL & Gordon Center for Systems Engineering at the TECHNION,. http://tx.technion.ac.il/~gordoncn/24012011/1_jack_110124%20final.ppt, besucht 14 August 2013

[SB10] Smith, E.D.; Bahill A.T.: Attribute Substitution in Systems Engineering. In Systems Engineering Vol. 13, No. 2, 2010, S. 130 ff. Wiley Periodicals, Inc.


10

[Sim08] Simon, F.B.: Einführung in die Systemtheorie und Konstruktivismus. 3. Auflage 2008, ISBN 978-3-89670-547-1, Carl-Auer-Systeme Verlag, Heidelberg.

[SM13] Sheard, S.A.; Mostashari, A.: Complexity Measures to Predict System Development Project Outcomes. 2013. In INCOSE i-Pub https://www.incose.org/ipub/13/16.pdf, besucht 14. August 2013

[SS11] Simpson, J.; Simpson, M.: Complexity reduction: A pragmatic approach. In Systems Engineering Vol. 14, No. 2, 2011, S. 180 ff. Wiley Periodicals, Inc.

[UTC11] Murray, B.T.; Pinto, A.; Skelding, R.; de Weck, O.; Zhu, H.; Nair, S.; Shougarian, N.; Sinha, K.; Bopardikar, S.; Zeidner, L.: META II – Complex Systems Design and Analysis (CODA) – Final Report. 2011. http://cps-vo.org/file/2693/download/10030, besucht 8. August 2013

[War01] Warfield, J.: Measuring Complexity. April 2001. In DSpace/Manakin Repository, http://digilib.gmu.edu:8080/xmlui/handle/1920/3411, besucht 8. August 2013

[WW07] Wohland, G; Wiemeyer, M.: Denkwerkzeuge der Höchstleister: Wie dynamikrobuste Unternehmen Marktdruck erzeugen. 1. Auflage 2007, ISBN 978-3-86774-020-3, Murmann Verlag GmbH, Hamburg.


11

Komplexitätsmanagement im Anlagenbau

Christian Wölfling1, Ingo Treue2

1Rücker und Schindele GmbH, Kapellenweg 6, 81371 München, Christian.Wö[email protected]

2Rücker und Schindele GmbH, Kapellenweg 6, 81371 München, [email protected]

Zusammenfassung: Auch im Anlagenbau stellt die kontinuierlich zunehmende Komplexität der Systeme eine ganz besondere Herausforderung dar. Der bewusste und erfolgreiche Umgang mit ihr erfordert ein umfassendes Verständnis der Komplexität sowie ein umfassendes Komplexitätsmanagement. Am Beispiel typischer Problemfelder in Anlagenbauprojekten werden Nutzen und Anwendbarkeit des Komplexitätsmanagements und der Zusammenhang zum Systems Engineering diskutiert. Darüber hinaus wird der Einsatz einzelner Methoden des Systems Engineering zur Umsetzung der verschiedenen Strategien aus dem Komplexitätsmanagement vorgestellt und der durch deren Anwendung entstehende Nutzen über den gesamten Projektverlauf bewertet. Die angewandten Methoden werden kritisch hinterfragt und Verbesserungspotenziale vorgestellt. Mit dem Hintergrund langjähriger Erfahrung in der Planung und Realisierung von Anlagenbauprojekten werden sowohl das ganzheitliche Komplexitätsmanagement als auch die Anwendung von Systems Engineering als wesentlicher Schlüssel zum erfolgreichen Umgang mit Komplexität herausgearbeitet.

1. Motivation und Inhalt

Technologien und Prozesse sind heute so hoch integriert und vernetzt wie nie zuvor. Grund dafür ist auch der schnelle Wandel mit neuen Technologien, Techniken und Organisationen. Es sind auch im Anlagenbau nicht mehr nur Sach- oder Dienstleistungen an sich, sondern kombinierte Produkt-Service-Systeme, auch hybride Produkte genannt, gefragt. Diese stellen kundenspezifische Komplettlösungen dar, die neben kundenindividuellen Produkten auch Dienstleistungen wie Beratung, Betrieb und Wartung umfassen [Ber11][Kna08]. Dadurch steigen die Komplexität der Produkte und damit auch die Komplexität der Produktentwicklungsprozesse [Tom07].

Laut einer Studie des Beratungsunternehmens PriceWaterhouseCoopers scheitern 75% aller Großprojekte im Anlagen-, Kraftwerks- und Infrastrukturbau bei Kosten-, Zeit- und Qualitätszielen [PWC12].

Komplexitätsmanagement wird zu einem der kritischen Erfolgsfaktoren der Zukunft. Die Durchführung eines Komplexitätsmanagements ist keine Frage des „ob“, sondern allenfalls eine des „Wie“ [Sch05][Gie10].

Um Komplexität zielgerichtet managen zu können, ist ein umfassendes Verständnis darüber notwendig, was unter Komplexität verstanden wird und welche Ausprägungen

Documents

Tag des Systems Engineering€¦ · Ansatz zur integrierten Verwendung von SysML Modellen in PLM 293 zur Beschreibung der funktionalen Produktarchitektur (W) Torsten Gilz, Martin