19-Soft-B6 Software Project Management, May 2015, Q2

Question 2 (10 marks)

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) — linear sequential (Waterfall) vs. prototyping. The linear sequential model performs the generic phases — requirements, design, implementation, testing, maintenance — exactly once, each phase completed and formally reviewed before the next begins; there is no planned iteration back to an earlier phase. The prototyping model instead builds a quick, partial, working version of the system (often skipping non-visible qualities such as robustness or efficiency) from an initial, incomplete set of requirements, has the customer evaluate it, and repeats the gather-requirements/build-prototype/evaluate cycle until the prototype (or the understanding it produced) is good enough to drive full development.

Fig. Q2(a) — linear sequential (single pass, gated) versus prototyping (repeated gather/build/evaluate loop until the requirements or the prototype itself is accepted).

Dimension	Linear sequential	Prototyping
Requirements assumption	Complete and stable up front	Incomplete/fuzzy; discovered through the prototype
Customer involvement	Front-loaded (sign-off), then largely absent until delivery	Continuous, iterative feedback each cycle
Change cost	High — a late change re-opens completed, reviewed phases	Low during the prototyping cycles themselves
What is produced first	A complete specification/design document	A working (if partial) executable
Best fit	Well-understood, stable-requirement domains (e.g., regulated/contractual work)	Novel UI/UX or unclear requirements, where seeing something concrete is the fastest way to elicit the real need

The two share the same underlying framework activities (Question 1b) — the contrast is entirely in how many times, and how early, the customer sees a concrete artifact: once, near the end, for linear sequential; repeatedly, from very early on, for prototyping.

Part (b) — evolutionary process models. Evolutionary models deliver the system in a planned sequence of increasingly complete versions rather than one final delivery:

Incremental model — applies linear-sequential development repeatedly, each increment adding a defined subset of functionality to the previously delivered, working increments, so the customer receives usable software early and often.
Spiral model — a risk-driven model that repeats four activities each cycle (determine objectives, identify and resolve risks, develop and verify the next-level product, plan the next cycle), with the spiral's radius growing each pass to represent increasing cost/completeness.
Rapid Application Development (RAD) — a compressed, component-based variant of the incremental model aimed at a very short (60–90 day) delivery cycle using heavy reuse and code generation.

Advantages vs. Waterfall: the customer gets working software far earlier (reducing the risk of building the wrong thing undetected for months), requirements can legitimately evolve between increments/cycles rather than being frozen at project start, and risk is confronted explicitly and early (spiral) instead of being discovered late in a single long testing phase. Disadvantages vs. Waterfall: the overall system architecture is harder to keep coherent when it is built incrementally rather than designed whole up front (risk of architectural erosion across increments); progress and cost are harder to track against a fixed baseline because the "final" scope is not fully known at project start; and evolutionary models demand a customer who is willing and available for frequent review, which some contractual/regulated environments cannot accommodate as readily as a single Waterfall sign-off.

Topic: Linear sequential vs. prototyping (single-pass vs. iterative discovery), and the incremental/spiral/RAD family of evolutionary models.

Key relations: Linear sequential = one pass, phases gated in order. Prototyping = repeat {gather → build → evaluate} until accepted. Evolutionary = deliver a growing sequence of working versions (incremental = fixed feature slices; spiral = risk-driven, growing radius).

Why this works: all of these models manage the same underlying tension — requirements are rarely fully known up front, and change is expensive the later it is discovered — by choosing when the customer first sees something real: never until the end (Waterfall, cheapest to plan, most expensive to change), early and often (prototyping/incremental/spiral, more overhead to manage but far cheaper to correct course).

Common pitfall: treating "prototyping" and "incremental" as the same thing — a prototype is typically discarded (or heavily reworked) once it has served its purpose of eliciting requirements, whereas each increment in the incremental model is production-quality, shippable software that is kept and built upon.

Source: Pressman, Software Engineering: A Practitioner's Approach, 9th ed., Ch. 2 (Process Models); Sommerville, Software Engineering, 10th ed., Ch. 2 (Software Process Models).

Question 2 of 8

Question 2 (10 marks)