Waterfall software development methodology has been favoured by teams for years. For some types of project, there can be no better solution than this robust methodology.
Try to imagine a waterfall. It’s a grand display, with freely cascading water. Once the water begins to fall, well – it doesn’t flow back up – the process continues in one direction! Though the process segments into several stages – reverting these processes to their previous respective stage is difficult to impossible.
Waterfall project management contrasts starkly with the relatively new Agile process. In this article, I will enlighten you on all there is to know about this esteemed tried & tested software development methodology.
For a better overview of the differences between these two methodologies, readProject Planning in Software Development: Agile vs Waterfall.
In this article you will learn:
Waterfall Project Management: A Technical Overview
The process began in the 1970s, purely as a concept without a name. Winston W. Royce described the model in 1970. The natural metaphor found its way into an academic paper (authors Bell & Thayer) in 1976.
What makes this model attractive is a straightforward, no-nonsense structure. The logical flow of the process itself made it an essential framework on which people could base their software development.
KEY TAKEAWAY
Key to this method is a lack of process regression, minimal interference from stakeholders, and autonomy from outside influence. Agile takes a conflicting approach, ensuring greater inclusion, with many instances of permitted changes to the outcome of the project.
The differences are stark but specific – you may have read these in one of my previous articles, which describes this at great length.
Who’s involved?
Waterfall is an old-school method, with an old-school command structure.
Larger teams take control of the project, in some cases can consist of more than 15 people in non-interchangeable groups. These individuals involved abide by a strict hierarchy, with the lead role going to the project manager.
We're a team of experienced IT professionals ready to join your Waterfall project.
There are four typical roles within the teams, which I will list according to the stages of the project:
Project Manager – the Leader & Delegator
The central part of every Waterfall team. Their principal responsibility is to ensure the project execution respecting its scope, cost and time. As the title indicates, their duties are delegating and team management.
Business Analyst
This individual ensures the all the business requirements of the software are considered and transformed into artefacts of the functional specification of the system.
Developers – the Codemakers
This member lays down the railroad tracks of the entire project, as the code creator. Their role is integral in that their presence warrants in several separate instances. Such a situation becomes apparent upon bug detection in the software.
Testers – the Codebreakers
The last line of defence of the project report for duty during the projects’ final stages. Their task is to identify bugs and defects within the software – prompting its possible return to developers.
Other Roles
Not all IT projects are created equal, with some requiring additional support. Depending on the size of the project and organisation, that list may be extensive. The following positions listed here are likely to play a part as well:
- Technical Architect – Also known as a Solutions Architect, their role entails designing the structure of IT systems, and oversight of business-optimising programs.
- System Administration and Helpdesk – These individuals are responsible for the day-to-day operations of networks. Their job is to organise, install, and support an organisation’s hardware and computer systems, including LAN and Intranet.
- Quality Manager – Role is responsible for the final quality of software and ensures that the project is performed according to defined processes. It is worth noting that they are not directly a project team member.
Waterfall Model Stages
From stage to stage, this process is very particular.
The waterfall process is exceptional for a reason – it has proven itself time, and time again as the go-to method for software development projects. The process has, of course, refined itself over the years, as it adapts to specific environments.
For this article, I apply the original Winston W. Royce model.
Note: depending on the publication, this may appear with a different title.
Stage 1 – System and Software Requirements
The initial stage consists of outlining and defining.
Potential application requirements are analysed methodologically and written down in a specifications document. Depending on the originating department, this appears as a Product Requirements Document, also known as a Marketing Requirements Document.
The document, written from a user perspective, should outline demands, and define in essence – the objective of the application.
The contents of the document, which range from tens to hundreds of pages, are summarised in the list below:
Stage 2 – Analysis
The team will analyse the system to generate models and business logic for use in the application. In this phase, your team will work to determine the needs of conditions to meet the project.
At this juncture, the team also studies often-overlapping and conflicting requirements of various stakeholders. This task consists of analysing, documenting, validating, and managing these priorities, as well as the creation of use cases, models, activity diagrams, state machine diagrams, and business rules.
Stage 3 – Design
Here, we focus on software architecture, as well as user interface and outputs design. Software developers establish a concrete solution concept based on previously determined requirements, tasks, and strategies. In this phase, software developers concentrate on specific components such as interfaces, frameworks, and libraries, in establishing a concise software construction plan.
Stage 4 – Code (Implementation)
The initiation of designs come into practice. Source code is written, with unit tests development, and integration of software. Here we undertake the implementing of all models, business logic, and previously-specified service integrations.
In this phase, the team implements the design in the desired programming language(s), where individual components are separately developed, checked within the framework of module testing, and integrated piecemeal into the overall product. The result of this phase is an alpha-level product ready for testing.
Stage 5 – Testing
The product undergoes systematic discovery of defects and debugging. The software also undergoes security and performance tests. Throughout this phase, initial versions of the product are released to select users as a beta version. This phase will repeat as necessary to remove bugs.
Stage 6 – Operations
Following successful testing, the application is ready for live deployment. This includes installation, migration, and support.
Stage 7 – Maintenance
Following the successful deployment of the application, this phase focuses on programme upkeep through patches, updates, as well as new software versions. In some cases, this phase combines with the Operations phase, depending on the publication.
Key Characteristics
More Autonomy
The quintessential aspect of this methodology is software team independence, with only select involvement from the client, due to fewer milestones presenting opportunities for interaction. During these fixed opportunities, communications restrict to addressing inconsistencies, as opposed to new ideas.
Although the client must approve deliverables throughout the project stages, the main acceptance criteria are that they must adapt with the deliverables of the previous step.
Highly Disciplined System
With Waterfall project management, the project is determined to abide by the timeline and is resistant to outside influence and distraction. The project model forces the completion of the project stages, with no interventions within mid-process steps.
The only stages at which interventions are permitted are during the Requirements and Testing phases.
Small & Simple Projects
In essence, the smaller the project, the better. As the process entails curtailed interaction from stakeholders, more modest projects with less possibility for crucial errors are the best candidates for this software development process. Ensure that these include a concise brief, as these are integral to ensuring a smooth process.
Bigger projects are generally split into smaller subprojects, whereby in each subproject, a waterfall model can be applied, and their stages can start in a sequence.
Some Disadvantages
The fact is, this is an older system, meaning it may no longer apply to the demands and scale of current IT projects, which can vary by size, and levels of desired interaction by the client. The following is a rundown of the disadvantages of the process.
Outdated Method
Many developers pursue timely feedback and guidance of clients throughout the process, which forms one of the leading arguments in favour of the competing Agile development methodology.
Less Flexibility
The waterfall is known for its resistance to change. While the lack of intervention keeps the project focused, this comes at the expense of minor adjustments which could pre-emptively keep bugs and errors at bay.
Unforeseen Changes
Owing to a lack of permitted changes throughout the project itself, bugs and other oddities may appear at the end stages. More significantly, it may also appear that requirements may have changed throughout the project, without prior notification.
No Looking Back
Despite the occasional need to update requirements throughout the process, possible new solutions to larger projects may become restricted due to pre-determined parameters set throughout the initial stages. Furthermore, any requirement changes past the initial stage can have a substantial impact on project costs and scheduling.
What You Need to Prepare
The Waterfall method is widely beneficial to smaller, more concise projects, with minimal requirements for feedback, as well as those with a specific budget and timeline.
Depending on the project, and conditions, Waterfall may be the most appropriate method. Be sure to consult the checklist to confirm:
With this guide, I hope to enlighten you to what is the most timeless software development method in existence. If your project identifies with the outlined conditions, then Waterfall is your best bet.
I wish you all the best, in your next successful project!
