19-Soft-B6 Software Project Management, May 2018, Q3

Question 3 (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) — how the V-model improves software quality. The V-model is a variant of the Waterfall model that pairs every development (specification) phase on the descending left leg of a "V" with a corresponding testing phase on the ascending right leg, joined at the vertex by coding.

Fig. Q3(a) — the V-model. Requirements↔acceptance testing, system design↔system testing, architecture design↔integration testing, module design↔unit testing; coding sits at the vertex.

Quality improves through three mechanisms this pairing creates that plain Waterfall does not:

Testable, traceable acceptance criteria at every level. Because each right-leg test phase is defined at the same time as its paired left-leg specification phase (not written after coding, as an afterthought), the exact criteria a module/architecture/system/requirement must satisfy are made explicit and traceable before construction begins — a defect is caught against a specific, pre-agreed criterion rather than discovered by ad hoc exploratory testing.
Early defect detection, cheaper fixes. Because test PLANS (not just test execution) exist from the same point in the project as their paired specification, a flaw in the requirements or design itself (not just in code) can be found by reviewing the corresponding test plan early — long before the expensive right-leg testing phase runs, when fixing a requirements-level defect is far cheaper than after full construction.
No untested layer. Every specification phase has an explicitly assigned verifying/validating test phase (module→unit, architecture→integration, system→system, requirements→acceptance), so there is no level of the design that quality assurance can silently skip, unlike an undifferentiated single "testing" block at the end of plain Waterfall where lower-level design defects can hide behind passing system-level tests.

In short, the V-model does not change WHAT Waterfall builds — it changes WHEN and HOW explicitly each artifact's verification is planned, and that shift from "test at the end" to "test planned alongside each specification" is the source of its quality improvement.

Part (b) — spiral model vs. agile development. The spiral model is a risk-driven evolutionary model: each cycle repeats four activities (determine objectives/alternatives, 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.

Fig. Q3(b) — the spiral model: four activities repeat each cycle, the spiral's growing radius representing rising cost/completeness toward a delivered system.

Agile development is a family of iterative, incremental methods (Scrum, XP, Kanban) built on the Agile Manifesto's priorities — individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan — delivered in short, fixed-length iterations (1–4 weeks) with a re-prioritizable backlog.

Dimension	Spiral model	Agile development
Organizing principle	Explicit, formal risk analysis at every cycle	Customer collaboration and responding to change; risk is managed implicitly through short feedback loops
Cycle length	Often months per cycle, especially early (large-scale/high-risk projects)	Short, fixed iterations (1–4 weeks/sprints)
Documentation of risk	Formal risk assessment/mitigation plan is a required deliverable each cycle	Minimal, informal — risk is absorbed by frequent re-planning rather than analysed up front
Best fit	Large, high-risk, high-cost projects (e.g., safety-critical, novel technology) where an unmanaged risk could be catastrophic	Projects where requirements are expected to evolve and fast, continuous customer feedback is available and valuable
Common ground	Both are evolutionary (build incrementally growing versions rather than one final delivery) and both explicitly plan for change rather than assuming a fixed, stable requirements baseline (Question 2a's Waterfall assumption).

The contrast is one of emphasis, not of philosophy: the spiral model makes risk management the organizing loop that every other activity revolves around and formalizes it as a deliverable, while agile treats responsiveness to the customer as the organizing loop and manages risk as a natural side effect of shipping and re-evaluating small increments quickly — a heavyweight, well-documented risk process versus a lightweight, high-frequency feedback process aimed at the same underlying goal of not committing too much before uncertainty is reduced.

Topic: How pairing development and test phases in the V-model improves traceability and early defect detection, and how the spiral model's explicit risk-driven cycles compare with agile's feedback-driven iterations.

Key relations: V-model quality gain = paired spec/test phases → testable criteria defined early + defects caught before expensive late-stage testing. Spiral cycle = objectives/alternatives → identify/resolve risks → develop/verify → plan next cycle, radius growing each pass. Agile = short iterations + re-prioritized backlog + continuous customer collaboration.

Why this works: in all three models, the mechanism that improves outcomes is the same — making the thing that could go wrong (an unverified requirement, an unresolved risk, a misunderstood need) visible and addressed as early and as often as the model's own structure allows, rather than deferring it to a single point near project end.

Common pitfall: assuming the spiral model IS agile because both are iterative — the spiral model's defining feature is its explicit, formal risk-analysis activity every cycle, which agile methods do not mandate as a discrete deliverable; conflating the two loses the spiral model's specific value on genuinely high-risk projects.

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

Question 3 of 8

Question 3 (10 marks)