Maintenance

Comprehensive reference on software maintenance models, evolution, reverse engineering, and legacy system modernization. Models: Boehm ACT, Belady-Lehman, CMM Level 5

Table of Contents

1. Software Maintenance Fundamentals
2. Categories of Maintenance
3. Maintenance Process & Activities
4. Maintenance Cost Models
5. Software Evolution (Lehman’s Laws)
6. Reverse Engineering
7. Software Re-engineering & Legacy Modernization
8. Configuration Management & Version Control
9. Software Documentation
10. Retirement & Decommissioning

1. Software Maintenance Fundamentals

Software maintenance is the process of modifying a software system after delivery to correct faults, improve performance, adapt to changing environments, and prevent future issues. It is the longest and most expensive phase of the SDLC — often consuming 60-90% of total lifecycle costs.

Key Maintenance Objectives

• Ensure continued operational effectiveness
• Adapt to evolving environments (OS, hardware, regulations)
• Fix defects discovered post-release
• Enhance functionality to meet emerging needs
• Improve system performance, security, and usability
• Preserve institutional knowledge through documentation

Maintenance Challenges

2. Categories of Maintenance

Corrective Maintenance

Fixes defects found after the software is in use. Includes:

• Emergency fixes (critical production bugs)
• Routine bug fixes (non-critical defects from backlog)
• Patch releases for reported issues

Adaptive Maintenance

Modifications required when the software’s external environment changes:

• Operating system upgrades
• Database platform migrations
• Hardware changes
• Regulatory and compliance updates
• Third-party API deprecations

Perfective Maintenance

The largest category — enhancements to improve the software:

• New features and functionality
• Performance optimization
• Usability improvements
• UI/UX refinements
• Code restructuring for better maintainability

Preventive Maintenance

Proactive measures to reduce future maintenance costs:

• Refactoring (improve structure without changing behavior)
• Code reviews and quality improvements
• Test coverage expansion
• Documentation updates
• Dependency upgrades (before they become critical)

3. Maintenance Process & Activities

Maintenance Process Flow

Change Request -> Impact Analysis -> Planning -> Implementation
    -> Review -> Testing -> Deployment -> Verification

Key Activities

Maintenance Priority Levels

4. Maintenance Cost Models

Boehm’s ACT (Annual Change Traffic)

ACT measures the fraction of a software product’s source instructions that undergo change during a year.

ACT = (Total Lines Changed + Added + Deleted) / Total Lines

Cost Estimation: Annual Maintenance Cost = Development Cost × ACT

Typical ACT values:

• Stable system: 10-20% per year
• Active development: 30-50% per year
• Rapidly evolving: 60%+ per year

Belady-Lehman Model

Cost increases exponentially with lack of maintenance:

Maintenance Cost = C × exp(D × Time Since Last Redesign)

Where:

• C = initial maintenance cost
• D = design deterioration factor
• Time = elapsed since last significant redesign

This model suggests that periodic major redesigns are more economical than continuous small patches in the long run.

Cost Factors

5. Software Evolution (Lehman’s Laws)

Lehman formulated eight laws describing the inevitable evolution of software systems over time:

Practical Implications

• Plan for change — architecture must accommodate evolution
• Combat complexity — active refactoring is mandatory, not optional
• Invest in quality — without maintenance, quality inevitably declines
• Accept continuous growth — systems naturally expand; plan capacity accordingly

6. Reverse Engineering

Reverse engineering is the process of analyzing a system to identify its components and their relationships without modifying it. It recovers design information from existing code or binaries.

Goals

• Understand how a system works when documentation is missing
• Discover hidden dependencies and side effects
• Extract business rules embedded in legacy code
• Prepare for re-engineering or migration
• Identify security vulnerabilities

Techniques

Reverse Engineering Process

1. Information Extraction — gather all available data (source, binaries, docs)
2. Abstraction Generation — create models at higher abstraction levels
3. Design Recovery — reconstruct design decisions and rationale

7. Software Re-engineering & Legacy Modernization

Re-engineering is the examination and alteration of a system to reconstitute it in a new form with improved quality, maintainability, or performance.

Re-engineering Process

Reverse Engineering (understand current system)
       |
       v
Restructuring (improve structure without changing function)
       |
       v
Forward Engineering (create improved version)

Legacy Modernization Strategies

Strangler Fig Pattern

Gradually migrate legacy functionality to new services:

1. Route specific features to new service
2. Keep remaining traffic on legacy system
3. Remove migrated code from legacy system
4. Repeat until legacy system is empty

8. Configuration Management & Version Control

Configuration Management (CM)

CM tracks and controls changes to software artifacts throughout the lifecycle.

Key Functions:

• Identification — uniquely identify all configuration items (CI)
• Version Control — track versions of all artifacts
• Change Control — manage changes to baselines
• Auditing — verify that what’s documented matches reality
• Status Accounting — report on the status of CIs

Version Control Best Practices

Semantic Versioning

MAJOR.MINOR.PATCH (e.g., v2.5.1)

9. Software Documentation

Documentation Types

Documentation Best Practices

• Treat docs like code — version-controlled, reviewed, tested
• Keep docs close to code — README files, docstrings, ADRs
• Automate generation — API docs from annotations, changelogs from commits
• Document why, not what — code expresses what; docs explain why
• Living documentation — update alongside code changes
• Architecture Decision Records (ADR) — document design decisions and context

10. Retirement & Decommissioning

When to Retire a System

• No longer meets business needs
• Maintenance costs exceed replacement cost
• Technology is obsolete and unsupported
• Regulatory or compliance requirements change
• A replacement system is operational

Decommissioning Process

1. Assessment — evaluate data, dependencies, and usage
2. Data Migration — archive or migrate business data
3. User Communication — notify users of timeline and transition plan
4. System Shutdown — gracefully terminate services
5. Verification — confirm no remaining dependencies or active users
6. Cleanup — de-provision infrastructure, remove credentials

Decommissioning Checklist

• All data archived or migrated
• Dependencies documented and redirected
• Users notified and transitioned
• Infrastructure de-provisioned
• Code archived in version control
• Documentation preserved
• DNS and load balancer entries removed
• Secrets and credentials rotated

References: Boehm ACT, Belady-Lehman, Lehman’s Laws, CMM Level 5, IEEE Standard for Software Maintenance