--- title: "Current process models; why waterfall is not accurate" subject: "Software Engineering" chapter: 1 key: "semester_5/software_engineering:waterfall-not-accurate" source: https://www.bctengineer.com/q/semester_5/software_engineering/waterfall-not-accurate site: BCT Engineering --- # Current process models; why waterfall is not accurate Software Engineering · Chapter 1: Software Process and requirements - Asked in: year not given, 4+4 marks - Answer checked by Claude Sonnet 5.5 on 2026-10-14 - Page: https://www.bctengineer.com/q/semester_5/software_engineering/waterfall-not-accurate - Whole chapter: https://www.bctengineer.com/md/semester_5/software_engineering/chapter-1 ## Question Explain details about current model of software process. Explain why waterfall model is not an accurate reflection of software development activities. ## Short answer Current process models include waterfall, evolutionary development, component-based engineering, iterative models like incremental and spiral, RUP, and agile methods, often combined in practice. Waterfall inaccurately reflects development because real projects overlap phases, requirements evolve, iteration is natural, software is easily changed, user feedback comes too late, and teams work in parallel rather than waiting for phase completion. ## Answer #### 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. ## Check yourself The answer's key points as multiple-choice questions, with the correct option and why. 1. Why is waterfall not an accurate reflection of real development? A. Real projects follow strictly separate phases B. Stages overlap and feed information to each other, e.g. design finds requirement problems C. Real projects have no requirements D. Testing never happens in real projects Answer: B. In practice problems found in later stages feed back into earlier ones, which waterfall's one-way flow hides. (Key point: Real projects overlap) 2. What is the problem with waterfall's assumption about requirements? A. Customers can always state all requirements at the start B. Requirements are never needed C. Customers usually cannot state all requirements at the beginning; they are discovered and change as the project proceeds D. Requirements are fixed by developers Answer: C. Requirements evolve as understanding grows, contrary to the waterfall assumption. (Key point: Requirements not known at start) 3. In evolutionary development, how are specification, development and validation organised? A. Strictly one after another B. Performed only after delivery C. Skipped for exploratory work D. Interleaved, with an initial version refined through customer feedback Answer: D. An initial version is built quickly and refined through feedback, with the activities interleaved. (Key point: Evolutionary development) 4. Which are the four phases of the Rational Unified Process? A. Inception, elaboration, construction, transition B. Analysis, design, coding, testing C. Plan, do, check, act D. Requirements, risk, prototype, release Answer: A. RUP has inception, elaboration, construction and transition phases with iterations in each. (Key point: Phases of RUP) ## Related in Software Engineering - [Waterfall model: advantages and limitations](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Awaterfall-limitations) — Software Engineering, chapter 1 - [Alternative models to waterfall](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Aalternative-to-waterfall) — Software Engineering, chapter 1 - [Software runaways; waterfall and prototyping inside spiral](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Asoftware-runaways-spiral) — Software Engineering, chapter 1 - [Why software development is complex; man-month myth](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Acomplex-development) — Software Engineering, chapter 1 - [Waterfall versus spiral; user participation](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Awaterfall-vs-spiral) — Software Engineering, chapter 1 - [Book store process model](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Abook-store-process-model) — Software Engineering, chapter 2 ## Related in other subjects - [Software process models and effort estimation](https://www.bctengineer.com/question.md?key=semester_5%2Finstrumentation_ii%3Asw-process-models) — Instrumentation II, chapter 9, asked 2× - [Spiral model of software development](https://www.bctengineer.com/question.md?key=semester_5%2Finstrumentation_ii%3Aspiral-model) — Instrumentation II, chapter 9, asked 3× - [Compare software models; propose a fourth model](https://www.bctengineer.com/question.md?key=semester_5%2Finstrumentation_ii%3Asw-models-compare-fourth) — Instrumentation II, chapter 9 - [Shortcomings of software development models](https://www.bctengineer.com/question.md?key=semester_5%2Finstrumentation_ii%3Asw-model-shortcomings) — Instrumentation II, chapter 9