Difference between revisions of "System Life Cycle Process Drivers and Choices"

From SEBoK
Jump to navigation Jump to search
m (Text replacement - "SEBoK v. 2.9, released 13 November 2023" to "SEBoK v. 2.9, released 20 November 2023")
(142 intermediate revisions by 10 users not shown)
Line 1: Line 1:
System requirements can be predetermined, or they can be changing, depending on the scope and nature of the development of a given system. These considerations lead to different life cycle model selections.
+
----
 +
'''''Lead Authors:''''' ''Kevin Forsberg, Rick Adcock''
 +
----
 +
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.)
  
 
==Fixed-Requirements and Evolutionary Development Processes==
 
==Fixed-Requirements and Evolutionary Development Processes==
 +
Aside from the traditional, pre-specified, sequential, single-step development process (identified as Fixed Requirements), there are several models of  {{Term|Evolutionary (glossary)|evolutionary}} development processes; 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.
 +
 +
Evolutionary development processes or 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
  
The need for rapid adaptation to unforeseen changes has caused many organizations to emphasize evolutionary development as compared with traditional development to a fixed set of requirements. Yet, there are still significant areas in which development driven by fixed requirements is appropriate. This section identifies the primary development and evolution options and decision criteria for choosing among them.
+
rapid exploration and implementation of part of the system is desired;
 
+
*  requirements are unclear from the beginning, or are rapidly changing;
Traditionally, system evolution has been an “operations and support” activity that took place after system development had put a system in place. There were separate budgets, teams, and procedures for doing it. However, the pace of change in technology and competition (Cusumano and Yoffee 1998) has changed the nature of system evolution to be a continuous process, in which there is no neat boundary between development and evolution (Boehm 2006; Pew and Mavor 2007).
+
* funding is constrained;
 
+
* the customer wishes to hold the SoI open to the possibility of inserting new technology when it becomes mature; and
There are several forms of [[Incremental (glossary)|incremental (glossary)]] and evolutionary development. Much as one would like there to be, there is no one-size-fits-all system evolution approach that is best for all situations. For rapid-fielding situations, an easiest-first, “get something working quickly and productize it later” approach is best. But for enduring systems, an easiest-first approach is likely to produce an unscalable system whose architecture is incompatible with achieving high levels of performance, safety, or security.  In general, system evolution now requires much higher sustained levels of systems engineering effort, earlier and continuous integration and test, proactive approaches to address sources of system change, greater levels of concurrent engineering, and achievement reviews based on evidence of feasibility versus evidence of plans, activity, and system descriptions.
+
* experimentation is required to develop successive versions.
 
 
Also, many traditional outsourcing practices are incompatible with effective evolutionary system development. These include “total package procurement” assumptions that full-capability requirements can be specified up front along with associated full-capability plans, budgets, schedules, work breakdown structures, and earned-value management targets. This type of development leads to assumptions that most systems engineers can be dismissed after the system’s Preliminary Design Review (PDR) or equivalent and that requirements change or “creep” should be discouraged.
 
 
 
There are several forms of incremental and evolutionary development, each of which meets different competitive challenges. The time phasing of each form is expressed in terms of the increment (1, 2, 3, …) content with respect to the stages in Figure 1 of Concept, Development, Production, and Utilization (including Support) or “CDPU.
 
  
 +
In evolutionary development a capability of the product is developed in an increment of time.  Each cycle of the increment subsumes the system elements of the previous increment and adds new capabilities to the evolving product to create an expanded version of the product in development. This evolutionary development process, that uses increments, can provide a number of advantages, including
 +
* 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 may occur.
  
*Prespecified Single-Step: CDPU
+
==Primary Models of Incremental and Evolutionary Development==
 +
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.
  
*Prespecified Sequential: CD; PU1; PU2; PU3; …
+
[[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)]]
  
*Evolutionary Sequential: CDPU1; CDPU2; CDPU3; …
+
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.
  
*Evolutionary Overlapped:
+
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.  
****CDPU 1;
 
******CDPU 2;
 
********CDPU 3
 
*********…
 
*Evolutionary Concurrent:
 
*****C; D1;  U1
 
*******C2; D2; U2
 
*********C3; D3; U3
 
************
 
 
Table 1 summarizes each, followed by explanatory notes.  The Incremental and Evolutionary Development models shown are represented in terms of the various ways they sequence the primary system development activities: system scoping (determining the system boundaries), system architecting (concurrently defining the system’s requirements, architecture, and life cycle plans), and system development, production, and operation.
 
  
<center>
+
{| '
{|
+
|+'''Table 1. Primary Models of Incremental and Evolutionary Development (Boehm, et. al. 2014, page 73).'''
|+'''Table 1. Forms of Incremental and Evolutionary Development (Boehm and Lane 2010)'''.  Reprinted with permission of the Systems Engineering Research Center (SERC).
+
!Model
!Type
 
 
!Examples
 
!Examples
!Strengths
+
!Pros
!Weakness (Cannot Easily Handle)
+
!Cons
 
|-
 
|-
|'''Pre-specified Single-Step'''
+
|'''Pre-specified Single-step'''
|Stable, precedented manufacturing
+
|Simple manufactured products: Nuts, bolts, simple sensors
|Stable, efficient
+
|Efficient, easy to verify
|Emerging requirements or rapid change
+
|Difficulties with rapid change, emerging requirements (complex sensors, human-intensive systems)
 
|-
 
|-
|'''Pre-specified Sequential'''
+
|'''Pre-specified Multi-step'''
|Platform base plus pre-planned product improvements (P3Is)
+
|Vehicle platform plus value-adding pre-planned product improvements (PPPIs)
|Stable, efficient; earlier initial capability
+
|Early initial capability, scalability when stable
|Emergent requirements or rapid change
+
|Emergent requirements or rapid change, architecture breakers
 
|-
 
|-
 
|'''Evolutionary Sequential'''
 
|'''Evolutionary Sequential'''
Line 55: Line 52:
  
 
Larger: Rapid fielding
 
Larger: Rapid fielding
|Adaptability to change; feedback from users
+
|Adaptability to change, smaller human-intensive systems
|Easiest-first; late, costly fixes; systems engineering time gaps; slow for large systems
+
|Easiest-first, late, costly fixes, systems engineering time gaps, slow for large systems
 
|-
 
|-
|'''Evolutionary Overlapped'''
+
|'''Evolutionary Opportunistic'''
|Stable development; need to wait for maturing enablers
+
|Stable development, Maturing technology
|Mature technology upgrades; synchronized multi-COTS refresh
+
|Mature technology upgrades
|Emergent requirements or rapid change; systems engineering time gaps
+
|Emergent requirements or rapid change, SysE time gaps
 
|-
 
|-
 
|'''Evolutionary Concurrent'''
 
|'''Evolutionary Concurrent'''
|Rapid, emergent development; systems of systems
+
|Rapid, emergent development, systems of systems
|High assurance with emergent requirements or rapid change; Systems Engineering continuity
+
|Emergent requirements or rapid change, stable development increments, SysE continuity
|Highly coupled systems with very rapid change
+
|Overkill on small or highly stable systems
 
|}
 
|}
</center>
 
  
The Prespecified Single-Step and Prespecified Sequential models are not evolutionary.  Prespecified Sequential just splits up the development in order to field an early Initial Operational Capability, followed by several Pre-Planned Product Improvements (P3Is). When requirements are pre-specifiable and stable, they 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 ''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.
  
With the Evolutionary Sequential model the system develops rapidly to initial operational capability and is upgraded based on operational experience. Pure agile software development fits this model: If something is wrong, it will be fixed in 30 days in the next release. Rapid fielding also fits this model for larger or hardware-software systems. Its strength is allowing 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 add security as a new feature in a later increment. For rapid fielding, using this model may prove expensive as SE and development teams must stay together and wait for feedback from users, but the cost may be worth it.
+
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.
  
"Evolutionary overlapped" covers the special case of deferring the next increment until 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 ''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 ''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.
  
"Evolutionary concurrent" has the systems engineers handling the change traffic and rebaselining the plans and specifications for the next increment, while keeping the development stabilized for the current increment. An example and discussion are provided in Table 2.
+
==Incremental and Evolutionary Development Decision Table==
  
==Life Cycle Process Decision Table==
+
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.
  
The decision table in Table 2 provides criteria for deciding which of the four primary classes of incremental and evolutionary development to use, plus the choice of single-step development.
+
<center>
 
+
{|
{| style="text-align: center"
+
|+'''Table 2. Incremental and Evolutionary Development Decision Table. (Boehm, et. al., 2014, page 74).''' Reprinted with permission.  
|+'''Table 2. Incremental and Evolutionary Development Decision Table (Boehm and Lane 2010).''' Reprinted with permission of the Systems Engineering Research Center (SERC).
+
|-
!Type
+
!Model
 
!Stable, pre-specifiable requirements?  
 
!Stable, pre-specifiable requirements?  
 
!OK to wait for full system to be developed?
 
!OK to wait for full system to be developed?
 
!Need to wait for next-increment priorities?
 
!Need to wait for next-increment priorities?
!Need to wait for next-increment enablers?
+
!Need to wait for next-increment enablers*?
 
|-
 
|-
|'''Single Step'''
+
|'''Pre-specified Single-step'''
 
|Yes
 
|Yes
 
|Yes
 
|Yes
Line 96: Line 94:
 
|
 
|
 
|-
 
|-
|'''Pre-specified Sequential'''
+
|'''Pre-specified Multi-step'''
 
|Yes
 
|Yes
 
|No
 
|No
Line 108: Line 106:
 
|
 
|
 
|-
 
|-
|'''Evolutionary Overlapped'''
+
|'''Evolutionary Opportunistic'''
 
|No
 
|No
 
|No
 
|No
Line 120: Line 118:
 
|No
 
|No
 
|}
 
|}
*Enablers: Technology maturity; external-system capabilities; needed resources; other
+
</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.
  
The single-step-to-full-capability process exemplified by the traditional waterfall or sequential Vee model is appropriate if the product’s requirements are prespecifiable 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 would be the hardware for an earth resources monitoring satellite whose altitude is too high for practical modification.
+
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.
 +
 +
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.
  
The pre-specified sequential process splits up the development in order to field an early initial operational capability and several pre-planned product improvements (P3Is)It is best if the product’s requirements are prespecifiable and have a low probability of significant change; and if waiting for the full system to be developed incurs a loss of important and deliverable incremental mission capabilities. A good example would be a well-understood and well-prioritized sequence of software upgrades for the on-board earth resources monitoring capabilities of the high-altitude satellite.
+
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.
 +
   
 +
The ''Evolutionary Concurrent'' process, as realized in the incremental commitment spiral model (Pew and Mavor 2007; Boehm, et.al., 2014, page 75) 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.  
  
The evolutionary sequential process develops an initial operational capability and upgrades it based on operational experience, as exemplified by agile methods. It is best when there is a need to get operational feedback on an initial capability before defining and developing the next increment’s content. A good example would be the software upgrades suggested by experiences with the satellite’s payload, such as what kind of multispectral data collection and analysis capabilities are best for what kind of agriculture under what weather conditions.
+
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.
  
The evolutionary overlapped process defers the next increment until its needed capabilities are available and mature enough to be added. It is best 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, or needed resources.  A good example 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.
+
[[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.]]
 
 
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 rebaselining the plans and specifications for the next increment, while keeping a development team stabilized for on-time, high-assurance delivery of the current increment, and employing a concurrent [[Verification (glossary)|verification (glossary)]] and [[Validation (glossary)|validation (glossary)]] [[Acronyms |(V&V)]] team to perform continuous defect detection to enable even higher assurance levels.  A good example would be the satellite’s ground-based mission control software’s rebaselining to adapt to new COTS releases and continuing user requests for data processing upgrades.
 
 
 
The satellite example shows that for the complex systems of the future, different parts of the system and its software may evolve in different ways, again indicating that there will be no one-size-fits-all process for software evolution. However, the decision table 2 can be quite helpful in determining which processes are the best fits for evolving each part of the system, and 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.
 
 
 
[[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.]]
 
  
 
==References==  
 
==References==  
Line 146: Line 144:
  
 
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.
 
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.
 +
 +
Boehm, B., J. Lane, S. Koolmanojwong, and R. Turner. 2014. ''The Incremental Commitment Spiral Model: Principles and Practices for Successful Systems and Software''. Indianapolis, IN, USA: Addison-Wesley.
  
 
Cusumano, M. and D. Yoffee. 1998. ''Competing on Internet Time: Lessons from Netscape and Its Battle with Microsoft.'' New York, NY, USA: Free Press.
 
Cusumano, M. and D. Yoffee. 1998. ''Competing on Internet Time: Lessons from Netscape and Its Battle with Microsoft.'' New York, NY, USA: Free Press.
Line 152: Line 152:
  
 
===Primary References===
 
===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.
+
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===
 
===Additional References===
Boehm, B. 2006. “Some Future Trends and Implications for Systems and Software Engineering Processes.” ''Systems Engineering'' 9(1): 1-19.
+
None.
 
 
Boehm, B. and J. Lane. 2007. “Using the Incremental Commitment Model to Integrate System Acquisition, Systems Engineering, and Software Engineering.” ''CrossTalk.'' October 2007: p. 4-9.
 
 
 
Boehm, B. and J. Lane. ''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.
 
  
 
----
 
----
  
<center>[[Life Cycle Characteristics|< Previous Article]] | [[Life Cycle Models|Parent Article]] | [[System Life Cycle Process Models: Vee|Next Article >]]</center>
+
<center>[[System Lifecycle Models|< Previous Article]] | [[System Lifecycle Models|Parent Article]] | [[System Life Cycle Process Models: Vee|Next Article >]]</center>
 
 
==Comments from SEBok 0.5 Wiki==
 
No comments were logged for this article in the SEBoK 0.5 wiki.  Because of this, it is especially important for reviewers to provide feedback on this article.  Please see the discussion prompts below.
 
 
 
{{DISQUS}}
 
  
 +
<center>'''SEBoK v. 2.9, released 20 November 2023'''</center>
  
[[Category: Part 3]][[Category:Topic]]
+
[[Category: Part 3]]
 +
[[Category:Topic]]
 
[[Category:Life Cycle Models]]
 
[[Category:Life Cycle Models]]

Revision as of 23:26, 18 November 2023


Lead Authors: Kevin Forsberg, Rick Adcock


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

Fixed-Requirements and Evolutionary Development Processes

Aside from the traditional, pre-specified, sequential, single-step development process (identified as Fixed Requirements), there are several models of evolutionaryevolutionary development processes; 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.

Evolutionary development processes or 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 system-of-interestsystem-of-interest (SoI). This practice is particularly valuable in cases in which

  • rapid exploration and implementation of part of the system is desired;
  • requirements are unclear from the beginning, or are rapidly changing;
  • 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 evolutionary development a capability of the product is developed in an increment of time. Each cycle of the increment subsumes the system elements of the previous increment and adds new capabilities to the evolving product to create an expanded version of the product in development. This evolutionary development process, that uses increments, can provide a number of advantages, including

  • 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 may occur.

Primary Models of Incremental and Evolutionary Development

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.

Figure 1. Primary Models of Incremental and Evolutionary Development. (SEBoK Original)

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.

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.

Table 1. Primary Models of Incremental and Evolutionary Development (Boehm, et. al. 2014, page 73).
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

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

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.

Table 2. Incremental and Evolutionary Development Decision Table. (Boehm, et. al., 2014, page 74). Reprinted with permission.
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

*Example enablers: Technology maturity; External-system capabilities; Needed resources; New opportunities

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.

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.

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.

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.

The Evolutionary Concurrent process, as realized in the incremental commitment spiral model (Pew and Mavor 2007; Boehm, et.al., 2014, page 75) 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 verificationverification and validationvalidation (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.

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.

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.

References

Works Cited

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.

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.

Boehm, B., J. Lane, S. Koolmanojwong, and R. Turner. 2014. The Incremental Commitment Spiral Model: Principles and Practices for Successful Systems and Software. Indianapolis, IN, USA: Addison-Wesley.

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.


< Previous Article | Parent Article | Next Article >
SEBoK v. 2.9, released 20 November 2023