Jeroen’s weblog

In the past weeks I’ve been stressing the complexity and nature of typical software maintenance activities. Before you can typically dive into performing maintenance however, an estimation of the required effort is usually needed. Now I’m not going to go present some foolproof formula to figure out how much time and effort is going to go into maintenance (since there is no such formula and several books have been written dealing with the topic in detail) but I can discuss some of the important issues that have a big impact on the final estimation.

First of all and most importantly is the state of the software you need to maintain. A couple of weeks ago I’ve discussed these quality attributes related to maintenance.

Next, the type of maintenance you need to perform is important. The reason these types of maintenance are important for determining the amount of effort required is because their impact on the system differs from type to type. Here’s a list of types of maintenance (from the IEEE’s software maintenance glossary) and some considerations to remember when performing them:

• Corrective — modifying the system to repair hardware or software faults. Basically fixing bugs, ranging from small rounding errors to complete system crashes.

  A system is typically designed to be consistent and function correctly (try not to think about cases where this is not true), so corrective maintenance is usually just a matter of finding the coding or design error and correcting it. Ofcourse there is the possibility that a bug ends up showing that the entire architecture is broken, but that’s a rare case. So the question to ask here is: is this a subtle bug or a fundamental error in the original design?

• Adaptive — modifying the system so that it can function in a changed environment. This can mean porting an application from Windows to Linux, but also modifying an application to be able to run without administrator priviliges.

  There are two questions you need to answer when estimating adaptive maintenance. First, how much is the target environment different from the current environment? Second, how closely is the system tied to the current environment? Going from Windows Forms 1.0 to 2.0 is a reasonably small change, but porting a native Win32 application to Linux is way much more work, especially if the application uses threads heavily, since threading APIs are typically very platform-specific.

• Perfective — improving the system, both functionality (what it does) and non-functionally (how it does it). These are typically user requests.

  This type of maintenance can have a huge impact even on the architectural level: sometimes users want modifications that are completely contradictory to what a system is supposed to be able to accomplish. I once developed a test application to replace a piece of hardware while developing software to interface with it. The application ended up having to be distributed as a learning tool to customers since the hardware wasn’t finished yet at the end of the project. It was designed to have a user interface that was useful for developers to test the functionality of the software, not for end users to learn to work with their upcoming hardware. The question to ask here is: how far removed from the original functionality of the system is this request?

• Preventive — modifying the system to make it better capable of handling current and future required changes. Refactoring can often be considered a typical form of preventive maintenance.

  This is easily the most complicated of all. Assuming you need to maintain a system that was developed by someone else and time has been allocated to perform preventive maintenance, this probably means the system is of high value and additional modifications will be required in the future (since those are the reasons for investing in preventive maintenance). What is basically asked of you is to modify the system in such a way that maintenance effort will decrease in the future. This can only be achieved by making sure the system’s architectural integrity is intact and gaining an understanding of the system’s inner workings similar to that of the original developers. Only by careful inspection and working with the code extensively can this be achieved, since you can’t measure architecture.

As described, the list above basically presents the types of maintenance in increasing order of average required effort. Note the word average however, since all types have both positive and negative excesses.

Another thing to remember is that both Shari Pfleeger (in Software Engineering, Theory and Practice) and Thomas Pigoski (in Practical Software Maintenance) conclude that understanding the system takes up about 40-60% of the time required to perform a maintenance activity. So once you have a good idea of what has to be done to do the maintenance, it’s usually safe to double that estimate.