Software Maintenance and Evolution
What to know
Maintenance is the majority of lifecycle cost. Know the four ISO-style categories: corrective (fixing defects), adaptive (responding to environment change), perfective (improving performance or maintainability), preventive (forestalling future problems, e.g., refactoring). Software evolution (Lehman's laws) observes that systems must continually change or become progressively less useful; complexity increases unless actively managed.
Understand legacy systems, reverse engineering (recovering design from code), reengineering (restructuring plus improvement), and impact analysis before change. Technical debt is the accumulated cost of shortcuts; it accrues interest as change gets harder. Regression testing and refactoring are core maintenance tools.
Traps in questions
- Category confusion: adding a feature users requested is perfective, not adaptive; adapting to a new OS is adaptive.
- Reverse vs re: reverse engineering recovers understanding without changing the system; reengineering changes it.
- Lehman's laws: "continuing change" and "increasing complexity" are often tested; complexity law says entropy rises without maintenance effort.
- Debt is not always bad: deliberate, documented debt can be rational; unintentional debt is the hazard.
Rule of thumb
Before any change, perform impact analysis: what depends on this module, what tests cover it, and what will break downstream. Then change in small, tested increments.
Worked example
A bank must migrate a COBOL batch system to a new platform. That is adaptive maintenance at the system level; decomposing it, the team first reverse-engineers business rules, then reengineers modules incrementally, running regression tests at each step to bound risk.