John Wiley & Sons Systems Engineering of Software-Enabled Systems Cover A comprehensive review of the life cycle processes, methods, and techniques used to develop and modi.. Product #: 978-1-119-53501-0 Regular price: $123.36 $123.36 Auf Lager

Systems Engineering of Software-Enabled Systems

Fairley, Richard E.

Wiley - IEEE

Cover

1. Auflage August 2019
432 Seiten, Hardcover
Wiley & Sons Ltd

ISBN: 978-1-119-53501-0
John Wiley & Sons

Jetzt kaufen

Preis: 132,00 €

Preis inkl. MwSt, zzgl. Versand

Weitere Versionen

epubmobipdf

A comprehensive review of the life cycle processes, methods, and techniques used to develop and modify software-enabled systems

Systems Engineering of Software-Enabled Systems offers an authoritative review of the most current methods and techniques that can improve the links between systems engineering and software engineering. The author--a noted expert on the topic--offers 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 attributes needed by stakeholders, based on model-based system architecture. In addition, the author covers the management activities that a systems engineer or software engineer must engage in to manage and lead the technical work to be done. This important book:
* Offers an approach to improving the process of working with systems engineers and software engineers
* Contains information on the planning and estimating, measuring and controlling, managing risk, and organizing and leading systems engineering teams
* Includes a discussion of the key points of each chapter and exercises for review
* Suggests numerous references that provide additional readings for development of software-enabled physical systems
* Provides two case studies as running examples throughout the text

Written for advanced undergraduates, graduate students, and practitioners, Systems Engineering of Software-Enabled Systems offers a comprehensive resource to the traditional and current techniques that can improve the links between systems engineering and software engineering.

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
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.

R. E. Fairley, Software Engineering Management Associates and Colorado Technical University in Colorado Springs