Difference between pages "System Life Cycle Process Drivers and Choices" and "System Realization"

From SEBoK
(Difference between pages)
Jump to: navigation, search
(Tech and grammar edits as discussed with Bkcase)
 
(Tech and grammar edits as discussed with Bkcase)
 
Line 1: Line 1:
As discussed in the [[Generic Life Cycle Model]] article, there are many organizational factors that can impact which life cycle processes are appropriate for a specific system. Additionally, technical factors will also influence the types of life cycle models appropriate for a given system. For example, system requirements can either be predetermined or they can be changing, depending on the scope and nature of the development for a system. These considerations lead to different life cycle model selections. This article discusses different technical factors which can be considered when selecting a life cycle process model and provides examples, guidance and tools from the literature to support life cycle model selection.  The life cycle model selected can impact all other aspects of system design and development. (See the knowledge areas in Part 3 for a description of how the life cycle can impact systems engineering (SE) processes.)
+
{{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}}).  
  
==Fixed-Requirements and Evolutionary Development Processes==
+
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.
Aside from the traditional, pre-specified, sequential, single-step development process, there are several models of {{Term|Incremental (glossary)|incremental}} and {{Term|Evolutionary (glossary)|evolutionary}} development; however, there is no one-size-fits-all approach that is best for all situations. For rapid-fielding situations, an easiest-first, prototyping approach may be most appropriate. For enduring systems, an easiest-first approach may produce an unscalable system, in which the architecture is incapable of achieving high levels of performance, safety, or security. In general, system evolution now requires much higher sustained levels of SE effort, earlier and continuous integration and testing, proactive approaches to address sources of system change, greater levels of concurrent engineering, and achievement reviews based on evidence of feasibility versus plans and system descriptions.
+
==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:
Incremental and evolutionary development methods have been in use since the 1960s (and perhaps earlier). They allow a project to provide an initial capability followed by successive deliveries to reach the desired {{Term|System-of-Interest (glossary)|system-of-interest}} (SoI).  This practice is particularly valuable in cases in which
+
* [[System Implementation]]
 +
* [[System Integration]]
 +
* [[System Verification]]
 +
* [[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.
  
*  rapid exploration and implementation of part of the system is desired;
+
==Overview==
requirements are unclear from the beginning, or are rapidly changing;
+
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.  
*  funding is constrained;
 
*  the customer wishes to hold the SoI open to the possibility of inserting new technology when it becomes mature; and
 
*  experimentation is required to develop successive versions.
 
  
In iterative development, each cycle of the iteration subsumes the system elements of the previous iteration and adds new capabilities to the evolving product to create an expanded version of the software. Iterative development processes can provide a number of advantages, including
+
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.)
* continuous integration, verification, and validation of the evolving product;
 
* frequent demonstrations of progress;
 
* early detection of defects;
 
* early warning of process problems; and
 
* systematic incorporation of the inevitable rework that occurs in software development.
 
  
==Primary Models of Incremental and Evolutionary Development==
+
[[File:JS_Figure_1.png|thumb|600 px|center|'''Figure 1. System Realization.''' (SEBoK Original)]]
The primary models of incremental and evolutionary development focus on different competitive and technical challenges. The time phasing of each model is shown in Figure 1 below in terms of the increment (1, 2, 3, …) content with respect to the definition (Df), development (Dv), and production, support, and utilization (PSU) stages in Figure 1 (A Generic System Life Cycle Model) from the [[Life Cycle Models]] article.
 
  
[[File:Fig 1 Primary models of incremental and evolutionary development KF.png|thumb|450px|center|'''Figure 1. Primary Models of Incremental and Evolutionary Development.''' (SEBoK Original)]]
+
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).
  
The Figure 1 notations (Df1..N  and Dv1..N)  indicate that their initial stages produce specifications not just for the first increment, but for the full set of increments.  These are assumed to remain stable for the pre-specified sequential model but are expected to involve changes for the evolutionary concurrent model.  The latter’s notation ( Dv1 and Df2R) in the same time frame, PSU1, Dv2 and Df3R in the same time frame, etc.) indicates that the plans and specifications for the next increment are being re-baselined by a systems engineering team concurrently with the development of the current increment and the PSU of the previous increment.  This offloads the work of handling the change traffic from the development team and significantly improves its chances of finishing the current increment on budget and schedule.
+
==Fundamentals==
  
In order to select an appropriate life cycle model, it is important to first gain an understanding of the main archetypes and where they are best used. Table 1 summarizes each of the primary models of single-step, incremental and evolutionary development in terms of examples, strengths, and weaknesses, followed by explanatory notes.
+
===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.
|+'''Table 1. Primary Models of Incremental and Evolutionary Development (SEBoK Original).'''
 
!Model
 
!Examples
 
!Pros
 
!Cons
 
|-
 
|'''Pre-specified Single-step'''
 
|Simple manufactured products: Nuts, bolts, simple sensors
 
|Efficient, easy to verify
 
|Difficulties with rapid change, emerging requirements (complex sensors, human-intensive systems)
 
|-
 
|'''Pre-specified Multi-step'''
 
|Vehicle platform plus value-adding pre-planned product improvements (PPPIs)
 
|Early initial capability, scalability when stable
 
|Emergent requirements or rapid change, architecture breakers
 
|-
 
|'''Evolutionary Sequential'''
 
|Small: Agile
 
  
Larger: Rapid fielding
+
[[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).]]
|Adaptability to change, smaller human-intensive systems
 
|Easiest-first, late, costly fixes, systems engineering time gaps, slow for large systems
 
|-
 
|'''Evolutionary Opportunistic'''
 
|Stable development, Maturing technology
 
|Mature technology upgrades
 
|Emergent requirements or rapid change, SysE time gaps
 
|-
 
|'''Evolutionary Concurrent'''
 
|Rapid, emergent development, systems of systems
 
|Emergent requirements or rapid change, stable development increments, SysE continuity
 
|Overkill on small or highly stable systems
 
|}
 
  
The ''Pre-specified Single-step'' and ''Pre-specified Multi-step'' models from Table 1 are not evolutionary.  Pre-specified multi-step models split the development in order to field an early initial operational capability, followed by several pre-planned product improvements (P3Is). An alternate version splits up the work but does not field the intermediate increments. When requirements are well understood and stable, the pre-specified models enable a strong, predictable process. When requirements are emergent and/or rapidly changing, they often require expensive rework if they lead to undoing architectural commitments.
+
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 ''Evolutionary Sequential'' model involves an approach in which the initial operational capability for the system is rapidly developed and is upgraded based on operational experience. Pure agile software development fits this model. If something does not turn out as expected and needs to be changed, it will be fixed in thirty days at the time of its next release. Rapid fielding also fits this model for larger or hardware-software systems. Its major strength is to enable quick-response capabilities in the field. For pure agile, the model can fall prey to an easiest-first set of architectural commitments which break when, for example, system developers try to scale up the workload by a factor of ten or to add security as a new feature in a later increment. For rapid fielding, using this model may prove expensive when the quick mash-ups require extensive rework to fix incompatibilities or to accommodate off-nominal usage scenarios, but the rapid results may be worth it.
+
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 ''Evolutionary Opportunistic'' model can be adopted in cases that involve deferring the next increment until: a sufficiently attractive opportunity presents itself, the desired new technology is mature enough to be added, or until other enablers such as scarce components or key personnel become available. It is also appropriate for synchronizing upgrades of multiple commercial-off-the-shelf (COTS) products. It may be expensive to keep the SE and development teams together while waiting for the enablers, but again, it may be worth it.
+
The U.S. Defense Acquisition University (DAU) provides an overview of what occurs during system realization:
 
The ''Evolutionary Concurrent'' model involves a team of systems engineers concurrently handling the change traffic and re-baselining the plans and specifications for the next increment, in order to keep the current increment development stabilized.  An example and discussion are provided in Table 2, below.
 
  
==Incremental and Evolutionary Development Decision Table==
+
<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>
  
The Table 2 provides some criteria for deciding which of the processes associated with the primary classes of incremental and evolutionary development models to use.
+
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.
  
<center>
+
[[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).]]
{| 
 
|+'''Table 2. Incremental and Evolutionary Development Decision Table. (Boehm and Lane 2010).''' Reprinted with permission of the Systems Engineering Research Center. All other rights are reserved by the copyright owner.
 
|-
 
!Model
 
!Stable, pre-specifiable requirements?
 
!OK to wait for full system to be developed?
 
!Need to wait for next-increment priorities?
 
!Need to wait for next-increment enablers*?
 
|-
 
|'''Pre-specified Single-step'''
 
|Yes
 
|Yes
 
|
 
|
 
|-
 
|'''Pre-specified Multi-step'''
 
|Yes
 
|No
 
|
 
|
 
|-
 
|'''Evolutionary Sequential'''
 
|No
 
|No
 
|Yes
 
|
 
|-
 
|'''Evolutionary Opportunistic'''
 
|No
 
|No
 
|No
 
|Yes
 
|-
 
|'''Evolutionary Concurrent'''
 
|No
 
|No
 
|No
 
|No
 
|}
 
</center>
 
'''''<nowiki>*Example enablers: Technology maturity; External-system capabilities; Needed resources; New opportunities</nowiki>'''''
 
  
The ''Pre-specified Single-step'' process exemplified by the traditional waterfall or sequential Vee model is appropriate if the product’s requirements are pre-specifiable and have a low probability of significant change and if there is no value or chance to deliver a partial product capability. A good example of this would be the hardware for an earth resources monitoring satellite that would be infeasible to modify after it goes into orbit.
+
==References==
  
The ''Pre-specified Multi-step'' process splits up the development in order to field an early initial operational capability and several P3I's. It is best if the product’s full capabilities can be specified in advance and are at a low probability of significant change. This is useful in cases when waiting for the full system to be developed incurs a loss of important and deliverable incremental mission capabilities. A good example of this would be a well-understood and well-prioritized sequence of software upgrades for the on-board earth resources monitoring satellite.
+
===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.
 
   
 
   
The ''Evolutionary Sequential'' process develops an initial operational capability and upgrades it based on operational experience, as exemplified by agile methods. It is most needed in cases when there is a need to obtain operational feedback on an initial capability before defining and developing the next increment’s content. A good example of this would be the software upgrades suggested by experiences with the satellite’s payload, such as what kind of multi-spectral data collection and analysis capabilities are best for what kind of agriculture under what weather conditions.
+
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).
  
The ''Evolutionary Opportunistic'' process defers the next increment until its new capabilities are available and mature enough to be added. It is best used when the increment does not need to wait for operational feedback, but it may need to wait for next-increment enablers such as technology maturity, external system capabilities, needed resources, or new value-adding opportunities. A good example of this would be the need to wait for agent-based satellite anomaly trend analysis and mission-adaptation software to become predictably stable before incorporating it into a scheduled increment.
+
===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.
 
   
 
   
The ''Evolutionary Concurrent'' process, as realized in the incremental commitment spiral model (Pew and Mavor 2007; Boehm and Lane 2007) and shown in Figure 2, has a continuing team of systems engineers handling the change traffic and re-baselining the plans and specifications for the next increment, while also keeping a development team stabilized for on-time, high-assurance delivery of the current increment and employing a concurrent {{Term|Verification (glossary)|verification}} and {{Term|Validation (glossary)|validation}} (V&V) team to perform continuous defect detection to enable even higher assurance levels. A good example of this would be the satellite’s ground-based mission control and data handling software’s next-increment re-baselining to adapt to new COTS releases and continuing user requests for data processing upgrades.  
+
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.
  
The satellite example illustrates the various ways in which the complex systems of the future, different parts of the system, and its software may evolve in a number of ways, once again affirming that there is no one-size-fits-all process for software evolution. However, Table 2 can be quite helpful in determining which processes are the best fits for evolving each part of the system.  Additionally, the three-team model in Figure 2 provides a way for projects to develop the challenging software-intensive systems of the future that will need both adaptability to rapid change and high levels of assurance.
+
Martin, J.N. 1997. ''[[Systems Engineering Guidebook]]: A process for developing systems and products,'' 1st ed. Boca Raton, FL, USA: CRC Press.
  
[[File:KF_EvolutionaryConcurrentChange.png|frame|center|600px|'''Figure 2. Evolutionary-Concurrent Rapid Change Handling and High Assurance (Pew and Mavor 2007, Figure 2-6).''' Reprinted with permission from the National Academy of Sciences, Courtesy of National Academies Press, Washington, D.C. All other rights are reserved by the copyright owner.]]
+
NASA. 2007. ''[[NASA Systems Engineering Handbook|Systems Engineering Handbook]].'' Washington, D.C.: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105.
  
==References==  
+
===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.
  
===Works Cited===
+
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).
Boehm, B. 2006. “Some Future Trends and Implications for Systems and Software Engineering Processes.''Systems Engineering.'' 9(1): 1-19.
 
  
Boehm, B. and J. Lane. 2007. “Using the Incremental Commitment Model to Integrate System Acquisition, Systems Engineering, and Software Engineering.''CrossTalk.'' October 2007: 4-9.
+
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.
 
 
Boehm, B. and J. Lane. 2010. ''DoD Systems Engineering and Management Implications for Evolutionary Acquisition of Major Defense Systems.'' SERC RT-5 report, March 2010. USC-CSSE-2010-500.
 
 
 
Cusumano, M. and D. Yoffee. 1998. ''Competing on Internet Time: Lessons from Netscape and Its Battle with Microsoft.'' New York, NY, USA: Free Press.
 
 
 
Pew, R. and A. Mavor (eds.). 2007. ''Human-System Integration in the System Development Process: A New Look.''  Washington DC, USA: The National Academies Press.
 
 
 
===Primary References===
 
Pew, R., and A. Mavor (eds.). 2007. ''[[Human-System Integration in the System Development Process]]: A New Look''.  Washington, DC, USA: The National Academies Press.
 
 
 
===Additional References===
 
None.
 
  
 +
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>[[Life Cycle Models|< Previous Article]] | [[Life Cycle Models|Parent Article]] | [[System Life Cycle Process Models: Vee|Next Article >]]</center>
 
  
 
<center>'''SEBoK v. 2.0, released 1 June 2019'''</center>
 
<center>'''SEBoK v. 2.0, released 1 June 2019'''</center>
  
[[Category: Part 3]][[Category:Topic]]
+
[[Category:Part 3]][[Category:Knowledge Area]]
[[Category:Life Cycle Models]]
 

Revision as of 20:32, 19 October 2019

System realizationSystem realization activities are conducted to create and test versions of a system as specified by system definitionsystem definition. The activities are grouped and described as generic processes that are performed iteratively and/or concurrently depending on the selected life cycle modellife cycle model. These activities include those required to build a system (system implementationsystem implementation), integrate disparate system elements (system integrationsystem integration), and ensure that the system meets both the needs of stakeholders (system validationsystem validation) and aligns with the system requirements and architecture (system verificationsystem 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 definitionsystem 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 definitionsystem definition are used during system implementationsystem implementation to create system elementssystem elements and during system integrationsystem integration to provide plans and criteria for combining these elements. The requirements are used to verifyverify and validatevalidate system elements, systems, and the overall system-of-interestsystem-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.)

Figure 1. System Realization. (SEBoK Original)

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.

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 (productsproducts, servicesservices, or enterprisesenterprises) are compliant with specifications and stakeholder requirementsstakeholder 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 propertiesdesign 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.

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).

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.


< Previous Article | Parent Article | Next Article >
SEBoK v. 2.0, released 1 June 2019