Question 8 of 8: Development vs. Maintenance, Maintenance Cost, Reverse Engineering, Restructuring, and Reuse

Question 8: Development vs. Maintenance, Maintenance Cost, Reverse Engineering, Restructuring, and Reuse (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, typically 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, e.g. a new OS version), adding new capability (perfective/enhancement), or improving internal quality without changing behaviour (preventive, Part d's restructuring). Maintenance typically consumes 60–80% of a system's total lifecycle cost and effort (Sommerville Ch. 9), far exceeding the 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) — when maintenance begins. Formally, maintenance activities begin the moment the system is accepted and enters operational use by real users (i.e. at delivery/deployment) — any change made after that point, however small, is a maintenance activity by definition. In good practice, however, planning for maintainability (modular design, thorough documentation, automated test coverage) must begin much earlier, during design and implementation, because a system not designed to be maintainable is disproportionately expensive to maintain later (directly connecting to Part c).

Part c) — why maintenance is expensive. Maintenance is expensive for several compounding reasons: the developers making a change are frequently not the ones who originally wrote the affected code, so they must first reconstruct the original design intent, often from incomplete or stale documentation (a knowledge-recovery cost development itself never pays). Every change to a live, in-production system carries regression risk — the fix or enhancement may itself introduce a new defect — which demands disproportionately thorough re-testing relative to the size of the change. Systems accumulate structural complexity and inconsistency over many successive, time-pressured changes ("software aging" or "software entropy," Part d's restructuring problem), so each new change is harder to make safely than the last. Finally, because the system is business-critical and already in use, changes must often be made with minimal downtime and under tighter operational constraints than original development ever faced.

Part d) — reverse engineering, restructuring, and reuse. Reverse engineering's goal is to recover a higher-level abstraction — design models, or even requirements — from an existing system's code, typically because the original design documentation is missing, lost or out of date; it supports understanding an undocumented legacy system well enough to maintain, extend, or safely re-platform it, without necessarily changing the system itself. Restructuring's goal is to transform a system's internal structure (code organisation, module boundaries, control flow) to reduce complexity and improve maintainability, testability and readability, while explicitly preserving the system's external, observable behaviour — the same discipline as refactoring, applied deliberately as a preventive-maintenance activity rather than incidentally during a feature change. Reusing software (existing components, frameworks, libraries, or entire subsystems) delivers several benefits: reduced development cost and time (a proven component need not be built from scratch); improved reliability (a component already exercised in production has already had many of its defects found and fixed); consistency across systems that share the same reused components; and a faster path to market, freeing the team's limited effort to focus on the parts of the system that are genuinely novel or differentiating rather than re-solving an already-solved problem.