Current process models; why waterfall is not accurate

Current models of software process

A software process model is a simplified, abstract representation of a software process. Modern practice (Sommerville) uses a few generic models, usually combined, and recognises that iteration is essential.

1. Waterfall model: separate, sequential phases (requirements, design, implementation, testing, maintenance). Used mainly when requirements are stable, or in large systems engineering projects.

2. Evolutionary development: specification, development and validation are interleaved. An initial version is built quickly and refined through customer feedback.

   • Exploratory development: work with the customer, start from well-understood parts and add new features.
   • Throwaway prototyping: build a prototype to understand unclear requirements, then discard it.

3. Component-based software engineering (reuse-oriented): the system is built by integrating existing components or COTS systems. Stages: component analysis, requirements modification, design with reuse, development and integration.

4. Process iteration models, where parts of the process are repeated:

   • Incremental delivery: the system is delivered in increments, highest-priority functions first; each increment is developed and delivered as a working part.
   • Spiral model: each loop is a phase with objective setting, risk assessment, development and planning; risk drives the process.

5. Rational Unified Process (RUP): a modern hybrid model with four phases (inception, elaboration, construction, transition), iterations within each phase, and recommended good practices (iterative development, managed requirements, component architecture, visual modelling with UML, quality verification, change control).

6. Agile methods (XP, Scrum): very short iterations, working software every few weeks, continuous customer involvement, minimal documentation, and acceptance of changing requirements.

In practice, organisations mix these: for example, a stable core developed by waterfall-style planning and user-facing parts developed by prototyping, inside an incremental or agile framework.

Why the waterfall model is not an accurate reflection of software development

1. Real projects rarely follow a strict sequence. In reality, stages overlap and feed information to each other: during design, problems with requirements are found; during coding, design problems are found. The waterfall's one-way flow hides this.
2. Requirements are not known completely at the start. Customers usually cannot state all requirements explicitly in the beginning; requirements are discovered and change as the project proceeds.
3. Iteration is natural. Software is developed by repeated cycles of "specify, build, evaluate, refine". Waterfall shows iteration only as costly going back, so in practice teams "freeze" parts of the specification and continue, leaving problems for later.
4. Software is intangible and easy to change, unlike a building or a bridge. Engineers naturally change it in response to new understanding, which the waterfall model does not show.
5. Feedback from users comes too late. A working version is available only at the end, but real development needs early feedback.
6. Blocking states are reduced, but not removed, in practice. The waterfall model assumes each group waits for the previous phase to finish. Real teams overlap the phases and work in parallel on analysis, design and code, so there is less waiting than the model suggests, though some waiting still remains. The strict one-after-another flow therefore does not match real work.
7. Maintenance is really further development. After delivery, software keeps evolving through new versions, which is a cycle, not the end of a linear process.

So the waterfall model is a useful management view (clear phases and documents), but the real development activity is iterative and overlapping, which is better shown by evolutionary, incremental, spiral or agile models.