Difference between revisions of "System Realization"
m (Text replacement - "<center>'''SEBoK v. 2.0, released 1 June 2019'''</center>" to "<center>'''SEBoK v. 2.1, released 31 October 2019'''</center>") |
|||
| (18 intermediate revisions by 6 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | ---- | |
| − | + | '''''Lead Authors:''''' ''John Snoderly, Alan Faisandier,'' '''''Contributing Author:''''' ''Rick Adcock'' | |
| − | + | ---- | |
| − | + | {{Term|System Realization (glossary)|System realization}} activities are conducted to create and test versions of a system as specified by {{Term|System Definition (glossary)|system definition}}. The activities are grouped and described as generic processes that are performed iteratively and/or concurrently depending on the selected {{Term|Life Cycle Model (glossary)}}. These activities include those required to build a system ({{Term|Implementation (glossary)|system implementation}}), integrate disparate system elements ({{Term|Integration (glossary)|system integration}}), and ensure that the system meets both the needs of stakeholders ({{Term|Validation (glossary)|system validation}}) and aligns with the system requirements and architecture ({{Term|Verification (glossary)|system verification}}). | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| + | These activities are not sequential, but are performed concurrently, iteratively and recursively depending on the selected [[Life Cycle Models|life cycle model]]. Figure 1 (see "Overview", below), also shows how these processes fit within the context of {{Term|System Definition (glossary)}} and [[System Deployment and Use]] KAs. See also [[Applying Life Cycle Processes]] for further discussion of the relationships between process and life cycle model. | ||
==Topics== | ==Topics== | ||
Each part of the SEBoK is divided into KAs, which are groupings of information with a related theme. The KAs in turn are divided into topics. This KA contains the following topics: | Each part of the SEBoK is divided into KAs, which are groupings of information with a related theme. The KAs in turn are divided into topics. This KA contains the following topics: | ||
| − | *[[System Implementation]] | + | * [[System Implementation]] |
| − | *[[System Integration]] | + | * [[System Integration]] |
| − | *[[System Verification]] | + | * [[System Verification]] |
| − | *[[System Validation]] | + | * [[System Validation]] |
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. | ||
==Overview== | ==Overview== | ||
| − | Essentially, the outputs of | + | Essentially, the outputs of {{Term|System Definition (glossary)|system definition}} are used during {{Term|Implementation (glossary)|system implementation}} to create {{Term|System Element (glossary)|system elements}} and during {{Term|Integration (glossary)|system integration}} to provide plans and criteria for combining these elements. The requirements are used to {{Term|Verification (glossary)|verify}} and {{Term|Validation (glossary)|validate}} system elements, systems, and the overall {{Term|System-of-Interest (glossary)|system-of-interest}} (SoI). These activities provide feedback into the system design, particularly when problems or challenges are identified. |
| − | Finally, when the system is considered verified and validated, it will then become an input to [[System Deployment and Use|system deployment and use]]. It is important to understand that there is overlap in these activities; they do not have to occur in sequence as demonstrated in Figure 1. Every life cycle model includes realization activities, | + | Finally, when the system is considered, verified, and validated, it will then become an input to [[System Deployment and Use|system deployment and use]]. It is important to understand that there is overlap in these activities; they do not have to occur in sequence as demonstrated in Figure 1. Every life cycle model includes realization activities, principally, verification and validation activities. The way these activities are performed is dependent upon the life cycle model in use. (For additional information on life cycles, see the [[Life Cycle Models]] KA.) |
[[File:JS_Figure_1.png|thumb|600 px|center|'''Figure 1. System Realization.''' (SEBoK Original)]] | [[File:JS_Figure_1.png|thumb|600 px|center|'''Figure 1. System Realization.''' (SEBoK Original)]] | ||
| − | The realization processes are performed to ensure that the system will be ready | + | The realization processes are performed to ensure that the system will be ready for transition and has the appropriate structure and behavior to enable the desired operation and functionality throughout the system’s life span. Both DAU and NASA include transition in realization, in addition to implementation, integration, verification, and validation (Prosnik 2010; NASA December 2007, 1-360). |
==Fundamentals== | ==Fundamentals== | ||
| Line 43: | Line 30: | ||
[[File:JS_Figure_2.png|thumb|600px|center|'''Figure 2. The Vee Activity Diagram (Prosnik 2010).''' Released by the Defense Acquisition University (DAU)/U.S. Department of Defense (DoD).]] | [[File:JS_Figure_2.png|thumb|600px|center|'''Figure 2. The Vee Activity Diagram (Prosnik 2010).''' Released by the Defense Acquisition University (DAU)/U.S. Department of Defense (DoD).]] | ||
| − | The left side of the Vee model demonstrates the development of system elements specifications and design descriptions. In this stage, verification and validation plans are developed which are later used to determine whether realized system elements ( | + | The left side of the Vee model demonstrates the development of system elements specifications and design descriptions. In this stage, verification and validation plans are developed, which are later used to determine whether realized system elements ({{Term|Product (glossary)|products}}, {{Term|Service (glossary)|services}}, or {{Term|Enterprise (glossary)|enterprises}}) are compliant with specifications and {{Term|Stakeholder Requirement (glossary)|stakeholder requirements}}. Also, during this stage initial specifications become flow-down requirements for lower-level system models. In terms of time frame, these activities take place early in the system’s life cycle. These activities are discussed further in the [[System Definition]] KA. However, it is important to understand that some of the system realization activities are initiated at the same time as system definition activities; this is the case with integration, verification and validation planning in particular. |
| − | The right side of the Vee model, as illustrated in Figure 2, | + | The right side of the Vee model, as illustrated in Figure 2, shows the system elements (products, services, or enterprises) are assembled according to the system model described on the left side of the Vee (integration). Verification and validation activities determine how well the realized system fulfills the stakeholder requirements, the system requirements, and {{Term|Design Property (glossary)|design properties}}. These activities should follow the plans developed on the left side of the Vee. Integration can be done continuously, incrementally and/or iteratively, supported by verification and validation (V&V) efforts. For example, integration typically starts at the bottom of the Vee and continues upwards to the top of the Vee. |
| − | The U.S. Defense Acquisition University (DAU) provides | + | The U.S. Defense Acquisition University (DAU) provides an overview of what occurs during system realization: |
<blockquote>''Once the products of all system models have been fully defined, Bottom-Up End Product Realization can be initiated. This begins by applying the Implementation Process to buy, build, code or reuse end products. These implemented end products are verified against their design descriptions and specifications, validated against Stakeholder Requirements and then transitioned to the next higher system model for integration. End products from the Integration Process are successively integrated upward, verified and validated, transitioned to the next acquisition phase or transitioned ultimately as the End Product to the user.'' (Prosnik 2010)</blockquote> | <blockquote>''Once the products of all system models have been fully defined, Bottom-Up End Product Realization can be initiated. This begins by applying the Implementation Process to buy, build, code or reuse end products. These implemented end products are verified against their design descriptions and specifications, validated against Stakeholder Requirements and then transitioned to the next higher system model for integration. End products from the Integration Process are successively integrated upward, verified and validated, transitioned to the next acquisition phase or transitioned ultimately as the End Product to the user.'' (Prosnik 2010)</blockquote> | ||
| − | While the systems engineering (SE) technical processes are life cycle processes, the processes are concurrent, and the emphasis of the respective processes depends on the phase and maturity of the design. Figure 3 portrays (from left to right) a notional emphasis of the respective processes throughout the systems acquisition life cycle from the perspective of the U.S. Department of Defense (DoD). It is important to note that from this perspective, these processes do not follow a linear progression | + | While the systems engineering (SE) technical processes are life cycle processes, the processes are concurrent, and the emphasis of the respective processes depends on the phase and maturity of the design. Figure 3 portrays (from left to right) a notional emphasis of the respective processes throughout the systems acquisition life cycle from the perspective of the U.S. Department of Defense (DoD). It is important to note that from this perspective, these processes do not follow a linear progression; instead, they are concurrent, with the amount of activity in a given area changing over the system’s life cycle. The red boxes indicate the topics that will be discussed as part of realization. |
[[File:JS_Figure_3.png|thumb|600px|center|'''Figure 3. Notional Emphasis of Systems Engineering Technical Processes and Program Life-Cycle Phases (DAU 2010).''' Released by the Defense Acquisition University (DAU)/U.S. Department of Defense (DoD).]] | [[File:JS_Figure_3.png|thumb|600px|center|'''Figure 3. Notional Emphasis of Systems Engineering Technical Processes and Program Life-Cycle Phases (DAU 2010).''' Released by the Defense Acquisition University (DAU)/U.S. Department of Defense (DoD).]] | ||
| Line 66: | Line 53: | ||
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1. | INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1. | ||
| − | ISO/IEC/IEEE. | + | ISO/IEC/IEEE. 2015.''[[ISO/IEC/IEEE 15288|Systems and Software Engineering - System Life Cycle Processes]].''Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers. [[ISO/IEC/IEEE 15288]]:2015. |
| − | Martin, J.N. 1997. ''[[Systems Engineering Guidebook]]: A process for developing systems and products'' | + | Martin, J.N. 1997. ''[[Systems Engineering Guidebook]]: A process for developing systems and products,'' 1st ed. Boca Raton, FL, USA: CRC Press. |
NASA. 2007. ''[[NASA Systems Engineering Handbook|Systems Engineering Handbook]].'' Washington, D.C.: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105. | NASA. 2007. ''[[NASA Systems Engineering Handbook|Systems Engineering Handbook]].'' Washington, D.C.: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105. | ||
| Line 80: | Line 67: | ||
ECSS. 2009. ''Systems Engineering General Requirements''. Noordwijk, Netherlands: Requirements and Standards Division, European Cooperation for Space Standardization (ECSS), 6 March 2009. ECSS-E-ST-10C. | ECSS. 2009. ''Systems Engineering General Requirements''. Noordwijk, Netherlands: Requirements and Standards Division, European Cooperation for Space Standardization (ECSS), 6 March 2009. ECSS-E-ST-10C. | ||
| − | IEEE. 2012. "Standard for System and Software Verification and Validation". Institute of Electrical and Electronics Engineers. IEEE 1012. | + | IEEE. 2012. "Standard for System and Software Verification and Validation". Institute of Electrical and Electronics Engineers. IEEE-1012. |
---- | ---- | ||
<center>[[System Analysis|< Previous Article]] | [[Systems Engineering and Management|Parent Article]] | [[System Implementation|Next Article >]]</center> | <center>[[System Analysis|< Previous Article]] | [[Systems Engineering and Management|Parent Article]] | [[System Implementation|Next Article >]]</center> | ||
| − | + | <center>'''SEBoK v. 2.1, released 31 October 2019'''</center> | |
| − | |||
| − | |||
[[Category:Part 3]][[Category:Knowledge Area]] | [[Category:Part 3]][[Category:Knowledge Area]] | ||
Revision as of 09:06, 28 October 2019
Lead Authors: John Snoderly, Alan Faisandier, Contributing Author: Rick Adcock
System realization activities are conducted to create and test versions of a system as specified by system definition. The activities are grouped and described as generic processes that are performed iteratively and/or concurrently depending on the selected life cycle model. These activities include those required to build a system (system implementation), integrate disparate system elements (system integration), and ensure that the system meets both the needs of stakeholders (system validation) and aligns with the system requirements and architecture (system verification).
These activities are not sequential, but are performed concurrently, iteratively and recursively depending on the selected life cycle model. Figure 1 (see "Overview", below), also shows how these processes fit within the context of system definition and System Deployment and Use KAs. See also Applying Life Cycle Processes for further discussion of the relationships between process and life cycle model.
Topics
Each part of the SEBoK is divided into KAs, which are groupings of information with a related theme. The KAs in turn are divided into topics. This KA contains the following topics:
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.
Overview
Essentially, the outputs of system definition are used during system implementation to create system elements and during system integration to provide plans and criteria for combining these elements. The requirements are used to verify and validate system elements, systems, and the overall system-of-interest (SoI). These activities provide feedback into the system design, particularly when problems or challenges are identified.
Finally, when the system is considered, verified, and validated, it will then become an input to system deployment and use. It is important to understand that there is overlap in these activities; they do not have to occur in sequence as demonstrated in Figure 1. Every life cycle model includes realization activities, principally, verification and validation activities. The way these activities are performed is dependent upon the life cycle model in use. (For additional information on life cycles, see the Life Cycle Models KA.)
The realization processes are performed to ensure that the system will be ready for transition and has the appropriate structure and behavior to enable the desired operation and functionality throughout the system’s life span. Both DAU and NASA include transition in realization, in addition to implementation, integration, verification, and validation (Prosnik 2010; NASA December 2007, 1-360).
Fundamentals
Macro View of Realization Processes
Figure 2 illustrates a macro view of generic outputs from realization activities when using a Vee life cycle model. The left side of the Vee represents various design activities 'going down' the system.
The left side of the Vee model demonstrates the development of system elements specifications and design descriptions. In this stage, verification and validation plans are developed, which are later used to determine whether realized system elements (products, services, or enterprises) are compliant with specifications and stakeholder requirements. Also, during this stage initial specifications become flow-down requirements for lower-level system models. In terms of time frame, these activities take place early in the system’s life cycle. These activities are discussed further in the System Definition KA. However, it is important to understand that some of the system realization activities are initiated at the same time as system definition activities; this is the case with integration, verification and validation planning in particular.
The right side of the Vee model, as illustrated in Figure 2, shows the system elements (products, services, or enterprises) are assembled according to the system model described on the left side of the Vee (integration). Verification and validation activities determine how well the realized system fulfills the stakeholder requirements, the system requirements, and design properties. These activities should follow the plans developed on the left side of the Vee. Integration can be done continuously, incrementally and/or iteratively, supported by verification and validation (V&V) efforts. For example, integration typically starts at the bottom of the Vee and continues upwards to the top of the Vee.
The U.S. Defense Acquisition University (DAU) provides an overview of what occurs during system realization:
Once the products of all system models have been fully defined, Bottom-Up End Product Realization can be initiated. This begins by applying the Implementation Process to buy, build, code or reuse end products. These implemented end products are verified against their design descriptions and specifications, validated against Stakeholder Requirements and then transitioned to the next higher system model for integration. End products from the Integration Process are successively integrated upward, verified and validated, transitioned to the next acquisition phase or transitioned ultimately as the End Product to the user. (Prosnik 2010)
While the systems engineering (SE) technical processes are life cycle processes, the processes are concurrent, and the emphasis of the respective processes depends on the phase and maturity of the design. Figure 3 portrays (from left to right) a notional emphasis of the respective processes throughout the systems acquisition life cycle from the perspective of the U.S. Department of Defense (DoD). It is important to note that from this perspective, these processes do not follow a linear progression; instead, they are concurrent, with the amount of activity in a given area changing over the system’s life cycle. The red boxes indicate the topics that will be discussed as part of realization.
References
Works Cited
DAU. 2010. Defense Acquisition Guidebook (DAG). Ft. Belvoir, VA, USA: Defense Acquisition University (DAU)/U.S. Department of Defense (DoD). February 19, 2010.
Prosnik, G. 2010. Materials from "Systems 101: Fundamentals of Systems Engineering Planning, Research, Development, and Engineering". DAU distance learning program. eds. J. Snoderly, B. Zimmerman. Ft. Belvoir, VA, USA: Defense Acquisition University (DAU)/U.S. Department of Defense (DoD).
Primary References
INCOSE. 2011. INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.
ISO/IEC/IEEE. 2015.Systems and Software Engineering - System Life Cycle Processes.Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.
Martin, J.N. 1997. Systems Engineering Guidebook: A process for developing systems and products, 1st ed. Boca Raton, FL, USA: CRC Press.
NASA. 2007. Systems Engineering Handbook. Washington, D.C.: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105.
Additional References
DAU. 2010. Defense Acquisition Guidebook (DAG). Ft. Belvoir, VA, USA: Defense Acquisition University (DAU)/U.S. Department of Defense (DoD). February 19, 2010.
DAU. Your Acquisition Policy and Discretionary Best Practices Guide. In Defense Acquisition University (DAU)/U.S. Department of Defense (DoD) [database online]. Ft Belvoir, VA, USA. Available at: https://dag.dau.mil/Pages/Default.aspx (accessed 2010).
ECSS. 2009. Systems Engineering General Requirements. Noordwijk, Netherlands: Requirements and Standards Division, European Cooperation for Space Standardization (ECSS), 6 March 2009. ECSS-E-ST-10C.
IEEE. 2012. "Standard for System and Software Verification and Validation". Institute of Electrical and Electronics Engineers. IEEE-1012.