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) — main parts of the project plan.
| Part of the plan | 1–2 line description |
|---|---|
| Scope & introduction | States the software's boundary — functions, data, performance, constraints — that every other part of the plan is derived from. |
| Estimates | Effort, cost and size estimates (e.g. Question 5's Function-Point count), produced from the scope before the schedule is built. |
| Schedule | A task/milestone breakdown mapped to a timeline (Question 3's Gantt chart), showing dependencies and target dates. |
| Resources & staffing plan | People (and their roles), tools, and reusable software components the project needs, and when each is required. |
| Risk management plan | Identified risks, their probability/impact, and a mitigation or contingency for each (see Part c). |
| Tracking & control plan | How progress is measured against the plan (metrics, reviews) and what triggers re-planning. |
Part b) — agile software development. Agile software development is an approach to building software through short, time-boxed iterations (sprints) that each produce a working, potentially shippable increment of the product, with requirements and solutions evolving through close, continuous collaboration between a self-organising, cross-functional team and the customer/product owner (Agile Manifesto, 2001; Sommerville Ch. 3). It values individuals and interactions over rigid processes, working software over comprehensive up-front documentation, customer collaboration over fixed-price contract negotiation, and responding to change over rigidly following a plan. Common methods include Scrum (fixed sprints, daily stand-ups, sprint reviews/retrospectives) and XP (pair programming, test-driven development, continuous integration).
Part c) — risk assessment: incremental vs. agile.
| Risk-assessment activity | Incremental model | Agile development |
|---|---|---|
| When performed | Formally, once per increment — typically at the start of planning that increment (e.g. before Team B's Increment 2 in Question 3). | Continuously — reviewed every sprint at sprint planning and again at the retrospective. |
| Who assesses | Often the project manager or a designated risk owner, documented in the risk management plan. | The whole self-organising team, surfaced informally in daily stand-ups as well as formally at sprint boundaries. |
| Granularity | Risks tied to an entire increment's scope (weeks of work). | Risks tied to individual backlog items/stories (days of work), so a bad risk call is caught and corrected within one short sprint. |
| Mitigation style | Planned contingencies built into the increment's schedule up front. | Adaptive — the next sprint's plan is adjusted in response to what the current sprint revealed, rather than following a pre-set contingency. |
| Exposure window | A mis-assessed risk can propagate for the whole increment before it is caught. | Exposure is capped at one sprint, since re-planning happens every cycle. |
Both models perform the same underlying risk-assessment steps — identify, analyse, plan a response, monitor — but incremental does so at increment cadence while agile does so at sprint cadence, so agile catches and corrects a wrong risk call sooner.
