19-Soft-A7 Software Development Process · May 2016
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams, May 2016 — 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 short, bulleted written answers; Question 3 asks for an incremental-model schedule using three teams, and Question 4 introduces a hypothetical pilot take-off/landing emulator (a pilot requests take-off or landing from the dispatcher, and the dispatcher records the request and allows the movement) that Question 5 builds 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) — software configuration; version vs. variant. The configuration of a software system is the specific set of components, and their versions, that together make up one identifiable, buildable/deployable instance of the system at a point in time (e.g. "Pilot Emulator v2.1: MovementRequest module 1.3, DispatchController 2.0, ATC-feed adapter 1.1") — software configuration management (SCM) tracks and controls exactly which configuration is in use where. A version is a revision of a component (or system) that supersedes an earlier one in time, normally intended to replace it (e.g. Increment 2 superseding Increment 1's build). A variant is a version that exists alongside other versions to serve a different context, not to replace them (e.g. a variant of the pilot emulator built for a different airport's runway configuration, released and maintained in parallel with the original).
Part b) — main change-control activities. (1) Change request — a proposed change is formally logged with its rationale. (2) Impact analysis — assess which components, tests, and other pending changes are affected, and estimate cost/risk. (3) Change review/approval — a change control board (or, in a small project, the lead) decides whether to accept, defer, or reject the change. (4) Implementation under version control — the change is made against a specific baseline, with the affected components' version identifiers updated. (5) Verification — the changed component (and anything it affects) is re-tested (Question 6's regression testing). (6) Release/baseline update — the new configuration is recorded as the current baseline once verified.
Part c) — change process: incremental vs. agile.
| Change activity | Incremental model | Agile development |
|---|---|---|
| Change request | Logged formally against the current increment's baseline; often batched for the next increment's planning. | Added directly to the product backlog as a new/re-prioritised item, discussed at backlog refinement. |
| Approval | A change control board or PM formally approves/rejects before it enters an increment's scope. | The product owner re-prioritises the backlog — there is no separate board; approval is the act of pulling the item into a sprint. |
| Impact analysis | Formal, scoped against the whole current increment's design. | Lightweight, scoped to the specific story/sprint; broader architectural impact is caught informally by the team's shared code ownership. |
| When applied | At the next increment boundary (Question 3's team hand-offs), not mid-increment. | As soon as the next sprint (or, for urgent fixes, immediately via an out-of-band hotfix). |
| Verification | Regression-tested as part of that increment's system test. | Verified by the same automated CI test suite that runs on every commit. |
