Question 1 of 8: Software Process, Process Models, and Umbrella Activities

Question 1: Software Process, Process Models, and Umbrella Activities (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 common activities. A software process is a structured, organised set of activities and associated work products that are 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 notation or tool used. Four generic activities are common to essentially every software process, regardless of the specific model chosen: specification (defining what the system should do and the constraints on its operation), design and implementation (producing a system that meets the specification, in software and/or hardware), validation (checking that the system meets what the customer actually wants), and evolution (changing the system to adapt it to changing requirements). Every named process model (Part b) is, at bottom, a different arrangement — sequential, iterative, or continuous — of these same four activities.

Part b) — three process models. Waterfall model: the four generic activities are represented as separate, sequential phases (requirements → design → implementation → verification → maintenance), with each phase completed and formally signed off before the next begins — well suited to well-understood, stable requirements. Incremental development: specification, development and validation are interleaved, and the system is delivered as a series of increments, each adding functionality to the previous one — costs of requirements change are lower than in waterfall because each increment is small. Agile development (e.g. Scrum/XP): specification, design, implementation and testing are interleaved within very short iterations (sprints, typically 1–4 weeks), with continuous customer/product-owner feedback driving re-prioritisation of what is built next — well suited to volatile or poorly-understood requirements.

Part c) — umbrella activities. Umbrella activities are process activities that are not tied to any single phase of development but instead apply across the whole software process, from start to finish, supporting and monitoring the primary engineering activities (Pressman Ch. 2). Of the umbrella activities Pressman identifies (project tracking and control, risk management, software quality assurance, formal technical reviews, measurement, software configuration management, reusability management, and work-product preparation and production), the five considered most important here are: (1) Risk management — identifying and mitigating threats to the project before they materialise (directly exercised in Question 3). (2) Software quality assurance (SQA) — ensuring work products meet defined quality standards throughout, not only at final test. (3) Software configuration management (SCM) — controlling the effects of change across every artifact the project produces (Question 7). (4) Project tracking and control — comparing actual progress against the plan and taking corrective action, without which schedule and cost overruns go undetected until it is too late to correct them. (5) Measurement — quantifying process, product and project attributes (e.g. the Function-Point sizing of Question 5) to make objective, rather than purely subjective, management decisions possible. These five are prioritised because each directly protects the project against a distinct, common failure mode — unmanaged risk, undetected defects, uncontrolled change, invisible schedule slip, and unmeasurable progress — that a purely phase-by-phase view of the process would miss.