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) — major project management activities. Project planning establishes the schedule, budget, staffing and milestone plan for delivering the software, and is revisited whenever circumstances change rather than fixed once. Estimation predicts the effort, cost and duration needed, typically using a sizing technique (e.g. Function-Point analysis, Question 5) combined with a productivity model or historical data from comparable projects. Risk management identifies, analyses and plans responses to the threats most likely to affect schedule, cost or quality (Question 3), and is tracked continuously rather than only at kickoff. Staffing and team management assigns people with the right skills to the right roles, manages team dynamics, and plans for turnover. Scheduling sequences the work (often visualised as a Gantt chart or PERT network) respecting task dependencies and resource constraints. Progress monitoring and reporting compares actual status against the plan at regular checkpoints and triggers corrective action (re-planning, re-staffing, scope adjustment) when a variance is detected. Together these activities form a continuous plan–execute–monitor–adjust cycle that runs for the life of the project, not a one-time up-front exercise.
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 explicitly 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 — while still, per the Manifesto, valuing the items on the right when useful. 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) — PM activities under Waterfall vs. agile.
| PM activity | Waterfall | Agile |
|---|---|---|
| Planning | One comprehensive, up-front plan for the whole project, covering all phases before development starts; deviations require formal change control. | High-level roadmap plus detailed planning re-done every sprint (sprint planning); the plan is expected to change as the backlog is re-prioritised. |
| Estimation | Whole-project estimate (e.g. Function-Point/COCOMO) 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 and task, fixed at baseline and tracked against slippage. | Sprint-length time-boxes (fixed duration) with scope, not duration, flexed to fit; a release plan is a rolling forecast, not a fixed schedule. |
| Progress monitoring | Milestone/phase-gate reviews at defined points (e.g. end of design, end of implementation); progress reported against the original plan. | Daily stand-ups, sprint reviews (demo of working software) and burndown/velocity charts every sprint; progress is visible continuously, not only at gates. |
| Change control | Formal change-request process against a frozen baseline; changes are costly and discouraged once a phase is signed off. | Change is expected and welcomed even late; the product backlog is re-prioritised by the product owner before each sprint at low process cost. |
| Risk management | Risk assessed mainly up front; large risks (e.g. requirements misunderstanding) may not surface until late-phase testing. | Risk is continuously reduced by shipping a working increment every sprint, surfacing integration and requirement-misunderstanding risk early. |
The underlying activities — plan, estimate, schedule, monitor, control change, manage risk — are the same in both models; what differs is the granularity and cadence at which they are performed: once per project (Waterfall) versus once per short iteration (agile).
