Question 8 of 8: Software Development vs. Evolution, Maintenance Onset, Program Comprehension, and Restructuring

Question 8: Software Development vs. Evolution, Maintenance Onset, Program Comprehension, and Restructuring (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 development vs. software evolution. Software development is the initial activity of specifying, designing, implementing and validating a system that does not yet exist — e.g. building the pilot emulator's Question-4 increments for the first time. Software evolution is the subsequent, ongoing activity of changing an already-deployed system in response to new requirements, defects, or a changed operating environment, without stopping its continued use. The two share the same underlying technical activities (analyse, design, implement, test) but differ in context: development works against a largely blank slate, while evolution must preserve the existing system's behaviour and users while changing it, under real deployment constraints (Question 7's configuration/version control, live users depending on the current baseline).

Part b) — when maintenance activities must begin. Maintenance activities must begin as soon as the system is deployed and in operational use — in practice, planning for maintainability (documentation, clean architecture, Question 7's configuration management discipline) must start during development, since a system built without those provisions is far more expensive to maintain later; but the maintenance activities themselves (defect correction, adaptation to environment changes, enhancement) formally begin at the point of first operational release/acceptance and continue for the system's entire operational life, typically outlasting the original development effort in both duration and cumulative cost.

Part c) — purpose of program comprehension. Program comprehension is the process of building an accurate mental model of what an existing program does and how, before changing it. Its purpose is to let a maintainer safely locate the code responsible for a given behaviour, predict the consequences of a proposed change, and avoid introducing a regression — it is a prerequisite for every maintenance activity in Part (b), and its cost (often estimated as the majority of total maintenance effort) is exactly what good documentation, clear naming, and a well-organised architecture (Question 1(a)'s process artifacts) are meant to reduce.

Part d) — purpose of restructuring. Restructuring (including refactoring at the code level) is the purpose-built activity of improving a system's internal structure — readability, modularity, removal of duplication — without changing its external, observable behaviour. Its purpose is to reduce the cost of Part (c)'s program comprehension and Part (a)'s subsequent evolution effort: a well-restructured system is easier to understand, safer to change, and less likely to accumulate the "technical debt" that otherwise makes each successive change to an ageing system more expensive than the last.