Difference between revisions of "Generic Life Cycle Model"

From SEBoK
Jump to navigation Jump to search
m (Text replacement - "SEBoK v. 2.9, released 20 November 2023" to "SEBoK v. 2.10, released 06 May 2024")
 
(108 intermediate revisions by 13 users not shown)
Line 1: Line 1:
==Type of Value Added Products/Services==
+
----
 +
'''''Lead Authors:''''' ''Kevin Forsberg, Richard Turner'', '''''Contributing Author:''''' ''Rick Adcock''
 +
----
 +
As discussed in the generic life cycle paradigm in [[System Life Cycle Approaches]], each {{Term|System-of-Interest (glossary)}} (SoI) has an associated {{Term|Life Cycle Model (glossary)}}. The generic life cycle model below applies to a single SoI.  SE must generally be synchronized across a number of tailored instances of such life cycle models to fully satisfy stakeholder needs.  More complex life cycle models which address this are described in [[Life Cycle Models]].
  
The common purpose of all organizations, public or private, for profit or non-profit, is to produce, via enterprise(s), some form of value added.  The nature of the added value is either a product or a service, or both. In either case the product or service is produced via provisioning of the elements of the system and the integration of the elements according to the system description into a product or service.  Various management and leadership approaches can be required based upon the type and complexity of value-added product and/or service that is produced and the type of enterprise involved in the production.  Some examples are as follows (Lawson 2010, 193-217):
+
==A Generic System Life Cycle Model==
  
* A manufacturing enterprise, for example one producing nuts, bolts, and lock washer products, sells their products as value added elements to be used by other enterprises who integrate these products into their more encompassing value added system; for example, an aircraft or an automobile.
+
There is no single “one-size-fits-all” system life cycle model that can provide specific guidance for all project situations.  Figure 1, adapted from (Lawson 2010, ISO 2015, and ISO 2010), provides a generic life cycle model that forms a starting point for the most common versions of pre-specified, evolutionary, sequential, opportunistic, and concurrent life cycle processes.  The model is defined as a set of stages, within which technical and management activities are performed.  The stages are terminated by {{Term|Decision Gate (glossary)|decision gates}}, where the key stakeholders decide whether to proceed into the next stage, to remain in the current stage, or to terminate or re-scope related projects.
  
* A wholesaling or retailing enterprise provides products that it offers to their customers. Their customers (individuals or enterprises) acquire the products and use them as elements in their systems.
+
[[File:Fig_1_A_generic_life_cycle_KF.png|thumb|600px|center|'''Figure 1.  A Generic Life Cycle Model.''' (SEBoK Original)]]
  
* A commercial service enterprise such as a bank sells a variety of “products” as services to their customers; for example, current accounts, savings accounts, loans, investment management, and so on.  These services add value and are incorporated in customer systems of individuals or enterprises.
+
Elaborated definitions of these stages are provided in the glossary below and in various other ways in subsequent articles.
  
* A governmental service enterprise provides citizens with services that vary widely from health care, highways and roads, pensions, police, defense, and so on.  Where appropriate, these services become infrastructure elements that are utilized in larger encompassing systems that are of interest to individuals and/or enterprises.
+
The '''Concept Definition''' stage begins with a decision by a protagonist (individual or organization) to invest resources in a new or improved {{Term|Engineered System (glossary)|engineered system}}. Inception begins with a set of {{Term|Stakeholder (glossary)|stakeholders}} agreeing to the need for change to an [[Engineered System Context|engineered system context]] and exploring whether new or modified SoI can be developed, in which the {{Term|Life Cycle (glossary)|life cycle}} benefits are worth the investments in the {{Term|Life Cycle Cost (LCC) (glossary)|life cycle costs}}. Activities include: developing the concept of operations and business case; determining the key stakeholders and their desired capabilities; negotiating the stakeholder requirements among the key stakeholders and selecting the system’s non-developmental items (NDIs).
  
* A consulting enterprise via its services adds value in the form of knowledge and know-how for its customers. For such an enterprise, the set of services “produced” may remain stable for some customers but can also change rapidly as agreements with new customers are established and as customer agreements are terminated.
+
The '''System Definition''' stage begins when the key stakeholders decide that the business needs and stakeholder requirements are sufficiently well defined to justify committing the resources necessary to define a solution options in sufficient detail to answer the life cycle cost question identified in concept definition and provide a basis of system realization if appropriate.  Activities include developing system architectures; defining and agreeing upon levels of system requirements; developing systems-level life cycle plans and performing system analysis in order to illustrate the compatibility and feasibility of the resulting system definition. The transition into the system realization stage can lead to either single-pass or multiple-pass development.
  
* An IT service enterprise provides data processing and information access capability by operating computers, communication equipment, and software systems.
+
It should be noted that the concept and system definition activities above describe activities performed by ''systems engineers'' when performing ''systems engineering''.  There is a very strong concurrency between proposing a problem situation or opportunity and describing one or more possible system solutions, as discussed in [[Systems Approach Applied to Engineered Systems]].  Other related definition activities include: prototyping or actual development of high-risk items to show evidence of system feasibility; collaboration with business analysts or performing mission effectiveness analyses to provide a viable business case for proceeding into realization; and modifications to realized systems to improve their production, support or utilization.  These activities will generally happen through the system life cycle to handle system evolution, especially under multiple-pass development.  This is discussed in more detail in the [[Life Cycle Models]] knowledge area.
  
* A software development enterprise provides software products that meet stakeholder requirements (needs) thus providing services to product users. Both the developed software and the operation service become part of the set of infrastructure systems of the user enterprise.
+
The '''System Realization''' stage begins when the key stakeholders decide that the SoI architecture and feasibility evidence are sufficiently low-risk to justify committing the resources necessary to develop and sustain the initial operational capability (IOC) or the single-pass development of the full operational capability (FOC). Activities include: construction of the developmental elements; integration of these elements with each other and with the non-developmental item (NDI) elements; verification and validation of the elements and their integration as it proceeds; and preparing for the concurrent production, support, and utilization activities.
  
Within these examples, there are systems that remain stable over reasonably long periods of time, but there are many that change rapidly.  The diversity of these examples and their process needs makes it very clear that there is no one-size-fits-all process for the systems life cycle.  Thus, the approach to management and leadership must take into account of the type of systems involved as well as their longevity and need for rapid adaptation to unforeseen changes in competition, technology, leadership, and mission prioritiesIn turn, the management and leadership directions impact the type and number of life cycle models that are deployed as well as the processes that are made available for utilization within a life cycle.
+
The '''System Production, Support, and Utilization (PSU)''' stages begin when the key stakeholders decide that the SoI life-cycle feasibility and safety are at a sufficiently low-risk level that justifies committing the resources necessary to produce, field, support, and utilize the system over its expected lifetimeThe lifetimes of production, support, and utilization are likely to be different. After market support will generally continue after production is complete and users will often continue to use unsupported systems.
  
==Systems Engineering Responsibility==
+
'''System Production''' involves the fabrication of instances or versions of an SoI and of associated after-market spare parts.  It also includes production quality monitoring and improvement; product or service acceptance activities; and continuous production process improvement. It may include low-rate initial production (LRIP) to mature the production process or to promote the continued preservation of the production capability for future spikes in demand.
  
The role of the systems engineer encompasses the entire life cycle for the System-of-InterestSystems engineers orchestrate the development of a solution from requirements determination through operations, and ultimately system retirement, by assuring that domain experts are properly involved, that all advantageous opportunities are pursued, and that all significant risks are identified and, where possible, mitigatedThe systems engineer works closely with the project manager in tailoring the generic life cycle, including key [[Decision Gate (glossary)]], to meet the needs of their specific project.
+
'''Systems Support''' includes various classes of maintenance: corrective (for defects), adaptive (for interoperability with independently evolving co-dependent systems), and perfective (for enhancement of performance, usability, or other key performance parameters)It also includes hot lines and responders for user or emergency support and the provisioning of needed consumables (gas, water, power, etc.)Its boundaries include some gray areas, such as the boundary between small system enhancements and the development of larger complementary new additions, and the boundary between rework/maintenance of earlier fielded increments in incremental or evolutionary development. ''Systems Support'' usually continues after ''System Production'' is terminated.
  
The purpose in defining the system life cycle is to establish a framework for meeting the stakeholders’ needs in an orderly and efficient manner.  This is usually done by defining life-cycle stages and using decision gates to determine readiness to move from one stage to the next.  Skipping stages and eliminating “time consuming” decision gates can greatly increase the programmatic risks (cost, schedule, and value) and may adversely affect the technical development as well by reducing the level of the SE effort.
+
'''System Utilization''' includes the use of the SoI in its context by operators, administrators, the general public, or systems above it in the system-of-interest hierarchy.  It usually continues after ''Systems Support'' is terminated.  
  
Systems engineering tasks are usually concentrated at the beginning of the life cycle, but both commercial and government organizations recognize the need for SE throughout the system’s life span, often 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 stagesDuring Operations and Support (O&S) stages, for example, SE executes performance analysis, interface monitoring, failure analysis, logistics analysis, tracking, management, etc. that is essential to ongoing support of the system.
+
The '''System Retirement''' stage is often executed incrementally as system versions or elements become obsolete or are no longer economical to support and therefore undergo disposal or recycling of their contentIncreasingly affordable considerations make system re-purposing an attractive alternative.
  
All project managers must ensure that the business aspect (cost, schedule, and value) and the technical aspect of the project cycle stay synchronized. For most programs the technical aspect drives the project, and it is the systems engineers’ responsibility to ensure that the technical solutions considered are consistent with the cost and schedule objectivesThis may require working with the users and customers to revise objectives to fit within the business boundsThese issues also drive the need for decision gates appropriately spaced throughout the project cycle. Decision gates such as the User Requirements Review, Concept Selection Review, and System Requirements Review are early gates that ensure that the project is on the right path and will produce an integrated product (hardware, software, human system interaction, services) that meets the user and customer needsTo ensure that the project is on the right path frequent [[In-Process Validation (glossary)]] must be performed between the developers and the end users. In-process validation asks the question: “Will what we are planning or creating satisfy the users’ needs?”  In-process validation begins at the very outset of the project during user needs discovery and continues through daily activities as well as at formal decision gate reviews to final product or solution delivery, through operations to system closeout and disposal.
+
==Applying the Life Cycle Model==
 +
 
 +
Figure 1 shows just the single-step approach for proceeding through the stages of a SoI life cycle. In the [[Life Cycle Models]] knowledge area, we discuss examples of real-world enterprises and their drivers, both technical and organizationalThese have led to a number of documented approaches for sequencing the life cycle stages to deal with some of the issues raisedThe Life Cycle Models KA 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.
 +
 
 +
In Figure 1, we have listed key technical and management activities critical to successful completion of each stage. This is a useful way to illustrate the goals of each stage and gives an indication of how processes align with these stages.  This can be important when considering how to plan for resources, milestones, etc.  However, it is important to observe that the execution of process activities is not compartmentalized to particular life cycle stages (Lawson 2010)In [[Applying Life Cycle Processes]], we discuss a number of views on the nature of the inter-relationships between process activities within a life cycle model. In general, the technical and management activities are applied in accordance with the principles of {{Term|Concurrent (glossary)|concurrency}}, {{Term|Iteration (glossary)}} and {{Term|Recursion (glossary)}} described in the [[System Life Cycle Approaches|generic life cycle paradigm]].
  
 
==References==  
 
==References==  
This article relies on limited sources.  Reviewers are requested to identify additional sources. 
 
  
===Citations===
+
===Works Cited===
Lawson, Harold. 2010. [[A Journey Through the Systems Landscape]] London, UK: College Publications.
+
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.
 +
 
 +
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.
 +
 
 +
Lawson, H. 2010. ''A Journey Through the Systems Landscape.'' London, UK: College Publications.
  
 
===Primary References===
 
===Primary References===
Lawson, Harold. 2010. [[A Journey Through the Systems Landscape]] London, UK: College Publications.
+
Forsberg, K., H. Mooz, H. Cotterman. 2005. ''[[Visualizing Project Management]]'', 3rd Ed. Hoboken, NJ: J. Wiley & Sons.
 +
 
 +
INCOSE. 2015. '[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities', version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0.
 +
 
 +
Lawson, H. 2010. ''[[A Journey Through the Systems Landscape]].''  London, UK: College Publications.
  
 
===Additional References===
 
===Additional References===
No additional references have been identified for version 0.5.  Please provide any recommendations on additional references in your review.
+
None.
 
----
 
----
====Article Discussion====
+
<center>[[System Life Cycle Approaches|< Previous Article]] | [[System Life Cycle Approaches|Parent Article]] | [[Applying Life Cycle Processes|Next Article >]]</center>
  
[[{{TALKPAGENAME}}|[Go to discussion page]]]
+
<center>'''SEBoK v. 2.10, released 06 May 2024'''</center>
<center>[[Life Cycle Models|<- Previous Article]] | [[Life Cycle Models|Parent Article]] | [[System Life Cycle Process Drivers and Choices|Next Article ->]]</center>
 
  
==Signatures==
 
 
[[Category: Part 3]][[Category:Topic]]
 
[[Category: Part 3]][[Category:Topic]]
 
+
[[Category:System Life Cycle Approaches]]
--[[User:Dholwell|Dholwell]] 19:50, 30 August 2011 (UTC) core team edit
 

Latest revision as of 21:48, 2 May 2024


Lead Authors: Kevin Forsberg, Richard Turner, Contributing Author: Rick Adcock


As discussed in the generic life cycle paradigm in System Life Cycle Approaches, each system-of-interestsystem-of-interest (SoI) has an associated life cycle modellife cycle model. The generic life cycle model below applies to a single SoI. SE must generally be synchronized across a number of tailored instances of such life cycle models to fully satisfy stakeholder needs. More complex life cycle models which address this are described in Life Cycle Models.

A Generic System Life Cycle Model

There is no single “one-size-fits-all” system life cycle model that can provide specific guidance for all project situations. Figure 1, adapted from (Lawson 2010, ISO 2015, and ISO 2010), provides a generic life cycle model that forms a starting point for the most common versions of pre-specified, evolutionary, sequential, opportunistic, and concurrent life cycle processes. The model is defined as a set of stages, within which technical and management activities are performed. The stages are terminated by decision gatesdecision gates, where the key stakeholders decide whether to proceed into the next stage, to remain in the current stage, or to terminate or re-scope related projects.

Figure 1. A Generic Life Cycle Model. (SEBoK Original)

Elaborated definitions of these stages are provided in the glossary below and in various other ways in subsequent articles.

The Concept Definition stage begins with a decision by a protagonist (individual or organization) to invest resources in a new or improved engineered systemengineered system. Inception begins with a set of stakeholdersstakeholders agreeing to the need for change to an engineered system context and exploring whether new or modified SoI can be developed, in which the life cyclelife cycle benefits are worth the investments in the life cycle costslife cycle costs. Activities include: developing the concept of operations and business case; determining the key stakeholders and their desired capabilities; negotiating the stakeholder requirements among the key stakeholders and selecting the system’s non-developmental items (NDIs).

The System Definition stage begins when the key stakeholders decide that the business needs and stakeholder requirements are sufficiently well defined to justify committing the resources necessary to define a solution options in sufficient detail to answer the life cycle cost question identified in concept definition and provide a basis of system realization if appropriate. Activities include developing system architectures; defining and agreeing upon levels of system requirements; developing systems-level life cycle plans and performing system analysis in order to illustrate the compatibility and feasibility of the resulting system definition. The transition into the system realization stage can lead to either single-pass or multiple-pass development.

It should be noted that the concept and system definition activities above describe activities performed by systems engineers when performing systems engineering. There is a very strong concurrency between proposing a problem situation or opportunity and describing one or more possible system solutions, as discussed in Systems Approach Applied to Engineered Systems. Other related definition activities include: prototyping or actual development of high-risk items to show evidence of system feasibility; collaboration with business analysts or performing mission effectiveness analyses to provide a viable business case for proceeding into realization; and modifications to realized systems to improve their production, support or utilization. These activities will generally happen through the system life cycle to handle system evolution, especially under multiple-pass development. This is discussed in more detail in the Life Cycle Models knowledge area.

The System Realization stage begins when the key stakeholders decide that the SoI architecture and feasibility evidence are sufficiently low-risk to justify committing the resources necessary to develop and sustain the initial operational capability (IOC) or the single-pass development of the full operational capability (FOC). Activities include: construction of the developmental elements; integration of these elements with each other and with the non-developmental item (NDI) elements; verification and validation of the elements and their integration as it proceeds; and preparing for the concurrent production, support, and utilization activities.

The System Production, Support, and Utilization (PSU) stages begin when the key stakeholders decide that the SoI life-cycle feasibility and safety are at a sufficiently low-risk level that justifies committing the resources necessary to produce, field, support, and utilize the system over its expected lifetime. The lifetimes of production, support, and utilization are likely to be different. After market support will generally continue after production is complete and users will often continue to use unsupported systems.

System Production involves the fabrication of instances or versions of an SoI and of associated after-market spare parts. It also includes production quality monitoring and improvement; product or service acceptance activities; and continuous production process improvement. It may include low-rate initial production (LRIP) to mature the production process or to promote the continued preservation of the production capability for future spikes in demand.

Systems Support includes various classes of maintenance: corrective (for defects), adaptive (for interoperability with independently evolving co-dependent systems), and perfective (for enhancement of performance, usability, or other key performance parameters). It also includes hot lines and responders for user or emergency support and the provisioning of needed consumables (gas, water, power, etc.). Its boundaries include some gray areas, such as the boundary between small system enhancements and the development of larger complementary new additions, and the boundary between rework/maintenance of earlier fielded increments in incremental or evolutionary development. Systems Support usually continues after System Production is terminated.

System Utilization includes the use of the SoI in its context by operators, administrators, the general public, or systems above it in the system-of-interest hierarchy. It usually continues after Systems Support is terminated.

The System Retirement stage is often executed incrementally as system versions or elements become obsolete or are no longer economical to support and therefore undergo disposal or recycling of their content. Increasingly affordable considerations make system re-purposing an attractive alternative.

Applying the Life Cycle Model

Figure 1 shows just the single-step approach for proceeding through the stages of a SoI life cycle. In the Life Cycle Models knowledge area, we discuss examples of real-world enterprises and their drivers, both technical and organizational. These have led to a number of documented approaches for sequencing the life cycle stages to deal with some of the issues raised. The Life Cycle Models KA summarizes a number of incrementalincremental and evolutionaryevolutionary life cycle models, including their main strengths and weaknesses, and also discusses criteria for choosing the best-fit approach.

In Figure 1, we have listed key technical and management activities critical to successful completion of each stage. This is a useful way to illustrate the goals of each stage and gives an indication of how processes align with these stages. This can be important when considering how to plan for resources, milestones, etc. However, it is important to observe that the execution of process activities is not compartmentalized to particular life cycle stages (Lawson 2010). In Applying Life Cycle Processes, we discuss a number of views on the nature of the inter-relationships between process activities within a life cycle model. In general, the technical and management activities are applied in accordance with the principles of concurrencyconcurrency, iterationiteration and recursionrecursion described in the generic life cycle paradigm.

References

Works Cited

ISO/IEC/IEEE. 2015.Systems and Software Engineering - System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers. ISO/IEC 15288:2015.

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.

Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications.

Primary References

Forsberg, K., H. Mooz, H. Cotterman. 2005. Visualizing Project Management, 3rd Ed. Hoboken, NJ: J. Wiley & Sons.

INCOSE. 2015. 'Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities', version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0.

Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications.

Additional References

None.


< Previous Article | Parent Article | Next Article >
SEBoK v. 2.10, released 06 May 2024