19-Soft-B6 Software Project Management · May 2015
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) — the V-model and its relation to Waterfall. The V-model is a variant of the Waterfall model that makes verification and validation explicit by pairing 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.
The V-model relates to Waterfall the same way a magnifying glass relates to a photograph: it is the identical single-pass, sequential set of phases (Question 1b/2a), "folded" at the coding step so that each specification phase is drawn opposite the test phase that will later verify it. Nothing about the sequencing or the one-pass assumption changes — the V-model is Waterfall with the verification/validation activity made explicit and traceable to its source phase, rather than testing being left as an undifferentiated block at the end.
Part (b) — agile development, and comparison with Waterfall. 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, and responding to change over following a plan. Development proceeds in short, fixed-length iterations (commonly 1–4 weeks), each producing a working, potentially shippable increment, with requirements ("the backlog") allowed to be re-prioritized between iterations rather than frozen up front.
| Dimension | Waterfall | Agile |
|---|---|---|
| Requirements | Fixed and signed off before design begins | Expected to evolve; re-prioritized each iteration |
| Delivery | One delivery, at the end | Working increment every iteration (weeks, not months) |
| Documentation | Comprehensive, formal, produced as a phase deliverable | Minimal, just enough to support the working software |
| Change response | Costly; routed through formal change control | Expected and accommodated at every iteration boundary |
| Customer role | Sign-off at defined milestones | Continuous collaboration (product owner embedded in the team) |
Part (c) — QA activities, Waterfall vs. agile. Waterfall's QA activities are phase-gated and largely document/design-centric before code exists: formal technical reviews and inspections of the requirements and design documents, a dedicated, separately-planned test phase (often executed by an independent QA team) once construction is complete, and formal QA audits/sign-off gates between phases. Agile's QA activities are continuous and embedded within every iteration: test-driven development (tests written before or alongside the code they verify), continuous integration with an automated regression-test suite run on every commit, pair programming/code review as an ongoing practice rather than a scheduled milestone, and the sprint review/retrospective, which evaluates both the product increment and the process itself at the end of every short iteration.