Difference between revisions of "System Lifecycle Process Drivers and Choices"

From SEBoK
Jump to navigation Jump to search
(Tech and grammar edits as discussed with Bkcase)
(Reverted edits by Mhaas (talk) to last revision by WikiWorks)
Tag: Rollback
Line 1: Line 1:
−
The life cycle model is one of the key concepts of systems engineering (SE).  A {{Term|Life Cycle (glossary)|life cycle}} for a {{Term|System (glossary)|system}} generally consists of a series of {{Term|Stage (glossary)|stages}} regulated by a set of management decisions which confirm that the system is mature enough to leave one stage and enter another.  
+
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. In addition, technical factors will also influence the types of life cycle models appropriate for a given system. For example, system requirements can 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.)
  
−
==Topics==
+
==Fixed-Requirements and Evolutionary Development Processes==
−
Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. The KAs in turn are divided into topics. This KA contains the following topics:
+
Aside from the traditional, pre-specified, sequential, single-step development process, there are several models of [[Incremental (glossary)|incremental]] and [[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.
−
*[[System Life Cycle Process Drivers and Choices]]
+
−
*[[System Life Cycle Process Models: Vee]]
+
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-Interest (glossary)|system-of-interest]] (SoI).  This practice is particularly valuable in cases in which
−
*[[System Life Cycle Process Models: Iterative]]
+
 
−
*[[Integration of Process and Product Models]]
+
*  rapid exploration and implementation of part of the system is desired;
−
*[[Lean Engineering]]
+
* 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.
  
−
See the article [[Matrix of Implementation Examples]] for a mapping of case studies and vignettes included in Part 7 to topics covered in Part 3.
+
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.
  
−
==Type of Value Added Products/Services==
+
==Primary Models of Incremental and Evolutionary Development==
−
The [[Generic Life Cycle Model]] shows just the single-step approach for proceeding through the stages of a system’s life cycle. Adding value (as a product, a service, or both), is a shared purpose among all enterprises, whether public or private, for profit or non-profit. Value is produced by providing and integrating the elements of a system into a product or service according to the system description and transitioning it into productive use. These value considerations will lead to various forms of the generic life cycle management approach in Figure 1. Some examples are as follows (Lawson 2010):
+
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.
  
−
* A manufacturing enterprise produces nuts, bolts, and lock washer products and then sells their products as value added elements to be used by other enterprises; in turn, these enterprises integrate these products into their more encompassing value-added system, such as an aircraft or an automobile. Their requirements will generally be pre-specified by the customer or by industry standards.
+
[[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)]]
  
−
* A wholesaling or retailing enterprise offers products to their customers. Its customers (individuals or enterprises) acquire the products and use them as elements in their systems.  The enterprise support system will likely evolve opportunistically, as new infrastructure capabilities or demand patterns emerge.
+
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.  
  
−
* A commercial service enterprise such as a bank sells a variety of ''products'' as services to their customers. This includes current accounts, savings accounts, loans, and investment management. These services add value and are incorporated into customer systems of individuals or enterprises. The service enterprise’s support system will also likely evolve opportunistically, as new infrastructure capabilities or demand patterns emerge.
+
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.  
  
−
* A governmental service enterprise provides citizens with services that vary widely, but may include services such as health care, highways and roads, pensions, law enforcement, or defense. Where appropriate, these services become infrastructure elements utilized in larger encompassing systems of interest to individuals and/or enterprises. Major initiatives, such as a next-generation air traffic control system or a metropolitan-area crisis management system (hurricane, typhoon, earthquake, tsunami, flood, fire), will be sufficiently complex enough to follow an evolutionary development and fielding approach. At the elemental level, there will likely be pre-specified single-pass life cycles. 
+
{|  '
 +
|+'''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
  
−
* For aircraft and automotive systems, there would likely be a pre-specified multiple-pass life cycle to capitalize on early capabilities in the first pass, but architected to add further value-adding capabilities in later passes.
+
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
 +
|}
  
−
* A diversified software development enterprise provides software products that meet stakeholder requirements (needs), thus providing services to product users.  It will need to be developed to have capabilities that can be tailored to be utilized in different customers’ life-cycle approaches and also with product-line capabilities that can be quickly and easily applied to similar customer system developments. Its business model may also include providing the customer with system life-cycle support and evolution capabilities.
+
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.
  
−
Within these examples, there are systems that remain stable over reasonably long periods of time and those that change rapidly. The diversity represented by these examples and their processes illustrate why there is no one-size-fits-all process that can be used to define a specific systems life cycle. Management and leadership approaches must consider the type of systems involved, their longevity, and the need for rapid adaptation to unforeseen changes, whether in competition, technology, leadership, or mission priorities. In turn, the management and leadership approaches impact the type and number of life cycle models that are deployed as well as the processes that will be used within any particular life cycle.
+
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.
  
−
There are several incremental and evolutionary approaches for sequencing the life cycle stages to deal with some of the issues raised above.  The [[Life Cycle Models]] knowledge area summarizes a number of {{Term|Incremental (glossary)|incremental}} and {{Term|Evolutionary (glossary)|evolutionary}} life cycle models, including their main strengths and weaknesses and also discusses criteria for choosing the best-fit approach.
+
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.
  
−
==Categories of Life Cycle Model==
+
==Incremental and Evolutionary Development Decision Table==
  
−
The Generic System Life Cycle Model in Figure 1 does not explicitly fit all situations.  A simple, precedential, follow-on system may need only one phase in the definition stage, while a complex system may need more than two.  With build-upon systems (vs. throwaway) {{Term|Prototype (glossary)|prototypes}}, a good deal of development may occur during the definition stage.  System {{Term|Integration (glossary)|integration}}, {{Term|Verification (glossary)|verification}}, and {{Term|Validation (glossary)|validation}} may follow implementation or acquisition of the system elements.  With software, particularly test-first and daily builds, integration, verification, and validation are interwoven with element implementation.  Additionally, with the upcoming ''Third Industrial Revolution'' of three-dimensional printing and digital manufacturing (Whadcock 2012), not only initial development but also initial production may be done during the concept stage.
+
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.
  
−
Software is a flexible and malleable medium which facilitates iterative analysis, design, construction, verification, and validation to a greater degree than is usually possible for the purely physical components of a system. Each repetition of an iterative development model adds material (code) to the growing software base, in which the expanded code base is tested, reworked as necessary, and demonstrated to satisfy the requirements for the baseline.
+
<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>'''''
  
−
Software can be electronically bought, sold, delivered, and upgraded anywhere in the world within reach of digital communication, making its logistics significantly different and more cost-effective than hardware.  It does not wear out and its fixes change its content and behavior, making regression testing more complex than with hardware fixes.  Its discrete nature dictates that its testing cannot count on analytic continuity as with hardware.  Adding 1 to 32767 in a 15-bit register does not produce 32768, but 0 instead, as experienced in serious situations, such as with the use of the Patriot Missile.
+
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.  
  
−
There are a large number of potential {{Term|Life Cycle Process (glossary)|life cycle process}} models. They fall into three major categories:
+
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.
 
   
 
   
−
# primarily pre-specified and sequential processes (e.g. the single-step waterfall model)
+
The ''Evolutionary Sequential'' process develops an initial operational capability and upgrades it based on operational experience, as exemplified by agile methods. It is most need in cases 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 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.
−
# primarily evolutionary and concurrent processes (e.g. lean development, the rational unified process, and various forms of the vee and spiral models)
 
−
# primarily interpersonal and emergent processes (e.g. agile development, scrum, extreme programming (XP), the dynamic system development method, and innovation-based processes)
 
  
−
The emergence of integrated, interactive hardware-software systems made pre-specified processes potentially harmful, as the most effective human-system interfaces tended to emerge with its use, leading to further process variations, such as soft SE (Warfield 1976, Checkland 1981) and human-system integration processes (Booher 2003, Pew and Mavor 2007).  Until recently, process standards and maturity models have tried to cover every eventuality.  They have included extensive processes for acquisition management, source selection, reviews and audits, quality assurance, configuration management, and document management, which in many instances would become overly bureaucratic and inefficient.  This led to the introduction of more lean (Ohno 1988; Womack et al. 1990; Oppenheim 2011) and agile (Beck 1999; Anderson 2010) approaches to concurrent hardware-software-human factors approaches such as the concurrent vee models (Forsberg 1991; Forsberg 2005) and Incremental Commitment Spiral Model (Pew and Mavor 2007; Boehm and Lane 2007).
+
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.
−
 
+
   
−
In the next article on [[System Life Cycle Process Drivers and Choices]], these variations on the theme of life cycle models will be identified and presented.
+
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 [[Verification (glossary)|verification]] and [[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.  
−
 
 
−
==Systems Engineering Responsibility==
 
−
Regardless of the life cycle models deployed, the role of the systems engineer encompasses the entire life cycle of the system-of-interest. Systems engineers orchestrate the development and evolution of a solution, from defining requirements through operation and ultimately until system retirement. They ensure that domain experts are properly involved, all advantageous opportunities are pursued, and all significant risks are identified and, when possible, mitigated. The systems engineer works closely with the project manager in tailoring the generic life cycle, including key {{Term|Decision Gate (glossary)|decision gates}}, to meet the needs of their specific project.  
 
  
−
Systems engineering tasks are usually concentrated at the beginning of the life cycle; however, both commercial and government organizations recognize the need for SE throughout the system’s life cycle. Often this ongoing effort is to modify or change a system, product or service after it enters production or is placed in operation. Consequently, SE is an important part of all life cycle stages. During the production, support, and utilization (PSU) stages, for example, SE executes performance analysis, interface monitoring, failure analysis, logistics analysis, tracking, and analysis of proposed changes. All these activities are essential to ongoing support of the system.  
+
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 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.
  
−
All project managers must ensure that the business aspect (cost, schedule, and value) and the technical aspect of the project cycle remain synchronized. Often, the technical aspect drives the project. It is the systems engineers’ responsibility to ensure that the technical solutions that are being considered are consistent with the cost and schedule objectives. This can require working with the users and customers to revise objectives to fit within the business bounds. These issues also drive the need for decision gates to be appropriately spaced throughout the project cycle. Although the nature of these decision gates will vary by the major categories above, each will involve {{Term|In-Process Validation (glossary)|in-process validation}} between the developers and the end users. In-process validation asks the question: ''“Will what we are planning or creating satisfy the stakeholders’ needs?”'' In-process validation begins at the initialization of the project during user needs discovery and continues through daily activities, formal decision gate reviews, final product or solution delivery, operations, and ultimately to system closeout and disposal.
+
[[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.]]
  
 
==References==  
 
==References==  
Line 59: Line 136:
  
 
===Works Cited===
 
===Works Cited===
−
Anderson, D. 2010. ''Kanban.'' Sequim, WA: Blue Hole Press.
+
Boehm, B. 2006. “Some Future Trends and Implications for Systems and Software Engineering Processes.” ''Systems Engineering.'' 9(1): 1-19.
  
−
Beck, K. 1999. ''Extreme Programming Explained.'' Boston, MA: Addison Wesley.
+
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. 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.
−
 
−
Booher, H. (ed.) 2003. ''Handbook of Human Systems Integration''. Hoboken, NJ, USA: Wiley.  
 
  
−
Checkland, P. 1999. ''Systems Thinking, Systems Practice,'' 2nd ed. Hoboken, NJ, USA: Wiley.
+
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. Yoffie. 1998. ''Competing on Internet Time'', New York, NY, USA: The Free Press.
 
  
−
Forsberg, K. and H. Mooz. 1991. "The Relationship of System Engineering to the Project Cycle," ''Proceedings of INCOSE'', October 1991.
+
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.
−
 
 
−
Forsberg, K., H. Mooz, and H. Cotterman. 2005. ''Visualizing Project Management'', 3rd ed. Hoboken, NJ: J. Wiley & Sons.
 
−
 
 
−
ISO/IEC/IEEE. 2015.''[[ISO/IEC/IEEE 15288|Systems and software engineering - system life cycle processes]]''.Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers.[[ISO/IEC/IEEE 15288|ISO/IEC 15288]]:2015.
 
−
 
 
−
Lawson, H. 2010. ''A Journey Through the Systems Landscape.'' London, UK: College Publications.
 
−
 
 
−
Ohno, T. 1988. ''Toyota Production System''. New York, NY: Productivity Press.
 
−
 
 
−
Oppenheim, B. 2011.  ''Lean for Systems Engineering.'' Hoboken, NJ: Wiley.
 
−
 
 
−
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.
 
−
 
 
−
Warfield, J. 1976. ''Systems Engineering''. Washington, DC, USA: US Department of Commerce (DoC).
 
−
 
−
Whadcock, I. 2012. “A third industrial revolution.” ''The Economist.'' April 21, 2012.
 
−
 
 
−
Womack, J.P., D.T. Jones, and D. Roos 1990. ''The Machine That Changed the World: The Story of Lean Production.'' New York, NY, USA: Rawson Associates.
 
  
 
===Primary References===
 
===Primary References===
−
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.
+
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.
−
 
 
−
Forsberg, K., H. Mooz, H. Cotterman. 2005. ''[[Visualizing Project Management]]'', 3rd Ed. Hoboken, NJ: J. Wiley & Sons.
 
−
 
 
−
INCOSE. 2012. ''[[INCOSE Systems Engineering Handbook | Systems Engineering Handbook]]'', 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]].''  London, UK:  College Publications.
 
−
 
 
−
Pew, R. and A. Mavor (Eds.). 2007. ''[[Human-System Integration in the System Development Process|Human-System Integration in The System Development Process: A New Look]].'' Washington, DC, USA: The National Academies Press.
 
  
 
===Additional References===
 
===Additional References===
−
Chrissis, M., M. Konrad, and S. Shrum. 2003. ''CMMI: Guidelines for Process Integration and Product Improvement.'' New York, NY, USA: Addison Wesley.
+
None.
−
 
 
−
Larman, C. and B. Vodde. 2009. ''Scaling Lean and Agile Development.'' New York, NY, USA: Addison Wesley.
 
−
 
 
−
 
 
−
The following three books are not referenced in the SEBoK text, nor are they systems engineering "texts"; however, they contain important systems engineering lessons, and readers of this SEBOK are encouraged to read them.
 
−
 
 
−
<blockquote>Kinder, G. 1998. ''Ship of Gold in the Deep Blue Sea.'' New York, NY, USA: Grove Press.</blockquote>
 
−
 
 
−
This is an excellent book that follows an idea from inception to its ultimately successful implementation. Although systems engineering is not discussed, it is clearly illustrated in the whole process from early project definition to alternate concept development to phased exploration and “thought experiments” to addressing challenges along the way. It also shows the problem of not anticipating critical problems outside the usual project and engineering scope. It took about five years to locate and recover the 24 tons of gold bars and coins from the sunken ship in the 2,500-meter-deep ocean, but it took ten years to win the legal battle with the lawyers representing insurance companies who claimed ownership based on 130-year-old policies they issued to the gold owners in 1857.  
 
  
−
<blockquote>McCullough, D. 1977. ''The Path Between the Seas: The Creation of the Panama Canal (1870 – 1914).'' New York, NY, USA: Simon & Schuster.</blockquote>
 
−
 
−
Although “systems engineering” is not mentioned, this book highlights many systems engineering issues and illustrates the need for SE as a discipline. The book also illustrates the danger of applying a previously successful concept (the sea level canal used in Suez a decade earlier) in a similar but different situation. Ferdinand de Lesseps led both the Suez and Panama projects. It illustrates the danger of lacking a fact-based project cycle and meaningful decision gates throughout the project cycle. It also highlights the danger of providing project status without visibility. After five years into the ten-year project investors were told the project was more than 50 percent complete when in fact only 10 percent of the work was complete. The second round of development under Stevens in 1904 focused on “moving dirt” rather than digging a canal, a systems engineering concept key to the completion of the canal. The Path Between the Seas won the National Book Award for history (1978), the Francis Parkman Prize (1978), the Samuel Eliot Morison Award (1978), and the Cornelius Ryan Award (1977).
 
−
 
−
<blockquote>Shackleton, Sir E.H. 2008. (Originally published in by William Heinemann, London, 1919). ''South: The Last Antarctic Expedition of Shackleton and the Endurance.'' Guilford, CT, USA: Lyons Press.</blockquote>
 
−
 
−
This is the amazing story of the last Antarctic expedition of Shackleton and the ''Endurance'' in 1914 to 1917. The systems engineering lesson is the continuous, daily risk assessment by the captain, expedition leader, and crew as they lay trapped in the arctic ice for 18 months. All 28 crew members survived.
 
 
----
 
----
  
−
<center>[[Life Cycle Processes and Enterprise Need|< Previous Article]] | [[Systems Engineering and Management|Parent Article]] | [[System Life Cycle Process Drivers and Choices|Next Article >]]</center>
+
<center>[[Life Cycle Models|< Previous Article]] | [[Life Cycle Models|Parent Article]] | [[System Life Cycle Process Models: Vee|Next Article >]]</center>
  
−
[[Category: Part 3]][[Category:Knowledge Area]]
 
 
<center>'''SEBoK v. 2.0, released 1 June 2019'''</center>
 
<center>'''SEBoK v. 2.0, released 1 June 2019'''</center>
 +
 +
[[Category: Part 3]][[Category:Topic]]
 +
[[Category:Life Cycle Models]]

Revision as of 03:06, 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. In addition, technical factors will also influence the types of life cycle models appropriate for a given system. For example, system requirements can 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 incremental and 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.

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

TheEvolutionary 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 need in cases 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 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 verification and 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 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 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.

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
Retrieved from "https://sandbox.sebokwiki.org/index.php?title=System_Lifecycle_Process_Drivers_and_Choices&oldid=56495"