8.0 Waterfall vs. Cyclical Project Management (Part 1)

A waterfall model, the six-phase model is a waterfall model. In other words, the stages occur sequentially. Just as swimming upstream against a waterfall is impossible, the pure waterfall technique precludes returning to a phase after it has been finished.

It is not ideal to decide to change the design during the implementation phase, thus halting implementation. The waterfall approach is often less suitable for software development projects for a variety of reasons.

  • Software development is an artistic endeavour; it is virtually difficult to anticipate all needs (functionalities).
  • Estimating the time required to develop a feature is very challenging.
  • Throughout the project’s lifecycle, users should be able to test all intermediate outcomes.

Software Development Is An artistic Endeavour #

To the uninitiated, software development seems to be more about engineering than it is about invention. It does, however, relate in a number of ways to inventing. In the process of creation, one never knows exactly what will occur.

The designers and programmers responsible for developing new software must come up with answers to the issues they are presented with. Regardless of the many techniques and prescriptions for work, creating computer code is still mostly unknown and therefore unpredictable. Programmers may select from millions of solutions written in dozens of programming languages and operating on thousands of different hardware combinations and software platforms. While this flexibility has a lot of benefits, it also makes the project more challenging to manage than more conventional project management (such as construction or building projects).

Implementation Set Up #

The waterfall approach requires that requirements be defined as a consequence of the project’s defining phase. Ideally, a minimal additional departure from these criteria should occur for the remainder of the project. The waterfall approach of software development necessitates an initial commitment of significant effort in analyzing the required functionality (requirements). This results in a functional design (see I for additional information on functional designs). The software architect creates a technical design throughout the design process, using the functional design as a reference. Further, the technical design provides instructions on how to execute the required functionality.

While this may seem to be a simple issue, consider the following scenario. A new vehicle is being developed as part of a project. As an active car driver, you are tasked with developing automotive needs. You confer with other motorists and compile an exhaustive list:

  • The car must seat four people;
  • The automobile must have a steering wheel in the front on the driver’s left-hand side; • The automobile must have a brake pedal, a gas pedal, and a hand brake.
  • The automobile’s headlights must be white and the taillamps must be red. (obviously, the real list would be huge)

Design & Modeling #

The designers create a new design using your list as a guide, which is then constructed many months later. As you go down the street, you see a vehicle has come to a halt. You realise that you omitted brake lights from your list! You quickly contact the car manufacturer’s engineer, who almost bursts in response to your call. You claim that it is a minor adjustment. However, it is a catastrophe for carmakers.  Automobiles already manufactured must be fully dismantled, wires from the brake pedals to the back must be extended, the rear of the vehicle must be totally redesigned to fit the brake lights, and already manufactured boot hatches must be scrapped, and the list goes on.

While the above scenario seems ridiculous, it represents a near-daily occurrence in software development. Programmers make the erroneous assumption that the clients, customers, or users of the product being created understand exactly what they want. Clients incorrectly believe that software developers can create (and modify) anything in the smallest amount of time feasible. This is the primary cause of contention between consumers and software developers.