DTU ProjectLab - User contributions [en-gb]

Life Cycle Model

2014-12-01T11:29:45Z

Student: /* Life Cycle Model Approaches and Reflection */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an Engineering System in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. A further variation is whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle in parallel (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates that mark the end of one phase and the beginning of another. Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1). Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even additional iterations are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref>

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act is taken. Decisions which are taken during this phase do need careful consideration, as they will typically influence the whole life cycle. Even though the knowledge of the system increases as the development phase progresses, the less influence can be taken on the system (Figure 2). If, for example, a decision made at the end of the phase affects the foundation of the Engineering System, the whole phase would be subject to a second iteration.<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may be an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis|Situation Analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy|Risk Management Strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed, which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the Engineering System. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company assesses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customers and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receive poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as an activity cycle in order to enhance the product or as a complete new life cycle of an Engineering System.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any Engineering System requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention as the main system in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach could be unclear project requirements during the development phase or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value of Engineering Systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools in this context.
However, the approaches do require refinement by the user in order to achieve the best possible result in relation to the use-context. As focus areas vary in every Engineering System, so does the Life Cycle Model and its approaches demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-contexts and perspectives differ, the contents of each phase are subject to modification and adaptation.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**The Life Cycle Model in the context of sustainability; it creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. It includes the additional stage of material extraction and is focussed on the environmental, economic and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**The Product Life Cycle; the life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-12-01T11:29:25Z

Student: /* Life Cycle Model Approaches and Reflection */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an Engineering System in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. A further variation is whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle in parallel (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates that mark the end of one phase and the beginning of another. Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1). Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even additional iterations are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref>

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act is taken. Decisions which are taken during this phase do need careful consideration, as they will typically influence the whole life cycle. Even though the knowledge of the system increases as the development phase progresses, the less influence can be taken on the system (Figure 2). If, for example, a decision made at the end of the phase affects the foundation of the Engineering System, the whole phase would be subject to a second iteration.<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may be an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis|Situation Analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy|Risk Management Strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed, which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the Engineering System. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company assesses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customers and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receive poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as an activity cycle in order to enhance the product or as a complete new life cycle of an Engineering System.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any Engineering System requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention as the main system in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach could be unclear project requirements during the development phase or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value of Engineering Systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools in this context.
However, the approaches do require refinement by the user in order to achieve the best possible result in relation to their use-context. As focus areas vary in every Engineering System, so does the Life Cycle Model and its approaches demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-contexts and perspectives differ, the contents of each phase are subject to modification and adaptation.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**The Life Cycle Model in the context of sustainability; it creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. It includes the additional stage of material extraction and is focussed on the environmental, economic and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**The Product Life Cycle; the life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-12-01T11:24:59Z

Student: /* Case Example Disposal Phase */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an Engineering System in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. A further variation is whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle in parallel (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates that mark the end of one phase and the beginning of another. Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1). Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even additional iterations are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref>

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act is taken. Decisions which are taken during this phase do need careful consideration, as they will typically influence the whole life cycle. Even though the knowledge of the system increases as the development phase progresses, the less influence can be taken on the system (Figure 2). If, for example, a decision made at the end of the phase affects the foundation of the Engineering System, the whole phase would be subject to a second iteration.<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may be an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis|Situation Analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy|Risk Management Strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed, which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the Engineering System. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company assesses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customers and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receive poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as an activity cycle in order to enhance the product or as a complete new life cycle of an Engineering System.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any Engineering System requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention as the main system in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value of Engineering Systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools in this context.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every Engineering System, so does the Life Cycle Model and its approaches demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-contexts and perspectives differ, the contents of each phase are subject to modification and adaptation.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**The Life Cycle Model in the context of sustainability; it creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. It includes the additional stage of material extraction and is focussed on the environmental, economic and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**The Product Life Cycle; the life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-12-01T11:24:29Z

Student: /* Case Example Utilisation Phase */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an Engineering System in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. A further variation is whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle in parallel (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates that mark the end of one phase and the beginning of another. Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1). Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even additional iterations are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref>

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act is taken. Decisions which are taken during this phase do need careful consideration, as they will typically influence the whole life cycle. Even though the knowledge of the system increases as the development phase progresses, the less influence can be taken on the system (Figure 2). If, for example, a decision made at the end of the phase affects the foundation of the Engineering System, the whole phase would be subject to a second iteration.<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may be an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis|Situation Analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy|Risk Management Strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed, which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the Engineering System. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company assesses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customers and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an Engineering System.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any Engineering System requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention as the main system in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value of Engineering Systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools in this context.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every Engineering System, so does the Life Cycle Model and its approaches demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-contexts and perspectives differ, the contents of each phase are subject to modification and adaptation.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**The Life Cycle Model in the context of sustainability; it creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. It includes the additional stage of material extraction and is focussed on the environmental, economic and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**The Product Life Cycle; the life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-12-01T11:23:51Z

Student: /* Case Example Realisation Phase */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an Engineering System in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. A further variation is whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle in parallel (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates that mark the end of one phase and the beginning of another. Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1). Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even additional iterations are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref>

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act is taken. Decisions which are taken during this phase do need careful consideration, as they will typically influence the whole life cycle. Even though the knowledge of the system increases as the development phase progresses, the less influence can be taken on the system (Figure 2). If, for example, a decision made at the end of the phase affects the foundation of the Engineering System, the whole phase would be subject to a second iteration.<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may be an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis|Situation Analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy|Risk Management Strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed, which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the Engineering System. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company assesses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customers and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an Engineering System.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any Engineering System requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention as the main system in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value of Engineering Systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools in this context.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every Engineering System, so does the Life Cycle Model and its approaches demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-contexts and perspectives differ, the contents of each phase are subject to modification and adaptation.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**The Life Cycle Model in the context of sustainability; it creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. It includes the additional stage of material extraction and is focussed on the environmental, economic and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**The Product Life Cycle; the life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-12-01T11:23:06Z

Student: /* Development Phase */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an Engineering System in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. A further variation is whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle in parallel (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates that mark the end of one phase and the beginning of another. Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1). Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even additional iterations are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref>

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act is taken. Decisions which are taken during this phase do need careful consideration, as they will typically influence the whole life cycle. Even though the knowledge of the system increases as the development phase progresses, the less influence can be taken on the system (Figure 2). If, for example, a decision made at the end of the phase affects the foundation of the Engineering System, the whole phase would be subject to a second iteration.<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may be an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis|Situation Analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy|Risk Management Strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed, which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the Engineering System. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company assesses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an Engineering System.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any Engineering System requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention as the main system in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value of Engineering Systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools in this context.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every Engineering System, so does the Life Cycle Model and its approaches demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-contexts and perspectives differ, the contents of each phase are subject to modification and adaptation.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**The Life Cycle Model in the context of sustainability; it creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. It includes the additional stage of material extraction and is focussed on the environmental, economic and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**The Product Life Cycle; the life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-12-01T11:21:33Z

Student: /* The Life Cycle Phases */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an Engineering System in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. A further variation is whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle in parallel (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates that mark the end of one phase and the beginning of another. Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1). Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even additional iterations are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref>

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act is taken. Decisions which are taken during this phase do need careful consideration, as they will typically influence the whole life cycle. Even though the knowledge of the system increases as the development phase progresses, the less influence can be taken on the system (Figure 2). If, for example, a decision made at the end of the phase affects the foundation of the Engineering System, the whole phase would be subject to a second iteration.<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may be an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis|Situation Analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed, which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the Engineering System. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an Engineering System.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any Engineering System requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention as the main system in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value of Engineering Systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools in this context.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every Engineering System, so does the Life Cycle Model and its approaches demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-contexts and perspectives differ, the contents of each phase are subject to modification and adaptation.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**The Life Cycle Model in the context of sustainability; it creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. It includes the additional stage of material extraction and is focussed on the environmental, economic and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**The Product Life Cycle; the life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-11-30T12:01:40Z

Student: /* Variations of the Life Cycle Model */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. A further variation is whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle in parallel (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even additional iterations are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref>

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act is taken. Decisions which are taken during this phase do need careful consideration, as they will typically influence the whole life cycle. Even though the knowledge of the system increases as the development phase progresses, the less influence can be taken on the system (Figure 2). If, for example, a decision made at the end of the phase affects the foundation of the Engineering System, the whole phase would be subject to a second iteration.<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may be an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed, which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the Engineering System. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an Engineering System.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any Engineering System requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention as the main system in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value of Engineering Systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools in this context.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every Engineering System, so does the Life Cycle Model and its approaches demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-contexts and perspectives differ, the contents of each phase are subject to modification and adaptation.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**The Life Cycle Model in the context of sustainability; it creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. It includes the additional stage of material extraction and is focussed on the environmental, economic and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**The Product Life Cycle; the life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-11-30T11:56:54Z

Student: /* Variations of the Life Cycle Model */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. A further variation is whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle in parallel (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even additional iterations are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref>

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act is taken. Decisions which are taken during this phase do need careful consideration, as they will typically influence the whole life cycle. Even though the knowledge of the system increases as the development phase progresses, the less influence can be taken on the system (Figure 2). If, for example, a decision made at the end of the phase affects the foundation of the Engineering System, the whole phase would be subject to a second iteration.<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may be an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed, which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the Engineering System. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an Engineering System.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any Engineering System requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention as the main system in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value of Engineering Systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools in this context.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every Engineering System, so does the Life Cycle Model and its approaches demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**The Life Cycle Model in the context of sustainability; it creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. It includes the additional stage of material extraction and is focussed on the environmental, economic and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**The Product Life Cycle; the life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-11-30T11:55:13Z

Student: /* Variations of the Life Cycle Model */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. A further variation is whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle in parallel (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even additional iterations are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref>

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act is taken. Decisions which are taken during this phase do need careful consideration, as they will typically influence the whole life cycle. Even though the knowledge of the system increases as the development phase progresses, the less influence can be taken on the system (Figure 2). If, for example, a decision made at the end of the phase affects the foundation of the Engineering System, the whole phase would be subject to a second iteration.<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may be an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed, which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the Engineering System. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an Engineering System.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any Engineering System requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention as the main system in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value of Engineering Systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools in this context.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every Engineering System, so does the Life Cycle Model and its approaches demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**The Life Cycle Model in the context of sustainability; it creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. It further includes the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**The Product Life Cycle; the life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-11-30T11:54:16Z

Student: /* Variations of the Life Cycle Model */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. A further variation is whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle in parallel (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even additional iterations are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref>

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act is taken. Decisions which are taken during this phase do need careful consideration, as they will typically influence the whole life cycle. Even though the knowledge of the system increases as the development phase progresses, the less influence can be taken on the system (Figure 2). If, for example, a decision made at the end of the phase affects the foundation of the Engineering System, the whole phase would be subject to a second iteration.<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may be an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed, which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the Engineering System. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an Engineering System.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any Engineering System requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention as the main system in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value of Engineering Systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools in this context.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every Engineering System, so does the Life Cycle Model and its approaches demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. It further includes the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-11-30T11:52:50Z

Student: /* Variations of the Life Cycle Model */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. A further variation is whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle in parallel (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even additional iterations are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref>

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act is taken. Decisions which are taken during this phase do need careful consideration, as they will typically influence the whole life cycle. Even though the knowledge of the system increases as the development phase progresses, the less influence can be taken on the system (Figure 2). If, for example, a decision made at the end of the phase affects the foundation of the Engineering System, the whole phase would be subject to a second iteration.<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may be an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed, which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the Engineering System. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an Engineering System.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any Engineering System requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention as the main system in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value of Engineering Systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools in this context.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every Engineering System, so does the Life Cycle Model and its approaches demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-11-30T11:51:50Z

Student: /* Life Cycle Model Approaches and Reflection */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. A further variation is whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle in parallel (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even additional iterations are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref>

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act is taken. Decisions which are taken during this phase do need careful consideration, as they will typically influence the whole life cycle. Even though the knowledge of the system increases as the development phase progresses, the less influence can be taken on the system (Figure 2). If, for example, a decision made at the end of the phase affects the foundation of the Engineering System, the whole phase would be subject to a second iteration.<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may be an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed, which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the Engineering System. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an Engineering System.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any Engineering System requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention as the main system in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value of Engineering Systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools in this context.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every Engineering System, so does the Life Cycle Model and its approaches demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; Is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-11-30T11:51:11Z

Student: /* Life Cycle Model Approaches and Reflection */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. A further variation is whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle in parallel (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even additional iterations are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref>

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act is taken. Decisions which are taken during this phase do need careful consideration, as they will typically influence the whole life cycle. Even though the knowledge of the system increases as the development phase progresses, the less influence can be taken on the system (Figure 2). If, for example, a decision made at the end of the phase affects the foundation of the Engineering System, the whole phase would be subject to a second iteration.<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may be an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed, which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the Engineering System. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an Engineering System.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any Engineering System requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention as the main system in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value of Engineering Systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools in this context.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every engineering system, so does the Life Cycle Model and its approaches demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; Is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-11-30T11:49:54Z

Student: /* Life Cycle Model Approaches and Reflection */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. A further variation is whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle in parallel (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even additional iterations are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref>

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act is taken. Decisions which are taken during this phase do need careful consideration, as they will typically influence the whole life cycle. Even though the knowledge of the system increases as the development phase progresses, the less influence can be taken on the system (Figure 2). If, for example, a decision made at the end of the phase affects the foundation of the Engineering System, the whole phase would be subject to a second iteration.<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may be an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed, which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the Engineering System. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an Engineering System.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any Engineering System requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention as the main system in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value of Engineering Systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools in this context.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every engineering system, so does the Life Cycle Model demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; Is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-11-30T11:49:17Z

Student: /* Life Cycle Model Approaches and Reflection */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. A further variation is whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle in parallel (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even additional iterations are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref>

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act is taken. Decisions which are taken during this phase do need careful consideration, as they will typically influence the whole life cycle. Even though the knowledge of the system increases as the development phase progresses, the less influence can be taken on the system (Figure 2). If, for example, a decision made at the end of the phase affects the foundation of the Engineering System, the whole phase would be subject to a second iteration.<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may be an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed, which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the Engineering System. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an Engineering System.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any Engineering System requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention as the main system in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value of Engineering Systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every engineering system, so does the Life Cycle Model demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; Is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-11-30T11:48:46Z

Student: /* Life Cycle Model Approaches and Reflection */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. A further variation is whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle in parallel (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even additional iterations are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref>

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act is taken. Decisions which are taken during this phase do need careful consideration, as they will typically influence the whole life cycle. Even though the knowledge of the system increases as the development phase progresses, the less influence can be taken on the system (Figure 2). If, for example, a decision made at the end of the phase affects the foundation of the Engineering System, the whole phase would be subject to a second iteration.<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may be an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed, which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the Engineering System. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an Engineering System.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any Engineering System requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention as the main system in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value for Engineering Systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every engineering system, so does the Life Cycle Model demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; Is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-11-30T11:47:50Z

Student: /* Activity Cycles within Individual Life Cycle Phases */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. A further variation is whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle in parallel (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even additional iterations are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref>

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act is taken. Decisions which are taken during this phase do need careful consideration, as they will typically influence the whole life cycle. Even though the knowledge of the system increases as the development phase progresses, the less influence can be taken on the system (Figure 2). If, for example, a decision made at the end of the phase affects the foundation of the Engineering System, the whole phase would be subject to a second iteration.<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may be an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed, which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the Engineering System. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an Engineering System.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any Engineering System requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention as the main system in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value for engineering systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every engineering system, so does the Life Cycle Model demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; Is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-11-30T11:46:03Z

Student: /* Case Example Disposal Phase */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. A further variation is whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle in parallel (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even additional iterations are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref>

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act is taken. Decisions which are taken during this phase do need careful consideration, as they will typically influence the whole life cycle. Even though the knowledge of the system increases as the development phase progresses, the less influence can be taken on the system (Figure 2). If, for example, a decision made at the end of the phase affects the foundation of the Engineering System, the whole phase would be subject to a second iteration.<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may be an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed, which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the Engineering System. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an Engineering System.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any engineering system requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention like the main system, in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value for engineering systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every engineering system, so does the Life Cycle Model demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; Is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-11-30T11:42:33Z

Student: /* Case Example Development Phase */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. A further variation is whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle in parallel (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even additional iterations are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref>

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act is taken. Decisions which are taken during this phase do need careful consideration, as they will typically influence the whole life cycle. Even though the knowledge of the system increases as the development phase progresses, the less influence can be taken on the system (Figure 2). If, for example, a decision made at the end of the phase affects the foundation of the Engineering System, the whole phase would be subject to a second iteration.<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may be an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed, which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the Engineering System. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an engineering system.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any engineering system requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention like the main system, in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value for engineering systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every engineering system, so does the Life Cycle Model demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; Is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-11-30T11:40:25Z

Student: /* Development Phase */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. A further variation is whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle in parallel (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even additional iterations are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref>

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act is taken. Decisions which are taken during this phase do need careful consideration, as they will typically influence the whole life cycle. Even though the knowledge of the system increases as the development phase progresses, the less influence can be taken on the system (Figure 2). If, for example, a decision made at the end of the phase affects the foundation of the Engineering System, the whole phase would be subject to a second iteration.<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may be an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed, which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the Engineering System. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues raised in the first step in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an engineering system.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any engineering system requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention like the main system, in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value for engineering systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every engineering system, so does the Life Cycle Model demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; Is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-11-30T11:39:47Z

Student: /* Development Phase */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. A further variation is whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle in parallel (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even additional iterations are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref>

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act is taken. Decisions which are taken during this phase do need careful consideration, as they will typically influence the whole life cycle. Even though the knowledge of the system increases as the development phase progresses, the less influence can be taken on the system (Figure 2). If, for example, a decision made at the end of the phase affects the foundation of the Engineering System, the whole phase would be subject to a second iteration.<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may be an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed, which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the engineering system. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues raised in the first step in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an engineering system.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any engineering system requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention like the main system, in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value for engineering systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every engineering system, so does the Life Cycle Model demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; Is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-11-30T11:38:29Z

Student: /* Development Phase */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. A further variation is whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle in parallel (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even additional iterations are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref>

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act is taken. Decisions which are taken during this phase do need careful consideration, as they will typically influence the whole life cycle. Even though the knowledge of the system increases as the development phase progresses, the less influence can be taken on the system (Figure 2). If, for example, a decision made at the end of the phase affects the foundation of the Engineering System, the whole phase would be subject to a second iteration.<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may be an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the engineering system. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues raised in the first step in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an engineering system.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any engineering system requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention like the main system, in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value for engineering systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every engineering system, so does the Life Cycle Model demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; Is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-11-30T11:36:36Z

Student: /* The Life Cycle Phases */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. A further variation is whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle in parallel (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even additional iterations are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref>

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act is taken. Decisions which are taken during this phase do need careful consideration, as they will typically influence the whole life cycle. Even though the knowledge of the system increases as the development phase progresses, the less influence can be taken on the system (Figure 2). If, for example, a decision made at the end of the phase affects the foundation of the Engineering System, the whole phase would be subject to a second iteration.<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may require an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the engineering system. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues raised in the first step in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an engineering system.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any engineering system requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention like the main system, in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value for engineering systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every engineering system, so does the Life Cycle Model demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; Is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-11-30T11:26:29Z

Student: /* The Life Cycle Phases */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. Further differences include whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle parallel to the utilisation phase (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even an additional iteration are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref> Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act is taken. Decisions which are taken during this phase do need careful consideration, as they will typically influence the whole life cycle. Even though the knowledge of the system increases as the development phase progresses, the less influence can be taken on the system (Figure 2). If, for example, a decision made at the end of the phase affects the foundation of the Engineering System, the whole phase would be subject to a second iteration.<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may require an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the engineering system. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues raised in the first step in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an engineering system.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any engineering system requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention like the main system, in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value for engineering systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every engineering system, so does the Life Cycle Model demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; Is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-11-30T10:00:49Z

Student: /* Development Phase */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. Further differences include whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle parallel to the utilisation phase (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even an additional iteration are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref> Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act is taken. Decisions which are taken during this phase do need careful consideration as they will typically influence the whole life cycle. Even though the knowledge of the system increases as the development phase progresses, the less influence can be taken on the system (Figure 2). If, for example, a decision made at the end of the phase affects the foundation of the Engineering System, the whole phase would be subject to a second iteration.<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may require an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the engineering system. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues raised in the first step in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an engineering system.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any engineering system requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention like the main system, in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value for engineering systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every engineering system, so does the Life Cycle Model demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; Is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-11-30T10:00:18Z

Student: /* Development Phase */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. Further differences include whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle parallel to the utilisation phase (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even an additional iteration are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref> Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act is taken. Decisions which are taken during this phase do need careful consideration as they will typically influence the whole life cycle. Even though the knowledge of the system increases as the development phase progresses, the less influence can be taken on the system. If, for example, a decision made at the end of the phase affects the foundation of the Engineering System, the whole phase would be subject to a second iteration (Figure 2).<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may require an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the engineering system. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues raised in the first step in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an engineering system.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any engineering system requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention like the main system, in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value for engineering systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every engineering system, so does the Life Cycle Model demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; Is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-11-30T09:59:53Z

Student: /* Development Phase */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. Further differences include whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle parallel to the utilisation phase (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even an additional iteration are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref> Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act is taken. Decisions which are taken during this phase do need careful consideration as they will typically influence the whole life cycle. Even though the knowledge of the system increases as the development phase progresses, the less influence can be taken on the system. If, for example, a decision made at the end of the phase affects the foundation of the Engineering System, the whole phase would be subject to a second iteration(Figure 2).<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may require an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the engineering system. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues raised in the first step in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an engineering system.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any engineering system requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention like the main system, in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value for engineering systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every engineering system, so does the Life Cycle Model demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; Is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-11-30T09:58:51Z

Student: /* Development Phase */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. Further differences include whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle parallel to the utilisation phase (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even an additional iteration are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref> Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act is taken. Decisions which are taken during this phase do need careful consideration as they will typically influence the whole life cycle. Even though the knowledge of the system increases the further the development phase progresses, the less influence can be taken on the system. If, for example, a decision made at the end of the phase affects the foundation of the engineering system, the whole phase would be subject to a second iteration(Figure 2).<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may require an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the engineering system. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues raised in the first step in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an engineering system.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any engineering system requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention like the main system, in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value for engineering systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every engineering system, so does the Life Cycle Model demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; Is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-11-30T09:52:33Z

Student: /* Development Phase */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. Further differences include whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle parallel to the utilisation phase (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even an additional iteration are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref> Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act is taken. Decisions which are taken during this phase do need careful consideration as they will typically influence the whole life cycle. The further the development phase progresses, the less influence can be taken on the system (Figure 2).<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may require an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the engineering system. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues raised in the first step in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an engineering system.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any engineering system requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention like the main system, in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value for engineering systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every engineering system, so does the Life Cycle Model demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; Is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-11-30T09:52:11Z

Student: /* Development Phase */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. Further differences include whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle parallel to the utilisation phase (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even an additional iteration are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref> Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act are taken. Decisions which are taken during this phase do need careful consideration as they will typically influence the whole life cycle. The further the development phase progresses, the less influence can be taken on the system (Figure 2).<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may require an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the engineering system. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues raised in the first step in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an engineering system.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any engineering system requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention like the main system, in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value for engineering systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every engineering system, so does the Life Cycle Model demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; Is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-11-30T09:50:53Z

Student: /* The Life Cycle Phases */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. Further differences include whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle parallel to the utilisation phase (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even an additional iteration are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref> Decision options include whether or not to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act are taken. Decisions which are taken do need careful consideration as they will typically influence the whole life cycle. The further the development phase progresses, the less influence can be taken on the system (Figure 2).<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may require an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the engineering system. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues raised in the first step in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an engineering system.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any engineering system requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention like the main system, in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value for engineering systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every engineering system, so does the Life Cycle Model demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; Is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Talk:Life Cycle Model

2014-11-30T09:47:12Z

Student:

== Feedback from Dnhr0 ==

Hello! I enjoyed reading your article and I found a couple of good points on it that make it easy and nice to read:

* There is a nice, natural flow in the content. It was quite easy to structure and picture in my mind what I was reading.
* It was understandable, with a good use of vocabulary and, of course, examples.
* The figures clarify the content easily, and are quite interesting.
* It was nice to go through the text and see that some key words were linked to other articles in the Wiki. It is very helpful when trying to get more in-depth knowledge about a certain topic.
* The references used throughout the text are from reliable sources.
* I think the length of the article is fine, since you talk about the important things of this topic.

* ''Thanks :-)''

At the same time, I think there are some minor things that you may want to go through again in order to consider my opinion (if you find it useful). Some of my recommendations are:
* Spelling:
*''(all considered and corrected)''
** Abstract: framework instead of frame work.
** Historic Background: article instead of articel.
** The Life Cycle Phases
*** Whether instead of wether (also in Development Phase).
*** “As suggested here” instead of “as suggest here”.
*** “As an activity” instead of “as a activity”.
*** In Main study: sufficiency instead of sufficiently (that is the idea I got but maybe the meaning is different).
*** Case Example Development Phase: through instead of trough.
*** Realisation Phase: tasks instead of task ?
*** Utilisation Phase. Its instead of it’s, and “performance is monitored” instead of “performance monitored”.
*** Activity Cycles within Individual Life Cycle Phases: Another instead of “an other”.

* Grammar: You may want to review these sentences:
** Under Detailed study: “Within this phase detailed studies of the subsystems and their interrelation, which lead to detailed information about each sub solution and gives advice towards the implementation of the Engineering System.” It seems that there is a missing verb (or a part of the sentence).
**''Right, it sounds horrific. I rephrased the whole paragraph''
** Under Realisation Phase: “Examples are the production of machinery or in case of IT and service systems the full documentation of the system. The system is ready to be implemented.” The first one I would add some commas: ““Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system”. However, it looks like there is a link missing between the first and the second sentences.
**''I added the commas and created the missing link''

* In the abstract or summary, it could be a good idea to state the four phases of the life cycle model before referring to them. You start talking about these phases in the third line of the paragraph; however, you mention them until the end of it. It might be the case that you do not want to mention them before, but it was quite complicated to know what I was reading about without knowing these phases. It may also be a good idea if you state more clearly in this part what the reader is going to read in the article (explanation of the four phases, examples, variations of the model, etc.).
**''I moved the definition of the phases forward, it truly makes more sense that way. And I added a brief intro to the rest of the article.''
* Don’t forget to reference the figures in the text. They are very useful, so it could be even better if the text guides you through them.
**''done''
* It could be useful to mention (before explaining the four phases) why you have decided to take these four phases and not others. It is not clear if this is the way Rainer Züst and Peter Troxler do it, or if you got the idea from other sources. This also affects the figure with the life cycle phases and decision gates.
**''I have tried to clarify this in the revised abstract''
* I consider it important to mention what you consider throughout the article as “Systems Engineering”. You could go into small detail, probably referencing a couple of sources. I think that it might be useful to divide the background in to sections: Main Concepts and Historical Background. That way you may be able to clarify this concept and probably make explicit the relationship between this topic and project/portfolio/program management.
**''I linked systems engineering to another wiki article for clarification, added a defintion in the background part and created the link to the Life Cycle model''
* You may want to make the bullet points under the Development Phase in bold letters; however, it is just a suggestion, it may not be that relevant.
**''good idea''
* The figures could be shown a little bit bigger. As they currently are, the reader needs to click on them to actually read the content.
**''done (400px)''
* The second figure may need to add a label on the Y-axis to clearly state that it reflects influence (very helpful chart).
**''The Y-axis corresponds to the percentage of the two curves at any given stage during the development phase. The two curves indicate influence vs. knowledge on/about the project and are marked accordingly''
* It could be nice to contrast in some way the Life Cycle Model to the variations shown in the last section. You could discuss some advantages and disadvantages that this model may have, and how the other variants help or fail to address some of the disadvantages. This might not be the case if they are suitable for different circumstances.
**''I added the four different approaches in that context and tried to make clear, that the choice of method is very much dependent on the circumstances. A proper comparison of models would be outside of the scope of this article.''
* I think we do not have a specific referencing format, but it would be better for your article if they were written in the same style.
**''done''

*''thank you, for taking your time to create a very detailed and thorough feedback, it helped a great deal to improve this article!''

==Review by kikigaga==
First of all I thought it was nice and easy to read. It was kept to the point.
The other reviewer (as I can see) covered a lot of my points so I will stick to the things that were extra;)
*Think about if you want a specific angle on the concept. I thought it was nice to hear about the area but as I also know about LCA and stuff I might want to know how this differs and what you found interesting about the subject?
**''I clarified the angle on the concept as 'viewed from a systems engineering perspective' (in abstract & background), I did add minimal description of the differences in the models and backup reading if required. I don't think my personal opinion belongs into an article.''
*I liked the case company idea, but maybe you would want to introduce it in the beginning as a strategy for the article so the reader is prepared. Did you or someone else come up with the cases?
**''good point, I wrote a brief introduction to the article within the abstract, in which I incorporated your suggestion. It states as well that the company case is fictional.''
*Could there be some implementation advice?
*''I added the section Approaches and reflection in order to give an idea, in which direction a company might choose to develop''
*Are we going to know what happens to the case companies?
**''no, since its based on (science) fiction''
*I would like to see a longer discussion of the model compared to de other models. How is this better, why do companies choose other models and so on.
*''as suggested above, a proper discussion would go well beyond the scope of this article, however I added some more meat to the 'alternative model' section''

Thank you for making it interesting to read, I really enjoyed it!
*''thank you for taking your time and valuable feedback!''

Talk:Life Cycle Model

2014-11-30T09:46:02Z

Student:

== Feedback from Dnhr0 ==

Hello! I enjoyed reading your article and I found a couple of good points on it that make it easy and nice to read:

* There is a nice, natural flow in the content. It was quite easy to structure and picture in my mind what I was reading.
* It was understandable, with a good use of vocabulary and, of course, examples.
* The figures clarify the content easily, and are quite interesting.
* It was nice to go through the text and see that some key words were linked to other articles in the Wiki. It is very helpful when trying to get more in-depth knowledge about a certain topic.
* The references used throughout the text are from reliable sources.
* I think the length of the article is fine, since you talk about the important things of this topic.

* ''Thanks :-)''

At the same time, I think there are some minor things that you may want to go through again in order to consider my opinion (if you find it useful). Some of my recommendations are:
* Spelling:
*''(all considered and corrected)''
** Abstract: framework instead of frame work.
** Historic Background: article instead of articel.
** The Life Cycle Phases
*** Whether instead of wether (also in Development Phase).
*** “As suggested here” instead of “as suggest here”.
*** “As an activity” instead of “as a activity”.
*** In Main study: sufficiency instead of sufficiently (that is the idea I got but maybe the meaning is different).
*** Case Example Development Phase: through instead of trough.
*** Realisation Phase: tasks instead of task ?
*** Utilisation Phase. Its instead of it’s, and “performance is monitored” instead of “performance monitored”.
*** Activity Cycles within Individual Life Cycle Phases: Another instead of “an other”.

* Grammar: You may want to review these sentences:
** Under Detailed study: “Within this phase detailed studies of the subsystems and their interrelation, which lead to detailed information about each sub solution and gives advice towards the implementation of the Engineering System.” It seems that there is a missing verb (or a part of the sentence).
**''Right, it sounds horrific. I rephrased the whole paragraph''
** Under Realisation Phase: “Examples are the production of machinery or in case of IT and service systems the full documentation of the system. The system is ready to be implemented.” The first one I would add some commas: ““Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system”. However, it looks like there is a link missing between the first and the second sentences.
**''I added the commas and created the missing link''

* In the abstract or summary, it could be a good idea to state the four phases of the life cycle model before referring to them. You start talking about these phases in the third line of the paragraph; however, you mention them until the end of it. It might be the case that you do not want to mention them before, but it was quite complicated to know what I was reading about without knowing these phases. It may also be a good idea if you state more clearly in this part what the reader is going to read in the article (explanation of the four phases, examples, variations of the model, etc.).
**''I moved the definition of the phases forward, it truly makes more sense that way. And I added a brief intro to the rest of the article.''
* Don’t forget to reference the figures in the text. They are very useful, so it could be even better if the text guides you through them.
**''done''
* It could be useful to mention (before explaining the four phases) why you have decided to take these four phases and not others. It is not clear if this is the way Rainer Züst and Peter Troxler do it, or if you got the idea from other sources. This also affects the figure with the life cycle phases and decision gates.
**''I have tried to clarify this in the revised abstract''
* I consider it important to mention what you consider throughout the article as “Systems Engineering”. You could go into small detail, probably referencing a couple of sources. I think that it might be useful to divide the background in to sections: Main Concepts and Historical Background. That way you may be able to clarify this concept and probably make explicit the relationship between this topic and project/portfolio/program management.
**''I linked systems engineering to another wiki article for clarification, added a defintion in the background part and created the link to the Life Cycle model''
* You may want to make the bullet points under the Development Phase in bold letters; however, it is just a suggestion, it may not be that relevant.
**''good idea''
* The figures could be shown a little bit bigger. As they currently are, the reader needs to click on them to actually read the content.
**''done (400px)''
* The second figure may need to add a label on the Y-axis to clearly state that it reflects influence (very helpful chart).
**''The Y-axis corresponds to the percentage of the two curves at any given stage during the development phase. The two curves indicate influence vs. knowledge on/about the project and are marked accordingly''
* It could be nice to contrast in some way the Life Cycle Model to the variations shown in the last section. You could discuss some advantages and disadvantages that this model may have, and how the other variants help or fail to address some of the disadvantages. This might not be the case if they are suitable for different circumstances.
**''I added the four different approaches in that context and tried to make clear, that the choice of method is very much dependent on the circumstances. A proper comparison of models would be outside of the scope of this article.''
* I think we do not have a specific referencing format, but it would be better for your article if they were written in the same style.
**''done''

==Review by kikigaga==
First of all I thought it was nice and easy to read. It was kept to the point.
The other reviewer (as I can see) covered a lot of my points so I will stick to the things that were extra;)
*Think about if you want a specific angle on the concept. I thought it was nice to hear about the area but as I also know about LCA and stuff I might want to know how this differs and what you found interesting about the subject?
**''I clarified the angle on the concept as 'viewed from a systems engineering perspective' (in abstract & background), I did add minimal description of the differences in the models and backup reading if required. I don't think my personal opinion belongs into an article.''
*I liked the case company idea, but maybe you would want to introduce it in the beginning as a strategy for the article so the reader is prepared. Did you or someone else come up with the cases?
**''good point, I wrote a brief introduction to the article within the abstract, in which I incorporated your suggestion. It states as well that the company case is fictional.''
*Could there be some implementation advice?
*''I added the section Approaches and reflection in order to give an idea, in which direction a company might choose to develop''
*Are we going to know what happens to the case companies?
**''no, since its based on (science) fiction''
*I would like to see a longer discussion of the model compared to de other models. How is this better, why do companies choose other models and so on.
*''as suggested above, a proper discussion would go well beyond the scope of this article, however I added some more meat to the 'alternative model' section''

Thank you for making it interesting to read, I really enjoyed it!
*''thank you, for taking your time to create a very detailed and thorough feedback, it help a great deal to improve this article!

Talk:Life Cycle Model

2014-11-30T09:44:29Z

Student:

== Feedback from Dnhr0 ==

Hello! I enjoyed reading your article and I found a couple of good points on it that make it easy and nice to read:

* There is a nice, natural flow in the content. It was quite easy to structure and picture in my mind what I was reading.
* It was understandable, with a good use of vocabulary and, of course, examples.
* The figures clarify the content easily, and are quite interesting.
* It was nice to go through the text and see that some key words were linked to other articles in the Wiki. It is very helpful when trying to get more in-depth knowledge about a certain topic.
* The references used throughout the text are from reliable sources.
* I think the length of the article is fine, since you talk about the important things of this topic.

* ''Thanks :-)''

At the same time, I think there are some minor things that you may want to go through again in order to consider my opinion (if you find it useful). Some of my recommendations are:
* Spelling:
*''(all considered and corrected)''
** Abstract: framework instead of frame work.
** Historic Background: article instead of articel.
** The Life Cycle Phases
*** Whether instead of wether (also in Development Phase).
*** “As suggested here” instead of “as suggest here”.
*** “As an activity” instead of “as a activity”.
*** In Main study: sufficiency instead of sufficiently (that is the idea I got but maybe the meaning is different).
*** Case Example Development Phase: through instead of trough.
*** Realisation Phase: tasks instead of task ?
*** Utilisation Phase. Its instead of it’s, and “performance is monitored” instead of “performance monitored”.
*** Activity Cycles within Individual Life Cycle Phases: Another instead of “an other”.

* Grammar: You may want to review these sentences:
** Under Detailed study: “Within this phase detailed studies of the subsystems and their interrelation, which lead to detailed information about each sub solution and gives advice towards the implementation of the Engineering System.” It seems that there is a missing verb (or a part of the sentence).
**''Right, it sounds horrific. I rephrased the whole paragraph''
** Under Realisation Phase: “Examples are the production of machinery or in case of IT and service systems the full documentation of the system. The system is ready to be implemented.” The first one I would add some commas: ““Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system”. However, it looks like there is a link missing between the first and the second sentences.
**''I added the commas and created the missing link''

* In the abstract or summary, it could be a good idea to state the four phases of the life cycle model before referring to them. You start talking about these phases in the third line of the paragraph; however, you mention them until the end of it. It might be the case that you do not want to mention them before, but it was quite complicated to know what I was reading about without knowing these phases. It may also be a good idea if you state more clearly in this part what the reader is going to read in the article (explanation of the four phases, examples, variations of the model, etc.).
**''I moved the definition of the phases forward, it truly makes more sense that way. And I added a brief intro to the rest of the article.''
* Don’t forget to reference the figures in the text. They are very useful, so it could be even better if the text guides you through them.
**''done''
* It could be useful to mention (before explaining the four phases) why you have decided to take these four phases and not others. It is not clear if this is the way Rainer Züst and Peter Troxler do it, or if you got the idea from other sources. This also affects the figure with the life cycle phases and decision gates.
**''I have tried to clarify this in the revised abstract''
* I consider it important to mention what you consider throughout the article as “Systems Engineering”. You could go into small detail, probably referencing a couple of sources. I think that it might be useful to divide the background in to sections: Main Concepts and Historical Background. That way you may be able to clarify this concept and probably make explicit the relationship between this topic and project/portfolio/program management.
**''I linked systems engineering to another wiki article for clarification, added a defintion in the background part and created the link to the Life Cycle model''
* You may want to make the bullet points under the Development Phase in bold letters; however, it is just a suggestion, it may not be that relevant.
**''good idea''
* The figures could be shown a little bit bigger. As they currently are, the reader needs to click on them to actually read the content.
**''done (400px)''
* The second figure may need to add a label on the Y-axis to clearly state that it reflects influence (very helpful chart).
**''The Y-axis corresponds to the percentage of the two curves at any given stage during the development phase. The two curves indicate influence vs. knowledge on/about the project and are marked accordingly''
* It could be nice to contrast in some way the Life Cycle Model to the variations shown in the last section. You could discuss some advantages and disadvantages that this model may have, and how the other variants help or fail to address some of the disadvantages. This might not be the case if they are suitable for different circumstances.
**''I added the four different approaches in that context and tried to make clear, that the choice of method is very much dependent on the circumstances. A proper comparison of models would be outside of the scope of this article.''
* I think we do not have a specific referencing format, but it would be better for your article if they were written in the same style.
**''done''

==Review by kikigaga==
First of all I thought it was nice and easy to read. It was kept to the point.
The other reviewer (as I can see) covered a lot of my points so I will stick to the things that were extra;)
*Think about if you want a specific angle on the concept. I thought it was nice to hear about the area but as I also know about LCA and stuff I might want to know how this differs and what you found interesting about the subject?
**''I clarified the angle on the concept as 'viewed from a systems engineering perspective' (in abstract & background), I did add minimal description of the differences in the models and backup reading if required. I don't think my personal opinion belongs into an article.''
*I liked the case company idea, but maybe you would want to introduce it in the beginning as a strategy for the article so the reader is prepared. Did you or someone else come up with the cases?
**''good point, I wrote a brief introduction to the article within the abstract, in which I incorporated your suggestion. It states as well that the company case is fictional.''
*Could there be some implementation advice?
*''I added the section Approaches and reflection in order to give an idea, in which direction a company might choose to develop''
*Are we going to know what happens to the case companies?
**''no, since its based on (science) fiction''
*I would like to see a longer discussion of the model compared to de other models. How is this better, why do companies choose other models and so on.
*''as suggested above, a proper discussion would go well beyond the scope of this article, however I added some more meat to the 'alternative model' section''

Thank you for making it interesting to read, I really enjoyed it!

Life Cycle Model

2014-11-30T09:36:39Z

Student: /* Life Cycle Model Approaches and Reflection */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. Further differences include whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle parallel to the utilisation phase (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even an additional iteration are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref> Decision options include whether or to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act are taken. Decisions which are taken do need careful consideration as they will typically influence the whole life cycle. The further the development phase progresses, the less influence can be taken on the system (Figure 2).<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may require an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the engineering system. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues raised in the first step in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an engineering system.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any engineering system requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention like the main system, in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value for engineering systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable. The Agile Alliance (www.agilealliance.com) is a major driver behind the development of faster and better tools.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every engineering system, so does the Life Cycle Model demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; Is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-11-30T09:26:36Z

Student: /* Variations of the Life Cycle Model */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. Further differences include whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle parallel to the utilisation phase (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even an additional iteration are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref> Decision options include whether or to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act are taken. Decisions which are taken do need careful consideration as they will typically influence the whole life cycle. The further the development phase progresses, the less influence can be taken on the system (Figure 2).<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may require an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the engineering system. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues raised in the first step in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an engineering system.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any engineering system requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention like the main system, in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value for engineering systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every engineering system, so does the Life Cycle Model demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; Is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and emphasises the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-11-30T09:25:33Z

Student: /* Variations of the Life Cycle Model */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. Further differences include whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle parallel to the utilisation phase (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even an additional iteration are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref> Decision options include whether or to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act are taken. Decisions which are taken do need careful consideration as they will typically influence the whole life cycle. The further the development phase progresses, the less influence can be taken on the system (Figure 2).<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may require an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the engineering system. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues raised in the first step in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an engineering system.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any engineering system requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention like the main system, in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value for engineering systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every engineering system, so does the Life Cycle Model demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; Is the most 'visual' tool of the ones presented here. It illustrates Systems Engineering activities both within and in-between the life cycles phases and points out the importance of continues consolidation with the stakeholders and assessments of risk and opportunities.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-11-30T09:18:00Z

Student: /* Background */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2011.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. Further differences include whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle parallel to the utilisation phase (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even an additional iteration are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref> Decision options include whether or to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act are taken. Decisions which are taken do need careful consideration as they will typically influence the whole life cycle. The further the development phase progresses, the less influence can be taken on the system (Figure 2).<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may require an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the engineering system. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues raised in the first step in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an engineering system.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any engineering system requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention like the main system, in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value for engineering systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every engineering system, so does the Life Cycle Model demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; illustrates Systems Engineering activities with a focus on concept and development phase.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Talk:Life Cycle Model

2014-11-30T09:15:22Z

Student: /* Feedback from Dnhr0 */

== Feedback from Dnhr0 ==

Hello! I enjoyed reading your article and I found a couple of good points on it that make it easy and nice to read:

* There is a nice, natural flow in the content. It was quite easy to structure and picture in my mind what I was reading.
* It was understandable, with a good use of vocabulary and, of course, examples.
* The figures clarify the content easily, and are quite interesting.
* It was nice to go through the text and see that some key words were linked to other articles in the Wiki. It is very helpful when trying to get more in-depth knowledge about a certain topic.
* The references used throughout the text are from reliable sources.
* I think the length of the article is fine, since you talk about the important things of this topic.

* ''Thanks :-)''

At the same time, I think there are some minor things that you may want to go through again in order to consider my opinion (if you find it useful). Some of my recommendations are:
* Spelling:
*''(all considered and corrected)''
** Abstract: framework instead of frame work.
** Historic Background: article instead of articel.
** The Life Cycle Phases
*** Whether instead of wether (also in Development Phase).
*** “As suggested here” instead of “as suggest here”.
*** “As an activity” instead of “as a activity”.
*** In Main study: sufficiency instead of sufficiently (that is the idea I got but maybe the meaning is different).
*** Case Example Development Phase: through instead of trough.
*** Realisation Phase: tasks instead of task ?
*** Utilisation Phase. Its instead of it’s, and “performance is monitored” instead of “performance monitored”.
*** Activity Cycles within Individual Life Cycle Phases: Another instead of “an other”.

* Grammar: You may want to review these sentences:
** Under Detailed study: “Within this phase detailed studies of the subsystems and their interrelation, which lead to detailed information about each sub solution and gives advice towards the implementation of the Engineering System.” It seems that there is a missing verb (or a part of the sentence).
**''Right, it sounds horrific. I rephrased the whole paragraph''
** Under Realisation Phase: “Examples are the production of machinery or in case of IT and service systems the full documentation of the system. The system is ready to be implemented.” The first one I would add some commas: ““Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system”. However, it looks like there is a link missing between the first and the second sentences.
**''I added the commas and created the missing link''

* In the abstract or summary, it could be a good idea to state the four phases of the life cycle model before referring to them. You start talking about these phases in the third line of the paragraph; however, you mention them until the end of it. It might be the case that you do not want to mention them before, but it was quite complicated to know what I was reading about without knowing these phases. It may also be a good idea if you state more clearly in this part what the reader is going to read in the article (explanation of the four phases, examples, variations of the model, etc.).
**''I moved the definition of the phases forward, it truly makes more sense that way. And I added a brief intro to the rest of the article.''
* Don’t forget to reference the figures in the text. They are very useful, so it could be even better if the text guides you through them.
**''done''
* It could be useful to mention (before explaining the four phases) why you have decided to take these four phases and not others. It is not clear if this is the way Rainer Züst and Peter Troxler do it, or if you got the idea from other sources. This also affects the figure with the life cycle phases and decision gates.
**''I have tried to clarify this in the revised abstract''
* I consider it important to mention what you consider throughout the article as “Systems Engineering”. You could go into small detail, probably referencing a couple of sources. I think that it might be useful to divide the background in to sections: Main Concepts and Historical Background. That way you may be able to clarify this concept and probably make explicit the relationship between this topic and project/portfolio/program management.
**''I linked systems engineering to another wiki article for clarification, added a defintion in the background part and created the link to the Life Cycle model''
* You may want to make the bullet points under the Development Phase in bold letters; however, it is just a suggestion, it may not be that relevant.
**''good idea''
* The figures could be shown a little bit bigger. As they currently are, the reader needs to click on them to actually read the content.
**''done (400px)''
* The second figure may need to add a label on the Y-axis to clearly state that it reflects influence (very helpful chart).
**''The Y-axis corresponds to the percentage of the two curves at any given stage during the development phase. The two curves indicate influence vs. knowledge on/about the project and are marked accordingly''
* It could be nice to contrast in some way the Life Cycle Model to the variations shown in the last section. You could discuss some advantages and disadvantages that this model may have, and how the other variants help or fail to address some of the disadvantages. This might not be the case if they are suitable for different circumstances.
* I think we do not have a specific referencing format, but it would be better for your article if they were written in the same style.
**done

==Review by kikigaga==
First of all I thought it was nice and easy to read. It was kept to the point.
The other reviewer (as I can see) covered a lot of my points so I will stick to the things that were extra;)
*Think about if you want a specific angle on the concept. I thought it was nice to hear about the area but as I also know about LCA and stuff I might want to know how this differs and what you found interesting about the subject?
**''I clarified the angle on the concept as 'viewed from a systems engineering perspective' (in abstract & background), I did add minimal description of the differences in the models and backup reading if required. I don't think my personal opinion belongs into an article.''
*I liked the case company idea, but maybe you would want to introduce it in the beginning as a strategy for the article so the reader is prepared. Did you or someone else come up with the cases?
**''good point, I wrote a brief introduction to the article within the abstract, in which I incorporated your suggestion. It state as well that the company case is fictional.''
*Could there be some implementation advice?
*Are we going to know what happens to the case companies?
**''since its based on (science) fiction, I would say no.''
*I would like to see a longer discussion of the model compared to de other models. How is this better, why do companies choose other models and so on.

Thank you for making it interesting to read, I really enjoyed it!

Life Cycle Model

2014-11-30T09:14:12Z

Student:

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA. 2012.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.</ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS"></ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. Further differences include whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle parallel to the utilisation phase (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288. 2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even an additional iteration are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref> Decision options include whether or to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act are taken. Decisions which are taken do need careful consideration as they will typically influence the whole life cycle. The further the development phase progresses, the less influence can be taken on the system (Figure 2).<ref name="HBSP">Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may require an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the engineering system. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues raised in the first step in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an engineering system.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any engineering system requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention like the main system, in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value for engineering systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every engineering system, so does the Life Cycle Model demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; illustrates Systems Engineering activities with a focus on concept and development phase.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. 1983</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.</ref>

==References==

<references/>

Life Cycle Model

2014-11-28T08:53:08Z

Student: /* Life Cycle Model Approaches and Reflection */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. No More Muddling Through: Mastering Complex Projects in Engineering and Management (2006): 1-185. Web.</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects.”. Project Management Journal 33.1 (2002): 12. Print.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Institute., Project Management. A Guide To the Project Management Body of Knowledge : PMBOK Guide. Project Management Institute, 2004. Print.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. (1997) Life-Cycle Management, in Project Management Handbook, Second Edition (eds D. I. Cleland and W. R. King), John Wiley & Sons, Inc., Hoboken, NJ, USA. </ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS">INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.</ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. Further differences include whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle parallel to the utilisation phase (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288:2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even an additional iteration are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref> Decision options include whether or to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act are taken. Decisions which are taken do need careful consideration as they will typically influence the whole life cycle. The further the development phase progresses, the less influence can be taken on the system (Figure 2).<ref name="HBSP">Haberfellner R. et al., 2002, Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich.</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may require an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the engineering system. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues raised in the first step in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an engineering system.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any engineering system requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R., 2002, ECODESIGN PILOT – Product-Investigation, Learn- ing and Optimisation-Tool for Sustainable Product Development with CD- ROM, Kluwer Academic Pubishers, Dordrecht (NL).</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention like the main system, in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value for engineering systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every engineering system, so does the Life Cycle Model demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; illustrates Systems Engineering activities with a focus on concept and development phase.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. (1 October 1983). "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. doi:10.1109/MAHC.1983.10102. Retrieved 2011-03-21.</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, August 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. (1996). Entry, exit, growth, and innovation over the product life cycle. AMERICAN ECONOMIC REVIEW, 86(3), 562-583.</ref>

==References==

<references/>

Life Cycle Model

2014-11-28T08:52:06Z

Student: /* Life Cycle Model Approaches and Reflection */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. No More Muddling Through: Mastering Complex Projects in Engineering and Management (2006): 1-185. Web.</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects.”. Project Management Journal 33.1 (2002): 12. Print.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Institute., Project Management. A Guide To the Project Management Body of Knowledge : PMBOK Guide. Project Management Institute, 2004. Print.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. (1997) Life-Cycle Management, in Project Management Handbook, Second Edition (eds D. I. Cleland and W. R. King), John Wiley & Sons, Inc., Hoboken, NJ, USA. </ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS">INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.</ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. Further differences include whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle parallel to the utilisation phase (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288:2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even an additional iteration are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref> Decision options include whether or to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act are taken. Decisions which are taken do need careful consideration as they will typically influence the whole life cycle. The further the development phase progresses, the less influence can be taken on the system (Figure 2).<ref name="HBSP">Haberfellner R. et al., 2002, Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich.</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may require an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the engineering system. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues raised in the first step in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an engineering system.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any engineering system requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R., 2002, ECODESIGN PILOT – Product-Investigation, Learn- ing and Optimisation-Tool for Sustainable Product Development with CD- ROM, Kluwer Academic Pubishers, Dordrecht (NL).</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention like the main system, in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value for engineering systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every engineering system, so does the Life Cycle Model demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

So the organisation has to....

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; illustrates Systems Engineering activities with a focus on concept and development phase.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. (1 October 1983). "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. doi:10.1109/MAHC.1983.10102. Retrieved 2011-03-21.</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, August 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. (1996). Entry, exit, growth, and innovation over the product life cycle. AMERICAN ECONOMIC REVIEW, 86(3), 562-583.</ref>

==References==

<references/>

Life Cycle Model

2014-11-28T08:51:40Z

Student: /* Life Cycle Model Approaches and Reflection */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. No More Muddling Through: Mastering Complex Projects in Engineering and Management (2006): 1-185. Web.</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects.”. Project Management Journal 33.1 (2002): 12. Print.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Institute., Project Management. A Guide To the Project Management Body of Knowledge : PMBOK Guide. Project Management Institute, 2004. Print.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. (1997) Life-Cycle Management, in Project Management Handbook, Second Edition (eds D. I. Cleland and W. R. King), John Wiley & Sons, Inc., Hoboken, NJ, USA. </ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS">INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.</ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. Further differences include whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle parallel to the utilisation phase (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288:2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even an additional iteration are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref> Decision options include whether or to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act are taken. Decisions which are taken do need careful consideration as they will typically influence the whole life cycle. The further the development phase progresses, the less influence can be taken on the system (Figure 2).<ref name="HBSP">Haberfellner R. et al., 2002, Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich.</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may require an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the engineering system. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues raised in the first step in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an engineering system.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any engineering system requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R., 2002, ECODESIGN PILOT – Product-Investigation, Learn- ing and Optimisation-Tool for Sustainable Product Development with CD- ROM, Kluwer Academic Pubishers, Dordrecht (NL).</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention like the main system, in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. In practice, four different approaches to the Life Cycle Model can be specified (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value for engineering systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''Agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable.
However, depending on the use-context the approaches do require refinement by the user in order to achieve the best possible result. As focus areas vary in every engineering system, so does the Life Cycle Model demand for adjustment of the utilised tools and methods, to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
::A “one size fits all” approach does not work when defining processes, thus organisations must continuously document, define, measure, analyse, assess, compare, and change processes to best meet project goals.

So the organisation has to....

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; illustrates Systems Engineering activities with a focus on concept and development phase.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. (1 October 1983). "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. doi:10.1109/MAHC.1983.10102. Retrieved 2011-03-21.</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, August 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. (1996). Entry, exit, growth, and innovation over the product life cycle. AMERICAN ECONOMIC REVIEW, 86(3), 562-583.</ref>

==References==

<references/>

Life Cycle Model

2014-11-28T08:45:14Z

Student: /* Life Cycle Model Approaches and Reflection */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. No More Muddling Through: Mastering Complex Projects in Engineering and Management (2006): 1-185. Web.</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects.”. Project Management Journal 33.1 (2002): 12. Print.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Institute., Project Management. A Guide To the Project Management Body of Knowledge : PMBOK Guide. Project Management Institute, 2004. Print.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. (1997) Life-Cycle Management, in Project Management Handbook, Second Edition (eds D. I. Cleland and W. R. King), John Wiley & Sons, Inc., Hoboken, NJ, USA. </ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS">INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.</ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. Further differences include whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle parallel to the utilisation phase (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288:2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even an additional iteration are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref> Decision options include whether or to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act are taken. Decisions which are taken do need careful consideration as they will typically influence the whole life cycle. The further the development phase progresses, the less influence can be taken on the system (Figure 2).<ref name="HBSP">Haberfellner R. et al., 2002, Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich.</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may require an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the engineering system. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues raised in the first step in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an engineering system.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any engineering system requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R., 2002, ECODESIGN PILOT – Product-Investigation, Learn- ing and Optimisation-Tool for Sustainable Product Development with CD- ROM, Kluwer Academic Pubishers, Dordrecht (NL).</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention like the main system, in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==

In practice, four different approaches to the Life Cycle Model exist (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value for engineering systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*The focus of '''Agile development''' is on flexibility. Selected events may be taken out of sequence, considered the risk is acceptable.

The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. Depending on the use-context it does need refinement by the user in order to achieve the best possible result. As focus areas vary in every project, so does the Life Cycle Model require adjustment of the included tools and methods, which are used during the four phases of the life cycle to ensure a relevance to the issues that shall be addressed. INCOSE states in this context:
A􏰀 “one􏰀 size􏰀 fits􏰀 all”􏰀 approach􏰀 does􏰀 not􏰀 work􏰀 when􏰀 defining􏰀 processes,􏰀 thus􏰀 organizations􏰀 must􏰀 continuously􏰀 document,􏰀define,􏰀measure,􏰀analyze,􏰀assess,􏰀compare,􏰀and􏰀change􏰀processes􏰀to􏰀 best􏰀 meet􏰀 project􏰀 goals.

As noted above a variety of Life Cycle Models have been developed already and every single one does differ by the targeted application.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; illustrates Systems Engineering activities with a focus on concept and development phase.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. (1 October 1983). "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. doi:10.1109/MAHC.1983.10102. Retrieved 2011-03-21.</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, August 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. (1996). Entry, exit, growth, and innovation over the product life cycle. AMERICAN ECONOMIC REVIEW, 86(3), 562-583.</ref>

==References==

<references/>

Life Cycle Model

2014-11-28T08:28:55Z

Student: /* Life Cycle Model Approaches and Reflection */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. No More Muddling Through: Mastering Complex Projects in Engineering and Management (2006): 1-185. Web.</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects.”. Project Management Journal 33.1 (2002): 12. Print.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Institute., Project Management. A Guide To the Project Management Body of Knowledge : PMBOK Guide. Project Management Institute, 2004. Print.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. (1997) Life-Cycle Management, in Project Management Handbook, Second Edition (eds D. I. Cleland and W. R. King), John Wiley & Sons, Inc., Hoboken, NJ, USA. </ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS">INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.</ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. Further differences include whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle parallel to the utilisation phase (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288:2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even an additional iteration are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref> Decision options include whether or to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act are taken. Decisions which are taken do need careful consideration as they will typically influence the whole life cycle. The further the development phase progresses, the less influence can be taken on the system (Figure 2).<ref name="HBSP">Haberfellner R. et al., 2002, Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich.</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may require an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the engineering system. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues raised in the first step in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an engineering system.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any engineering system requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R., 2002, ECODESIGN PILOT – Product-Investigation, Learn- ing and Optimisation-Tool for Sustainable Product Development with CD- ROM, Kluwer Academic Pubishers, Dordrecht (NL).</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention like the main system, in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. Depending on the use-context it does need refinement by the user in order to achieve the best possible result. As focus areas vary in every project, so does the Life Cycle Model require adjustment of the included tools and methods, which are used during the four phases of the life cycle to ensure a relevance to the issues that shall be addressed.

In practice, four different approaches to the Life Cycle Model exist (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.
*'''Lean development''' adapts lean thinking in Systems Engineering. [[Lean Project Management]] aims to increase the life cycle value for engineering systems while reducing waste (e.g budget and schedule overruns, poor coordination, unstable requirements, quality problems, management frustration) to a minimum.
*'''Agile development'''

As noted above a variety of Life Cycle Models have been developed already and every single one does differ by the targeted application.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; illustrates Systems Engineering activities with a focus on concept and development phase.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. (1 October 1983). "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. doi:10.1109/MAHC.1983.10102. Retrieved 2011-03-21.</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, August 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. (1996). Entry, exit, growth, and innovation over the product life cycle. AMERICAN ECONOMIC REVIEW, 86(3), 562-583.</ref>

==References==

<references/>

Life Cycle Model

2014-11-28T08:17:28Z

Student: /* Life Cycle Model Approaches and Reflection */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. No More Muddling Through: Mastering Complex Projects in Engineering and Management (2006): 1-185. Web.</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects.”. Project Management Journal 33.1 (2002): 12. Print.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Institute., Project Management. A Guide To the Project Management Body of Knowledge : PMBOK Guide. Project Management Institute, 2004. Print.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. (1997) Life-Cycle Management, in Project Management Handbook, Second Edition (eds D. I. Cleland and W. R. King), John Wiley & Sons, Inc., Hoboken, NJ, USA. </ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS">INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.</ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. Further differences include whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle parallel to the utilisation phase (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288:2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even an additional iteration are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref> Decision options include whether or to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act are taken. Decisions which are taken do need careful consideration as they will typically influence the whole life cycle. The further the development phase progresses, the less influence can be taken on the system (Figure 2).<ref name="HBSP">Haberfellner R. et al., 2002, Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich.</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may require an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the engineering system. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues raised in the first step in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an engineering system.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any engineering system requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R., 2002, ECODESIGN PILOT – Product-Investigation, Learn- ing and Optimisation-Tool for Sustainable Product Development with CD- ROM, Kluwer Academic Pubishers, Dordrecht (NL).</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention like the main system, in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. Depending on the use-context it does need refinement by the user in order to achieve the best possible result. As focus areas vary in every project, so does the Life Cycle Model require adjustment of the included tools and methods, which are used during the four phases of the life cycle to ensure a relevance to the issues that shall be addressed.

In practice, four different approaches to the Life Cycle Model exist (adapted from INCOSE)<ref name="HBTS"></ref>:
*The '''plan-driven method''' is the traditional way to build systems with a systematic approach and specific processes. Advantages of this approach include predictability, stability, repeatability, and high assurance.
*The '''incremental and Iterative development''' differs from the plan driven method in its increased speed and adaptability. It can be applied on smaller projects in which flexibility is required. Reasons to apply this approach would be for example if the project requirements are unclear at the beginning or if integration of emerging technologies during the development of the system should be possible.

Incremental􏰀 and􏰀 iterative􏰀 development􏰀 (IID)􏰀 methods􏰀 have􏰀 been􏰀 in􏰀 use􏰀 since􏰀 the􏰀 1960s.19􏰀 They􏰀 represent􏰀 a􏰀 practical􏰀 and􏰀 useful􏰀 approach􏰀 that􏰀 allows􏰀 a􏰀 project􏰀to􏰀provide􏰀an􏰀initial􏰀capability􏰀followed􏰀by􏰀successive􏰀deliveries􏰀to􏰀reach􏰀 the􏰀 desired􏰀 system􏰁of􏰁interest.􏰀 The􏰀 goal􏰀 is􏰀 to􏰀 provide􏰀 rapid􏰀 value􏰀 and􏰀 responsiveness.􏰀 This􏰀 approach􏰀 is􏰀 generally􏰀 presented􏰀 in􏰀 opposition􏰀 to􏰀 the􏰀 perceived􏰀burden􏰀associated􏰀with􏰀using􏰀any􏰀process,􏰀including􏰀those􏰀defined􏰀in􏰀 this􏰀handbook.􏰀
The􏰀 IID􏰀 approach􏰀 is􏰀 used􏰀 when􏰀 the􏰀 requirements􏰀 are􏰀 unclear􏰀 from􏰀 the􏰀 beginning􏰀 or􏰀 the􏰀 customer􏰀 wishes􏰀 to􏰀 hold􏰀 the􏰀 system􏰁of􏰁interest􏰀 open􏰀 to􏰀 the􏰀 possibilities􏰀of􏰀inserting􏰀new􏰀technology.􏰀Based􏰀on􏰀an􏰀initial􏰀set􏰀of􏰀assumptions,􏰀 a􏰀 candidate􏰀 system􏰁of􏰁interest􏰀 is􏰀 developed􏰀 and􏰀 then􏰀 assessed􏰀 to􏰀 determine􏰀 if􏰀 it􏰀 meets􏰀 user􏰀 needs􏰀 or􏰀 requirements.􏰀 If􏰀 not,􏰀 another􏰀 evolutionary􏰀 round􏰀 is􏰀 initiated,􏰀 and􏰀 the􏰀 process􏰀 is􏰀 repeated􏰀 until􏰀 a􏰀 system􏰀 is􏰀 delivered􏰀 to􏰀 satisfied􏰀 stakeholders􏰀or􏰀until􏰀the􏰀organization􏰀decides􏰀to􏰀terminate􏰀the􏰀effort.􏰀􏰀

*'''Lean development'''
*'''Agile development'''

As noted above a variety of Life Cycle Models have been developed already and every single one does differ by the targeted application.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; illustrates Systems Engineering activities with a focus on concept and development phase.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. (1 October 1983). "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. doi:10.1109/MAHC.1983.10102. Retrieved 2011-03-21.</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, August 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. (1996). Entry, exit, growth, and innovation over the product life cycle. AMERICAN ECONOMIC REVIEW, 86(3), 562-583.</ref>

==References==

<references/>

Life Cycle Model

2014-11-28T08:00:17Z

Student: /* Life Cycle Model Approaches and Reflection */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. No More Muddling Through: Mastering Complex Projects in Engineering and Management (2006): 1-185. Web.</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects.”. Project Management Journal 33.1 (2002): 12. Print.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Institute., Project Management. A Guide To the Project Management Body of Knowledge : PMBOK Guide. Project Management Institute, 2004. Print.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. (1997) Life-Cycle Management, in Project Management Handbook, Second Edition (eds D. I. Cleland and W. R. King), John Wiley & Sons, Inc., Hoboken, NJ, USA. </ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS">INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.</ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. Further differences include whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle parallel to the utilisation phase (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288:2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even an additional iteration are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref> Decision options include whether or to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act are taken. Decisions which are taken do need careful consideration as they will typically influence the whole life cycle. The further the development phase progresses, the less influence can be taken on the system (Figure 2).<ref name="HBSP">Haberfellner R. et al., 2002, Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich.</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may require an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the engineering system. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues raised in the first step in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an engineering system.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any engineering system requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R., 2002, ECODESIGN PILOT – Product-Investigation, Learn- ing and Optimisation-Tool for Sustainable Product Development with CD- ROM, Kluwer Academic Pubishers, Dordrecht (NL).</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention like the main system, in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. Depending on the use-context it does need refinement by the user in order to achieve the best possible result. As focus areas vary in every project, so does the Life Cycle Model require adjustment of the included tools and methods, which are used during the four phases of the life cycle to ensure a relevance to the issues that shall be addressed.

In practice, four different approaches to the Life Cycle Model exist (adapted from INCOSE)<ref name="HBTS"></ref>:
*The plan-driven method
*The incremental & Iterative development
*Lean development
*Agile development

As noted above a variety of Life Cycle Models have been developed already and every single one does differ by the targeted application.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; illustrates Systems Engineering activities with a focus on concept and development phase.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. (1 October 1983). "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. doi:10.1109/MAHC.1983.10102. Retrieved 2011-03-21.</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, August 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. (1996). Entry, exit, growth, and innovation over the product life cycle. AMERICAN ECONOMIC REVIEW, 86(3), 562-583.</ref>

==References==

<references/>

Life Cycle Model

2014-11-28T07:46:19Z

Student: /* Development Phase */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. No More Muddling Through: Mastering Complex Projects in Engineering and Management (2006): 1-185. Web.</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects.”. Project Management Journal 33.1 (2002): 12. Print.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Institute., Project Management. A Guide To the Project Management Body of Knowledge : PMBOK Guide. Project Management Institute, 2004. Print.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. (1997) Life-Cycle Management, in Project Management Handbook, Second Edition (eds D. I. Cleland and W. R. King), John Wiley & Sons, Inc., Hoboken, NJ, USA. </ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS">INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.</ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. Further differences include whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle parallel to the utilisation phase (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288:2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even an additional iteration are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref> Decision options include whether or to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act are taken. Decisions which are taken do need careful consideration as they will typically influence the whole life cycle. The further the development phase progresses, the less influence can be taken on the system (Figure 2).<ref name="HBSP">Haberfellner R. et al., 2002, Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich.</ref>
The development phase consists of four steps:
*The '''proposal for systems design''' originates at the recognition of a need for change. The change may require an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed which are concretised during the main study.
*The '''main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the engineering system. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues raised in the first step in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an engineering system.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any engineering system requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R., 2002, ECODESIGN PILOT – Product-Investigation, Learn- ing and Optimisation-Tool for Sustainable Product Development with CD- ROM, Kluwer Academic Pubishers, Dordrecht (NL).</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention like the main system, in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
In practice, four different approaches to the Life Cycle Model exist (adapted from INCOSE)<ref name="HBTS"></ref>:
*The plan-driven method
*The incremental & Iterative development
*Lean development
*Agile development

The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. However, depending on the use-context it does need refinement by the user in order to achieve the best possible result. As focus areas vary in every project, so does the Life Cycle Model need adjustment of the tools and methods, which are used during the four phases of the life cycle to ensure a relevance to the issues that shall be addressed. As noted above a variety of Life Cycle Models have been developed already and every single one does differ by the targeted application. As Systems Engineering itself encompasses a huge variety of products, technical and other systems, it might be reasonable to clarify, which tools can be utilised during which phase and how they can contribute to the specific challenges.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; illustrates Systems Engineering activities with a focus on concept and development phase.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. (1 October 1983). "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. doi:10.1109/MAHC.1983.10102. Retrieved 2011-03-21.</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, August 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. (1996). Entry, exit, growth, and innovation over the product life cycle. AMERICAN ECONOMIC REVIEW, 86(3), 562-583.</ref>

==References==

<references/>

Life Cycle Model

2014-11-28T07:45:52Z

Student: /* Development Phase */

The Life Cycle Model is one of two methodical concepts that build the basis for [[Systems Engineering versus Project Management, a comparative study|Systems Engineering]]. Next to the Problem-Solving concept, which deals with the challenge of developing solutions for project management challenges, the Life Cycle Model aims to structure the life of an engineering system by a number of subsequent phases. Commonly those include development, realisation, utilisation and disposal. The Life Cycle Model can be understood as an overall framework that defines criteria and expected results for each phase. This allows for the evaluation of technical systems according to their current position within the life cycle. Each phase can be supported by a variety of tools and methods, which are relevant to the project and its content. Deviations on the denominations, quantity and content of those phases do exist and are discussed in the chapter [[#Variations of the Life Cycle Model|Variations of the Life Cycle Model]]. This article is primarily based on the work of Rainer Züst and Peter Troxler<ref name="HBS">Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. No More Muddling Through: Mastering Complex Projects in Engineering and Management (2006): 1-185. Web.</ref>, who propose the use of the Life Cycle Model in a Systems Engineering context. The article follows the Life Cycle Model phases chronologically, providing a theoretic backbone, which is illustrated by case examples of the fictional company A.

==Background==
The here introduced Life Cycle Model aims to adapt the holistic view derived from Systems Engineering. The model does not only apply to a specific product, but includes the context of its use and its interaction with other systems. System Engineering as used in this article is understood as:

::Systems engineering is an interdisciplinary approach and means to enable the realisation of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.<ref name="HBTS">INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.</ref>

The origin of the Life Cycle Model can not be clearly attributed to a single author.<ref name="HS">Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects.”. Project Management Journal 33.1 (2002): 12. Print.</ref> A range of similar models have been presented by the guide [[Project Management Book of Knowledge]]<ref name="HPS">Institute., Project Management. A Guide To the Project Management Body of Knowledge : PMBOK Guide. Project Management Institute, 2004. Print.</ref> and the Project Management Handbook.<ref name="HPPS">King, W. R. and Cleland, D. I. (1997) Life-Cycle Management, in Project Management Handbook, Second Edition (eds D. I. Cleland and W. R. King), John Wiley & Sons, Inc., Hoboken, NJ, USA. </ref> Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook<ref name="HBTS">INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.</ref> and the publication Systems Engineering Practice.<ref name="HBXS">R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014</ref>

== The Life Cycle Phases ==
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]]
Most of the literature divides the life cycle of an engineering system in-between four to seven stages. While the content of the model and its phases is depended on the targeted system, there are different definitions of each stage. INCOSE for example splits the development stage into three substages which encompass exploratory research, concept and development phase<ref name="HBTS"></ref>, whereas Züst et al.<ref name="HBS"></ref> suggest to include all three stages in one development phase. Further differences include whether the support/maintenance phase is excluded of the utilisation phase or, as suggested here, exists as an activity cycle parallel to the utilisation phase (Figure 1). A definition out of the ISO 15288 standards states in this context:

::6.2.1.3 (a) (5) NOTE The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the system-of-interest's scope, magnitude, complexity, changing needs and opportunities.<ref name="HBSPP">ISO/IEC 15288:2008</ref>

The statement puts the focus correctly on the important fact that no matter which Life Cycle Model is chosen, the user will have to adapt it to the engineering system he/she attempts to structure.

A common feature of any structure in the Life Cycle Model are the decisions gates, which mark the end of one phase and the beginning of another. Primarily the focus is on the quality of the results of a particular phase and the decision wether those results allow to progress forward or if adjustments or even an additional iteration are required. Any project progression without reaching the previous' phases goals may entail increasing risk as the project develops.<ref name="HBTS"></ref> Decision options include whether or to continue to the next phase and how shortcomings of the previous phase are addressed (Figure 1).

=== Development Phase ===
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]]
This early phase in the life cycle is crucial for the development of any Engineering System. Here the need for change is established and the decision whether or not to act are taken. Decisions which are taken do need careful consideration as they will typically influence the whole life cycle. The further the development phase progresses, the less influence can be taken on the system (Figure 2).<ref name="HBSP">Haberfellner R. et al., 2002, Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich.</ref>
The development phase consists of four steps:
*The '''Proposal for systems design''' originates at the recognition of a need for change. The change may require an improvement of an Engineering System or its new development. A commonly used tool in this stage is the [[SWOT analysis]] in order to pinpoint weaknesses or opportunities. Based on an assessment of the need, the decision whether or not to solve the challenge is taken.
*The '''Preliminary study''' aims to provide a broad picture of the challenge. It includes elements like [[Stakeholder Analysis]] and [[Situation analysis]]. The target of the preliminary study is a clear problem description and a set of objectives which shall be addressed by a potential solution. Furthermore an overview of risk and uncertainties is established, which for example can be addressed by the application of [[Risk management strategy]]. When dealing with complex projects the [[Causal Loop Diagram]] might support efforts to achieve further structure within the preliminary study. Concept proposals are developed which are concretised during the main study.
*The '''Main study''' aims to specify the concepts in detail. The focus shifts from a broad perspective to the engineering system. The concepts are evaluated against the objectives in order to establish their suitability towards the problem solution and investigates whether issues like stakeholder involvement or critical components within the system are known and dealt with sufficiently.
*The '''Detailed study''' specifies the studies of the subsystems and their interrelations in-depth. The focus shifts to specific aspects of the solution, which might be critical in relation to e.g. risk, uncertainty or unexplored issues, which previously have been neglected. The output of this phase is accurate information about each subsystem and gives advice towards the implementation of the Engineering System.
==== Case Example Development Phase ====
The case company A, experiences unpleasant feedback from their customers on one of their products. The need for change is recognised and the decision to improve the situation is taken (proposal to system design). The company asses the extend of the problem. Internal as well as external factors are included in order to pinpoint the origin of the problems. The key stakeholders are identified and the area of solution defined. The search for solutions through creative methods leads to the development of concepts, which may be evaluated by using tools such as Cost-Benefit Analysis or an evaluation matrix with a specific set of criteria (preliminary study).
The preferred concept is specified and analysed in detail to establish the effect that can be expected to influence the system (main study). Finally each of the systems parts are studied in detail in order to ensure that the concept addresses all issues raised in the first step in a high quality.

=== Realisation Phase ===
The realisation phase covers the transition in between the development and utilisation phases. It can be divided in two major steps, which are system realisation and system installation. The system realisation includes tasks which transform the concept into a tangible system. Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system. At this point, the system is ready to be implemented.
The second phase describes the implementation itself. The system is rolled out, which includes the system's installation and the instruction of the customer/end-user.

====Case Example Realisation Phase====
Company A has developed a concrete concept to deal with its unsatisfied customer and chooses to redesign their existing product. The new product is developed in accordance to the established objectives, defined during the previous phase. Documentation for the new product needs to be released and customers, who are in possession of the previous product get informed about the possibility to upgrade.

=== Utilisation Phase ===
The System is in operation and its performance monitored by a suitable system. Deviations from the expected performance can be grouped into an unintended use of the system by the user or insufficient planning throughout development and realisation phase. Depending on the systems requirements, the use phase is interrupted by [[#Activity Cycles within Individual Life Cycle Phases|activity cycles]] in order to improve life time and performance of the system.

====Case Example Utilisation Phase====
Company A has implemented the redesigned product within the system. The monitoring is based on customer feedback. Depending on the significance of the feedback the company can decide whether a third iteration and further improvement of the system is necessary. Smaller changes do not require a whole new Systems Engineering process.

=== Disposal Phase ===
The disposal phase describes the decommissioning of a system. The result of this phase is either a complete removal or a radical change of the original system. Ideally the disposal phase is considered during the development phase in order to allow a smooth removal of the system.

====Case Example Disposal Phase====
Company A continues to receives poor feedback on the redesigned product and decides to upgrade the product one more time. The development of the third generation of the system is interrelated with the disposal of the previous one, as it acts as a successor. Depending on the scale of the upgrade it could either be defined as activity cycle in order to enhance the product or as a complete new life cycle of an engineering system.

==Activity Cycles within Individual Life Cycle Phases==
Throughout its life cycle any engineering system requires frequent maintenance and updating. Activity cycles are complementary to the four regular phases of the model and target the increase of the life time/product use phase.<ref name="HBSB">Wimmer W., Züst R., 2002, ECODESIGN PILOT – Product-Investigation, Learn- ing and Optimisation-Tool for Sustainable Product Development with CD- ROM, Kluwer Academic Pubishers, Dordrecht (NL).</ref> An example hereof is the servicing or repair of a product: After a certain time in use the product is examined and weak parts exchanged, after which the product re-enters the use phase (e.g. machinery). Another example is the upgrade of a system/product in order to respond to new market developments (e.g. IT software). The activity cycles are iterative and can be repeated as often as required. Usually the activity cycles are organised in separate development and realisation phases. A spare part, for example, does require the same amount of attention like the main system, in oder to ensure that the part will fit in seamlessly. Once the part is integrated in the system, the life cycle of both system and part merge and they usually continue to co-exist throughout the use and disposal phase.

== Life Cycle Model Approaches and Reflection==
In practice, four different approaches to the Life Cycle Model exist (adapted from INCOSE)<ref name="HBTS"></ref>:
*The plan-driven method
*The incremental & Iterative development
*Lean development
*Agile development

The Life Cycle Model in a Systems Engineering perspective is a generic model with broad area of application. However, depending on the use-context it does need refinement by the user in order to achieve the best possible result. As focus areas vary in every project, so does the Life Cycle Model need adjustment of the tools and methods, which are used during the four phases of the life cycle to ensure a relevance to the issues that shall be addressed. As noted above a variety of Life Cycle Models have been developed already and every single one does differ by the targeted application. As Systems Engineering itself encompasses a huge variety of products, technical and other systems, it might be reasonable to clarify, which tools can be utilised during which phase and how they can contribute to the specific challenges.

==Variations of the Life Cycle Model==

Life Cycle Models are usually featuring similar phases as described above, but as their use-context and perspectives differ, the content of each phase might be subject to change.
*Relevant for Systems Engineering:
**The [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing.
**The Vee-model; illustrates Systems Engineering activities with a focus on concept and development phase.<ref name="HBTS"></ref>
**The Waterfall model; originally used for hardware development, was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D. (1 October 1983). "Production of Large Computer Programs". IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. doi:10.1109/MAHC.1983.10102. Retrieved 2011-03-21.</ref>
**The Spiral model; developed for software projects.<ref name="TS">Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, August 1986</ref>
**Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.<ref name="HS"></ref>
*Other applications:
**Life Cycle Model in the context of sustainability. It creates the basis for Life Cycle Sustainability Assessments and Life Cycle Management. Does include the stage of material extraction and is focussed on environment, business and social impacts of a product system.<ref name="H">UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011</ref>
**Product Life Cycle. The life cycle from a business perspective. It may include issues such as innovation diffusion, maturity of product/market or revenue over time.<ref name="HP">Klepper, S. (1996). Entry, exit, growth, and innovation over the product life cycle. AMERICAN ECONOMIC REVIEW, 86(3), 562-583.</ref>

==References==

<references/>