Question 1 of 8: Software Process, Metrics/Measures, and the Spiral Model

Question 1: Software Process, Metrics/Measures, and the Spiral Model (10 marks)

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 process and its decomposition. A software process is a structured, organised set of activities and associated work products carried out to develop, deliver and evolve a software product (Sommerville Ch. 2); it defines who does what, when, and in what order, independently of the specific tool or notation used. It is typically decomposed in two complementary ways: (1) into four generic (phase-bound) activities — specification, design and implementation, validation, and evolution — that every named process model arranges differently (sequentially in Waterfall, iteratively in Spiral, continuously in Agile); and (2) into those four generic activities plus a set of umbrella (phase-independent) activities that run throughout the whole process rather than belonging to any one phase — e.g. project tracking and control, risk management, software quality assurance, and software configuration management (Pressman Ch. 2).

Part b) — software process metrics vs. project measures. A software process metric is a quantitative indicator of an attribute of the process itself — how the work is being done — used to assess and improve process effectiveness over time (e.g. defect-removal efficiency, average review effort per KLOC, mean time between failures found in test). A project measure (or project metric) is a quantitative indicator of an attribute of a specific project — captured directly, such as effort expended, elapsed schedule time, cost, staffing level, or size (lines of code or function points, Question 5) — used by the project manager to track progress, estimate remaining work, and support decisions on that one project. The distinction matters because process metrics are aggregated across many projects to improve the organisation's process, while project measures are used within a single project to control that project's plan.

Part c) — the spiral model. The spiral model (Boehm) represents the software process as an expanding spiral of iterative cycles, each divided into four quadrants: (1) determine objectives, alternatives and constraints for that cycle; (2) identify and resolve risks — the model's defining feature, using techniques such as prototyping to reduce the highest-priority risk before committing further; (3) develop and verify the next-level product increment (using whichever process model, e.g. Waterfall or prototyping, best fits that cycle's risk profile); (4) plan the next cycle, reviewing progress with the customer. Each pass around the spiral produces a more complete, more validated version of the system. Situation likely to use it: large, complex, high-risk projects where requirements are not fully understood up front and where a single wrong technical or business decision would be very costly (e.g. large mission-critical or safety-related systems, or the Question-4 emergency reporting system, where getting the resource-allocation logic wrong has real operational consequences) — the explicit, repeated risk-analysis quadrant is exactly what such projects need and a purely sequential model does not provide. Main drawback: the model demands considerable, genuine risk-assessment expertise to be used correctly — if risks are not correctly identified and prioritised each cycle, the project can be no better off (or worse off) than under a simpler model — and its open-ended, cycle-based structure makes it hard to give a customer a fixed cost/schedule commitment up front, which makes it a difficult sell for contractually fixed-price work.