Douglass Agile Systems Engineering

1. Auflage 2015
ISBN: 978-0-12-802349-5
Verlag: Elsevier Science & Techn.
Format: EPUB
Kopierschutz: 6 - ePub Watermark

E-Book, Englisch, 452 Seiten

Agile Systems Engineering presents a vision of systems engineering where precise specification of requirements, structure, and behavior meet larger concerns as such as safety, security, reliability, and performance in an agile engineering context. World-renown author and speaker Dr. Bruce Powel Douglass incorporates agile methods and model-based systems engineering (MBSE) to define the properties of entire systems while avoiding errors that can occur when using traditional textual specifications. Dr. Douglass covers the lifecycle of systems development, including requirements, analysis, design, and the handoff to specific engineering disciplines. Throughout, Dr. Douglass couples agile methods with SysML and MBSE to arm system engineers with the conceptual and methodological tools they need to avoid specification defects and improve system quality while simultaneously reducing the effort and cost of systems engineering. - Identifies how the concepts and techniques of agile methods can be effectively applied in systems engineering context - Shows how to perform model-based functional analysis and tie these analyses back to system requirements and stakeholder needs, and forward to system architecture and interface definition - Provides a means by which the quality and correctness of systems engineering data can be assured (before the entire system is built!) - Explains agile system architectural specification and allocation of functionality to system components - Details how to transition engineering specification data to downstream engineers with no loss of fidelity - Includes detailed examples from across industries taken through their stages, including the 'Waldo' industrial exoskeleton as a complex system

Embedded Software Methodologist. Triathlete. Systems engineer. Contributor to UML and SysML specifications. Writer. Black Belt. Neuroscientist. Classical guitarist. High school dropout. Bruce Powel Douglass, who has a doctorate in neurocybernetics from the USD Medical School, has over 35 years of experience developing safety-critical real-time applications in a variety of hard real-time environments. He is the author of over 5700 book pages from a number of technical books including Real-Time UML, Real-Time UML Workshop for Embedded Systems, Real-Time Design Patterns, Doing Hard Time, Real-Time Agility, and Design Patterns for Embedded Systems in C. He is the Chief Evangelist at IBM Rational, where he is a thought leader in the systems space and consulting with and mentors IBM customers all over the world. He can be followed on Twitter @BruceDouglass. Papers and presentations are available at his Real-Time UML Yahoo technical group (http://tech.groups.yahoo.com/group/RT-UML) and from his IBM thought leader page (www-01.ibm.com/software/rational/leadership/thought/brucedouglass.html).

Autoren/Hrsg.

Douglass, Bruce Powel

Inhaltsverzeichnis

1;Front Cover;1
2;Agile Systems Engineering;4
3;Copyright Page;5
4;Dedication;6
5;Contents;8
6;About the Author;16
7;Preface;18
7.1;Audience;19
7.2;Goals;19
7.3;Tooling;20
7.4;Where to Go After the Book;20
8;Acknowledgments;22
9;1 What Is Model-Based Systems Engineering?;24
9.1;1.1 Key Systems Engineering Activities;26
9.1.1;1.1.1 Identifying Customer Needs;27
9.1.2;1.1.2 Specifying System Requirements;28
9.1.3;1.1.3 Assess Dependability;28
9.1.4;1.1.4 Evaluating Alternative Architectures and Technologies;29
9.1.5;1.1.5 Selecting Specific Architectures and Technologies;30
9.1.6;1.1.6 Allocating Requirements and Interfaces to Architectures;30
9.1.7;1.1.7 Hand Off to Downstream Engineering;30
9.1.8;1.1.8 Integrate Discipline-Specific Designs into System Composite;31
9.1.9;1.1.9 Verify System as a Whole;31
9.1.9.1;1.1.9.1 Syntactic verification;32
9.1.9.1.1;Audits;32
9.1.9.1.2;Syntactic reviews;32
9.1.9.2;1.1.9.2 Semantic verification;33
9.1.9.2.1;Semantic review;33
9.1.9.2.2;Testing;34
9.1.9.2.3;Formal methods;34
9.1.9.3;1.1.9.3 System verification;35
9.1.10;1.1.10 System Validation;35
9.2;1.2 Systems Engineering Data;36
9.2.1;1.2.1 System Development Plan;36
9.2.2;1.2.2 Stakeholder Requirements;36
9.2.3;1.2.3 System Requirements;37
9.2.4;1.2.4 Certification Plan;37
9.2.5;1.2.5 Subsystem Requirements;37
9.2.6;1.2.6 Discipline-Specific Requirements;37
9.2.7;1.2.7 Safety Analysis;37
9.2.8;1.2.8 Reliability Analysis;38
9.2.9;1.2.9 Security Analysis;38
9.2.10;1.2.10 System Architecture;38
9.2.10.1;1.2.10.1 Subsystems;38
9.2.10.2;1.2.10.2 Deployment architecture;39
9.2.10.3;1.2.10.3 Dependability architecture;39
9.2.10.4;1.2.10.4 Distribution architecture;39
9.2.11;1.2.11 Integration Test Plan;40
9.2.12;1.2.12 Integration Tests;40
9.2.13;1.2.13 Verification Plan;40
9.2.14;1.2.14 Verification Tests;40
9.2.15;1.2.15 Validation Plan;41
9.2.16;1.2.16 Trace Matrix;41
9.2.17;1.2.17 Integration Test Results;42
9.2.18;1.2.18 Verification Results;42
9.2.19;1.2.19 Validation Results;42
9.3;1.3 Lifecycles of the Systems Engineer;42
9.3.1;1.3.1 V-Model Lifecycle;43
9.3.2;1.3.2 Incremental;44
9.3.3;1.3.3 Hybrid;46
9.4;1.4 Model-Based Systems Engineering (MBSE);46
9.4.1;1.4.1 The Modeling Advantage;48
9.4.1.1;1.4.1.1 Precision of engineering data;48
9.4.1.2;1.4.1.2 Data consistency across work products and engineering activities;48
9.4.1.3;1.4.1.3 A common source of engineering truth;49
9.4.1.4;1.4.1.4 Improved visualization and comprehension of engineering data;50
9.4.1.5;1.4.1.5 Ease of integration of disparate engineering data;50
9.4.1.6;1.4.1.6 Improved management and maintenance of engineering data;50
9.4.1.7;1.4.1.7 Early verification of the correctness of engineering data;51
9.4.2;1.4.2 High-Precision Modeling with UML and SysML;51
9.4.2.1;1.4.2.1 The fundamental truth of modeling: drawing?modeling;51
9.4.3;1.4.3 Modeling Is Essential for Agile Systems Engineering;52
9.4.3.1;1.4.3.1 The fundamental truth of agile systems engineering: verifiable models are required for agile systems engineering;52
9.4.4;1.4.4 Adopting Modeling in Your Organization or Project;54
9.4.4.1;1.4.4.1 Antipatterns of adopting MBSE;54
9.4.4.2;1.4.4.2 Recommend approaches for adopting MBSE;54
9.4.4.2.1;Assessment;55
9.4.4.2.2;Planning for adoption;57
9.4.4.2.3;Pilot;58
9.4.4.2.4;Deployment;58
9.4.5;1.4.5 The Rules (of Modeling);59
9.5;1.5 Summary;62
9.6;References;62
10;2 What Are Agile Methods and Why Should I Care?;64
10.1;2.1 The Agile Manifesto;66
10.2;2.2 Benefits of Agile Methods;69
10.2.1;Improved Quality of Engineering Data;69
10.2.2;Improved Engineering Efficiency;70
10.2.3;Early Return on Investment (ROI);70
10.2.4;Satisfied Stakeholders;70
10.2.5;Increased Project Control;70
10.2.6;Responsiveness to Change;71
10.2.7;Earlier and Greater Reduction in Project Risk;71
10.3;2.3 Applying the Agile Manifesto to Systems Engineering;71
10.3.1;2.3.1 Work Incrementally;71
10.3.2;2.3.2 Plan Dynamically;72
10.3.3;2.3.3 Actively Reduce Project Risk;73
10.3.4;2.3.4 Verify Constantly;74
10.3.5;2.3.5 Integrate Continuously;74
10.3.6;2.3.6 Use Case 1: Find Tracks in Airspace;75
10.3.7;2.3.7 Use Case 2: Perform Periodic Built in Test (PBIT);75
10.3.8;2.3.8 Validate Frequently;76
10.3.9;2.3.9 Modeling Is Essential for aMBSE;76
10.4;2.4 Agile Best Practices for Systems Engineering;76
10.4.1;2.4.1 Incremental Development of Work Products;76
10.4.2;2.4.2 Continual Verification of Work Products;77
10.4.3;2.4.3 Executable Requirements Models;78
10.4.4;2.4.4 Model-Based Specification Linked to Textual Specification;79
10.4.5;2.4.5 Continuous Dependability Assessment;81
10.4.6;2.4.6 Active Project Risk Management;82
10.4.7;2.4.7 Model-Based Hand Off to Downstream Engineering;84
10.4.8;2.4.8 Dynamic Planning;84
10.5;2.5 Putting It All Together: The Harmony Agile MBSE (aMBSE) Process;86
10.5.1;2.5.1 Initiate Project;89
10.5.2;2.5.2 Define Stakeholder Requirements;91
10.5.3;2.5.3 System Requirements Definition and Analysis;93
10.5.4;2.5.4 Approach 1: Flow-based Use Case Analysis;94
10.5.5;2.5.5 Approach 2: Scenario-based Use Case Analysis;95
10.5.6;2.5.6 Approach 3: State-based Use Case Analysis;95
10.5.7;2.5.7 Architectural Analysis;97
10.5.8;2.5.8 Architectural Design;97
10.5.9;2.5.9 Perform Iteration Retrospective;102
10.5.10;2.5.10 Handoff to Downstream Engineering;102
10.5.11;2.5.11 Control Project;104
10.5.12;2.5.12 Perform Quality Assurance Audits;105
10.5.13;2.5.13 Manage Change;105
10.6;2.6 Summary;106
10.7;References;107
11;3 SysML Introduction;108
11.1;3.1 SysML at 30,000 Feet;109
11.2;3.2 UML Extension Mechanisms;113
11.2.1;3.2.1 SysML Model Elements;115
11.2.2;3.2.2 SysML Diagrams;116
11.2.3;3.2.3 Behavior Diagrams;117
11.2.3.1;3.2.3.1 Activity diagram;117
11.2.3.2;3.2.3.2 Sequence diagram;118
11.2.3.3;3.2.3.3 State machine diagram;118
11.2.3.4;3.2.3.4 Use case diagram;118
11.2.4;3.2.4 Requirement Diagram;119
11.2.5;3.2.5 Structure Diagrams;120
11.2.5.1;3.2.5.1 Package diagram;120
11.2.5.2;3.2.5.2 Block definition diagram;121
11.2.5.3;3.2.5.3 Internal block diagram;121
11.2.5.4;3.2.5.4 Parametric diagram;123
11.3;3.3 Organize Your Models Like It Matters;124
11.4;3.4 Key SysML Views and Core Semantics;130
11.4.1;3.4.1 Blocks, Relations, Interfaces, and Ports;130
11.4.1.1;3.4.1.1 Blocks;130
11.4.1.2;3.4.1.2 Block instances;131
11.4.1.3;3.4.1.3 Association;132
11.4.1.4;3.4.1.4 Flows;133
11.4.1.5;3.4.1.5 Aggregation;133
11.4.1.6;3.4.1.6 Composition;134
11.4.1.7;3.4.1.7 Connector;135
11.4.1.8;3.4.1.8 Generalization;135
11.4.1.9;3.4.1.9 Dependencies;137
11.4.1.10;3.4.1.10 Ports;137
11.4.1.10.1;Standard ports;137
11.4.1.10.2;Interfaces;138
11.4.1.10.3;Proxy ports;139
11.4.1.10.4;Interface blocks;139
11.4.1.10.5;Flow properties and flow items;140
11.4.1.10.6;Full ports;140
11.4.1.11;3.4.1.11 Parts;141
11.4.2;3.4.2 Sequence Diagrams;142
11.4.3;3.4.3 Activities, Actions, and Activity Diagrams;146
11.4.3.1;3.4.3.1 Some subtle semantics;151
11.4.4;3.4.4 State Machine Diagrams;153
11.4.4.1;3.4.4.1 Definitions;154
11.4.4.2;3.4.4.2 Basic state machines;154
11.4.4.3;3.4.4.3 Nested states;159
11.4.4.4;3.4.4.4 Submachines;160
11.4.4.5;3.4.4.5 AND-states;162
11.4.4.6;3.4.4.6 Pseudostates;163
11.4.4.7;3.4.4.7 Activity diagrams or state machines?;165
11.5;3.5 Minimal SysML Profile;165
11.5.1;3.5.1 Diagrams;165
11.6;3.6 Summary;167
11.6.1;3.6.1 Copied from the UML;168
11.6.2;3.6.2 Modifications;168
11.6.3;3.6.3 New Elements;168
11.7;References;168
12;4 Agile Stakeholder Requirements Engineering;170
12.1;4.1 Objectives;171
12.2;4.2 The Stakeholder Requirements Workflow;172
12.2.1;4.2.1 Remember—This Is Agile MBSE;173
12.2.2;4.2.2 So, What Is a Use Case?;174
12.2.2.1;4.2.2.1 General properties of good use cases;174
12.2.2.1.1;Coherence;175
12.2.2.1.2;Independence;175
12.2.2.1.3;Coverage;175
12.2.2.1.4;Size (10–100 requirements, 3–50 scenarios);175
12.2.2.1.5;Exception for large systems;176
12.2.2.1.6;Return a result visible to an actor;176
12.2.2.2;4.2.2.2 Some things to avoid with use cases;176
12.2.2.2.1;Implying or revealing internal system structure;177
12.2.2.2.2;Using use cases to decompose system internals;177
12.2.2.2.3;Use cases that are too small;178
12.2.2.2.4;Dependent use cases;178
12.2.2.2.5;Too many relations among use case;178
12.2.2.2.6;Associations between use cases;178
12.2.3;4.2.3 Use Case Diagrams;179
12.2.3.1;4.2.3.1 An example: the Speed Demon Treadmill;179
12.2.3.2;4.2.3.2 Use cases;179
12.2.3.3;4.2.3.3 Actors;180
12.2.3.4;4.2.3.4 Relations;182
12.2.3.5;4.2.3.5 Association;182
12.2.3.6;4.2.3.6 Generalization;182
12.2.3.7;4.2.3.7 «Include»;182
12.2.3.8;4.2.3.8 «Extend»;183
12.2.3.9;4.2.3.9 «Allocate»;183
12.3;4.3 The Example Model: T-Wrecks, the Industrial Exoskeleton;184
12.4;4.4 Identifying Stakeholders;185
12.4.1;4.4.1 Pilot;186
12.4.2;4.4.2 Fleet Manager;186
12.4.3;4.4.3 Maintainer;187
12.4.4;4.4.4 Purchaser;187
12.4.5;4.4.5 Installer;187
12.4.6;4.4.6 The T-Wreckers Testing Team;187
12.4.7;4.4.7 Manufacturing Engineer;187
12.5;4.5 Generating Stakeholder Requirements;187
12.5.1;4.5.1 What’s a Requirement?;188
12.5.2;4.5.2 Performance and Other QoS Requirements;190
12.5.3;4.5.3 Visualizing Requirements;191
12.5.4;4.5.4 Requirements Management Tools;191
12.5.5;4.5.5 Organizing the Stakeholder Requirements Specification;194
12.6;4.6 Modeling Stakeholder Use Cases Scenarios;194
12.6.1;4.6.1 What Is a Use Case Scenario, Exactly?;195
12.6.2;4.6.2 Scenario Analysis Workflow;197
12.6.2.1;4.6.2.1 How do you know when you’re done?;199
12.6.3;4.6.3 T-Wrecks Stakeholder Use Case Scenarios;201
12.6.3.1;4.6.3.1 Proximity detection use case;201
12.6.3.2;4.6.3.2 Move joint use case;202
12.7;4.7 Create/Update Validation Plan;209
12.8;4.8 Summary;209
12.8.1;4.8.1 Identify Stakeholders;210
12.8.2;4.8.2 Generate Stakeholder Requirements;210
12.8.3;4.8.3 Model Stakeholder Use Case Scenarios;210
12.8.4;4.8.4 Create/Update Validation Plan;211
12.9;4.9 Moving On;211
12.10;Reference;211
13;5 Agile Systems Requirements Definition and Analysis;212
13.1;5.1 Objectives;213
13.1.1;5.1.1 Let’s Get Technical;213
13.2;5.2 The Systems Requirements Workflow;214
13.2.1;5.2.1 Identify System Use Cases;215
13.2.2;5.2.2 Generating/Updating System Requirements;216
13.2.3;5.2.3 Perform Use Case Analysis;216
13.2.3.1;5.2.3.1 Flow-based approach for use case analysis;216
13.2.3.2;5.2.3.2 Scenario-based approach for use case analysis;217
13.2.3.3;5.2.3.3 State-based approach for use case analysis;217
13.2.4;5.2.4 Create Logical Data Schema;217
13.2.5;5.2.5 Analyze Dependability;217
13.2.6;5.2.6 Create/Update System Verification Plan;218
13.3;5.3 Identify System Use Cases;218
13.4;5.4 Generating System Requirements;218
13.4.1;5.4.1 Allocating Requirements to System Use Cases;219
13.5;5.5 Analyzing Use Cases;220
13.5.1;5.5.1 Flow-Based Use Case Analysis;220
13.5.1.1;5.5.1.1 Define the use case context;221
13.5.1.1.1;Packages;222
13.5.1.1.2;Actor blocks;222
13.5.1.1.3;Activity and state;222
13.5.1.2;5.5.1.2 Derive use case functional flow;223
13.5.1.3;5.5.1.3 Define use case scenarios;224
13.5.1.4;5.5.1.4 Define ports and interfaces;225
13.5.1.5;5.5.1.5 Derive use case state machine;226
13.5.1.6;5.5.1.6 Verify and validate functional requirements;229
13.5.1.7;5.5.1.7 Add traceability links;229
13.5.1.8;5.5.1.8 Perform review;230
13.5.1.9;5.5.1.9 T-Wrecks flow-based use case analysis;230
13.5.1.9.1;Step 1: Use case execution context;231
13.5.1.9.2;Step 2: Derive use case functional flow;233
13.5.1.9.3;Step 3: Define use case scenarios;235
13.5.1.9.4;Step 4: Define ports and interfaces;236
13.5.1.9.5;Step 5: Derive use case state behavior;238
13.5.1.9.6;Step 6: Verify and validate functional requirements;239
13.5.1.9.7;Step 7: Add traceability links;239
13.5.1.9.8;Step 8: Perform review;240
13.5.2;5.5.2 Scenarios-Based Use Case Analysis;240
13.5.2.1;5.5.2.1 Define the use case context;243
13.5.2.2;5.5.2.2 Define use case scenarios;243
13.5.2.3;5.5.2.3 Derive use case functional flow;244
13.5.2.4;5.5.2.4 Define ports and interfaces;246
13.5.2.5;5.5.2.5 Derive use case state machine;246
13.5.2.5.1;How much simulation fidelity do you need?;251
13.5.2.6;5.5.2.6 T-Wrecks scenario-based use case analysis;253
13.5.2.6.1;Step 1: Use case execution context;253
13.5.2.6.2;Step 2: Define use case scenarios;254
13.5.2.6.3;Step 3: Derive use case functional flow;256
13.5.2.6.4;Step 4: Define ports and interfaces;257
13.5.2.6.5;Step 5: Derive use case state behavior;259
13.5.2.6.6;Step 6: Verify and validate functional requirements;261
13.5.3;5.5.3 State-Based Use Case Analysis;262
13.5.3.1;5.5.3.1 Define the use case context;263
13.5.3.2;5.5.3.2 Derive use case state machine;264
13.5.3.3;5.5.3.3 Define use case scenarios;268
13.5.3.4;5.5.3.4 Define ports and interfaces;270
13.5.3.5;5.5.3.5 T-Wrecks state-based use case analysis;271
13.5.3.5.1;Step 1: Use case execution context;272
13.5.3.5.2;Step 2: Derive use case state behavior;272
13.5.3.5.3;Step 3: Create scenarios;274
13.5.3.5.4;Step 4: Define ports and interfaces;276
13.5.3.5.5;Step 5: Verify and validate functional requirements;277
13.6;5.6 Create/Update Logical Data Schema;278
13.7;5.7 Dependability Analysis;283
13.7.1;5.7.1 Safety Analysis;284
13.7.1.1;5.7.1.1 Reliability analysis;290
13.7.1.1.1;Steps to creating a FMEA;290
13.7.1.2;5.7.1.2 Security analysis;291
13.7.2;5.7.2 T-Wrecks Initial Dependability Analysis;297
13.7.2.1;5.7.2.1 T-Wrecks safety;297
13.7.2.2;5.7.2.2 T-Wrecks reliability;297
13.7.2.3;5.7.2.3 T-Wrecks security;299
13.8;5.8 Create/Update Verification Plan;300
13.9;5.9 Summary;301
13.10;5.10 Moving On;301
13.11;References;302
14;6 Agile Systems Architectural Analysis and Trade Studies;304
14.1;6.1 Objectives;305
14.2;6.2 Architecture Analysis Workflow;306
14.2.1;6.2.1 Identify Key System Functions;307
14.2.2;6.2.2 Define Candidate Solutions;307
14.2.3;6.2.3 Perform Architectural Trade Study;307
14.2.4;6.2.4 Merge Solutions into Systems Architecture;308
14.2.5;6.2.5 Define Assessment Criteria;309
14.2.6;6.2.6 Assign Weights to Criteria;309
14.2.7;6.2.7 Define Utility Curve for Each Criterion;309
14.2.8;6.2.8 Assign MOEs to Candidate Solutions;309
14.2.9;6.2.9 Determine the Solution;310
14.3;6.3 Assessment Methodology;310
14.3.1;6.3.1 The Easy Way;310
14.3.2;6.3.2 The High-Fidelity Way;312
14.4;6.4 Identify Key System Functions (and Properties);316
14.5;6.5 Define the Candidate Solutions;319
14.5.1;6.5.1 Speed Demon Candidate Solutions;319
14.5.2;6.5.2 T-Wrecks Candidate Solutions;320
14.5.2.1;6.5.2.1 Ultrasonic;321
14.5.2.2;6.5.2.2 Lidar scanning unit;321
14.5.2.3;6.5.2.3 Lidar rangefinder;321
14.6;6.6 Perform the Architectural Trade Study;324
14.6.1;6.6.1 Define the Assessment Criteria;324
14.6.1.1;6.6.1.1 Speed Demon;324
14.6.1.2;6.6.1.2 T-Wrecks;325
14.6.2;6.6.2 Assign Weights to the Criteria;325
14.6.3;6.6.3 Define the Utility Curve for Each Criterion;325
14.6.4;6.6.4 Assign MOEs to Candidate Solutions;328
14.6.5;6.6.5 Determine the Solution;330
14.7;6.7 Merge the Solutions into the Systems Architecture;331
14.8;6.8 Summary;333
14.9;6.9 Moving On;334
14.10;References;334
15;7 Agile Systems Architectural Design;336
15.1;7.1 Objectives;337
15.1.1;7.1.1 So … What’s a Subsystem?;337
15.1.2;7.1.2 Key Architectural Views;339
15.2;7.2 Architectural Design Workflow;341
15.2.1;7.2.1 Identify Subsystems;341
15.2.2;7.2.2 Allocate System Requirements to Subsystems;342
15.2.3;7.2.3 Allocate Use Cases to Subsystems;342
15.2.4;7.2.4 Create/Update Logical Data Schema;343
15.2.5;7.2.5 Create/Update Subsystem Requirements;343
15.2.6;7.2.6 Develop Control Laws;343
15.2.7;7.2.7 Analyze Dependability;343
15.2.8;7.2.8 Perform Review;344
15.3;7.3 Identify Subsystems;344
15.3.1;7.3.1 Speed Demon Subsystems;346
15.3.2;7.3.2 T-Wrecks Subsystems;354
15.4;7.4 Allocate System Requirements to Subsystems;358
15.5;7.5 Allocate Use Cases to Subsystems;359
15.5.1;7.5.1 Bottom-Up Allocation;360
15.5.1.1;7.5.1.1 Derive white box scenarios;360
15.5.1.2;7.5.1.2 Define subsystem ports and interfaces;361
15.5.1.3;7.5.1.3 Group services into use cases;361
15.5.2;7.5.2 Top-Down Allocation;361
15.5.2.1;7.5.2.1 Decompose use cases to subsystem level;361
15.5.2.2;7.5.2.2 Define subsystem-level scenarios;363
15.5.2.3;7.5.2.3 Define subsystem ports and interfaces;364
15.5.3;7.5.3 Common Tasks;364
15.5.3.1;7.5.3.1 Derive use case state behavior;364
15.5.3.2;7.5.3.2 Verify and validate functional requirements;364
15.5.3.3;7.5.3.3 Add traceability links;364
15.5.3.4;7.5.3.4 Perform review;365
15.5.4;7.5.4 Speed Demon Subsystem Use Case Allocation Example;365
15.5.5;7.5.5 T-Wrecks Subsystem Use Case Allocation Example;371
15.6;7.6 Create/Update Logical Data Schema;376
15.6.1;7.6.1 Speed Demon Treadmill Example;377
15.6.2;7.6.2 T-Wrecks Example;381
15.7;7.7 Create/Update Subsystem Requirements;382
15.8;7.8 Develop Control Laws;383
15.9;7.9 Analyze Dependability;385
15.9.1;7.9.1 Safety Analysis;386
15.9.2;7.9.2 Reliability Analysis;386
15.9.3;7.9.3 Security Analysis;386
15.10;7.10 Summary;386
15.11;7.11 Moving On;388
15.12;References;388
16;8 The Handoff to Downstream Engineering;390
16.1;8.1 Objectives;391
16.2;8.2 The Handoff to Downstream Engineering Workflow;391
16.2.1;8.2.1 Gather Subsystem Specification Data;391
16.2.2;8.2.2 Create the Shared Model;392
16.2.3;8.2.3 Define Subsystem Physical Interfaces;392
16.2.4;8.2.4 Create Subsystem Model;393
16.2.5;8.2.5 Define Interdisciplinary Interfaces;393
16.2.6;8.2.6 Allocation Requirements to Engineering Disciplines;393
16.3;8.3 Gather Subsystem Specification Data;394
16.3.1;8.3.1 Gathering SysML Model Data;394
16.3.2;8.3.2 Gathering Other Engineering Data;395
16.4;8.4 Create the Shared Model;396
16.4.1;8.4.1 Organizing the Shared Model;396
16.5;8.5 Define Subsystem Physical Interfaces;398
16.5.1;8.5.1 Creating Physical Specifications from Logical Specifications;398
16.5.1.1;8.5.1.1 Refine the logical service into a physical service;402
16.5.1.2;8.5.1.2 Refine the data schema;402
16.5.1.3;8.5.1.3 Refine the constraints;402
16.5.1.4;8.5.1.4 Put the physical interface and data into the shared model;402
16.5.2;8.5.2 Speed Demon Interface Example;402
16.5.3;8.5.3 T-Wrecks Interface Example;405
16.6;8.6 Create Subsystem Model;409
16.7;8.7 Define Interdisciplinary Interfaces;411
16.7.1;8.7.1 Speed Demon Example: Control Unit Subsystem Interface Specification;412
16.7.2;8.7.2 T-Wrecks Example;414
16.7.2.1;8.7.2.1 The Coordination subsystem;414
16.7.2.2;8.7.2.2 The Limb Assembly subsystem;416
16.8;8.8 Allocation Requirements to Engineering Disciplines;420
16.8.1;8.8.1 Speed Demon Example;420
16.8.2;8.8.2 T-Wrecks Example;420
16.9;8.9 And Downstream Engineering Begins;425
16.10;8.10 And System Engineering Continues …;428
16.11;References;429
17;Appendix A: T-Wrecks Stakeholder Requirements;430
17.1;Project Overview;430
17.2;T-Wrecks High Level Use Cases;430
17.3;General Requirements;431
17.4;Encase Use Case;431
17.5;Balance Use Case;431
17.6;Walk Use Case;431
17.7;Monitor System Use Case;431
17.8;Move Limbs Use Case;432
17.9;Manage Power Use Case;432
17.10;Startup Use Case;432
17.11;Self Test Use Case;433
17.12;Provide Visibility Use Case;433
17.13;Monitor System Use Case;433
17.14;Shutdown Use Case;433
17.15;Proximity Detection Use Case;433
17.16;Configure Use Case;433
17.17;Communicate Use Case;434
18;Appendix B: T-Wrecks System Requirements;436
18.1;T-Wrecks High Level Use Cases;436
18.2;Requirements Table (Initial Set);437
19;Index;442
20;Back Cover;453

Leseproben

Chapter 2

What Are Agile Methods and Why Should I Care?

Chapter 2 introduces agile methods and their application to systems engineering. Although agile methods arose in IT software development, they have begun to be applied——with good success—in other engineering disciplines as well. In order to understand how best to apply them to systems engineering, a good understanding of the basic agile concepts, methods, and approaches is necessary. This chapter outlines the Agile Manifesto and restates it to be more relevant to systems engineering, including identifying the important measure of success—verified engineering data. The benefits of agile approaches are explained with an emphasis on the difference it can make to systems engineers. Key methodological approaches—incremental engineering, dynamic planning, continuous verification (of engineering data), continuous integration, and so on—are all explained in the context of systems engineering.

The chapter highlights the key agile best practices for improving quality and efficiency in systems engineering and then outlines the Harmony Agile Model-Based Systems Engineering (Harmony aMBSE) process that integrates those best practices into a coherent approach.

Keywords

Agile; harmony agile MBSE process; agile best practices; agile systems engineering

Chapter Outline

2.1 The Agile Manifesto 43

2.2 Benefits of Agile Methods 46

2.3 Applying the Agile Manifesto to Systems Engineering 48

2.3.1 Work Incrementally 48

2.3.2 Plan Dynamically 49

2.3.3 Actively Reduce Project Risk 50

2.3.4 Verify Constantly 51

2.3.5 Integrate Continuously 51

2.3.6 Use Case 1: Find Tracks in Airspace 52

2.3.7 Use Case 2: Perform Periodic Built in Test (PBIT) 52

2.3.8 Validate Frequently 53

2.3.9 Modeling Is for aMBSE 53

2.4 Agile Best Practices for Systems Engineering 53

2.4.1 Incremental Development of Work Products 53

2.4.2 Continual Verification of Work Products 54

2.4.3 Executable Requirements Models 55

2.4.4 Model-Based Specification Linked to Textual Specification 56

2.4.5 Continuous Dependability Assessment 58

2.4.6 Active Project Risk Management 59

2.4.7 Model-Based Hand Off to Downstream Engineering 61

2.4.8 Dynamic Planning 61

2.5 Putting It All Together: The Harmony Agile MBSE (aMBSE) Process 63

2.5.1 Initiate Project 66

2.5.2 Define Stakeholder Requirements 68

2.5.3 System Requirements Definition and Analysis 70

2.5.4 Approach 1: Flow-based Use Case Analysis 71

2.5.5 Approach 2: Scenario-based Use Case Analysis 72

2.5.6 Approach 3: State-based Use Case Analysis 72

2.5.7 Architectural Analysis 74

2.5.8 Architectural Design 74

2.5.9 Perform Iteration Retrospective 79

2.5.10 Handoff to Downstream Engineering 79

2.5.11 Control Project 81

2.5.12 Perform Quality Assurance Audits 82

2.5.13 Manage Change 82

2.6 Summary 83

References 84

Agile methods are largely a response to increasing regimentation of software development and work that was only tangentially related to the development of the software itself. It is also a reaction to the fact that despite the burden of this additional work, the quality of the software is low and the software far too often doesn’t meet the needs of its intended users. Although agile was originally conceived for small software projects, we will see that there is much to recommend it for other endeavors, including (and of great interest here) systems engineering.

From an overview perspective, agile methods are really about optimizing development along two dimensions—product quality and engineering efficiency. Many people think it’s about what you DON’T do—you DON’T plan, document, fill out paper work, design, analyze, or create requirements. In actuality, agile is more about what you DO and the order in which you do them. Agile methods are meant to be adaptive and responsive to different situations and changing needs using objective evidence to guide how work it done.

Put another way, it isn’t so much that you do different things when you do agile methods as much as the order and sequence of those things is changed. This facilitates early feedback as to the correctness and adequacy of the work and work products you create. For example, traditional methods1 do a “breadth-first” approach to creating work products and defer the verification of those work products at least until they are complete, and often much later. Agile, on the other hand, incrementally verifies the work products as they are being created. That provides more immediate feedback as to the correctness of the work product and how well your process is helping you achieve your engineering goals.

I liken the agile approach to dental hygiene. Imagine that you want to ensure your “tooth quality” by applying the “tooth brushing quality step.” Because you view this as important, at the end of every year, on December 31, you do a good and thorough job of brushing your teeth and verifying their quality, and then going to a dentist for tooth quality problem remediation. Much to your dismay, your tooth quality is pretty low and requires extraordinary measures (and no small amount of discomfort) to bring the quality up. That is how the traditional approach works with deferred verification.

Imagine instead performing this quality improvement and assessment step immediately after using your teeth (i.e., after meals). Through constant application of quality methods, the quality of your teeth remains high throughout the year. This is a more hygienic approach and avoids big quality problems more than identifying them late for defect removal. In either case, you’re performing quality assurance activities to both improve and verify quality but what is different is those activities are performed. Agile methods perform quality assurance activities throughout the development of important work products rather than after they are completed. That is, when these activities are performed, we optimize defect avoidance rather than defect identification.

Oh, and Agilistas DO plan, document, fill out paper work, design, analyze, and create requirements. We’ll talk about how those activities can be done in an agile systems engineering environment in some detail in this book.

2.1 The Agile Manifesto

A good place to start to understand agile methods is with the agile manifesto.2 The manifesto is a public declaration of intent by the Agile Alliance, consisting of 17 signatories including Kent Beck, Martin Fowler, Ron Jeffries, Robert Martin, and others. Originally drafted in 2001, this manifesto is summed up in four key statements:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan.

A thing to note about the manifesto is that it states an emphasis, not an exclusion. We emphasize working software over documentation, but that doesn’t mean that we don’t write documentation. We emphasize responsiveness to change over dogmatically following a plan, but that doesn’t mean that we don’t plan. The point is to pay more attention to the things that really matter. Paying attention to meeting the customer’s needs and creating correct software is more important than following the plan and writing the documentation, but it doesn’t mean that these other aspects don’t get any attention at all.

To support the statements of the manifesto, the Agile Alliance give a set of 12 principles. I’ll state them here to set the context of the following discussion:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

• Business people and developers must work together daily throughout the project.

• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

• The most efficient and effective method of conveying...