View source for System Life Cycle Process Drivers and Choices

==Fixed-Requirements and Evolutionary Development Processes==

The need for rapid adaptation to unforeseen changes has caused many organizations to emphasize evolutionary development as compared to traditional development to a fixed set of requirements.  Yet, there are still significant areas in which fixed-requirements driven development is appropriate.  This section identifies the primary development and evolution options and decision criteria for choosing among them.

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

There are several forms of [[Incremental (glossary)|incremental]] 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, pro-active 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.

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 leads to assumptions that most systems engineers can be dismissed after the system’s Preliminary Design Review (PDR); 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.”


*Prespecified Single-Step: CDPU

*Prespecified Sequential: CD; PU1; PU2; PU3; …

*Evolutionary Sequential: CDPU1; CDPU2; CDPU3; …

*Evolutionary Overlapped: 
****CDPU 1;
******CDPU 2;
********CDPU 3
*********…
*Evolutionary Concurrent: 
*****C; D1;  U1
*******C2; D2; U2
*********C3; D3; U3
************
 
Table 1 below 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.

[[File:KF_Incremental&EvolDevelopment.png|600px|Forms of Incremental and Evolutionary Development]]

Table 1 - Forms of Incremental and Evolutionary Development (Boehm and Lane 2010)

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 very expensive rework when they need to undo architectural commitments.

The Evolutionary Sequential model rapidly develops an initial operational capability and upgrades it 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 getting quick-response capabilities in the field.  For pure agile, it can fall prey to an easiest-first set of architectural commitments which break when, for example, it tries to add security as a new feature in a later increment.  For rapid fielding, it may be expensive to keep the SE and development teams together while waiting for usage feedback, but it 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.  In addition it may be expensive to keep the SE and development teams together while waiting for the enablers, but again it may be worth it.

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.  Its example and discussion are provided below in Table 2.

==Life Cycle Process Decision Table==

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.

[[File:KF_Incremental&EvolDecision.png|600px|Table. Incremental and Evolutionary Development Decision Table (SERC 2010/Permission Pending)]]

Table 2 - Incremental and Evolutionary Development Decision Table (Boehm and Lane 2010)

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 Prespecified 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 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 Evolutionary Overlapped process defers the next increment until its needed capabilities are available and mature enough to be added. It is best when one does not need to wait for operational feedback, but 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 some agent-based satellite anomaly trend analysis and mission adaptation software to become predictably stable before incorporating it in 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 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]] and [[Validation (glossary)|Validation]] (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|600px|Evolutionary-Concurrent Rapid Change Handling and High Assurance Pew, Mavor 2007/Permission Pending)]]

Figure 2 Evolutionary-Concurrent Rapid Change Handling and High Assurance (Pew and Malvoir 2007, Figure 2-6)

==References== 
Please make sure all references are listed alphabetically and are formatted according to the Chicago Manual of Style (15th ed). See the [http://www.bkcase.org/fileadmin/bkcase/files/Wiki_Files__for_linking_/BKCASE_Reference_Guidance.pdf BKCASE Reference Guidance] for additional information.

===Citations===
Boehm, B. 2006. “Some Future Trends and Implications for Systems and Software Engineering Processes”, Systems Engineering 9(1), pp. 1-19.

Boehm, B. and J. Lane, October 2007. “Using the Incremental Commitment Model to Integrate System Acquisition, Systems Engineering, and Software Engineering,” CrossTalk, pp. 4-9.

Boehm, B. and J. Lane. March 2010. "DoD Systems Engineering and Management Implications for Evolutionary Acquisition of Major Defense Systems," SERC RT-5 report, USC-CSSE-2010-500.

Cusumano, M., and D. Yoffee, 1998. Competing on Internet Time: Lessons from Netscape and Its Battle with Microsoft, New York: Free Press.

Pew, R., and A. Mavor (eds.) 2007. [[Human-System Integration in the System Development Process]]: A New Look, The National Academies Press. http://www.nap.edu.

===Primary References===
Pew, R., and A. Mavor (eds.) 2007. [[Human-System Integration in the System Development Process]]: A New Look, The National Academies Press. http://www.nap.edu.

===Additional References===
Boehm, B., 2006. “Some Future Trends and Implications for Systems and Software Engineering Processes”, Systems Engineering 9(1), pp. 1-19.

Boehm, B., and J. Lane, October 2007. “Using the Incremental Commitment Model to Integrate System Acquisition, Systems Engineering, and Software Engineering,” CrossTalk, pp. 4-9.

Boehm, B. and J. Lane. March 2010. "DoD Systems Engineering and Management Implications for Evolutionary Acquisition of Major Defense Systems," SERC RT-5 report, USC-CSSE-2010-500.

Cusumano, M., and D. Yoffee, 1998. Competing on Internet Time: Lessons from Netscape and Its Battle with Microsoft, New York: Free Press.

----
====Article Discussion====



[[{{TALKPAGENAME}}|[Go to discussion page]]]
<center>[[Life Cycle Characteristics|<- Previous Article]] | [[Life Cycle Models|Parent Article]] | [[Representative System Life Cycle Process Models|Next Article ->]]</center>

==Signatures==
[[Category: Part 3]][[Category:Topic]]