The Waterfall Model
(→Best Practice) |
(→Disadvantages) |
||
| (64 intermediate revisions by one user not shown) | |||
| Line 1: | Line 1: | ||
| − | The | + | This article is focusing on when and how the Waterfall Model should be used in a software development environment. The Waterfall Model is a Software Development Life Cycle model (SDLC) and was the first process model 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 requirements 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 | + | |
| − | + | ||
| − | + | ||
| + | The Waterfall Model is widely used for software development, but it is also widely criticized. The model is often criticized for the late detection of defects in the process and how to handle change requests. It is most optimal to use the Waterfall Model for simple projects with precise requirements and projects that do not change through the development process. | ||
==About== | ==About== | ||
| − | + | Winston W. Royce wrote the first description of the Waterfall Model in 1970. Back then, he did not call it the Waterfall Model. <ref name="Large-Scale"> 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. doi: https://doi-org.proxy.findit.cvt.dk/10.1007/978-3-642-02152-7_29 </ref> Later, it got the name because all the phases are done one by one and flow downwards like a waterfall. It is the finest and oldest known SDLC model. There are defined and designed various SDLC models such as V-Shaped model, Big Bang Model, Iterative model, etc. <ref name="Best Practices"> Kramer, M. (2018) 'Best Practices in Systems Development Lifecycle: An Analyses Based on the Waterfall Model', Review of Business & Finance Studies, v. 9 (1) p. 77-84, SSRN: https://ssrn.com/abstract=3131958</ref> 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.”'' (Dubey, 2009)<ref> Dubey, A. Jain, A. Mantri, A. (2015) 'Comparative Study: Waterfall v/s Agile Model', International Journal of Engineering Sciences & Research Technology (IJESRT) </ref> | |
| − | =Application of the Waterfall | + | =Application of the Waterfall Model= |
| − | + | [[File:TheStaceyMatrix.png|thumb|right|500px|Figure 1: Application of the Waterfall Model<ref name= "Agile Principles"/>]] | |
| − | To understand where and when the | + | A good project manager is familiar with different project life cycle models and knows 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<ref name= "Agile Principles"> Boral, S. (2016). Domain I: Agile Principles and Mindset. In: Ace the PMI-ACP® exam. Apress, Berkeley, CA. https://doi.org/10.1007/978-1-4842-2526-4_1</ref> is used. The Stacey Matrix was published and developed by Ralph Douglas Stacey. It is developed to give an understanding of which factors there contribute to the complexity and how to address the different degrees of complexity and, with that knowledge, choose the best-suited project life cycle. <ref name="strategic management"> Stacey RD. Strategic management and organizational dynamics: the challenge of complexity. 3rd ed. Harlow: Prentice Hall, 2002 </ref> |
| − | The Stacey Matrix | + | The Stacey Matrix is a two-dimensional matrix where the uncertainty of the requirements is plotted against the perceived disagreement of the stakeholders. <ref name= "Agile Principles"/> |
| − | The Stacey | + | |
| − | |||
| + | '''A project is close to certainty''' when "How" is well known, for example, if a similar project, decision, or issue has been done before, and therefore 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. <ref name= "Agile Principles"/> <ref name="strategic management"/> | ||
| − | |||
| + | '''A project is far from certainty''' if the project is new to the project manager, such as an innovative project or something unknown to the project manager. Then it can be hard to set up the needed requirements from the beginning, and therefore there will be a lot of uncertainties about the "How" and the unclear relationship between cause and effect. <ref name= "Agile Principles"/> <ref name="strategic management"/> | ||
| − | |||
| + | '''A project's level of agreement''' is a measurement of agreement about decisions and issues within the project group, the management team, and the stakeholders. It is important because the project manager function varies based on the level of agreement. <ref name= "Agile Principles"/> <ref name="strategic management"/> | ||
| − | |||
| + | The Waterfall Model is placed in the bottom left corner in the zone called ''"simple,"'' as illustrated in the figure. The requirements are almost certain in this region, 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. <ref name= "Agile Principles"/> | ||
| − | The Waterfall | + | =The Waterfall Model= |
| − | + | [[File:WaterfallModel.png|thumb|right|600px|Figure 2: 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. The project has to pass a gate to get from one phase to another. A stage consists of a description of activities there need to be done during each state. The gate is the requirement and the review that determines whether a project can continue. The phases must 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 freeze, 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. All six phases must be completed to achieve a positive outcome. <ref name="Best Practices"/> | |
| − | [[File: | + | |
| − | The | + | |
==1. Requirements Gathering and Analysis== | ==1. Requirements Gathering and Analysis== | ||
| − | + | '''State''' | |
| − | In the first phase the customer's needs are identified and documented. | + | |
| − | In the first phase the project manager | + | In the first phase, the customer's needs are identified and documented. Afterward, the identified needs have to be redefined as requirements to use as input to the system development phase. The number of requirements can variate and depends on the available resources. Because when a new product is made, it is not made from scratch only. It is typically made on top of parts of old products, which are used as input to the requirement phase. <ref name="Large-Scale"/> |
| + | In the first phase, the project manager plans the project by gathering the requirements from the organization and the stakeholders and beginning the analysis to determine the project approach, deliverables, and anticipated outcomes to gather the non-functional and functional requirements. <ref name="Best Practices"/> | ||
| + | |||
| + | |||
| + | '''Gate''' | ||
| − | + | All requirements must be checked at this gate. Whether they are understood, agreed upon, and documented. It also has to be controlled whether all the relevant stakeholders are identified. <ref name="Large-Scale"/> | |
| − | + | ||
Deliverables: Functional and Business requirements and Requirements Understanding Document (RUD) <ref name="Best Practices"/> | Deliverables: Functional and Business requirements and Requirements Understanding Document (RUD) <ref name="Best Practices"/> | ||
==2. Systems Development== | ==2. Systems Development== | ||
| − | + | '''State''' | |
| − | This phase is in some descriptions of the | + | |
| + | This phase is in some descriptions of the Waterfall Model called the design phase because this phase is all about describing the architecture of the system and documenting 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. The detailed systems design is a detailed description of how the required functionalities (must- and wish- list) | 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 | + | can be delivered to the system. It includes an accurate description of the key components and the interface for the components.<ref name="Best Practices"/> |
| + | |||
| + | |||
| + | '''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.<ref name="Large-Scale"/> | |
| − | 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.<ref name="Large-Scale"/> | + | |
Deliverables: Low-Level Design document (LLD) and High-Level Design Document (HLD)<ref name="Best Practices"/> | Deliverables: Low-Level Design document (LLD) and High-Level Design Document (HLD)<ref name="Best Practices"/> | ||
==3. Systems Implementation and Coding== | ==3. Systems Implementation and Coding== | ||
| − | + | '''State''' | |
| − | In this phase, all the information, requirements, and analysis gathered in the two previous phases are converted into code. This will show whether the previous phases | + | |
| − | Before moving on to the next phase the developer conducts | + | In this phase, all the information, requirements, and analysis gathered in the two previous phases are converted into code. This will show whether the previous phases are documented well enough for the developer to develop the application and implement the design. Depending on the size of the application, this can be the longest phase of the Waterfall Model. <ref name="Best Practices"/> |
| + | Before moving on to the next phase, the developer conducts basic unit tests to ensure that the application is running. <ref name="Large-Scale"/> | ||
| + | |||
| + | |||
| + | '''Gate''' | ||
| − | |||
This gate is about verifying that the developed application and design do not deviate from the requirements or agreements from previous states. <ref name="Large-Scale"/> | This gate is about verifying that the developed application and design do not deviate from the requirements or agreements from previous states. <ref name="Large-Scale"/> | ||
| − | Deliverables: Unit test cases, results and the application delivered by the developer. <ref name="Best Practices"/> | + | Deliverables: Unit test cases, results, and the application delivered by the developer. <ref name="Best Practices"/> |
==4. Testing== | ==4. Testing== | ||
| − | + | '''State''' | |
| − | This phase involves testing and verifying that the application delivers the quality and functionality needed by performing an | + | |
| + | This phase involves testing and verifying that the application delivers the quality and functionality needed by performing an integration test. The individual software modules are combined in a group and tested. <ref name="Large-Scale"/> | ||
Other test methods can also be performed, such as use test cases, stress tests, module unit testing, Etc. It is crucial to track the progress when performing the tests. It is done by reporting all test activities, including the issues raised along the way.<ref name="Best Practices"/> | Other test methods can also be performed, such as use test cases, stress tests, module unit testing, Etc. It is crucial to track the progress when performing the tests. It is done by reporting all test activities, including the issues raised along the way.<ref name="Best Practices"/> | ||
| − | + | ||
| + | '''Gate''' | ||
| + | |||
This gate is a review of the checklist to verify deviations between the application performance in terms of quality, requirements, and other terms from the previous gates. <ref name="Large-Scale"/> | This gate is a review of the checklist to verify deviations between the application performance in terms of quality, requirements, and other terms from the previous gates. <ref name="Large-Scale"/> | ||
| Line 76: | Line 83: | ||
==5. Deployment== | ==5. Deployment== | ||
| − | + | '''State''' | |
| − | Now that the application and design have passed the test phase it can | + | |
| − | In this phase, the application is presented to the end-user to ensure the application and design meet the needs and ensure that the specifications | + | Now that the application and design have passed the test phase, it can be deployed. |
| + | In this phase, the application is presented to the end-user to ensure the application and design meet the needs and ensure that the specifications are right. | ||
It also proves whether the application and design perform as intended when placed in the intended environment. This kind of end-user validation test is called User Acceptance Testing (UAT).<ref name="Large-Scale"/> <ref name="Best Practices"/> | It also proves whether the application and design perform as intended when placed in the intended environment. This kind of end-user validation test is called User Acceptance Testing (UAT).<ref name="Large-Scale"/> <ref name="Best Practices"/> | ||
Another part of the deployment phase is to train the end-user to use the new application. | Another part of the deployment phase is to train the end-user to use the new application. | ||
| − | It is important to log every issue during this state. It is acceptable if there | + | It is important to log every issue during this state. It is acceptable if there are issues as long it is not critical or high-level defects. If any minor issues occur, this will be handled in the Systems Operations and Maintenance phase.<ref name="Best Practices"/> |
| − | + | ||
| − | To get through this gate the application and design have to meet the customers' requirements, which includes its, presented in time, | + | '''Gate''' |
| + | |||
| + | To get through this gate, the application and design have to meet the customers' requirements, which includes its, presented in time, fulfills the customers' quality requirements, and the customer can accept the outcome. <ref name="Large-Scale"/> | ||
Deliverables: Environment Definition Specification and Issues Log <ref name="Best Practices"/> | Deliverables: Environment Definition Specification and Issues Log <ref name="Best Practices"/> | ||
==6. Systems Operations and Maintenance== | ==6. Systems Operations and Maintenance== | ||
| − | + | '''State''' | |
| + | |||
The last phase is when the application and design are ready to be released for the customer. After the release, some technical issues can occur, or the customer can discover new problems. Therefore it is essential to have an issue log open and conduct maintenance while releasing an application. Hiring technical and procedural experts is vital because the end-users will have questions. <ref name="Large-Scale"/> <ref name="Best Practices"/> | The last phase is when the application and design are ready to be released for the customer. After the release, some technical issues can occur, or the customer can discover new problems. Therefore it is essential to have an issue log open and conduct maintenance while releasing an application. Hiring technical and procedural experts is vital because the end-users will have questions. <ref name="Large-Scale"/> <ref name="Best Practices"/> | ||
| − | + | ||
| − | In this phase, there is no gate because the state is an ongoing process. There are some documents there can be a good idea to keep updated to keep an overview of the operation and maintenance. If a new application needs to be developed, The | + | '''Gate''' |
| + | |||
| + | In this phase, there is no gate because the state is an ongoing process. There are some documents there can be a good idea to keep updated to keep an overview of the operation and maintenance. If a new application needs to be developed, The Waterfall Model can be used again from the beginning. | ||
Deliverables: User Manual, List of Production Tickets (Resolved), List of New Features Implemented | Deliverables: User Manual, List of Production Tickets (Resolved), List of New Features Implemented | ||
| Line 99: | Line 112: | ||
=Best Practice= | =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.”'' (James S. Collofello, 1998)<ref>James S. Collofello, (1998) “Introduction to Software Verification and Validation” SEI Curriculum Module SEI-CM-13-1.1, Carnegie Mellon University Software Engineering Institute</ref> |
==Requirements Gathering and Analysis== | ==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 | + | In this phase, it would be a good idea to hire a Business Analyst to ensure that the functional requirements and business requirements meet the stakeholder's expectations. Business requirements are about determining 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 has 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. <ref name="Best Practices"/> |
| − | Another best practice 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, | + | Another best practice 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, discuss any challenges, and 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. <ref name="Best Practices"/> |
| Line 119: | Line 132: | ||
== Testing == | == Testing == | ||
| − | In the testing phase it | + | In the testing phase, it is best practice to have the Business Architect or/and Analyst review the issues log, Test Cases, test, and defect reports because they are the ones who provided the design specs and therefore also the ones who know what is intended and what to expect. If the application does not meet the exceptions from the Business Architect or/and Analyst, it needs to go back to the Developer to correct the issues. This verification process is a way to ensure that the application works as designed. <ref name="Best Practices"/> |
| − | This verification process is a way to ensure that the application works as designed. | + | |
| − | + | ||
== Deployment == | == Deployment == | ||
| − | + | A best practice in the deployment phase would be to load the application into a test system before moving it into production. When doing this, it is vital to have an exit strategy if something goes wrong with the data conversion, especially a backup is needed. Another best practice is making a user manual for the end-user, assisting the training to learn how to use the application. This user manual can also be good for the end-user for future clarifications or references. <ref name="Best Practices"/> | |
== Systems Operations and Maintenance == | == Systems Operations and Maintenance == | ||
| + | In the Systems Operations and Maintenance phase, a best practice would be to keep an eye on the open issues log and resolve every reported issue. Another best practice is to ensure that the code gets updated in the coding environment and the development environment every time an issue is corrected. It is vital because the application evolves over time, and if changes are not incorporated in all environments, the coding environment and the development environment will begin to act differently. <ref name="Best Practices"/> | ||
| + | |||
| + | =Advantages= | ||
| + | The Waterfall Model is widely used and recognized in the industry because of its precise and rigid stages. It is easy to understand and thereby also easy to implement. It is methodical, simple, and works well. Other than that, it is easy to maintain because of the one at a time stage execution and easy to identify deliverables and milestones, which helps to ensure the quality. The Waterfall Model is not a stressful model because of the well-defined start and finish criteria. <ref name="Large-Scale"/><ref name="Best Practices"/> | ||
| + | |||
| + | =Disadvantages= | ||
| + | The Waterfall Model has always been widely criticized because of the significant disadvantage: it cannot handle any considerable requirement changes during the project, especially after reaching the testing phase, it is difficult to change. It is difficult for the Waterfall Model to handle a requirement change because all the previous phases must be changed together with previous documentation. Therefore, it is recommended to use another model than the Waterfall Model if it is known before the beginning of the project that there might be changes during the project.<ref name="Large-Scale"/><ref name="Best Practices"/> | ||
| + | |||
| + | Another disadvantage is that the final product often has an extended delivery; this can be because there is no previous available prototype to compare to the developed application. The risk of error is higher without a prototype, and errors can be a big problem with the Waterfall Model. Because the testing phase is late in the process, it can be hard to identify risks, errors, and challenges in an early phase.<ref name="Large-Scale"/><ref name="Best Practices"/> | ||
| + | |||
| + | =Annotated bibliography= | ||
| + | |||
| + | '''Petersen, K. Wohlin, C. Baca, D. (2009) 'The Waterfall Model in Large-Scale Development',''' <ref name="Large-Scale"/> | ||
| + | |||
| + | This article aims to provide empirical evidence about the Waterfall Model to address what they call a research gap between the problems mentioned in literature and empirical evidence. This is done through a case study at Ericsson AB in Sweden. This case study aims to investigate the issues mentioned in the literature about the Waterfall Model. Through the case study, they found the same issues as described in the literature, but they could give a more detailed explanation of the issues with the case study. | ||
| + | |||
| − | = | + | '''Kramer, M. (2018) 'Best Practices in Systems Development Lifecycle: An Analyses Based on the Waterfall Model','''<ref name="Best Practices"/> |
| − | + | This article discusses the theory, best practice, and gate deliverables for the Systems Development Lifecycle; the analyses and discussion are based on the Waterfall Model. The author Kramer, M. have worked on and completed numerous projects using different models for businesses to Fortune 1000 companies. At the end of the article, the advantages and disadvantages of the Waterfall Model are discussed. | |
| − | |||
| − | + | '''Boral, S. (2016). 'Domain I: Agile Principles and Mindset','''<ref name= "Agile Principles"/> | |
| − | + | This book is written for the PMI-ACP certification. PMI-ACP stands for Project Management Institute Agile Certified Practitioner. The course aims to develop an agile mindset and, through that, develop a better project management mindset. The certification is offered by PMI. The book describes the foundation concepts of the Agile framework and clarifies the difference between the traditional waterfall-based project management and the agile framework and principles. | |
=References= | =References= | ||
<references/> | <references/> | ||
Latest revision as of 14:42, 27 March 2022
This article is focusing on when and how the Waterfall Model should be used in a software development environment. The Waterfall Model is a Software Development Life Cycle model (SDLC) and was the first process model 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 requirements 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 widely criticized. The model is often criticized for the late detection of defects in the process and how to handle change requests. It is most optimal to use the Waterfall Model for simple projects with precise requirements and projects that do not change through the development process.
Contents |
[edit] About
Winston W. Royce wrote the first description of the Waterfall Model 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 flow downwards like a waterfall. It is the finest and oldest known SDLC model. There are defined and designed various SDLC 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.” (Dubey, 2009)[3]
[edit] Application of the Waterfall Model
A good project manager is familiar with different project life cycle models and knows 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 was published and developed by Ralph Douglas Stacey. It is developed to give an understanding of which factors there contribute to the 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 the uncertainty of the requirements is plotted against the perceived disagreement of the stakeholders. [4]
A project is close to certainty when "How" is well known, for example, if a similar project, decision, or issue has been done before, and therefore 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 is far from certainty if the project is new to the project manager, such as an innovative project or something unknown to the project manager. Then it can be hard to set up the needed requirements from the beginning, and therefore there will be a lot of uncertainties about the "How" and the unclear relationship between cause and effect. [4] [5]
A project's level of agreement is a measurement of agreement about decisions and issues within the project group, the management team, and the stakeholders. It 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 called "simple," as illustrated in the figure. The requirements are almost certain in this region, 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]
[edit] 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. The project has to pass a gate to get from one phase to another. A stage consists of a description of activities there need to be done during each state. The gate is the requirement and the review that determines whether a project can continue. The phases must 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 freeze, 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. All six phases must be completed to achieve a positive outcome. [2]
[edit] 1. Requirements Gathering and Analysis
State
In the first phase, the customer's needs are identified and documented. Afterward, the identified needs have to be redefined as requirements to use as input to the system development phase. The number of requirements can variate and depends on the available resources. Because when a new product is made, it is not made from scratch only. It is typically made on top of parts of old products, which are used as input to the requirement phase. [1] In the first phase, the project manager plans the project by gathering the requirements from the organization and the stakeholders and beginning the analysis to determine the project approach, deliverables, and anticipated outcomes to gather the non-functional and functional requirements. [2]
Gate
All requirements must be checked at this gate. Whether 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]
[edit] 2. Systems Development
State
This phase is in some descriptions of the Waterfall Model called the design phase because this phase is all about describing the architecture of the system and documenting 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. It includes an accurate description of the key components and the interface for the components.[2]
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]
[edit] 3. Systems Implementation and Coding
State
In this phase, all the information, requirements, and analysis gathered in the two previous phases are converted into code. This will show whether the previous phases are documented well enough for the developer to develop the application and implement the design. Depending on the size of the application, this can be the longest phase of the Waterfall Model. [2] Before moving on to the next phase, the developer conducts basic unit tests to ensure that the application is running. [1]
Gate
This gate is about verifying that the developed application and design do not deviate from the requirements or agreements from previous states. [1]
Deliverables: Unit test cases, results, and the application delivered by the developer. [2]
[edit] 4. Testing
State
This phase involves testing and verifying that the application delivers the quality and functionality needed by performing an integration test. The individual software modules are combined in a group and tested. [1] Other test methods can also be performed, such as use test cases, stress tests, module unit testing, Etc. It is crucial to track the progress when performing the tests. It is done by reporting all test activities, including the issues raised along the way.[2]
Gate
This gate is a review of the checklist to verify deviations between the application performance in terms of quality, requirements, and other terms from the previous gates. [1]
Deliverables: Test Cases, Test Reports, Defect Reports, Issues Log [2]
[edit] 5. Deployment
State
Now that the application and design have passed the test phase, it can be deployed. In this phase, the application is presented to the end-user to ensure the application and design meet the needs and ensure that the specifications are right. It also proves whether the application and design perform as intended when placed in the intended environment. This kind of end-user validation test is called User Acceptance Testing (UAT).[1] [2] Another part of the deployment phase is to train the end-user to use the new application. It is important to log every issue during this state. It is acceptable if there are issues as long it is not critical or high-level defects. If any minor issues occur, this will be handled in the Systems Operations and Maintenance phase.[2]
Gate
To get through this gate, the application and design have to meet the customers' requirements, which includes its, presented in time, fulfills the customers' quality requirements, and the customer can accept the outcome. [1]
Deliverables: Environment Definition Specification and Issues Log [2]
[edit] 6. Systems Operations and Maintenance
State
The last phase is when the application and design are ready to be released for the customer. After the release, some technical issues can occur, or the customer can discover new problems. Therefore it is essential to have an issue log open and conduct maintenance while releasing an application. Hiring technical and procedural experts is vital because the end-users will have questions. [1] [2]
Gate
In this phase, there is no gate because the state is an ongoing process. There are some documents there can be a good idea to keep updated to keep an overview of the operation and maintenance. If a new application needs to be developed, The Waterfall Model can be used again from the beginning.
Deliverables: User Manual, List of Production Tickets (Resolved), List of New Features Implemented
[edit] 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.” (James S. Collofello, 1998)[6]
[edit] 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 meet the stakeholder's expectations. Business requirements are about determining 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 has 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 practice 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, discuss any challenges, and 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]
[edit] Systems Development
Business Architects would be helpful to hire in the Systems development phase. Business architects are specialists in producing designs of products. They know whether a developer can deliver the design or not. Therefore business architects can produce several functional designs from the requirements gathered in the first stage. These designs are then presented to the internal stakeholders, who can review the designs in a design document and approve the best design. After choosing the design, the business architects can finalize the design by creating the blueprint of the design, which includes all the necessary specifications about data resources, software, people, and information about coding and how to debug the application.[2]
Best practice in the system development phase would be to describe the system characteristics and operations in detail by having a low-level and a high-level design document. These design documents include detailed descriptions of the desired characteristics of the software. It includes screen format maps, functional hierarchy diagrams, tables, business rules; business processes diagrams, pseudo-code, and an entity-relationship diagram of the data dictionary.[2] This design documentation is to assist the developer in the development process and make sure that additional input required will be held to a minimum. Another best practice is to include sign-off on all documents for the stakeholders.[2]
[edit] Systems Implementation and Coding
Best practice in this phase is that the developer verifies that the application works according to the design specifications.[2]
[edit] Testing
In the testing phase, it is best practice to have the Business Architect or/and Analyst review the issues log, Test Cases, test, and defect reports because they are the ones who provided the design specs and therefore also the ones who know what is intended and what to expect. If the application does not meet the exceptions from the Business Architect or/and Analyst, it needs to go back to the Developer to correct the issues. This verification process is a way to ensure that the application works as designed. [2]
[edit] Deployment
A best practice in the deployment phase would be to load the application into a test system before moving it into production. When doing this, it is vital to have an exit strategy if something goes wrong with the data conversion, especially a backup is needed. Another best practice is making a user manual for the end-user, assisting the training to learn how to use the application. This user manual can also be good for the end-user for future clarifications or references. [2]
[edit] Systems Operations and Maintenance
In the Systems Operations and Maintenance phase, a best practice would be to keep an eye on the open issues log and resolve every reported issue. Another best practice is to ensure that the code gets updated in the coding environment and the development environment every time an issue is corrected. It is vital because the application evolves over time, and if changes are not incorporated in all environments, the coding environment and the development environment will begin to act differently. [2]
[edit] Advantages
The Waterfall Model is widely used and recognized in the industry because of its precise and rigid stages. It is easy to understand and thereby also easy to implement. It is methodical, simple, and works well. Other than that, it is easy to maintain because of the one at a time stage execution and easy to identify deliverables and milestones, which helps to ensure the quality. The Waterfall Model is not a stressful model because of the well-defined start and finish criteria. [1][2]
[edit] Disadvantages
The Waterfall Model has always been widely criticized because of the significant disadvantage: it cannot handle any considerable requirement changes during the project, especially after reaching the testing phase, it is difficult to change. It is difficult for the Waterfall Model to handle a requirement change because all the previous phases must be changed together with previous documentation. Therefore, it is recommended to use another model than the Waterfall Model if it is known before the beginning of the project that there might be changes during the project.[1][2]
Another disadvantage is that the final product often has an extended delivery; this can be because there is no previous available prototype to compare to the developed application. The risk of error is higher without a prototype, and errors can be a big problem with the Waterfall Model. Because the testing phase is late in the process, it can be hard to identify risks, errors, and challenges in an early phase.[1][2]
[edit] Annotated bibliography
Petersen, K. Wohlin, C. Baca, D. (2009) 'The Waterfall Model in Large-Scale Development', [1]
This article aims to provide empirical evidence about the Waterfall Model to address what they call a research gap between the problems mentioned in literature and empirical evidence. This is done through a case study at Ericsson AB in Sweden. This case study aims to investigate the issues mentioned in the literature about the Waterfall Model. Through the case study, they found the same issues as described in the literature, but they could give a more detailed explanation of the issues with the case study.
Kramer, M. (2018) 'Best Practices in Systems Development Lifecycle: An Analyses Based on the Waterfall Model',[2]
This article discusses the theory, best practice, and gate deliverables for the Systems Development Lifecycle; the analyses and discussion are based on the Waterfall Model. The author Kramer, M. have worked on and completed numerous projects using different models for businesses to Fortune 1000 companies. At the end of the article, the advantages and disadvantages of the Waterfall Model are discussed.
Boral, S. (2016). 'Domain I: Agile Principles and Mindset',[4]
This book is written for the PMI-ACP certification. PMI-ACP stands for Project Management Institute Agile Certified Practitioner. The course aims to develop an agile mindset and, through that, develop a better project management mindset. The certification is offered by PMI. The book describes the foundation concepts of the Agile framework and clarifies the difference between the traditional waterfall-based project management and the agile framework and principles.
[edit] References
- ↑ 1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 1.10 1.11 1.12 1.13 1.14 1.15 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. doi: https://doi-org.proxy.findit.cvt.dk/10.1007/978-3-642-02152-7_29
- ↑ 2.00 2.01 2.02 2.03 2.04 2.05 2.06 2.07 2.08 2.09 2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17 2.18 2.19 2.20 2.21 2.22 2.23 2.24 2.25 2.26 Kramer, M. (2018) 'Best Practices in Systems Development Lifecycle: An Analyses Based on the Waterfall Model', Review of Business & Finance Studies, v. 9 (1) p. 77-84, SSRN: https://ssrn.com/abstract=3131958
- ↑ Dubey, A. Jain, A. Mantri, A. (2015) 'Comparative Study: Waterfall v/s Agile Model', International Journal of Engineering Sciences & Research Technology (IJESRT)
- ↑ 4.0 4.1 4.2 4.3 4.4 4.5 4.6 4.7 Boral, S. (2016). Domain I: Agile Principles and Mindset. In: Ace the PMI-ACP® exam. Apress, Berkeley, CA. https://doi.org/10.1007/978-1-4842-2526-4_1
- ↑ 5.0 5.1 5.2 5.3 Stacey RD. Strategic management and organizational 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
