Question 1 of 8: The Software Development Process

Question 1: The Software Development Process (a) 10, (b) 5, (c) 5 — 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 actually need, resolves conflicting demands among them, and records the outcome as a requirements specification that both customer and developers can agree on. Design takes that specification and works out how the system will be built: architectural design partitions the system into major subsystems and their interfaces, while detailed design works out each component's internal data structures and algorithms. Implementation and unit testing translates the design into executable code and verifies each unit in isolation against its own specification. 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, reliability and security. Operation and maintenance is the longest stage: the system is installed and used, and is progressively corrected (fixing residual defects), adapted (accommodating new hardware, operating systems or regulations) and perfected (adding capability the customer now wants) as the operating environment and the understanding of the requirements evolve.

(b) Effort Distribution Across the Stages

Industry data on software effort is usually reported in two separate views, and both are needed to answer this honestly. Pre-delivery (development) effort follows the widely-cited "40–20–40" rule of thumb: roughly 40% of development effort goes to requirements analysis and design combined, 20% to coding (implementation and unit test), and the remaining 40% to integration and system testing — testing is typically the single largest pre-delivery activity because defects found late are far more expensive to fix than defects found while the system is still being designed. Post-delivery, however, operation and maintenance dominates everything else: industry studies consistently report that corrective, adaptive and perfective maintenance together consume somewhere between 60% and 90% of a software system's total lifetime effort, because a delivered system is typically used and evolved for years while development itself takes only months. The explanation for this split is structural, not accidental: software has no physical wear mechanism, so once delivered it does not need "servicing" the way a machine does, but it must still change constantly to track evolving requirements, new platforms, and defects discovered only once real users exercise it under real conditions — and that ongoing change is exactly what the 60–90% maintenance figure measures.

(c) Software Development vs. Building and Owning a House

The stage-by-stage mapping is close. Requirements elicitation corresponds to deciding what kind of house is needed — number of bedrooms, lot, budget, style — in consultation with the eventual occupants. Design corresponds to the architect's blueprints: an architectural design (site plan, floor plan, structural layout) followed by detailed design (wiring diagrams, plumbing runs, material specifications). Implementation and unit testing correspond to construction itself and to the trade-by-trade inspections that check each subsystem (electrical, plumbing, framing) against code as it is built. Integration and system testing correspond to the final building inspection and walkthrough, where the assembled house as a whole is checked against the building permit and the owner's original requirements before occupancy is allowed. Operation and maintenance correspond to decades of living in the house: routine upkeep, repairs as components wear out, and renovations as the occupants' needs change — and, just as in software, this stage dominates the total cost of ownership, since a house's purchase/construction price is typically a smaller fraction of what is spent on it (mortgage interest aside) than the cumulative cost of maintaining, heating, repairing and renovating it over 30+ years of occupancy.

The analogy is genuinely useful for two ideas: first, that changes are progressively more expensive the later they are made (moving a wall on a blueprint costs almost nothing; moving it after the framing is built costs a great deal — exactly mirroring the "cost of change" curve for fixing a requirements error before vs. after coding); and second, that the acquisition/construction cost is only the down payment on a much larger stream of ownership cost. Where the analogy breaks down is in the nature of that ownership-stage cost. A house degrades through physical processes — wear, weathering, material fatigue — that occur whether or not the house is used, and its fundamental requirements (a place with a given number of rooms, a certain layout) are largely fixed once built; renovation is the exception, not the rule. Software has no physical wear at all: a program does not degrade by being run, and every maintenance activity is really a form of re-design driven by changing requirements, new environments or previously undiscovered defects rather than by physical decay. So the two processes look alike in structure and in "maintenance dominates the bill," but the underlying reason maintenance dominates — physical entropy for a house, versus continual re-specification for software — is fundamentally different, and a house's design is far less expected to keep changing after construction than a software system's is expected to keep evolving after delivery.