Systems Engineering of Software-Enabled Systems

RICHARD E. FAIRLEY, PHD, He has been a tenured professor of computer science and software systems engineering, a department chair, an associate dean, and a dean. He founded, and for several years, was the fulltime principal associate of Software and Systems Engineering Associates (S2EA), a consulting and training company. He is the author of the Wiley title Managing and Leading Software Projects.

• Preface xvPart I Systems Engineering and Software Engineering 11 Introduction and Overview 31.1 Introduction 31.2 The Evolution of Engineering 51.3 Characterizations of Systems 81.3.1 Open and Closed Systems 91.3.2 Static and Dynamic Systems 91.3.3 System Boundaries 101.3.4 Naturally Occurring Systems 121.3.5 Engineered Systems 131.3.6 Systems of Systems 171.4 Systems Engineering 181.4.1 The Systems Engineering Profession 191.5 Applications of Systems Engineering 211.5.1 Systems Engineering of Products 231.5.2 Systems Engineering of Service Provision 231.5.3 Systems Engineering for Enterprises 231.5.4 Systems Engineering for Systems of Systems 231.6 Specialty Engineering 241.7 Related Disciplines 251.7.1 Industrial Engineering 251.7.2 Project Management 261.8 Software Engineering 261.8.1 The Software Engineering Profession 271.9 Applications of Software Engineering 271.9.1 Application Packages 281.9.2 System Software and Software Utilities 281.9.3 Software Tools 291.9.4 Software-Intensive Systems 291.9.5 Software-Enabled Systems 291.10 Physical Systems Engineers and Software Systems Engineers 291.11 Key Points 31Exercises 32References 342 Systems Engineering and Software Engineering 372.1 Introduction 372.2 Categories of Systems 372.3 Common Attributes of PhSEs and SwSEs 392.4 Ten Things PhSEs Need to Know About Software and Software Engineering 402.4.1 Systems Engineering and Software Engineering are Distinct Disciplines 412.4.2 Software is a Logical Medium 412.4.3 Exhaustive Testing of Software is Not Feasible 432.4.4 Software is Highly Complex 442.4.5 Software Conformity Must Be Exact 452.4.6 Software is an Invisible Medium 472.4.7 Software Appears to Be Easily Changed 482.4.8 Software Development is a Team-Oriented, Intellect-Intensive Endeavor 492.4.9 Software Developers use Mostly Iterative Processes 522.4.10 Software Engineering Metrics and Models are Different in Kind 542.5 Ten Things Software Engineers Need to Know About Systems Engineering 552.5.1 Most PhSEs Have Traditional Engineering Backgrounds 552.5.2 Systems Engineers’Work Activities are Technical and Managerial 562.5.3 The Scope of Systems Engineering Work is Diverse 562.5.4 Systems Engineers Apply Holistic and Reductionist Thinking 572.5.5 Systems Engineering Covers the Full Spectrum of Life-Cycle Processes 572.5.6 System Engineers Plan and Coordinate the Work of Interdisciplinary Teams 602.5.7 Current Systems Engineering Development Processes are Mostly Incremental 612.5.8 Systems Engineering is Transitioning to a Model-Based Approach 612.5.9 Some Who Perform Systems Engineering Tasks are Not Called Systems Engineers 622.5.10 Most PhSEs View Software Engineers as Disciplinary Engineers or Specialty Engineers 622.6 Key Points 63Exercises 63References 653 Issues and Opportunities for Improvements 673.1 Introduction 673.2 Some Background 673.3 Professional Literacy 693.3.1 System Engineering Literacy 693.3.1.1 Opportunities for Improving Systems Engineering Literacy of Systems Engineers and Software Engineers 703.3.2 Software Engineering Literacy 723.3.2.1 Opportunities for Improving Software Engineering Literacy of Systems Engineers and Software Engineers 733.4 Differences in Terminology 763.4.1 Hierarchical Decomposition 763.4.1.1 System Hierarchy 773.4.1.2 Software Hierarchy 783.4.2 UML Classes and SysML Blocks 793.4.3 Performance 803.4.4 Prototype 803.4.5 Model-Based Engineering 813.4.6 Implementation, Construction, and Realization 823.4.7 Specialty Engineering and Supporting Processes 833.4.8 Opportunities for Improving Usage of Terminology 843.5 Differences in Problem-Solving Styles 843.5.1 Opportunities for Improving Styles of Problem Solving 863.6 Holistic and Reductionist Problem Solving 883.6.1 Opportunities for Improving Holistic and Reductionist Thinking 893.7 Logical and Physical Design 893.7.1 Opportunities for Improving Logical Design and Physical Design Activities 903.8 Differences in Process Models and Technical Processes 913.8.1 Opportunities for Improving Process Models and Technical Processes 913.9 Workplace Respect 913.9.1 Opportunities for Improving Workplace Respect 923.10 Key Points 93Exercises 94References 95Part II Systems Engineering for Software-Enabled Physical Systems 974 Traditional Process Models for System Development 994.1 Introduction 994.2 Characteristics of Physical Elements and Software Elements 1004.3 Development Process Foundations 1044.4 Linear and Vee Development Models 1064.4.1 The Linear One-Pass Development Model 1074.4.2 A Linear-Revisions Development Model 1084.4.3 The Vee Development Model 1084.4.4 Incremental Vee Development Models 1094.5 Iterative Development Models 1114.5.1 Iterative Fabrication of Physical Elements 1114.5.2 Iterative Construction of Software Elements 1124.6 The ATM Revisited 1154.7 Key Points 116Exercises 117References 1185 The Integrated-Iterative-Incremental System Development Model 1215.1 Introduction 1215.2 Capabilities-Based System Development 1215.2.1 Issues and Ameliorations 1285.3 The I3 System Development Model 1295.3.1 Systems Engineering During the I3 System Development Phases 1305.3.2 Synchronizing Realization of Physical Elements and Software Elements 1345.3.3 Mapping the I3 Development Model to the Technical Processes of 15288 and 12207 1355.4 Key Points 137Exercises 139References 1406 The I3 System Definition Phase 1416.1 Introduction 1416.2 Performing Business or Mission Analysis 1416.2.1 Business Analysis for the RC-DSS Project 1456.2.2 RFPs, SOWs, and MOUs 1466.2.2.1 An RC-DSS MOU 1476.3 Identifying Stakeholders’ Needs and Defining Their Requirements 1496.3.1 Identifying System Stakeholders 1506.3.1.1 Some Clarifying Terminology 1516.3.1.2 Identifying RC-DSS Stakeholders 1536.3.2 Eliciting, Categorizing, and Prioritizing Stakeholder Requirements 1546.3.2.1 Eliciting Stakeholders’ Requirement 1546.3.2.2 Categorizing Stakeholders’ Requirements 1556.3.2.3 Prioritizing Stakeholders’ Requirements 1576.3.3 Defining RC-DSS Stakeholders’ Requirements 1586.3.3.1 Specifying RC-DSS User Features 1586.3.3.2 Specifying RC-DSS Quality Attributes 1626.3.3.3 Specifying RC-DSS Design Constraints 1626.3.4 The Concept of Operations 1636.3.4.1 The RC-DSS ConOps 1636.4 Identifying and Prioritizing System Capabilities 1656.4.1 Identifying RC-DSS System Capabilities 1656.4.2 Prioritizing RC-DSS Capabilities 1666.5 Determining Technical Feasibility 1676.5.1 Determining RC-DSS Technical Feasibility 1686.6 Establishing and Maintaining Traceability 1706.7 Key Points 170Exercises 171References 1727 System Requirements Definition 1757.1 Introduction 1757.2 The System Requirements Definition Process 1777.3 A Requirements Taxonomy 1787.3.1 Stakeholders’ Requirements and System Capabilities 1787.3.2 System Requirements 1807.3.2.1 Primary System Requirements 1807.3.2.2 Derived System Requirements 1817.3.2.3 System Design Constraints 1827.3.2.4 System Design Goals 1827.3.2.5 System Quality Requirements 1837.3.2.6 System Interface Requirements 1847.4 Verifying and Validating System Requirements 1877.4.1 Verifying System Requirements 1887.4.1.1 Verifying Implementation Feasibility 1897.4.1.2 Verifying Coverage of System Capabilities 1897.4.2 Validating System Requirements 1937.5 System Requirements for the RC-DSS Case Study 1957.5.1 RC-DSS Operational Requirements 1957.6 Key Points 196Exercises 197References 1998 Architecture Definition and Design Definition 2018.1 Introduction 2018.2 Principles of Architecture Definition 2028.2.1 Activities of Architecture Definition 2058.3 Defining System Architectures 2058.3.1 Defining System Structure 2068.3.1.1 Allocating System Requirements to System Architecture 2078.3.2 Defining System Behavior 2088.3.2.1 Analyzing System Behavior 2098.4 Architecture Evaluation Criteria 2108.5 Selecting the Architecture 2128.6 Principles of Design Definition 2138.6.1 Design Evaluation Criteria 2148.6.2 Logical Design and Physical Design 2158.6.3 Activities of Design Definition 2158.6.4 Buying or Building 2178.6.5 Verifying and Validating the System Design 2188.7 RC-DSS Architecture Definition 2218.7.1 RC-DSS Architecture Evaluation 2258.7.2 RC-DSS Interface Definition 2268.8 RC-DSS Design Definition 2278.9 Controlling the Complexity of System Architecture and System Design 2288.10 Key Points 231Exercises 2328.A The System Modeling Language (SysML) 2338.A.1 SysML Structure Diagrams 2348.A.2 SysML Behavior Diagrams 2358.A.3 SysML Crosscutting Diagrams 238References 2399 SystemImplementation and Delivery 2419.1 Introduction 2419.2 I3 Phases 5 and 6 2419.3 I3 System Implementation 2449.3.1 Subphase Planning 2509.3.2 Realization, Integration, Verification, and Validation of System Capabilities 2529.4 I3 System Delivery 2529.5 Key Points 253Exercises 254References 255Part III Technical Management of Systems Engineering 25710 Planning and Estimating the Technical Work 25910.1 Introduction 25910.2 Documenting the Technical Work Plan (SEMP) 26010.2.1 Documenting Other Technical Processes 26210.2.2 Developing the Initial Plan 26710.3 The Estimation Process 26810.3.1 An Inverse Estimation Process 27110.3.2 Making an Initial Estimate 27210.4 Estimation Techniques 27310.4.1 Rule of Thumb Estimation 27310.4.2 Estimation by Analogy 27410.4.3 Expert Judgment 27510.4.4 The Delphi Method 27610.4.5 Wideband Delphi Estimation 27710.4.6 Regression-Based Estimation Models 27810.4.7 Monte Carlo Estimation 27910.4.8 Bottom-Up Estimation 28110.5 Documenting an Estimate 28310.5.1 An Estimation Template 28610.6 Key Points 287Exercises 288References 28911 Assessing, Analyzing, and Controlling Technical Work 29111.1 Introduction 29111.2 Assessing and Analyzing Process Parameters 29211.2.1 Assessing and Analyzing Effort 29311.2.2 Assessing and Analyzing Binary Progress 29511.2.3 Estimating Future Status 29711.2.4 Assessing and Analyzing Technical Debt 29911.2.5 Assessing and Analyzing Earned Value 30111.2.6 Assessing and Controlling Risk 30711.3 Assessing and Analyzing System Parameters 31611.3.1 Direct and Indirect Measures 31911.3.2 Surrogate Measures 32111.3.3 Technical Performance Measurement 32111.4 Corrective Action 32211.4.1 Acceptable Corrective Action 32211.4.2 Unacceptable Corrective Action 32311.4.3 Inhibitors of Corrective Action 32311.5 Key Points 325Exercises 227References 32812 Organizing, Leading, and Coordinating 32912.1 Introduction 32912.2 Managing Versus Leading 33012.3 The Influence of Corporate Culture 33112.4 Responsibility and Authority 33412.4.1 Responsibility 33412.4.2 Authority 33412.5 Teams and Teamwork 33512.5.1 Lone Wolves 33612.5.2 Teamicide 33712.5.2.1 Defensive Management 33712.5.2.2 Mindless Bureaucracy 33812.5.2.3 Unrealistic Deadlines 33912.5.2.4 Physical Separation 33912.5.2.5 Fragmentation of Time 34012.5.2.6 Clique Control 34112.5.2.7 Quality Reduction 34112.6 Maintaining Motivation and Morale 34212.7 Can’t Versus Won’t 34412.8 Fourteen Guidelines for Organizing and Leading Engineering Teams 34512.8.1 Use the Best People You Can Find 34612.8.1.1 Develop a Key Personnel Plan 34712.8.2 Treat Engineers as Assets Rather than Costs 34912.8.3 Provide a Balance Between Job Specialization and Job Variety 34912.8.4 Keep Team Members Together 34912.8.5 Limit the Size of Each Team 35012.8.6 Differentiate the Role of Team Leader 35112.8.7 Each Team Leader Should Be the Team’s Quality Control Agent 35112.8.8 Safeguard Individual Productivity and Quality Data 35212.8.9 Decompose Tasks into Manageable Units of Work 35312.8.10 Set Performance Goals for Each Team 35312.8.11 Adopt a Contractual Model for Commitments 35412.8.12 Ensure Daily Interactions with Team Leaders and Team Members 35512.8.13 Conduct Weekly Status Review Meetings 35512.8.13.1 Maintain Weekly Top-N Lists at All Levels of a Systems Project 35612.8.13.2 Conduct Retrospective and Planning Meetings 35912.8.14 Structure Large Projects as Collections of Highly Cohesive, Loosely Coupled Small Projects 35912.8.14.1 A Rule of Thumb 36012.9 Summary of the Guidelines 36212.10 Key Points 363Exercises 364References 365Appendix A The Northwest Hydroelectric System 367A.1 Background 367A.2 Purpose 369A.3 Challenges 371A.4 Systems Engineering Practices 372A.4.1 Product Provisioning 372A.4.2 Service Provisioning 373A.4.3 Enterprise Provisioning 374A.4.4 System-of-Systems Provisioning 374A.5 Lessons Learned 375References 375Appendix B Automobile Embedded Real-Time Systems 377B.1 Introduction 377B.2 Electronic Control Units 378B.3 ECU Domains 382B.4 The Powertrain Domain (Engine and Transmission) 383B.5 The Chassis Domain 384B.6 The Body Domain 384B.7 The Infotainment Domain 385B.8 An Emerging Domain 385B.9 The ECU Network 386B.10 Automotive Network Domains 386B.11 Network Protocols 387B.12 Summary 388References 389Glossary of Terms 391Index 397