Life Cycle Model
| (62 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | The | + | ''*Disclaimer: The articles are created by DTU students. As part of the course, students are introduced to knowledge related to IP rights, plagiarism and copyright infringement. Additionally, the articles are a product of critical engagement of students with the literature review, and their aim is to contribute to the Project Management holistic field of science. If you discover any potential copyright infringement on the site, please inform thereof by sending an email to ophavsret@dtu.dk.'' |
| − | + | ''Developed by Philippe Maurice Stotz'' | |
| − | |||
| − | 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 == | == The Life Cycle Phases == | ||
[[File:Life Cycle Phases.jpg|400px|thumb|alt=Puzzle globe|Figure 1: Life cycle phases and decision gates]] | [[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 | + | 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 | + | ::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. | 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 | + | 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 === | === Development Phase === | ||
[[File:Development phase wiki.jpg|400px|thumb|alt=Puzzle globe|Figure 2: Influence vs knowledge of engineering system]] | [[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 | + | 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 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 ==== | ==== 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 | + | 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 | + | 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 === | === Realisation Phase === | ||
| Line 39: | Line 40: | ||
====Case Example Realisation Phase==== | ====Case Example Realisation Phase==== | ||
| − | Company A has developed a concrete concept to deal with its unsatisfied | + | 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 === | === Utilisation Phase === | ||
| Line 45: | Line 46: | ||
====Case Example Utilisation Phase==== | ====Case Example Utilisation Phase==== | ||
| − | Company A has implemented the redesigned product | + | 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 === | === Disposal Phase === | ||
| Line 51: | Line 52: | ||
====Case Example Disposal Phase==== | ====Case Example Disposal Phase==== | ||
| − | Company A continues to | + | 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== | ==Activity Cycles within Individual Life Cycle Phases== | ||
| − | Throughout its life cycle any | + | 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. | + | 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== | ==Variations of the Life Cycle Model== | ||
| − | Life Cycle Models are usually featuring similar phases as described above, but as their use- | + | 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. | |
| − | Relevant for Systems Engineering: | + | **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 [[Agile Project Management]] model; structures the life of a project in the five stages of envisioning, speculation, exploration, adaptation and closing. | + | **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 Vee-model; illustrates Systems Engineering activities with | + | **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> |
| − | *The Waterfall model; originally used for hardware development was adapted to the creation of software.<ref name="HBXS">Benington, Herbert D | + | **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> |
| − | *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, | + | *Other applications: |
| − | *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> | + | **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> |
| − | Other applications: | + | **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> |
| − | *Life Cycle Model in the context of sustainability | + | |
| − | *Product Life Cycle | + | |
==References== | ==References== | ||
<references/> | <references/> | ||
| + | |||
| + | [[Category:Project Management]][[Category:Life cycle]] | ||
Latest revision as of 10:26, 17 May 2019
*Disclaimer: The articles are created by DTU students. As part of the course, students are introduced to knowledge related to IP rights, plagiarism and copyright infringement. Additionally, the articles are a product of critical engagement of students with the literature review, and their aim is to contribute to the Project Management holistic field of science. If you discover any potential copyright infringement on the site, please inform thereof by sending an email to ophavsret@dtu.dk.
Developed by Philippe Maurice Stotz
The Life Cycle Model is one of two methodical concepts that build the basis for 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. This article is primarily based on the work of Rainer Züst and Peter Troxler[1], 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.
Contents |
[edit] 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.[2]
The origin of the Life Cycle Model can not be clearly attributed to a single author.[3] A range of similar models have been presented by the guide Project Management Book of Knowledge[4] and the Project Management Handbook.[5] Life Cycle Models in Systems Engineering context have been described in the INCOSE Systems Engineering Handbook[2] and the publication Systems Engineering Practice.[6]
[edit] The Life Cycle Phases
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[2], whereas Züst et al.[1] 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.[7]
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.[2]
[edit] Development Phase
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.[8] 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.
[edit] 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.
[edit] 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.
[edit] 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.
[edit] 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 in order to improve life time and performance of the system.
[edit] 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.
[edit] 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.
[edit] 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.
[edit] 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.[9] 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.
[edit] 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)[2]:
- 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.
[edit] 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.[2]
- The Waterfall model; originally used for hardware development, was adapted to the creation of software.[6]
- The Spiral model; developed for software projects.[10]
- Bonnal, Gourc & Lacoste (2002) define five project management related Life Cycle Models with differing focus: Strait forward, fractal, risk, quality or control oriented.[3]
- 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.[11]
- 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.[12]
[edit] References
- ↑ 1.0 1.1 Züst, Rainer, and Peter Troxler. “No More Muddling Through: Mastering Complex Projects In Engineering and Management”. Web. 2006
- ↑ 2.0 2.1 2.2 2.3 2.4 2.5 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.
- ↑ 3.0 3.1 Bonnal, Pierre, Didier Gourc, and Germain Lacoste. “The Life Cycle of Technical Projects”. Project Management Journal. 2002.
- ↑ Project Management Institute. A Guide To the Project Management Body of Knowledge: PMBOK Guide. 2004.
- ↑ King, W. R. and Cleland, D. I. Project Management Handbook, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA. 1997.
- ↑ 6.0 6.1 R.I. Faulconbridge and M.J. Ryan, “Systems Engineering Practice”, Argos Press, Canberra, 2014
- ↑ ISO/IEC 15288. 2008
- ↑ Haberfellner R. et al. Systems Engineering. Daenzer, W. et al. (Publisher). 11. Auflage, Verlag Industrielle Organisation, Zürich. 2002
- ↑ Wimmer W., Züst R. Ecodesign Pilot – Product-Investigation, Learning and Optimisation-Tool for Sustainable Product Development, Kluwer Academic Pubishers, Dordrecht (NL). 2002 .
- ↑ Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, ACM, 11(4):14-24, 1986
- ↑ UNEP-SETAC. Towards Life Cycle Sustainability Assessment. 2011
- ↑ Klepper, S. Entry, exit, growth, and innovation over the product life cycle. American Economic Review, 86(3), 562-583. 1996.
