Difference between revisions of "Generic Life Cycle Model"

From SEBoK
Jump to navigation Jump to search
Line 1: Line 1:
−
A [[Life Cycle (glossary)|life cycle]] is the evolution of a system, product, service, project or other human-made entity from conception through retirement (ISO/IEC 15288). This article is the first in a series on life cycle models and focuses specifically on the characteristics used to classify, discuss, and differentiate various life cycle models. It discusses how different types of systems require tailored approaches aimed toward managing life cycle and the role of systems engineers in managing them. The concepts in this article provide a foundation for the discussion of different types of life cycle models (e.g. [[System Life Cycle Process Models: Vee|Vee models]] and [[System Life Cycle Process Models: Iterative|iterative models]]), which are discussed later within this knowledge area.  Finally, life cycles provide a foundational understanding and context which supports the various phases of systems engineering, as seen throughout Part 3 (e.g. [[Concept Definition]], [[System Definition]], [[System Realization]], [[System Deployment and Use]], etc.).
+
As discussed in the generic life cycle paradigm in [[Introduction to Life Cycle Processes]] each [[System-of-Interest (glossary)]] has an associated life cycle model. The generic life cycle model below applies to a single SoI. SE must generally be synchronised across a number of such life cycle models to fully satisfy stakeholder needs. More complex life cycle models which address this are described in the [[Life Cycle Models] KA.
  
−
==Types of Value Added Products/Services==
+
==A Generic System Life Cycle Model==
  
−
Adding [[Value (glossary)|value]] through products, services, or a combination of the two, is the common purpose of all organizations; the life cycle processes used by an organization may impact their ability to deliver this value. This generally holds true whether an organization is 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.  Various management and leadership approaches can be required based upon the type and complexity of the work and the type of enterprise involved in the production. Some examples are as follows (Lawson 2010, 193-217):
+
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/IEC 2008, and ISO/IEC 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.
  
−
* A manufacturing enterprise produces nuts, bolts, and lock washer products, sells their products as value added elements to be used by other enterprises. These enterprises then integrate these products into their more encompassing value added system; for example, an aircraft or an automobile.
+
[[File:Fig_1_A_generic_life_cycle_KF.png|thumb|600px|center|'''Figure 1.  A Generic Life Cycle Model.''' (SEBoK Original)]]
−
* A wholesaling or retailing enterprise offers products to their customers. Their customers (individuals or enterprises) acquire the products and use them as elements in their systems.
 
−
* A commercial service enterprise such as a bank sells a variety of services as “products” to their customers; for example, current accounts, savings accounts, loans, and investment management.  These services add value and are incorporated into customer systems of individuals or enterprises.
 
−
* A governmental service enterprise provides citizens with services that vary widely, but may include such services as health care, highways and roads, pensions, law enforcement, and defense. When appropriate, these services become infrastructure elements utilized in larger encompassing systems of interest to individuals and/or enterprises.
 
−
* 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” can remain stable for some customers but can also change rapidly as agreements with new customers are established and as customer agreements are terminated.
 
−
* An IT service enterprise provides data processing and information access capability by operating computers, communication equipment, and software systems.
 
−
* A software development enterprise provides software products that meet stakeholder requirements (needs) thus providing services to product users. Both the developed software and the operations service become part of the set of infrastructure systems of the user enterprise.
 
  
−
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 substantial range of their process needs makes it evident that there is not a one-size-fits-all process that defines a particular 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, including competition, technology, leadership, or mission priorities.  In turn, management and leadership approaches may impact the type and number of life cycle models that are deployed as well as the processes used within any particular life cycle.
+
Elaborated definitions of these stages are provided below, in the glossary, and in various other ways in subsequent articles.
  
−
==Systems Engineer's Responsibilities==
+
The '''Concept Definition''' stage begins with a decision by a protagonist (individual or organization) to invest resources in a new or improved system. Inception begins with a set of [[Stakeholder (glossary)|stakeholders]] agreeing to the need for a system and exploring whether a new or modified system can be developed, in which the [[Life Cycle (glossary)|life cycle]] benefits are worth the investments in the [[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).
  
−
The role of the systems engineer encompasses the entire life cycle for the system-of-interest (SoI).  Systems engineers orchestrate the development of a solution from operations to determining the initial requirements ultimately until system retirement. They assure 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 establishing key [[Decision Gate (glossary)|decision gates (glossary)]], that are designed to meet the needs of their specific project.
+
The '''System Definition''' stage begins when the key stakeholders decide that that the business needs and stakeholder requirements are sufficiently well defined to justify committing the resources necessary define a whole system solution in sufficient detail to answer the life cycle cost questions identified in concept definition and provide a basis of system realization if appropriate.  Activities include developing the system’s architecture; defining and agreeing 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.
  
−
Defining the system life cycle establishes a framework for meeting the stakeholders’ needs in an orderly and efficient manner.  This is usually done by defining life cycle stages and establishing 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) or can adversely affect the technical development by reducing the level of the SE effort.
+
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.
  
−
Systems engineering tasks are typically given the most concentration at the beginning of the life cycle; however, both commercial and government organizations recognize the need for SE throughout a system’s life span. In most cases, this ongoing effort is to modify or change a system product or service after it enters production or is placed into operation.  Consequently, SE is a critical part of all life cycle stages.  During operations and support (O&S) stages, for example, SE executes performance analysis, interface monitoring, failure analysis, logistics analysis, tracking, and management, which are all activities that are essential to ongoing support of the system (see [[System Deployment and Use]]).
+
The '''System Realization''' stage begins when the key stakeholders decide that the system elements 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 with each other and with the non-developmental item (NDI) elements; verification and validation (V&V) of the elements and their integration as it proceeds; and preparing for the concurrent production, support, and utilization activities.
  
−
All project managers must ensure that the business aspects (e.g. cost, schedule, and value) and the technical aspects of a project cycle remain synchronized. For most programs, the technical aspects drive the project and it is the responsibility of the systems engineer to ensure that the technical solutions 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 businesses boundaries.  These issues also drive the need for decision gates to be 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 (e.g., hardware, software, human system interaction, or services) that meets the user and customer needs.  To ensure that the project is on the right path, frequent [[In-Process Validation (glossary)|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 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 until system closeout and disposal.
+
The '''System Production, Support, and Utilization (PSU)''' stages begins when the key stakeholders decide that the system life-cycle feasibility and safety illustrate 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.  Aftermarket support will generally continue after production is complete and users will often continue to use unsupported systems.
 +
 
 +
'''System Production''' involves the fabrication of system copies or versions and of associated aftermarket 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 system 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.
 +
 
 +
==Life Cycle Process Terminology==
 +
 
 +
===Requirement===
 +
 
 +
A [[Requirement (glossary)|requirement]] is something that is needed or wanted, but may not be compulsory in all circumstances. Requirements may refer to product or process characteristics or constraints.  Different understandings of requirements are dependent on process state, level of abstraction, and type (e.g. functional, performance, constraint).  An individual requirement may also have multiple interpretations over time.
 +
 
 +
Requirements exist at multiple levels of enterprise or system with multiple levels abstraction.  This ranges from the highest level of the enterprise capability or customer need to the lowest level of the system design Thus, requirements need to be defined at the appropriate level of detail for the level of the entity to which it applies. See the article [[Transforming Enterprise Need to Requirements]] for further detail on the transformation of needs and requirements from the enterprise to the lowest system element across concept definition and system definition.
 +
 
 +
===Architecture===
 +
 
 +
An [[Architecture (glossary)|architecture]] refers to the organizational structure of a system, whereby the system can be defined in different contexts.  Architecting is the art or practice of designing the structures. See the article [[Iterative and Recursive System Definition]] for further discussion on the use of levels Logical and Physical architecture to define related system and system elements; and support the requirements activities.
 +
 
 +
Architectures can apply for a system, product, enterprise, or service.  For example, Part 3 mostly considers product-related architectures that systems engineers create, but enterprise architecture describes the structure of an organization.  [[Enabling Systems Engineering|Part 5: Enabling Systems Engineering]] interprets enterprise architecture in a much broader manner than an IT system used across an organization, which is a specific instance of architecture.  
 +
 +
Frameworks are closely related to architectures, as they are ways of representing architectures.  The terms Architecture Framework and Architectural Framework both refer to the same.  Examples include:  DoDAF, MoDAF, NAF for representing systems in defense applications, the TOGAF open group Architecture Framework, and the Federal Enterprise Architecture Framework (FEAF) for information technology acquisition, use and disposal.  See the glossary of terms [[Architecture Framework (glossary)|Architecture Framework]] for definition and other examples.
 +
===Other Processes==
 +
 
 +
A number of other life cycle processes mentioned above, including analysis, integration, verification, validation, transition, use, maintenance and disposal are discussed in detail in the [[System Realization]] and [[Systems Deployment and Use]] knowledge areas.
 +
 
 +
==Type of Value Added Products/Services==
 +
Figure 1 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):
 +
 
 +
* 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.
 +
 
 +
* 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.
 +
 
 +
* A commercial service enterprise such as a bank sells a variety of ''products'' as services to their customers; for example, 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.
 +
 
 +
* 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 element level, there will likely be pre-specified single-pass life cycles. 
 +
 
 +
* 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.
 +
 
 +
* 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.
 +
 
 +
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.
 +
 
 +
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 [[Incremental (glossary)|incremental]] and [[Evolutionary (glossary)|evolutionary]] life cycle models, including their main strengths and weaknesses and also discusses criteria for choosing the best-fit approach.
 +
 
 +
 
 +
==References==
  
−
==References== 
 
  
 
===Works Cited===
 
===Works Cited===
−
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.
+
Anderson, D. 2010. ''Kanban.'' Sequim, WA: Blue Hole Press.
 +
 
 +
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.
 +
 +
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. 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 NCOSE'', October 1991.
 +
 
 +
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.
+
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.
+
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.
  
−
Lawson, H. 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. 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===
−
None.
+
Chrissis, M., M. Konrad, and S. Shrum. 2003. ''CMMI: Guidelines for Process Integration and Product Improvement.'' New York, NY, USA: Addison Wesley.
 +
 
 +
Larman , C. and B. Vodde. 2009. ''Scaling Lean and Agile Development.'' New York, NY, USA: Addison Wesley.
  
 
----
 
----

Revision as of 14:30, 13 May 2015

As discussed in the generic life cycle paradigm in Introduction to Life Cycle Processes each system-of-interest has an associated life cycle model. The generic life cycle model below applies to a single SoI. SE must generally be synchronised across a number of such life cycle models to fully satisfy stakeholder needs. More complex life cycle models which address this are described in the [[Life Cycle Models] KA.

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/IEC 2008, and ISO/IEC 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.

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

Elaborated definitions of these stages are provided below, in the glossary, 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 system. Inception begins with a set of stakeholders agreeing to the need for a system and exploring whether a new or modified system can be developed, in which the life cycle benefits are worth the investments in the 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).

The System Definition stage begins when the key stakeholders decide that that the business needs and stakeholder requirements are sufficiently well defined to justify committing the resources necessary define a whole system solution in sufficient detail to answer the life cycle cost questions identified in concept definition and provide a basis of system realization if appropriate. Activities include developing the system’s architecture; defining and agreeing 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 system elements 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 with each other and with the non-developmental item (NDI) elements; verification and validation (V&V) 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 begins when the key stakeholders decide that the system life-cycle feasibility and safety illustrate 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. Aftermarket support will generally continue after production is complete and users will often continue to use unsupported systems.

System Production involves the fabrication of system copies or versions and of associated aftermarket 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 system 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.

Life Cycle Process Terminology

Requirement

A requirement is something that is needed or wanted, but may not be compulsory in all circumstances. Requirements may refer to product or process characteristics or constraints. Different understandings of requirements are dependent on process state, level of abstraction, and type (e.g. functional, performance, constraint). An individual requirement may also have multiple interpretations over time.

Requirements exist at multiple levels of enterprise or system with multiple levels abstraction. This ranges from the highest level of the enterprise capability or customer need to the lowest level of the system design Thus, requirements need to be defined at the appropriate level of detail for the level of the entity to which it applies. See the article Transforming Enterprise Need to Requirements for further detail on the transformation of needs and requirements from the enterprise to the lowest system element across concept definition and system definition.

Architecture

An architecture refers to the organizational structure of a system, whereby the system can be defined in different contexts. Architecting is the art or practice of designing the structures. See the article Iterative and Recursive System Definition for further discussion on the use of levels Logical and Physical architecture to define related system and system elements; and support the requirements activities.

Architectures can apply for a system, product, enterprise, or service. For example, Part 3 mostly considers product-related architectures that systems engineers create, but enterprise architecture describes the structure of an organization. Part 5: Enabling Systems Engineering interprets enterprise architecture in a much broader manner than an IT system used across an organization, which is a specific instance of architecture.

Frameworks are closely related to architectures, as they are ways of representing architectures. The terms Architecture Framework and Architectural Framework both refer to the same. Examples include: DoDAF, MoDAF, NAF for representing systems in defense applications, the TOGAF open group Architecture Framework, and the Federal Enterprise Architecture Framework (FEAF) for information technology acquisition, use and disposal. See the glossary of terms Architecture Framework for definition and other examples.

=Other Processes

A number of other life cycle processes mentioned above, including analysis, integration, verification, validation, transition, use, maintenance and disposal are discussed in detail in the System Realization and Systems Deployment and Use knowledge areas.

Type of Value Added Products/Services

Figure 1 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):

  • 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.
  • 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.
  • A commercial service enterprise such as a bank sells a variety of products as services to their customers; for example, 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.
  • 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 element level, there will likely be pre-specified single-pass life cycles.
  • 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.
  • 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.

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.

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 incremental and evolutionary life cycle models, including their main strengths and weaknesses and also discusses criteria for choosing the best-fit approach.


References

Works Cited

Anderson, D. 2010. Kanban. Sequim, WA: Blue Hole Press.

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.

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. 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 NCOSE, October 1991.

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

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.

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

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.

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

INCOSE. 2012. 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: A New Look. Washington, DC, USA: The National Academies Press.

Additional References

Chrissis, M., M. Konrad, and S. Shrum. 2003. CMMI: Guidelines for Process Integration and Product Improvement. New York, NY, USA: Addison Wesley.

Larman , C. and B. Vodde. 2009. Scaling Lean and Agile Development. New York, NY, USA: Addison Wesley.

< Previous Article | Parent Article | Next Article >


SEBoK v. 1.9.1 released 30 September 2018

SEBoK Discussion

Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.

If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.

blog comments powered by Disqus

Retrieved from "https://sandbox.sebokwiki.org/index.php?title=Generic_Life_Cycle_Model&oldid=50661"