The waterfall system development life cycle (SDLC) is a methodology whereby a product, be it hardware, software or both, is developed from start to finish in a totally linear fashion, which one phase following the next through to completion, and when considered properly, beyond.
For the points made below I am considering a software-only system.
Traditionally, the waterfall method consists of the the following key phases:
- Plan
- Define
- Design
- Build
- Test
- Deploy
- Maintain
In addition there are two other phases that do not always get considered:
- Evaluation
- Disposal
Waterfall Phases
Plan
The planning phase involves all key stakeholders in the project and is used to ascertain the benefits of the proposed project and in most cases involves working out how quickly a return of investment can be obtained, as this is often a key driver as to whether the project is deemed feasible or not.
Define
This is where the features of the proposed software are locked down, based in part on discussions that took place in the “Plan” phase. These features and other aspects are tied down in a document formally known as a “Statement of Requirements”, which in the games industry is more normally known as a Game Design Document (GDD).
The “Statement of Requirements” introduces the term “SMART requirements” where SMART means Specific, Measurable, Achievable, Relevant and Time bound, and all these key words must apply to the “Statement of Requirements”.
Design
This is where the software is designed. This simply means that this is the phase where system architects choose how each module within the project will interact with other modules to form a fully functioning system, from a set of sub-systems. The finished design comes in the form of a document known as a “System Design Document”, which defines the rules and parameters of the software system as a whole.
Build
Once the “System Design Document” has been signed off and accepted by all stakeholders, it is usually passed to the build team, who are tasked with actually writing the software itself. In smaller companies this may well even be the people who wrote the design, but where it is not the build team are fully reliant on the “Statement of Requirements” and more importantly the “System Design Document” to actually start bringing the system to life.
Test
The test phase is a bit of a misnomer, as a lot of testing is carried out during the build phase anyway, as is normal in software development. Here though, this refers to a more rigorous testing and fixing phase towards the end of a project. The equivalent to letting a Q.A. department loose on testing game software. As long as the documents leading up to this point have been well written and received, this phase should only be used for testing and fixing, not adding product features.
Once heavy internal testing has been completed, depending on the type of software being developed, it might be released to members of the public for “beta” testing. Again, this yields a test and fix cycle.
Deploy
Once the software meets the “Statement of Requirements”, has been developed according to the “System Design Document” and has been deemed to have been sufficiently tested, it is ready for deployment to the target audience for the software.
Depending on how the development has been planned, the initial deployment might only be key features of the software, with other features to be released as part of another whole waterfall SDLC. This is not uncommon.
Maintain
The maintenance phase is as equally important as any of the other phases, but is one often under-valued. In this day and age, as software gets more and more complex, it becomes harder and harder to ensure that deployed software is entirely bug-free. The maintenance phase should be there to be able to pick up any issues that had been missed, and fix them, or to add features that are needed. Maintenance tends to taper off over the life of the software, with a high need early on.
Evaluation
The smartsheet website 1 agrees with what I have always believe the good “end of a project” to be.
Once software has been deployed it is useful for all parties from all stage to come together for a “post-mortem”. This stage can be used to find out what went well, what didn’t, and what can be done to improve aspects of development for any subsequent projects. For me this is a hugely important phase.
Disposal
This phase can be looked at in a number of ways. As we are only considering a software project here, I would say this phase is mainly concerned with the software end of life, and what happens to any client data, whether primary or exhaust data once the product essentially dies, and should also consider upgrade paths.
For me, this can also be used for team management and code management, and is almost a direct consequence of the valuation phase.
A good evaluation can be used to find team members who did not perform and they can be disposed of from the roles they played. This does not always mean getting rid of them from the team, but more often moving them into a role better suited to their skillset, to help create a better performing team.
A good evaluation can also identify areas of code that might need attention as they might be underperforming and so need to be dropped and replaced as part of the maintenance phase.
Personal Opinion
For large projects, with large, professional teams, and highly focussed stakeholders, I think the waterfall method tends to work very well, but only if the “Plan”, “Define” and “Design” phases are absolutely spot on.
If there is any slip or errors in those phases they tend to multiply as you progress, and can potentially end up with a poor product.