Helpful Analysis
Maintenance and Support (M&S) productivity can be expressed in terms of the number of people (full time equivalent) supporting a measurable amount of software (functional size).
- Seek correlations between productivity
(effort/size ratio) and the rates of changes
made, defects reported, technology used, etc.
- Plot the effort/size ratio against the age of the applications (time since the last re-write). Typically effort is initially high, falls to a low level, then rises as it ages.
This 'bathtub' graph can be used to plan when it is cheaper to replace than maintain. If productivity does not fit the general curve, ask ‘why’?
- Plot annual M&S costs against running costs. Look for very high ratios, taking into account the volume of processing. Applications which cost a little to run and a lot to maintain may be being changed disproportionately.
|
Key Action Priorities
- Reduce unjustified enhancement work. Reject all enhancement requests which are not justified by business needs. Do not allow enhancements simply because there is budget to be used.
- Bundle minor changes and fixes into larger releases. There is a large overhead whether making few or many changes due to impact analysis, planning, testing etc. (Note: XP users may still want to bundle up minor changes so that stories can be analysed and prioritised.)
- Improve documentation. M&S groups seldom have adequate documentation or a proper configuration management (CM) system to keep it in. Investment in training and processes for documentation and CM will pay off.
- Focus on error-prone modules. If there are recurrent defects, they often occur in the same pieces of the code. Many studies show that a few defects can give rise to a high proportion of failures (often the 80:20 rule applies). Measure the level of defects per module (or piece of code) and focus remedial action accordingly.
- Training. It may not be the M&S group who most need training. To reduce unnecessary demands on their time, look to the needs of both end users and their first line support staff.
- Testing. Look at how much effort is spent on testing and why. Look for inefficiencies in testing and problems in earlier stages of work adversely affecting testing.
- Plan Replacements. Analyse support costs to predict when replacement of a system is more cost effective than continued maintenance. Plan replacement in good time.
|
