Jeroen’s weblog

If you’ve ever considered using metrics to support software maintenance activities, it’s good to first determine in what stage of maintenance you are since it has a lot of impact on the expected usefulness of these metrics. Dividing software maintenance in distinct stages was first proposed in a research paper by Keith Bennett and Vaclav Rajlich on what they call the staged model of the software lifecycle. This staged model divides the lifecycle of a piece of software into seperate stages: initial development, evolution, servicing, phase-out and close-down. All stages have important implications, but the ones in which actual modifications to the software itself take place after the software has been finished (and usually released) are evolution and servicing.

Software evolution is the stage where besides correcting defects new and evolving user requirements are implemented. In order for this to be viable, two conditions must be met:

• The software’s architecture must be intact.
• The original development team must be available to perform the modifications.

Apparantly, both are extremely important since they reinforce eachother. The downside is that if one of these two conditions is not met, successful evolution becomes extremely complicated, since not having a good architecture tends to make it hard to keep knowledge of the system up-to-date and not having knowledge of the system available causes decisions to be made that quickly degrade the system’s architecture. To complicate this further, the authors stress that it is almost always impossible to sufficiently document the architecture and design choices so that others can continue the work of the original developers, it’s what is called tacit knowledge.

Software servicing is the next stage, where the only goal is to keep the system functioning correctly: bugs are fixed and small modifications are implemented in order for the system to keep functioning in a changing environment, like tweaking in- or output formats, changing some code to no longer use deprecated API calls, etc. The architecture will degrade, which is not really such a problem since we’re past the point where the software could evolve anyway.

Now it’s the servicing stage that can benefit greatly from using metrics: from simple call graphs to complexity analyses, you can basically use everything to get as much information as possible to help in keeping the current functionality available and getting as complete a view as possible of the system you’re servicing. During evolution however, it appears that if you don’t have the required insight into the architecture already, there’s not much point in trying to measure the architecture. It basically comes down to this: if you need metrics to figure out how to modify a piece of software, you’re quickly heading towards servicing once you start modifying stuff.