Index Up Site Map Latest News Working Practices Discussion & Review Glossary Module Testing Non-Func. Testing Domains-Techniques Links Test Papers Feedback Administration

Maintainability Guidelines


Maintainability is defined as the ease with which changes can be made to a software system. These changes may be necessary for the correction of faults, adaptation of the system to a meet a new requirement, addition of new functionality, removal of existing functionality or corrected when errors or deficiencies occur and can be perfected, adapted or action taken to reduce further maintenance costs.

Maintainability testing is not the same as maintenance testing which is testing software that has been modified.


Maintainability can be either a static form of testing, i.e. carried out by inspections and reviews, or a dynamic form i.e. measuring the effort required to execute maintenance activities.

Maintainability Assessment – Static Maintainability Testing

The following steps should be undertaken to assess maintainability statically:

-          A list of maintainability factors to be included in the assessment should be devised e.g. structure, complexity.

-          Each factor (or group of factors) should be assigned a weighting to indicate its importance to the overall maintainability of the system.  Each factor will have a maximum score of 10. The higher the score the less maintainable the system.

-          During the assessment a score is awarded against each factor on the list. For example, a relatively old system may be awarded a score of 8 out of 10 to indicate that due to its age the system will relatively difficult to maintain.

-          The scores for each of the factors assessed are then multiplied by the appropriate weighting and the resultant products are then summed to give an overall score which forms the Maintainability Measure of the system (the lower the score, the better the maintainability of the software system).

Example factors which can be used in a maintainability assessment are given below; the list is not exhaustive and should be modified to suit an individual organisation (although it is helpful if the same list is used throughout the organisation so comparisons between systems can be made):

§          Size

§          Maintainers’ perception

§          Complexity

§          Environmental facilities

§          Structure

§          Maintenance relationships

§          Development process

§          System users/customers

§          Documentation

§          Maintenance team

§          Development team

§          Test facilities

§          Development timescale

§          Operating procedures

§          Maintenance procedures

§          Problem change traffic

§          Development relationships

§          Business change traffic

Using the Results

Once the Maintainability Measure has been derived, the weighted score for each factor assessed can be ranked to identify areas most in need of attention. For instance, action plans to address these areas, addressing the factors with the highest score first, can then be produced, detailing activities with the associated cost and maintainability benefit.

There are no objective (preset) targets for the Maintainability Measure; targets are set individually for each new system.  Constraints such as time, cost, resource availability and technical limitations will affect the required Maintainability Measure.

Maintainability tests are considered to have passed when the Maintainability Measure from the assessment is such that the objectives can be met.

Maintainability Assessment – Example

The following is a simplified example using a subset of the possible maintainability assessment factors in order to show the technique in practice.

We need to test the maintainability of a system which is being introduced into the support function as the result of a merger with another company. We have a database of maintainability measures for other systems of a similar size and technology, and have calculated an average maintainability measure figure which equals 300. The requirement is that the ‘new’ system has a maintainability measure not greater than this average.

The following table shows the subset of factors chosen from which a Maintainability Measure will be calculated, their relevant weightings and the final score.  Note that the maximum score for all factors is 10.



Actual Score

Weighted Score

Business Requirement Complexity

Application Complexity

Data Structures Complexity

Code Complexity

Change History Documentation

Automated Documentation

Business Overview Documentation

Code Annotation

Code Size

Release Frequency































Overall total MM




From the table we can see that the required Maintainability Measure is not greater than 300, so the system has met the maintainability requirement.

Maintainability measures can be calculated and recorded at regular intervals, showing trends in maintainability, both positive and negative. It should be noted that, as this technique is dependent on deriving a suitable maintainability measure from information about the maintainability of existing systems, it is not easily suited to systems where there is little historical data from which to build the measure. It is also best to establish a single list of maintainability factors to be used throughout an organisation to allow accurate comparison between systems.

There are a number of examples of this method available from sources such as the CCTA.