Details

Systems Engineering of Software-Enabled Systems


Systems Engineering of Software-Enabled Systems


IEEE Press 1. Aufl.

von: Richard E. Fairley

117,99 €

Verlag: Wiley
Format: EPUB
Veröffentl.: 17.06.2019
ISBN/EAN: 9781119535034
Sprache: englisch
Anzahl Seiten: 432

DRM-geschütztes eBook, Sie benötigen z.B. Adobe Digital Editions und eine Adobe ID zum Lesen.

Beschreibungen

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

Diese Produkte könnten Sie auch interessieren:

Strategies to the Prediction, Mitigation and Management of Product Obsolescence
Strategies to the Prediction, Mitigation and Management of Product Obsolescence
von: Bjoern Bartels, Ulrich Ermel, Peter Sandborn, Michael G. Pecht
PDF ebook
116,99 €