Muutke küpsiste eelistusi

Model-Based System Architecture 2nd edition [Kõva köide]

"The book covers the practice of being a system architect in an organization that uses models to support the systems engineering processes. It will therefore introduce the fundamentals of both architecting systems and using models to assist the architecting process. While the first edition of the book had a balanced description of both the technicalities of modeling the system architecture and concrete advice on the practical work as a system architect, the second edition focuses even more on the system architect role and what it means to be a system architect. It includes new chapters on systems, systems-of-systems, and cyber-physical systems; model governance; and tools for the architect. It also provides guidance on how a practitioner can benefit and apply the presented concepts."--

MODEL-BASED SYSTEM ARCHITECTURE

AN UP-TO-DATE EXPLORATION OF THE NEWEST STANDARDS AND BEST PRACTICES IN SYSTEM ARCHITECTING

In the newly revised Second Edition of Model-Based System Architecture, a team of expert engineers deliver a detailed and authoritative review of the practice of system architecture in organizations that use models to support the systems engineering process. In the book, readers will find introductions to the fundamentals of architecting systems and using models to assist the architecting process.

The latest edition offers refreshed content based on ISO 15288:2015 and a renewed focus on the role of the system architect. New chapters on systems-of-systems, and cyber-physical systems, and system architect tools offer guidance to practicing professionals on how to apply the presented concepts in the real-world.

In addition to the latest definitions of the architecture governance and evaluation processes described in ISO 42020 and 42030, the book provides:

  • A thorough introduction to the value of systems architecting, definitions of system architecture, and model-based system architecture
  • Comprehensive explorations of model governance, architecture descriptions, patterns, and principles, and the roles of typical architecture stakeholders
  • Practical discussions of Agile approaches to systems architecture, the FAS Method, and architecture frameworks
  • In-depth examinations of systems architecting work and necessary soft skills for systems architects
  • Modeling of system architectures with SysML including a brief overview of SysML v1 and an outlook to SysML v2

Perfect for system architects and system engineers, Model-Based System Architecture will also earn a place in the libraries of students and researchers studying functional architectures.

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

JESKO G. LAMM is a Senior Systems Engineer in the European hearing healthcare industry.

STEPHAN ROTH is a coach, consultant, and trainer for systems and software engineering at oose. He is a certified systems engineer (GfSE)®- Level C.

MARKUS WALKER is Elevator System Architect in the CTO Division at Schindler Elevator. He is an INCOSE Certified Systems Engineering Professional (CSEP).