Maintenance types; design for maintainability

Software maintenance is the modification of software after delivery to correct faults, adapt it to a new environment, or improve it. Since maintenance often costs more than development, the design must make change easy.

Types of software maintenance

1. Corrective maintenance

   • Fixing faults found after delivery: coding, design or requirements errors.
   • Example: a payroll system calculates overtime wrongly; the formula is corrected.

2. Adaptive maintenance

   • Modifying the software to work in a changed environment: new hardware, operating system, database, or new laws and business rules.
   • Example: the payroll system is updated when the government changes the income tax slabs, or is moved to a cloud server.

3. Perfective maintenance

   • Adding new functions or improving performance and usability on user request. This is the largest share (about 50–65%) of maintenance effort.
   • Example: adding a feature to email payslips to employees.

4. Preventive maintenance

   • Improving the structure and documentation of the software to make future maintenance easier, without changing its behaviour.
   • Example: restructuring a large, complex salary module into smaller, documented functions.

Design principles for maintainability

Maintainability is how easily software can be understood, corrected, adapted and enhanced. The following design principles improve it:

1. Modularity: divide the system into small, well-defined modules so a change affects only one module.
2. High cohesion: each module does one clear job, so it is easy to understand and change.
3. Low coupling: modules depend on each other as little as possible, through simple interfaces, so a change does not spread.
4. Information hiding and encapsulation: hide internal data and design decisions inside modules; others use only the public interface.
5. Abstraction and layering: separate concerns into layers (presentation, business logic, data access), so for example the database can be replaced without changing the user interface.
6. Simplicity: prefer simple designs and keep complexity (such as cyclomatic complexity) low; avoid clever but obscure code.
7. Avoid duplication (DRY): keep each piece of logic in one place so a fix is made once.
8. No hard-coded values: keep tax rates, URLs and limits in configuration files or tables, so adaptive changes need no code change.
9. Coding standards and meaningful names: consistent style and clear names make code readable by others.
10. Good documentation: keep design documents, interface descriptions and comments up to date.
11. Use design patterns and standard components: well-known solutions are easier for new staff to understand.
12. Design for testability: provide automated unit and regression tests so changes can be checked quickly.
13. Robust error handling: check inputs and handle exceptions clearly, which makes faults easier to locate.

Example: if the payroll system keeps tax slabs in a database table and calculates tax in one separate module behind an interface, a change in tax law needs only a data update or a change to that single module.