Question 1 of 8: Software Process Models, Project Metrics, and the Incremental Model

Question 1: Software Process Models, Project Metrics, and the Incremental 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 model and its typical components. A software process model is an abstract, simplified representation of a software process, presented from a particular perspective, that prescribes an approach to developing software (Sommerville Ch. 2). It answers what is done, in what order, and by what artifact — independently of any one project's specifics. Its typical components are: (1) activities — the four generic phases (specification, design/implementation, validation, evolution) that every model arranges differently; (2) work products/artifacts produced and consumed at each activity (requirements documents, design models, code, test reports); (3) roles — who performs each activity; (4) a process flow or ordering/decision structure describing how activities and artifacts connect (sequential, iterative, or continuous); and (5) milestones/deliverables marking measurable progress. Pressman groups (1)–(5) around the same four generic activities plus a set of umbrella activities that run throughout the whole process rather than belonging to one phase (project tracking, risk management, SQA, configuration management — Question 6–7's subjects).

Part b) — two software project metrics. (1) Effort (person-hours or person-months expended) — a direct project measure used to track actual spend against the plan and to calibrate future estimates for similarly-sized work. (2) Defect density (defects found per KLOC or per function point, Question 5) — a quality metric used to compare modules, flag disproportionately defect-prone components for rework, and track whether quality is improving release over release. Both are quantitative, are collected consistently across projects, and feed decisions (staffing, rework priority) rather than being reported for their own sake.

Part c) — the incremental model, a likely situation, and its main drawback. The incremental process model delivers the system as a series of increments (builds), each adding working functionality to what was delivered before, rather than delivering the whole system in one pass; a core set of requirements is analysed, designed, implemented and validated first, released, and then subsequent increments add features on top of the stable core (Pressman Ch. 2; Sommerville Ch. 2). Situation likely to use it: when the customer needs core functionality delivered and usable early — even before every requirement is finalised — and staff/budget become available incrementally; the Question-4 pilot emulator fits this well, since a working "record and log a request" core (Increment 1, Question 3) has real value on its own before the authorization and conflict-check logic (Increments 2–3) is added. Main drawback: because each increment adds to a shared, already-deployed architecture, the model demands a well-defined overall architecture up front — if that architecture cannot anticipate later increments' needs, later increments force rework/regression on already-delivered increments, and integrating each new increment without breaking prior ones grows harder as more increments accumulate.