Maintenance Estimation
Has your boss ever dropped by and asked “How hard would it be to add X functionality”, or “What’s involved in fixing that bug in Y”? Some call this activity “Software Estimation”, others “Change Scoping”, and still others “SWAG” (sophisticated wild assed guessing). Since we are focused on tools for software maintenance, we call it “Maintenance Estimation”.
Understand has been used to assist in Maintenance Estimation since we first offered it. This traditionally involved collecting metrics of the code involved, identifying and comprehending dependencies (call tree usually), and mashing it all together into an informed estimate. Enough customers told us of how they used Understand in that role that we decided that 2.0 should have features directly supporting it.
And thus the new “Estimate” menu was born. “Estimate” helps engineers prepare, measure and assess plans for software modifications and enhancements. It is focused on supporting scoping of changes to existing code. It supports specifying new code to be hooked into existing code.
The “Estimate” menu inside Understand 2.0 offers personal Maintenance Estimation by a single engineer. A tool we will release later this year, tenatively called “Impact”, permits combined multi-user estimation that can integrate plans and estimates from multiple engineers planning maintenance on the same body of source code.
Build 447 will contain the first public release of the “Estimate” feature of 2.0. It is brand new and we release it more for comments/suggestions than for you to do large amounts of estimating work with. We wanted to get some early feedback so we could have time to respond to it as we finalize other features in the tool.
So please give it a try. I’ll go over the concepts below the fold. Your feedback is very welcome.
Concepts
“Estimate” maintenance estimates are based on these concepts:
- Scenarios – Scenarios are basically glorified ToDo lists. For instance, I could organize my maintenance estimate into something like this:
I built the above hierchy using the “Estimate” menus Scenario builder. - Plans – Plans are saved states of the checkboxes next to scenarios. For instance a default plan “Everything” is always available. But I could also have a plan called “Bug Fixes Only” that remembered I’d only had Bug Fixes checked:
- Code Changes – Code Changes are where you specify where a change is going to occur and what the nature of the change will be. You can specify code changes in three ways:
- Entities – just pick an entity, like a function, procedure, class. Indicate how it will change. Use this for precise planning.
For instance, here I’ve added the Class Renderer as something that will change for Scenario 15 (Fix the Renderer). I’ve also indicated that it’s interface, inheritance and internal logic will change. - Architectures – if you know the general area is going to globally change, like for instance the entire Renderer in the project I’m working with, you can specify that architectural area.
Here I associated the entire architectural area “OpenExpr” with the scenario for fixing an infinite loop in the expression parser. - New Code – most maintenance projects require new code. The “Estimate” menu lets you specify parameters of new code that is to be written in support of a scenario. If the new code is similar to existing code you can specify it with a single click by choosing what it is similar to.
Here I’ve added a new class for rendering to PDF that I expect to be similar to rendering to a TIFF file:
Once I’ve built up my hierarchy of scenarios and entities, architectures that I’m going to change as well as new code I’m going to add, then I can quickly get reports showing detailed information that can guide me with estimates.
And I can see what the impact of my scenarios are through different architectural views. For instance here I can see “RI” – the rendering interface – is affected by the Performance Enhancements and PDF support scenarios.
As the saying goes… there is a lot more where that came from. But I’ll stop now having covered the basic of maintenance estimation with Understand 2.0. If you have ideas and feedback on this new feature, please e-mail our support address.
Leave a comment