Geschäftskunden Kundenprogramme
Vor Ort
Merkzettel Warenkorb
Model-Based System Architecture

Model-Based System Architecture

Wiley Series in Systems Engineering and Management

Aus der Reihe

Fr. 202.00

inkl. gesetzl. MwSt.
Versandkostenfrei

Model-Based System Architecture

Ebenfalls verfügbar als:

Gebundenes Buch

Gebundenes Buch

ab Fr. 173.00
eBook

eBook

ab Fr. 115.00

Beschreibung

Details

Verkaufsrang

42059

Einband

Gebundene Ausgabe

Erscheinungsdatum

22.04.2022

Verlag

John Wiley & Sons

Seitenzahl

464

Beschreibung

Details

Verkaufsrang

42059

Einband

Gebundene Ausgabe

Erscheinungsdatum

22.04.2022

Verlag

John Wiley & Sons

Seitenzahl

464

Maße (L/B/H)

23.5/15.7/2.9 cm

Gewicht

814 g

Auflage

2. Auflage

Sprache

Englisch

ISBN

978-1-119-74665-2

Weitere Bände von Wiley Series in Systems Engineering and Management

Unsere Kundinnen und Kunden meinen

0.0

0 Bewertungen

Informationen zu Bewertungen

Zur Abgabe einer Bewertung ist eine Anmeldung im Konto notwendig. Die Authentizität der Bewertungen wird von uns nicht überprüft. Wir behalten uns vor, Bewertungstexte, die unseren Richtlinien widersprechen, entsprechend zu kürzen oder zu löschen.

Verfassen Sie die erste Bewertung zu diesem Artikel

Helfen Sie anderen Kund*innen durch Ihre Meinung

Erste Bewertung verfassen

Unsere Kundinnen und Kunden meinen

0.0

0 Bewertungen filtern
Die Leseprobe wird geladen.
  • Model-Based System Architecture
  • Foreword xv Preface xvii About the Companion Website xxi 1 Introduction 1 2 An Example: The Scalable Observation and Rescue System 5 3 Better Products - The Value of Systems Architecting 9 3.1 The Share of Systems Architecting in Making Better Products 9 3.2 Benefits that can be Achieved 10 3.2.1 Benefit for the Customer 10 3.2.2 Benefit for the Organization 12 3.3 Benefits that can be Communicated Inside the Organization 14 3.4 Beneficial Elements of Systems Architecting 15 3.5 Benefits of Model-Based Systems Architecting 16 4 Systems, Systems of Systems, and Cyber-Physical Systems 17 4.1 Definition of "System" 17 4.1.1 System Elements 19 4.1.2 System Context 20 4.1.3 System Characteristics 21 4.1.4 Purpose 22 4.1.5 System Evolution 23 4.2 Definition of "System of Systems" 23 4.3 Definition of "Cyber-Physical System" 26 4.4 Composition of a "Cyber-Physical System of Systems" 27 5 Definition of System Architecture 31 5.1 What Is Architecture? - Discussion of Some Existing Definitions 31 5.2 Relations Between Concepts of "System," "Architecture," and "Architecture Description" 33 5.3 Definition of "Architecture" 35 5.3.1 Interactions 36 5.3.2 Principles 37 5.3.3 Architecture Decisions 37 5.4 Functional and Physical Architecture 37 5.5 Taxonomy of Physical Architectures 39 5.5.1 Logical Architecture 40 5.5.2 Product Architecture 41 5.5.3 Base Architecture 41 5.6 Architecture Landscape for Systems 41 5.6.1 System Architecture 42 5.6.2 System Design 43 5.6.3 Discipline-Specific Architecture and Design 44 6 Model-Based Systems Architecting 45 7 Model Governance 51 7.1 Overview 51 7.2 Model Governance in Practice 52 8 Architecture Description 57 8.1 Architecture Descriptions for Stakeholders 58 8.2 Definition of "Architecture Description" 60 8.2.1 Architecture Viewpoints 62 8.2.2 Architecture Views 65 8.2.3 Architecture Decisions 67 8.2.4 Architecture Rationales 69 8.3 How to Get Architecture Descriptions? 69 8.3.1 Model-Based Vision 69 8.3.2 Forms and Templates 71 9 Architecture Patterns and Principles 75 9.1 The SYSMOD Zigzag Pattern 76 9.2 The Base Architecture 82 9.3 Cohesion and Coupling 85 9.4 Separation of Definition, Usage, and Run-Time 87 9.5 Separate Stable from Unstable Parts 89 9.6 The Ideal System 89 9.7 View and Model 90 9.8 Diagram Layout 92 9.9 System Model Structure 93 9.10 System Architecture Principles 95 9.11 Heuristics 95 9.11.1 Heuristics as a Tool for the System Architect 95 9.11.2 Simplify, Simplify, Simplify: Strength and Pitfall 97 10 Model-Based Requirements Engineering and Use Case Analysis 99 10.1 Requirement and Use Case Definitions 99 10.2 Model-Based Requirements and Use Case Analysis from the MBSA Viewpoint 102 10.2.1 Identify and Define Requirements 103 10.2.2 Specify the System Context 104 10.2.3 Identify Use Cases 105 10.2.4 Describe Use Case Flows 109 10.2.5 Model the Domain Knowledge 110 10.3 The SAMS Method 112 10.3.1 SAMS Method Definitions 113 10.3.2 SAMS Method 114 10.4 Use Cases 2.0 117 11 Perspectives, Viewpoints and Views in System Architecture 119 11.1 Introduction 119 11.2 The Functional Perspective 121 11.2.1 SysML Modeling of Functional Blocks 123 11.2.2 Architecture Views for the System Architect 124 11.2.3 Different Architecture Views for the Stakeholders of Different Functions 124 11.3 The Physical Perspective 125 11.3.1 Logical Architecture Example 126 11.3.2 Product Architecture Example 127 11.4 The Behavioral Perspective 130 11.5 The Layered Perspective 130 11.5.1 The Layered Approach 130 11.5.2 The Layered Perspective in Systems Architecting 132 11.5.3 Relation to the Domain Knowledge Model 134 11.5.4 Architecting the Layers 136 11.5.5 SysML Modeling of Layers 136 11.6 System Deployment Perspective 142 11.7 Other Perspectives 144 11.8 Relation to the System Context 146 11.8.1 Validity of the System Boundary 146 11.8.2 Using the System Context as a Part of the Stakeholder-Specific Views 146 11.8.3 Special System Context View for Verification 147 11.9 Mapping Different System Elements Across Different Levels 148 11.9.1 Functional-to-Physical Perspective Mapping 149 11.9.2 Mapping More Perspectives 153 11.9.3 Mapping Different Levels 153 11.10 Traceability 155 11.11 Perspectives and Architecture Views in Model-based Systems Architecting 155 11.11.1 Creating Different Architecture Views in a Model-Based Approach 155 11.11.2 Using SysML for Working with Different Perspectives and Architecture Views 157 11.11.3 The Importance of Architecture Viewpoints in Model-Based Systems Architecting 159 12 Typical Architecture Stakeholders 161 12.1 Overview 161 12.2 Requirements Engineering 162 12.3 Verification 163 12.4 Configuration Management 166 12.5 Engineering and Information Technology Disciplines 167 12.6 Project and Product Management 171 12.7 Risk Managers 174 12.8 Development Roadmap Planners 174 12.9 Production and Distribution 177 12.10 Suppliers 178 12.11 Marketing and Brand Management 178 12.12 Management 180 13 Roles 185 13.1 Roles 185 13.2 The System Architect Role 186 13.2.1 Objective 186 13.2.2 Responsibilities 186 13.2.3 Tasks 187 13.2.4 Competences 188 13.2.5 Required Skills of a System Architect 188 13.2.6 Required Skills for Model-Based Systems Architecting 190 13.3 System Architecture Teams 190 13.4 System Architecture Stakeholders 192 13.5 Recruiting System Architecture People 192 13.6 Talent Development for System Architects 194 14 Processes 199 14.1 Systems Architecting Processes 199 14.1.1 Overview 199 14.1.2 Example of Generic Process Steps 201 14.1.3 Example of Concrete Process Steps 202 14.1.4 Validation, Review, and Approval in a Model-Based Environment 203 14.2 Design Definition Process 207 14.3 Change and Configuration Management Processes 207 14.4 Other Processes Involving the System Architect 207 15 Tools for the Architect 209 16 Agile Approaches 213 16.1 The History of Iterative-Incremental Approaches 214 16.1.1 Project Mercury (NASA, 1958) 214 16.1.2 The New New Product Development Game (1986) 215 16.1.3 Boehm's Spiral Model (1988) 216 16.1.4 Lean (1945 Onwards) 217 16.1.5 Dynamic Systems Development Method (DSDM, 1994) 219 16.1.6 Scrum (1995) 220 16.2 The Manifesto for Agile Software Development (2001) 221 16.3 Agile Principles in Systems Engineering 223 16.3.1 Facilitate Face-to-Face Communication 223 16.3.2 Create a State of Confidence 224 16.3.3 Build Transdisciplinary and Self-Organized Teams 225 16.3.4 Create a Learning Organization 225 16.3.5 Design, but No Big Design (Up-Front) 226 16.3.6 Reduce Dependencies 227 16.3.7 Foster a Positive Error Culture 228 16.4 Scaling Agile 228 16.5 System Architects in an Agile Environment 230 17 The FAS Method 233 17.1 Motivation 234 17.2 Functional Architectures for Systems 236 17.3 How the FAS Method Works 239 17.4 FAS Heuristics 242 17.5 FAS with SysML 244 17.5.1 Identifying Functional Groups 244 17.5.2 Modeling the Function Structure 246 17.5.3 Modeling the Functional Architecture 249 17.6 SysML Modeling Tool Support 250 17.6.1 Create Initial Functional Groups 251 17.6.2 Changing and Adding Functional Groups 254 17.6.3 Creating Functional Blocks and their Interfaces 254 17.7 Mapping of a Functional Architecture to a Physical Architecture 254 17.8 Experiences with the FAS Method 256 17.9 FAS Workshops 258 17.10 Quality Requirements and the Functional Architecture 259 17.11 Functional Architectures and the Zigzag Pattern 262 17.12 CPS-FAS for Cyber-physical Systems 263 18 Product Lines and Variants 269 18.1 Definitions Variant Modeling 270 18.2 Variant Modeling with SysML 271 18.3 Other Variant Modeling Techniques 276 19 Architecture Frameworks 279 19.1 Enterprise Architectures 280 19.2 Characteristics of System of Systems (SoS) 282 19.2.1 Emergence 283 19.3 An Overview of Architecture Frameworks 285 19.3.1 Zachman FrameworkTM 285 19.3.2 The TOGAF(r) Standard 286 19.3.3 Federal Enterprise Architecture Framework (FEAF) 288 19.3.4 Department of Defense Architecture Framework (DoDAF) 289 19.3.5 Ministry of Defense Architecture Framework (MODAF) 290 19.3.6 NATO Architecture Framework (NAF) 291 19.3.7 TRAK 292 19.3.8 European Space Agency Architectural Framework (ESA-AF) 293 19.3.9 OMG Unified Architecture Framework(r) (UAF(r)) 295 19.4 System Architecture Framework (SAF) 296 Together with Michael Leute 296 19.4.1 SAF and Enterprise Frameworks 296 19.4.2 SAF Ontology 298 19.5 What to Do When We Come in Touch With Architecture Frameworks 298 20 Cross-cutting Concerns 301 20.1 The Game-Winning Nonfunctional Aspects 301 20.2 Human System Interaction and Human Factors Engineering 303 20.3 Risk Management 304 20.4 Trade Studies 305 20.5 Budgets 306 21 Architecture Assessment 307 22 Making It Work in the Organization 313 22.1 Overview 313 22.2 Organizational Structure for Systems Architecting 314 22.3 Recipes from the Authors' Experience 318 22.3.1 Be Humble 319 22.3.2 Appraise the Stakeholders 319 22.3.3 Care About Organizational Interfaces 319 22.3.4 Show that it Was Always There 321 22.3.5 Lead by Good Example 321 22.3.6 Collect Success Stories and Share them When Appropriate 322 22.3.7 Acknowledge that Infections Beat Dictated Rollout 323 22.3.8 Assign the System Architect Role to Yourself 324 22.3.9 Be a Leader 324 23 Soft Skills 327 23.1 It's All About Communication 328 23.1.1 Losses in Communication 329 23.1.2 The Anatomy of a Message 330 23.1.3 Factors Influencing Communication 333 23.1.3.1 The Language 333 23.1.3.2 The Media Used 333 23.1.3.3 Spatial Distance 333 23.1.3.4 Various Connotations of Words 335 23.1.4 The Usage of Communication Aids and Tools 335 23.2 Personality Types 338 23.2.1 Psychological Types by C. G. Jung 338 23.2.2 The 4MAT System by Bernice McCarthy 340 23.3 Team Dynamics 341 23.4 Diversity and Psychological Safety 342 23.4.1 Project Aristotle (Google) 342 23.4.2 Elements of Psychological Safety 343 23.5 Intercultural Collaboration Skills 344 24 Outlook: The World After Artificial Intelligence 347 Appendix A OMG Systems Modeling Language 349 A.1 Architecture of the Language 350 A.2 Diagram and Model 352 A.3 Structure Diagrams 353 A.3.1 Block Definition Diagram 354 A.3.2 Internal Block Diagram 357 A.3.3 Parametric Diagram 361 A.3.4 Package Diagram 362 A.4 Behavior Diagrams 363 A.4.1 Use Case Diagram 364 A.4.2 Activity Diagram 366 A.4.3 State Machine Diagram 369 A.4.4 Sequence Diagram 371 A.5 Requirements Diagram 372 A.6 Extension of SysML with Profiles 374 A.7 Next-Generation Modeling Language SysML v2 376 Appendix B The V-Model 381 B.1 A Brief History of the V-Model or the Systems Engineering Vee 381 B.2 A Handy Illustration but No Comprehensive Process Description 383 B.3 Critical Considerations 385 B.3.1 The V-Model as Process Description 386 B.3.2 The V-Model Does Not Impose a Waterfall Process 386 B.3.3 The V-Model Accommodates Iterations 387 B.3.4 The V-Model Permits Incremental Development 387 B.3.5 The V-Model and Concurrent Engineering 388 B.3.6 The V-Model Accommodates Change 388 B.3.7 The V-Model Permits Early Verification Planning 388 B.3.8 The V-Model Shows Where to Prevent Dissatisfaction 388 B.4 Reading Instruction for a Modern Systems Engineering Vee 389 B.4.1 The Vertical Dimension 389 B.4.2 The Horizontal Dimension 389 B.4.3 The Left Side 389 B.4.4 The Right Side 390 B.4.5 The Levels 390 B.4.6 Life Cycle Processes 390 B.4.7 The Third Dimension 390 Appendix C Glossary 391 C.1 Heritage of the Term "Glossary" 391 C.2 Terms with Specific Meaning 393 References 399 Index 417