The Waterfall Model
(→Systems Development) |
(→Systems Development) |
||
| Line 49: | Line 49: | ||
'''State''' | '''State''' | ||
| − | This phase is in some descriptions of the waterfall model also called the design phase because this phase is all about describing the architecture of the system and document it. <ref name="Large-Scale"/> This can be done by converting all the detailed requirements, from the previous phase, into a completed detailed systems design. | + | This phase is in some descriptions of the waterfall model also called the design phase because this phase is all about describing the architecture of the system and document it. <ref name="Large-Scale"/> This can be done |
| − | The detailed systems design is a description of the | + | by converting all the detailed requirements, from the previous phase, into a completed detailed systems design. The detailed systems design is a detailed description of how the required functionalities (must- and wish- list) |
| + | can be delivered to the system which includes a pricise description of the key components and the interface for the components. | ||
| + | |||
| + | |||
| + | focuses on | ||
'''Gate''' | '''Gate''' | ||
Revision as of 15:07, 2 March 2022
The waterfall model is a Software Development Life Cycle model (SDLC) and was the first process model to be introduced. The waterfall model is easy to understand and use, it is a stage gate model which means that the model consists of stages and gates. Each phase consists of one stage and one gate. Each phase has some pre-determined activities and requirements. The current phase must be completed before the next phase can begin and to end a phase it must pass a gate. A stage is the activities, and the gate is the requirement and the review that determine whether a project can continue. The waterfall model consists of six different stages, 1) Requirements Gathering and Analysis, 2) Systems Development, 3) Systems Implementation and Coding, 4) Testing, 5) Deployment, 6) Systems Operations and Maintenance.
The waterfall model is widely used for software development, but it is also a widely criticized model. The model is often criticized for the late detection of defects in the process and how to handle change requests among other things. It is most optimal to use the waterfall model for simple projects with clear reqirements and projects that do not change through the development process.
Contents |
About
The first description of the Waterfall model was written by Winston W. Royce in 1970. Back then he did not call it the Waterfall model. [1] Later it got the name because all the phases are done one by one and flows downwards like a waterfall. It is the finest and oldest known Software Development Life Cycle model (SDLC). There are defined and designed various Software Development Life Cycle models such as V-Shaped model, Big Bang Model, Iterative model etc. [2] These models are also called Software Development Process Models and are all "process consisting of a sequence of planned phases to develop or to amend the software products." [3]
Application of the Waterfall model
To be a good project manager it is important to be familiar with a list of different project life cycle models and be aware of where and when to use which project life cycle whether it is a predictive or an adaptive lifecycle. To understand where and when the waterfall model potentially works best an adapted version of Stacey's matrix from Domain I: Agile Principles and Mindset by Sumanta Boral [4] is used. The Stacey Matrix is published and developed by Ralph Douglas Stacey. It is developed to give an understanding of which factors there contributes to complexity and how to address the different degrees of complexity and with that knowledge choose the best suited project life cycle. [5] The Stacey matrix is a two dimensional matrix where uncertainty of the requirements are plottet against the perceived disagreement of the stakeholders. [4]
A project are close to certainty when "How" is well known for example if a similar project, decision or issue have been done before and therefor the effect and cause relationship is well known. Because then there will be some experiences and learnings there can be used to predict the "How" and set up the needed requirements from the beginning. [4] [5]
A project are far from certainty if the project is new to the project manager for example if it is about something new or it is an innovative project. Then it can be hard to set up the needed requirements from the beginning and therefor there will be a lot of uncertainties about the "How" and the unclear relationship between cause and effect. [4] [5]
A projects level of agreement is a measurement of the level of agreement about decisions and issues within the project group, the management team and the stakeholders. This is important because the project manager function varies based on the level of agreement. [4] [5]
The Waterfall model is placed in the bottom left corner in the zone that is called "simple" as illustrated on the figure. In this region the requirements are almost certain and there is a good consensus around the project. In this zone the decision making is based on reliable data gathered from the past to predict the future. [4]
The waterfall model
The waterfall model is a stage gate model which is a category of life cycle models. A stage gate model consists of multiple phases, each phase includes one stage and one gate, to get from one phase to another the project has to pass a gate. A stage consists of a description of activities there needs to be done during each state, the gate is the requirement and the review that determine whether a project can continue. The phases has to be processed in order without overlapping and within a specified timeframe. In the waterfall model it is not possible to move back and forth between phases, once a phase is completed it will be frozen and therefore it is not possible to move back and work on it again. The waterfall model consists of 6 phases, 1) Requirements Gathering and Analysis, 2) Systems Development, 3) Systems Implementation and Coding, 4) Testing, 5) Deployment, 6) Systems Operations and Maintenance. To achieve a positive outcome all six phases must be completed. [2]
Requirements Gathering and Analysis
State
In the first phase the customers needs are identified and documented. Afterwords the identified needs has to be redefined as requirements to use them as input to the system development phase. The number of requirements can variate and depends on the available resources. Because when a new product has to be build it is not build from scratch only. It is typically build on top of parts of old products which are used as input to the requirement phase. [1] In the first phase the project manager are planing the project by gathering the requirements from the organization and the stakeholders and begin the analysis to determine the project approach, deliverables, and anticipated outcomes to gather the non-functional and functional requirements. [2]
Gate
At this gate all the requirements has to be checked wether they are understood, agreed upon and documented. It also has to be controlled whether all the relevant stakeholders are identified. [1]
Deliverables: Functional and Business requirements and Requirements Understanding Document (RUD) [2]
Systems Development
State
This phase is in some descriptions of the waterfall model also called the design phase because this phase is all about describing the architecture of the system and document it. [1] This can be done by converting all the detailed requirements, from the previous phase, into a completed detailed systems design. The detailed systems design is a detailed description of how the required functionalities (must- and wish- list) can be delivered to the system which includes a pricise description of the key components and the interface for the components.
focuses on
Gate
This gate is a quality checklist that verifies the evaluation of the architecture, which includes checking for deviations between the design and requirements from the previous gate. Other than that there also have to be looked for deviations in the effort, planned timeline or product scope.[1]
Deliverables: Low-Level Design document (LLD) and High-Level Design Document (HLD)[2]
Systems Implementation and Coding
Testing
Deployment
Systems Operations and Maintenance
Best Practice
"The evolution of software that satisfies its user expectations is a necessary goal of a successful software development organization. To achieve this goal, software engineering practices must be applied throughout the evolution of the software product. Most of these software engineering practices attempt to create and modify software in a manner that maximizes the probability of satisfying its user expectations. Other practices, addressed in this module, actually attempt to insure that the product will meet these user expectations.” (James S. Collofello, 1998)[6]
Requirements Gathering and Analysis
In this phase it would be a good idea to hire a Business Analyst to ensure that the functional requirements and business requirements meets the stakeholder's expectations. Business requirements is about determine the software user and how the software will be used. The business analyst will conduct a needs analysis together with the end user of the system. Because the end user knows or have an idea of which results they expect and information they want from the system. In this state it is important to capture all the requirements, this can be done by using user or test cases, flowcharts and current documentation. [2]
Another best practices for the needs analysis is to arrange a meeting with the stakeholders either one on one or all together in a group to find out and understand their requirements, discussing any challenges and to receive all documentation on the current phase. It is important to make a documented outline of each process in collaboration with the stakeholders which include a complete description and understanding of their needs which can be separated into must have and wish list. when making the documentation it is a good idea to use visuals like flowcharts, diagrams and screenshots. It is important that the document include purpose, current processes, details of expected accomplishments and expectations. [2]
Systems Development
Systems Implementation and Coding
Testing
Deployment
Systems Operations and Maintenance
Pros and cons
Ref
Petersen K., Wohlin C., Baca D. (2009) The Waterfall Model in Large-Scale Development. In: Bomarius F., Oivo M., Jaring P., Abrahamsson P. (eds) Product-Focused Software Process Improvement. PROFES 2009. Lecture Notes in Business Information Processing, vol 32. Springer, Berlin, Heidelberg. https://doi-org.proxy.findit.cvt.dk/10.1007/978-3-642-02152-7_29
Kramer, Mitch, Best Practices in Systems Development Lifecycle: An Analyses Based on the Waterfall Model (2018). Review of Business & Finance Studies, v. 9 (1) p. 77-84, Available at SSRN: https://ssrn.com/abstract=3131958
http://tryqa.com/what-is-waterfall-model-advantages-disadvantages-and-when-to-use-it/
References
- ↑ 1.0 1.1 1.2 1.3 1.4 Petersen K., Wohlin C., Baca D. (2009) The Waterfall Model in Large-Scale Development. In: Bomarius F., Oivo M., Jaring P., Abrahamsson P. (eds) Product-Focused Software Process Improvement. PROFES 2009. Lecture Notes in Business Information Processing, vol 32. Springer, Berlin, Heidelberg. https://doi-org.proxy.findit.cvt.dk/10.1007/978-3-642-02152-7_29
- ↑ 2.0 2.1 2.2 2.3 2.4 2.5 2.6 Kramer, Mitch, Best Practices in Systems Development Lifecycle: An Analyses Based on the Waterfall Model (2018). Review of Business & Finance Studies, v. 9 (1) p. 77-84, Available at SSRN: https://ssrn.com/abstract=3131958
- ↑ Dubey A.; Jain A.; Mantri A., "Comparative Study: Waterfall v/s Agile Model", International Journal of Engineering Sciences & Research Technology (IJESRT), 2015
- ↑ 4.0 4.1 4.2 4.3 4.4 4.5 Boral S.,"Domain I: Agile Principles and Mindset", Ace the Pmi-acp pp. 1-27, 2016
- ↑ 5.0 5.1 5.2 5.3 Stacey RD. Strategic management and organisational dynamics: the challenge of complexity. 3rd ed. Harlow: Prentice Hall, 2002
- ↑ James S. Collofello, (1998) “Introduction to Software Verification and Validation” SEI Curriculum Module SEI-CM-13-1.1, Carnegie Mellon University Software Engineering Institute
