Difference between revisions of "SEBoK Introduction"

From SEBoK
Jump to navigation Jump to search
Line 30: Line 30:
  
  
 +
==Systems and Systems Engineering==
 +
When we speak of a “system,” we may mean an engineered system, a natural system, a social system, or all three.
 +
 +
Since the province of Systems Engineering (SE) is engineered systems, most SE literature assumes that this is the context. Thus, in an SE discussion, “system architecture” would refer to the architecture of the system being engineered (e.g., a spacecraft) and not the architecture of a natural system outside its boundary (e.g., the solar system).
 +
 +
This may produce ambiguities at times: for example, does “management” refer to management of the SE process, or management of the system being engineered? In such cases, the SEBoK tries to avoid misinterpretation by elaborating the alternatives into “system management” or “systems engineering management.”
 +
 +
As with many special disciplines, SE uses terms in ways that may be unfamiliar outside the discipline. For example, in systems science and therefore SE, “open” means that a system is able to interact with its environment--as opposed to being "closed” to its environment. But in the broader engineering world we would read “open” to mean “non-proprietary” or “publicly agreed upon.”
 +
 +
Some special meanings or terms reflect the historical evolution of SE. “Systems architecting” was introduced in (Rechtin 1991) to embody the idea that better systems resulted from concurrently rather than sequentially addressing a system’s operational concept, requirements, structure, plans, and economics. “Soft SE” was introduced in (Checkland 1981) to express the criticality of human factors in SE. In both cases, the emphases that these terms imply are now accepted as integral to SE.
 +
 +
An extensive Glossary identifies how terms are used in the SEBoK, and shows how their meanings may vary in different contexts. As needed, the Glossary includes pointers to articles providing more detail.
 +
 +
For more about the definition of systems, see the article [[What is a System?]] in Part 2. For more on systems engineering see Part 3.
 
==Purpose of the SEBoK==
 
==Purpose of the SEBoK==
 
The purpose of the SEBoK is to provide a consensus-based, evolvable baseline of SE knowledge that strengthens mutual understanding among SE practitioners and the people in other disciplines with whom they interact. Shortfalls in such mutual understanding are a major source of system failures. Ongoing studies of system cost and schedule failures (Gruhl-Stutzke 2005; Johnson 2006) and safety failures (Leveson 2012) have shown that the failures have mostly come not from their domain disciplines, but from lack of adequate SE.
 
The purpose of the SEBoK is to provide a consensus-based, evolvable baseline of SE knowledge that strengthens mutual understanding among SE practitioners and the people in other disciplines with whom they interact. Shortfalls in such mutual understanding are a major source of system failures. Ongoing studies of system cost and schedule failures (Gruhl-Stutzke 2005; Johnson 2006) and safety failures (Leveson 2012) have shown that the failures have mostly come not from their domain disciplines, but from lack of adequate SE.
Line 86: Line 100:
 
A second diagram summarizes the interactions among systems engineers, systems developers, and the environment of an engineered system, across its life cycle of system definition, development, evolution (production, utilization, and support) and retirement. These are elaborated in the discussion of the nature of systems and systems engineering in Part 2, and in the [[Life Cycle Models]] article in Part 3.
 
A second diagram summarizes the interactions among systems engineers, systems developers, and the environment of an engineered system, across its life cycle of system definition, development, evolution (production, utilization, and support) and retirement. These are elaborated in the discussion of the nature of systems and systems engineering in Part 2, and in the [[Life Cycle Models]] article in Part 3.
  
−
==Systems and Systems Engineering==
 
−
When we speak of a “system,” we may mean an engineered system, a natural system, a social system, or all three.
 
−
 
−
Since the province of Systems Engineering (SE) is engineered systems, most SE literature assumes that this is the context. Thus, in an SE discussion, “system architecture” would refer to the architecture of the system being engineered (e.g., a spacecraft) and not the architecture of a natural system outside its boundary (e.g., the solar system).
 
−
 
−
This may produce ambiguities at times: for example, does “management” refer to management of the SE process, or management of the system being engineered? In such cases, the SEBoK tries to avoid misinterpretation by elaborating the alternatives into “system management” or “systems engineering management.”
 
−
 
−
As with many special disciplines, SE uses terms in ways that may be unfamiliar outside the discipline. For example, in systems science and therefore SE, “open” means that a system is able to interact with its environment--as opposed to being "closed” to its environment. But in the broader engineering world we would read “open” to mean “non-proprietary” or “publicly agreed upon.”
 
−
 
−
Some special meanings or terms reflect the historical evolution of SE. “Systems architecting” was introduced in (Rechtin 1991) to embody the idea that better systems resulted from concurrently rather than sequentially addressing a system’s operational concept, requirements, structure, plans, and economics. “Soft SE” was introduced in (Checkland 1981) to express the criticality of human factors in SE. In both cases, the emphases that these terms imply are now accepted as integral to SE.
 
−
 
−
An extensive Glossary identifies how terms are used in the SEBoK, and shows how their meanings may vary in different contexts. As needed, the Glossary includes pointers to articles providing more detail.
 
−
 
−
For more about the definition of systems, see the article [[What is a System?]] in Part 2. For more on systems engineering see Part 3.
 
  
 
==SEBoK Uses==
 
==SEBoK Uses==

Revision as of 19:03, 28 August 2012

Systems engineering (SE) is essential to the success of many human endeavors. As systems increase in scale and complexity, SE is increasingly recognized worldwide for its importance in their development, deployment, operation, and evolution.

The purpose of the SEBoK is to provide a widely accepted, community based, and regularly updated baseline of SE knowledge. This baseline will strengthen the mutual understanding across the many disciplines involved in developing and operating systems. Shortfalls in such mutual understanding are a major source of system failures, which have increasingly severe impacts as systems become more global, interactive, and critical.

To download a PDF of Part 1, please click here.

Key terms

A good first step towards understanding is to define key terms. Four terms will suffice for this Introduction: system, engineered system, systems engineering, and systems engineer.

Here are baseline definitions of what these terms mean for the purposes of the SEBoK:

  • A system is “a set of elements and a set of inter-relationships between the elements such that they form a bounded whole relative to the elements around them” (Bertalanffy 1968) and which exists in an environment which contains related systems and conditions. While there are many definitions of the word “system,” the SEBoK authors believe that this definition encompasses most of those which are relevant to systems engineering.
  • An engineered system is an open system of technical or sociotechnical elements that exhibits emergent properties not exhibited by its individual elements. It is created by and for people; has a purpose, with multiple views; satisfies key stakeholders’ value propositions; has a life cycle and evolution dynamics; has a boundary and an external environment; and is part of a system-of-interest hierarchy.
  • Systems engineering is “an interdisciplinary approach and means to enable the realization of successful systems” (INCOSE 2011). It focuses on holistically and concurrently understanding stakeholder needs; exploring opportunities; documenting requirements; and synthesizing, verifying, validating, and evolving solutions while considering the complete problem, from system concept exploration through system disposal.
  • A systems engineer is “a person who practices systems engineering” as defined above, and whose systems engineering capabilities and experience include sustained practice, specialization, leadership or authority over systems engineering activities. Systems engineering activities may be conducted by any competent person regardless of job title or professional affiliation.

Part 1 Articles

Articles in Part 1 include:


Systems and Systems Engineering

When we speak of a “system,” we may mean an engineered system, a natural system, a social system, or all three.

Since the province of Systems Engineering (SE) is engineered systems, most SE literature assumes that this is the context. Thus, in an SE discussion, “system architecture” would refer to the architecture of the system being engineered (e.g., a spacecraft) and not the architecture of a natural system outside its boundary (e.g., the solar system).

This may produce ambiguities at times: for example, does “management” refer to management of the SE process, or management of the system being engineered? In such cases, the SEBoK tries to avoid misinterpretation by elaborating the alternatives into “system management” or “systems engineering management.”

As with many special disciplines, SE uses terms in ways that may be unfamiliar outside the discipline. For example, in systems science and therefore SE, “open” means that a system is able to interact with its environment--as opposed to being "closed” to its environment. But in the broader engineering world we would read “open” to mean “non-proprietary” or “publicly agreed upon.”

Some special meanings or terms reflect the historical evolution of SE. “Systems architecting” was introduced in (Rechtin 1991) to embody the idea that better systems resulted from concurrently rather than sequentially addressing a system’s operational concept, requirements, structure, plans, and economics. “Soft SE” was introduced in (Checkland 1981) to express the criticality of human factors in SE. In both cases, the emphases that these terms imply are now accepted as integral to SE.

An extensive Glossary identifies how terms are used in the SEBoK, and shows how their meanings may vary in different contexts. As needed, the Glossary includes pointers to articles providing more detail.

For more about the definition of systems, see the article What is a System? in Part 2. For more on systems engineering see Part 3.

Purpose of the SEBoK

The purpose of the SEBoK is to provide a consensus-based, evolvable baseline of SE knowledge that strengthens mutual understanding among SE practitioners and the people in other disciplines with whom they interact. Shortfalls in such mutual understanding are a major source of system failures. Ongoing studies of system cost and schedule failures (Gruhl-Stutzke 2005; Johnson 2006) and safety failures (Leveson 2012) have shown that the failures have mostly come not from their domain disciplines, but from lack of adequate SE.

To provide a foundation for the desired mutual understanding, the SEBoK describes the boundaries, terminology, content, and structure of systems engineering (SE). In so doing, the SEBoK systematically and consistently supports six broad purposes, described in Table 1.

Table 1. SEBoK Purposes. (SEBoK Original)
Purpose Description
1 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.
2 Inform Research Inform researchers about the limitations and gaps in current SE knowledge that should help guide their research agenda.
3 Inform Interactors Inform performers in interacting disciplines (system implementation, project and enterprise management, other disciplines) of the nature and value of SE.
4 Inform Curriculum Developers Inform organizations defining the content that should be common in undergraduate and graduate programs in SE.
5 Inform Certifiers Inform organizations certifying individuals as qualified to practice systems engineering.
6 Inform SE Staffing Inform organizations and managers deciding which competencies that practicing systems engineers should possess in various roles ranging from apprentice to expert.

The SEBoK is a guide to the body of systems engineering knowledge, not an attempt to capture that knowledge directly. It provides references to more detailed sources of knowledge, all of which are generally available to any interested reader. No proprietary information is referenced, but not all referenced material is free—for example, some books or standards must be purchased from their publishers. The criterion for including a source is simply that the authors believed it offered the best generally available information on a particular subject.

The SEBoK is global in applicability. Although SE is practiced differently from industry to industry and country to country, the SEBoK is written to be useful to systems engineers anywhere. Authors have been chosen from diverse locales and industries, and have refined the SEBoK to broaden applicability based on extensive global reviews of several drafts.

The SEBoK aims to inform a wide variety of user communities about essential SE concepts and practices, in ways that can be tailored to different enterprises and activities while retaining greater commonality and consistency than would be possible without the SEBoK. Because the world in which SE is being applied is evolving and dynamic, the SEBoK is designed for easy, continuous updating as new sources of knowledge emerge.

Scope and Context of the SEBoK

The SEBoK is one of two complementary products. The other, which uses the content of the SEBoK to define a core Body of Knowledge to be included in graduate SE curricula, is called the Graduate Reference Curriculum in Systems Engineering (GRCSE). The GRCSE is not a standard, but a reference curriculum to be tailored and extended to meet the objectives of each university’s graduate program. These products are being developed by the Body of Knowledge and Curriculum to Advance Systems Engineering (BKCASE) project.

Most of the SEBoK (Parts 2 – 6) focuses on domain-independent information—that which is universal to systems engineering regardless of the domain in which it is applied. Part 7 includes examples from real projects. These illustrate the concepts discussed elsewhere in the SEBoK, while detailing considerations relevant to domains such as aerospace, medicine, and transportation.

SE in the context of Engineered Systems (glossary) (ES) is the primary scope for the SEBoK, though general systems concepts are also discussed in Part 2. The SEBoK also covers considerations for the disciplines of software engineering and project management, which are strongly intertwined with the practice of SE.

The context of the SEBoK is elaborated in two agent-activity-artifact diagrams in Part 1.

One summarizes the SEBoK’s definition by an international group of volunteer authors; its review by the SE community at large; its life cycle evolution management and support by the two primary international SE-related professional societies, the Institute of Electrical and Electronic Engineers (IEEE) and the International Council on Systems Engineering (INCOSE); and its use in derivative products and services by the community at large.

A second diagram summarizes the interactions among systems engineers, systems developers, and the environment of an engineered system, across its life cycle of system definition, development, evolution (production, utilization, and support) and retirement. These are elaborated in the discussion of the nature of systems and systems engineering in Part 2, and in the Life Cycle Models article in Part 3.


SEBoK Uses

The communities involved with systems engineering include its various specialists, engineers from disciplines other than systems engineering, managers, researchers, and educators. This diversity means that there is no single best way to use the SEBoK. The SEBoK includes use cases that highlight ways that particular communities can draw upon the content of the SEBoK, identify articles of interest to those communities, and discuss primary users (those who use the SEBoK directly) and secondary users (those who use the SEBoK with assistance from a systems engineer). See the article SEBoK Users and Uses.

SEBoK Development

This is version 1.0 of the SEBoK, released on September 15, 2012. Three prototype releases preceded this production release:

  1. Version 0.25 on September 15, 2010
  2. Version 0.5 on September 19, 2011
  3. Version 0.75 on March 15, 2012.

Version 0.25 was released as a PDF document for limited review. A total of 3135 comments were received on this document from 114 reviewers across 17 countries. The author team studied these comments with particular interest in feedback about content and about diversity within the community.

In January 2011, the authors agreed to move from a document-based SEBoK to a wiki-based SEBoK, and beginning with Version 0.5, the SEBOK has been available at www.sebokwiki.org. Making the transition to a wiki provided three benefits:

  1. easy worldwide access to the SEBoK;
  2. more methods for search and navigation; and
  3. a forum for community feedback alongside content that remains stable between versions.

See the article on SEBoK Evolution.

References

Works Cited

INCOSE. 2011. INCOSE Systems Engineering Handbook, version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE). INCOSE-TP-2003-002-03.2.

Bertalanffy, L. von. 1968. General System Theory: Foundations, Development, Applications. Revised ed. New York, NY, USA: Braziller.

Checkland, P. 1981. Systems Thinking, Systems Practice. Hoboken, NJ, USA: Wiley (2nd edition 1999).

Gruhl, W. and Stutzke, R. 2005. “Werner Gruhl Analysis of SE Investments and NASA Overruns,” in Stutzke, R., Estimating Software-Intensive Systems. Boston, MA, USA: Addison Wesley, page 290.

Johnson, J. 2006. My Life Is Failure: 100 Things You Should Know to Be a Better Project Leader. Boston, MA, USA: Standish Group International.

Leveson, N. 2012. Engineering a Safer World: Systems Thinking Applied to Safety. Cambridge, MA, USA: MIT Press.

Rechtin, E. 1991. Systems Architecting. Upper Saddle River, NJ, USA: Prentice Hall.

Primary References

INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE). INCOSE-TP-2003-002-03.2.

Sage, A., and Rouse, W. (eds.) 1999. Handbook of Systems Engineering and Management. Hoboken, NJ, USA: John Wiley and Sons, Inc.

Additional References

Bertalanffy, L. von. 1968. General System Theory: Foundations, Development, Applications. Revised ed. New York, NY, USA: Braziller.

Blanchard, B., and Fabrycky, W. 2010. Systems Engineering and Analysis, (5th edition). Saddle River, NJ, USA: Prentice Hall.

Checkland, P. 1981. Systems Thinking, Systems Practice. Hoboken, NJ, USA: Wiley (2nd edition 1999).

Booher, H. (ed.) 2003. Handbook of Human Systems Integration. Hoboken, NJ, USA: Wiley.

Hitchins, D., 2007. Systems Engineering: A 21st Century Methodology. Chichester, England: Wiley.


< Return to Table of Contents | Parent Article | Next Article >



SEBoK v. 1.9.1 released 30 September 2018

SEBoK Discussion

Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.

If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.

blog comments powered by Disqus

Retrieved from "https://sandbox.sebokwiki.org/index.php?title=SEBoK_Introduction&oldid=40945"