Question 1 of 8: The Software Development Process

Question 1: The Software Development Process (a) 10, (b) 2, (c) 8 — 20 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.

(a) Stages of the Software Development Life Cycle

A generic software life cycle comprises five stages. Requirements elicitation and analysis discovers what stakeholders need, resolves conflicts between what different stakeholders ask for, and records the agreed result as a requirements specification. Design converts that specification into a plan for how the system will be built: architectural design partitions the system into major sub-systems and their interfaces, and detailed design works out each component's data structures and algorithms. Implementation and unit testing writes the executable code and verifies each unit against its own specification in isolation. Integration and system testing assembles the units into the complete system and validates the assembled whole against the original requirements, including non-functional properties such as performance, security and reliability. Operation and maintenance is the longest stage: the delivered system is installed, used, and progressively corrected (residual defects fixed), adapted (to new hardware, platforms or regulations) and perfected (given new capability the customer now wants) as the operating environment and understanding of the requirements evolve. In practice these stages are rarely performed once in strict sequence — most projects interleave them iteratively, delivering working subsets and refining requirements and design over several cycles — but every development approach performs some form of all five activities.

(b) Typical Effort Distribution Across the Stages

Excluding post-delivery maintenance (which Sommerville reports typically consumes 60–90% of a system's total lifetime cost, but which is a separate, much longer-running activity than initial development), the effort spent during development itself is commonly cited to split roughly as: requirements elicitation and analysis ≈10–15%; design ≈20–25%; implementation (coding) ≈15–20%; and testing (unit, integration and system testing combined) ≈35–45% — testing is consistently the single largest share of development effort, not implementation, because verifying that a system meets its specification (and finding and fixing the defects that verification exposes) takes longer than writing the code in the first place. The intuitive assumption that "coding is most of the work" is wrong in industry practice: requirements and design work is comparatively front-loaded and bounded, whereas testing effort grows with the number of interacting components and the need to exercise both expected and unexpected inputs, so it dominates the schedule.

(c) Analogy with Building and Owning a House

The stages line up reasonably well at a coarse level. Requirements elicitation and analysis corresponds to the owner briefing an architect on the number of rooms, budget and site constraints; design corresponds to the architect's drawings (architectural design) refined into structural and services drawings (detailed design); implementation corresponds to construction; integration and system testing corresponds to the building inspection and occupancy sign-off; and operation and maintenance corresponds to living in the house and paying for repairs, renovations and code-compliance upgrades.

The analogy is useful for explaining the sequence of activities to a lay audience but breaks down on the properties that matter most to a software engineer. A house's design is essentially frozen once construction starts — structural changes after the foundation is poured are enormously expensive precisely because the building is a physical artifact, so change is discouraged and requirements are gathered as completely as possible up front (a waterfall-like process). Software has no equivalent physical rigidity: a design or even a requirement can, in principle, be changed after "construction" (coding) has begun, which is exactly why modern software processes are iterative and incremental rather than a single pass of sequential stages the way house-building is. A house also degrades purely through physical wear and needs no changes at all if the owner's needs never change, whereas software needs no physical maintenance yet must still change continually because the business environment around it keeps changing. The analogy is therefore good for the high-level stage sequence but misleading if taken to suggest that software, like a house, should be fully specified and frozen before "construction" begins.