19-Soft-B6 Software Project Management · May 2018
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.
Part (a) — sequential vs. rapid prototype: similarities, differences, disadvantages. Both models pass through the same generic framework activities from Question 1a (communication, planning, modeling, construction, deployment) and both are used to arrive at a working software system from an initial understanding of customer needs — that is their similarity. They differ sharply in how many times, and how early, the customer sees something concrete: the sequential (Waterfall) model performs each activity once, gated in strict order, producing a complete specification and design before any code is written; the rapid prototype model instead builds a quick, partial, working version from an initial, incomplete set of requirements, has the customer evaluate it, and repeats gather/build/evaluate until the requirements (or the prototype itself) are good enough to drive full development.
| Dimension | Sequential (Waterfall) | Rapid Prototype |
|---|---|---|
| Requirements assumption | Complete and stable up front | Incomplete/fuzzy; discovered through the prototype |
| Main disadvantage | Real projects rarely follow the sequential flow in practice, and a late requirements change is expensive because it re-opens completed, reviewed phases; the customer only sees a working system near the very end. | The customer may mistake the quick-and-dirty prototype for the final product and demand it be shipped as-is, and design/implementation shortcuts taken purely to make the prototype work fast (skipping efficiency, robustness) can be left in place once management insists on reusing prototype code. |
Both disadvantages trace back to the same root cause identified in Question 1b: neither model corrects for a wrong first pass through a phase without cost — Waterfall pays that cost late, through change control on a signed-off document; prototyping pays it by risking that speed-over-quality shortcuts survive into production.
Part (b) — the incremental process model and its main tradeoff. The incremental model combines linear-sequential and iterative elements: it applies the framework activities repeatedly, with each pass ("increment") delivering a working, production-quality subset of functionality that is added to what earlier increments already delivered, rather than one big-bang delivery at project end. The first increment is often the core product; subsequent increments add features until the full system is complete.
The main tradeoff is between early, incremental value delivery and architectural/schedule discipline: delivering working software after the first increment (often weeks, not months) reduces the risk of discovering a fundamental misunderstanding of requirements late, and lets the customer start using and reacting to the system early — but this benefit is paid for by a harder-to-keep-coherent overall architecture (each increment's design decisions constrain what later increments can still change without costly rework) and by planning/estimation that must be redone at every increment boundary rather than fixed once at project start. A team that commits to the incremental model is trading the up-front predictability of a single fixed plan for the ongoing benefit — and ongoing cost — of re-planning around what has actually been learned and delivered so far.
