19-Soft-A7 Software Development Process · December 2013
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams, December 2013 — 04-Soft-A7, Software Process (open book, 3 hours). Notes on the paper: FIVE of the eight questions constitute a complete paper (the first five as answered in the answer book are marked, each of equal value); this solution answers all eight as a full study resource. Most questions call for essay-format answers; Question 4 introduces a hypothetical information search-and-delivery tool (delivering electronic documents from a repository to a user by keyword/preference — e.g. a product catalog or classified-ads listing) that Question 5 and parts of Questions 7 build on.
Reference texts. Sommerville, Software Engineering, 10th ed., Ch. 2 (Software Processes), Ch. 3 (Agile Software Development), Ch. 5 (System Modeling), Ch. 8–9 (Testing), Ch. 22–23 (Project Management, Configuration Management), Ch. 9 (Software Evolution/Maintenance); Pressman, Software Engineering: A Practitioner's Approach, 9th ed., Ch. 2–3 (Process Models, Agile), Ch. 23–24 (Project Management, Risk Management), Ch. 29 (Function-Point sizing), Ch. 22 (SQA), Ch. 24 (Software Configuration Management); SWEBOK v4 (Software Engineering Process, Software Configuration Management, Software Maintenance KAs).
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) — testing strategies. Black-box (functional) testing derives test cases from the specification alone, without reference to internal code structure, checking that outputs are correct for given inputs. White-box (structural) testing derives test cases from the internal code structure itself (e.g. covering every branch or path), catching logic errors black-box testing might miss. Top-down integration testing integrates and tests from the highest-level modules downward, using stubs for not-yet-integrated lower modules. Bottom-up integration testing integrates from the lowest-level modules upward, using drivers to exercise not-yet-integrated higher modules. Regression testing re-runs previously-passing tests after a change to confirm nothing that used to work has broken.
Part b) — unit, integration, and system testing. Unit testing tests the smallest independently testable piece of code (a function, method or class) in isolation from the rest of the system, typically by the developer who wrote it, using stubs/mocks for any dependency (e.g. testing PreferenceManager.savePreferences() from Question 4 against a mocked PreferenceStore). Integration testing tests the interfaces and interactions between units that have already individually passed unit testing, exposing defects that arise only when components are combined (e.g. does PreferenceManager actually call PreferenceStore.persist() with the right data). System testing tests the complete, integrated system as a whole against its full functional and non-functional requirements, in an environment as close to production as practical (e.g. exercising the full Set-Preferences → Search → Select-and-Deliver flow end to end).
Part c) — verification vs. validation. Verification asks “are we building the product right?” — does the software conform to its specification, typically checked through static techniques (reviews, inspections, static analysis) as well as testing against the spec, at every stage of development. Validation asks “are we building the right product?” — does the software actually meet the customer's real needs and expectations, typically checked by exercising the system (often with the customer/user directly involved) and comparing its behaviour against real-world intent rather than only the written specification. A system can pass every verification check (it correctly implements a flawed or misunderstood specification) and still fail validation.
Part d) — V&V under Waterfall vs. agile.
| Aspect | Waterfall (V-model) | Agile |
|---|---|---|
| Verification | A distinct review/inspection activity paired with each development phase (e.g. design review verifies the design against requirements); performed at defined phase gates. | Continuous, via code review, pair programming, and automated unit/integration tests run on every commit (continuous integration). |
| Validation | Concentrated mainly in acceptance testing near the end of the project, when the full system is first exercised against real user needs — the classic V-model right-hand leg matched to each left-hand specification phase. | Continuous, via sprint reviews/demos where the product owner and, where possible, real users assess each increment against actual need every 1–4 weeks. |
| Timing of feedback | Late — a validation gap (e.g. a misunderstood requirement) discovered at acceptance testing is expensive to fix, since design and implementation are already complete. | Early and frequent — a validation gap is discoverable after the very first sprint that touches the affected feature, while it is still cheap to correct. |
| Documentation basis | Verification is checked against a comprehensive, largely-frozen requirements/design document set. | Verification is checked against acceptance criteria attached to each backlog item/user story, refined as understanding improves. |
In both models verification and validation remain conceptually distinct (right product vs. right way of building it), but Waterfall concentrates each into a small number of large, phase-gated events while agile distributes both continuously across every sprint — the same granularity shift already noted for project management in Question 2(c).
