Description
Book SynopsisA comprehensive review of the life cycle processes, methods, and techniques used to develop and modify software-enabled systems
Systems Engineering of Software-Enabled Systemsoffers an authoritative review of the most current methods and techniques that can improve the links between systems engineering and software engineering. The authora noted expert on the topicoffers an introduction to systems engineering and software engineering and presents the issues caused by the differences between the two during development process. The book reviews the traditional approaches used by systems engineers and software engineers and explores how they differ.
The book presents an approach to developing software-enabled systems that integrates the incremental approach used by systems engineers and the iterative approach used by software engineers. This unique approach is based on developing system capabilities that will provide the features, behaviors, and quality attr
Table of Contents
Preface xv
Part I Systems Engineering and Software Engineering 1
1 Introduction and Overview 3
1.1 Introduction 3
1.2 The Evolution of Engineering 5
1.3 Characterizations of Systems 8
1.3.1 Open and Closed Systems 9
1.3.2 Static and Dynamic Systems 9
1.3.3 System Boundaries 10
1.3.4 Naturally Occurring Systems 12
1.3.5 Engineered Systems 13
1.3.6 Systems of Systems 17
1.4 Systems Engineering 18
1.4.1 The Systems Engineering Profession 19
1.5 Applications of Systems Engineering 21
1.5.1 Systems Engineering of Products 23
1.5.2 Systems Engineering of Service Provision 23
1.5.3 Systems Engineering for Enterprises 23
1.5.4 Systems Engineering for Systems of Systems 23
1.6 Specialty Engineering 24
1.7 Related Disciplines 25
1.7.1 Industrial Engineering 25
1.7.2 Project Management 26
1.8 Software Engineering 26
1.8.1 The Software Engineering Profession 27
1.9 Applications of Software Engineering 27
1.9.1 Application Packages 28
1.9.2 System Software and Software Utilities 28
1.9.3 Software Tools 29
1.9.4 Software-Intensive Systems 29
1.9.5 Software-Enabled Systems 29
1.10 Physical Systems Engineers and Software Systems Engineers 29
1.11 Key Points 31
Exercises 32
References 34
2 Systems Engineering and Software Engineering 37
2.1 Introduction 37
2.2 Categories of Systems 37
2.3 Common Attributes of PhSEs and SwSEs 39
2.4 Ten Things PhSEs Need to Know About Software and Software Engineering 40
2.4.1 Systems Engineering and Software Engineering are Distinct Disciplines 41
2.4.2 Software is a Logical Medium 41
2.4.3 Exhaustive Testing of Software is Not Feasible 43
2.4.4 Software is Highly Complex 44
2.4.5 Software Conformity Must Be Exact 45
2.4.6 Software is an Invisible Medium 47
2.4.7 Software Appears to Be Easily Changed 48
2.4.8 Software Development is a Team-Oriented, Intellect-Intensive Endeavor 49
2.4.9 Software Developers use Mostly Iterative Processes 52
2.4.10 Software Engineering Metrics and Models are Different in Kind 54
2.5 Ten Things Software Engineers Need to Know About Systems Engineering 55
2.5.1 Most PhSEs Have Traditional Engineering Backgrounds 55
2.5.2 Systems Engineers’Work Activities are Technical and Managerial 56
2.5.3 The Scope of Systems Engineering Work is Diverse 56
2.5.4 Systems Engineers Apply Holistic and Reductionist Thinking 57
2.5.5 Systems Engineering Covers the Full Spectrum of Life-Cycle Processes 57
2.5.6 System Engineers Plan and Coordinate the Work of Interdisciplinary Teams 60
2.5.7 Current Systems Engineering Development Processes are Mostly Incremental 61
2.5.8 Systems Engineering is Transitioning to a Model-Based Approach 61
2.5.9 Some Who Perform Systems Engineering Tasks are Not Called Systems Engineers 62
2.5.10 Most PhSEs View Software Engineers as Disciplinary Engineers or Specialty Engineers 62
2.6 Key Points 63
Exercises 63
References 65
3 Issues and Opportunities for Improvements 67
3.1 Introduction 67
3.2 Some Background 67
3.3 Professional Literacy 69
3.3.1 System Engineering Literacy 69
3.3.1.1 Opportunities for Improving Systems Engineering Literacy of Systems Engineers and Software Engineers 70
3.3.2 Software Engineering Literacy 72
3.3.2.1 Opportunities for Improving Software Engineering Literacy of Systems Engineers and Software Engineers 73
3.4 Differences in Terminology 76
3.4.1 Hierarchical Decomposition 76
3.4.1.1 System Hierarchy 77
3.4.1.2 Software Hierarchy 78
3.4.2 UML Classes and SysML Blocks 79
3.4.3 Performance 80
3.4.4 Prototype 80
3.4.5 Model-Based Engineering 81
3.4.6 Implementation, Construction, and Realization 82
3.4.7 Specialty Engineering and Supporting Processes 83
3.4.8 Opportunities for Improving Usage of Terminology 84
3.5 Differences in Problem-Solving Styles 84
3.5.1 Opportunities for Improving Styles of Problem Solving 86
3.6 Holistic and Reductionist Problem Solving 88
3.6.1 Opportunities for Improving Holistic and Reductionist Thinking 89
3.7 Logical and Physical Design 89
3.7.1 Opportunities for Improving Logical Design and Physical Design Activities 90
3.8 Differences in Process Models and Technical Processes 91
3.8.1 Opportunities for Improving Process Models and Technical Processes 91
3.9 Workplace Respect 91
3.9.1 Opportunities for Improving Workplace Respect 92
3.10 Key Points 93
Exercises 94
References 95
Part II Systems Engineering for Software-Enabled Physical Systems 97
4 Traditional Process Models for System Development 99
4.1 Introduction 99
4.2 Characteristics of Physical Elements and Software Elements 100
4.3 Development Process Foundations 104
4.4 Linear and Vee Development Models 106
4.4.1 The Linear One-Pass Development Model 107
4.4.2 A Linear-Revisions Development Model 108
4.4.3 The Vee Development Model 108
4.4.4 Incremental Vee Development Models 109
4.5 Iterative Development Models 111
4.5.1 Iterative Fabrication of Physical Elements 111
4.5.2 Iterative Construction of Software Elements 112
4.6 The ATM Revisited 115
4.7 Key Points 116
Exercises 117
References 118
5 The Integrated-Iterative-Incremental System Development Model 121
5.1 Introduction 121
5.2 Capabilities-Based System Development 121
5.2.1 Issues and Ameliorations 128
5.3 The I3 System Development Model 129
5.3.1 Systems Engineering During the I3 System Development Phases 130
5.3.2 Synchronizing Realization of Physical Elements and Software Elements 134
5.3.3 Mapping the I3 Development Model to the Technical Processes of 15288 and 12207 135
5.4 Key Points 137
Exercises 139
References 140
6 The I3 System Definition Phase 141
6.1 Introduction 141
6.2 Performing Business or Mission Analysis 141
6.2.1 Business Analysis for the RC-DSS Project 145
6.2.2 RFPs, SOWs, and MOUs 146
6.2.2.1 An RC-DSS MOU 147
6.3 Identifying Stakeholders’ Needs and Defining Their Requirements 149
6.3.1 Identifying System Stakeholders 150
6.3.1.1 Some Clarifying Terminology 151
6.3.1.2 Identifying RC-DSS Stakeholders 153
6.3.2 Eliciting, Categorizing, and Prioritizing Stakeholder Requirements 154
6.3.2.1 Eliciting Stakeholders’ Requirement 154
6.3.2.2 Categorizing Stakeholders’ Requirements 155
6.3.2.3 Prioritizing Stakeholders’ Requirements 157
6.3.3 Defining RC-DSS Stakeholders’ Requirements 158
6.3.3.1 Specifying RC-DSS User Features 158
6.3.3.2 Specifying RC-DSS Quality Attributes 162
6.3.3.3 Specifying RC-DSS Design Constraints 162
6.3.4 The Concept of Operations 163
6.3.4.1 The RC-DSS ConOps 163
6.4 Identifying and Prioritizing System Capabilities 165
6.4.1 Identifying RC-DSS System Capabilities 165
6.4.2 Prioritizing RC-DSS Capabilities 166
6.5 Determining Technical Feasibility 167
6.5.1 Determining RC-DSS Technical Feasibility 168
6.6 Establishing and Maintaining Traceability 170
6.7 Key Points 170
Exercises 171
References 172
7 System Requirements Definition 175
7.1 Introduction 175
7.2 The System Requirements Definition Process 177
7.3 A Requirements Taxonomy 178
7.3.1 Stakeholders’ Requirements and System Capabilities 178
7.3.2 System Requirements 180
7.3.2.1 Primary System Requirements 180
7.3.2.2 Derived System Requirements 181
7.3.2.3 System Design Constraints 182
7.3.2.4 System Design Goals 182
7.3.2.5 System Quality Requirements 183
7.3.2.6 System Interface Requirements 184
7.4 Verifying and Validating System Requirements 187
7.4.1 Verifying System Requirements 188
7.4.1.1 Verifying Implementation Feasibility 189
7.4.1.2 Verifying Coverage of System Capabilities 189
7.4.2 Validating System Requirements 193
7.5 System Requirements for the RC-DSS Case Study 195
7.5.1 RC-DSS Operational Requirements 195
7.6 Key Points 196
Exercises 197
References 199
8 Architecture Definition and Design Definition 201
8.1 Introduction 201
8.2 Principles of Architecture Definition 202
8.2.1 Activities of Architecture Definition 205
8.3 Defining System Architectures 205
8.3.1 Defining System Structure 206
8.3.1.1 Allocating System Requirements to System Architecture 207
8.3.2 Defining System Behavior 208
8.3.2.1 Analyzing System Behavior 209
8.4 Architecture Evaluation Criteria 210
8.5 Selecting the Architecture 212
8.6 Principles of Design Definition 213
8.6.1 Design Evaluation Criteria 214
8.6.2 Logical Design and Physical Design 215
8.6.3 Activities of Design Definition 215
8.6.4 Buying or Building 217
8.6.5 Verifying and Validating the System Design 218
8.7 RC-DSS Architecture Definition 221
8.7.1 RC-DSS Architecture Evaluation 225
8.7.2 RC-DSS Interface Definition 226
8.8 RC-DSS Design Definition 227
8.9 Controlling the Complexity of System Architecture and System Design 228
8.10 Key Points 231
Exercises 232
8.A The System Modeling Language (SysML) 233
8.A.1 SysML Structure Diagrams 234
8.A.2 SysML Behavior Diagrams 235
8.A.3 SysML Crosscutting Diagrams 238
References 239
9 SystemImplementation and Delivery 241
9.1 Introduction 241
9.2 I3 Phases 5 and 6 241
9.3 I3 System Implementation 244
9.3.1 Subphase Planning 250
9.3.2 Realization, Integration, Verification, and Validation of System Capabilities 252
9.4 I3 System Delivery 252
9.5 Key Points 253
Exercises 254
References 255
Part III Technical Management of Systems Engineering 257
10 Planning and Estimating the Technical Work 259
10.1 Introduction 259
10.2 Documenting the Technical Work Plan (SEMP) 260
10.2.1 Documenting Other Technical Processes 262
10.2.2 Developing the Initial Plan 267
10.3 The Estimation Process 268
10.3.1 An Inverse Estimation Process 271
10.3.2 Making an Initial Estimate 272
10.4 Estimation Techniques 273
10.4.1 Rule of Thumb Estimation 273
10.4.2 Estimation by Analogy 274
10.4.3 Expert Judgment 275
10.4.4 The Delphi Method 276
10.4.5 Wideband Delphi Estimation 277
10.4.6 Regression-Based Estimation Models 278
10.4.7 Monte Carlo Estimation 279
10.4.8 Bottom-Up Estimation 281
10.5 Documenting an Estimate 283
10.5.1 An Estimation Template 286
10.6 Key Points 287
Exercises 288
References 289
11 Assessing, Analyzing, and Controlling Technical Work 291
11.1 Introduction 291
11.2 Assessing and Analyzing Process Parameters 292
11.2.1 Assessing and Analyzing Effort 293
11.2.2 Assessing and Analyzing Binary Progress 295
11.2.3 Estimating Future Status 297
11.2.4 Assessing and Analyzing Technical Debt 299
11.2.5 Assessing and Analyzing Earned Value 301
11.2.6 Assessing and Controlling Risk 307
11.3 Assessing and Analyzing System Parameters 316
11.3.1 Direct and Indirect Measures 319
11.3.2 Surrogate Measures 321
11.3.3 Technical Performance Measurement 321
11.4 Corrective Action 322
11.4.1 Acceptable Corrective Action 322
11.4.2 Unacceptable Corrective Action 323
11.4.3 Inhibitors of Corrective Action 323
11.5 Key Points 325
Exercises 227
References 328
12 Organizing, Leading, and Coordinating 329
12.1 Introduction 329
12.2 Managing Versus Leading 330
12.3 The Influence of Corporate Culture 331
12.4 Responsibility and Authority 334
12.4.1 Responsibility 334
12.4.2 Authority 334
12.5 Teams and Teamwork 335
12.5.1 Lone Wolves 336
12.5.2 Teamicide 337
12.5.2.1 Defensive Management 337
12.5.2.2 Mindless Bureaucracy 338
12.5.2.3 Unrealistic Deadlines 339
12.5.2.4 Physical Separation 339
12.5.2.5 Fragmentation of Time 340
12.5.2.6 Clique Control 341
12.5.2.7 Quality Reduction 341
12.6 Maintaining Motivation and Morale 342
12.7 Can’t Versus Won’t 344
12.8 Fourteen Guidelines for Organizing and Leading Engineering Teams 345
12.8.1 Use the Best People You Can Find 346
12.8.1.1 Develop a Key Personnel Plan 347
12.8.2 Treat Engineers as Assets Rather than Costs 349
12.8.3 Provide a Balance Between Job Specialization and Job Variety 349
12.8.4 Keep Team Members Together 349
12.8.5 Limit the Size of Each Team 350
12.8.6 Differentiate the Role of Team Leader 351
12.8.7 Each Team Leader Should Be the Team’s Quality Control Agent 351
12.8.8 Safeguard Individual Productivity and Quality Data 352
12.8.9 Decompose Tasks into Manageable Units of Work 353
12.8.10 Set Performance Goals for Each Team 353
12.8.11 Adopt a Contractual Model for Commitments 354
12.8.12 Ensure Daily Interactions with Team Leaders and Team Members 355
12.8.13 Conduct Weekly Status Review Meetings 355
12.8.13.1 Maintain Weekly Top-N Lists at All Levels of a Systems Project 356
12.8.13.2 Conduct Retrospective and Planning Meetings 359
12.8.14 Structure Large Projects as Collections of Highly Cohesive, Loosely Coupled Small Projects 359
12.8.14.1 A Rule of Thumb 360
12.9 Summary of the Guidelines 362
12.10 Key Points 363
Exercises 364
References 365
Appendix A The Northwest Hydroelectric System 367
A.1 Background 367
A.2 Purpose 369
A.3 Challenges 371
A.4 Systems Engineering Practices 372
A.4.1 Product Provisioning 372
A.4.2 Service Provisioning 373
A.4.3 Enterprise Provisioning 374
A.4.4 System-of-Systems Provisioning 374
A.5 Lessons Learned 375
References 375
Appendix B Automobile Embedded Real-Time Systems 377
B.1 Introduction 377
B.2 Electronic Control Units 378
B.3 ECU Domains 382
B.4 The Powertrain Domain (Engine and Transmission) 383
B.5 The Chassis Domain 384
B.6 The Body Domain 384
B.7 The Infotainment Domain 385
B.8 An Emerging Domain 385
B.9 The ECU Network 386
B.10 Automotive Network Domains 386
B.11 Network Protocols 387
B.12 Summary 388
References 389
Glossary of Terms 391
Index 397
