Difference between revisions of "Systems Engineering and Management"

From SEBoK
Jump to navigation Jump to search
Tag: visualeditor
m (Text replacement - "<center>'''SEBoK v. 2.4, released 19 May 2021'''</center>" to "<center>'''SEBoK v. 2.5, released 15 October 2021'''</center>")
(44 intermediate revisions by 6 users not shown)
Line 1: Line 1:
This part of the SEBoK focuses on the general knowledge of ''how'' systems are engineered. It builds upon [[Foundations of Systems Engineering|Part 2]], which discusses the ''what'' element of systems. Part 3 provides a basis for the engineering of [[Product System (glossary)|product systems]][[Service System (glossary)|service systems]], [[Enterprise System (glossary)|enterprise systems]], and [[System of Systems (SoS) (glossary)|systems of systems]] (SoS), as described in [[Applications of Systems Engineering|Part 4]]. Part 3 defines [[Systems Engineering (glossary)|systems engineering(glossary)]]; provides an overview of the common uses of [[Life Cycle Models|life cycle models]] in systems engineering (SE); discusses the most commonly-used SE processes; provides additional references to the common methods, tools, and techniques used in these processes; and discusses the [[Systems Engineering Management|management]] aspects of SE.
+
----
 +
'''''Lead Authors:''''' ''Bud Lawson, Alan Faisandier,'' '''''Contributing Authors:''''' ''Rick Adcock, Dick Fairley, Garry Roedler, Ray Madachy, Deva Henry, Sanford Friedenthal''
 +
----
 +
Part 3 of the Guide to the SE Body of Knowledge (SEBoK) focuses on the general knowledge of ''how'' systems are engineered.  
 +
[[File:SEBoK_Context_Diagram_Inner_P3_Ifezue_Obiako.png|centre|thumb|600x600px|'''Figure 1 SEBoK Part 3 in context (SEBoK Original).''' For more detail see [[Structure of the SEBoK]]]]
 +
 
 +
This part builds upon Part 2: [[Foundations of Systems Engineering]], which discusses the need for a {{Term|Systems Approach (glossary)}} applied to one or more {{Term|Engineered System (glossary)}} contexts as a part of managed interventions into {{Term|Complexity (glossary)|complex}} real world problems.  Part 3 provides an overview of the common uses of [[Life Cycle Models|life cycle models]] to organize the technical and non-technical aspects of SE and discusses [[Systems Engineering Management]] activities. Part 3 also discusses the most commonly used SE technical processes and provides additional references to the common methods, tools, and techniques used in these processes.
 +
 
 +
The commonly recognized definition of {{Term|Systems Engineering (glossary)|systems engineering}} (SE) used across the SEBoK (INCOSE 2015) defines SE as an interdisciplinary approach which applies across the complete life cycle of an identified {{Term|System-of-Interest (glossary)|System-of-Interest}}.  The definition states that 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'''”. Thus, SE is an engineering discipline concerned with all aspects of an engineered systems life, including how we organize to do the engineering, what is produced by that engineering and how the resulting systems are used and sustained to meet stakeholder needs.
 +
 
 +
Part 3 provides only an overview of how systems are engineered in a generic sense. [[Applications of Systems Engineering|Part 4]] provides more specific information as to how the principles discussed in Part 3 are applied differently in consideration of {{Term|Product System (glossary)|product systems}}{{Term|Service System (glossary)|service systems}}, {{Term|Enterprise System (glossary)|enterprise systems}}, and {{Term|System of Systems (SoS) (glossary)|systems of systems}} (SoS) contexts. [[Enabling Systems Engineering|Part 5]] explains how people and organizations may approach utilizing these principles as part of a holistic systems approach. [[Related Disciplines|Part 6]] contains references to other engineering and management disciplines, which work with the SE processes within a systems life cycle, but do not fall under the umbrella of SE.
  
Part 3 provides only an overview of how systems are engineered in a generic sense. [[Applications of Systems Engineering|Part 4]] provides more specific information as to how the principles discussed in Part 3 are applied differently in consideration of the type of system that is being engineered (e.g. product, service, enterprise, or system of systems (SoS)). [[Enabling Systems Engineering|Part 5]] explains how an organization may approach utilizing these principles in a holistic manner. [[Related Disciplines|Part 6]] contains references to other related disciplines, which may be utilized in the various SE processes described in Part 3, but do not fall under the umbrella of SE.
+
Systems engineering, like many other engineering disciplines, is transitioning to a model-based approach, {{Term|Model-Based Systems Engineering (MBSE) (glossary)|model-based systems engineering (MBSE)}}.  The aim is to enhance productivity and quality, and to cope with the design of increasingly complex systems.  Although models have always been used by systems engineering to create information about engineered systems, that information has been translated and managed through document based artifacts. In a model-based approach, the information about the system is captured in a shared system model, made up of a set of integrated models appropriate to the life cycle stages. This model is managed and controlled throughout the system life cycle as noted in Part 2 under [[Representing Systems with Models|Representing Systems with Models]]. This provides the ability to maintain more consistent, precise, and traceable information about the system. The system model provides an authoritative source of information that can be communicated across the development team and other stakeholders, used to generate views of the system relevant to particular stakeholders, and used to generate documentation about the system similar to more traditional systems engineering documentation. The model can also be analyzed to assess the integrity of the system specification and design. A model also captures knowledge in a way that can be more readily reused than traditional document-based approaches. In a model-based systems engineering approach, the processes referred to in this and other Parts of the SEBoK remain fundamentally the same, but the artifacts produced are model-based. Some examples of MBSE methods are highlighted in [[A Survey of Model-Based Systems Engineering (MBSE) Methodologies]] (Estefan 2008). It is anticipated that as the transition to model-based practices occurs, the SEBoK will be updated to reflect the body of current and emerging practice.
  
 
==Knowledge Areas in Part 3==
 
==Knowledge Areas in Part 3==
 
Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. Part 3 contains the following knowledge areas:
 
Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. Part 3 contains the following knowledge areas:
 +
*[[Introduction to Life Cycle Processes]]
 
*[[Life Cycle Models]]
 
*[[Life Cycle Models]]
 
*[[Concept Definition]]
 
*[[Concept Definition]]
Line 14: Line 25:
 
*[[Systems Engineering Standards]]
 
*[[Systems Engineering Standards]]
 
See the article [[Matrix of Implementation Examples]] for a mapping of case studies and vignettes included in Part 7 to topics covered in Part 3.
 
See the article [[Matrix of Implementation Examples]] for a mapping of case studies and vignettes included in Part 7 to topics covered in Part 3.
 
==Systems Engineering Definition==
 
There is no community consensus on a single definition for "[[Systems Engineering (glossary)|systems engineering]]"; the term has different connotations in different domains. However, one of the more commonly recognized definitions in the field is that of the International Council on Systems Engineering (INCOSE) (see http://www.incose.org):
 
 
<blockquote>''An interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem:''</blockquote>
 
<blockquote>
 
*''Operations''
 
*''Performance''
 
*''Test''
 
*''Manufacturing''
 
*''Cost & Schedule''
 
*''Training & Support''
 
*''Disposal''
 
</blockquote>
 
<blockquote>''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. Systems engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs. (INCOSE 2012)''</blockquote>
 
 
This is the definition that is frequently referenced throughout the SEBoK. SE is also the application of engineering practices and holistic systems thinking that works in combination with domain engineering, human sciences, management, and commercial disciplines in order to support the engineering of one or more systems-of-interest (SoI). SE may also be considered an interdisciplinary approach, governing the complete technical and managerial effort that is required to transform a set of customer needs, expectations, and constraints into a solution and to continue to support that solution throughout its life cycle. Each of these perspectives is valuable for gaining a holistic view of SE.
 
 
==Generic Systems Engineering Paradigm==
 
 
Figure 1 identifies the overall goals of any SE effort, which are: the understanding of stakeholder value; the selection of a specific need to be addressed; the transformation of that need into a system (the product or service that provides for the need); and the use of that product or service to provide the stakeholder value. This paradigm has been developed according to the principles of the [[Applying the Systems Approach|systems approach]] discussed in Part 2 and is used to establish a basis for the KAs in Part 3 and Part 4 of the SEBoK.
 
 
[[File:062211_BL_Paradigm.png|thumb|center|700px|'''Figure 1. Generic Systems Engineering Paradigm.''' (SEBoK Original)]]
 
 
On the left side of Figure 1, there are three [[System-of-Interest (glossary)|SoI's]] identified in the formation of a [[System Breakdown Structure (glossary) |system breakdown structure]]. SoI 1 is broken down into its basic elements, which in this case are systems as well (SoI 2 and SoI 3). These two systems are composed of [[System Element (glossary)|system elements]] that are not refined any further.
 
 
On the right side of Figure 1, each SoI has a corresponding [[Life Cycle Model (glossary)|life cycle model (glossary)]] which is composed of the stages that are populated with processes. The function of these processes is to define the work that is to be performed. Note that some of the requirements defined to meet the need are distributed in the early stages of the life cycle for SoI 1, while others are designated to the life cycles of SoI 2 or SoI 3. The decomposition of the system illustrates the fundamental concept of [[Recursion (glossary)|recursion (glossary)]] as defined in the ISO/IEC/IEEE 15288 standard; with the standard being reapplied for each SoI (ISO/IEC/IEEE 15288 2015). It is important to point out that the stakeholder requirements may be allocated to different system elements, which may be integrated in different life cycle stages of any of the three SoI's; however, together they form a cohesive system. For example, SoI 1 may be an embedded system composed of a hardware system, SoI 2 composed of a chassis and a motor, and Sol 3 a [[Software System (glossary)|software system]].
 
 
When performing SE processes in stages, [[Iteration (glossary)|iteration (glossary)]] between stages is often required (e.g. in successive refinement of the definition of the system or in providing an update or upgrade of an existing system). The work performed in the processes and stages can be performed in a [[Concurrent (glossary)|concurrent]] manner within the life cycle of any of the systems of interest and also among the multiple life cycles.
 
 
This paradigm provides a fundamental framework for understanding generic SE (seen in Part 3), as well as for the application of SE to the various types of systems described in [[Applications of Systems Engineering|Part 4]].
 
 
==Applying Iteration and Recursion to Systems Engineering in the Life Cycle==
 
 
The concept of iteration is also applied to processes. Figure 2 below gives an example of iteration in life cycle processes. The processes in this example are further discussed in the [[System Definition]] KA.
 
 
[[File:Ex_Itera_of_processes_related_to_Sys_Def_AF_052312.png|thumb|center|650px|'''Figure 2. Example of Iterations of Processes Related to System Definition (Faisandier 2012).''' Permission Granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]
 
 
The comprehensive definition of a SoI is generally achieved using decomposition layers and [[System Element (glossary)|system elements (glossary)]]. Figure 3 presents a fundamental schema of a system breakdown structure.
 
 
[[File:Hierarchical_decomposition_of_a_system-of-interest_060612.jpg|thumb|center|650px|'''Figure 3. Hierarchical Decomposition of a System-of-Interest (Faisandier 2012).''' Permission Granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]
 
 
In each decomposition layer and for each system, the [[System Definition]] processes are applied recursively because the notion of "system" is in itself recursive; the notions of SoI, system, and system element are based on the same concepts (see [[Foundations of Systems Engineering|Part 2]]). Figure 4 shows an example of the recursion of life cycle processes.
 
 
[[File:Recursion_of_processes_on_layers_060612.jpg|thumb|center|650px|'''Figure 4. Recursion of Processes on Layers (Faisandier 2012).''' Permission Granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]
 
  
 
==Value of Ontology Concepts for Systems Engineering==
 
==Value of Ontology Concepts for Systems Engineering==
  
Ontology is the set of entities presupposed by a theory (Collins English Dictionary 2011). Systems engineering, and system development in particular, is based on concepts related to mathematics and proven practices. A SE ontology can be defined considering the following path.
+
Ontology is the set of entities presupposed by a theory (Collins English Dictionary 2011). Systems engineering, and system development in particular, is based on concepts related to mathematics and proven practices. A SE ontology can be defined considering the following path/rationale.
  
SE provides engineers with an approach based on a set of concepts (i.e., stakeholder, requirement, function, scenario, system element, etc.) and generic processes. Each process is composed of a set of activities and tasks gathered logically around a theme or a purpose. A process describes “what to do” using the applied concepts. The implementation of the activities and tasks is supported by methods and modeling techniques, which are composed themselves of elementary tasks; they describe the “how to do” of SE. The activities and tasks of SE are transformations of generic data using predefined concepts. Those generic data are called entities, classes, or types. Each ''entity'' is characterized by specific ''attributes'', and each attribute may have a different value. All along their execution, the activities and tasks of processes, methods, and modeling techniques exchange instances of generic entities according to logical ''relationships''. These relationships allow the engineer to link the entities between themselves [[Traceability (glossary)|(traceability)]] and to follow a logical sequence of the activities and the global progression (engineering management). Cardinality is associated with every relationship, expressing the minimum and maximum number of entities that are required in order to make the relationship valid. Additional information on this subject may be found in ''Engineering Complex Systems with Models and Objects'' (Oliver, Kelliher, and Keegan 1997).
+
SE provides engineers with an approach based on a set of concepts (i.e., stakeholder, requirement, function, scenario, system element, etc.) and generic processes (Madni and Sievers, 2018). Each process is composed of a set of activities and tasks gathered logically around a theme or a purpose. A process describes “what to do” using the applied concepts. The implementation of the activities and tasks is supported by methods and modeling techniques, which are composed themselves of elementary tasks; they describe the “how to do” of SE. The activities and tasks of SE are transformations of generic data using predefined concepts. Those generic data are called entities, classes, or types. Each ''entity'' is characterized by specific ''attributes'', and each attribute may have a different value. All along their execution, the activities and tasks of processes, methods, and modeling techniques exchange instances of generic entities according to logical ''relationships''. These relationships allow the engineer to link the entities between themselves {{Term|Traceability (glossary)|(traceability)}} and to follow a logical sequence of the activities and the global progression (engineering management). Cardinality is associated with every relationship, expressing the minimum and maximum number of entities that are required in order to make the relationship valid.  
 +
{| class="wikitable mw-collapsible"
 +
|''‘Cardinality in systems is associated with every relationship, expressing the number of  entities that are required to make the relationship stand. As such a relationship  can be viewed in one of three ways:'' One-2-One,  One-2-Many or Many-to-Many ''and described in terms of quantity, pattern and arrangement.’''
 +
|}
 +
Additional information on this subject may be found in ''Engineering Complex Systems with Models and Objects'' (Oliver, Kelliher, and Keegan 1997).
  
The set of SE entities and their relationships form an ontology, which is also referred to as an "engineering meta-model". Such an approach is used and defined in the ISO 10303 standard (ISO 2007). There are many benefits to using an ontology. The ontology allows or forces:
+
The set of SE entities and their relationships form an ontology, which is also referred to as an "engineering meta-model". Such an approach is used and defined in the ISO 10303:AP233 standard (ISO 2007). There are many benefits to using an ontology including:
  
 
*the use of a standardized vocabulary, with carefully chosen names, which helps to avoid the use of synonyms in the processes, methods, and modeling techniques
 
*the use of a standardized vocabulary, with carefully chosen names, which helps to avoid the use of synonyms in the processes, methods, and modeling techniques
Line 75: Line 45:
 
Throughout Part 3, there are discussions of the ontological elements specifically relevant to a given topic.
 
Throughout Part 3, there are discussions of the ontological elements specifically relevant to a given topic.
  
==Terminology: Process, Architecture and Requirement ==
+
==Mapping of Topics to ISO/IEC 15288, System Life Cycle Processes==
 
 
There are terms with multiple definitions used in Part 3 and the rest of the SEBoK.  Understanding how and where they are used is important. This section discusses them from a variety of contexts to minimize confusion.
 
 
 
The terms ''process'', ''architecture'', and ''requirement'' are fundamental to topics within SE; below, they are defined in general, partially elaborated upon, and outlined as to how they are used in different parts of SEBoK for further reference.
 
  
===Process===
+
Figure 2, below, shows the relative position of the KA's of the SEBoK with respect to the processes outlined in the ISO/IEC/IEEE 15288 (ISO 2015) standard.
  
A [[Process (glossary)|process]] is a series of actions or steps taken in order to achieve a particular end; as a verb it is the performing of the operations.  Processes can be performed by humans or machines transforming inputs into outputs.
+
As shown, all of the major processes described in ISO/IEC/IEE 15288:2015 are discussed within the SEBoK.
 +
[[File:Mapping_of_tech_topics_SEBoK_with_ISO_IEC_15288techPro_060612.jpg|thumb|center|600px|'''Figure 2. Mapping of Technical Topics of Knowledge Areas of SEBoK with ISO/IEC/IEEE 15288 Technical Processes.''' (SEBoK Original)]]
  
In SEBoK processes are interpreted in several ways, including: technical, lifecycle, business, or manufacturing flow processes.  Many of the Part 3 sections are structured along technical processes (e.g. design, verification); however, [[Life Cycle Models]] applies the concept at the high level of a program lifecycle sequence (e.g. rational unified process (RUP), Vee model, etc.).
+
The ISO/IEC/IEEE 15288:2015 marked with an * are new or have been renamed and modified in scope for this revision of the standard.   
 
 
[[Applications of Systems Engineering|Part 4: Applications of Systems Engineering]] and [[Enabling Systems Engineering|Part 5: Enabling Systems Engineering]] utilize processes that are related to services and business enterprise operationsSee [[Process (glossary)]] for various interpretations of this term.
 
  
===Architecture===
+
These changes and associated changes to the SEBoK now mean that the two are significantly more closely aligned than before.  It should also be noted that the latest update of the INCOSE SE Handbook (INCOSE 2015) is now fully aligned with the 2015 revision of the standard.
  
An [[Architecture (glossary)|architecture]] refers to the the organizational structure of a system, whereby the system can be defined in different contexts.  Architecting is the art or practice of designing the structures.
+
Any future evolution of Life Cycle Process knowledge in the SEBoK will be complementary to these standard descriptions of the generic SE process set.
 
 
Architectures can apply for a system, product, enterprise, or service.  For example, Part 3 mostly considers product-related architectures that systems engineers create, but enterprise architecture describes the structure of an organization.  [[Enabling Systems Engineering|Part 5: Enabling Systems Engineering]] interprets enterprise architecture in a much broader manner than an IT system used across an organization, which is a specific instance of architecture.  More complete definitions are available [[Architecture (glossary)]].
 
 
Frameworks are closely related to architectures, as they are ways of representing architectures.  The terms Architecture Framework and Architectural Framework both refer to the same.  Examples include:  DoDAF, MoDAF, NAF for representing systems in defense applications, the TOGAF open group Architecture Framework, and the Federal Enterprise Architecture Framework (FEAF) for information technology acquisition, use and disposal.  See the glossary of terms [[Architecture Framework (glossary)|Architecture Framework]] for definition and other examples.
 
 
 
===Requirement===
 
 
 
A [[Requirement (glossary)|requirement]] is something that is needed or wanted, but may not be compulsory in all circumstances. Requirements may refer to product or process characteristics or constraints.  Different understandings of requirements are dependent on process state, level of abstraction, and type (e.g. functional, performance, constraint).  An individual requirement may also have multiple interpretations over time.
 
 
 
Requirements exist at multiple levels of enterprise or system with multiple levels abstraction.  This ranges from the highest level of the enterprise capability or customer need to the lowest level of the system design.  During the Concept Definition, as the enterprise identifies new capabilities that are desired, the business or mission analysis develops a high level set of mission requirements that reflect the problem space perspective.   As the solution space is explored and solution classes are characterized, stakeholder needs are developed and transformed into stakeholder requirements (user perspective).  After the solution class has been determined and the specific solution is sought, during the System Definition the stakeholder requirements are transformed into system requirements (solution perspective).  As the system definition recursively defines the lower level detail of the solution, requirements are defined with lower level of abstraction.  At the highest level, the ideal requirement is implementation-independent, and therefore not specific to a solution, allowing for a range of possible solutions. At the lowest level, requirement statements may become more specific to the selected solution.  Thus, requirements need to be defined at the appropriate level of detail for the level of the entity to which it applies. See the article [[Process Synopsis]] for further detail on the transformation of needs and requirements from the enterprise to the lowest system element.
 
 
 
Concept Definition has further descriptions of business or enterprise and stakeholder needs and requirements.  It discusses how the new capability for the business or enterprise is defined as part of the understanding of the problem space.  It also discusses the development of the stakeholder needs and their transformation into requirements from the user perspective. 
 
 
 
[[System Definition]] has further descriptions of requirements and their types (e.g. system requirement, stakeholder requirement, derived requirement). It discusses how different process roles/ states, levels, and the nature of requirements apply to the understanding of requirements.  Also see [[Requirement (glossary)|requirement]].
 
 
 
Furthermore, these terms are intertwined and linked to additional concepts. For example, processes are used to generate architectures and requirements. Processes are also architectures themselves, since the activities form a structure with connections between them.  There are process and architecture requirements, with the requirement depending on the process state. These are some of the ways that these terms and concepts tie together in systems engineering.
 
 
 
==Mapping of Topics to ISO/IEC 15288, System Life Cycle Processes==
 
 
 
Figure 5, below, shows the relative position of the KA's of the SEBoK with respect to the processes outlined in the ISO/IEC/IEEE 15288 (ISO/IEC/IEEE 15288 2015) standard.  As shown, all of the major processes described in ISO/IEC 15288 are discussed within the SEBoK, though the organization of topics may differ.
 
 
 
[[File:Mapping_of_tech_topics_SEBoK_with_ISO_IEC_15288techPro_060612.jpg|thumb|center|600px|'''Figure 5. Mapping of Technical Topics of Knowledge Areas of SEBoK with ISO/IEC/IEEE 15288 Technical Processes.''' (SEBoK Original)]]
 
  
 
==References==  
 
==References==  
===Works Cited===
 
 
Collins English Dictionary, s.v. "Ontology." 2011.
 
Collins English Dictionary, s.v. "Ontology." 2011.
  
Faisandier, A. 2012. ''Systems Architecture and Design''. Belberaud, France: Sinergy'Com.
+
Estefan, J. 2008. ''A Survey of Model-Based Systems Engineering (MBSE) Methodologies'', rev, B. Seattle, WA: International Council on Systems EngineeringINCOSE-TD-2007-003-02. Available at: http://www.omgsysml.org/MBSE_Methodology_Survey_RevB.pdf. Accessed April 13, 2015.
 
 
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.2.
 
  
ISO/IEC. 2003. ''Systems Engineering A Guide for The Application of ISO/IEC 15288 System Life Cycle Processes.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 19760:2003 (E).
+
INCOSE. 2015. ''Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities'', version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0.
  
 
ISO/IEC/IEEE. 2015. ''Systems and Software Engineering -- System Life Cycle Processes''. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute for Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.
 
ISO/IEC/IEEE. 2015. ''Systems and Software Engineering -- System Life Cycle Processes''. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute for Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.
Line 132: Line 72:
  
 
===Primary References===
 
===Primary References===
INCOSE. 2012. ''[[INCOSE Systems Engineering Handbook|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.2.
+
INCOSE. 2015. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]] - A Guide for System Life Cycle Processes and Activities'', version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0.
  
 
ISO/IEC/IEEE. 2015. [[ISO/IEC/IEEE 15288| Systems and Software Engineering -- System Life Cycle Processes]]. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2015.
 
ISO/IEC/IEEE. 2015. [[ISO/IEC/IEEE 15288| Systems and Software Engineering -- System Life Cycle Processes]]. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2015.
  
 
===Additional References===
 
===Additional References===
Bell Telephone Laboratories. 1982. ''Engineering and Operations in the Bell System''. Murray Hill, NJ: Bell Telephone Laboratories.
+
Bell Telephone Laboratories. 1982. ''Engineering and Operations in the Bell System''. Murray Hill, NJ, USA: Bell Telephone Laboratories.
  
 
Fortescue, P.W., J. Stark, and G. Swinerd. 2003. ''Spacecraft Systems Engineering''. New York, NY, USA: J. Wiley.
 
Fortescue, P.W., J. Stark, and G. Swinerd. 2003. ''Spacecraft Systems Engineering''. New York, NY, USA: J. Wiley.
 +
 +
Madni, A. M. and Sievers, M. 2018. ''Model‐based systems engineering: Motivation, current status, and research opportunities'', Systems Engineering. 2018; 21: 172– 190. <nowiki>https://doi.org/10.1002/sys.21438</nowiki>
  
 
----
 
----
 
<center>[[Applying the Systems Approach|< Previous Article]] | [[SEBoK Table of Contents|Parent Article]] | [[Introduction to Life Cycle Processes|Next Article >]]</center>
 
<center>[[Applying the Systems Approach|< Previous Article]] | [[SEBoK Table of Contents|Parent Article]] | [[Introduction to Life Cycle Processes|Next Article >]]</center>
  
{{DISQUS}}
+
<center>'''SEBoK v. 2.5, released 15 October 2021'''</center>
  
[[Category: Part 3]][[Category:Part]]
+
[[Category: Part 3]]
 +
[[Category:Part]]

Revision as of 18:32, 14 October 2021


Lead Authors: Bud Lawson, Alan Faisandier, Contributing Authors: Rick Adcock, Dick Fairley, Garry Roedler, Ray Madachy, Deva Henry, Sanford Friedenthal


Part 3 of the Guide to the SE Body of Knowledge (SEBoK) focuses on the general knowledge of how systems are engineered.

Figure 1 SEBoK Part 3 in context (SEBoK Original). For more detail see Structure of the SEBoK

This part builds upon Part 2: Foundations of Systems Engineering, which discusses the need for a systems approachsystems approach applied to one or more engineered systemengineered system contexts as a part of managed interventions into complexcomplex real world problems. Part 3 provides an overview of the common uses of life cycle models to organize the technical and non-technical aspects of SE and discusses Systems Engineering Management activities. Part 3 also discusses the most commonly used SE technical processes and provides additional references to the common methods, tools, and techniques used in these processes.

The commonly recognized definition of systems engineeringsystems engineering (SE) used across the SEBoK (INCOSE 2015) defines SE as an interdisciplinary approach which applies across the complete life cycle of an identified System-of-InterestSystem-of-Interest. The definition states that 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”. Thus, SE is an engineering discipline concerned with all aspects of an engineered systems life, including how we organize to do the engineering, what is produced by that engineering and how the resulting systems are used and sustained to meet stakeholder needs.

Part 3 provides only an overview of how systems are engineered in a generic sense. Part 4 provides more specific information as to how the principles discussed in Part 3 are applied differently in consideration of product systemsproduct systems, service systemsservice systems, enterprise systemsenterprise systems, and systems of systemssystems of systems (SoS) contexts. Part 5 explains how people and organizations may approach utilizing these principles as part of a holistic systems approach. Part 6 contains references to other engineering and management disciplines, which work with the SE processes within a systems life cycle, but do not fall under the umbrella of SE.

Systems engineering, like many other engineering disciplines, is transitioning to a model-based approach, model-based systems engineering (MBSE)model-based systems engineering (MBSE). The aim is to enhance productivity and quality, and to cope with the design of increasingly complex systems. Although models have always been used by systems engineering to create information about engineered systems, that information has been translated and managed through document based artifacts. In a model-based approach, the information about the system is captured in a shared system model, made up of a set of integrated models appropriate to the life cycle stages. This model is managed and controlled throughout the system life cycle as noted in Part 2 under Representing Systems with Models. This provides the ability to maintain more consistent, precise, and traceable information about the system. The system model provides an authoritative source of information that can be communicated across the development team and other stakeholders, used to generate views of the system relevant to particular stakeholders, and used to generate documentation about the system similar to more traditional systems engineering documentation. The model can also be analyzed to assess the integrity of the system specification and design. A model also captures knowledge in a way that can be more readily reused than traditional document-based approaches. In a model-based systems engineering approach, the processes referred to in this and other Parts of the SEBoK remain fundamentally the same, but the artifacts produced are model-based. Some examples of MBSE methods are highlighted in A Survey of Model-Based Systems Engineering (MBSE) Methodologies (Estefan 2008). It is anticipated that as the transition to model-based practices occurs, the SEBoK will be updated to reflect the body of current and emerging practice.

Knowledge Areas in Part 3

Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. Part 3 contains the following knowledge areas:

See the article Matrix of Implementation Examples for a mapping of case studies and vignettes included in Part 7 to topics covered in Part 3.

Value of Ontology Concepts for Systems Engineering

Ontology is the set of entities presupposed by a theory (Collins English Dictionary 2011). Systems engineering, and system development in particular, is based on concepts related to mathematics and proven practices. A SE ontology can be defined considering the following path/rationale.

SE provides engineers with an approach based on a set of concepts (i.e., stakeholder, requirement, function, scenario, system element, etc.) and generic processes (Madni and Sievers, 2018). Each process is composed of a set of activities and tasks gathered logically around a theme or a purpose. A process describes “what to do” using the applied concepts. The implementation of the activities and tasks is supported by methods and modeling techniques, which are composed themselves of elementary tasks; they describe the “how to do” of SE. The activities and tasks of SE are transformations of generic data using predefined concepts. Those generic data are called entities, classes, or types. Each entity is characterized by specific attributes, and each attribute may have a different value. All along their execution, the activities and tasks of processes, methods, and modeling techniques exchange instances of generic entities according to logical relationships. These relationships allow the engineer to link the entities between themselves (traceability)(traceability) and to follow a logical sequence of the activities and the global progression (engineering management). Cardinality is associated with every relationship, expressing the minimum and maximum number of entities that are required in order to make the relationship valid.

‘Cardinality in systems is associated with every relationship, expressing the number of entities that are required to make the relationship stand. As such a relationship can be viewed in one of three ways: One-2-One, One-2-Many or Many-to-Many and described in terms of quantity, pattern and arrangement.’

Additional information on this subject may be found in Engineering Complex Systems with Models and Objects (Oliver, Kelliher, and Keegan 1997).

The set of SE entities and their relationships form an ontology, which is also referred to as an "engineering meta-model". Such an approach is used and defined in the ISO 10303:AP233 standard (ISO 2007). There are many benefits to using an ontology including:

  • the use of a standardized vocabulary, with carefully chosen names, which helps to avoid the use of synonyms in the processes, methods, and modeling techniques
  • the reconciliation of the vocabulary used in different modeling techniques and methods
  • the automatic appearance of the traceability requirements when implemented in databases, SE tools or workbenches, and the quick identification of the impacts of modifications in the engineering data set
  • the continual observation of the consistency and completeness of engineering data; etc.

Throughout Part 3, there are discussions of the ontological elements specifically relevant to a given topic.

Mapping of Topics to ISO/IEC 15288, System Life Cycle Processes

Figure 2, below, shows the relative position of the KA's of the SEBoK with respect to the processes outlined in the ISO/IEC/IEEE 15288 (ISO 2015) standard.

As shown, all of the major processes described in ISO/IEC/IEE 15288:2015 are discussed within the SEBoK.

Figure 2. Mapping of Technical Topics of Knowledge Areas of SEBoK with ISO/IEC/IEEE 15288 Technical Processes. (SEBoK Original)

The ISO/IEC/IEEE 15288:2015 marked with an * are new or have been renamed and modified in scope for this revision of the standard.

These changes and associated changes to the SEBoK now mean that the two are significantly more closely aligned than before. It should also be noted that the latest update of the INCOSE SE Handbook (INCOSE 2015) is now fully aligned with the 2015 revision of the standard.

Any future evolution of Life Cycle Process knowledge in the SEBoK will be complementary to these standard descriptions of the generic SE process set.

References

Collins English Dictionary, s.v. "Ontology." 2011.

Estefan, J. 2008. A Survey of Model-Based Systems Engineering (MBSE) Methodologies, rev, B. Seattle, WA: International Council on Systems Engineering. INCOSE-TD-2007-003-02. Available at: http://www.omgsysml.org/MBSE_Methodology_Survey_RevB.pdf. Accessed April 13, 2015.

INCOSE. 2015. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0.

ISO/IEC/IEEE. 2015. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute for Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.

ISO. 2007. Systems Engineering and Design. Geneva, Switzerland: International Organization for Standardization (ISO). ISO 10303-AP233.

Oliver, D., T. Kelliher, and J. Keegan. 1997. Engineering Complex Systems with Models and Objects. New York, NY, USA: McGraw-Hill.

Primary References

INCOSE. 2015. Systems Engineering Handbook - A Guide for System Life Cycle Processes and Activities, version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0.

ISO/IEC/IEEE. 2015. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2015.

Additional References

Bell Telephone Laboratories. 1982. Engineering and Operations in the Bell System. Murray Hill, NJ, USA: Bell Telephone Laboratories.

Fortescue, P.W., J. Stark, and G. Swinerd. 2003. Spacecraft Systems Engineering. New York, NY, USA: J. Wiley.

Madni, A. M. and Sievers, M. 2018. Model‐based systems engineering: Motivation, current status, and research opportunities, Systems Engineering. 2018; 21: 172– 190. https://doi.org/10.1002/sys.21438


< Previous Article | Parent Article | Next Article >
SEBoK v. 2.5, released 15 October 2021