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.
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).
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 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.
We collaborate with ambitious brands and people; we’d love to build something great together.[email protected]