Waterfall model
(→Description of the model in phases) |
|||
| Line 27: | Line 27: | ||
'''6- Release''' | '''6- Release''' | ||
| − | Once a final product is approved, its commissioning is prepared. Then the product is installed and used | + | Once a final product is approved, its commissioning is prepared. Then the product is installed and used <ref>Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009</ref>. |
A final maintenance phase is added, often in software development companies [11]. This seventh phase corresponds to the work of the company to make sure that the product works as expected once implemented and to intervene in the opposite case to solve problems that may arise. | A final maintenance phase is added, often in software development companies [11]. This seventh phase corresponds to the work of the company to make sure that the product works as expected once implemented and to intervene in the opposite case to solve problems that may arise. | ||
| Line 47: | Line 47: | ||
In this model, the requirements analysis is rigorous and detailed. The requirements are deepened in the early stages of the project and are set in such a way that they are not modified once the requirements phase is closed [11]. This way, the basis of the requirements is solid and can be referred to continuously during the project [1]. In addition, the Waterfall Model implies the production of detailed project documentation that traces all the stages and architecture of the project and its development. This documentation is used | In this model, the requirements analysis is rigorous and detailed. The requirements are deepened in the early stages of the project and are set in such a way that they are not modified once the requirements phase is closed [11]. This way, the basis of the requirements is solid and can be referred to continuously during the project [1]. In addition, the Waterfall Model implies the production of detailed project documentation that traces all the stages and architecture of the project and its development. This documentation is used | ||
| − | both for the smooth running of the work and for future projects [2] | + | both for the smooth running of the work and for future projects [2]<ref>Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009</ref>. |
'''Control''' | '''Control''' | ||
| − | Finally, a project following a Waterfall Model will be easy to control for both the client and the project management team. The client can control the progress of the project through the numerous reports and the comprehensive project documentation [11]. Stages and deliverables are defined in advance and it is easy to distinguish the different phases by their deadlines [2]. In this way the project is made predictable | + | Finally, a project following a Waterfall Model will be easy to control for both the client and the project management team. The client can control the progress of the project through the numerous reports and the comprehensive project documentation [11]. Stages and deliverables are defined in advance and it is easy to distinguish the different phases by their deadlines [2]. In this way the project is made predictable<ref>Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009</ref>. Furthermore the structure of the Waterfall Model is such that it is possible to determine the final cost of the product and to give a date of commissioning before starting the development which is a real advantage for the customer. Moreover, the management of a project following this model is facilitated: the fact that the phases are carried out one at a time and successively allows for departmentalization between these phases [2]. Finally, iterations and changes |
are only made between adjacent phases, which limits changes [1]. | are only made between adjacent phases, which limits changes [1]. | ||
'''When to use Waterfall Model ?''' | '''When to use Waterfall Model ?''' | ||
| Line 64: | Line 64: | ||
'''Fixity of requirements''' | '''Fixity of requirements''' | ||
| − | One of the key principles of the model is the detailed and fixed definition of requirements from the very first phase of the process. The complete and detailed definition of requirements in the first phase implies that the teams involved in the project cannot work on the development steps until the requirement phase has been concluded | + | One of the key principles of the model is the detailed and fixed definition of requirements from the very first phase of the process. The complete and detailed definition of requirements in the first phase implies that the teams involved in the project cannot work on the development steps until the requirement phase has been concluded<ref>Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009</ref>. Furthermore, the Waterfall Model will fail in projects where requirements are likely to evolve [2][11]. All subsequent phases of the project depend on this upstream requirements analysis and the requirements cannot be changed as the project progresses [1]. Generally speaking, the rigidity of the model is criticized, as Waterfall is ineffective in the face of |
| − | change | + | change<ref>Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009</ref>[8]. |
'''A high risk model''' | '''A high risk model''' | ||
| − | The Waterfall Model is very bad at reducing project risk. W.W. Royce said in it's 1970's article that the model "is risky and invites failure" [1] and the How to Kill the Scrum Monster guide shows that projects using Waterfall model had a failure rate of 29% (the numbers were sourced from The Standish Group 2015 Chaos Report). This high risk rate is explained by the difficulty of identifying risks at the beginning of the project, which also makes it difficult to develop an effective risk reduction strategy [11]. Furthermore, the fact that the customer is not involved in the development process leaves him with little opportunity for feedback | + | The Waterfall Model is very bad at reducing project risk. W.W. Royce said in it's 1970's article that the model "is risky and invites failure" [1] and the How to Kill the Scrum Monster guide shows that projects using Waterfall model had a failure rate of 29% (the numbers were sourced from The Standish Group 2015 Chaos Report). This high risk rate is explained by the difficulty of identifying risks at the beginning of the project, which also makes it difficult to develop an effective risk reduction strategy [11]. Furthermore, the fact that the customer is not involved in the development process leaves him with little opportunity for feedback<ref>Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009</ref>, which can have the disastrous consequence that the customer's needs are not coordinated with the final product [8]. Similarly, the way testing is conducted in the final phase makes it difficult to identify problems during development [2]. This can lead to the identification of unexpected problems in the final stages of the project |
| − | + | <ref>Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009</ref>, "then invariably a major redesign is required" adds W.W. Royce [1]. | |
'''High costs and efforts''' | '''High costs and efforts''' | ||
| − | Finally, the Waterfall Model is likely to cause various problems that increase the cost and effort of a project. The detailed documentation to be written and approved for each step as well as the step approval procedures are criticized as being effortful [8] and can also lead to project lengthening and time overruns | + | Finally, the Waterfall Model is likely to cause various problems that increase the cost and effort of a project. The detailed documentation to be written and approved for each step as well as the step approval procedures are criticized as being effortful [8] and can also lead to project lengthening and time overruns <ref>Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009</ref>. Similarly, iterations and rollbacks of previous phases are costly in terms of team effort<ref>Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009</ref>[11]. Finally, in the case of major substantive problems encountered in the final phase, additional costs are obviously to be expected, as |
| − | well as an overrun of the planned dates | + | well as an overrun of the planned dates<ref>Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009</ref>. |
===Comparison Waterfall / Agile=== | ===Comparison Waterfall / Agile=== | ||
| Line 108: | Line 108: | ||
This article is a detailed development of the ideas and advice of Dr. W.W. Royce, an American computer scientist, about the Waterfall Model. This pioneer of software development wrote a critical article in 1970 about such a model, proposing modifications to improve this working method in the case of software development. A detailed solution of some problems inspired by Dr. Royce's experience can be found in this article. | This article is a detailed development of the ideas and advice of Dr. W.W. Royce, an American computer scientist, about the Waterfall Model. This pioneer of software development wrote a critical article in 1970 about such a model, proposing modifications to improve this working method in the case of software development. A detailed solution of some problems inspired by Dr. Royce's experience can be found in this article. | ||
| − | ''' | + | '''Kai Petersen et al, The Waterfall Model in Large-Scale Development, 2009<ref>Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009</ref>''' |
This article stems from the observation that although the Waterfall Model is widely criticized by the scientific community, it is still used in many cases. The authors then question the impact of the model's disadvantages on a project. They gather the criticisms made of the model in the literature, then test the model in a defined example of a company to analyze whether the defects are observable. In conclusion, they did find significant negative impacts of the model. | This article stems from the observation that although the Waterfall Model is widely criticized by the scientific community, it is still used in many cases. The authors then question the impact of the model's disadvantages on a project. They gather the criticisms made of the model in the literature, then test the model in a defined example of a company to analyze whether the defects are observable. In conclusion, they did find significant negative impacts of the model. | ||
Revision as of 16:20, 18 March 2022
Summary
Contents |
The Big Idea
Description of the model in phases
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:
1- Requirements
This phase corresponds to the expression of needs [1]. First of all, the customer's requirements for the product are documented: the functions and the expected performances. The customer and the project team work together to establish a Requirement Specification Document [2].
2- Analysis
In some models, the analysis phase is included in the requirement phase [2]. In this second step, the requirements are analysed and the schemas and models for the product are defined.
3- Design
From the specifications, the functions and requirements are transformed into a feasible product. The product is specified and its architecture is designed [11].
4- Implementation
This step is the passage in a concrete phase of realisation of the product. While the first three phases are more about planning and mock-up, during this one, a first version of the product is developed [1].
5- Testing and Validation
The completed product undergoes a series of tests to compare it with the specifications and verify that it meets the requirements. During this phase, we identify the defects of the product. The quality of the final product depends largely on the efficiency of the testing phase [2]. At the end of this phase, if it passes all the requirements, the product is validated.
6- Release
Once a final product is approved, its commissioning is prepared. Then the product is installed and used [2].
A final maintenance phase is added, often in software development companies [11]. This seventh phase corresponds to the work of the company to make sure that the product works as expected once implemented and to intervene in the opposite case to solve problems that may arise. Like a waterfall, the different phases of this model follow each other consecutively and chronologically. One cannot move on to a new step without having validated the previous one and each step must be accompanied by solid documentation. The first person to theorise this model was W.W. Royce in 1970. In his article: Imagining the development of large software system, he represents graphically the phases of the model without using the name waterfall. In his article, Royce already criticises this model at the time [1].
Applications
Advantages of the model and when to use it
The Waterfall Model, by the triviality of its features, has many advantages that explain why it has been and still is massively used.
Simplicity
First of all, this method is quite simplistic in its architecture, which makes it easy to understand [2] for the various stakeholders of a project. It is also easy to use by project managers [2]. The management and implementation of a Waterfall Model as a project structure presents little challenge: the structure is clear and explicit and requires few resources and management knowledge to follow the model [11].
Consistency
In this model, the requirements analysis is rigorous and detailed. The requirements are deepened in the early stages of the project and are set in such a way that they are not modified once the requirements phase is closed [11]. This way, the basis of the requirements is solid and can be referred to continuously during the project [1]. In addition, the Waterfall Model implies the production of detailed project documentation that traces all the stages and architecture of the project and its development. This documentation is used both for the smooth running of the work and for future projects [2][3].
Control
Finally, a project following a Waterfall Model will be easy to control for both the client and the project management team. The client can control the progress of the project through the numerous reports and the comprehensive project documentation [11]. Stages and deliverables are defined in advance and it is easy to distinguish the different phases by their deadlines [2]. In this way the project is made predictable[4]. Furthermore the structure of the Waterfall Model is such that it is possible to determine the final cost of the product and to give a date of commissioning before starting the development which is a real advantage for the customer. Moreover, the management of a project following this model is facilitated: the fact that the phases are carried out one at a time and successively allows for departmentalization between these phases [2]. Finally, iterations and changes are only made between adjacent phases, which limits changes [1]. When to use Waterfall Model ? Due to its characteristics and advantages, it is preferable to use a Waterfall Model under certain conditions. In Software Development Lifecycle (SDLC), the Waterfall Model is often suggested for small projects with little development [2] [11]. N. B. Ruparelia adds that the Waterfall Model is the most efficient for software development "that provides back-end functionality". However, W. van Casteren defends more generally (outside the SDLC) that in very large projects the Waterfall Model should be chosen for its advantages [8].
Limitations
Problems encountered with the Model
The principles governing the Waterfall Model bring certain advantages such as simplicity, consistency and control, but these same added values of the model can be the source of fundamental problems widely criticized.
Fixity of requirements
One of the key principles of the model is the detailed and fixed definition of requirements from the very first phase of the process. The complete and detailed definition of requirements in the first phase implies that the teams involved in the project cannot work on the development steps until the requirement phase has been concluded[5]. Furthermore, the Waterfall Model will fail in projects where requirements are likely to evolve [2][11]. All subsequent phases of the project depend on this upstream requirements analysis and the requirements cannot be changed as the project progresses [1]. Generally speaking, the rigidity of the model is criticized, as Waterfall is ineffective in the face of change[6][8].
A high risk model
The Waterfall Model is very bad at reducing project risk. W.W. Royce said in it's 1970's article that the model "is risky and invites failure" [1] and the How to Kill the Scrum Monster guide shows that projects using Waterfall model had a failure rate of 29% (the numbers were sourced from The Standish Group 2015 Chaos Report). This high risk rate is explained by the difficulty of identifying risks at the beginning of the project, which also makes it difficult to develop an effective risk reduction strategy [11]. Furthermore, the fact that the customer is not involved in the development process leaves him with little opportunity for feedback[7], which can have the disastrous consequence that the customer's needs are not coordinated with the final product [8]. Similarly, the way testing is conducted in the final phase makes it difficult to identify problems during development [2]. This can lead to the identification of unexpected problems in the final stages of the project [8], "then invariably a major redesign is required" adds W.W. Royce [1].
High costs and efforts
Finally, the Waterfall Model is likely to cause various problems that increase the cost and effort of a project. The detailed documentation to be written and approved for each step as well as the step approval procedures are criticized as being effortful [8] and can also lead to project lengthening and time overruns [9]. Similarly, iterations and rollbacks of previous phases are costly in terms of team effort[10][11]. Finally, in the case of major substantive problems encountered in the final phase, additional costs are obviously to be expected, as well as an overrun of the planned dates[11].
Comparison Waterfall / Agile
Because of the defects mentioned above, the Waterfall Model was criticized very early on (1970 [1]). In order to get rid of the model's defects, some people tried to modify or evolve it. This is the case of the W.W. Royce model [1], but also of the development of the V-cycle and other Unified Processes (needs a link to these two methods).
Agile methods
The values at the base of the agile method aim at prioritizing people and interactions [8], a functional product, collaboration with the customer and reactivity to change. This may be at the expense of processes, intelligible and detailed documentation, contract negotiation and a clear plan to follow from start to finish [9]. The principle is based on the iteration of short cycles with dynamic planning and prioritization.
When to use which
In his article The Waterfall Model and Agile Methodologies: A comparison by project characteristics [8], W. van Casteren gives the characteristics of the two methods to determine whether a project is better suited to an agile or waterfall method. The following points are taken directly from his article and are the most important points to determine whether a project should be structured according to a Waterfall Model or agile: Primary goals: the goals regarding Waterfall will always be "predictability, repeatability, and optimization"[8] while Agile has the essence of focusing on rapid value creation and responsiveness to change[5].
- Customer: Agile adapts to cases where the customer is deeply involved in the development, which can be associated and knowledgeable, while the Waterfall Model requires adequately skilled customers.
- Requirements : The formal expression of requirements independently of the solution is left to the Waterfall, the Agile is more prepared to the requirements that evolve quickly and change.
- Culture: Generally speaking, the Waterfall Model will better adapt to a company cultivating values of order and rigor while Agile methods thrive on chaos.
Conclusion
Finally, although considered obsolete by some and even risky in the course of certain projects, the Waterfall Model continues to be used in cases where it is necessary to provide detailed documentation of the development stages of a product. When it is necessary to be rigorous and well defined, the Waterfall Model or its evolutions can be useful. However, it can present flaws and big risks, especially in terms of loss of time and money, due to the rigidity of the model and the lack of communication between its stages. One of the solutions provided in opposition to this model is the agile method. However, you must be careful to be in a framework that is conducive to its use.
Annotated bibliography
To go deeper into details it is suggested to look further into those three articles:
[1] W.W. Royce, Managing the Development of Large Software Systems
This article is a detailed development of the ideas and advice of Dr. W.W. Royce, an American computer scientist, about the Waterfall Model. This pioneer of software development wrote a critical article in 1970 about such a model, proposing modifications to improve this working method in the case of software development. A detailed solution of some problems inspired by Dr. Royce's experience can be found in this article.
Kai Petersen et al, The Waterfall Model in Large-Scale Development, 2009[12]
This article stems from the observation that although the Waterfall Model is widely criticized by the scientific community, it is still used in many cases. The authors then question the impact of the model's disadvantages on a project. They gather the criticisms made of the model in the literature, then test the model in a defined example of a company to analyze whether the defects are observable. In conclusion, they did find significant negative impacts of the model.
[9] Ilya Bibik, How To Kill the Scrum Monster
This guide is mainly focused on the Agile Scrum method and what lies behind the development of agile methods over the past decades. The author explains how to use these tools properly according to him and the mistakes associated with Agile. The chapter used for this article is 'From Waterfall to Agile' but the publication also gives many interesting details about agile management.
References
- ↑ Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009
- ↑ Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009
- ↑ Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009
- ↑ Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009
- ↑ Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009
- ↑ Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009
- ↑ Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009
- ↑ Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009
- ↑ Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009
- ↑ Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009
- ↑ Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009
- ↑ Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009
