Cover
Preface
Part I: Systems Engineering and Software Engineering
1. 1 Introduction and Overview
  1. 1.1 Introduction
  2. 1.2 The Evolution of Engineering
  3. 1.3 Characterizations of Systems
  4. 1.4 Systems Engineering
  5. 1.5 Applications of Systems Engineering
  6. 1.6 Specialty Engineering
  7. 1.7 Related Disciplines
  8. 1.8 Software Engineering
  9. 1.9 Applications of Software Engineering
  10. 1.10 Physical Systems Engineers and Software Systems Engineers
  11. 1.11 Key Points
  12. Exercises
  13. References
2. 2 Systems Engineering and Software Engineering
  1. 2.1 Introduction
  2. 2.2 Categories of Systems
  3. 2.3 Common Attributes of PhSEs and SwSEs
  4. 2.4 Ten Things PhSEs Need to Know About Software and Software Engineering
  5. 2.5 Ten Things Software Engineers Need to Know About Systems Engineering
  6. 2.6 Key Points
  7. Exercises
  8. References
3. 3 Issues and Opportunities for Improvements
  1. 3.1 Introduction
  2. 3.2 Some Background
  3. 3.3 Professional Literacy
  4. 3.4 Differences in Terminology
  5. 3.5 Differences in Problem‐Solving Styles
  6. 3.6 Holistic and Reductionist Problem Solving
  7. 3.7 Logical and Physical Design
  8. 3.8 Differences in Process Models and Technical Processes
  9. 3.9 Workplace Respect
  10. 3.10 Key Points
  11. Exercises
  12. References
Part II: Systems Engineering for Software‐Enabled Physical Systems
1. 4 Traditional Process Models for System Development
  1. 4.1 Introduction
  2. 4.2 Characteristics of Physical Elements and Software Elements
  3. 4.3 Development Process Foundations
  4. 4.4 Linear and Vee Development Models
  5. 4.5 Iterative Development Models
  6. 4.6 The ATM Revisited
  7. 4.7 Key Points
  8. Exercises
  9. References
2. 5 The Integrated‐Iterative‐Incremental System Development Model
  1. 5.1 Introduction
  2. 5.2 Capabilities‐Based System Development
  3. 5.3 The I³ System Development Model
  4. 5.4 Key Points
  5. Exercises
  6. References
3. 6 The I³ System Definition Phase
  1. 6.1 Introduction
  2. 6.2 Performing Business or Mission Analysis
  3. 6.3 Identifying Stakeholders' Needs and Defining Their Requirements
  4. 6.4 Identifying and Prioritizing System Capabilities
  5. 6.5 Determining Technical Feasibility
  6. 6.6 Establishing and Maintaining Traceability
  7. 6.7 Key Points
  8. References
4. 7 System Requirements Definition
  1. 7.1 Introduction
  2. 7.2 The System Requirements Definition Process
  3. 7.3 A Requirements Taxonomy
  4. 7.4 Verifying and Validating System Requirements
  5. 7.5 System Requirements for the RC‐DSS Case Study
  6. 7.6 Key Points
  7. Exercises
  8. References
5. 8 Architecture Definition and Design Definition
  1. 8.1 Introduction
  2. 8.2 Principles of Architecture Definition
  3. 8.3 Defining System Architectures
  4. 8.4 Architecture Evaluation Criteria
  5. 8.5 Selecting the Architecture
  6. 8.6 Principles of Design Definition
  7. 8.7 RC‐DSS Architecture Definition
  8. 8.8 RC‐DSS Design Definition
  9. 8.9 Controlling the Complexity of System Architecture and System Design
  10. 8.10 Key Points
  11. Exercises
  12. The System Modeling Language (SysML)
  13. References
6. 9 System Implementation and Delivery
  1. 9.1 Introduction
  2. 9.2 I³ Phases 5 and 6
  3. 9.3 I³ System Implementation
  4. 9.4 I³ System Delivery
  5. 9.5 Key Points
  6. Exercises
  7. References
Part III: Technical Management of Systems Engineering
1. 10 Planning and Estimating the Technical Work
  1. 10.1 Introduction
  2. 10.2 Documenting the Technical Work Plan (SEMP)
  3. 10.3 The Estimation Process
  4. 10.4 Estimation Techniques
  5. 10.5 Documenting an Estimate
  6. 10.6 Key Points
  7. Exercises
  8. References
2. 11 Assessing, Analyzing, and Controlling Technical Work
  1. 11.1 Introduction
  2. 11.2 Assessing and Analyzing Process Parameters
  3. 11.3 Assessing and Analyzing System Parameters
  4. 11.4 Corrective Action
  5. 11.5 Key Points
  6. Exercises
  7. References
3. 12 Organizing, Leading, and Coordinating
  1. 12.1 Introduction
  2. 12.2 Managing Versus Leading
  3. 12.3 The Influence of Corporate Culture
  4. 12.4 Responsibility and Authority
  5. 12.5 Teams and Teamwork
  6. 12.6 Maintaining Motivation and Morale
  7. 12.7 Can't Versus Won't
  8. 12.8 Fourteen Guidelines for Organizing and Leading Engineering Teams
  9. 12.9 Summary of the Guidelines
  10. 12.10 Key Points
  11. Exercises
  12. References
Appendix A: The Northwest Hydroelectric System
1. A.1 Background
2. A.2 Purpose
3. A.3 Challenges
4. A.4 Systems Engineering Practices
5. A.5 Lessons Learned
6. References
Appendix B: Automobile Embedded Real‐Time Systems
1. B.1 Introduction
2. B.2 Electronic Control Units
3. B.3 ECU Domains
4. B.4 The Powertrain Domain (Engine and Transmission)
5. B.5 The Chassis Domain
6. B.6 The Body Domain
7. B.7 The Infotainment Domain
8. B.8 An Emerging Domain
9. B.9 The ECU Network
10. B.10 Automotive Network Domains
11. B.11 Network Protocols
12. B.12 Summary
13. References
Glossary of Terms
Index
End User License Agreement

List of Tables

Chapter 1
1. Table 1.1 Attributes of the systems engineering profession.
2. Table 1.2 Attributes of the software engineering profession.
Chapter 2
1. Table 2.1 Three categories of systems.
2. Table 2.2 Mutual adaptation of methods by PhSEs and SwSEs.
Chapter 4
1. Table 4.1 Physical and performance parameters of HSRL.
2. Table 4.2 15288:2015 and 12207:2017 technical processes.
Chapter 5
1. Table 5.1 ATM system capabilities/feasible hardware and software.
2. Table 5.2 Capability prioritization criteria and rationale.
3. Table 5.3 System development activities for the I³ development phases....
4. Table 5.4 I³ development phase and 15288/12207 processes.
Chapter 6
1. Table 6.1 Business or mission analysis.
2. Table 6.2 Stakeholder needs and requirements definition.
3. Table 6.3 An RC‐DSS use case.
4. Table 6.4 Capability prioritization and rationale.
Chapter 7
1. Table 7.1 Inputs, processes, and outputs of system requirements definit...
2. Table 7.2 Some examples of quality attributes.
3. Table 7.3 Some users and uses of system requirements.
4. Table 7.4 A traceability example.
5. Table 7.5 Examples of RC‐DSS system capabilities and system requirement...
Chapter 8
1. Table 8.1 Architecture definition inputs, process, and outputs.
2. Table 8.2 Design definition inputs, process, and outputs.
3. Table 8.3 RC‐DSS architecture options and criteria satisfied.
4. Table 8.4N ² diagram for the RC‐DSS system elements.
Chapter 9
1. Table 9.1 I³ phases and 15288/12207 processes.
2. Table 9.2 Implementation of inputs, processes, and outputs.
3. Table 9.3 Previous I³ phases and 15288/12207 technical processes.
Chapter 11
1. Table 11.1 An example of project status using binary assessment.
2. Table 11.2 Percent of effort for various work activities.
3. Table 11.3 Earned value terminology.
4. Table 11.4 Earned value relationships.
5. Table 11.5 Some commonly occurring risk factors for systems projects.
6. Table 11.6 Qualitative determination of risk exposure.
7. Table 11.7 Risk mitigation strategies.
8. Table 11.8 Example of an immediate action plan.
9. Table 11.9 Example of a deferred action plan.
10. Table 11.10 A hierarchy of measurement scales.
11. Table 11.11 Some direct measures.
12. Table 11.12 Some indirect measures.
Chapter 12
1. Table 12.1 Some antidotes for teamicide.
2. Table 12.2 Four combinations of can't and won't.
3. Table 12.3 Four situations and leadership styles.
4. Table 12.4 Agenda and follow‐up activities for weekly status meetings.

List of Illustrations

Chapter 1
1. Figure 1.1 A stationary steam engine.
2. Figure 1.2 The 5C levels of a smart factory architecture.
3. Figure 1.3 The NOAA NPOESS context diagram.
4. Figure 1.4 A complex natural system (the Blue Marble).
5. Figure 1.5 A software‐enabled natural/engineered system.
6. Figure 1.6 A complex software‐enabled engineered system.
7. Figure 1.7 Launch of Saturn V and Apollo spacecraft.
8. Figure 1.8 The Apollo spacecraft.
9. Figure 1.9 A complex engineered system in a natural environment.
10. Figure 1.10 Attributes of an engineering profession.
11. Figure 1.11 An enterprise information system (EIS) in context.
Chapter 2
1. Figure 2.1 The Ariane 5 rocket at Le Bourget Air and Space Museum, Paris....
2. Figure 2.2 Iterative software development.
3. Figure 2.3 Quality assurance observation of a systems project.
Chapter 3
1. Figure 3.1 Template for a partial product breakdown structure.
2. Figure 3.2 A generalization/specialization class hierarchy.
3. Figure 3.3 A software product line instantiation.
4. Figure 3.4 Aggregation of ATM hardware elements.
5. Figure 3.5 Composition of ATM software elements.
Chapter 4
1. Figure 4.1 A linear one‐pass system development model.
2. Figure 4.2 A linear‐revisions system development model.
3. Figure 4.3 A Vee system development model.
4. Figure 4.4 An incremental Vee system development model.
5. Figure 4.5 An overlapping incremental Vee development model.
Chapter 5
1. Figure 5.1 A capabilities‐based approach to system development.
2. Figure 5.2 The I³ system development model.
Chapter 6
1. Figure 6.1 Package diagram of the RC‐DSS driving simulator.
2. Figure 6.2 Some project relationships.
3. Figure 6.3 Simpler project relationships.
4. Figure 6.4 A state machine diagram for RC‐DSS authentication and terminati...
5. Figure 6.5 An activity diagram for RC‐DSS authentication and termination....
6. Figure 6.6 A use case diagram.
Chapter 7
1. Figure 7.1 The I³ system development model.
2. Figure 7.2 A requirements taxonomy.
3. Figure 7.3 A capabilities‐based approach to requirements realization.
4. Figure 7.4 Context diagram for the RC‐DSS driving system simulator.
Chapter 8
1. Figure 8.1 The I³ system development model.
2. Figure 8.2 Allocation of system requirements to architectural elements.
3. Figure 8.3 Selecting the system architecture.
4. Figure 8.4 The inspection process.
5. Figure 8.5 RC‐DSS functional block diagram.
6. Figure 8.6 A partially decomposed RC‐DSS system structure.
7. Figure 8.7 An RC‐DSS sequence diagram.
8. Figure 8.8 An RC‐DSS activity diagram.
9. Figure 8.9 An RC‐DSS state diagram.
10. Figure 8.10 An RC‐DSS use case diagram.
11. Figure 8.A.1 Nine types of SysML diagrams.
12. Figure 8.A.2 A template for a block definition diagram.
13. Figure 8.A.3 Template for a sequence diagram.
14. Figure 8.A.4 An example of a sequence diagram.
15. Figure 8.A.5 Template for an activity diagram.
Chapter 9
1. Figure 9.1 The I³ system development model.
2. Figure 9.2 A template for adapter patterns.
3. Figure 9.3 An example of a bridge pattern.
Chapter 10
1. Figure10.1 The change management process.
2. Figure 10.2 Quality assurance for systems engineering projects.
3. Figure 10.3 The P‐80 Shooting Star jet fighter.
4. Figure 10.4 The Lockheed Martin Skunk Works logo.
5. Figure 10.5 An estimation process.
6. Figure 10.6 An inverted estimation process.
7. Figure 10.7 Illustrating Monte Carlo estimation.
8. Figure 10.8 An effort histogram.
9. Figure 10.9 A partial WBS. ATMHD, hardware drivers; FINAT, financial trans...
Chapter 11
1. Figure 11.1 A taxonomy of project effort.
2. Figure 11.2 Illustrating the 95% complete syndrome.
3. Figure 11.3 Illustrating accumulation of technical debt.
4. Figure 11.4 Burndown chart for an iteration cycle.
5. Figure 11.5 An example of earned value assessment.
6. Figure 11.6 Earned value projections of estimated actual cost and estimate...
7. Figure 11.7 Illustrating a 10% memory threshold for risk management.
Chapter 12
1. Figure 12.1 Structure of a small engineering team.

Copyright

This edition first published 2019

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, except as permitted by law. Advice on how to obtain permission to reuse material from this title is available at http://www.wiley.com/go/permissions.

The right of Richard E. Fairley to be identified as the author of this work has been asserted in accordance with law.

Registered Office

John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, USA

Editorial Office

111 River Street, Hoboken, NJ 07030, USA

For details of our global editorial offices, customer services, and more information about Wiley products visit us at www.wiley.com.

Wiley also publishes its books in a variety of electronic formats and by print‐on‐demand. Some content that appears in standard print versions of this book may not be available in other formats.

Limit of Liability/Disclaimer of Warranty

While the publisher and authors have used their best efforts in preparing this work, they make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives, written sales materials or promotional statements for this work. The fact that an organization, website, or product is referred to in this work as a citation and/or potential source of further information does not mean that the publisher and authors endorse the information or services the organization, website, or product may provide or recommendations it may make. This work is sold with the understanding that the publisher is not engaged in rendering professional services. The advice and strategies contained herein may not be suitable for your situation. You should consult with a specialist where appropriate. Further, readers should be aware that websites listed in this work may have changed or disappeared between when this work was written and when it is read. Neither the publisher nor authors shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.

Library of Congress Cataloging‐in‐Publication Data

Names: Fairley, R. E. (Richard E.), 1937‐ author.

Title: Systems engineering of software‐enabled systems / Richard E. Fairley,

Software Engineering Management Assoc., CO, US.

Description: Hoboken, NJ, USA : Wiley, 2019. | Includes bibliographical

references and index. |

Identifiers: LCCN 2019004173 (print) | LCCN 2019009630 (ebook) | ISBN

9781119535027 (Adobe PDF) | ISBN 9781119535034 (ePub) | ISBN 9781119535010

(hardback)

Subjects: LCSH: Software engineering. | Systems engineering.

Classification: LCC QA76.758 (ebook) | LCC QA76.758 .F355 2019 (print) | DDC

005.1–dc23

LC record available at https://lccn.loc.gov/2019004173

Cover image: © Henrik5000/E+/Getty Images

Cover design by Wiley

Preface

Modern physical systems would be inoperable without software. Software elements provide interfaces among physical elements, coordinate the interactions among software elements and physical elements, enable connections to system environments, and provide some (or most) of the functionality, behavior, and quality attributes of software‐enabled physical systems.

It is not an exaggeration to state that software‐enabled physical systems are ubiquitous throughout modern society, including but not limited to systems in the domains of transportation, communication, health care, energy, aerospace, military defense, manufacturing, ecology, agriculture, and intelligent structures such as buildings and bridges. Software‐enabled physical systems include real‐time embedded systems (navigation, communication), consumer products (cell phones, microwave ovens), health care devices (pacemakers, heart and lung machines), transportation systems (automobiles, light rail), energy systems (solar and wind farms, power grids), military defense systems (Tomahawk missiles, F‐35 aircraft), earth orbiting satellites (GPS, weather), and interplanetary missions (Cassini, Rosetta).

Software‐enabled physical systems have evolved so rapidly in size, complexity, and number of deployments that the systems engineering processes, methods, and techniques for gracefully coordinating development of the software elements and physical elements of software‐enabled physical systems have not evolved at a comparable pace.

This text presents processes, methods, and techniques that can be used to bridge the gaps between systems engineering and software engineering that will enable members of both disciplines to perform their tasks in a more cooperative and coordinated manner, which will permit more efficient system development and higher quality systems.

The text is presented in three parts. Part I includes Chapters 1-3. Chapter 1 provides an introduction to and overview of systems engineering and software engineering. Chapter 2 presents similarities and differences in the professional disciplines of systems engineering and software engineering. Chapter 3 presents issues that can facilitate and inhibit successful execution of software‐enabled physical systems development projects.

Part II includes Chapters 4-9 and covers the technical aspects of systems engineering for software‐enabled physical systems from system definition to system delivery. Chapter 4 presents traditional approaches to analysis, design, and development of complex systems. Chapters 5-9 present an approach for improving the linkages among systems engineering, software engineering, and the other engineering disciplines that collaborate to build software‐enabled physical systems.

Part III (Chapters 10-12) is concerned with technical management of systems engineering activities: planning and estimating, assessing and controlling, and organizing and leading project teams that develop software‐enabled systems.

Emphasis of this text is on systems engineering of software‐enabled physical systems but the material in the text can be applied to development of other kinds of complex systems.

Explanatory sidebars are included throughout the text. Each chapter of the text concludes with key points, exercises, and references. Two running examples are used to illustrate various processes, methods, and techniques for system engineering of software‐enabled physical systems: automated teller machines and a driving system simulator for ground‐based vehicles. The examples are large enough to illustrate key issues in systems engineering of software‐enabled physical systems but small enough to be treated within the page limitations of the text.

The intended audiences for the text include advanced undergraduate students, graduate students, practitioners of systems engineering and software engineering, and others who desire to know more about systems engineering and software engineering of software‐enabled physical systems.

The following references provide guidance for the material in this text:

ISO/IEC/IEEE Standard 15288:2015 Systems and software engineering – System life‐cycle processes;
ISO/IEC/IEEE Standard 12207:2017 Systems and software engineering – Software life‐cycle processes;
The Guide to the Systems Engineering Body of Knowledge (SEBoK);
The Guide to the Software Engineering Body of Knowledge (SWEBOK);
The Software Engineering Competency Model (SWECOM);
NASA's Systems Engineering Competency Model; and
The INCOSE Systems Engineering Handbook.

Citations for accessing these documents are provided throughout the text and in the bibliography at the end of the text. Access to these documents will be helpful in understanding the material in this text but is not essential.

I am indebted to the students and practitioners from whom I have learn as much and perhaps more than they have learned from me. I am doubly indebted to my wife and best friend Mary Jane for her thoughtful advice on the structure and content of the text.

15 January 2019

Dick Fairley

Teller County, Colorado

Systems Engineering of Software-Enabled Systems

Copyright

Preface

Part I
Systems Engineering and Software Engineering