Fully understanding the life cycle of software development could take countless hours of detailed explanations and comprehensive PowerPoint presentations. We’d have to talk about the current languages in the industry, brainstorming methods, the tasks and activities one takes to hurdle coding challenges – blah, blah, blah – it’d be ridiculous.
We’ll spare you the boredom by instead focusing on models of software development. Specifically, today we’re examining the waterfall model, a sequential design process originating from manufacturing and construction industries. It’s a basic software development process that, in fact, receives a lot of criticism in the industry because it’s seen as too basic.
The Waterfall Model
First mentioned on June 29, 1956, by Herbert D. Benington to describe advanced programming methods, the waterfall model describes software development as something that “flows from the top to the bottom, like a cascading waterfall.”
The exact phases within the cascading waterfall are as follows:
- Requirements specification
- Design
- Construction
- Integration
- Testing and debugging
- Installation
- Maintenance
The model follows the idea that one phase must be fully completed before moving onto the next one. The idea being, finding a mistake later in the software development life cycle – say, in construction – could lead to having to recreate the previous steps, thus wasting both time and money. A fully completed phase, the waterfall model argues, prevents such occurrences.
Benefits
Even though the waterfall model is over fifty years old, supporters continue hailing it as the most effective method for creating a piece of software. Here are some of the reasons why programmers use the waterfall method:
- Whole project must be fleshed out before coding can begin, which puts a greater emphasis on documentation and source code.
- Easier to fix problems in earlier stages rather than discovering them later.
- Smoother integration of new team members into project due to documentation.
- Simple phase transitions leading to less miscommunication and errors.
- Identifiable milestones provide a sense of accomplishment.
- Rigid structure increases team’s discipline and ability to maintain schedules.
Of course, for every supporter of the waterfall model there is the same amount of criticizers, providing their own examples of where the model falls short. To stay fair and balanced, let’s examine their arguments.
Criticisms
Although the waterfall model uses a simple step-by-step process, it’s this exact rigid structure that many believe hold back projects. Specifically, something as complex and comprehensive as software development cannot be contained within the authoritarian transitional phases of the waterfall model.
Some have even claimed it to be impossible to fully finish a phase before moving to the next one, because learning from the next phase could help its predecessor.
Also, when building for a client, they may request software changes halfway through the waterfall mode, which would require starting the model over again, thus increasing the project’s working hours and cost.
In response to criticisms of the model’s limited structure, modified waterfall models have been developed putting emphasis on flexibility and discipline. This creates a developmental environment in which projects thrive under structured schedules and fluid problem responsiveness. Examples of such modified waterfall models will be expanded upon in later articles.
The Takeaway
Understanding the limitations and benefits of a specific model helps to empower a project’s completion rate, as it gives the team an expectation when taking on the model as a framework.
Now, is this the model we use for all of our software development projects? No, it’s too limiting for our purposes, and we cater to the client, which means being open to software alterations any time during development.
Is this the point when I reveal our exact development process? Sorry, no, that’s our little company secret, but we’ll continue delving into the various publicized software development methods so as to hint at how we conduct business.