• Corrective maintenance: corrects discovered problems;
• Adaptive maintenance: keeps software usable in a changed or changing environment;
• Perfective maintenance: improves performance or maintainability;
• Preventive maintenance: corrects latent faults in the software before they become effective faults.

Others have attempted to identify more types of maintenance activities, but these have served well to cover the activities of most business IT activities.

Another useful model for looking at maintenance work is defined in terms of software evolution.  Professor Meir Lehman, working with others, attempted to define Eight Laws of Software Evolution.  In my opinion the first two of these laws are typically the most relevant:

• Software must continuously change to maintain its usefulness
• As the software is changed it becomes increasingly complex unless work is invested to prevent this
  
  

• Technical understanding
• Impact analysis
• Testing
• Maintainability

Technical understanding refers to the ability of a developer to understand where and how a program change needs to be made, particularly in programs the developer did not personally author.  It is worth noting that studies have documented that 40-60% of maintenance developers’ time is spent trying to understand the programs to be modified.  There are two general categories of tools that assist this effort:

• PCOSA – Program Comprehension through Static Analysis – these are tools that represent the source code to the developer in various ways to expedite understanding and analysis; i.e., the source code is sliced, diced, graphed and made navigable in various helpful ways.  vLegaci’s Codelyzer is primarily this type of tool.

• PCODA – Program Comprehension through Dynamic Analysis – these are tools that examine trace records of program execution and present the results in various ways to help developers understand what actually happens when a program executes.  Codelyzer has features that enable this sort of analysis.

Impact Analysis is the process of analyzing the source code to identify the full extent of modifications needed to fulfill Change Requests without adding new defects to the system.  Typically this is begun in a project planning phase that identifies the scope of modifications, work effort and risks, and is then completed in the coding phase.  Organizations typically have little in the way of defined processes around this critical task -  Codelyzer has features that assist in this task and support its systemization.

Testing in software maintenance is divided into feature testing and regression testing.  Feature testing is similar to testing for new development but can have the added complexity of coordinating multiple developers performing simultaneous work on the same sections of code, typically due to production support needs.  The primary issue in software maintenance testing is that of regression testing – repeatedly re-testing sections of the system to ensure that new defects have not entered the system in areas that were previously performing correctly.  This carries three main challenges: 

1. Identifying the sections of the system that need regression testing. 
2. Describing the tests that need to be conducted to prove the system performs as before.  Codelyzer has features that help with identifying and documenting business rules that should be included in regression testing.
3. Executing those tests in a cost-effective manner.  There are tools on the market that assist with this process.

Maintainability is foremost something that needs to be designed into a system when it is first built.  It is difficult and costly to improve after the fact, however, preventing the maintainability of a system from degrading is an important aspect of preserving the system's value and should be an explicit and measured goal of maintenance operations.  Codelyzer has analytical measurement features that assist in measuring and monitoring a system's maintainability.