| Inhaltsverzeichnis | 6 |
| Vorwort | 8 |
| Modellbasierte Systementwicklung 1 | 12 |
| Werkzeuge für den Schmied funktionaler Architekturen | 14 |
| 1 Einleitung | 14 |
| 2 Methode zur Erstellung funktionaler Architekturen | 15 |
| 3 Beispiel | 16 |
| 4 Automatische Erstellung funktionaler Architekturen | 16 |
| 5 Verknüpfung mit existierenden funktionalen Modellen | 21 |
| 6 Diskussion, Schlussfolgerungen und Ausblick | 22 |
| 7 Danksagung | 23 |
| Literaturverzeichnis | 23 |
| Qualitätssicherung für modellbasierte Entwicklungsansätze | 24 |
| 1 Modelle und Modellqualität | 24 |
| 2 Unternehmensmodelle – Inhalte, Zusammenhänge, Darstellungsmittel | 25 |
| 3 Qualität von Modellen | 25 |
| 3.1 Qualitätskriterien und Messgrößen | 26 |
| 3.2 The Decision Model – Ein Ansatz mit integrierten Qualitätskriterien | 28 |
| Literaturverzeichnis | 28 |
| Modellbasierte Systementwicklung 2 | 30 |
| Hierarchie von Entwurfsentscheidungen im modellbasiertenEntwurf komplexer Systeme | 32 |
| 1 Einleitung | 32 |
| 2 Entwurfssprachen im modellbasierten Entwurf | 32 |
| 3 Analyse von Entwurfsalternativen | 35 |
| 3.1 Auswahl von Bauteilen | 36 |
| 3.2 Auswahl von Subsystemen | 37 |
| 3.3 Generierung von Analysemodellen | 39 |
| 4 Zusammenfassung | 41 |
| Literaturverzeichnis | 42 |
| Modellbasierte Systementwicklung 3 | 44 |
| Modellbasierter Systementwurf mit dem PrEMISE-Modell | 46 |
| Abkürzungen | 46 |
| Einführung | 47 |
| Teambasierter Systementwurf | 47 |
| Modellbasierte Systementwicklung | 48 |
| PrEMISE | 48 |
| Gliederung | 48 |
| Verfügbare Normen | 49 |
| ISO 10303 (STEP) | 49 |
| ECSS Normen | 49 |
| SysML | 49 |
| Das PrEMISE-Modell | 49 |
| Systemkomponenten | 49 |
| Datenaustausch | 50 |
| Vergleich mit verfügbaren Normen | 50 |
| Implementierung | 51 |
| Anwendung | 52 |
| Raumfahrt | 52 |
| Luftfahrt | 53 |
| Automotive | 53 |
| Zusammenfassung und Ausblick | 54 |
| Literaturverzeichnis | 55 |
| Modellbasierte Konzipierung eines hybriden Energiespeichersystems für ein autonomes Schienenfahrzeug | 56 |
| 1 Einleitung | 56 |
| 2 Handlungsfeld: Frühzeitige Systemmodellierung | 57 |
| 2.1 Systems Modeling Language – SysML | 58 |
| 2.2 CONSENS | 59 |
| 3 Modellbasierte Konzipierung eines hybriden Energiespeichersystems(HES) mit CONSENS | 61 |
| 3.1 Anwendungsbeispiel: Hybrides Energiespeichersystem (HES) des RailCabs | 61 |
| 3.2 Modellbasierte Konzipierung des HES | 62 |
| 4 Zusammenfassung | 64 |
| Literaturverzeichnis | 65 |
| Vorgehensmethodik 1 | 66 |
| Nachhaltige Entscheidungsfindung im Systems Engineering | 68 |
| 1 Einführung | 68 |
| 2 Das Rubikonmodell der Handlungsphasen | 69 |
| 3 Das Gruppendynamische Modell nach Tuckman | 70 |
| 4 Entscheidungen im Systems Engineering | 71 |
| 5Nachhaltige Entscheidungsfindung | 73 |
| 6 Der Entscheidungsprozess im Systems Engineering | 75 |
| Literaturverzeichnis | 77 |
| Systemmodellierung im Fokus von Generic Systems Engineering | 78 |
| 1 Bewältigung der Komplexität mit System Engin | 78 |
| 2 SE hat seinen Ursprung im Systemdenken in Kopplung mit demingenieurmäßigen Handeln | 79 |
| 3 SE war vielfältigen Wandlungen unterworfen | 80 |
| 4 SE hat das Potential für ein generelles Denkmodell undVorgehenskonzept zur Problemlösung | 81 |
| 5 SE braucht als Basis ein transparentes Systemmodell | 83 |
| 6 Roboterdesign mit erweitertem GSE-Ansatz | 84 |
| 7 Zusammenfassung und Ausblick | 86 |
| Literaturverzeichnis | 87 |
| Vorgehensmethodik 2 | 88 |
| Herausforderungen und Lösungen bei der Durchführung von asymmetrischen Prozessverbesserungsprojekten | 90 |
| 1 Einleitung | 90 |
| Warum Prozessverbesserung? | 90 |
| Welche Voraussetzungen sollten für erfolgreiche Prozessverbesserungsprojekteerfüllt sein? | 91 |
| Welche Prozessreifegradmodelle werden genutzt und wo liegen derenAnsatzschwerpunkte? | 92 |
| Was versteht man unter Prozessreifegraden? | 92 |
| 2 Zwei Praxisbeispiele für Prozessverbesserungsprojekte | 93 |
| Elektrik/Elektronik-Entwicklung eins Nutzfahrzeug OEMs | 93 |
| Software-Entwicklung eines Sonderfahrzeugbauers | 94 |
| 3 Herausforderungen und gelebte Lösungen | 95 |
| Fehlbesetzung einer Rolle | 95 |
| Fehlendes Commitment bei den Mitarbeitern | 96 |
| Auswahl der von der Prozessverbesserung erfassten Bereiche | 97 |
| Keine Bereitstellung der Ressource Zeit durch die Stakeholder der einzelnenProzesse | 98 |
| Fazit | 99 |
| Literaturverzeichnis | 99 |
| Contract Based Design: A Means to Assure Interoperability in Complex Distributed Systems | 100 |
| 1 Introduction | 100 |
| 1.1 The Risks of “Complex” Design | 101 |
| 1.2 Hidden Links | 101 |
| 1.3 State-of-the-Art Save System Engineering Methods | 101 |
| 1.4 Save Systems Architectures | 102 |
| 1.5 Complex Systems Design Issues | 103 |
| 2 Contract Based Design | 104 |
| 3 Ariane 5 Failure | 106 |
| 3.1 Contracts for the Inertial Reference System | 107 |
| 3.2 Contracts at a TechnicalPerspective | 110 |
| 4 Conclusions | 110 |
| References | 111 |
| Modell des Einsatzsystems der Fregatte F125 | 112 |
| 1 Kontext der Aufgabe | 112 |
| 1.1 Fregatte F125 | 112 |
| 1.2 Einsatzsystem der Fregatte F125 | 113 |
| 2 Aufgabenstellung | 113 |
| 2.1 Methodische Vorgaben der ES-Entwicklung | 113 |
| 2.2 Aufgabenbeschreibung | 114 |
| 3 Realisierung des ES-Modells | 114 |
| 3.1 Ausgangsbasis | 114 |
| 3.2 Struktur des Modells | 115 |
| 3.3 Ergebnis | 116 |
| 3.4 Werkzeuge | 116 |
| 4 Ergebnisbewertung und Ausblick | 116 |
| Requirements Engineering | 118 |
| Requirements: ReqIF, Formal description with DSLs and a traceability approach for Eclipse | 120 |
| 1 Introduction | 120 |
| 1.1 The research project VERDE | 120 |
| 1.2 Structure of this paper | 121 |
| 2 The Requirements Interchange Format “ReqIF” | 122 |
| 3 Requirements Modeling Framework (RMF) | 122 |
| 3.1 Eclipse as a platform | 122 |
| 3.2 Scope | 123 |
| 3.3 Structure | 123 |
| 4 Domain-specific languages and requirements | 124 |
| 4.1 Domain-Specific Languages | 125 |
| 4.2 Integrated Tooling | 126 |
| 4.3 Traceability | 127 |
| 5 Conclusion and Future Plans | 128 |
| References | 129 |
| Verbesserung der Qualität von Anforderung und Test bei komplexen Systemen durch Reverse Engineering | 130 |
| 1 Problembeschreibung | 130 |
| 2 Stand der Technik | 131 |
| 3 Industrielle Anwendung | 132 |
| 4 Lösungsvorschlag | 133 |
| 5 Evaluierung im industriellen Kontext | 135 |
| 6 Fazit und Ausblick | 138 |
| Literaturverzeichnis | 138 |
| MBSE und RBE:Ergänzung und kein Widerspruch | 140 |
| 1 „Model-Based-SE“ heute noch nicht vollständig umgesetzt | 140 |
| 2 Abgrenzung | 141 |
| a) Funktionale Analyse und Architektur | 141 |
| b) Physikalische Architektur | 141 |
| c) Schnittstellen Architektur | 142 |
| 3 Nachverfolgbarkeit (Tracebility) | 142 |
| 3.1 Verwendete Modellierungsmetho | 142 |
| 3.2 Verbindung von Modellelemente zu Anforderungen | 143 |
| 3.3 Verlinkung von Anforderungen über die Hierarchieebenen | 144 |
| 4 Ableitung von Testfällen | 145 |
| 5 Berücksichtigung von Safety Aspekten | 145 |
| 6 Dokumentationserzeugung | 147 |
| 7 Anforderungen an die Toolumgebung | 148 |
| 8 Ausblick | 149 |
| Literaturverzeichnis | 149 |
| Agile Systementwicklung 1 | 150 |
| Entscheidungsstrategien zur Festlegung und Priorisierung von Änderungen | 152 |
| 1 Entscheidungen in der modernen Produktentwicklung | 152 |
| 2 Lösungsansätze zum Umgang mit Entscheidungen | 153 |
| 2.1 Entscheidungen beim Umgang mit Änderungen | 153 |
| 2.2 Entscheidungsgremien | 153 |
| 2.3 Agile Methoden | 154 |
| 2.4 Entscheidungsstrategien | 154 |
| 2.5 Forschungsfragen und Zielstellung | 154 |
| 3 Untersuchung von Entscheidungsstrategien mittels Simulation | 155 |
| 3.1 Anforderungen an das Simulationsmodell | 155 |
| 3.2 Beschreibung der Änderungssituation | 156 |
| 3.3 Simulation der Entscheidungsstrategien | 156 |
| 3.4 Parameter der Simulation und ihre Variation | 157 |
| 3.5 Auswertung der Simulationsergebnisse | 157 |
| 4 Ergebnisse der Simulationen | 158 |
| 5 Diskussion und Ausblick | 160 |
| Danksagung | 161 |
| Literaturverzeichnis | 161 |
| Agile vs. Waterfall: What is the Best for your Development Project? | 162 |
| 1 Introduction | 162 |
| 2 Waterfall | 163 |
| 3 Agile | 164 |
| 4 Comparison | 165 |
| 5 Questionnaire | 167 |
| 7 Conclusions | 169 |
| References | 169 |
| Agile Systementwicklung 2 | 170 |
| Agiles Projektmanagement für Systeme im regulatorischen Umfeld | 172 |
| 1 Einleitung | 172 |
| 2 Motivation | 173 |
| 3 Das Umfeld | 173 |
| 4 Die Herausforderungen | 175 |
| 5 Hart, aber agil – Agilität trotz starrer Rahmenbedingungen | 176 |
| 5.1 Das Problem mit den Iterationen | 176 |
| 5.2 Das Iterationsergebnis | 176 |
| 5.3 „Agile Projekte dokumentieren nicht!“ | 177 |
| 6 Regulatorische Anforderungen an eine normgerechteProduktentwicklung | 177 |
| 7 Iteratives agiles Prototyping von Systemen | 180 |
| 7.1 Kombination von Software- und Hardware-Entwicklung als Herausforderung | 180 |
| 7.2 Erkennen und minimieren der Projektrisiken als Treiber für agiles Vorgehen | 180 |
| 7.3 Regelmäßiges und zeitnahes Feedback durch zyklische Pre-Integrationsphasen | 181 |
| 7.4 Feedback zum Vorgehen von den Projektbeteiligten | 182 |
| 8 Fazit und Ausblick | 182 |
| Literaturverzeichnis | 183 |
| Expeditionsmitglieder gesucht! Agile Wege in hierarchischen Unternehmen | 184 |
| 1 Einführung: Selbstorganisation und agilePrinzipien | 184 |
| 1.1 Anwendungsbereich und Grundprinzipien agiler Arbeitsformen | 185 |
| 2 Hindernisse in hierarchischen Unternehmen | 188 |
| 3 Lösungsansätze: Expeditionen mit Hilfe der System-Landkarte | 189 |
| 3.1 Persönliche Kompetenz | 190 |
| 3.2 Inhaltlicher Kontext | 191 |
| 3.3 Sozialer Kontext | 191 |
| 3.4 Organisatorischer Kontext | 192 |
| Literaturverzeichnis | 193 |
