University of Southern California Center for Software Engineering C S E USC Barry Boehm, Art Pyster BKCASE Workshop VI April 12, 2011 SEBoK Part 1 Systems Engineering Body of Knowledge Introduction

University of Southern California Center for Software Engineering C S E USC 03/12/112 Outline SEBoK Motivation, Context, Purpose, and Scope Nature of Systems, Engineered Systems, and SE SE and Other Engineering Disciplines Short History of SE Key SE Principles and Practices SEBoK Origins, Users, and Use Cases SEBoK Content and Organization SEBoK Operational Concept and Next Steps Backup: Detailed Tables, Definitions

University of Southern California Center for Software Engineering C S E USC SEBoK Purpose, Motivation, Context, and Scope SEBoK Motivation and Context –Quantitative evidence of SE value –Proliferation of current definitions –Confusion in nature of SE services sought, bought, and taught –Rapidly evolving field SEBoK Purpose –Provide evolvable baseline definition of the SEBoK Inform SE practice, research, interactors, curriculum developers, certifiers, staffing Scope: SE Boundary and Environment –Deals with Engineered Systems –Overlaps with system development, project management –Needs to integrate hardware, software, human factors engineering –Focus on domain-independent knowledge –Range from enterprises to subassemblies of components 03/12/113

University of Southern California Center for Software Engineering C S E USC Quantitative Evidence of SE Value 03/12/114

University of Southern California Center for Software Engineering C S E USC Systems, Engineered Systems, and SE Natural Systems and Engineered Systems –Natural systems: Solar system, real number system Not a concern of SEBoK, other than being external environments –Engineered systems: Technical or sociotechnical aggregations of physical, informational, and human elements that exhibit emergent properties not exhibited by the individual elements Are created by and for people Have a purpose, with multiple views Satisfy key stakeholders’ value propositions Have a life cycle and evolution dynamics Have a boundary and an external environment Are part of a system-of-interest hierarchy –SE (modified INCOSE; details in chart 18): An interdisciplinary approach and means to enable the realization of successful systems. It focuses on holistically and concurrently understanding stakeholder needs; exploring opportunities; documenting requirements; and synthesizing, verifying, validating, and evolving solutions 03/12/115

University of Southern California Center for Software Engineering C S E USC Engineered Systems, Social Systems, and Natural Systems 03/12/116

University of Southern California Center for Software Engineering C S E USC SE, Systems Development, and Project Management 03/12/117 * Software Development parts of Software Engineering

University of Southern California Center for Software Engineering C S E USC 03/12/118 Comparison of SE and Other Engineering Disciplines The intellectual content of most engineering disciplines is component-oriented, largely reductionist, and value-neutral –Ohm’s Law, Hooke’s Law, Newton’s Laws The intellectual content of systems engineering is focused on: –How people and components can be combined into a cost- effective system Holistic, opportunistic synthesis Concurrent system definition, architecting, analysis, planning, evaluation, improvement Cost-effectiveness in terms of value to stakeholders

University of Southern California Center for Software Engineering C S E USC SE Stakeholders and Use Cases From current Table 3 Practicing SEs Process engineers defining or implementing SE Faculty members GRCSE authors Certifiers Program managers, other engineers, developers, testers, researchers SE managers, researchers Customers of SE Human resource development professionals Non-technical managers Attorneys, policy makers 03/12/119

University of Southern California Center for Software Engineering C S E USC History of SE: Challenge and Response Early cities: Middle East, Egypt, Asia, Latin America Early megacities, mobile cities: Roman Empire; Vitruvius Industrial Revolution: transportation, mass production World War II: Rapid, complex command-control, logistics 1950s formalizations of SE, systems analysis –Warfield, Churchman-Ackoff-Arnoff, Goode-Machol, McKean, … 1940s-1970s systems theories –Wiener, Forrester, Von Bertalanffy, Wymore, … 1970s-1990s: Soft SE, systems architecting –Warfield, Checkland, Rechtin-Maier, … 2000s: Exponential growth in systems complexity, proliferation of SE approaches 03/12/1110

University of Southern California Center for Software Engineering C S E USC Key SE Principles and Practices Start with Hitchins principles –Systems Approach “Consider System of Interest in context” –Synthesis “Bring parts together to create solutions” –Holism “Consider whole when making decisions” –Organism Analogy “Consider systems to have dynamic behaviour” –Adaptive Optimizing “Solve problems progressively over time” –Progressive Entropy Reduction “Continue to make systems work over time” –Progressive Satisfying “system success equals stakeholder success” 03/12/1111

University of Southern California Center for Software Engineering C S E USC BKCASE Content and Organization Part 1: Introduction (why?) Part 2: Systems (what?) Part 3: SE Processes (how, when, how much?) Part 4: Implementing SE in Organizations (who, where) Part 5: Implementation Examples 03/12/1112

University of Southern California Center for Software Engineering C S E USC BKCASE Operational Concept and Evolution SEBoK, GRCSE developed by SERC project –Graduate Reference Curriculum for SE –Convergence on hardcopy and softcopy versions (wikis?) Transitioned to IEEE, INCOSE –Available free to all –Update processes negotiated with IEEE, INCOSE Open to all, but with core editorial group 03/12/1113

University of Southern California Center for Software Engineering C S E USC Backup charts 03/12/1114

University of Southern California Center for Software Engineering C S E USC 03/12/1115 Task NameTask Description Inform Practice Inform systems engineers about the boundaries, terminology, and structure of their discipline and point them to useful information needed to practice SE in any application domain Inform Research Inform researchers about the limitations and gaps in current SE knowledge that should help guide their research agenda Inform Interactors Inform performers in interacting disciplines (system development, project and enterprise management, other disciplines) of the nature and value of SE Inform Curriculum Developers Inform organizations defining the content that should be common in undergraduate and graduate programs in SE Inform CertifiersInform organizations certifying individuals as qualified to practice systems engineering Inform SE StaffingInform organizations and managers deciding which competencies practicing systems engineers should possess in various roles ranging from apprentice to expert Table 1. SEBoK Purposes

University of Southern California Center for Software Engineering C S E USC 03/12/ Process engineers responsible for defining or implementing SE processes  Users are maintaining a library of SE process assets and want to understand which are the most relevant SE process standards  Users are tailoring a process for a specific project and want to find examples in the literature of how others have tailored processes in the past or to find how a specific application domain should affect tailoring  Users wish to measure the effectiveness of their organization’s SE processes and want to find examples in the literature of how others have done such measurement 3Faculty members  Users are developing a new graduate program in SE and need to decide the core knowledge that all students in the program should master; users would simultaneously reference GRCSE, which makes extensive reference to the SEBoK  Users are developing a new SE course and need to identify course objectives, topics, and reading assignments  Users in other engineering disciplines want to incorporate SE concepts in their courses or curricula 4GRCSE authors  Users are members of the GRCSE author team and need to decide what knowledge to expect from all SE graduate students 5Certifiers  Users are defining a company’s in-house SE certification program and want to understand what others have done, how such programs are typically structured, and how to select the knowledge that each person seeking certification should master 6 Managers, other engineers, developers, testers, researchers  Users want to understand the scope of SE relative to their roles  Users want to understand basic vocabulary, boundaries, and structure of SE and are looking for a few primary references  Users want to understand the role of the systems engineer versus others on a project or in an organization  Users want to effectively perform their roles on a SE integrated product team 7Customers of systems engineers  Users receive artifacts from systems engineers and want to better understand what to ask for, how to request it, and how to judge the quality of what is received 8SE managers  Users’ teams of systems engineers are proposing changes in the teams’ processes and tools, and the users want to read independent information to evaluate the proposal  Users need to hire systems engineers and want to develop competency-based job descriptions #UsersCommon SEBoK Uses 1 Practicing SEs ranging from novice up through expert  Users are taking on a new SE role in a project and need the best references to help prepare  Users want to expand their areas of SE expertise and specialization and need the best references to read  Users want to understand the principles of SE and find the best references to elaborate on those principles  Users want to understand what best SE practices to look for in a project they are reviewing, or for mentoring a new SE performer

University of Southern California Center for Software Engineering C S E USC 03/12/1117 9SE researchers  Users want to understand where the gaps are in SE knowledge to help guide their research agendas  Users want to familiarize themselves with research topics and want to know the best articles to read #UsersCommon SEBoK Uses 1 Human resource development professionals  Users will access SEBoK with the assistance of a direct user in order to support the hiring and professional development of systems engineers 2Non-technical managers  Users will access SEBoK with the assistance of a direct user in order to find specific information of interest about SE topics central to the managers’ concerns; e.g., a contracting manager might want to better understand SE deliverables being called out in a contract 3Attorneys, policy makers  Users will access SEBoK with the assistance of a direct user in order to understand such legal issues as the liability of a systems engineer for errors in judgment on a project, or to understand the limitations of SE in guaranteeing the success of a project vs. the actions of sponsors, managers, or developers

University of Southern California Center for Software Engineering C S E USC Proposed Definitions engineered system -- A technical or sociotechnical aggregation of physical, informational, and human elements that exhibit emergent properties not exhibited by the individual elements. Its characteristics include being created by and for people; having a purpose, with multiple views; satisfying key stakeholders’ value propositions; having a life cycle and evolution dynamics; having a boundary and an external environment; and being a part of a system-of-interest hierarchy. natural system – a system whose elements, boundary, and relationships exist independently of human control. Examples: the real number system, the solar system, planetary atmosphere circulation systems. social system – a system that includes humans as elements. sociotechnical system – a system that is both an engineered system and a social system. system – a set of system elements within a system boundary defined by a set of membership criteria, and a set of relationships satisfied by the elements within the boundary. systems engineering-- An interdisciplinary approach and means to enable the realization of successful systems. It focuses on holistically and concurrently understanding stakeholder needs, exploring opportunities, documenting requirements, and synthesizing, verifying, and validating solutions while considering the complete problem: Performance and Mission Effectiveness; Verification and Validation; Development and Production; Training and Support; Operations and Maintenance; Disposal; Life Cycle Cost and Schedule Systems engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation for each evolutionary increment. Systems engineering considers both the business and the technical needs of all key stakeholders with the goal of providing a quality system that satisfactorily addresses the full set of stakeholder needs. 03/12/1118