Waterfall model
(→Description of the model in phases) |
|||
| (19 intermediate revisions by one user not shown) | |||
| Line 1: | Line 1: | ||
'''Summary''' | '''Summary''' | ||
| + | |||
| + | The waterfall model is a linear form of project organisation. The model is generally divided into six sequential phases: requirement, analysis, design, implementation, validation, and commissioning first presented in 1970 by W.W. Royce<ref name = "Ref1"></ref>. Each of these phases corresponds to a specialisation of tasks. The particularity of this model is that each phase follows chronologically and depends directly on the results of the previous phase. | ||
| + | Although considered obsolete, this model is still widely used in the business world, for instance in software development companies<ref name = "Ref2"></ref>. The waterfall model is often chosen for its simplicity of use, its clarity and its ease of management on projects with reduced scope. However, since the first appearance of the waterfall principle in the literature<ref name = "Ref1"></ref>, this model has been criticised for its rigidity: the final result depends on the success of each of the phases and a mistake along the way can mean a complete setback for the project in progress. | ||
| + | Since the emergence of the agile project management method, many comparative studies<ref name = "Ref3">Nayan B. Ruparelia et al, Software Development Lifecycle Models, 2010</ref> have been published to demonstrate the benefits of one model over another. This article critically reviews the tool that is the waterfall model and provides insights in comparing this model with the agile methods. | ||
==The Big Idea== | ==The Big Idea== | ||
| Line 7: | Line 11: | ||
'''1- Requirements''' | '''1- Requirements''' | ||
| − | This phase corresponds to the expression of needs <ref>Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009</ref>. 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 | + | This phase corresponds to the expression of needs<ref name="Ref6">Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009</ref>. 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<ref name = "Ref2">tutorials.com, SDLC - Waterfall Model, 2021, https://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm#:~:text=The%20Waterfall%20model%20is%20the,the%20previous%20phase%20is%20complete.</ref>. |
'''2- Analysis''' | '''2- Analysis''' | ||
| − | In some models, the analysis phase is included in the requirement phase | + | In some models, the analysis phase is included in the requirement phase<ref name = "Ref2"></ref>. In this second step, the requirements are analysed and the schemas and models for the product are defined. |
'''3- Design''' | '''3- Design''' | ||
| − | From the specifications, the functions and requirements are transformed into a feasible product. The product is specified and its architecture is designed | + | From the specifications, the functions and requirements are transformed into a feasible product. The product is specified and its architecture is designed <ref name = "Ref11">javaTpoint, Waterfall model, https://www.javatpoint.com/software-engineering-waterfall-model</ref>. |
'''4- Implementation''' | '''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 | + | 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 <ref name = "Ref1">W.W. Royce, Managing the Development of Large Software Systems</ref>. |
'''5- Testing and Validation''' | '''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 | + | 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<ref name = "Ref2"></ref>. At the end of this phase, if it passes all the requirements, the product is validated. |
'''6- Release''' | '''6- Release''' | ||
| − | Once a final product is approved, its commissioning is prepared. Then the product is installed and used <ref> | + | Once a final product is approved, its commissioning is prepared. Then the product is installed and used<ref name = "Ref6"></ref>. |
| − | A final maintenance phase is added, often in software development companies | + | A final maintenance phase is added, often in software development companies<ref name = "Ref11"></ref>. 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. | 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 | + | 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<ref name = "Ref1">W.W. Royce, Managing the Development of Large Software Systems</ref>. |
| + | |||
| + | [[File:Waterfall Figure 1.png|frame|right|Figure 1: Waterfall model with Royce’s iterative feedback.<ref name = "Ref3"></ref>]] | ||
==Applications== | ==Applications== | ||
===Advantages of the model and when to use it=== | ===Advantages of the model and when to use it=== | ||
| − | The Waterfall Model, by the triviality of its features, has many advantages that explain why | + | The Waterfall Model, by the triviality of its features, has many advantages that explain why it has been and still is massively used. |
| − | it has been and still is massively used. | + | |
'''Simplicity''' | '''Simplicity''' | ||
| − | First of all, this method is quite simplistic in its architecture, which makes it easy to understand | + | First of all, this method is quite simplistic in its architecture, which makes it easy to understand<ref name = "Ref2"></ref> for the various stakeholders of a project. It is also easy to use by project managers<ref name = "Ref2"></ref>. 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 | + | resources and management knowledge to follow the model<ref name = "Ref11"></ref>. |
'''Consistency''' | '''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 | + | 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<ref name = "Ref11"></ref>. This way, the basis of the requirements is solid and can be referred to continuously during the project<ref name = "Ref1"></ref>. 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 | + | both for the smooth running of the work and for future projects<ref name = "Ref2"></ref><ref name = "Ref6"></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 | + | 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<ref name = "Ref11"></ref>. Stages and deliverables are defined in advance and it is easy to distinguish the different phases by their deadlines<ref name = "Ref2"></ref>. In this way the project is made predictable<ref name = "Ref6"></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<ref name = "Ref2"></ref>. Finally, iterations and changes |
| − | are only made between adjacent phases, which limits changes | + | are only made between adjacent phases, which limits changes<ref name = "Ref1"></ref>. |
| + | |||
'''When to use Waterfall Model ?''' | '''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 | + | |
| − | in very large projects the Waterfall Model should be chosen for its advantages | + | 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 <ref name = "Ref2"></ref><ref name = "Ref11"></ref>. 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<ref name = "Ref8">Wilfred van Casteren, The Waterfall Model and the Agile Methodologies : A comparison by project characteristics</ref>. | ||
==Limitations== | ==Limitations== | ||
| Line 64: | Line 71: | ||
'''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<ref> | + | 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 name = "Ref6"></ref>. Furthermore, the Waterfall Model will fail in projects where requirements are likely to evolve<ref name = "Ref2"></ref><ref name = "Ref11"></ref>. All subsequent phases of the project depend on this upstream requirements analysis and the requirements cannot be changed as the project progresses<ref name = "Ref1"></ref>. Generally speaking, the rigidity of the model is criticized, as Waterfall is ineffective in the face of |
| − | change<ref> | + | change<ref name = "Ref6"></ref><ref name = "Ref8"></ref>. |
'''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" | + | 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"<ref name = "Ref1"></ref> 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<ref name = "Ref11"></ref>. Furthermore, the fact that the customer is not involved in the development process leaves him with little opportunity for feedback<ref name = "Ref6"></ref>, which can have the disastrous consequence that the customer's needs are not coordinated with the final product<ref name = "Ref8"></ref>. Similarly, the way testing is conducted in the final phase makes it difficult to identify problems during development<ref name = "Ref2"></ref>. This can lead to the identification of unexpected problems in the final stages of the project<ref name = "Ref6"></ref>, "then invariably a major redesign is required" adds W.W. Royce<ref name = "Ref1"></ref>. |
| − | <ref> | + | |
'''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 | + | 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<ref name = "Ref8"></ref> and can also lead to project lengthening and time overruns<ref name = "Ref6"></ref>. Similarly, iterations and rollbacks of previous phases are costly in terms of team effort<ref name = "Ref6"></ref><ref name = "Ref11"></ref>. 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<ref name = "Ref6"></ref>. |
| − | well as an overrun of the planned dates<ref> | + | |
===Comparison Waterfall / Agile=== | ===Comparison Waterfall / Agile=== | ||
| − | Because of the defects mentioned above, the Waterfall Model was criticized very early on (1970 | + | Because of the defects mentioned above, the Waterfall Model was criticized very early on (1970<ref name = "Ref1"></ref>). 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<ref name = "Ref1"></ref>, but also of the development of the V-cycle |
and other Unified Processes (needs a link to these two methods). | and other Unified Processes (needs a link to these two methods). | ||
'''Agile methods''' | '''Agile methods''' | ||
| − | The values at the base of the agile method aim at prioritizing people and interactions | + | The values at the base of the agile method aim at prioritizing people and interactions<ref name = "Ref8"></ref>, 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<ref name = "Ref9">Ilya Bibik, How To Kill the Scrum Monster, From Waterfall to Agile</ref>. The principle is based on the iteration of |
short cycles with dynamic planning and prioritization. | short cycles with dynamic planning and prioritization. | ||
'''When to use which''' | '''When to use which''' | ||
| − | In his article The Waterfall Model and Agile Methodologies: A comparison by project characteristics | + | In his article The Waterfall Model and Agile Methodologies: A comparison by project characteristics<ref name = "Ref8"></ref>, 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: | 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" | + | Primary goals: the goals regarding Waterfall will always be "predictability, repeatability, and optimization"<ref name = "Ref8"></ref> while Agile has the essence of focusing on rapid value creation and responsiveness to change<ref name = "Ref5">Mitch Kramer, Best Practices in Systems Development Lifecycle: an analysis based on |
| − | responsiveness to change | + | the waterfall model, 2018</ref>. |
* 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. | * 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. | * 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. | ||
| Line 104: | Line 109: | ||
To go deeper into details it is suggested to look further into those three articles: | To go deeper into details it is suggested to look further into those three articles: | ||
| − | ''' | + | '''Kai Petersen et al, The Waterfall Model in Large-Scale Development, 2009<ref name = "Ref6"></ref>''' |
| − | This article | + | 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. |
| − | ''' | + | '''W.W. Royce, Managing the Development of Large Software Systems<ref name = "Ref1"></ref> ''' |
| − | 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. |
| − | ''' | + | '''Ilya Bibik, How To Kill the Scrum Monster<ref name = "Ref9"></ref>''' |
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. | 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. | ||
Latest revision as of 16:56, 18 March 2022
Summary
The waterfall model is a linear form of project organisation. The model is generally divided into six sequential phases: requirement, analysis, design, implementation, validation, and commissioning first presented in 1970 by W.W. Royce[1]. Each of these phases corresponds to a specialisation of tasks. The particularity of this model is that each phase follows chronologically and depends directly on the results of the previous phase. Although considered obsolete, this model is still widely used in the business world, for instance in software development companies[2]. The waterfall model is often chosen for its simplicity of use, its clarity and its ease of management on projects with reduced scope. However, since the first appearance of the waterfall principle in the literature[1], this model has been criticised for its rigidity: the final result depends on the success of each of the phases and a mistake along the way can mean a complete setback for the project in progress. Since the emergence of the agile project management method, many comparative studies[3] have been published to demonstrate the benefits of one model over another. This article critically reviews the tool that is the waterfall model and provides insights in comparing this model with the agile methods.
Contents |
[edit] The Big Idea
[edit] 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[4]. 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 [5].
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[4].
A final maintenance phase is added, often in software development companies[5]. 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].
[edit] Applications
[edit] 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[5].
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[5]. 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][4].
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[5]. 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][5]. 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[6].
[edit] Limitations
[edit] 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[4]. Furthermore, the Waterfall Model will fail in projects where requirements are likely to evolve[2][5]. 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[4][6].
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[5]. Furthermore, the fact that the customer is not involved in the development process leaves him with little opportunity for feedback[4], which can have the disastrous consequence that the customer's needs are not coordinated with the final product[6]. 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[4], "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[6] and can also lead to project lengthening and time overruns[4]. Similarly, iterations and rollbacks of previous phases are costly in terms of team effort[4][5]. 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[4].
[edit] 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[6], 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[7]. 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[6], 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"[6] while Agile has the essence of focusing on rapid value creation and responsiveness to change[8].
- 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.
[edit] 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.
[edit] Annotated bibliography
To go deeper into details it is suggested to look further into those three articles:
Kai Petersen et al, The Waterfall Model in Large-Scale Development, 2009[4]
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.
W.W. Royce, Managing the Development of Large Software Systems[1]
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.
Ilya Bibik, How To Kill the Scrum Monster[7]
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.
[edit] References
- ↑ 1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 1.10 1.11 W.W. Royce, Managing the Development of Large Software Systems
- ↑ 2.00 2.01 2.02 2.03 2.04 2.05 2.06 2.07 2.08 2.09 2.10 2.11 tutorials.com, SDLC - Waterfall Model, 2021, https://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm#:~:text=The%20Waterfall%20model%20is%20the,the%20previous%20phase%20is%20complete.
- ↑ 3.0 3.1 Nayan B. Ruparelia et al, Software Development Lifecycle Models, 2010
- ↑ 4.00 4.01 4.02 4.03 4.04 4.05 4.06 4.07 4.08 4.09 4.10 4.11 Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009
- ↑ 5.0 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 javaTpoint, Waterfall model, https://www.javatpoint.com/software-engineering-waterfall-model
- ↑ 6.0 6.1 6.2 6.3 6.4 6.5 6.6 Wilfred van Casteren, The Waterfall Model and the Agile Methodologies : A comparison by project characteristics
- ↑ 7.0 7.1 Ilya Bibik, How To Kill the Scrum Monster, From Waterfall to Agile
- ↑ Mitch Kramer, Best Practices in Systems Development Lifecycle: an analysis based on the waterfall model, 2018
