Software development starts with an idea and then rushes to the "how" factor. As the industry has been growing for decades, a multitude of approaches to the development process has been invented. To choose the right one, one needs to realize what software development methodologies exist and how to choose the one most suitable for your business needs.
One of the big philosophies of the software development life cycle (SDLC) is called "Waterfall development." Although the exact implementation varies from one company to another, the core concept of Waterfall development applies almost universally.
What is Waterfall development?
Waterfall software development focuses on thorough initial planning and a clear scope of work. Doing Waterfall means agreeing—before any coding starts—on what exactly the final results of development must look like. In other words, the customer and the contractor decide on the software's budget and pricing, precise scope of work, and deadlines with an intention to not change their plans once the implementation starts.
A good way to explain what Waterfall development is is to turn to the alternative approaches to the SDLS—Agile, Waterfall's long-standing rival, is a methodology where plans can be regularly revised. Initial arrangements are tentative, and requirements for the final product can change. Agile teams quickly adapt to new market opportunities, changes in consumer behaviors, and alterations in the roadmap to find the right market fit.
Why Waterfall is used in software development
Certainty in results—that's what Waterfall software development ensures. The customer and the provider take time to clarify the scope to a tee. As a result, the provider presents documentation with:
- A precise description of the final product / feature;
- A timeline with a deadline, and possibly, milestones along the way;
- A quote with a fixed price;
In Waterfall development, customers know what they're paying for, what they'll get in the end, and when they'll get it. For a customer who is buying the software, the Waterfall methodology might sound as an ideal one, since it provides the required level of stability.
What works in any other industry doesn’t always apply to software development. Thus, there are certain cases where Waterfall development is not a viable approach (spoiler for the section on Pros and cons of Waterfall development).
Stages in Waterfall development
Details may vary, but there are general core concepts and stages in the Waterfall development process. In its classical variation, the process can be broken down into five stages:
1. Collecting and specifying product requirements
In the Waterfall model, requirements must be as detailed as conceivable. If they are vague or too general, no specialist—no matter how experienced—can estimate how much development will take or cost.
This stage is about extensive communication. The customer and the contractor must make sure that they picture the same thing as the ultimate result of the project.
The result of this stage is a product requirements document (PRD). Once the PRD is approved by both parties, it's cast in stone and not to be altered in later stages.
2. Product architecture design
The next step is to translate the established requirements into the language of software. Here, the development team is figuring out what technological solutions they need to build the product described in the PRD.
Normally, the design stage is about the software architecture. Developers come up with the fundamental components of the future system and the logical connections between them. Completed architecture, therefore, is the result of work in this stage.
However, initial arrangements may be so that there will be some other activities after the PRD is approved.
3. Implementation
Implementation is the central stage of the Waterfall systems development life cycle. It simply means coding: the engineers start developing the product.
If the requirements are clear and estimates correct, implementation should be smooth and stress-free. But if something unpredicted happens, the developers may need to make extra efforts to deliver the results as agreed.
Unit testing and system integration are usually included in implementation because, by the end of this stage, the team is supposed to present functioning software.
4. Verification
This is where the customer gets to test the software and make sure it works the way it should. This stage exposes bugs, unfinished or improper work, and perhaps details about the software’s functionality that were overlooked in previous stages.
The verification stage is essentially about feedback. The customer and the contractor try to figure out together what was done properly in planning and implementing and what wasn't. That's how they come up with ideas on how to make the next phase or the next project better. That’s how verification and debugging feed further decision-making, help learn lessons, and teach how to avoid mistakes down the line.
5. Software maintenance
Depending on initial agreements, the development team can be involved in further support and maintenance of the software they built to various extents. Normally, they won't just leave it, and they will keep it functional as needed.
Maintenance can involve performance monitoring, corrective action, and adaptation. It's important to understand that the built software will operate in an evolving environment, so changes may be needed to keep it functional.
Now that the Waterfall development process has been scrutinized, it's time to address this question:
What is the most expensive part of software development?
It's the maintenance, and not necessarily because there's something wrong with the software. It's just that any real-life system relies on many external services in its operation. If something changes about them, the software under maintenance will require changes, too. Besides, maintenance is simply longer: it runs for the entire time you want your software to work, sometimes spanning decades.
Maintenance is the most expensive stage in the Waterfall systems development life cycle but not necessarily in the alternatives. And now, it's about time to turn to them.
Agile vs. Waterfall
In Waterfall, you plan the scope in advance and make no changes in your plans until the job is done. In agile, you make changes as you go. The latter methodology, as its name suggests, is more flexible and adaptive. As development unfolds, you can revise the ultimate functionality that you aim at, thus ensuring that the final product will fit the market.
Agile is done in sprints: periods of one to two weeks. The team defines tasks for each sprint. Waterfall, in turn, is about setting the tasks only once.
Importantly, the two approaches differ in terms of their focus.
- Agile focuses on the customer's business and its needs: the requirements can be redefined as the needs of the business change, as they tend to
- Waterfall focuses on the product: the goal is to build it so that it meets the initial requirements precisely
Pricing
The pivotal difference between Waterfall and agile is about pricing. In Waterfall, as the customer and the contractor have a precise plan for what's to be developed, they can agree on a fixed price (the fixed-price model is Waterfall's alternative name). In agile, where the scope is modifiable, a fixed price cannot be quoted. This is why agile requires the time and material model, where the parties agree on hourly rates or monthly budgets instead of a fixed price
Pros and cons of Waterfall development
Pros
- No surprises in the final product: it is delivered as initially required
- Predictability: the project has defined stages and a deadline
- Fixed price: no risk of extra spending or overpaying
Cons
- Rigidity: requests for extra features cannot be made once development starts
- Extensive planning: drawing up a detailed PRD takes a long time
- Focus on the product: the team doesn’t guarantee that the product will succeed in the market; they can only guarantee that it will meet the initial requirements
Conclusion
Waterfall software development is about specifying software requirements once, getting a fixed quote, and developing a product exactly as described. It goes: collecting requirements, building the architecture, building the rest of the software system, testing, and maintaining. The Waterfall development process cascades from phase to phase—like a waterfall.
Waterfall doesn't fit projects with a lot of uncertainty. The approach is too rigid to build a product in a highly competitive and thus constantly changing environment. However, Waterfall is a reliable and efficient methodology for projects where the scope is crystal clear and the desired results are pictured in detail.
Latest articles here
