Software Evolution
software evolution is such an important part of software engineering which describes the challenges of maintaining a large base of software systems, developed over many years
Why operational software has to keep changing to stay useful, the business cost of evolution, and brownfield development.
The difference between the evolution phase (major changes) and servicing phase (small essential changes) in a system's life, and what happens at retirement.
How change proposals drive evolution, the change identification/evolution cycle, and the core activities: impact analysis, release planning, implementation, and release.
Why some changes must be handled urgently, the emergency repair process, and the risks of documentation drift and accelerated software ageing
How agile practices apply to ongoing evolution, handover problems between agile and plan-based teams, and agile techniques useful for managing change
What makes a system "legacy," why it's more than just code, and the six interconnected components (hardware, software, data, business processes, policies)
COBOL and skill shortages, security vulnerabilities in old systems, and why replacing a working legacy system is expensive and risky
When to scrap, leave unchanged, reengineer, or replace a legacy system, with scenario-based matching
Plotting business value against system quality to form four decision clusters, and the four issues used to judge business value
Technical assessment factors for hardware/support software (supplier stability, age, interoperability) and application software quality indicators
The three maintenance types (fault repair, environmental adaptation, functionality addition), naming inconsistencies, and how effort is distributed across them
The four reasons maintenance is pricier than original development, and how integrating development/maintenance roles can help
Predicting future change volume, the complexity-maintainability link, and process metrics (impact analysis time, outstanding requests) used to spot declining maintainability
The five-stage reengineering process (translation, reverse engineering, restructuring, modularization, data reengineering), its cost/risk advantages over replacement, and legacy system wrapping
Refactoring as continuous structural upkeep, its tie to agile methods, common "bad smells," and how it differs from reengineering
Self-contained scenario questions on technology obsolescence, impact analysis, sociotechnical risk, reengineering strategy, support software risk, metrics programs, and professional responsibility
Comprehensive, fresh-question review spanning the whole chapter, with original use-case scenarios combining multiple concepts (strategy selection, maintenance classification, handover risk, refactoring triggers, etc.)