19-Soft-A7 Software Development Process · December 2014
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams, December 2014 — 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 4 introduces a hypothetical emergency reporting system (a field officer reports an emergency, a dispatcher records the issue and allocates resources) 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) — objective of project planning and software scope. The main objective of project planning is to provide the project manager with a realistic framework — of schedule, cost, staffing and risk — for successfully delivering the software, established before significant resources are committed and revisited as the project proceeds (Pressman Ch. 23). Software scope describes the boundary of what is (and is not) to be built: the data and control to be processed, the functions the system must perform, the performance required, the constraints imposed (hardware, interfaces, standards), and the reliability expected — it is the essential input every estimate (schedule, cost, staffing, Question 5's function-point size) is derived from, so a poorly-defined scope propagates error into every downstream plan.
Part b) — what is 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 development 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 agile methods include Scrum (fixed-length sprints, daily stand-ups, sprint reviews/retrospectives) and Extreme Programming/XP (pair programming, test-driven development, continuous integration).
Part c) — project planning activities under Waterfall vs. agile.
| Planning activity | Waterfall | Agile |
|---|---|---|
| Scope definition | Complete software scope fixed up front and formally signed off before planning proceeds. | Scope captured as a product backlog, deliberately left open to re-prioritisation as understanding improves. |
| Estimation | Whole-project estimate (e.g. Function-Point/COCOMO, Question 5) produced early and used as the baseline for the entire schedule and budget. | Relative estimation per backlog item (story points, planning poker), refined continuously as the team's actual velocity becomes known. |
| Scheduling | Detailed Gantt/PERT schedule for every phase, fixed at baseline and tracked against slippage (Question 3a). | Sprint-length time-boxes (fixed duration, Question 3b) with scope, not duration, flexed to fit; the release plan is a rolling forecast. |
| Re-planning trigger | A formal change-control process against the frozen baseline; re-planning is the exception. | Re-planning is routine, done every sprint at backlog-refinement/sprint-planning time. |
| Risk exposure | Estimation error compounds across a long, single planning horizon before it is tested against reality. | Estimation error is caught and corrected every 1–2 sprints, limiting how far a bad estimate can propagate. |
The underlying activities — define scope, estimate, schedule, track and re-plan — are the same in both models; what differs is the granularity and cadence: once per project (Waterfall) versus once per short iteration (agile).
