Question 1 of 9: The Software Development Process

Question 1: The Software Development Process (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 conflicting demands, and records the result as a requirements specification the 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 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 and reliability. 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 understanding of the requirements change. In practice these stages are rarely followed strictly in sequence — most modern projects interleave them iteratively or incrementally, delivering working subsets of the system and refining requirements and design across several cycles — but the five activities themselves (specify, design, build, verify, evolve) are present in every development approach.

(b) Software vs. Equipment Life-Cycle Costs

Purchasing and owning a car or refrigerator follows a broadly similar shape: a needs assessment (what capacity, what budget), a selection/acquisition stage (comparing models, purchasing), a commissioning stage (delivery, initial setup), an operating stage in which the owner uses the item and pays for consumables (fuel, food-safe cooling) and routine servicing, and finally a disposal/replacement stage once the item wears out or becomes uneconomical to repair. This maps loosely onto the software life cycle's requirements → design/build → delivery → operation → retirement structure, and in both cases the acquisition cost is only the first instalment of the total cost of ownership.

The life-cycle cost profiles, however, differ sharply. For physical equipment, cost is dominated by the initial purchase price plus a roughly predictable, rising curve of preventive maintenance and part replacement driven by mechanical wear — a car's brake pads, a refrigerator's compressor, all degrade through physical use regardless of whether any "defect" was ever present, and the owner eventually retires the item outright once repair cost exceeds replacement cost. For software, acquisition (development) cost is typically the smaller share of total lifetime cost: because software has no physical wear mechanism, it does not degrade with use, but it must still change constantly to track evolving requirements, new hardware and operating-system platforms, and defects discovered only once the system is exercised by real users under real conditions — and empirically this post-delivery maintenance activity consumes the majority (commonly 60–90%) of a software system's total lifetime cost. The two are similar in that both incur an ongoing cost stream after acquisition and both eventually reach a point where continued ownership stops making economic sense; they differ in that hardware's ongoing cost is driven by physical entropy and is comparatively predictable, whereas software's ongoing cost is driven by changing requirements and repeated modification, tends to grow (rather than merely continue) as the system ages and its structure erodes under successive patches, and ends not in physical failure but in the system becoming too costly or too brittle to change further (a state sometimes called "legacy" rather than "worn out").