http://13.50.150.85/api.php?action=feedcontributions&feedformat=atom&user=S212522DTU ProjectLab - User contributions [en-gb]2026-07-15T09:36:12ZUser contributionsMediaWiki 1.43.3http://13.50.150.85/index.php?title=File:Waterfall_Figure_1.png&diff=116361File:Waterfall Figure 1.png2022-03-18T15:57:47Z<p>S212522: S212522 uploaded a new version of &quot;File:Waterfall Figure 1.png&quot;</p>
<hr />
<div>Waterfall model with Royce’s iterative feedback</div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116359Waterfall model2022-03-18T15:56:25Z<p>S212522: /* Description of the model in phases */</p>
<hr />
<div>'''Summary'''<br />
<br />
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.<br />
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.<br />
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.<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
<br />
'''1- Requirements'''<br />
<br />
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>.<br />
<br />
'''2- Analysis'''<br />
<br />
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.<br />
<br />
'''3- Design'''<br />
<br />
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>.<br />
<br />
'''4- Implementation'''<br />
<br />
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>.<br />
<br />
'''5- Testing and Validation'''<br />
<br />
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.<br />
<br />
'''6- Release'''<br />
<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used<ref name = "Ref6"></ref>.<br />
<br />
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.<br />
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.<br />
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>.<br />
<br />
[[File:Waterfall Figure 1.png|frame|right|Figure 1: Waterfall model with Royce’s iterative feedback.<ref name = "Ref3"></ref>]]<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why it has been and still is massively used.<br />
<br />
'''Simplicity'''<br />
<br />
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<br />
resources and management knowledge to follow the model<ref name = "Ref11"></ref>.<br />
<br />
'''Consistency'''<br />
<br />
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<br />
both for the smooth running of the work and for future projects<ref name = "Ref2"></ref><ref name = "Ref6"></ref>.<br />
<br />
'''Control'''<br />
<br />
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<br />
are only made between adjacent phases, which limits changes<ref name = "Ref1"></ref>.<br />
<br />
'''When to use Waterfall Model ?'''<br />
<br />
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<br />
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>.<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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<br />
change<ref name = "Ref6"></ref><ref name = "Ref8"></ref>.<br />
<br />
'''A high risk model'''<br />
<br />
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>.<br />
<br />
'''High costs and efforts'''<br />
<br />
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>.<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
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<br />
and other Unified Processes (needs a link to these two methods).<br />
<br />
'''Agile methods'''<br />
<br />
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<br />
short cycles with dynamic planning and prioritization.<br />
<br />
'''When to use which'''<br />
<br />
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<br />
whether a project should be structured according to a Waterfall Model or agile:<br />
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<br />
the waterfall model, 2018</ref>.<br />
* 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.<br />
* 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.<br />
* Culture: Generally speaking, the Waterfall Model will better adapt to a company cultivating values of order and rigor while Agile methods thrive on chaos.<br />
<br />
==Conclusion==<br />
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.<br />
<br />
==Annotated bibliography==<br />
<br />
To go deeper into details it is suggested to look further into those three articles:<br />
<br />
'''Kai Petersen et al, The Waterfall Model in Large-Scale Development, 2009<ref name = "Ref6"></ref>'''<br />
<br />
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.<br />
<br />
'''W.W. Royce, Managing the Development of Large Software Systems<ref name = "Ref1"></ref> '''<br />
<br />
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.<br />
<br />
'''Ilya Bibik, How To Kill the Scrum Monster<ref name = "Ref9"></ref>'''<br />
<br />
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.<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116358Waterfall model2022-03-18T15:55:53Z<p>S212522: /* Description of the model in phases */</p>
<hr />
<div>'''Summary'''<br />
<br />
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.<br />
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.<br />
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.<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
<br />
'''1- Requirements'''<br />
<br />
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>.<br />
<br />
'''2- Analysis'''<br />
<br />
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.<br />
<br />
'''3- Design'''<br />
<br />
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>.<br />
<br />
'''4- Implementation'''<br />
<br />
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>.<br />
<br />
'''5- Testing and Validation'''<br />
<br />
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.<br />
<br />
'''6- Release'''<br />
<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used<ref name = "Ref6"></ref>.<br />
<br />
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.<br />
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.<br />
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>.<br />
<br />
[[File:Waterfall Figure 1.png|border|right|middle|upright = 0.01|Figure 1: Waterfall model with Royce’s iterative feedback.<ref name = "Ref3"></ref>]]<br />
<br />
[[File:Waterfall Figure 1.png|frame|right|Figure 1: Waterfall model with Royce’s iterative feedback.<ref name = "Ref3"></ref>]]<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why it has been and still is massively used.<br />
<br />
'''Simplicity'''<br />
<br />
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<br />
resources and management knowledge to follow the model<ref name = "Ref11"></ref>.<br />
<br />
'''Consistency'''<br />
<br />
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<br />
both for the smooth running of the work and for future projects<ref name = "Ref2"></ref><ref name = "Ref6"></ref>.<br />
<br />
'''Control'''<br />
<br />
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<br />
are only made between adjacent phases, which limits changes<ref name = "Ref1"></ref>.<br />
<br />
'''When to use Waterfall Model ?'''<br />
<br />
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<br />
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>.<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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<br />
change<ref name = "Ref6"></ref><ref name = "Ref8"></ref>.<br />
<br />
'''A high risk model'''<br />
<br />
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>.<br />
<br />
'''High costs and efforts'''<br />
<br />
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>.<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
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<br />
and other Unified Processes (needs a link to these two methods).<br />
<br />
'''Agile methods'''<br />
<br />
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<br />
short cycles with dynamic planning and prioritization.<br />
<br />
'''When to use which'''<br />
<br />
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<br />
whether a project should be structured according to a Waterfall Model or agile:<br />
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<br />
the waterfall model, 2018</ref>.<br />
* 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.<br />
* 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.<br />
* Culture: Generally speaking, the Waterfall Model will better adapt to a company cultivating values of order and rigor while Agile methods thrive on chaos.<br />
<br />
==Conclusion==<br />
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.<br />
<br />
==Annotated bibliography==<br />
<br />
To go deeper into details it is suggested to look further into those three articles:<br />
<br />
'''Kai Petersen et al, The Waterfall Model in Large-Scale Development, 2009<ref name = "Ref6"></ref>'''<br />
<br />
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.<br />
<br />
'''W.W. Royce, Managing the Development of Large Software Systems<ref name = "Ref1"></ref> '''<br />
<br />
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.<br />
<br />
'''Ilya Bibik, How To Kill the Scrum Monster<ref name = "Ref9"></ref>'''<br />
<br />
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.<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116356Waterfall model2022-03-18T15:55:12Z<p>S212522: /* Description of the model in phases */</p>
<hr />
<div>'''Summary'''<br />
<br />
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.<br />
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.<br />
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.<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
<br />
'''1- Requirements'''<br />
<br />
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>.<br />
<br />
'''2- Analysis'''<br />
<br />
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.<br />
<br />
'''3- Design'''<br />
<br />
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>.<br />
<br />
'''4- Implementation'''<br />
<br />
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>.<br />
<br />
'''5- Testing and Validation'''<br />
<br />
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.<br />
<br />
'''6- Release'''<br />
<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used<ref name = "Ref6"></ref>.<br />
<br />
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.<br />
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.<br />
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>.<br />
<br />
[[File:Waterfall Figure 1.png|border|right|middle|upright = 0.01|Figure 1: Waterfall model with Royce’s iterative feedback.<ref name = "Ref3"></ref>]]<br />
<br />
[[File:Waterfall Figure 1.png|border|right|middle|upright|Figure 1: Waterfall model with Royce’s iterative feedback.<ref name = "Ref3"></ref>]]<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why it has been and still is massively used.<br />
<br />
'''Simplicity'''<br />
<br />
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<br />
resources and management knowledge to follow the model<ref name = "Ref11"></ref>.<br />
<br />
'''Consistency'''<br />
<br />
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<br />
both for the smooth running of the work and for future projects<ref name = "Ref2"></ref><ref name = "Ref6"></ref>.<br />
<br />
'''Control'''<br />
<br />
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<br />
are only made between adjacent phases, which limits changes<ref name = "Ref1"></ref>.<br />
<br />
'''When to use Waterfall Model ?'''<br />
<br />
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<br />
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>.<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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<br />
change<ref name = "Ref6"></ref><ref name = "Ref8"></ref>.<br />
<br />
'''A high risk model'''<br />
<br />
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>.<br />
<br />
'''High costs and efforts'''<br />
<br />
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>.<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
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<br />
and other Unified Processes (needs a link to these two methods).<br />
<br />
'''Agile methods'''<br />
<br />
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<br />
short cycles with dynamic planning and prioritization.<br />
<br />
'''When to use which'''<br />
<br />
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<br />
whether a project should be structured according to a Waterfall Model or agile:<br />
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<br />
the waterfall model, 2018</ref>.<br />
* 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.<br />
* 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.<br />
* Culture: Generally speaking, the Waterfall Model will better adapt to a company cultivating values of order and rigor while Agile methods thrive on chaos.<br />
<br />
==Conclusion==<br />
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.<br />
<br />
==Annotated bibliography==<br />
<br />
To go deeper into details it is suggested to look further into those three articles:<br />
<br />
'''Kai Petersen et al, The Waterfall Model in Large-Scale Development, 2009<ref name = "Ref6"></ref>'''<br />
<br />
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.<br />
<br />
'''W.W. Royce, Managing the Development of Large Software Systems<ref name = "Ref1"></ref> '''<br />
<br />
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.<br />
<br />
'''Ilya Bibik, How To Kill the Scrum Monster<ref name = "Ref9"></ref>'''<br />
<br />
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.<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116351Waterfall model2022-03-18T15:49:48Z<p>S212522: /* Description of the model in phases */</p>
<hr />
<div>'''Summary'''<br />
<br />
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.<br />
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.<br />
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.<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
<br />
'''1- Requirements'''<br />
<br />
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>.<br />
<br />
'''2- Analysis'''<br />
<br />
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.<br />
<br />
'''3- Design'''<br />
<br />
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>.<br />
<br />
'''4- Implementation'''<br />
<br />
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>.<br />
<br />
'''5- Testing and Validation'''<br />
<br />
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.<br />
<br />
'''6- Release'''<br />
<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used<ref name = "Ref6"></ref>.<br />
<br />
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.<br />
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.<br />
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>.<br />
<br />
[[File:Waterfall Figure 1.png|border|right|middle|upright = 0.01|Figure 1: Waterfall model with Royce’s iterative feedback.<ref name = "Ref3"></ref>]]<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why it has been and still is massively used.<br />
<br />
'''Simplicity'''<br />
<br />
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<br />
resources and management knowledge to follow the model<ref name = "Ref11"></ref>.<br />
<br />
'''Consistency'''<br />
<br />
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<br />
both for the smooth running of the work and for future projects<ref name = "Ref2"></ref><ref name = "Ref6"></ref>.<br />
<br />
'''Control'''<br />
<br />
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<br />
are only made between adjacent phases, which limits changes<ref name = "Ref1"></ref>.<br />
<br />
'''When to use Waterfall Model ?'''<br />
<br />
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<br />
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>.<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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<br />
change<ref name = "Ref6"></ref><ref name = "Ref8"></ref>.<br />
<br />
'''A high risk model'''<br />
<br />
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>.<br />
<br />
'''High costs and efforts'''<br />
<br />
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>.<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
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<br />
and other Unified Processes (needs a link to these two methods).<br />
<br />
'''Agile methods'''<br />
<br />
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<br />
short cycles with dynamic planning and prioritization.<br />
<br />
'''When to use which'''<br />
<br />
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<br />
whether a project should be structured according to a Waterfall Model or agile:<br />
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<br />
the waterfall model, 2018</ref>.<br />
* 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.<br />
* 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.<br />
* Culture: Generally speaking, the Waterfall Model will better adapt to a company cultivating values of order and rigor while Agile methods thrive on chaos.<br />
<br />
==Conclusion==<br />
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.<br />
<br />
==Annotated bibliography==<br />
<br />
To go deeper into details it is suggested to look further into those three articles:<br />
<br />
'''Kai Petersen et al, The Waterfall Model in Large-Scale Development, 2009<ref name = "Ref6"></ref>'''<br />
<br />
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.<br />
<br />
'''W.W. Royce, Managing the Development of Large Software Systems<ref name = "Ref1"></ref> '''<br />
<br />
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.<br />
<br />
'''Ilya Bibik, How To Kill the Scrum Monster<ref name = "Ref9"></ref>'''<br />
<br />
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.<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116343Waterfall model2022-03-18T15:45:36Z<p>S212522: /* Description of the model in phases */</p>
<hr />
<div>'''Summary'''<br />
<br />
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.<br />
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.<br />
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.<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
<br />
'''1- Requirements'''<br />
<br />
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>.<br />
<br />
'''2- Analysis'''<br />
<br />
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.<br />
<br />
'''3- Design'''<br />
<br />
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>.<br />
<br />
'''4- Implementation'''<br />
<br />
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>.<br />
<br />
'''5- Testing and Validation'''<br />
<br />
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.<br />
<br />
'''6- Release'''<br />
<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used<ref name = "Ref6"></ref>.<br />
<br />
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.<br />
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.<br />
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>.<br />
<br />
[[File:Waterfall Figure 1.png|right|middle|upright = 0.1|Figure 1: Waterfall model with Royce’s iterative feedback.<ref name = "Ref3"></ref>]]<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why it has been and still is massively used.<br />
<br />
'''Simplicity'''<br />
<br />
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<br />
resources and management knowledge to follow the model<ref name = "Ref11"></ref>.<br />
<br />
'''Consistency'''<br />
<br />
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<br />
both for the smooth running of the work and for future projects<ref name = "Ref2"></ref><ref name = "Ref6"></ref>.<br />
<br />
'''Control'''<br />
<br />
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<br />
are only made between adjacent phases, which limits changes<ref name = "Ref1"></ref>.<br />
<br />
'''When to use Waterfall Model ?'''<br />
<br />
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<br />
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>.<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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<br />
change<ref name = "Ref6"></ref><ref name = "Ref8"></ref>.<br />
<br />
'''A high risk model'''<br />
<br />
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>.<br />
<br />
'''High costs and efforts'''<br />
<br />
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>.<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
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<br />
and other Unified Processes (needs a link to these two methods).<br />
<br />
'''Agile methods'''<br />
<br />
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<br />
short cycles with dynamic planning and prioritization.<br />
<br />
'''When to use which'''<br />
<br />
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<br />
whether a project should be structured according to a Waterfall Model or agile:<br />
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<br />
the waterfall model, 2018</ref>.<br />
* 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.<br />
* 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.<br />
* Culture: Generally speaking, the Waterfall Model will better adapt to a company cultivating values of order and rigor while Agile methods thrive on chaos.<br />
<br />
==Conclusion==<br />
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.<br />
<br />
==Annotated bibliography==<br />
<br />
To go deeper into details it is suggested to look further into those three articles:<br />
<br />
'''Kai Petersen et al, The Waterfall Model in Large-Scale Development, 2009<ref name = "Ref6"></ref>'''<br />
<br />
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.<br />
<br />
'''W.W. Royce, Managing the Development of Large Software Systems<ref name = "Ref1"></ref> '''<br />
<br />
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.<br />
<br />
'''Ilya Bibik, How To Kill the Scrum Monster<ref name = "Ref9"></ref>'''<br />
<br />
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.<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116337Waterfall model2022-03-18T15:41:39Z<p>S212522: /* Description of the model in phases */</p>
<hr />
<div>'''Summary'''<br />
<br />
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.<br />
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.<br />
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.<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
<br />
'''1- Requirements'''<br />
<br />
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>.<br />
<br />
'''2- Analysis'''<br />
<br />
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.<br />
<br />
'''3- Design'''<br />
<br />
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>.<br />
<br />
'''4- Implementation'''<br />
<br />
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>.<br />
<br />
'''5- Testing and Validation'''<br />
<br />
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.<br />
<br />
'''6- Release'''<br />
<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used<ref name = "Ref6"></ref>.<br />
<br />
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.<br />
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.<br />
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>.<br />
<br />
[[File:Waterfall Figure 1.png|right|upright = 0.5|frame|Figure 1: Waterfall model with Royce’s iterative feedback.<ref name = "Ref3"></ref>]]<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why it has been and still is massively used.<br />
<br />
'''Simplicity'''<br />
<br />
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<br />
resources and management knowledge to follow the model<ref name = "Ref11"></ref>.<br />
<br />
'''Consistency'''<br />
<br />
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<br />
both for the smooth running of the work and for future projects<ref name = "Ref2"></ref><ref name = "Ref6"></ref>.<br />
<br />
'''Control'''<br />
<br />
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<br />
are only made between adjacent phases, which limits changes<ref name = "Ref1"></ref>.<br />
<br />
'''When to use Waterfall Model ?'''<br />
<br />
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<br />
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>.<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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<br />
change<ref name = "Ref6"></ref><ref name = "Ref8"></ref>.<br />
<br />
'''A high risk model'''<br />
<br />
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>.<br />
<br />
'''High costs and efforts'''<br />
<br />
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>.<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
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<br />
and other Unified Processes (needs a link to these two methods).<br />
<br />
'''Agile methods'''<br />
<br />
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<br />
short cycles with dynamic planning and prioritization.<br />
<br />
'''When to use which'''<br />
<br />
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<br />
whether a project should be structured according to a Waterfall Model or agile:<br />
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<br />
the waterfall model, 2018</ref>.<br />
* 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.<br />
* 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.<br />
* Culture: Generally speaking, the Waterfall Model will better adapt to a company cultivating values of order and rigor while Agile methods thrive on chaos.<br />
<br />
==Conclusion==<br />
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.<br />
<br />
==Annotated bibliography==<br />
<br />
To go deeper into details it is suggested to look further into those three articles:<br />
<br />
'''Kai Petersen et al, The Waterfall Model in Large-Scale Development, 2009<ref name = "Ref6"></ref>'''<br />
<br />
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.<br />
<br />
'''W.W. Royce, Managing the Development of Large Software Systems<ref name = "Ref1"></ref> '''<br />
<br />
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.<br />
<br />
'''Ilya Bibik, How To Kill the Scrum Monster<ref name = "Ref9"></ref>'''<br />
<br />
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.<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116335Waterfall model2022-03-18T15:41:07Z<p>S212522: /* Description of the model in phases */</p>
<hr />
<div>'''Summary'''<br />
<br />
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.<br />
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.<br />
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.<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
<br />
'''1- Requirements'''<br />
<br />
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>.<br />
<br />
'''2- Analysis'''<br />
<br />
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.<br />
<br />
'''3- Design'''<br />
<br />
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>.<br />
<br />
'''4- Implementation'''<br />
<br />
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>.<br />
<br />
'''5- Testing and Validation'''<br />
<br />
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.<br />
<br />
'''6- Release'''<br />
<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used<ref name = "Ref6"></ref>.<br />
<br />
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.<br />
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.<br />
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>.<br />
<br />
[[File:Waterfall Figure 1.png|right|upright|frame|Figure 1: Waterfall model with Royce’s iterative feedback.<ref name = "Ref3"></ref>]]<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why it has been and still is massively used.<br />
<br />
'''Simplicity'''<br />
<br />
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<br />
resources and management knowledge to follow the model<ref name = "Ref11"></ref>.<br />
<br />
'''Consistency'''<br />
<br />
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<br />
both for the smooth running of the work and for future projects<ref name = "Ref2"></ref><ref name = "Ref6"></ref>.<br />
<br />
'''Control'''<br />
<br />
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<br />
are only made between adjacent phases, which limits changes<ref name = "Ref1"></ref>.<br />
<br />
'''When to use Waterfall Model ?'''<br />
<br />
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<br />
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>.<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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<br />
change<ref name = "Ref6"></ref><ref name = "Ref8"></ref>.<br />
<br />
'''A high risk model'''<br />
<br />
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>.<br />
<br />
'''High costs and efforts'''<br />
<br />
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>.<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
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<br />
and other Unified Processes (needs a link to these two methods).<br />
<br />
'''Agile methods'''<br />
<br />
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<br />
short cycles with dynamic planning and prioritization.<br />
<br />
'''When to use which'''<br />
<br />
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<br />
whether a project should be structured according to a Waterfall Model or agile:<br />
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<br />
the waterfall model, 2018</ref>.<br />
* 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.<br />
* 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.<br />
* Culture: Generally speaking, the Waterfall Model will better adapt to a company cultivating values of order and rigor while Agile methods thrive on chaos.<br />
<br />
==Conclusion==<br />
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.<br />
<br />
==Annotated bibliography==<br />
<br />
To go deeper into details it is suggested to look further into those three articles:<br />
<br />
'''Kai Petersen et al, The Waterfall Model in Large-Scale Development, 2009<ref name = "Ref6"></ref>'''<br />
<br />
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.<br />
<br />
'''W.W. Royce, Managing the Development of Large Software Systems<ref name = "Ref1"></ref> '''<br />
<br />
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.<br />
<br />
'''Ilya Bibik, How To Kill the Scrum Monster<ref name = "Ref9"></ref>'''<br />
<br />
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.<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116331Waterfall model2022-03-18T15:37:13Z<p>S212522: /* Description of the model in phases */</p>
<hr />
<div>'''Summary'''<br />
<br />
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.<br />
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.<br />
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.<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
<br />
'''1- Requirements'''<br />
<br />
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>.<br />
<br />
'''2- Analysis'''<br />
<br />
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.<br />
<br />
'''3- Design'''<br />
<br />
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>.<br />
<br />
'''4- Implementation'''<br />
<br />
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>.<br />
<br />
'''5- Testing and Validation'''<br />
<br />
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.<br />
<br />
'''6- Release'''<br />
<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used<ref name = "Ref6"></ref>.<br />
<br />
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.<br />
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.<br />
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>.<br />
<br />
[[File:Waterfall Figure 1.png|right|frame|Figure 1: Waterfall model with Royce’s iterative feedback.<ref name = "Ref3"></ref>]]<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why it has been and still is massively used.<br />
<br />
'''Simplicity'''<br />
<br />
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<br />
resources and management knowledge to follow the model<ref name = "Ref11"></ref>.<br />
<br />
'''Consistency'''<br />
<br />
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<br />
both for the smooth running of the work and for future projects<ref name = "Ref2"></ref><ref name = "Ref6"></ref>.<br />
<br />
'''Control'''<br />
<br />
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<br />
are only made between adjacent phases, which limits changes<ref name = "Ref1"></ref>.<br />
<br />
'''When to use Waterfall Model ?'''<br />
<br />
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<br />
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>.<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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<br />
change<ref name = "Ref6"></ref><ref name = "Ref8"></ref>.<br />
<br />
'''A high risk model'''<br />
<br />
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>.<br />
<br />
'''High costs and efforts'''<br />
<br />
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>.<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
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<br />
and other Unified Processes (needs a link to these two methods).<br />
<br />
'''Agile methods'''<br />
<br />
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<br />
short cycles with dynamic planning and prioritization.<br />
<br />
'''When to use which'''<br />
<br />
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<br />
whether a project should be structured according to a Waterfall Model or agile:<br />
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<br />
the waterfall model, 2018</ref>.<br />
* 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.<br />
* 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.<br />
* Culture: Generally speaking, the Waterfall Model will better adapt to a company cultivating values of order and rigor while Agile methods thrive on chaos.<br />
<br />
==Conclusion==<br />
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.<br />
<br />
==Annotated bibliography==<br />
<br />
To go deeper into details it is suggested to look further into those three articles:<br />
<br />
'''Kai Petersen et al, The Waterfall Model in Large-Scale Development, 2009<ref name = "Ref6"></ref>'''<br />
<br />
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.<br />
<br />
'''W.W. Royce, Managing the Development of Large Software Systems<ref name = "Ref1"></ref> '''<br />
<br />
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.<br />
<br />
'''Ilya Bibik, How To Kill the Scrum Monster<ref name = "Ref9"></ref>'''<br />
<br />
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.<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=File:Waterfall_Figure_1.png&diff=116328File:Waterfall Figure 1.png2022-03-18T15:34:44Z<p>S212522: Waterfall model with Royce’s iterative feedback</p>
<hr />
<div>Waterfall model with Royce’s iterative feedback</div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116275Waterfall model2022-03-18T15:06:58Z<p>S212522: </p>
<hr />
<div>'''Summary'''<br />
<br />
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.<br />
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.<br />
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.<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
<br />
'''1- Requirements'''<br />
<br />
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>.<br />
<br />
'''2- Analysis'''<br />
<br />
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.<br />
<br />
'''3- Design'''<br />
<br />
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>.<br />
<br />
'''4- Implementation'''<br />
<br />
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>.<br />
<br />
'''5- Testing and Validation'''<br />
<br />
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.<br />
<br />
'''6- Release'''<br />
<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used<ref name = "Ref6"></ref>.<br />
<br />
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.<br />
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.<br />
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>.<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why it has been and still is massively used.<br />
<br />
'''Simplicity'''<br />
<br />
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<br />
resources and management knowledge to follow the model<ref name = "Ref11"></ref>.<br />
<br />
'''Consistency'''<br />
<br />
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<br />
both for the smooth running of the work and for future projects<ref name = "Ref2"></ref><ref name = "Ref6"></ref>.<br />
<br />
'''Control'''<br />
<br />
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<br />
are only made between adjacent phases, which limits changes<ref name = "Ref1"></ref>.<br />
<br />
'''When to use Waterfall Model ?'''<br />
<br />
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<br />
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>.<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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<br />
change<ref name = "Ref6"></ref><ref name = "Ref8"></ref>.<br />
<br />
'''A high risk model'''<br />
<br />
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>.<br />
<br />
'''High costs and efforts'''<br />
<br />
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>.<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
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<br />
and other Unified Processes (needs a link to these two methods).<br />
<br />
'''Agile methods'''<br />
<br />
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<br />
short cycles with dynamic planning and prioritization.<br />
<br />
'''When to use which'''<br />
<br />
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<br />
whether a project should be structured according to a Waterfall Model or agile:<br />
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<br />
the waterfall model, 2018</ref>.<br />
* 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.<br />
* 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.<br />
* Culture: Generally speaking, the Waterfall Model will better adapt to a company cultivating values of order and rigor while Agile methods thrive on chaos.<br />
<br />
==Conclusion==<br />
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.<br />
<br />
==Annotated bibliography==<br />
<br />
To go deeper into details it is suggested to look further into those three articles:<br />
<br />
'''Kai Petersen et al, The Waterfall Model in Large-Scale Development, 2009<ref name = "Ref6"></ref>'''<br />
<br />
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.<br />
<br />
'''W.W. Royce, Managing the Development of Large Software Systems<ref name = "Ref1"></ref> '''<br />
<br />
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.<br />
<br />
'''Ilya Bibik, How To Kill the Scrum Monster<ref name = "Ref9"></ref>'''<br />
<br />
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.<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116271Waterfall model2022-03-18T15:03:43Z<p>S212522: </p>
<hr />
<div>'''Summary'''<br />
<br />
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.<br />
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.<br />
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.<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
<br />
'''1- Requirements'''<br />
<br />
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>.<br />
<br />
'''2- Analysis'''<br />
<br />
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.<br />
<br />
'''3- Design'''<br />
<br />
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>.<br />
<br />
'''4- Implementation'''<br />
<br />
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>.<br />
<br />
'''5- Testing and Validation'''<br />
<br />
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.<br />
<br />
'''6- Release'''<br />
<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used<ref name = "Ref6"></ref>.<br />
<br />
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.<br />
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.<br />
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>.<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why it has been and still is massively used.<br />
<br />
'''Simplicity'''<br />
<br />
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<br />
resources and management knowledge to follow the model<ref name = "Ref11"></ref>.<br />
<br />
'''Consistency'''<br />
<br />
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<br />
both for the smooth running of the work and for future projects<ref name = "Ref2"></ref><ref name = "Ref6"></ref>.<br />
<br />
'''Control'''<br />
<br />
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<br />
are only made between adjacent phases, which limits changes<ref name = "Ref1"></ref>.<br />
<br />
'''When to use Waterfall Model ?'''<br />
<br />
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<br />
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>.<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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<br />
change<ref name = "Ref6"></ref><ref name = "Ref8"></ref>.<br />
<br />
'''A high risk model'''<br />
<br />
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>.<br />
<br />
'''High costs and efforts'''<br />
<br />
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>.<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
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<br />
and other Unified Processes (needs a link to these two methods).<br />
<br />
'''Agile methods'''<br />
<br />
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<br />
short cycles with dynamic planning and prioritization.<br />
<br />
'''When to use which'''<br />
<br />
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<br />
whether a project should be structured according to a Waterfall Model or agile:<br />
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<br />
the waterfall model, 2018</ref>.<br />
* 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.<br />
* 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.<br />
* Culture: Generally speaking, the Waterfall Model will better adapt to a company cultivating values of order and rigor while Agile methods thrive on chaos.<br />
<br />
==Conclusion==<br />
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.<br />
<br />
==Annotated bibliography==<br />
<br />
To go deeper into details it is suggested to look further into those three articles:<br />
<br />
'''Kai Petersen et al, The Waterfall Model in Large-Scale Development, 2009<ref name = "Ref6"></ref>'''<br />
<br />
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.<br />
<br />
'''W.W. Royce, Managing the Development of Large Software Systems<ref name = "Ref1"></ref> '''<br />
<br />
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.<br />
<br />
'''Ilya Bibik, How To Kill the Scrum Monster<ref name = "Ref9"></ref>'''<br />
<br />
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.<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116269Waterfall model2022-03-18T15:02:55Z<p>S212522: </p>
<hr />
<div>'''Summary'''<br />
<br />
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.<br />
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.<br />
Since the emergence of the agile project management method, many comparative studies<ref name = "Ref3"></ref> have been published to demonstrate the benefits of one model over another.<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
<br />
'''1- Requirements'''<br />
<br />
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>.<br />
<br />
'''2- Analysis'''<br />
<br />
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.<br />
<br />
'''3- Design'''<br />
<br />
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>.<br />
<br />
'''4- Implementation'''<br />
<br />
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>.<br />
<br />
'''5- Testing and Validation'''<br />
<br />
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.<br />
<br />
'''6- Release'''<br />
<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used<ref name = "Ref6"></ref>.<br />
<br />
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.<br />
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.<br />
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>.<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why it has been and still is massively used.<br />
<br />
'''Simplicity'''<br />
<br />
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<br />
resources and management knowledge to follow the model<ref name = "Ref11"></ref>.<br />
<br />
'''Consistency'''<br />
<br />
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<br />
both for the smooth running of the work and for future projects<ref name = "Ref2"></ref><ref name = "Ref6"></ref>.<br />
<br />
'''Control'''<br />
<br />
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<br />
are only made between adjacent phases, which limits changes<ref name = "Ref1"></ref>.<br />
<br />
'''When to use Waterfall Model ?'''<br />
<br />
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<br />
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>.<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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<br />
change<ref name = "Ref6"></ref><ref name = "Ref8"></ref>.<br />
<br />
'''A high risk model'''<br />
<br />
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>.<br />
<br />
'''High costs and efforts'''<br />
<br />
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>.<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
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<br />
and other Unified Processes (needs a link to these two methods).<br />
<br />
'''Agile methods'''<br />
<br />
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<br />
short cycles with dynamic planning and prioritization.<br />
<br />
'''When to use which'''<br />
<br />
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<br />
whether a project should be structured according to a Waterfall Model or agile:<br />
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<br />
the waterfall model, 2018</ref>.<br />
* 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.<br />
* 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.<br />
* Culture: Generally speaking, the Waterfall Model will better adapt to a company cultivating values of order and rigor while Agile methods thrive on chaos.<br />
<br />
==Conclusion==<br />
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.<br />
<br />
==Annotated bibliography==<br />
<br />
To go deeper into details it is suggested to look further into those three articles:<br />
<br />
'''Kai Petersen et al, The Waterfall Model in Large-Scale Development, 2009<ref name = "Ref6"></ref>'''<br />
<br />
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.<br />
<br />
'''W.W. Royce, Managing the Development of Large Software Systems<ref name = "Ref1"></ref> '''<br />
<br />
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.<br />
<br />
'''Ilya Bibik, How To Kill the Scrum Monster<ref name = "Ref9"></ref>'''<br />
<br />
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.<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116268Waterfall model2022-03-18T15:01:54Z<p>S212522: </p>
<hr />
<div>'''Summary'''<br />
<br />
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.<br />
Although considered obsolete, this model is still widely used in the business world, for instance in software development companies<ref name = "Ref2">. 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.<br />
Since the emergence of the agile project management method, many comparative studies<ref name = "Ref3"> have been published to demonstrate the benefits of one model over another.<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
<br />
'''1- Requirements'''<br />
<br />
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>.<br />
<br />
'''2- Analysis'''<br />
<br />
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.<br />
<br />
'''3- Design'''<br />
<br />
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>.<br />
<br />
'''4- Implementation'''<br />
<br />
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>.<br />
<br />
'''5- Testing and Validation'''<br />
<br />
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.<br />
<br />
'''6- Release'''<br />
<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used<ref name = "Ref6"></ref>.<br />
<br />
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.<br />
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.<br />
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>.<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why it has been and still is massively used.<br />
<br />
'''Simplicity'''<br />
<br />
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<br />
resources and management knowledge to follow the model<ref name = "Ref11"></ref>.<br />
<br />
'''Consistency'''<br />
<br />
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<br />
both for the smooth running of the work and for future projects<ref name = "Ref2"></ref><ref name = "Ref6"></ref>.<br />
<br />
'''Control'''<br />
<br />
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<br />
are only made between adjacent phases, which limits changes<ref name = "Ref1"></ref>.<br />
<br />
'''When to use Waterfall Model ?'''<br />
<br />
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<br />
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>.<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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<br />
change<ref name = "Ref6"></ref><ref name = "Ref8"></ref>.<br />
<br />
'''A high risk model'''<br />
<br />
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>.<br />
<br />
'''High costs and efforts'''<br />
<br />
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>.<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
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<br />
and other Unified Processes (needs a link to these two methods).<br />
<br />
'''Agile methods'''<br />
<br />
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<br />
short cycles with dynamic planning and prioritization.<br />
<br />
'''When to use which'''<br />
<br />
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<br />
whether a project should be structured according to a Waterfall Model or agile:<br />
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<br />
the waterfall model, 2018</ref>.<br />
* 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.<br />
* 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.<br />
* Culture: Generally speaking, the Waterfall Model will better adapt to a company cultivating values of order and rigor while Agile methods thrive on chaos.<br />
<br />
==Conclusion==<br />
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.<br />
<br />
==Annotated bibliography==<br />
<br />
To go deeper into details it is suggested to look further into those three articles:<br />
<br />
'''Kai Petersen et al, The Waterfall Model in Large-Scale Development, 2009<ref name = "Ref6"></ref>'''<br />
<br />
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.<br />
<br />
'''W.W. Royce, Managing the Development of Large Software Systems<ref name = "Ref1"></ref> '''<br />
<br />
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.<br />
<br />
'''Ilya Bibik, How To Kill the Scrum Monster<ref name = "Ref9"></ref>'''<br />
<br />
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.<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116267Waterfall model2022-03-18T15:00:36Z<p>S212522: </p>
<hr />
<div>'''Summary'''<br />
<br />
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.<br />
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.<br />
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.<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
<br />
'''1- Requirements'''<br />
<br />
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>.<br />
<br />
'''2- Analysis'''<br />
<br />
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.<br />
<br />
'''3- Design'''<br />
<br />
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>.<br />
<br />
'''4- Implementation'''<br />
<br />
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>.<br />
<br />
'''5- Testing and Validation'''<br />
<br />
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.<br />
<br />
'''6- Release'''<br />
<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used<ref name = "Ref6"></ref>.<br />
<br />
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.<br />
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.<br />
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>.<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why it has been and still is massively used.<br />
<br />
'''Simplicity'''<br />
<br />
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<br />
resources and management knowledge to follow the model<ref name = "Ref11"></ref>.<br />
<br />
'''Consistency'''<br />
<br />
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<br />
both for the smooth running of the work and for future projects<ref name = "Ref2"></ref><ref name = "Ref6"></ref>.<br />
<br />
'''Control'''<br />
<br />
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<br />
are only made between adjacent phases, which limits changes<ref name = "Ref1"></ref>.<br />
<br />
'''When to use Waterfall Model ?'''<br />
<br />
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<br />
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>.<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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<br />
change<ref name = "Ref6"></ref><ref name = "Ref8"></ref>.<br />
<br />
'''A high risk model'''<br />
<br />
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>.<br />
<br />
'''High costs and efforts'''<br />
<br />
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>.<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
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<br />
and other Unified Processes (needs a link to these two methods).<br />
<br />
'''Agile methods'''<br />
<br />
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<br />
short cycles with dynamic planning and prioritization.<br />
<br />
'''When to use which'''<br />
<br />
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<br />
whether a project should be structured according to a Waterfall Model or agile:<br />
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<br />
the waterfall model, 2018</ref>.<br />
* 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.<br />
* 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.<br />
* Culture: Generally speaking, the Waterfall Model will better adapt to a company cultivating values of order and rigor while Agile methods thrive on chaos.<br />
<br />
==Conclusion==<br />
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.<br />
<br />
==Annotated bibliography==<br />
<br />
To go deeper into details it is suggested to look further into those three articles:<br />
<br />
'''Kai Petersen et al, The Waterfall Model in Large-Scale Development, 2009<ref name = "Ref6"></ref>'''<br />
<br />
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.<br />
<br />
'''W.W. Royce, Managing the Development of Large Software Systems<ref name = "Ref1"></ref> '''<br />
<br />
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.<br />
<br />
'''Ilya Bibik, How To Kill the Scrum Monster<ref name = "Ref9"></ref>'''<br />
<br />
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.<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116266Waterfall model2022-03-18T14:58:49Z<p>S212522: /* Annotated bibliography */</p>
<hr />
<div>'''Summary'''<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
<br />
'''1- Requirements'''<br />
<br />
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>.<br />
<br />
'''2- Analysis'''<br />
<br />
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.<br />
<br />
'''3- Design'''<br />
<br />
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>.<br />
<br />
'''4- Implementation'''<br />
<br />
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>.<br />
<br />
'''5- Testing and Validation'''<br />
<br />
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.<br />
<br />
'''6- Release'''<br />
<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used<ref name = "Ref6"></ref>.<br />
<br />
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.<br />
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.<br />
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>.<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why it has been and still is massively used.<br />
<br />
'''Simplicity'''<br />
<br />
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<br />
resources and management knowledge to follow the model<ref name = "Ref11"></ref>.<br />
<br />
'''Consistency'''<br />
<br />
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<br />
both for the smooth running of the work and for future projects<ref name = "Ref2"></ref><ref name = "Ref6"></ref>.<br />
<br />
'''Control'''<br />
<br />
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<br />
are only made between adjacent phases, which limits changes<ref name = "Ref1"></ref>.<br />
<br />
'''When to use Waterfall Model ?'''<br />
<br />
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<br />
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>.<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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<br />
change<ref name = "Ref6"></ref><ref name = "Ref8"></ref>.<br />
<br />
'''A high risk model'''<br />
<br />
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>.<br />
<br />
'''High costs and efforts'''<br />
<br />
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>.<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
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<br />
and other Unified Processes (needs a link to these two methods).<br />
<br />
'''Agile methods'''<br />
<br />
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<br />
short cycles with dynamic planning and prioritization.<br />
<br />
'''When to use which'''<br />
<br />
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<br />
whether a project should be structured according to a Waterfall Model or agile:<br />
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<br />
the waterfall model, 2018</ref>.<br />
* 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.<br />
* 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.<br />
* Culture: Generally speaking, the Waterfall Model will better adapt to a company cultivating values of order and rigor while Agile methods thrive on chaos.<br />
<br />
==Conclusion==<br />
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.<br />
<br />
==Annotated bibliography==<br />
<br />
To go deeper into details it is suggested to look further into those three articles:<br />
<br />
'''Kai Petersen et al, The Waterfall Model in Large-Scale Development, 2009<ref name = "Ref6"></ref>'''<br />
<br />
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.<br />
<br />
'''W.W. Royce, Managing the Development of Large Software Systems<ref name = "Ref1"></ref> '''<br />
<br />
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.<br />
<br />
'''Ilya Bibik, How To Kill the Scrum Monster<ref name = "Ref9"></ref>'''<br />
<br />
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.<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116265Waterfall model2022-03-18T14:58:06Z<p>S212522: /* Advantages of the model and when to use it */</p>
<hr />
<div>'''Summary'''<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
<br />
'''1- Requirements'''<br />
<br />
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>.<br />
<br />
'''2- Analysis'''<br />
<br />
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.<br />
<br />
'''3- Design'''<br />
<br />
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>.<br />
<br />
'''4- Implementation'''<br />
<br />
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>.<br />
<br />
'''5- Testing and Validation'''<br />
<br />
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.<br />
<br />
'''6- Release'''<br />
<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used<ref name = "Ref6"></ref>.<br />
<br />
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.<br />
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.<br />
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>.<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why it has been and still is massively used.<br />
<br />
'''Simplicity'''<br />
<br />
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<br />
resources and management knowledge to follow the model<ref name = "Ref11"></ref>.<br />
<br />
'''Consistency'''<br />
<br />
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<br />
both for the smooth running of the work and for future projects<ref name = "Ref2"></ref><ref name = "Ref6"></ref>.<br />
<br />
'''Control'''<br />
<br />
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<br />
are only made between adjacent phases, which limits changes<ref name = "Ref1"></ref>.<br />
<br />
'''When to use Waterfall Model ?'''<br />
<br />
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<br />
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>.<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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<br />
change<ref name = "Ref6"></ref><ref name = "Ref8"></ref>.<br />
<br />
'''A high risk model'''<br />
<br />
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>.<br />
<br />
'''High costs and efforts'''<br />
<br />
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>.<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
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<br />
and other Unified Processes (needs a link to these two methods).<br />
<br />
'''Agile methods'''<br />
<br />
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<br />
short cycles with dynamic planning and prioritization.<br />
<br />
'''When to use which'''<br />
<br />
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<br />
whether a project should be structured according to a Waterfall Model or agile:<br />
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<br />
the waterfall model, 2018</ref>.<br />
* 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.<br />
* 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.<br />
* Culture: Generally speaking, the Waterfall Model will better adapt to a company cultivating values of order and rigor while Agile methods thrive on chaos.<br />
<br />
==Conclusion==<br />
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.<br />
<br />
==Annotated bibliography==<br />
<br />
To go deeper into details it is suggested to look further into those three articles:<br />
<br />
'''W.W. Royce, Managing the Development of Large Software Systems<ref name = "Ref1"></ref> '''<br />
<br />
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.<br />
<br />
'''Kai Petersen et al, The Waterfall Model in Large-Scale Development, 2009<ref name = "Ref6"></ref>'''<br />
<br />
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.<br />
<br />
'''Ilya Bibik, How To Kill the Scrum Monster<ref name = "Ref9"></ref>'''<br />
<br />
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.<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116263Waterfall model2022-03-18T14:57:05Z<p>S212522: </p>
<hr />
<div>'''Summary'''<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
<br />
'''1- Requirements'''<br />
<br />
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>.<br />
<br />
'''2- Analysis'''<br />
<br />
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.<br />
<br />
'''3- Design'''<br />
<br />
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>.<br />
<br />
'''4- Implementation'''<br />
<br />
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>.<br />
<br />
'''5- Testing and Validation'''<br />
<br />
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.<br />
<br />
'''6- Release'''<br />
<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used<ref name = "Ref6"></ref>.<br />
<br />
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.<br />
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.<br />
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>.<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why it has been and still is massively used.<br />
<br />
'''Simplicity'''<br />
<br />
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<br />
resources and management knowledge to follow the model<ref name = "Ref11"></ref>.<br />
<br />
'''Consistency'''<br />
<br />
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<br />
both for the smooth running of the work and for future projects<ref name = "Ref2"></ref><ref name = "Ref6"></ref>.<br />
<br />
'''Control'''<br />
<br />
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<br />
are only made between adjacent phases, which limits changes<ref name = "Ref1"></ref>.<br />
'''When to use Waterfall Model ?'''<br />
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<br />
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>.<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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<br />
change<ref name = "Ref6"></ref><ref name = "Ref8"></ref>.<br />
<br />
'''A high risk model'''<br />
<br />
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>.<br />
<br />
'''High costs and efforts'''<br />
<br />
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>.<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
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<br />
and other Unified Processes (needs a link to these two methods).<br />
<br />
'''Agile methods'''<br />
<br />
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<br />
short cycles with dynamic planning and prioritization.<br />
<br />
'''When to use which'''<br />
<br />
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<br />
whether a project should be structured according to a Waterfall Model or agile:<br />
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<br />
the waterfall model, 2018</ref>.<br />
* 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.<br />
* 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.<br />
* Culture: Generally speaking, the Waterfall Model will better adapt to a company cultivating values of order and rigor while Agile methods thrive on chaos.<br />
<br />
==Conclusion==<br />
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.<br />
<br />
==Annotated bibliography==<br />
<br />
To go deeper into details it is suggested to look further into those three articles:<br />
<br />
'''W.W. Royce, Managing the Development of Large Software Systems<ref name = "Ref1"></ref> '''<br />
<br />
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.<br />
<br />
'''Kai Petersen et al, The Waterfall Model in Large-Scale Development, 2009<ref name = "Ref6"></ref>'''<br />
<br />
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.<br />
<br />
'''Ilya Bibik, How To Kill the Scrum Monster<ref name = "Ref9"></ref>'''<br />
<br />
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.<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116258Waterfall model2022-03-18T14:30:12Z<p>S212522: </p>
<hr />
<div>'''Summary'''<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
<br />
'''1- Requirements'''<br />
<br />
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 [2].<br />
<br />
'''2- Analysis'''<br />
<br />
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.<br />
<br />
'''3- Design'''<br />
<br />
From the specifications, the functions and requirements are transformed into a feasible product. The product is specified and its architecture is designed [11].<br />
<br />
'''4- Implementation'''<br />
<br />
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].<br />
<br />
'''5- Testing and Validation'''<br />
<br />
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.<br />
<br />
'''6- Release'''<br />
<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used <ref name = "Ref6"></ref>.<br />
<br />
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.<br />
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.<br />
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].<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why<br />
it has been and still is massively used.<br />
<br />
'''Simplicity'''<br />
<br />
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<br />
resources and management knowledge to follow the model [11].<br />
<br />
'''Consistency'''<br />
<br />
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<br />
both for the smooth running of the work and for future projects [2]<ref name = "Ref6"></ref>.<br />
<br />
'''Control'''<br />
<br />
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 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 [2]. Finally, iterations and changes<br />
are only made between adjacent phases, which limits changes [1].<br />
'''When to use Waterfall Model ?'''<br />
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<br />
in very large projects the Waterfall Model should be chosen for its advantages [8].<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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 [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<br />
change<ref name = "Ref6"></ref>[8].<br />
<br />
'''A high risk model'''<br />
<br />
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 name = "Ref6"></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 name = "Ref6"></ref>, "then invariably a major redesign is required" adds W.W. Royce [1].<br />
<br />
'''High costs and efforts'''<br />
<br />
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 name = "Ref6"></ref>. Similarly, iterations and rollbacks of previous phases are costly in terms of team effort<ref name = "Ref6"></ref>[11]. Finally, in the case of major substantive problems encountered in the final phase, additional costs are obviously to be expected, as<br />
well as an overrun of the planned dates<ref name = "Ref6"></ref>.<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
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<br />
and other Unified Processes (needs a link to these two methods).<br />
<br />
'''Agile methods'''<br />
<br />
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<br />
short cycles with dynamic planning and prioritization.<br />
<br />
'''When to use which'''<br />
<br />
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<br />
whether a project should be structured according to a Waterfall Model or agile:<br />
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<br />
responsiveness to change[5].<br />
* 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.<br />
* 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.<br />
* Culture: Generally speaking, the Waterfall Model will better adapt to a company cultivating values of order and rigor while Agile methods thrive on chaos.<br />
<br />
==Conclusion==<br />
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.<br />
<br />
==Annotated bibliography==<br />
<br />
To go deeper into details it is suggested to look further into those three articles:<br />
<br />
'''[1] W.W. Royce, Managing the Development of Large Software Systems'''<br />
<br />
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.<br />
<br />
'''Kai Petersen et al, The Waterfall Model in Large-Scale Development, 2009<ref name = "Ref6"></ref>'''<br />
<br />
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.<br />
<br />
'''[9] Ilya Bibik, How To Kill the Scrum Monster'''<br />
<br />
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.<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116256Waterfall model2022-03-18T14:27:10Z<p>S212522: /* Description of the model in phases */</p>
<hr />
<div>'''Summary'''<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
<br />
'''1- Requirements'''<br />
<br />
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 [2].<br />
<br />
'''2- Analysis'''<br />
<br />
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.<br />
<br />
'''3- Design'''<br />
<br />
From the specifications, the functions and requirements are transformed into a feasible product. The product is specified and its architecture is designed [11].<br />
<br />
'''4- Implementation'''<br />
<br />
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].<br />
<br />
'''5- Testing and Validation'''<br />
<br />
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.<br />
<br />
'''6- Release'''<br />
<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used <ref name = "Ref6"></ref>.<br />
<br />
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.<br />
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.<br />
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].<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why<br />
it has been and still is massively used.<br />
<br />
'''Simplicity'''<br />
<br />
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<br />
resources and management knowledge to follow the model [11].<br />
<br />
'''Consistency'''<br />
<br />
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<br />
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>.<br />
<br />
'''Control'''<br />
<br />
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<br />
are only made between adjacent phases, which limits changes [1].<br />
'''When to use Waterfall Model ?'''<br />
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<br />
in very large projects the Waterfall Model should be chosen for its advantages [8].<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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<br />
change<ref>Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009</ref>[8].<br />
<br />
'''A high risk model'''<br />
<br />
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<br />
<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].<br />
<br />
'''High costs and efforts'''<br />
<br />
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<br />
well as an overrun of the planned dates<ref>Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009</ref>.<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
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<br />
and other Unified Processes (needs a link to these two methods).<br />
<br />
'''Agile methods'''<br />
<br />
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<br />
short cycles with dynamic planning and prioritization.<br />
<br />
'''When to use which'''<br />
<br />
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<br />
whether a project should be structured according to a Waterfall Model or agile:<br />
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<br />
responsiveness to change[5].<br />
* 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.<br />
* 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.<br />
* Culture: Generally speaking, the Waterfall Model will better adapt to a company cultivating values of order and rigor while Agile methods thrive on chaos.<br />
<br />
==Conclusion==<br />
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.<br />
<br />
==Annotated bibliography==<br />
<br />
To go deeper into details it is suggested to look further into those three articles:<br />
<br />
'''[1] W.W. Royce, Managing the Development of Large Software Systems'''<br />
<br />
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.<br />
<br />
'''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>'''<br />
<br />
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.<br />
<br />
'''[9] Ilya Bibik, How To Kill the Scrum Monster'''<br />
<br />
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.<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116255Waterfall model2022-03-18T14:26:42Z<p>S212522: </p>
<hr />
<div>'''Summary'''<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
<br />
'''1- Requirements'''<br />
<br />
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 [2].<br />
<br />
'''2- Analysis'''<br />
<br />
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.<br />
<br />
'''3- Design'''<br />
<br />
From the specifications, the functions and requirements are transformed into a feasible product. The product is specified and its architecture is designed [11].<br />
<br />
'''4- Implementation'''<br />
<br />
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].<br />
<br />
'''5- Testing and Validation'''<br />
<br />
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.<br />
<br />
'''6- Release'''<br />
<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used <ref name = "Ref6">.<br />
<br />
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.<br />
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.<br />
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].<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why<br />
it has been and still is massively used.<br />
<br />
'''Simplicity'''<br />
<br />
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<br />
resources and management knowledge to follow the model [11].<br />
<br />
'''Consistency'''<br />
<br />
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<br />
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>.<br />
<br />
'''Control'''<br />
<br />
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<br />
are only made between adjacent phases, which limits changes [1].<br />
'''When to use Waterfall Model ?'''<br />
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<br />
in very large projects the Waterfall Model should be chosen for its advantages [8].<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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<br />
change<ref>Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009</ref>[8].<br />
<br />
'''A high risk model'''<br />
<br />
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<br />
<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].<br />
<br />
'''High costs and efforts'''<br />
<br />
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<br />
well as an overrun of the planned dates<ref>Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009</ref>.<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
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<br />
and other Unified Processes (needs a link to these two methods).<br />
<br />
'''Agile methods'''<br />
<br />
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<br />
short cycles with dynamic planning and prioritization.<br />
<br />
'''When to use which'''<br />
<br />
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<br />
whether a project should be structured according to a Waterfall Model or agile:<br />
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<br />
responsiveness to change[5].<br />
* 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.<br />
* 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.<br />
* Culture: Generally speaking, the Waterfall Model will better adapt to a company cultivating values of order and rigor while Agile methods thrive on chaos.<br />
<br />
==Conclusion==<br />
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.<br />
<br />
==Annotated bibliography==<br />
<br />
To go deeper into details it is suggested to look further into those three articles:<br />
<br />
'''[1] W.W. Royce, Managing the Development of Large Software Systems'''<br />
<br />
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.<br />
<br />
'''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>'''<br />
<br />
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.<br />
<br />
'''[9] Ilya Bibik, How To Kill the Scrum Monster'''<br />
<br />
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.<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116254Waterfall model2022-03-18T14:25:30Z<p>S212522: </p>
<hr />
<div>'''Summary'''<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
<br />
'''1- Requirements'''<br />
<br />
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 [2].<br />
<br />
'''2- Analysis'''<br />
<br />
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.<br />
<br />
'''3- Design'''<br />
<br />
From the specifications, the functions and requirements are transformed into a feasible product. The product is specified and its architecture is designed [11].<br />
<br />
'''4- Implementation'''<br />
<br />
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].<br />
<br />
'''5- Testing and Validation'''<br />
<br />
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.<br />
<br />
'''6- Release'''<br />
<br />
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>.<br />
<br />
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.<br />
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.<br />
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].<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why<br />
it has been and still is massively used.<br />
<br />
'''Simplicity'''<br />
<br />
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<br />
resources and management knowledge to follow the model [11].<br />
<br />
'''Consistency'''<br />
<br />
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<br />
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>.<br />
<br />
'''Control'''<br />
<br />
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<br />
are only made between adjacent phases, which limits changes [1].<br />
'''When to use Waterfall Model ?'''<br />
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<br />
in very large projects the Waterfall Model should be chosen for its advantages [8].<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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<br />
change<ref>Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009</ref>[8].<br />
<br />
'''A high risk model'''<br />
<br />
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<br />
<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].<br />
<br />
'''High costs and efforts'''<br />
<br />
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<br />
well as an overrun of the planned dates<ref>Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009</ref>.<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
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<br />
and other Unified Processes (needs a link to these two methods).<br />
<br />
'''Agile methods'''<br />
<br />
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<br />
short cycles with dynamic planning and prioritization.<br />
<br />
'''When to use which'''<br />
<br />
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<br />
whether a project should be structured according to a Waterfall Model or agile:<br />
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<br />
responsiveness to change[5].<br />
* 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.<br />
* 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.<br />
* Culture: Generally speaking, the Waterfall Model will better adapt to a company cultivating values of order and rigor while Agile methods thrive on chaos.<br />
<br />
==Conclusion==<br />
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.<br />
<br />
==Annotated bibliography==<br />
<br />
To go deeper into details it is suggested to look further into those three articles:<br />
<br />
'''[1] W.W. Royce, Managing the Development of Large Software Systems'''<br />
<br />
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.<br />
<br />
'''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>'''<br />
<br />
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.<br />
<br />
'''[9] Ilya Bibik, How To Kill the Scrum Monster'''<br />
<br />
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.<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Emotional_Intelligence_in_a_Program,_Project_and_Portfolio_Management_View&diff=116253Emotional Intelligence in a Program, Project and Portfolio Management View2022-03-18T14:25:09Z<p>S212522: </p>
<hr />
<div>"Developed by Andrea Gatto"<br />
<br />
'''Summary'''<br />
<br />
The well-known American psychologist Daniel Goleman in his book “Emotional Intelligence”, published in 1995, defines the Emotional Intelligence as “the ability to recognize, understand and manage our own emotions and recognize, understand and influence the emotions of the others”<ref>Goleman, D. (1995). Emotional Intelligence </ref>. <br />
Indeed, EI belongs to the large group of soft skills, also called behavior skills, which are a prerogative to be flexible and adaptable to any environment, especially in a business environment, where interactions with colleagues and stakeholders are on the agenda.<br />
Is it possible that someone selected for a job position through classic tests is not actually able to handle it? it could be: self-control, stubbornness, empathy, and attention to the others are fundamental to work effectively in a shared environment. Indeed, the purpose of this article is to provide an overview of the importance of the EI within team projects, individual tasks and relations with stakeholders, especially from a psychological point of view.<br />
<br />
==Emotional Intelligence and its Application==<br />
<br />
EI, as an individual and soft skill, can be applied in different contexts. Since it is a skill that every person should develop and train to make the most of it, in the first paragraphs it will be addressed from the point of view of the people who are working in a group project, then moving on the concept of EI used as an effective tool for stakeholder negotiation and limitations in its application.<br />
<br />
===EI in team projects===<br />
<br />
Why EI can be matter more than IQ? Interesting question, isn't it? In order to answer it, it would be wise to analyze the behavior of individuals in carrying out corporate activities or, even better, group activities.<br />
Sy, Tram and O'Hara, professors of the Department of Psychology at the University of California, suggested in their research that there is a positive relationship between job performance and team members having high level of EI, because they are highly proficient at appraising and regulating their own emotions, which results in a higher level of faith in themselves and have power over them, which lead to make realistic actions resulting in high performance and less supervisory interference <ref> Sy, T., Tram, S., and O’Hara, L. A. (2006). Relation of employee and manger EI to job satisfaction and performance. In Journal of Vocational Behavior, 68, 461-473. Retrieved April 02, 2010, from http://www.emeraldinsight.com </ref>.<br />
On the other hand, it is logical thinking about that team members with low level of EI are less skilled at appraising and regulating their emotions, so they need to be supervised and helped by managers to better control their feelings, improving so the coordination and adaptability within the working team. <br />
Another ability included in EI is the use of emotions, or the individual skill addressed to aid the cognitive processes. The right use of emotions can be a very useful tool to expand the flexibility of information processing or pick out among corresponding alternatives. Therefore, individuals differ not only in the ability to understand and express their emotions, but also in their ability to use emotions in collaboration with their cognitive processes to heighten fruitful operating. It seems to be clear that individuals, who struggle with the right use of EI linked to cognitive processes, are less likely to coordinate themselves in a group environment, being less able to fulfill the assigned task <ref>Zhou, J., George, J. M. (2003). Awakening employee creativity: The role of leader emotional intelligence. Leadership Quarterly, 14, 545 – 568</ref>. <br />
In addition to that, the other milestone comprised into EI is the regulation of the emotions of the people: individuals should focus on that aspect because it is extremely important to keep the balance between all the members involved in a project, for a better coordination, chemistry within the group and consequently for better outputs. For instance, if there occur any breach in quality, it may raise up a negative emotion reaction when the manager tries to understand the cause of the problem. However, managing that negative emotion, trying to effectively solve the problem, instead of just complaining or blaming someone, is fundamental. Handling emotional reactions leads to understand where the focus of interest is, avoiding disruptive conflicts and misunderstandings.<br />
<br />
[[File:sustainability-11-0-2299-g001.png|650px|thumb|left|Handling emotions for job performances <ref>Nhu Ngoc Nguyen, Phong Tuan Nham and Yoshi Takahashi. Relationship between Ability-Based Emotional Intelligence, Cognitive Intelligence, and Job Performance. https://www.mdpi.com/2071-1050/11/8/2299</ref>]]<br />
<br />
EI is a value that can be developed, trained, and achieved with a certain maturity. Nevertheless, as soon as the activities become more demanding and the workload increases, emotions are put to the test. Who knows how to stay motivated under stress, motivate others and manage complex interpersonal relationships, will get better result <ref>Goleman, D. (2005). Emotional Intelligence. (10th Ed). New York: Bantam Books</ref>. <br />
Though there are many studies and research regarding the improvement of job performances through a right use of EI, it seems that on individual level there would be no significant results. Indeed, few studies have investigated the relationships between EI and performance at group level are more relevant: Jordan and Troth (2002) have found a link between EI and performance on a purely cognitive task at group level. According to these authors, the ability to deal with one’s own emotions, allows team members to be more inclined to listen to others’ points of view and to seek superior solutions, without thinking of being wrong. Moreover, they found out that teams with a high level of EI have preference for collaborative conflict resolution strategies, unlike teams with low level of EI <ref>Quoidbach, J & Hansenne, M. (2000). The impact of trait emotional intelligence on nursing team performance and cohesiveness. In Journal of Professional Nursing, 25(1), 23–29. Retrieved March 02, 2010, from http://www.emeraldinsight.com</ref>.<br />
<br />
<br />
<br />
All these aspects are relevant to understand the importance of developing these skills, not focusing just on classic tests but much more on individual mental growth.<br />
<br />
====Practical advice to improve EI <ref> Paisley V., 5 Ways to Develop the Emotional Intelligence of Your Workforce (2018) from https://www.learnlight.com/en/articles/5-ways-to-develop-emotional-intelligence-of-your-workforce/</ref>====<br />
To work better in a team, managers look for people who strive to be flexible and put the team's good before their own interests. This is the reason why the individual contribution is extremely important within a project group, so that everyone could follow five steps which would allow people to be more understandable towards colleagues:<br />
* '''Stop and think about feelings''': as it is stated above, EI starts with self and social awareness. Through this, people do not let feelings rule their behavior. In order to do so, managers should encourage employees to ask themselves reflective questions, such as "What are my emotional strengths and weaknesses?" or "How does my current state of mind influence my thoughts and decision-making?", which reveal valuable insights that can be used to develop new interpersonal skills and, over time, intercept negative influences, enhancing positivity.<br />
* '''Show empathy towards other''': empathy is the skill which allows people to recognize their and other's feelings. So people should strive to understand other's viewpoints in order to build deeper connections with colleagues, helpful when a person is dealing with someone who is challenging to work with.<br />
*'''Listen to understand and not to answer''': patience is a key of developing a right EI attitude; listening is a valuable competence and even though a person does't agree with a colleague, it is important to acknowledge what they are saying in order to establish trust and rapport.<br />
*'''See challenges and criticism as a learning opportunity''': being positive is fundamental in every situation, so for a manager it would be useful to encourage employees to look at how they deal with criticism and push them to deal with the feedback in a positive way. This would help the individuals to learn from their mistakes and how they might deal with a similar situation in the future. Over time, the person will be able to motivate themselves more easily and respond well to challenge.<br />
*'''Manage relationships well''': the last step, after working hard on the previous ones, leads the individual to communicate effectively, deal with conflict more smoothly and encourage more trust in colleagues. <br />
<br />
The sooner people begin to work on themself, the sooner they foster effective and efficient work.<br />
<br />
===EI: Individual Effort and Motivation===<br />
<br />
In addition to being characterized by social skills such as empathy and construction of relational networks as it is stated above, EI is characterized by personal skills such as self-awareness, self-control and understanding of one’s motivation. This is clear that is a task that should be fulfill by the individual, nevertheless, it is also a task of managers to help their employees to find the right way, right motivations for an effective and efficient work.<br />
A clear picture of the expectations of individuals is presented by the “'''Vroom’s Expectancy Theory of Motivation'''”<ref>Costa, Gianecchini, Risorse Umane 4e, Slides from ‘Management of Human Resources’ bachelor’s course, University of Padova, 2020</ref>. This is a process theory of motivation, which says that an individual’s motivation is affected by their expectations about the future: people direct their efforts towards behaviors that lead to desirable rewards. The theory of expectations is a theory of decisions: people engage in rational decision, so firstly they think about the behavior they must adopt to get what they want and what the reward means to them. In order to understand what is the right motivation which lets the individual carry out a significant work effort, the individual must be intelligent from the emotional point of view and either the manager since they should provide a significant reward to facilitate and encourage individuals’ efforts. Let’s make an example: an insurance agent is notified that if in the following year he will obtain a turnover 10% higher than that of the previous year, he will be placed in the group of those who can obtain a promotion. The greater the stake, the greater the effort to obtain it. <br />
<br />
[[File:Vroom'sTheory.png|650px|thumb|left|How to calculate Motivation <ref> Difference between Expectation Theory and Equity Theory, December 9, 2015. Posted by Keth. https://www.differencebetween.com/difference-between-expectancy-theory-and-vs-equity-theory-2/ </ref>]]<br />
<br />
To dig deeper in the Vroom’s model, it is relevant saying that an individual’s motivation is product of three factor: <br />
* '''Valence''': the value that a person places on the reward they will be able to obtain and the consequences of his work. It can take on positive value (+1) if the worker prefers to get reward rather than not get it, or negative value (-1) if the worker prefers to avoid the consequences of work (toil, stress). <br />
* '''Expectancy''': the individual perception of the likelihood that the effort will lead to a certain level of performance. A worker will try harder if they evaluate the result achievable. It can take on a null value if there aren’t any possibility to fulfill the task or a positive value (+1) if, whatever it takes, the worker will be able to complete the task and get the expected result. <br />
* '''Instrumentality''': how much does a person believe that a high performance will match the expected rewards. The instrumentality varies between a maximum probability (1) if it is certain that once the worker reaches the goal, they will get the reward and a minimum probability (0) if there is no relationship between performance and reward. <br />
<br />
The product of these three factors will provide the '''Motivational Strength''' of the individual in fulfill a task: the higher the result (between 0 and 1), the stronger the motivation (e.g. a result equal to 1 indicates a strong motivation, while a result equal to 0 or 0.125 indicates a poor motivation)<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
===EI: Relation and Negotiation with Stakeholders===<br />
Another important aspect of the EI as a powerful tool to interact with others is '''Persuasion'''. Persuasion is defined as the ability to convince a person or other people of the value of a point of view or of the advantage they could derive from adopting a certain attitude, opinion, position. This is the reason why this aspect is certainly useful in establishing relations with stakeholders, especially in the negotiation phase. As an individual skill, there are behavioral indicators which should be followed to be effective: firstly, managers should try to convince the stakeholders by appealing to their interests (e.g., by pointing out what each one earns personally), managers should also try to convince them by trying to anticipate how they will react to an argument, request or situation and develop communication appropriate to the level of understanding or emotional state of the listeners. Finally, ask questions or knowingly uses techniques aimed at gaining emotional and rational consensus on certain ideas. This is how a manager should behave in an environment where everyone wants to feather one's own nest. <br />
To be fair, managing relations with stakeholders is not easy, indeed, there are several activities of identification, analysis, planning and implementation of actions designed to influence stakeholders, so-called Stakeholder Engagement. Limiting ourselves to the use of the EI, it could be interesting digging into the phase of “Strengthen the skills of the involvement”<ref> Krick T., Forstater M., Monaghan P., Sillanpää M. (2005). The Stakeholder Engagement Manual, Volume 2: The practitioner's handbook on Stakeholder Engagement, from https://stakeholderresearch.com/wp-content/uploads/sra-2005-words-to-action-stakeholder-engagement-02.pdf </ref>.<br />
This step aims to ensure that the company and its stakeholders have organizational systems and the capabilities to profitably engage in a fruitful relationship and, in addition, overcome obstacles that can hinder the desire to commit. This process requires a high level of EI from both parts, noticeable in three principles which provide a guidance for ensuring that stakeholder management supports the achievement of the organization’s reporting objective:<br />
*'''Relevance'''<br />
*'''Completeness''' <br />
*'''Responsiveness''' <br />
All of them make sure that the company and its employees are able to understand the concerns and expectations of stakeholders and preparing the company to respond to these. In addition, the “Inclusiveness” in the reporting commitment is also relevant, which means to be aware of the stakeholders’ right to be heard and report on their own stakeholder activities. <br />
<br />
[[File:3-skills-blog.png|550px|thumb|left|The Holy Trinity of Procurement Skills <ref>Shute, B. (October, 2019), The Holy Trinity of Procurement Skills, https://comprara.com.au/the-holy-trinity-of-procurement-skills/ </ref>]]<br />
<br />
The process of strengthening involvement skills develops in three steps, after which stakeholders and the company are ready for the involvement:<br />
* '''Strengthen the organizational capabilities of response'''<br />
* '''Take into consideration the limitations and needs of each specific stakeholder '''<br />
* '''Strengthen the skills of individuals '''<br />
<br />
Negotiation phase is part of the involvement, or better, the most important one. After knowing who the manager is dealing with, they must have a clear vision on which direction they are going to. Having a clear vision requires a good level of EI because it requires to identify which problems the manager is trying to solve, who they are trying to solve it for and what outcomes they want to meet. So, it’s all about an analysis of needs of the company, followed by in-depth knowledge. As a storyteller, the manager must orchestrate several characters to a conclusion, and a huge part of that is aligning them to certain outcomes. Shoot bad ideas down is important. In addition, managers should justify their position why they refused an idea in order to be clear and be understood by the stakeholders. <br />
What should not be missing in a relation with a third part is a clear communication, asking questions and acknowledgment: understand why stakeholders feel in a certain way and their needs.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
==Emotional Intelligence: Limitation in its Application <ref>"L'Intelligenza Emotiva è sempre positiva?" LinkedIn article by Simone Corel, 2020 </ref> <ref> "Emotional Intelligence Has 12 Elements. Which Do You Need to Work On?". Article by Daniel Goleman and Richard E. Boyatzis, February 06, 2017 </ref>==<br />
EI has always been classified as one of the greatest soft skills to own, however the use of it must be balanced, especially in a business environment. Since a person with a high level of EI is able to handle conflicts thanks to their ability to understand different points of view, they would be capable to give constructive negative feedbacks with the aim of healing a difficult situation in the most correct way possible. Being one hundred per cent honest is not always the easiest thing to do, since a person doesn’t know how people would react to their honesty and opinions. However, a person with a high ability to know how to manage the conflict, has the “power” to moderate their words with respect for the other and with empathy, but they won’t be always sure that the conflict management will always have positive implications, since everyone could have the willingness to control themselves, but doesn’t have much influence on others. <br />
<br />
Although the previous studies mentioned have highlighted the positive effects of having high levels of EI, some problems arise when a person over-develops their EI in a team context. This can lead to:<br />
<br />
* '''Low levels of creativity and openness to innovation''': There are negative correlations between EI and many traits that predispose to creativity and the pursuit of innovation. To be more specific, creativity has always been associated with low levels of EI, since it is an expression of nonconformity, impulsiveness, and excitement. Traits that seem to be contrary to those of EI characterized more by control and moderation. For that reason, people with high level of EI are usually less creative than the other. <br />
* '''Difficulty giving and receiving feedback''': High empathy and high sensitivity can lead people to have more difficulty in providing negative feedback to others, because they usually focus on transmitting positivity and optimism. This leads to avoiding giving pressure and criticism to others. In addition, high level of EI can be associated with greater indifference to negative feedback received, because it is viewed more as pointless criticism than constructive advice. <br />
* '''Reluctance to be unpopular''': It could happen that despite a person is solar, respectful, emphatic, and capable to handle interpersonal relations, that person wouldn’t become a high-level manager. This would happen because people with high level of EI do not know how to make unpopular decisions. They are so oriented towards making other people feel good and making them as productive as possible that they are unable to give negative feedback and take positions that often make the manager feel “alone”.<br />
* '''The risk of manipulation''': Understanding others is not that simple, however a high level of EI tends to improve this skill. The edge is very thin, and the ability to understand people could be used to manipulate them.<br />
* '''Risk aversion''': Every job has its share of risk. People with high EI tend to prefer the comfort zone. This is especially true when there are high levels of conscientiousness and low level of adaptability.<br />
<br />
To be clear, there is no doubt that emotional intelligent people are desirable employee, however a more in-depth investigation highlights how this aspect could lead to ineffective or inefficient behaviors in everyday working life .<br />
<br />
== Conclusion==<br />
EI is a very powerful tool and no-one can deny that having a teammates or a manager who is able to understand everyone's needs is a prerogative to work in a positive, effective and efficient environment. On the other hand, over-developing this soft skill can negatively affect the other, increasing pressure and conflicts. It is clear that it is better developing EI step by step in order to balance it according to the situation, rather than over-developing it in the initial stage, since it would be difficult to manage. However, it should be taken into account that there is no general rule which says that owning a high level of EI is mandatory to work effectively and in harmony with other people, it depends on too many factors. Indeed, many theories have been developed around this topic throughout decades and sometimes they contradict each other. Nevertheless, this article has followed the main path which psychology has shaped in the last thirty years.<br />
<br />
==Annotated Bibliography==<br />
<br />
'''Goleman, D.(1995). Emotional Intelligence: Why it can Matter more than IQ?'''. Provides useful insight into our "two minds"—the rational and the emotional—and how they together shape our destiny.<br />
<br />
<br />
'''Sy, T., Tram, S., and O’Hara, L. A. (2006). Relation of employee and manger emotional intelligence to job satisfaction and performance. In Journal of Vocational Behavior'''. Article which examines the relationships among employees’ emotional intelligence, their manager’s emotional intelligence, employees’ job satisfaction, and performance for 187 food service employees from nine different locations of the same restaurant franchise.<br />
<br />
<br />
'''Quoidbach, J & Hansenne, M. (2000). The impact of trait emotional intelligence on nursing team performance and cohesiveness. In Journal of Professional Nursing'''. Article that claims about the positive influence of emotional intelligence (EI) on work team performance are very numerous, both in commercial and scientific literature. <br />
<br />
<br />
'''Costa, Gianecchini, University of Padova (2020). Slides from "Management of Human Resources" bachelor course'''. Lecture Slides about individual and transversal skills in a business environment. <br />
<br />
<br />
'''Corel, S. (2020). L'intelligenza Emotiva è sempre positiva?'''. LinkedIn Article published to explain which negative aspects could arise from an overuse of EI. <br />
<br />
<br />
'''Goleman, D., Boyatzis, R.E. (2017). Emotional Intelligence Has 12 Elements. Which Do You Need to Work On?'''. Article which gives a 360-degree overview on which elements everyone should work on in order to improve their EI.<br />
<br />
<br />
'''Krick T., Forstater M., Monaghan P., Sillanpää M. (2005). The Stakeholder Engagement Manual, Volume 2: The practitioner's handbook on Stakeholder Engagement'''. Handbook which provides practical guidance, advice and signposts for further information to those interested in how to make stakeholder engagement more effective and beneficial for the organisation and its stakeholders.<br />
<br />
<br />
'''Paisley V., 5 Ways to Develop the Emotional Intelligence of Your Workforce (2018)'''. Article which highlights 5 effective ways to improve emotional intelligence skills.<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Emotional_Intelligence_in_a_Program,_Project_and_Portfolio_Management_View&diff=116252Emotional Intelligence in a Program, Project and Portfolio Management View2022-03-18T14:24:38Z<p>S212522: </p>
<hr />
<div>"Developed by Andrea Gatto"<br />
<br />
'''Summary'''<br />
<br />
The well-known American psychologist Daniel Goleman in his book “Emotional Intelligence”, published in 1995, defines the Emotional Intelligence as “the ability to recognize, understand and manage our own emotions and recognize, understand and influence the emotions of the others”<ref name="Ref6">Goleman, D. (1995). Emotional Intelligence </ref>. <br />
Indeed, EI belongs to the large group of soft skills, also called behavior skills, which are a prerogative to be flexible and adaptable to any environment, especially in a business environment, where interactions with colleagues and stakeholders are on the agenda.<br />
Is it possible that someone selected for a job position through classic tests is not actually able to handle it? it could be: self-control, stubbornness, empathy, and attention to the others are fundamental to work effectively in a shared environment. Indeed, the purpose of this article is to provide an overview of the importance of the EI within team projects, individual tasks and relations with stakeholders, especially from a psychological point of view.<br />
<br />
==Emotional Intelligence and its Application==<br />
<br />
EI, as an individual and soft skill, can be applied in different contexts. Since it is a skill that every person should develop and train to make the most of it, in the first paragraphs it will be addressed from the point of view of the people who are working in a group project, then moving on the concept of EI used as an effective tool for stakeholder negotiation and limitations in its application.<br />
<br />
===EI in team projects===<br />
<br />
Why EI can be matter more than IQ? Interesting question, isn't it? In order to answer it, it would be wise to analyze the behavior of individuals in carrying out corporate activities or, even better, group activities.<br />
Sy, Tram and O'Hara, professors of the Department of Psychology at the University of California, suggested in their research that there is a positive relationship between job performance and team members having high level of EI, because they are highly proficient at appraising and regulating their own emotions, which results in a higher level of faith in themselves and have power over them, which lead to make realistic actions resulting in high performance and less supervisory interference <ref> Sy, T., Tram, S., and O’Hara, L. A. (2006). Relation of employee and manger EI to job satisfaction and performance. In Journal of Vocational Behavior, 68, 461-473. Retrieved April 02, 2010, from http://www.emeraldinsight.com </ref>.<br />
On the other hand, it is logical thinking about that team members with low level of EI are less skilled at appraising and regulating their emotions, so they need to be supervised and helped by managers to better control their feelings, improving so the coordination and adaptability within the working team. <br />
Another ability included in EI is the use of emotions, or the individual skill addressed to aid the cognitive processes. The right use of emotions can be a very useful tool to expand the flexibility of information processing or pick out among corresponding alternatives. Therefore, individuals differ not only in the ability to understand and express their emotions, but also in their ability to use emotions in collaboration with their cognitive processes to heighten fruitful operating. It seems to be clear that individuals, who struggle with the right use of EI linked to cognitive processes, are less likely to coordinate themselves in a group environment, being less able to fulfill the assigned task <ref>Zhou, J., George, J. M. (2003). Awakening employee creativity: The role of leader emotional intelligence. Leadership Quarterly, 14, 545 – 568</ref>. <br />
In addition to that, the other milestone comprised into EI is the regulation of the emotions of the people: individuals should focus on that aspect because it is extremely important to keep the balance between all the members involved in a project, for a better coordination, chemistry within the group and consequently for better outputs. For instance, if there occur any breach in quality, it may raise up a negative emotion reaction when the manager tries to understand the cause of the problem. However, managing that negative emotion, trying to effectively solve the problem, instead of just complaining or blaming someone, is fundamental. Handling emotional reactions leads to understand where the focus of interest is, avoiding disruptive conflicts and misunderstandings.<br />
<br />
[[File:sustainability-11-0-2299-g001.png|650px|thumb|left|Handling emotions for job performances <ref>Nhu Ngoc Nguyen, Phong Tuan Nham and Yoshi Takahashi. Relationship between Ability-Based Emotional Intelligence, Cognitive Intelligence, and Job Performance. https://www.mdpi.com/2071-1050/11/8/2299</ref>]]<br />
<br />
EI is a value that can be developed, trained, and achieved with a certain maturity. Nevertheless, as soon as the activities become more demanding and the workload increases, emotions are put to the test. Who knows how to stay motivated under stress, motivate others and manage complex interpersonal relationships, will get better result <ref>Goleman, D. (2005). Emotional Intelligence. (10th Ed). New York: Bantam Books</ref>. <br />
Though there are many studies and research regarding the improvement of job performances through a right use of EI, it seems that on individual level there would be no significant results. Indeed, few studies have investigated the relationships between EI and performance at group level are more relevant: Jordan and Troth (2002) have found a link between EI and performance on a purely cognitive task at group level. According to these authors, the ability to deal with one’s own emotions, allows team members to be more inclined to listen to others’ points of view and to seek superior solutions, without thinking of being wrong. Moreover, they found out that teams with a high level of EI have preference for collaborative conflict resolution strategies, unlike teams with low level of EI <ref>Quoidbach, J & Hansenne, M. (2000). The impact of trait emotional intelligence on nursing team performance and cohesiveness. In Journal of Professional Nursing, 25(1), 23–29. Retrieved March 02, 2010, from http://www.emeraldinsight.com</ref>.<br />
<br />
<br />
<br />
All these aspects are relevant to understand the importance of developing these skills, not focusing just on classic tests but much more on individual mental growth.<br />
<br />
====Practical advice to improve EI <ref> Paisley V., 5 Ways to Develop the Emotional Intelligence of Your Workforce (2018) from https://www.learnlight.com/en/articles/5-ways-to-develop-emotional-intelligence-of-your-workforce/</ref>====<br />
To work better in a team, managers look for people who strive to be flexible and put the team's good before their own interests. This is the reason why the individual contribution is extremely important within a project group, so that everyone could follow five steps which would allow people to be more understandable towards colleagues:<br />
* '''Stop and think about feelings''': as it is stated above, EI starts with self and social awareness. Through this, people do not let feelings rule their behavior. In order to do so, managers should encourage employees to ask themselves reflective questions, such as "What are my emotional strengths and weaknesses?" or "How does my current state of mind influence my thoughts and decision-making?", which reveal valuable insights that can be used to develop new interpersonal skills and, over time, intercept negative influences, enhancing positivity.<br />
* '''Show empathy towards other''': empathy is the skill which allows people to recognize their and other's feelings. So people should strive to understand other's viewpoints in order to build deeper connections with colleagues, helpful when a person is dealing with someone who is challenging to work with.<br />
*'''Listen to understand and not to answer''': patience is a key of developing a right EI attitude; listening is a valuable competence and even though a person does't agree with a colleague, it is important to acknowledge what they are saying in order to establish trust and rapport.<br />
*'''See challenges and criticism as a learning opportunity''': being positive is fundamental in every situation, so for a manager it would be useful to encourage employees to look at how they deal with criticism and push them to deal with the feedback in a positive way. This would help the individuals to learn from their mistakes and how they might deal with a similar situation in the future. Over time, the person will be able to motivate themselves more easily and respond well to challenge.<br />
*'''Manage relationships well''': the last step, after working hard on the previous ones, leads the individual to communicate effectively, deal with conflict more smoothly and encourage more trust in colleagues. <br />
<br />
The sooner people begin to work on themself, the sooner they foster effective and efficient work.<br />
<br />
===EI: Individual Effort and Motivation===<br />
<br />
In addition to being characterized by social skills such as empathy and construction of relational networks as it is stated above, EI is characterized by personal skills such as self-awareness, self-control and understanding of one’s motivation. This is clear that is a task that should be fulfill by the individual, nevertheless, it is also a task of managers to help their employees to find the right way, right motivations for an effective and efficient work.<br />
A clear picture of the expectations of individuals is presented by the “'''Vroom’s Expectancy Theory of Motivation'''”<ref>Costa, Gianecchini, Risorse Umane 4e, Slides from ‘Management of Human Resources’ bachelor’s course, University of Padova, 2020</ref>. This is a process theory of motivation, which says that an individual’s motivation is affected by their expectations about the future: people direct their efforts towards behaviors that lead to desirable rewards. The theory of expectations is a theory of decisions: people engage in rational decision, so firstly they think about the behavior they must adopt to get what they want and what the reward means to them. In order to understand what is the right motivation which lets the individual carry out a significant work effort, the individual must be intelligent from the emotional point of view and either the manager since they should provide a significant reward to facilitate and encourage individuals’ efforts. Let’s make an example: an insurance agent is notified that if in the following year he will obtain a turnover 10% higher than that of the previous year, he will be placed in the group of those who can obtain a promotion. The greater the stake, the greater the effort to obtain it. <br />
<br />
[[File:Vroom'sTheory.png|650px|thumb|left|How to calculate Motivation <ref> Difference between Expectation Theory and Equity Theory, December 9, 2015. Posted by Keth. https://www.differencebetween.com/difference-between-expectancy-theory-and-vs-equity-theory-2/ </ref>]]<br />
<br />
To dig deeper in the Vroom’s model, it is relevant saying that an individual’s motivation is product of three factor: <br />
* '''Valence''': the value that a person places on the reward they will be able to obtain and the consequences of his work. It can take on positive value (+1) if the worker prefers to get reward rather than not get it, or negative value (-1) if the worker prefers to avoid the consequences of work (toil, stress). <br />
* '''Expectancy''': the individual perception of the likelihood that the effort will lead to a certain level of performance. A worker will try harder if they evaluate the result achievable. It can take on a null value if there aren’t any possibility to fulfill the task or a positive value (+1) if, whatever it takes, the worker will be able to complete the task and get the expected result. <br />
* '''Instrumentality''': how much does a person believe that a high performance will match the expected rewards. The instrumentality varies between a maximum probability (1) if it is certain that once the worker reaches the goal, they will get the reward and a minimum probability (0) if there is no relationship between performance and reward. <br />
<br />
The product of these three factors will provide the '''Motivational Strength''' of the individual in fulfill a task: the higher the result (between 0 and 1), the stronger the motivation (e.g. a result equal to 1 indicates a strong motivation, while a result equal to 0 or 0.125 indicates a poor motivation)<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
===EI: Relation and Negotiation with Stakeholders===<br />
Another important aspect of the EI as a powerful tool to interact with others is '''Persuasion'''. Persuasion is defined as the ability to convince a person or other people of the value of a point of view or of the advantage they could derive from adopting a certain attitude, opinion, position. This is the reason why this aspect is certainly useful in establishing relations with stakeholders, especially in the negotiation phase. As an individual skill, there are behavioral indicators which should be followed to be effective: firstly, managers should try to convince the stakeholders by appealing to their interests (e.g., by pointing out what each one earns personally), managers should also try to convince them by trying to anticipate how they will react to an argument, request or situation and develop communication appropriate to the level of understanding or emotional state of the listeners. Finally, ask questions or knowingly uses techniques aimed at gaining emotional and rational consensus on certain ideas. This is how a manager should behave in an environment where everyone wants to feather one's own nest. <br />
To be fair, managing relations with stakeholders is not easy, indeed, there are several activities of identification, analysis, planning and implementation of actions designed to influence stakeholders, so-called Stakeholder Engagement. Limiting ourselves to the use of the EI, it could be interesting digging into the phase of “Strengthen the skills of the involvement”<ref> Krick T., Forstater M., Monaghan P., Sillanpää M. (2005). The Stakeholder Engagement Manual, Volume 2: The practitioner's handbook on Stakeholder Engagement, from https://stakeholderresearch.com/wp-content/uploads/sra-2005-words-to-action-stakeholder-engagement-02.pdf </ref>.<br />
This step aims to ensure that the company and its stakeholders have organizational systems and the capabilities to profitably engage in a fruitful relationship and, in addition, overcome obstacles that can hinder the desire to commit. This process requires a high level of EI from both parts, noticeable in three principles which provide a guidance for ensuring that stakeholder management supports the achievement of the organization’s reporting objective:<br />
*'''Relevance'''<br />
*'''Completeness''' <br />
*'''Responsiveness''' <br />
All of them make sure that the company and its employees are able to understand the concerns and expectations of stakeholders and preparing the company to respond to these. In addition, the “Inclusiveness” in the reporting commitment is also relevant, which means to be aware of the stakeholders’ right to be heard and report on their own stakeholder activities. <br />
<br />
[[File:3-skills-blog.png|550px|thumb|left|The Holy Trinity of Procurement Skills <ref>Shute, B. (October, 2019), The Holy Trinity of Procurement Skills, https://comprara.com.au/the-holy-trinity-of-procurement-skills/ </ref>]]<br />
<br />
The process of strengthening involvement skills develops in three steps, after which stakeholders and the company are ready for the involvement:<br />
* '''Strengthen the organizational capabilities of response'''<br />
* '''Take into consideration the limitations and needs of each specific stakeholder '''<br />
* '''Strengthen the skills of individuals '''<br />
<br />
Negotiation phase is part of the involvement, or better, the most important one. After knowing who the manager is dealing with, they must have a clear vision on which direction they are going to. Having a clear vision requires a good level of EI because it requires to identify which problems the manager is trying to solve, who they are trying to solve it for and what outcomes they want to meet. So, it’s all about an analysis of needs of the company, followed by in-depth knowledge. As a storyteller, the manager must orchestrate several characters to a conclusion, and a huge part of that is aligning them to certain outcomes. Shoot bad ideas down is important. In addition, managers should justify their position why they refused an idea in order to be clear and be understood by the stakeholders. <br />
What should not be missing in a relation with a third part is a clear communication, asking questions and acknowledgment: understand why stakeholders feel in a certain way and their needs.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
==Emotional Intelligence: Limitation in its Application <ref>"L'Intelligenza Emotiva è sempre positiva?" LinkedIn article by Simone Corel, 2020 </ref> <ref> "Emotional Intelligence Has 12 Elements. Which Do You Need to Work On?". Article by Daniel Goleman and Richard E. Boyatzis, February 06, 2017 </ref>==<br />
EI has always been classified as one of the greatest soft skills to own, however the use of it must be balanced, especially in a business environment. Since a person with a high level of EI is able to handle conflicts thanks to their ability to understand different points of view, they would be capable to give constructive negative feedbacks with the aim of healing a difficult situation in the most correct way possible. Being one hundred per cent honest is not always the easiest thing to do, since a person doesn’t know how people would react to their honesty and opinions. However, a person with a high ability to know how to manage the conflict, has the “power” to moderate their words with respect for the other and with empathy, but they won’t be always sure that the conflict management will always have positive implications, since everyone could have the willingness to control themselves, but doesn’t have much influence on others. <br />
<br />
Although the previous studies mentioned have highlighted the positive effects of having high levels of EI, some problems arise when a person over-develops their EI in a team context. This can lead to:<br />
<br />
* '''Low levels of creativity and openness to innovation''': There are negative correlations between EI and many traits that predispose to creativity and the pursuit of innovation. To be more specific, creativity has always been associated with low levels of EI, since it is an expression of nonconformity, impulsiveness, and excitement. Traits that seem to be contrary to those of EI characterized more by control and moderation. For that reason, people with high level of EI are usually less creative than the other. <br />
* '''Difficulty giving and receiving feedback''': High empathy and high sensitivity can lead people to have more difficulty in providing negative feedback to others, because they usually focus on transmitting positivity and optimism. This leads to avoiding giving pressure and criticism to others. In addition, high level of EI can be associated with greater indifference to negative feedback received, because it is viewed more as pointless criticism than constructive advice. <br />
* '''Reluctance to be unpopular''': It could happen that despite a person is solar, respectful, emphatic, and capable to handle interpersonal relations, that person wouldn’t become a high-level manager. This would happen because people with high level of EI do not know how to make unpopular decisions. They are so oriented towards making other people feel good and making them as productive as possible that they are unable to give negative feedback and take positions that often make the manager feel “alone”.<br />
* '''The risk of manipulation''': Understanding others is not that simple, however a high level of EI tends to improve this skill. The edge is very thin, and the ability to understand people could be used to manipulate them.<br />
* '''Risk aversion''': Every job has its share of risk. People with high EI tend to prefer the comfort zone. This is especially true when there are high levels of conscientiousness and low level of adaptability.<br />
<br />
To be clear, there is no doubt that emotional intelligent people are desirable employee, however a more in-depth investigation highlights how this aspect could lead to ineffective or inefficient behaviors in everyday working life .<br />
<br />
== Conclusion==<br />
EI is a very powerful tool and no-one can deny that having a teammates or a manager who is able to understand everyone's needs is a prerogative to work in a positive, effective and efficient environment. On the other hand, over-developing this soft skill can negatively affect the other, increasing pressure and conflicts. It is clear that it is better developing EI step by step in order to balance it according to the situation, rather than over-developing it in the initial stage, since it would be difficult to manage. However, it should be taken into account that there is no general rule which says that owning a high level of EI is mandatory to work effectively and in harmony with other people, it depends on too many factors. Indeed, many theories have been developed around this topic throughout decades and sometimes they contradict each other. Nevertheless, this article has followed the main path which psychology has shaped in the last thirty years.<br />
<br />
==Annotated Bibliography==<br />
<br />
'''Goleman, D.(1995). Emotional Intelligence: Why it can Matter more than IQ?'''. Provides useful insight into our "two minds"—the rational and the emotional—and how they together shape our destiny.<br />
<br />
<br />
'''Sy, T., Tram, S., and O’Hara, L. A. (2006). Relation of employee and manger emotional intelligence to job satisfaction and performance. In Journal of Vocational Behavior'''. Article which examines the relationships among employees’ emotional intelligence, their manager’s emotional intelligence, employees’ job satisfaction, and performance for 187 food service employees from nine different locations of the same restaurant franchise.<br />
<br />
<br />
'''Quoidbach, J & Hansenne, M. (2000). The impact of trait emotional intelligence on nursing team performance and cohesiveness. In Journal of Professional Nursing'''. Article that claims about the positive influence of emotional intelligence (EI) on work team performance are very numerous, both in commercial and scientific literature. <br />
<br />
<br />
'''Costa, Gianecchini, University of Padova (2020). Slides from "Management of Human Resources" bachelor course'''. Lecture Slides about individual and transversal skills in a business environment. <br />
<br />
<br />
'''Corel, S. (2020). L'intelligenza Emotiva è sempre positiva?'''. LinkedIn Article published to explain which negative aspects could arise from an overuse of EI. <br />
<br />
<br />
'''Goleman, D., Boyatzis, R.E. (2017). Emotional Intelligence Has 12 Elements. Which Do You Need to Work On?'''. Article which gives a 360-degree overview on which elements everyone should work on in order to improve their EI.<br />
<br />
<br />
'''Krick T., Forstater M., Monaghan P., Sillanpää M. (2005). The Stakeholder Engagement Manual, Volume 2: The practitioner's handbook on Stakeholder Engagement'''. Handbook which provides practical guidance, advice and signposts for further information to those interested in how to make stakeholder engagement more effective and beneficial for the organisation and its stakeholders.<br />
<br />
<br />
'''Paisley V., 5 Ways to Develop the Emotional Intelligence of Your Workforce (2018)'''. Article which highlights 5 effective ways to improve emotional intelligence skills.<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116247Waterfall model2022-03-18T14:20:12Z<p>S212522: </p>
<hr />
<div>'''Summary'''<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
<br />
'''1- Requirements'''<br />
<br />
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 [2].<br />
<br />
'''2- Analysis'''<br />
<br />
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.<br />
<br />
'''3- Design'''<br />
<br />
From the specifications, the functions and requirements are transformed into a feasible product. The product is specified and its architecture is designed [11].<br />
<br />
'''4- Implementation'''<br />
<br />
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].<br />
<br />
'''5- Testing and Validation'''<br />
<br />
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.<br />
<br />
'''6- Release'''<br />
<br />
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>.<br />
<br />
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.<br />
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.<br />
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].<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why<br />
it has been and still is massively used.<br />
<br />
'''Simplicity'''<br />
<br />
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<br />
resources and management knowledge to follow the model [11].<br />
<br />
'''Consistency'''<br />
<br />
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<br />
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>.<br />
<br />
'''Control'''<br />
<br />
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<br />
are only made between adjacent phases, which limits changes [1].<br />
'''When to use Waterfall Model ?'''<br />
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<br />
in very large projects the Waterfall Model should be chosen for its advantages [8].<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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<br />
change<ref>Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009</ref>[8].<br />
<br />
'''A high risk model'''<br />
<br />
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<br />
<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].<br />
<br />
'''High costs and efforts'''<br />
<br />
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<br />
well as an overrun of the planned dates<ref>Kai Petersen et al., The Waterfall Model in Large-Scale Development, 2009</ref>.<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
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<br />
and other Unified Processes (needs a link to these two methods).<br />
<br />
'''Agile methods'''<br />
<br />
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<br />
short cycles with dynamic planning and prioritization.<br />
<br />
'''When to use which'''<br />
<br />
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<br />
whether a project should be structured according to a Waterfall Model or agile:<br />
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<br />
responsiveness to change[5].<br />
* 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.<br />
* 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.<br />
* Culture: Generally speaking, the Waterfall Model will better adapt to a company cultivating values of order and rigor while Agile methods thrive on chaos.<br />
<br />
==Conclusion==<br />
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.<br />
<br />
==Annotated bibliography==<br />
<br />
To go deeper into details it is suggested to look further into those three articles:<br />
<br />
'''[1] W.W. Royce, Managing the Development of Large Software Systems'''<br />
<br />
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.<br />
<br />
'''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>'''<br />
<br />
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.<br />
<br />
'''[9] Ilya Bibik, How To Kill the Scrum Monster'''<br />
<br />
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.<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116246Waterfall model2022-03-18T14:18:19Z<p>S212522: /* Description of the model in phases */</p>
<hr />
<div>'''Summary'''<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
<br />
'''1- Requirements'''<br />
<br />
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 [2].<br />
<br />
'''2- Analysis'''<br />
<br />
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.<br />
<br />
'''3- Design'''<br />
<br />
From the specifications, the functions and requirements are transformed into a feasible product. The product is specified and its architecture is designed [11].<br />
<br />
'''4- Implementation'''<br />
<br />
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].<br />
<br />
'''5- Testing and Validation'''<br />
<br />
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.<br />
<br />
'''6- Release'''<br />
<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used [6].<br />
<br />
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.<br />
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.<br />
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].<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why<br />
it has been and still is massively used.<br />
<br />
'''Simplicity'''<br />
<br />
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<br />
resources and management knowledge to follow the model [11].<br />
<br />
'''Consistency'''<br />
<br />
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<br />
both for the smooth running of the work and for future projects [2][6].<br />
<br />
'''Control'''<br />
<br />
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 [6]. 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<br />
are only made between adjacent phases, which limits changes [1].<br />
'''When to use Waterfall Model ?'''<br />
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<br />
in very large projects the Waterfall Model should be chosen for its advantages [8].<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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 [6]. 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<br />
change [6][8].<br />
<br />
'''A high risk model'''<br />
<br />
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 [6], 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<br />
[6], "then invariably a major redesign is required" adds W.W. Royce [1].<br />
<br />
'''High costs and efforts'''<br />
<br />
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 [6]. Similarly, iterations and rollbacks of previous phases are costly in terms of team effort [6][11]. Finally, in the case of major substantive problems encountered in the final phase, additional costs are obviously to be expected, as<br />
well as an overrun of the planned dates [6].<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
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<br />
and other Unified Processes (needs a link to these two methods).<br />
<br />
'''Agile methods'''<br />
<br />
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<br />
short cycles with dynamic planning and prioritization.<br />
<br />
'''When to use which'''<br />
<br />
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<br />
whether a project should be structured according to a Waterfall Model or agile:<br />
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<br />
responsiveness to change[5].<br />
* 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.<br />
* 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.<br />
* Culture: Generally speaking, the Waterfall Model will better adapt to a company cultivating values of order and rigor while Agile methods thrive on chaos.<br />
<br />
==Conclusion==<br />
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.<br />
<br />
==Annotated bibliography==<br />
<br />
To go deeper into details it is suggested to look further into those three articles:<br />
<br />
'''[1] W.W. Royce, Managing the Development of Large Software Systems'''<br />
<br />
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.<br />
<br />
'''[6] Kai Petersen et al, The Waterfall Model in Large-Scale Development, 2009'''<br />
<br />
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.<br />
<br />
'''[9] Ilya Bibik, How To Kill the Scrum Monster'''<br />
<br />
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.<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116245Waterfall model2022-03-18T14:17:09Z<p>S212522: /* Annotated bibliography */</p>
<hr />
<div>'''Summary'''<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
<br />
'''1- Requirements'''<br />
<br />
This phase corresponds to the expression of needs [6]. 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].<br />
<br />
'''2- Analysis'''<br />
<br />
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.<br />
<br />
'''3- Design'''<br />
<br />
From the specifications, the functions and requirements are transformed into a feasible product. The product is specified and its architecture is designed [11].<br />
<br />
'''4- Implementation'''<br />
<br />
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].<br />
<br />
'''5- Testing and Validation'''<br />
<br />
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.<br />
<br />
'''6- Release'''<br />
<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used [6].<br />
<br />
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.<br />
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.<br />
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].<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why<br />
it has been and still is massively used.<br />
<br />
'''Simplicity'''<br />
<br />
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<br />
resources and management knowledge to follow the model [11].<br />
<br />
'''Consistency'''<br />
<br />
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<br />
both for the smooth running of the work and for future projects [2][6].<br />
<br />
'''Control'''<br />
<br />
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 [6]. 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<br />
are only made between adjacent phases, which limits changes [1].<br />
'''When to use Waterfall Model ?'''<br />
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<br />
in very large projects the Waterfall Model should be chosen for its advantages [8].<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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 [6]. 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<br />
change [6][8].<br />
<br />
'''A high risk model'''<br />
<br />
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 [6], 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<br />
[6], "then invariably a major redesign is required" adds W.W. Royce [1].<br />
<br />
'''High costs and efforts'''<br />
<br />
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 [6]. Similarly, iterations and rollbacks of previous phases are costly in terms of team effort [6][11]. Finally, in the case of major substantive problems encountered in the final phase, additional costs are obviously to be expected, as<br />
well as an overrun of the planned dates [6].<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
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<br />
and other Unified Processes (needs a link to these two methods).<br />
<br />
'''Agile methods'''<br />
<br />
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<br />
short cycles with dynamic planning and prioritization.<br />
<br />
'''When to use which'''<br />
<br />
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<br />
whether a project should be structured according to a Waterfall Model or agile:<br />
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<br />
responsiveness to change[5].<br />
* 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.<br />
* 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.<br />
* Culture: Generally speaking, the Waterfall Model will better adapt to a company cultivating values of order and rigor while Agile methods thrive on chaos.<br />
<br />
==Conclusion==<br />
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.<br />
<br />
==Annotated bibliography==<br />
<br />
To go deeper into details it is suggested to look further into those three articles:<br />
<br />
'''[1] W.W. Royce, Managing the Development of Large Software Systems'''<br />
<br />
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.<br />
<br />
'''[6] Kai Petersen et al, The Waterfall Model in Large-Scale Development, 2009'''<br />
<br />
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.<br />
<br />
'''[9] Ilya Bibik, How To Kill the Scrum Monster'''<br />
<br />
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.<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116243Waterfall model2022-03-18T14:16:14Z<p>S212522: /* Conclusion */</p>
<hr />
<div>'''Summary'''<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
<br />
'''1- Requirements'''<br />
<br />
This phase corresponds to the expression of needs [6]. 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].<br />
<br />
'''2- Analysis'''<br />
<br />
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.<br />
<br />
'''3- Design'''<br />
<br />
From the specifications, the functions and requirements are transformed into a feasible product. The product is specified and its architecture is designed [11].<br />
<br />
'''4- Implementation'''<br />
<br />
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].<br />
<br />
'''5- Testing and Validation'''<br />
<br />
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.<br />
<br />
'''6- Release'''<br />
<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used [6].<br />
<br />
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.<br />
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.<br />
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].<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why<br />
it has been and still is massively used.<br />
<br />
'''Simplicity'''<br />
<br />
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<br />
resources and management knowledge to follow the model [11].<br />
<br />
'''Consistency'''<br />
<br />
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<br />
both for the smooth running of the work and for future projects [2][6].<br />
<br />
'''Control'''<br />
<br />
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 [6]. 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<br />
are only made between adjacent phases, which limits changes [1].<br />
'''When to use Waterfall Model ?'''<br />
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<br />
in very large projects the Waterfall Model should be chosen for its advantages [8].<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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 [6]. 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<br />
change [6][8].<br />
<br />
'''A high risk model'''<br />
<br />
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 [6], 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<br />
[6], "then invariably a major redesign is required" adds W.W. Royce [1].<br />
<br />
'''High costs and efforts'''<br />
<br />
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 [6]. Similarly, iterations and rollbacks of previous phases are costly in terms of team effort [6][11]. Finally, in the case of major substantive problems encountered in the final phase, additional costs are obviously to be expected, as<br />
well as an overrun of the planned dates [6].<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
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<br />
and other Unified Processes (needs a link to these two methods).<br />
<br />
'''Agile methods'''<br />
<br />
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<br />
short cycles with dynamic planning and prioritization.<br />
<br />
'''When to use which'''<br />
<br />
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<br />
whether a project should be structured according to a Waterfall Model or agile:<br />
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<br />
responsiveness to change[5].<br />
* 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.<br />
* 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.<br />
* Culture: Generally speaking, the Waterfall Model will better adapt to a company cultivating values of order and rigor while Agile methods thrive on chaos.<br />
<br />
==Conclusion==<br />
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.<br />
<br />
==Annotated bibliography==<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116242Waterfall model2022-03-18T14:15:49Z<p>S212522: /* Comparison Waterfall / Agile */</p>
<hr />
<div>'''Summary'''<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
<br />
'''1- Requirements'''<br />
<br />
This phase corresponds to the expression of needs [6]. 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].<br />
<br />
'''2- Analysis'''<br />
<br />
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.<br />
<br />
'''3- Design'''<br />
<br />
From the specifications, the functions and requirements are transformed into a feasible product. The product is specified and its architecture is designed [11].<br />
<br />
'''4- Implementation'''<br />
<br />
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].<br />
<br />
'''5- Testing and Validation'''<br />
<br />
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.<br />
<br />
'''6- Release'''<br />
<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used [6].<br />
<br />
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.<br />
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.<br />
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].<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why<br />
it has been and still is massively used.<br />
<br />
'''Simplicity'''<br />
<br />
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<br />
resources and management knowledge to follow the model [11].<br />
<br />
'''Consistency'''<br />
<br />
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<br />
both for the smooth running of the work and for future projects [2][6].<br />
<br />
'''Control'''<br />
<br />
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 [6]. 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<br />
are only made between adjacent phases, which limits changes [1].<br />
'''When to use Waterfall Model ?'''<br />
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<br />
in very large projects the Waterfall Model should be chosen for its advantages [8].<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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 [6]. 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<br />
change [6][8].<br />
<br />
'''A high risk model'''<br />
<br />
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 [6], 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<br />
[6], "then invariably a major redesign is required" adds W.W. Royce [1].<br />
<br />
'''High costs and efforts'''<br />
<br />
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 [6]. Similarly, iterations and rollbacks of previous phases are costly in terms of team effort [6][11]. Finally, in the case of major substantive problems encountered in the final phase, additional costs are obviously to be expected, as<br />
well as an overrun of the planned dates [6].<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
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<br />
and other Unified Processes (needs a link to these two methods).<br />
<br />
'''Agile methods'''<br />
<br />
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<br />
short cycles with dynamic planning and prioritization.<br />
<br />
'''When to use which'''<br />
<br />
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<br />
whether a project should be structured according to a Waterfall Model or agile:<br />
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<br />
responsiveness to change[5].<br />
* 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.<br />
* 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.<br />
* Culture: Generally speaking, the Waterfall Model will better adapt to a company cultivating values of order and rigor while Agile methods thrive on chaos.<br />
<br />
==Conclusion==<br />
==Annotated bibliography==<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116241Waterfall model2022-03-18T14:15:35Z<p>S212522: /* Comparison Waterfall / Agile */</p>
<hr />
<div>'''Summary'''<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
<br />
'''1- Requirements'''<br />
<br />
This phase corresponds to the expression of needs [6]. 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].<br />
<br />
'''2- Analysis'''<br />
<br />
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.<br />
<br />
'''3- Design'''<br />
<br />
From the specifications, the functions and requirements are transformed into a feasible product. The product is specified and its architecture is designed [11].<br />
<br />
'''4- Implementation'''<br />
<br />
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].<br />
<br />
'''5- Testing and Validation'''<br />
<br />
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.<br />
<br />
'''6- Release'''<br />
<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used [6].<br />
<br />
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.<br />
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.<br />
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].<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why<br />
it has been and still is massively used.<br />
<br />
'''Simplicity'''<br />
<br />
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<br />
resources and management knowledge to follow the model [11].<br />
<br />
'''Consistency'''<br />
<br />
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<br />
both for the smooth running of the work and for future projects [2][6].<br />
<br />
'''Control'''<br />
<br />
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 [6]. 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<br />
are only made between adjacent phases, which limits changes [1].<br />
'''When to use Waterfall Model ?'''<br />
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<br />
in very large projects the Waterfall Model should be chosen for its advantages [8].<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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 [6]. 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<br />
change [6][8].<br />
<br />
'''A high risk model'''<br />
<br />
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 [6], 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<br />
[6], "then invariably a major redesign is required" adds W.W. Royce [1].<br />
<br />
'''High costs and efforts'''<br />
<br />
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 [6]. Similarly, iterations and rollbacks of previous phases are costly in terms of team effort [6][11]. Finally, in the case of major substantive problems encountered in the final phase, additional costs are obviously to be expected, as<br />
well as an overrun of the planned dates [6].<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
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<br />
and other Unified Processes (needs a link to these two methods).<br />
<br />
'''Agile methods'''<br />
<br />
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<br />
short cycles with dynamic planning and prioritization.<br />
<br />
'''When to use which'''<br />
<br />
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<br />
whether a project should be structured according to a Waterfall Model or agile:<br />
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<br />
responsiveness to change[5].<br />
* Customer: Agile adapts to cases where the customer is deeply involved in the development, which can be associated and knowledgeable, while the Waterfall Model<br />
requires adequately skilled customers.<br />
* 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.<br />
* Culture: Generally speaking, the Waterfall Model will better adapt to a company cultivating values of order and rigor while Agile methods thrive on chaos.<br />
<br />
==Conclusion==<br />
==Annotated bibliography==<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116240Waterfall model2022-03-18T14:15:27Z<p>S212522: /* Comparison Waterfall / Agile */</p>
<hr />
<div>'''Summary'''<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
<br />
'''1- Requirements'''<br />
<br />
This phase corresponds to the expression of needs [6]. 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].<br />
<br />
'''2- Analysis'''<br />
<br />
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.<br />
<br />
'''3- Design'''<br />
<br />
From the specifications, the functions and requirements are transformed into a feasible product. The product is specified and its architecture is designed [11].<br />
<br />
'''4- Implementation'''<br />
<br />
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].<br />
<br />
'''5- Testing and Validation'''<br />
<br />
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.<br />
<br />
'''6- Release'''<br />
<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used [6].<br />
<br />
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.<br />
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.<br />
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].<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why<br />
it has been and still is massively used.<br />
<br />
'''Simplicity'''<br />
<br />
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<br />
resources and management knowledge to follow the model [11].<br />
<br />
'''Consistency'''<br />
<br />
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<br />
both for the smooth running of the work and for future projects [2][6].<br />
<br />
'''Control'''<br />
<br />
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 [6]. 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<br />
are only made between adjacent phases, which limits changes [1].<br />
'''When to use Waterfall Model ?'''<br />
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<br />
in very large projects the Waterfall Model should be chosen for its advantages [8].<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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 [6]. 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<br />
change [6][8].<br />
<br />
'''A high risk model'''<br />
<br />
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 [6], 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<br />
[6], "then invariably a major redesign is required" adds W.W. Royce [1].<br />
<br />
'''High costs and efforts'''<br />
<br />
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 [6]. Similarly, iterations and rollbacks of previous phases are costly in terms of team effort [6][11]. Finally, in the case of major substantive problems encountered in the final phase, additional costs are obviously to be expected, as<br />
well as an overrun of the planned dates [6].<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
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<br />
and other Unified Processes (needs a link to these two methods).<br />
<br />
'''Agile methods'''<br />
<br />
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<br />
short cycles with dynamic planning and prioritization.<br />
<br />
'''When to use which'''<br />
<br />
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<br />
whether a project should be structured according to a Waterfall Model or agile:<br />
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<br />
responsiveness to change[5].<br />
* Customer: Agile adapts to cases where the customer is deeply involved in the development, which can be associated and knowledgeable, while the Waterfall Model<br />
requires adequately skilled customers.<br />
* 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.<br />
* Culture: Generally speaking, the Waterfall Model will better adapt to a company<br />
cultivating values of order and rigor while Agile methods thrive on chaos.<br />
<br />
==Conclusion==<br />
==Annotated bibliography==<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116239Waterfall model2022-03-18T14:14:58Z<p>S212522: /* Comparison Waterfall / Agile */</p>
<hr />
<div>'''Summary'''<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
<br />
'''1- Requirements'''<br />
<br />
This phase corresponds to the expression of needs [6]. 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].<br />
<br />
'''2- Analysis'''<br />
<br />
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.<br />
<br />
'''3- Design'''<br />
<br />
From the specifications, the functions and requirements are transformed into a feasible product. The product is specified and its architecture is designed [11].<br />
<br />
'''4- Implementation'''<br />
<br />
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].<br />
<br />
'''5- Testing and Validation'''<br />
<br />
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.<br />
<br />
'''6- Release'''<br />
<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used [6].<br />
<br />
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.<br />
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.<br />
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].<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why<br />
it has been and still is massively used.<br />
<br />
'''Simplicity'''<br />
<br />
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<br />
resources and management knowledge to follow the model [11].<br />
<br />
'''Consistency'''<br />
<br />
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<br />
both for the smooth running of the work and for future projects [2][6].<br />
<br />
'''Control'''<br />
<br />
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 [6]. 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<br />
are only made between adjacent phases, which limits changes [1].<br />
'''When to use Waterfall Model ?'''<br />
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<br />
in very large projects the Waterfall Model should be chosen for its advantages [8].<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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 [6]. 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<br />
change [6][8].<br />
<br />
'''A high risk model'''<br />
<br />
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 [6], 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<br />
[6], "then invariably a major redesign is required" adds W.W. Royce [1].<br />
<br />
'''High costs and efforts'''<br />
<br />
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 [6]. Similarly, iterations and rollbacks of previous phases are costly in terms of team effort [6][11]. Finally, in the case of major substantive problems encountered in the final phase, additional costs are obviously to be expected, as<br />
well as an overrun of the planned dates [6].<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
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<br />
and other Unified Processes (needs a link to these two methods).<br />
<br />
'''Agile methods'''<br />
<br />
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<br />
short cycles with dynamic planning and prioritization.<br />
<br />
'''When to use which'''<br />
<br />
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<br />
whether a project should be structured according to a Waterfall Model or agile:<br />
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<br />
responsiveness to change[5].<br />
* Customer: Agile adapts to cases where the customer is deeply involved in the development, which can be associated and knowledgeable, while the Waterfall Model<br />
requires adequately skilled customers.<br />
* 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<br />
change.<br />
* Culture: Generally speaking, the Waterfall Model will better adapt to a company<br />
cultivating values of order and rigor while Agile methods thrive on chaos.<br />
<br />
==Conclusion==<br />
==Annotated bibliography==<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116238Waterfall model2022-03-18T14:14:45Z<p>S212522: /* Comparison Waterfall / Agile */</p>
<hr />
<div>'''Summary'''<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
<br />
'''1- Requirements'''<br />
<br />
This phase corresponds to the expression of needs [6]. 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].<br />
<br />
'''2- Analysis'''<br />
<br />
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.<br />
<br />
'''3- Design'''<br />
<br />
From the specifications, the functions and requirements are transformed into a feasible product. The product is specified and its architecture is designed [11].<br />
<br />
'''4- Implementation'''<br />
<br />
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].<br />
<br />
'''5- Testing and Validation'''<br />
<br />
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.<br />
<br />
'''6- Release'''<br />
<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used [6].<br />
<br />
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.<br />
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.<br />
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].<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why<br />
it has been and still is massively used.<br />
<br />
'''Simplicity'''<br />
<br />
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<br />
resources and management knowledge to follow the model [11].<br />
<br />
'''Consistency'''<br />
<br />
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<br />
both for the smooth running of the work and for future projects [2][6].<br />
<br />
'''Control'''<br />
<br />
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 [6]. 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<br />
are only made between adjacent phases, which limits changes [1].<br />
'''When to use Waterfall Model ?'''<br />
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<br />
in very large projects the Waterfall Model should be chosen for its advantages [8].<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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 [6]. 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<br />
change [6][8].<br />
<br />
'''A high risk model'''<br />
<br />
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 [6], 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<br />
[6], "then invariably a major redesign is required" adds W.W. Royce [1].<br />
<br />
'''High costs and efforts'''<br />
<br />
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 [6]. Similarly, iterations and rollbacks of previous phases are costly in terms of team effort [6][11]. Finally, in the case of major substantive problems encountered in the final phase, additional costs are obviously to be expected, as<br />
well as an overrun of the planned dates [6].<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
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<br />
and other Unified Processes (needs a link to these two methods).<br />
<br />
'''Agile methods'''<br />
<br />
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<br />
short cycles with dynamic planning and prioritization.<br />
<br />
'''When to use which'''<br />
<br />
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<br />
whether a project should be structured according to a Waterfall Model or agile:<br />
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<br />
responsiveness to change[5].<br />
* Customer: Agile adapts to cases where the customer is deeply involved in the development, which can be associated and knowledgeable, while the Waterfall Model<br />
requires adequately skilled customers.<br />
* 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<br />
change.<br />
* ''''Culture:'''' Generally speaking, the Waterfall Model will better adapt to a company<br />
cultivating values of order and rigor while Agile methods thrive on chaos.<br />
<br />
==Conclusion==<br />
==Annotated bibliography==<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116237Waterfall model2022-03-18T14:14:30Z<p>S212522: /* Comparison Waterfall / Agile */</p>
<hr />
<div>'''Summary'''<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
<br />
'''1- Requirements'''<br />
<br />
This phase corresponds to the expression of needs [6]. 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].<br />
<br />
'''2- Analysis'''<br />
<br />
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.<br />
<br />
'''3- Design'''<br />
<br />
From the specifications, the functions and requirements are transformed into a feasible product. The product is specified and its architecture is designed [11].<br />
<br />
'''4- Implementation'''<br />
<br />
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].<br />
<br />
'''5- Testing and Validation'''<br />
<br />
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.<br />
<br />
'''6- Release'''<br />
<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used [6].<br />
<br />
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.<br />
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.<br />
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].<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why<br />
it has been and still is massively used.<br />
<br />
'''Simplicity'''<br />
<br />
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<br />
resources and management knowledge to follow the model [11].<br />
<br />
'''Consistency'''<br />
<br />
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<br />
both for the smooth running of the work and for future projects [2][6].<br />
<br />
'''Control'''<br />
<br />
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 [6]. 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<br />
are only made between adjacent phases, which limits changes [1].<br />
'''When to use Waterfall Model ?'''<br />
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<br />
in very large projects the Waterfall Model should be chosen for its advantages [8].<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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 [6]. 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<br />
change [6][8].<br />
<br />
'''A high risk model'''<br />
<br />
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 [6], 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<br />
[6], "then invariably a major redesign is required" adds W.W. Royce [1].<br />
<br />
'''High costs and efforts'''<br />
<br />
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 [6]. Similarly, iterations and rollbacks of previous phases are costly in terms of team effort [6][11]. Finally, in the case of major substantive problems encountered in the final phase, additional costs are obviously to be expected, as<br />
well as an overrun of the planned dates [6].<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
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<br />
and other Unified Processes (needs a link to these two methods).<br />
<br />
'''Agile methods'''<br />
<br />
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<br />
short cycles with dynamic planning and prioritization.<br />
<br />
'''When to use which'''<br />
<br />
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<br />
whether a project should be structured according to a Waterfall Model or agile:<br />
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<br />
responsiveness to change[5].<br />
* Customer: Agile adapts to cases where the customer is deeply involved in the development, which can be associated and knowledgeable, while the Waterfall Model<br />
requires adequately skilled customers.<br />
* 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<br />
change.<br />
* Culture: Generally speaking, the Waterfall Model will better adapt to a company<br />
cultivating values of order and rigor while Agile methods thrive on chaos.<br />
<br />
==Conclusion==<br />
==Annotated bibliography==<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116236Waterfall model2022-03-18T14:13:38Z<p>S212522: /* Description of the model in phases */</p>
<hr />
<div>'''Summary'''<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
<br />
'''1- Requirements'''<br />
<br />
This phase corresponds to the expression of needs [6]. 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].<br />
<br />
'''2- Analysis'''<br />
<br />
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.<br />
<br />
'''3- Design'''<br />
<br />
From the specifications, the functions and requirements are transformed into a feasible product. The product is specified and its architecture is designed [11].<br />
<br />
'''4- Implementation'''<br />
<br />
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].<br />
<br />
'''5- Testing and Validation'''<br />
<br />
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.<br />
<br />
'''6- Release'''<br />
<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used [6].<br />
<br />
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.<br />
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.<br />
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].<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why<br />
it has been and still is massively used.<br />
<br />
'''Simplicity'''<br />
<br />
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<br />
resources and management knowledge to follow the model [11].<br />
<br />
'''Consistency'''<br />
<br />
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<br />
both for the smooth running of the work and for future projects [2][6].<br />
<br />
'''Control'''<br />
<br />
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 [6]. 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<br />
are only made between adjacent phases, which limits changes [1].<br />
'''When to use Waterfall Model ?'''<br />
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<br />
in very large projects the Waterfall Model should be chosen for its advantages [8].<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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 [6]. 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<br />
change [6][8].<br />
<br />
'''A high risk model'''<br />
<br />
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 [6], 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<br />
[6], "then invariably a major redesign is required" adds W.W. Royce [1].<br />
<br />
'''High costs and efforts'''<br />
<br />
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 [6]. Similarly, iterations and rollbacks of previous phases are costly in terms of team effort [6][11]. Finally, in the case of major substantive problems encountered in the final phase, additional costs are obviously to be expected, as<br />
well as an overrun of the planned dates [6].<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
==Conclusion==<br />
==Annotated bibliography==<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116234Waterfall model2022-03-18T14:12:57Z<p>S212522: /* Advantages of the model and when to use it */</p>
<hr />
<div>'''Summary'''<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
*'''1- Requirements'''<br />
This phase corresponds to the expression of needs [6]. 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].<br />
*'''2- Analysis'''<br />
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.<br />
*'''3- Design'''<br />
From the specifications, the functions and requirements are transformed into a feasible product. The product is specified and its architecture is designed [11].<br />
*'''4- Implementation'''<br />
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].<br />
*'''5- Testing and Validation'''<br />
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.<br />
*'''6- Release'''<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used [6].<br />
<br />
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.<br />
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.<br />
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].<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why<br />
it has been and still is massively used.<br />
<br />
'''Simplicity'''<br />
<br />
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<br />
resources and management knowledge to follow the model [11].<br />
<br />
'''Consistency'''<br />
<br />
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<br />
both for the smooth running of the work and for future projects [2][6].<br />
<br />
'''Control'''<br />
<br />
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 [6]. 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<br />
are only made between adjacent phases, which limits changes [1].<br />
'''When to use Waterfall Model ?'''<br />
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<br />
in very large projects the Waterfall Model should be chosen for its advantages [8].<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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 [6]. 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<br />
change [6][8].<br />
<br />
'''A high risk model'''<br />
<br />
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 [6], 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<br />
[6], "then invariably a major redesign is required" adds W.W. Royce [1].<br />
<br />
'''High costs and efforts'''<br />
<br />
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 [6]. Similarly, iterations and rollbacks of previous phases are costly in terms of team effort [6][11]. Finally, in the case of major substantive problems encountered in the final phase, additional costs are obviously to be expected, as<br />
well as an overrun of the planned dates [6].<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
==Conclusion==<br />
==Annotated bibliography==<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116232Waterfall model2022-03-18T14:12:05Z<p>S212522: /* Advantages of the model and when to use it */</p>
<hr />
<div>'''Summary'''<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
*'''1- Requirements'''<br />
This phase corresponds to the expression of needs [6]. 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].<br />
*'''2- Analysis'''<br />
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.<br />
*'''3- Design'''<br />
From the specifications, the functions and requirements are transformed into a feasible product. The product is specified and its architecture is designed [11].<br />
*'''4- Implementation'''<br />
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].<br />
*'''5- Testing and Validation'''<br />
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.<br />
*'''6- Release'''<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used [6].<br />
<br />
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.<br />
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.<br />
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].<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why<br />
it has been and still is massively used.<br />
'''Simplicity'''<br />
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<br />
resources and management knowledge to follow the model [11].<br />
'''Consistency'''<br />
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<br />
both for the smooth running of the work and for future projects [2][6].<br />
'''Control'''<br />
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 [6]. 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<br />
are only made between adjacent phases, which limits changes [1].<br />
'''When to use Waterfall Model ?'''<br />
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<br />
in very large projects the Waterfall Model should be chosen for its advantages [8].<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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 [6]. 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<br />
change [6][8].<br />
<br />
'''A high risk model'''<br />
<br />
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 [6], 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<br />
[6], "then invariably a major redesign is required" adds W.W. Royce [1].<br />
<br />
'''High costs and efforts'''<br />
<br />
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 [6]. Similarly, iterations and rollbacks of previous phases are costly in terms of team effort [6][11]. Finally, in the case of major substantive problems encountered in the final phase, additional costs are obviously to be expected, as<br />
well as an overrun of the planned dates [6].<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
==Conclusion==<br />
==Annotated bibliography==<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116231Waterfall model2022-03-18T14:11:44Z<p>S212522: </p>
<hr />
<div>'''Summary'''<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
*'''1- Requirements'''<br />
This phase corresponds to the expression of needs [6]. 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].<br />
*'''2- Analysis'''<br />
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.<br />
*'''3- Design'''<br />
From the specifications, the functions and requirements are transformed into a feasible product. The product is specified and its architecture is designed [11].<br />
*'''4- Implementation'''<br />
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].<br />
*'''5- Testing and Validation'''<br />
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.<br />
*'''6- Release'''<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used [6].<br />
<br />
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.<br />
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.<br />
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].<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why<br />
it has been and still is massively used.<br />
*'''Simplicity'''<br />
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<br />
resources and management knowledge to follow the model [11].<br />
* '''Consistency'''<br />
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<br />
both for the smooth running of the work and for future projects [2][6].<br />
* '''Control'''<br />
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 [6]. 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<br />
are only made between adjacent phases, which limits changes [1].<br />
*'''When to use Waterfall Model ?'''<br />
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<br />
in very large projects the Waterfall Model should be chosen for its advantages [8].<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
<br />
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 [6]. 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<br />
change [6][8].<br />
<br />
'''A high risk model'''<br />
<br />
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 [6], 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<br />
[6], "then invariably a major redesign is required" adds W.W. Royce [1].<br />
<br />
'''High costs and efforts'''<br />
<br />
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 [6]. Similarly, iterations and rollbacks of previous phases are costly in terms of team effort [6][11]. Finally, in the case of major substantive problems encountered in the final phase, additional costs are obviously to be expected, as<br />
well as an overrun of the planned dates [6].<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
==Conclusion==<br />
==Annotated bibliography==<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116230Waterfall model2022-03-18T14:11:27Z<p>S212522: </p>
<hr />
<div>'''Summary'''<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
*'''1- Requirements'''<br />
This phase corresponds to the expression of needs [6]. 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].<br />
*'''2- Analysis'''<br />
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.<br />
*'''3- Design'''<br />
From the specifications, the functions and requirements are transformed into a feasible product. The product is specified and its architecture is designed [11].<br />
*'''4- Implementation'''<br />
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].<br />
*'''5- Testing and Validation'''<br />
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.<br />
*'''6- Release'''<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used [6].<br />
<br />
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.<br />
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.<br />
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].<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why<br />
it has been and still is massively used.<br />
*'''Simplicity'''<br />
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<br />
resources and management knowledge to follow the model [11].<br />
* '''Consistency'''<br />
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<br />
both for the smooth running of the work and for future projects [2][6].<br />
* '''Control'''<br />
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 [6]. 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<br />
are only made between adjacent phases, which limits changes [1].<br />
*'''When to use Waterfall Model ?'''<br />
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<br />
in very large projects the Waterfall Model should be chosen for its advantages [8].<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
<br />
'''Fixity of requirements'''<br />
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 [6]. 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<br />
change [6][8].<br />
<br />
'''A high risk model'''<br />
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 [6], 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<br />
[6], "then invariably a major redesign is required" adds W.W. Royce [1].<br />
<br />
'''High costs and efforts'''<br />
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 [6]. Similarly, iterations and rollbacks of previous phases are costly in terms of team effort [6][11]. Finally, in the case of major substantive problems encountered in the final phase, additional costs are obviously to be expected, as<br />
well as an overrun of the planned dates [6].<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
==Conclusion==<br />
==Annotated bibliography==<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116228Waterfall model2022-03-18T14:11:04Z<p>S212522: /* Problems encountered with the Model */</p>
<hr />
<div>'''Summary'''<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
*'''1- Requirements'''<br />
This phase corresponds to the expression of needs [6]. 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].<br />
*'''2- Analysis'''<br />
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.<br />
*'''3- Design'''<br />
From the specifications, the functions and requirements are transformed into a feasible product. The product is specified and its architecture is designed [11].<br />
*'''4- Implementation'''<br />
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].<br />
*'''5- Testing and Validation'''<br />
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.<br />
*'''6- Release'''<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used [6].<br />
<br />
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.<br />
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.<br />
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].<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why<br />
it has been and still is massively used.<br />
*'''Simplicity'''<br />
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<br />
resources and management knowledge to follow the model [11].<br />
* '''Consistency'''<br />
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<br />
both for the smooth running of the work and for future projects [2][6].<br />
* '''Control'''<br />
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 [6]. 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<br />
are only made between adjacent phases, which limits changes [1].<br />
*'''When to use Waterfall Model ?'''<br />
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<br />
in very large projects the Waterfall Model should be chosen for its advantages [8].<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
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<br />
fundamental problems widely criticized.<br />
'''Fixity of requirements'''<br />
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 [6]. 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<br />
change [6][8].<br />
'''A high risk model'''<br />
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 [6], 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<br />
[6], "then invariably a major redesign is required" adds W.W. Royce [1].<br />
'''High costs and efforts'''<br />
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 [6]. Similarly, iterations and rollbacks of previous phases are costly in terms of team effort [6][11]. Finally, in the case of major substantive problems encountered in the final phase, additional costs are obviously to be expected, as<br />
well as an overrun of the planned dates [6].<br />
<br />
===Comparison Waterfall / Agile===<br />
<br />
==Conclusion==<br />
==Annotated bibliography==<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116225Waterfall model2022-03-18T14:08:58Z<p>S212522: /* Advantages of the model and when to use it */</p>
<hr />
<div>'''Summary'''<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
*'''1- Requirements'''<br />
This phase corresponds to the expression of needs [6]. 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].<br />
*'''2- Analysis'''<br />
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.<br />
*'''3- Design'''<br />
From the specifications, the functions and requirements are transformed into a feasible product. The product is specified and its architecture is designed [11].<br />
*'''4- Implementation'''<br />
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].<br />
*'''5- Testing and Validation'''<br />
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.<br />
*'''6- Release'''<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used [6].<br />
<br />
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.<br />
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.<br />
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].<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why<br />
it has been and still is massively used.<br />
*'''Simplicity'''<br />
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<br />
resources and management knowledge to follow the model [11].<br />
* '''Consistency'''<br />
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<br />
both for the smooth running of the work and for future projects [2][6].<br />
* '''Control'''<br />
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 [6]. 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<br />
are only made between adjacent phases, which limits changes [1].<br />
*'''When to use Waterfall Model ?'''<br />
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<br />
in very large projects the Waterfall Model should be chosen for its advantages [8].<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
===Comparison Waterfall / Agile===<br />
<br />
==Conclusion==<br />
==Annotated bibliography==<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116223Waterfall model2022-03-18T14:08:35Z<p>S212522: </p>
<hr />
<div>'''Summary'''<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
*'''1- Requirements'''<br />
This phase corresponds to the expression of needs [6]. 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].<br />
*'''2- Analysis'''<br />
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.<br />
*'''3- Design'''<br />
From the specifications, the functions and requirements are transformed into a feasible product. The product is specified and its architecture is designed [11].<br />
*'''4- Implementation'''<br />
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].<br />
*'''5- Testing and Validation'''<br />
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.<br />
*'''6- Release'''<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used [6].<br />
<br />
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.<br />
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.<br />
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].<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
The Waterfall Model, by the triviality of its features, has many advantages that explain why<br />
it has been and still is massively used.<br />
*'''1-Simplicity'''<br />
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<br />
resources and management knowledge to follow the model [11].<br />
* '''2-Consistency'''<br />
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<br />
both for the smooth running of the work and for future projects [2][6].<br />
* '''3-Control'''<br />
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 [6]. 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<br />
are only made between adjacent phases, which limits changes [1].<br />
*'''4-When to use Waterfall Model ?'''<br />
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<br />
in very large projects the Waterfall Model should be chosen for its advantages [8].<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
===Comparison Waterfall / Agile===<br />
<br />
==Conclusion==<br />
==Annotated bibliography==<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116222Waterfall model2022-03-18T14:07:29Z<p>S212522: </p>
<hr />
<div>'''Summary'''<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
*'''1- Requirements'''<br />
This phase corresponds to the expression of needs [6]. 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].<br />
*'''2- Analysis'''<br />
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.<br />
*'''3- Design'''<br />
From the specifications, the functions and requirements are transformed into a feasible product. The product is specified and its architecture is designed [11].<br />
*'''4- Implementation'''<br />
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].<br />
*'''5- Testing and Validation'''<br />
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.<br />
*'''6- Release'''<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used [6].<br />
<br />
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.<br />
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.<br />
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].<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
===Comparison Waterfall / Agile===<br />
<br />
==Conclusion==<br />
==Annotated bibliography==<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116221Waterfall model2022-03-18T14:07:04Z<p>S212522: </p>
<hr />
<div>'''Summary'''<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
The waterfall project management model is broken down into a series of consecutive stages. The classic model has six phases:<br />
'''1- Requirements'''<br />
This phase corresponds to the expression of needs [6]. 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].<br />
'''2- Analysis'''<br />
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.<br />
'''3- Design'''<br />
From the specifications, the functions and requirements are transformed into a feasible product. The product is specified and its architecture is designed [11].<br />
'''4- Implementation'''<br />
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].<br />
'''5- Testing and Validation'''<br />
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.<br />
'''6- Release'''<br />
Once a final product is approved, its commissioning is prepared. Then the product is installed and used [6].<br />
<br />
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.<br />
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.<br />
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].<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
===Comparison Waterfall / Agile===<br />
<br />
==Conclusion==<br />
==Annotated bibliography==<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116219Waterfall model2022-03-18T14:05:31Z<p>S212522: </p>
<hr />
<div>'''Summary'''<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
===Comparison Waterfall / Agile===<br />
<br />
==Conclusion==<br />
==Annotated bibliography==<br />
<br />
==References==<br />
<references /></div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=116218Waterfall model2022-03-18T14:04:43Z<p>S212522: </p>
<hr />
<div>'''Summary'''<br />
<br />
==The Big Idea==<br />
===Description of the model in phases===<br />
<br />
==Applications==<br />
===Advantages of the model and when to use it===<br />
<br />
==Limitations==<br />
===Problems encountered with the Model===<br />
===Comparison Waterfall / Agile===<br />
<br />
==Conclusion==<br />
==Annotated bibliography==</div>S212522http://13.50.150.85/index.php?title=Articles_Spring_Term_2022&diff=116214Articles Spring Term 20222022-03-18T13:59:39Z<p>S212522: /* Overview of 2022 Wiki Collections */</p>
<hr />
<div>=Overview of 2022 Wiki Collections=<br />
<br />
{| class="wikitable sortable"<br />
|+Spring Term 2022 Wiki Collections<br />
|Group 32<br />
|Nikoleta<br />
|Tsolaki<br />
|s212602<br />
|[[The Kaizen Method in Project Management]]<br />
|-<br />
|-<br />
|TAs Example<br />
|Thomas<br />
|Giannoulopoulos<br />
|s192419<br />
|[[APPM Example 2021]]<br />
|-<br />
|-<br />
|Group 8<br />
|Daniel Rohrer<br />
|Hansen<br />
|s173922<br />
|[[Managing “emails”]]<br />
|-<br />
|-<br />
|Group 9<br />
|Andrea<br />
|Sánchez Díez<br />
|s202957<br />
|[[Urgent vs important. The Eisenhower matrix]]<br />
|-<br />
|-<br />
|Group 22<br />
|Edgars<br />
|Treimanis<br />
|s213590<br />
|[[Sustainable Project management]]<br />
|-<br />
|-<br />
|Group 31<br />
|William Taul<br />
|Madsen<br />
|s184956<br />
|[[Risk Treatment in project management]]<br />
|-<br />
|-<br />
|Group 12<br />
|Pablo Leandro<br />
|Capellari<br />
|s213666<br />
|[[Internal Rate of Return (IRR)]]<br />
|-<br />
|-<br />
|Group 15<br />
|Tolga<br />
|Azgun<br />
|s220502<br />
|[[Pooled, Sequential & Reciprocal Interdependence]]<br />
|-<br />
|-<br />
|Group 15<br />
|Mathilde <br />
|Dahl <br />
|s176213 <br />
|[[Development Arena in Project Management]]<br />
|-<br />
|-<br />
|Group 19<br />
|Matias<br />
|Earthy-Find<br />
|s184350<br />
|[[Stress Management]]<br />
|-<br />
|-<br />
|Group 3<br />
|Stephen Akabekire<br />
|Azongo<br />
|s213057<br />
|[[The magic triangle as a project management tool]]<br />
|-<br />
|-<br />
|Group 19<br />
|Wout<br />
|Jennissen<br />
|s216914<br />
|[[Porter's Five Forces Framework]]<br />
|-<br />
|-<br />
|Group 4<br />
|Sissel Albrecht<br />
|Kahr<br />
|s173964<br />
|[[Work Break Down Structure (WBS)]]<br />
|-<br />
|-<br />
|Group 15<br />
|Teis<br />
|Johannesen<br />
|s213561<br />
|[[Reflective practice]]<br />
|-<br />
|-<br />
|Group 9<br />
|Berta<br />
|Viñas<br />
|s202256<br />
|[[Agile model]]<br />
|-<br />
|-<br />
|Group 15<br />
|Christina<br />
|Qwist Frank<br />
|s173409<br />
|[[Staging negotiation spaces in project management]]<br />
|-<br />
|-<br />
|Group 15<br />
|Sara <br />
|Kristine Holmskov Eberle<br />
|s211691<br />
|[[Wheel of change]]<br />
|-<br />
|-<br />
|Group Name: TBD<br />
|Saaransh<br />
|PD Kattula<br />
|s210240<br />
|[[7 principles of Stephen covey for project mangers to tackle risks]]<br />
|-<br />
|-<br />
|Group Name: 47<br />
|Jakob Weber<br />
|Vestermark<br />
|s175072<br />
|[[Kanban method]]<br />
|-<br />
|-<br />
|Group Name: TBD<br />
|Jakob<br />
|Kehler<br />
|s212691<br />
|[[Post-Implementation Review (PIR)]]<br />
|-<br />
|-<br />
|Group Name: 47<br />
|Fie<br />
|Fredshavn Nielsen<br />
|s170396<br />
|[[Project dashboard]]<br />
|-<br />
|-<br />
|Group Name: 33<br />
|Alvaro<br />
|Martin Sanchez<br />
|s220145<br />
|[[New Hybrid Methodology: Scrumban]]<br />
|-<br />
|-<br />
|Group Name: TBD<br />
|Mathias<br />
|Christensen<br />
|s175382<br />
|[[Agile (Adaptive) model]]<br />
|-<br />
|-<br />
|Group Name:<br />
|Emilie<br />
|Haahr<br />
|s175383<br />
|[[Leadship vs Management Qualities]]<br />
|-<br />
|-<br />
|Group 22<br />
|Linda<br />
|Zviedre<br />
|s213817<br />
|[[Matrix Organizations]]<br />
|-<br />
|-<br />
|Group Name: 4<br />
|Casper<br />
|Stenbæk<br />
|s183504<br />
|[[Causes and effects of stress in project management]]<br />
|-<br />
|-<br />
|Group name<br />
|Sarah<br />
|Naegele<br />
|S220025<br />
|[[Communication models based on Schulz von Thun]]<br />
|-<br />
|-<br />
|Group Name:<br />
|Sofie<br />
|Wallin<br />
|s173884<br />
|[[Sources of conflict]]<br />
|-<br />
|-<br />
|Group 19<br />
|Elias<br />
|Bobrowski<br />
|s216056<br />
|[[The Difference Between Leadership and Management]]<br />
|-<br />
|-<br />
|Group Name:<br />
|Luisa<br />
|Buchta<br />
|s216284<br />
|[[MTA (Milestone trend analysis)]]<br />
|-<br />
|-<br />
|Group Name:<br />
|Frederik<br />
|Østergaard Schytte<br />
|s175075<br />
|[[Prioritizing in Projects with Eisenhower Decision Matrix]]<br />
|-<br />
|-<br />
|Group 40<br />
|Xenofon<br />
|Apostolou<br />
|s202908<br />
|[[Continuous Improvement (CI)]]<br />
|-<br />
|-<br />
|Group Name: The Insifers<br />
|Periklis<br />
|Aprilis<br />
|s212866<br />
|[[FMEA as tool in Project Management]]<br />
|-<br />
|-<br />
|Group Name: <br />
|Nils<br />
|Lehmann<br />
|s220153<br />
|[[Effects of Social Loafing on Team Performance]]<br />
|-<br />
|-<br />
|Group Name:<br />
|Olivia<br />
|Mark<br />
|s175096<br />
|[[Self-awareness in management]]<br />
|-<br />
|-<br />
|Group Name: <br />
|Paul<br />
|Schatt<br />
|s210736<br />
|[[Perception filters]]<br />
|-<br />
|-<br />
|Group 8<br />
|Lorenzo<br />
|Incarnato<br />
|s220426<br />
|[[Internal rate of return (IRR)]]<br />
|-<br />
|-<br />
|Group Name: 40<br />
|Sasa<br />
|Javorac<br />
|s210770<br />
|[[Agile way of working]]<br />
|-<br />
|-<br />
|Group Name: 12<br />
|Elia<br />
|Simon<br />
|s212700<br />
|[[Extrinsic motivation]]<br />
|-<br />
|-<br />
|Group Name: 32 <br />
|Hamzeh<br />
|Alrijjal<br />
|s152941<br />
|[[Eisenhower decision matrix in project management]]<br />
|-<br />
|-<br />
|Group Name: <br />
|Swann<br />
|Roussillon<br />
|s212830<br />
|[[Robust Decision Making (RDM)]]<br />
|-<br />
|-<br />
|Group Name: The Insifers<br />
|Marcus<br />
|Randrup<br />
|s184486<br />
|[[Virtual War Rooms]]<br />
|-<br />
|-<br />
|Group 09<br />
|Deepthi<br />
|Parana Liyanage Don<br />
|s203116<br />
|[[Net Present Value (NPV)]]<br />
|-<br />
|-<br />
|Group Name: 10<br />
|Felix<br />
|Piepenstock<br />
|s201828<br />
|[[The Successive Principle for Managing Uncertainty]]<br />
|-<br />
|-<br />
|Group Name: 10<br />
|Julian<br />
|Schmidt<br />
|s213004<br />
|[[Social loafing]]<br />
|-<br />
|-<br />
|Group 22: MuchManage<br />
|Gustav<br />
|Gregersen<br />
|s153930<br />
|[[DMAIC Projects]]<br />
|-<br />
|-<br />
|Group 42<br />
|Simon<br />
|Widmer<br />
|s210449<br />
|[[Scaled Agile Framework (SAFe)]]<br />
|-<br />
|-<br />
|Group 17<br />
|Cosmina<br />
|Oltean<br />
|s212409<br />
|[[Team Cohesiveness]]<br />
|-<br />
|-<br />
|Group 12<br />
|Jasmine Riis<br />
|Douglas<br />
|s123367<br />
|[[How stress management improves the effectiveness of the employees]]<br />
|-<br />
|-<br />
|Group 42<br />
|Preetham <br />
|Obla Sampathkumar<br />
|s213604<br />
|[[Root cause analysis (RCA)]]<br />
|-<br />
|-<br />
|Group 4<br />
|Patrick <br />
|Laybourn<br />
|s144993<br />
|[[Robust decision making]]<br />
|-<br />
|-<br />
|Group 6<br />
|Gudrun<br />
|Gudnadottir<br />
|s212950<br />
|[[Risk-based Learning]]<br />
|-<br />
|-<br />
|Group 17<br />
|Andreea Bianca<br />
|Ladaru<br />
|s202438<br />
|[[Lean principles in the construction industry]]<br />
|-<br />
|-<br />
|Group 15<br />
|Lærke Viuff <br />
|Petersen<br />
|s163830<br />
|[[Social Loafing in Teams]]<br />
|-<br />
|-<br />
|Group 15<br />
|Stine Pagaard <br />
|Haahr<br />
|s152100<br />
|[[Conflict Management using the Thomas-Kilmann Conflict Mode Instrument (TKI)]]<br />
|-<br />
|-<br />
|Group 42<br />
|Nachanan<br />
|Wongsupakpun<br />
|s210284<br />
|[[Organizational context]]<br />
|-<br />
|-<br />
|Group 33<br />
|Guillermo<br />
|Roig Pitarch<br />
|s212754<br />
|[[Kanban: a project management framework]]<br />
|-<br />
|-<br />
|Group 29<br />
|Magnus<br />
|Leick<br />
|s213818<br />
|[[VUCA]]<br />
|-<br />
|-<br />
|Group 4<br />
|Freja Ejdrup<br />
|Andersen<br />
|s183631<br />
|[[The paradox of project planning from an uncertainty perspective]]<br />
|-<br />
|-<br />
|Group 9<br />
|Nongnapat<br />
|Suksusiang<br />
|s213572<br />
|[[New Product Introduction (NPI)]]<br />
|-<br />
|-<br />
|Group 31<br />
|Eigil<br />
|Vølund<br />
|s183887<br />
|[[Risk Treatment]]<br />
|-<br />
|-<br />
|Group 11<br />
|Ann Sofie<br />
|Grube Kjeldsen<br />
|s184535<br />
|[[Milestone trend analysis]]<br />
|-<br />
|-<br />
|Group 19<br />
|Qiushi <br />
|Lyu<br />
|s212543<br />
|[[Porter's 5 Forces - A strategic planning model]]<br />
|-<br />
|-<br />
|Group 9<br />
|Qifan <br />
|Wang<br />
|s212500<br />
|[[The Big Five(OCEAN) Personality Traits]]<br />
|-<br />
|-<br />
|Group 12<br />
|Hai <br />
|Hu<br />
|s212360<br />
|[[Kano Model: Introduction and Application]]<br />
|-<br />
|-<br />
|Group 32<br />
|Tobias<br />
|Nielsen<br />
|s220719<br />
|[[Fixed-price contracts]]<br />
|-<br />
|-<br />
|Group 11<br />
|Hannah<br />
|Nissen<br />
|s184497<br />
|[[Effective teams with Belbin]]<br />
|-<br />
|-<br />
|Group 11 <br />
|Emil Engstrøm<br />
|Bruun<br />
|S180902<br />
|[[Adizes management styles]]<br />
|-<br />
|-<br />
|Group 33<br />
|Raquel <br />
|Galocha<br />
|S212745<br />
|[[Project interdependency mapping]]<br />
|-<br />
|-<br />
|Group 11 <br />
|Emilie <br />
|Rasmussen<br />
|S184532<br />
|[[WBS, Work Breakdown Structure]]<br />
|-<br />
|-<br />
|Group 6 <br />
|Telma Sigrún <br />
|Torfadóttir<br />
|S212566<br />
|[[Stress]]<br />
|-<br />
|-<br />
|-<br />
|-<br />
|Group 4 <br />
|Erlend Thabiso Rømyhr <br />
|Sehube<br />
|S212426<br />
|[[Risk treatment for renewable energy developers]]<br />
|-<br />
|-<br />
|Group 11 <br />
|Peter<br />
|Birkholm<br />
|S184514<br />
|[[Gantt Chart In Construction]]<br />
|-<br />
|-<br />
|Group 18 <br />
|Giacomo<br />
|Branchini<br />
|S212987<br />
|[[Sources of Conflict: Guidelines for a Healthy Organizational Environment]]<br />
|-<br />
|-<br />
|Group 33 <br />
|Paula<br />
|González<br />
|S213398<br />
|[[The Big Five (Ocean)]]<br />
|-<br />
|-<br />
|Group 33 <br />
|Fernando<br />
|Ramiro Gonzalez<br />
|S214134<br />
|[[MCDA methods in decision making]]<br />
|-<br />
|-<br />
|Group 20 <br />
|Magnus Stjernborg<br />
|Koch<br />
|S175189<br />
|[[Project Success and Project Management Success]]<br />
|-<br />
|-<br />
|Group 26<br />
|Katarzyna<br />
|Kukulowicz<br />
|S213042<br />
|[[Extrinsic and intrinsic motivation. What does the will to act depend on?]]<br />
|-<br />
|-<br />
|Group 6 <br />
|Hildur Lara <br />
|Jonsdottir<br />
|S212410<br />
|[[The Significance of Cohesiveness in Projects]]<br />
|-<br />
|-<br />
|Group 20<br />
|Ziwei<br />
|Chen<br />
|S212635<br />
|[[Stakeholder Identification and Categorization]]<br />
|-<br />
|-<br />
|Group 18<br />
|Raül<br />
|Ciscar<br />
|S217122<br />
|[[Developing a project with the Tuckman's model]]<br />
|-<br />
|-<br />
|Group 18<br />
|Giorgio<br />
|Galasso<br />
|S212985<br />
|[[Risk Assessment: framework for combining CBA and MCDA]]<br />
|-<br />
|-<br />
|Group 33<br />
|Maria Elena<br />
|Igarzabal Saborida<br />
|S213206<br />
|[[Intrinsic and Extrinsic motivation]]<br />
|-<br />
|-<br />
|Group 32<br />
|Aikaterini<br />
|Deli<br />
|s212459<br />
|[[The Technique of Value Engineering (VE) in Architecture]]<br />
|-<br />
|-<br />
|Group 08<br />
|Jiajing<br />
|Zhang<br />
|s212412<br />
|[[The Rolling-wave Planning]]<br />
|-<br />
|-<br />
|Group<br />
|Isera Sarah<br />
|Hajaj<br />
|s153540<br />
|[[Standard Operating Procedures (SOPs)]]<br />
|-<br />
|Group 50<br />
|Ibrahim<br />
|Nassrallah<br />
|s211254<br />
|[[Brain Storming Technique]]-<br />
|-<br />
|-<br />
|Group 29<br />
|Panagiotis<br />
|Bakas<br />
|s216860<br />
|[[Drexler/Sibbet Model for Team development and project management]]<br />
|-<br />
|-<br />
|Group 20<br />
|Dionysios<br />
|Maroulis<br />
|s212885<br />
|[[Knowns and Unknowns]]<br />
|-<br />
|-<br />
|Group 32<br />
|Gabriela Miti<br />
|Tsuge Costa<br />
|s220075<br />
|[[Social Loafing in Projects]]<br />
|-<br />
|-<br />
|Group 32<br />
|Helená Evin<br />
|Cinar<br />
|s164741<br />
|[[The use of SWOT analysis]]<br />
|-<br />
|-<br />
|Group 3<br />
|Pietro<br />
|Boschetto<br />
|s213928<br />
|[[Enterprise Risk Management]]<br />
|-<br />
|-<br />
|Group 3<br />
|Virginia<br />
|Stinchi<br />
|s213230<br />
|[[The Blake and Mouton's Managerial (Leadership) Grid]]<br />
|-<br />
|-<br />
|Group 32<br />
|César<br />
|Delafargue<br />
|s212834<br />
|[[Design validation]]<br />
|-<br />
|-<br />
|Group 11<br />
|Rune<br />
|Andersen<br />
|s180642<br />
|[[Creating effective teams by means of mathematical modelling]]<br />
|-<br />
|-<br />
|Group Name: 47<br />
|Hannibal<br />
|Danielsen<br />
|s154283<br />
|[[Managing SCRUM]]<br />
|-<br />
|Group 20<br />
|Kunyi<br />
|Yang<br />
|s220027<br />
|[[Wideband Delphi]]<br />
|-<br />
|Group 20<br />
|Haeberle<br />
|François<br />
|s213827<br />
|[[TOC (Theory of Constraints)]]<br />
<br />
<br />
|-<br />
|Group 3<br />
|Cristiana<br />
|Moraru<br />
|s210219<br />
|[[The strategy choice cascade. Where to play and how to win.]]<br />
|-<br />
<br />
|-<br />
|Group 3<br />
|Andrea<br />
|Gatto<br />
|s212974<br />
|[[Emotional Intelligence in a Program, Project and Portfolio Management View]]<br />
|-<br />
|-<br />
|Group 19<br />
|Maria<br />
|Bakali<br />
|s220150<br />
|[[Benefit realization management]]<br />
|-<br />
<br />
|-<br />
|Group 20<br />
|Iliana<br />
|Dritsa<br />
|s210373<br />
|[[Risk management in Transport Infrastructure Projects (TIPs).]]<br />
|-<br />
<br />
|-<br />
|Group 17<br />
|Stine<br />
|Bonne Rasmussen<br />
|s203168<br />
|[[Robust Decision Making under Deep Uncertainty]]<br />
|-<br />
<br />
|-<br />
|Group 4<br />
|Josep<br />
|Comas Stokes<br />
|s212787<br />
|[[Management versus leadership qualities]]<br />
|-<br />
<br />
|-<br />
|Group 26<br />
|Almaelisa<br />
|Giovannucci Fernandez<br />
|s220007<br />
|[[Agile in Project Management]]<br />
|-<br />
<br />
|-<br />
|Group 47<br />
|Tobias<br />
|Stabrand<br />
|s175082<br />
|[[Ishikawa Diagram]]<br />
|-<br />
<br />
|-<br />
|Group 47<br />
|Maria<br />
|Kylafi<br />
|s212860<br />
|[[SWOT Analysis in Construction Projects]]<br />
|-<br />
<br />
|-<br />
|Group 42<br />
|Kristoffer Zanchetta<br />
|Klercke<br />
|s183633<br />
|[[Digital Communication in Project Management]]<br />
|-<br />
<br />
|-<br />
|Group 26<br />
|Julie<br />
|Nielsen<br />
|s163853<br />
|[[The Eisenhower Decision Matrix]]<br />
|-<br />
<br />
|-<br />
|Group 32<br />
|Marco<br />
|Lombardo<br />
|s210384<br />
|[[Agile (adaptive) model]]<br />
|-<br />
<br />
<br />
|-<br />
|Group 31<br />
|Jacob<br />
|Worsøe<br />
|s176466<br />
|[[Lead, lag and CPM]]<br />
|-<br />
<br />
|-<br />
|Group 40<br />
|Chloé<br />
|Alcalde<br />
|s212522<br />
|[[Waterfall model]]<br />
|-</div>S212522http://13.50.150.85/index.php?title=Articles_Spring_Term_2022&diff=102344Articles Spring Term 20222022-02-06T15:55:47Z<p>S212522: /* Overview of 2022 Wiki Collections */</p>
<hr />
<div>=Overview of 2022 Wiki Collections=<br />
<br />
{| class="wikitable sortable"<br />
|+Spring Term 2022 Wiki Collections<br />
|Group name<br />
|First name<br />
|Surname<br />
|Student number<br />
|[[Article name]]<br />
|-<br />
|-<br />
|TAs Example<br />
|Thomas<br />
|Giannoulopoulos<br />
|s192419<br />
|[[APPM Example 2021]]<br />
|-<br />
|-<br />
|TAs Example<br />
|Daniel Rohrer<br />
|Hansen<br />
|s173922<br />
|[[Managing “emails”]]<br />
|-<br />
|-<br />
|Group 15<br />
|Tolga<br />
|Azgun<br />
|s220502<br />
|[[Pooled, Sequential & Reciprocal Interdependence]]<br />
|-<br />
|-<br />
|Group Name?<br />
|Matias<br />
|Earthy-Find<br />
|s184350<br />
|[[Stress Management]]<br />
|-<br />
|-<br />
|Group 15<br />
|Teis<br />
|Johannesen<br />
|s213561<br />
|[[Self-Awareness]]<br />
|-<br />
|-<br />
|<br />
|Berta<br />
|Viñas<br />
|s202256<br />
|[[Agile model]]<br />
|-<br />
|-<br />
|Group Name: TBD<br />
|Saaransh<br />
|PD Kattula<br />
|s210240<br />
|[[7 principles of Stephen covey for project mangers to tackle risks]]<br />
|-<br />
|-<br />
|Group Name: 47<br />
|Jakob Weber<br />
|Vestermark<br />
|s175072<br />
|[[Matrix organization]]<br />
|-<br />
|-<br />
|Group Name: TBD<br />
|Jakob<br />
|Kehler<br />
|s212691<br />
|[[Post-Implementation Review (PIR)]]<br />
|-<br />
|-<br />
|Group Name: TBD<br />
|Fie<br />
|Fredshavn Nielsen<br />
|s170396<br />
|[[Project dashboard]]<br />
|-<br />
|-<br />
|Group Name: TBD<br />
|Mathias<br />
|Christensen<br />
|s175382<br />
|[[Agile (Adaptive) model]]<br />
|-<br />
|-<br />
|Group Name:<br />
|Emilie<br />
|Haahr<br />
|s175383<br />
|[[Leadship vs Management Qualities]]<br />
|-<br />
|-<br />
|Group name<br />
|Sarah<br />
|Naegele<br />
|S220025<br />
|[[Communication models based on Schulz von Thun]]<br />
|-<br />
|-<br />
|Group Name:<br />
|Sofie<br />
|Wallin<br />
|s173884<br />
|[[Sources of conflict]]<br />
|-<br />
|-<br />
|Group Name:<br />
|Elias<br />
|Bobrowski<br />
|s216056<br />
|[[Management vs. Leadership Skills]]<br />
|-<br />
|-<br />
|Group Name:<br />
|Luisa<br />
|Buchta<br />
|s216284<br />
|[[Milestone trend analysis]]<br />
|-<br />
|-<br />
|Group Name:<br />
|Frederik<br />
|Østergaard Schytte<br />
|s175075<br />
|[[Prioritizing in Projects with Eisenhower Decision Matrix]]<br />
|-<br />
|-<br />
|Group Name: 40<br />
|Xenofon<br />
|Apostolou<br />
|s202908<br />
|[[Continuous Improvement (CI)]]<br />
|-<br />
|-<br />
|Group Name: 08<br />
|Periklis<br />
|Aprilis<br />
|s212866<br />
|[[FMEA as tool in Project Management]]<br />
|-<br />
|-<br />
|Group Name: <br />
|Nils<br />
|Lehmann<br />
|s220153<br />
|[[Effects of Social Loafing on Team Performance (due to low motivation)]]<br />
|-<br />
|-<br />
|Group Name:<br />
|Olivia<br />
|Mark<br />
|s175096<br />
|[[Self-awareness in management]]<br />
|-<br />
|-<br />
|Group Name: <br />
|Paul<br />
|Schatt<br />
|s210736<br />
|[[Perception filters]]<br />
|-<br />
|-<br />
|Group name<br />
|Lorenzo<br />
|Incarnato<br />
|s220426<br />
|[[Internal rate of return (IRR)]]<br />
|-<br />
|-<br />
|Group Name: 40<br />
|Sasa<br />
|Javorac<br />
|s210770<br />
|[[Agile way of working]]<br />
|-<br />
|-<br />
|Group Name: 12<br />
|Elia<br />
|Simon<br />
|s212700<br />
|[[Extrinsic motivation]]<br />
|-<br />
|-<br />
|Group Name: <br />
|Swann<br />
|Roussillon<br />
|s212830<br />
|[[Robust Decision Making (RDM)]]<br />
|-<br />
|-<br />
|Group Name: <br />
|Felix<br />
|Piepenstock<br />
|s201828<br />
|[[Successive Cost Estimation]]<br />
|-<br />
|-<br />
|Group Name: TBD<br />
|Gustav<br />
|Gregersen<br />
|s153930<br />
|[[DMAIC]]<br />
|-<br />
|-<br />
|Group Name: TBD<br />
|Simon<br />
|Widmer<br />
|s210449<br />
|[[Scaled Agile Framework]]<br />
|-<br />
|-<br />
|Group Name: TBD<br />
|Casper<br />
|Stenbaek<br />
|s183504<br />
|[[Causes and effects of stress in project management]]<br />
|-<br />
|-<br />
|Group name : 40<br />
|Chloé<br />
|Alcalde<br />
|s212522<br />
|[[Waterfall model]]</div>S212522http://13.50.150.85/index.php?title=Waterfall_model&diff=102343Waterfall model2022-02-06T15:52:43Z<p>S212522: Created page with "This page will describe the waterfall model in project management."</p>
<hr />
<div>This page will describe the waterfall model in project management.</div>S212522