Question 8 of 8: Development vs. Maintenance, Evolution, Version Control, and Re-engineering vs. Reverse Engineering

Question 8: Development vs. Maintenance, Evolution, Version Control, and Re-engineering vs. Reverse Engineering (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) — development vs. maintenance. Software development is the initial, largely one-time effort to design, build and deliver a new system from a set of requirements, organised into the phases already discussed (specification → design/implementation → validation). Software maintenance is every subsequent change made to a delivered system while it remains in operational use — correcting defects (corrective), adapting to a changed environment (adaptive), adding new capability (perfective), or improving internal quality without changing behaviour (preventive). Maintenance typically consumes 60–80% of a system's total lifecycle cost (Sommerville Ch. 9), far exceeding original development cost, and unlike development it is repetitive, open-ended in duration, and constrained by the need to preserve existing, in-production behaviour while changing it.

Part b) — software evolution vs. maintenance. Software evolution is the broader, whole-lifecycle view: the continual process by which a system changes and adapts over its entire useful life, from initial development through every subsequent release, including changes so extensive they amount to re-architecting or partially re-engineering the system (Question 7's variant-management scenario, or a move from a monolithic to a service-based architecture, are both evolution). Maintenance is traditionally the narrower, operational-phase term for the day-to-day corrective/adaptive/perfective changes made to a system already in production, without fundamentally changing its architecture. In modern usage (Sommerville explicitly prefers "evolution" over "maintenance"), maintenance is best understood as a subset of the wider evolution process — the incremental, in-place changes — while evolution also covers the larger, more disruptive architectural changes that periodically punctuate a long-lived system's life.

Part c) — version control. Version control (revision control) is a system for recording and retrieving the history of changes made to a set of files (source code, design documents, test suites — the CIs of Question 7) over time: every committed change is retained, any historical version can be recovered, and multiple developers can work on the same files concurrently through branching and merging, with a clear audit trail of who changed what, when, and why. It is the core mechanism configuration management (Question 7b) relies on to actually implement version identification and configuration auditing in practice.

Part d) — re-engineering vs. reverse engineering. Reverse engineering's goal is to analyse an existing system's code and recover a higher-level abstraction from it — design models, or even requirements — typically because the original documentation is missing, lost or out of date; it does not itself change the system, only the team's understanding of it. Re-engineering (or software re-engineering) is the broader forward-looking activity of actually transforming a legacy system into a new, improved form while preserving its external functionality — it typically proceeds in three stages: reverse engineering (understand the existing system), restructuring (redesign/reorganise), and forward engineering (rebuild into the improved target system). In short: reverse engineering understands without changing; re-engineering changes, and normally uses reverse engineering as its first stage.