Today most applications are Object Oriented in nature. Sizing maintenance effort is mostly based on the experience of developers working on that application. This gut-feel or experience based estimate is person specific and is not consistent or repeatable. In this…
Today most applications are Object Oriented in nature. Sizing maintenance effort is mostly based on the experience of developers working on that application. This gut-feel or experience based estimate is person specific and is not consistent or repeatable.
In this post we propose a complexity based sizing methodology for maintenance projects. A standard methodology will not only remove individual bias but also provide repeatability and consistency to the estimation process. Since it is based on standard methods of measuring complexity it can also be used to derive Organizational Baseline once sufficient historical data is collected.
The underlying assumption in the proposed technique is that more complex the application is, the more effort it will take to maintain it. There are several tools that automatically calculate the complexity of the application on several parameters like Inheritance Depth, Polymorphism, cycolmatic complexity, fan-in etc. One such tool is ckjm.
An asset inventory, including classes, methods, UI etc. of the application with complexity rating against each asset can provide an insight into the effort it takes to maintain that asset.
We can utilize a combination of standard complexity measures to derive a unit of size for maintenance work package.
Methodology
- Create an asset inventory using an automated tool like ckjm that parses your source and generates a list of classes with metrics like SLOC and Cyclomatic Complexity.
- Assign a weightage to a range of complexity
- Once the inventory is generated, create a matrix for operations on these classes as illustrated in the table below
| McCabe Cyclomatic Complexity | Complexity | Modify | Add | Delete |
| 1 – 100 | Low | 4 | 8 | 1 |
| 100 – 200 | Medium | 3 | 10 | 3 |
| High | 12 | 20 | 5 |
- Each Maintenance task may involve several operations touching several classes, a matrix can be prepared for estimation in the following format
| Class | Complexity | Modify | Add | Delete | Total Size (CU – Complexity Unit) |
| Class 1 | High | 12 | |||
| Class 2 | Medium | 10 | |||
| Class 3 | Low | 4 | 8 | 1 | |
| 16 | 18 | 1 | 35 |
- A similar matrix can be created to determine the effort and size for adding a complete new class, refactoring or other operations.
- From the above table a figure can be arrived at to determine the size and effort of the change required.
The biggest advantage is that this technique can be reused consistently across the organization since it is sizing the work package or Change Request based on the standard complexity metrics. Weights can be defined and fine tuned using statistical analysis once sufficient data is available.
In this post I have lightly touched upon this technique and implementation in a live environment needs some work.