Difference between pages "System Life Cycle Process Models: Vee" and "System Life Cycle Process Drivers and Choices"

From SEBoK
(Difference between pages)
Jump to: navigation, search
(Robot improving glossary links)
 
(Tech and grammar edits as discussed with Bkcase)
 
Line 1: Line 1:
There are a large number of [[Life Cycle Models|life cycle process models]]. As discussed in the [[System Life Cycle Process Drivers and Choices]] article, these models fall into three major categories: (1) primarily pre-specified and sequential processes; (2) primarily evolutionary and concurrent processes (e.g., the rational unified process and various forms of the Vee and spiral models); and (3) primarily interpersonal and unconstrained processes (e.g., agile development, Scrum, extreme programming (XP), the dynamic system development method, and innovation-based processes).
+
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.)
  
This article specifically focuses on the Vee Model as the primary example of pre-specified and sequential processes. In this discussion, it is important to note that the Vee model, and variations of the Vee model, all address the same basic set of systems engineering (SE) activities. The key difference between these models is the way in which they group and represent the aforementioned SE activities.
+
==Fixed-Requirements and Evolutionary Development Processes==
 
+
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.
General implications of using the Vee model for system design and development are discussed below; for a more specific understanding of how this life cycle model impacts systems engineering activities, please see the other knowledge areas (KAs) in Part 3.
 
 
 
==A Primarily Pre-specified and Sequential Process Model: The Vee Model==
 
The sequential version of the Vee Model is shown in Figure 1. Its core involves a sequential progression of plans, specifications, and products that are baselined and put under configuration management. The vertical, two-headed arrow enables projects to perform concurrent opportunity and risk analyses, as well as continuous in-process validation. The Vee Model encompasses the first three life cycle stages listed in the "Generic Life Cycle Stages" table of the INCOSE ''Systems Engineering Handbook'': exploratory research, concept, and development (INCOSE 2012).
 
 
   
 
   
[[File:KF_VeeModel_Left.png|thumb|1200px|center|'''Figure 1. Left Side of the Sequential Vee Model (Forsberg, Mooz, and Cotterman 2005).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.]]
+
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
  
The Vee Model endorses the INCOSE ''Systems Engineering Handbook'' (INCOSE 2012) definition of life cycle stages and their purposes or activities, as shown in Figure 2 below.  
+
*  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.
  
[[File:Fig_2_Life_Cycle_Stages_Vee_KF.png|thumb|500px|center|'''Figure 2. An Example of Stages, Their Purposes and Major Decision Gates.''' (SEBoK Original)]]
+
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
 +
* 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.
  
The INCOSE ''Systems Engineering Handbook'' 3.2.2 contains a more detailed version of the Vee diagram (2012, Figures 3-4, p. 27) which incorporates life cycle activities into the more generic Vee model. A similar diagram, developed at the U.S. Defense Acquisition University (DAU), can be seen in Figure 3 below.
+
==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.
  
[[File:JS_Figure_2.png|thumb|600px|center|'''Figure 3. The Vee Activity Diagram (Prosnik 2010).''' Released by the Defense Acquisition University (DAU)/U.S. Department of Defense (DoD).]]  
+
[[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)]]
  
===Application of the Vee Model===
+
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.  
Lawson (Lawson 2010) elaborates on the activities in each life cycle stage and notes that it is useful to consider the structure of a generic life cycle stage model for any type of system-of-interest (SoI) as portrayed in Figure 4. This '''(T)''' model indicates that one or more definition stages precede a production stage(s) where the implementation (acquisition, provisioning, or development) of two or more system elements has been accomplished.
 
  
[[File:KF_GenericStageStructure.png|frame|center|600px|'''Figure 4. Generic (T) Stage Structure of System Life Cycle Models (Lawson 2010).''' Reprinted with permission of Harold Lawson. All other rights are reserved by the copyright owner.]]
+
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.  
 
Figure 5 shows the generic life cycle stages for a variety of stakeholders, from a standards organization (ISO/IEC) to commercial and government organizations. Although these stages differ in detail, they all have a similar sequential format that emphasizes the core activities as noted in Figure 2 (definition, production, and utilization/retirement).
 
  
[[File:Comparisons_of_life_cycle_models.PNG|frame|center|500px|'''Figure 5. Comparisons of Life Cycle Models (Forsberg, Mooz, and Cotterman 2005).''' Reprinted with permission of John Wiley & Sons. All other rights are reserved by the copyright owner.]]
+
{|  '
 +
|+'''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
  
It is important to note that many of the activities throughout the life cycle are iterated. This is an example of {{Term|Recursion (glossary)|recursion (glossary)}} as discussed in the [[Systems Engineering and Management|Part 3 Introduction]].
+
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
 +
|}
  
==Fundamentals of Life Cycle Stages and Program Management Phase==
+
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.
  
For this discussion, it is important to note that
+
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 term '''{{Term|Stage (glossary)|stage}}''' refers to the different states of a system during its life cycle; some stages may overlap in time, such as the utilization stage and the support stage. The term “stage” is used in [[ISO/IEC/IEEE 15288]].
+
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.
  
*The term '''phase''' refers to the different steps of the program that support and manage the life of the system; the phases usually do not overlap. The term “phase” is used in many well-established models as an equivalent to the term “stage.”
+
==Incremental and Evolutionary Development Decision Table==
  
{{Term|Program Management (glossary)|Program management}} employs phases, {{Term|Milestone (glossary)|milestones}}, and {{Term|Decision Gate (glossary)|decision gates}} which are used to assess the evolution of a system through its various stages. The stages contain the activities performed to achieve goals and serve to control and manage the sequence of stages and the transitions between each stage. For each project, it is essential to define and publish the terms and related definitions used on respective projects to minimize confusion.
+
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.
  
A typical {{Term|Program (glossary)|program}} is composed of the following phases:
+
<center>
 +
{|
 +
|+'''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-study phase''', which identifies potential opportunities to address user needs with new solutions that make business sense.
+
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 '''feasibility phase''' consists of studying the feasibility of alternative concepts to reach a second decision gate before initiating the execution stage. During the feasibility phase, stakeholders' requirements and system requirements are identified, viable solutions are identified and studied, and virtual {{Term|prototype (glossary)|prototypes (glossary)}} can be implemented. During this phase, the decision to move forward is based on
 
**whether a concept is feasible and is considered able to counter an identified threat or exploit an opportunity;
 
**whether a concept is sufficiently mature to warrant continued development of a new product or line of products; and
 
**whether to approve a proposal generated in response to a request for proposal.
 
*The '''execution phase''' includes activities related to four stages of the system life cycle: ''development, production, utilization, and support''. Typically, there are two decision gates and two milestones associated with execution activities. The first milestone provides the opportunity for management to review the plans for execution before giving the go-ahead. The second milestone provides the opportunity to review progress before the decision is made to initiate production. The decision gates during execution can be used to determine whether to produce the developed SoI and whether to improve it or retire it.
 
  
These program management views apply not only to the SoI, but also to its elements and structure.
+
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.
 
+
==Life Cycle Stages==
+
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.
Variations of the Vee model deal with the same general stages of a life cycle:
 
*New projects typically begin with an exploratory research phase which generally includes the activities of [[Concept Definition|concept definition]], specifically the topics of [[Business or Mission Analysis|business or mission analysis]] and the understanding of [[Stakeholder Needs and Requirements|stakeholder needs and requirements]]. These mature as the project goes from the exploratory stage to the concept stage to the development stage.
 
*The production phase includes the activities of [[System Definition|system definition]] and [[System Realization|system realization]], as well as the development of the system {{Term|System Requirement (glossary)|requirements (glossary)}} and {{Term|Architecture (glossary)|architecture (glossary)}} through [[System Verification|verification]] and [[System Validation|validation]].
 
*The utilization phase includes the activities of [[System Deployment|system deployment]] and [[Operation of the System|system operation]].
 
*The support phase includes the activities of [[System Maintenance|system maintenance]], [[Logistics|logistics]], and [[Product and Service Life Management|product and service life management]], which may include activities such as [[Service Life Extension|service life extension]] or [[Capability Updates, Upgrades, and Modernization|capability updates, upgrades, and modernization]].
 
*The retirement phase includes the activities of [[Disposal and Retirement|disposal and retirement]], though in some models, activities such as [[Service Life Extension|service life extension]] or [[Capability Updates, Upgrades, and Modernization|capability updates, upgrades, and modernization]] are grouped into the "retirement" phase.
 
 
 
Additional information on each of these stages can be found in the sections below (see links to additional Part 3 articles above for further detail). It is important to note that these life cycle stages, and the activities in each stage, are supported by a set of [[Systems Engineering Management|systems engineering management processes]].
 
 
 
===Exploratory Research Stage===
 
[[Stakeholder Needs and Requirements|User requirements]] analysis and agreement is part of the exploratory research stage and is critical to the development of successful systems. Without proper understanding of the user needs, any system runs the risk of being built to solve the wrong problems. The first step in the exploratory research phase is to define the user (and stakeholder) requirements and constraints. A key part of this process is to establish the feasibility of meeting the user requirements, including technology readiness assessment. As with many SE activities this is often done iteratively, and stakeholder needs and requirements are revisited as new information becomes available.
 
 
 
A recent study by the National Research Council (National Research Council 2008) focused on reducing the development time for US Air Force projects. The report notes that, “simply stated, systems engineering is the translation of a user’s needs into a definition of a system and its architecture through an iterative process that results in an effective system design.” The iterative involvement with stakeholders is critical to the project success.
 
  
Except for the first and last decision gates of a project, the gates are performed simultaneously. See Figure 6 below.
+
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.
 
   
 
   
[[File:KF_SchedulingDevelopment.png|800px|thumb|center|'''Figure 6. Scheduling the Development Phases.''' (SEBoK Original)]]
+
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.  
 
 
===Concept Stage===
 
During the [[Concept Definition|concept stage]], alternate concepts are created to determine the best approach to meet stakeholder needs. By envisioning alternatives and creating models, including appropriate prototypes, stakeholder needs will be clarified and the driving issues highlighted. This may lead to an incremental or evolutionary approach to system development. Several different concepts may be explored in parallel.
 
 
 
===Development Stage===
 
The selected concept(s) identified in the concept stage are elaborated in detail down to the lowest level to produce the solution that meets the {{Term|Stakeholder Requirement (glossary)|stakeholder requirements}}. Throughout this stage, it is vital to continue with user involvement through in-process validation (the upward arrow on the Vee models). On hardware, this is done with frequent program reviews and a customer resident representative(s) (if appropriate). In agile development, the practice is to have the customer representative integrated into the development team.
 
 
 
===Production Stage===
 
The production stage is where the SoI is built or manufactured. Product modifications may be required to resolve production problems, to reduce production costs, or to enhance product or SoI capabilities. Any of these modifications may influence system requirements and may require system re-{{Term|qualification (glossary)|qualification}}, re-{{Term|verification (glossary)|verification}}, or re-{{Term|validation (glossary)|validation}}. All such changes require SE assessment before changes are approved.
 
 
 
===Utilization Stage===
 
A significant aspect of product life cycle management is the provisioning of supporting systems which are vital in sustaining operation of the product. While the supplied product or service may be seen as the narrow system-of-interest (NSOI) for an {{Term|Acquirer (glossary)|acquirer}}, the acquirer also must incorporate the supporting systems into a wider system-of-interest (WSOI). These supporting systems should be seen as system assets that, when needed, are activated in response to a situation that has emerged in respect to the operation of the NSOI. The collective name for the set of supporting systems is the integrated logistics support (ILS) system.
 
 
 
It is vital to have a holistic view when defining, producing, and operating system products and services.  In Figure 7, the relationship between system design and development and the ILS requirements is portrayed.
 
 
 
[[File:KF_ILSSystemLifeCycle.png|frame|center|1100px|'''Figure 7. Relating ILS to the System Life Cycle (Eichmueller and Foreman 2009)'''.  Reprinted with permission of of ASD/AIA S3000L Steering Committee. All other rights are reserved by the copyright owner.]]
 
 
 
The requirements for reliability, resulting in the need of maintainability and testability, are driving factors.
 
 
 
===Support Stage===
 
In the support stage, the SoI is provided services that enable continued operation.  Modifications may be proposed to resolve supportability problems, to reduce operational costs, or to extend the life of a system. These changes require SE assessment to avoid loss of system capabilities while under operation. The corresponding technical process is the maintenance process.
 
 
 
===Retirement Stage ===
 
In the retirement stage, the SoI and its related services are removed from operation. SE activities in this stage are primarily focused on ensuring that disposal requirements are satisfied. In fact, planning for disposal is part of the system definition during the concept stage. Experiences in the 20th century repeatedly demonstrated the consequences when system retirement and disposal was not considered from the outset. Early in the 21st century, many countries have changed their laws to hold the creator of a SoI accountable for proper end-of-life disposal of the system.
 
  
==Life Cycle Reviews==
+
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.
  
To control the progress of a project, different types of reviews are planned. The most commonly used are listed as follows, although the names are not universal:
+
[[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 '''system requirements review''' (SRR) is planned to verify and validate the set of system requirements before starting the detailed design activities.
 
*The {{Term|Preliminary Design Review (PDR) (glossary)|preliminary design review}} (PDR) is planned to verify and validate the set of system requirements, the design artifacts, and justification elements at the end of the first engineering loop (also known as the "design-to" gate).
 
*The {{Term|Critical Design Review (CDR) (glossary)|critical design review}} (CDR) is planned to verify and validate the set of system requirements, the design artifacts, and justification elements at the end of the last engineering loop (the “build-to” and “code-to” designs are released after this review).
 
*The {{Term|integration (glossary)|integration}}, {{Term|verification (glossary)|verification}}, and {{Term|validation (glossary)|validation}} reviews are planned as the components are assembled into higher level subsystems and elements. A sequence of reviews is held to ensure that everything integrates properly and that there is objective evidence that all requirements have been met. There should also be an in-process validation that the system, as it is evolving, will meet the stakeholders’ requirements (see Figure 7).
 
*The final validation review is carried out at the end of the integration phase.
 
*Other management related reviews can be planned and conducted in order to control the correct progress of work, based on the type of system and the associated risks.
 
  
[[File:KF_VeeModel_Right.png|frame|center|600px|'''Figure 8. Right Side of the Vee Model (Forsberg, Mooz, and Cotterman 2005).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.]]
+
==References==
  
==References==
 
  
 
===Works Cited===
 
===Works Cited===
Eichmueller, P. and B. Foreman. 2010. ''S3000LTM''. Brussels, Belgium: Aerospace and Defence Industries Association of Europe (ASD)/Aerospace Industries Association (AIA).
+
Boehm, B. 2006. “Some Future Trends and Implications for Systems and Software Engineering Processes.''Systems Engineering.'' 9(1): 1-19.
  
Faisandier, A. 2012. ''Systems Architecture and Design''. Belberaud, France: Sinergy'Com.
+
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.
  
Forsberg, K., H. Mooz, and H. Cotterman. 2005. ''Visualizing Project Management,'' 3rd ed. New York, NY, USA: J. Wiley & Sons.
+
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.
  
INCOSE. 2012. ''Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities,'' version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.
+
Cusumano, M. and D. Yoffee. 1998. ''Competing on Internet Time: Lessons from Netscape and Its Battle with Microsoft.'' New York, NY, USA: Free Press.
  
Lawson, H. 2010. ''A Journey Through the Systems Landscape.'' London, UK: College Publications, Kings College, UK.
+
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===
 
===Primary References===
Beedle, M., et al. 2009. "[[The Agile Manifesto: Principles behind the Agile Manifesto]]". in ''The Agile Manifesto''  [database online]. Accessed December 04 2014 at www.agilemanifesto.org/principles.html
+
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.
 
 
Boehm, B. and R. Turner. 2004. ''[[Balancing Agility and Discipline]].''  New York, NY, USA: Addison-Wesley.
 
 
 
Fairley, R. 2009. ''[[Managing and Leading Software Projects]].'' New York, NY, USA: J. Wiley & Sons.
 
 
 
Forsberg, K., H. Mooz, and H. Cotterman. 2005. ''[[Visualizing Project Management]].'' 3rd ed.  New York, NY, USA: J. Wiley & Sons.
 
 
 
INCOSE. 2012. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.
 
 
 
Lawson, H. 2010. ''[[A Journey Through the Systems Landscape]].'' Kings College, UK: College Publications.
 
 
 
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.
 
 
 
Royce, W.E. 1998. ''[[Software Project Management]]: A Unified Framework''. New York,  NY, USA: Addison Wesley.
 
  
 
===Additional References===
 
===Additional References===
Anderson, D. 2010. ''Kanban''.  Sequim, WA, USA: Blue Hole Press.
+
None.
 
 
Baldwin, C. and K. Clark. 2000. ''Design Rules: The Power of Modularity.'' Cambridge, MA, USA: MIT Press.
 
 
 
Beck, K. 1999. ''Extreme Programming Explained.'' New York, NY, USA: Addison Wesley.
 
 
 
Beedle, M., et al. 2009. "The Agile Manifesto: Principles behind the Agile Manifesto". in The Agile Manifesto [database online]. Accessed 2010. Available at: www.agilemanifesto.org/principles.html
 
 
 
Biffl, S.,  A. Aurum, B. Boehm, H. Erdogmus, and P. Gruenbacher (eds.). 2005. ''Value-Based Software Engineering''. New York, NY, USA: Springer.
 
 
 
Boehm, B. 1988. “A Spiral Model of Software Development.” IEEE ''Computer'' 21(5): 61-72.
 
 
 
Boehm, B. 2006. “Some Future Trends and Implications for Systems and Software Engineering Processes.” ''Systems Engineering.'' 9(1): 1-19.
 
 
 
Boehm, B., A. Egyed, J. Kwan, D. Port, A. Shah, and R. Madachy. 1998. “Using the WinWin Spiral Model: A Case Study.” IEEE ''Computer.'' 31(7): 33-44.
 
 
 
Boehm, B., R. Turner, J. Lane, S. Koolmanojwong. 2014 (in press). ''Embracing the Spiral Model: Creating Successful Systems with the Incremental Commitment Spiral Model''. Boston, MA, USA: Addison Wesley.
 
 
 
Castellano, D.R. 2004. “Top Five Quality Software Projects.” ''CrossTalk.'' 17(7) (July 2004): 4-19. Available at: http://www.crosstalkonline.org/storage/issue-archives/2004/200407/200407-0-Issue.pdf
 
 
 
Checkland, P. 1981. ''Systems Thinking, Systems Practice''. New York, NY, USA: Wiley.
 
 
 
Crosson, S. and B. Boehm. 2009. “Adjusting Software Life cycle Anchorpoints: Lessons Learned in a System of Systems Context.” Proceedings of the Systems and Software Technology Conference, 20-23 April 2009, Salt Lake City, UT, USA.
 
 
Dingsoyr, T., T. Dyba. and N. Moe (eds.). 2010. "Agile Software Development: Current Research and Future Directions.”  Chapter in B. Boehm, J. Lane, S. Koolmanjwong, and R. Turner, ''Architected Agile Solutions for Software-Reliant Systems.'' New York, NY, USA: Springer.
 
 
 
Dorner, D. 1996. ''The Logic of Failure''.  New York, NY, USA: Basic Books.
 
 
 
Forsberg, K. 1995. "'If I Could Do That, Then I Could…' System Engineering in a Research and Development Environment.” Proceedings of the Fifth Annual International Council on Systems Engineering (INCOSE) International Symposium. 22-26 July 1995. St. Louis, MO, USA.
 
 
 
Forsberg, K. 2010. “Projects Don’t Begin With Requirements.” Proceedings of the IEEE Systems Conference, 5-8 April 2010, San Diego, CA, USA.
 
 
 
Gilb, T. 2005.  ''Competitive Engineering''.  Maryland Heights, MO, USA: Elsevier Butterworth Heinemann.
 
 
 
Goldratt, E. 1984. ''The Goal''. Great Barrington, MA, USA: North River Press.
 
 
 
Hitchins, D.  2007. ''Systems Engineering: A 21st Century Systems Methodology.''  New York, NY, USA: Wiley.
 
 
 
Holland, J. 1998. ''Emergence''. New York, NY, USA: Perseus Books.
 
 
 
ISO/IEC. 2010. Systems and Software Engineering, Part 1: Guide for Life Cycle Management.  Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 24748-1:2010.
 
 
 
ISO/IEC/IEEE. 2015. ''Systems and Software Engineering -- System Life Cycle Processes.'' Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / , Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.
 
 
 
ISO/IEC. 2003. ''Systems Engineering — A Guide for The Application of ISO/IEC 15288 System Life Cycle Processes''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 19760:2003 (E).
 
 
 
Jarzombek, J. 2003. “Top Five Quality Software Projects.” ''CrossTalk.'' 16(7) (July 2003): 4-19. Available at: http://www.crosstalkonline.org/storage/issue-archives/2003/200307/200307-0-Issue.pdf.
 
 
 
Kruchten, P. 1999. ''The Rational Unified Process.'' New York, NY, USA: Addison Wesley.
 
 
 
Landis, T. R. 2010. ''Lockheed Blackbird Family (A-12, YF-12, D-21/M-21 & SR-71).''  North Branch, MN, USA: Specialty Press.
 
 
 
Madachy, R. 2008. ''Software Process Dynamics''.  Hoboken, NJ, USA: Wiley.
 
 
 
Maranzano, J.F., S.A. Rozsypal, G.H. Zimmerman, G.W. Warnken, P.E. Wirth, D.W. Weiss. 2005. “Architecture Reviews: Practice and Experience.” IEEE ''Software.'' 22(2): 34-43.
 
 
 
National Research Council of the National Academies (USA). 2008. ''Pre-Milestone A and Early-Phase Systems Engineering''. Washington, DC, USA: The National Academies Press.
 
 
 
Osterweil, L. 1987. “Software Processes are Software Too.” Proceedings of the SEFM 2011: 9th International Conference on Software Engineering. Monterey, CA, USA.
 
 
 
Poppendeick, M. and T. Poppendeick. 2003. ''Lean Software Development: an Agile Toolkit.''  New York, NY, USA: Addison Wesley.
 
 
 
Rechtin, E. 1991. ''System Architecting: Creating and Building Complex Systems.'' Upper Saddle River, NY, USA: Prentice-Hall.
 
 
 
Rechtin, E., and M. Maier. 1997.  ''The Art of System Architecting''. Boca Raton, FL, USA: CRC Press.
 
 
 
Schwaber, K. and M. Beedle. 2002. ''Agile Software Development with Scrum''. Upper Saddle River, NY, USA: Prentice Hall.
 
 
 
Spruill, N. 2002. “Top Five Quality Software Projects.” ''CrossTalk.'' 15(1) (January 2002): 4-19. Available at: http://www.crosstalkonline.org/storage/issue-archives/2002/200201/200201-0-Issue.pdf.
 
 
 
Stauder, T. 2005. “Top Five Department of Defense Program Awards.” ''CrossTalk.'' 18(9) (September 2005): 4-13. Available at http://www.crosstalkonline.org/storage/issue-archives/2005/200509/200509-0-Issue.pdf.
 
 
 
Warfield, J. 1976. ''Societal Systems: Planning, Policy, and Complexity''.  New York, NY, USA: Wiley.
 
 
 
Womack, J. and D. Jones. 1996. ''Lean Thinking.'' New York, NY, USA: Simon and Schuster.
 
  
 
----
 
----
  
<center>[[System Life Cycle Process Drivers and Choices|< Previous Article]] | [[Life Cycle Models|Parent Article]] | [[System Life Cycle Process Models: Iterative|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>

Revision as of 03:07, 19 October 2019

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, there are several models of incrementalincremental and evolutionaryevolutionary 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.

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

  • 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

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

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

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

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.0, released 1 June 2019