Estimation Example - From a Single Line (VB6 to VB.Net)

Introduction: Many a times, we have to estimate pratically with thin air i.e no information available except for a line or two.

Cannot blame anyone for this, in this fast pace life and industry.

Below is a hypothetical example (but not impractical) that i have taken and tried to work out. The aim of example below is to give direction and get one started in the thought flow. It is not intended to be a complete proposal or solution in anyways.

Any comments, criticism and remarks would be appreciated and helpful.

Input: The only input is that the client had 1.2 million line of VB code that needed to be migrated to .Net. And the reason was that the application was quite old and maintenance was becoming an issue as well as retaining the talent of VB skills.

Approach: Ideally it would have been nice to talk to client and understand the exact reason for migration and also if any value added services could be provided while migration like, Need to host part or entire application on Web; Availability of the application on both Desktop and Web; Any part of the application that needed to be exposed as service for other application, etc.

But with no provision to clarify the above details and with just the scope of submitting a proposal to the one line input, below is a possible approach. ( Was aided by a colleague too in brainstorming the approach).

Instead of going the typical numeric way by dividing the number of LOC with productivity, we went about defining the various stages that would be required in the project, estimating for each stage and then totalling it up.

Now there are a couple of tools available in the market that migrate code from VB6 to Vb.Net and they are as follows:
1. Microsoft upgrade wizard that comes along with the Visual Studio IDE.
2. VB Migration Partner (http://www.vbmigration.com/overview.aspx)
3. VB Upgrade Companion (http://www.artinsoft.com/pr_vbcompanion.aspx)

Some do the job better than the other and that’s need to be investigated. But generally no tool does a complete job and also it is good practise to check the existing code to see if it can be tweaked for better migration like upgrade of DAO/RDO to ADO to avoid data binding issues during migration, strong typing of variables, etc.

The approach proposes a 2 phase split for executing the project:
Phase-1: Understanding the existing project and migrating the code as much as possible
Phase-2: Doing the necessary architectural changes and migrating manually the remaining code that could not be migrated with the tool.

Phase-1:
The Phase-1 would consist of following 4 stages:
1. Understanding the application
2. Determining the changes needed along with any POCs
3. Modifying the application code to prepare it for migration
4. Using the upgrade wizard to migrate the application

The output of this phase would be the following:
1. Architecture re-design document explaining the architecture of the migrated application
2. Reworked UI Specifications
3. Dot net compatible source code, 50% to 60%
4. Upgrade report generated by the upgrade wizard


Assuming that understanding the application and making the Architecture and UI specs could be done at a rate of 800 LOC per day, the phase would take 1500 man-days i.e. 75 man-months. A team of 10 people would take 7.5 months to complete this phase and the composition of team would be:
1. One Project Manager: for co-ordinating overall as well guiding technical decisions
2. One Architect: for creating the re-design document and actually migrating the code with the help of team members
3. Five team members of Analyst/Sr Developer capability
4. One UI lead and
5. Two UI members : for creating the UI specs.

Phase-2:
The outputs of the previous phase would feed into this phase. This phase would consist of the following stages:
1. Modifying code based on the architectural re-design
2. Migrating the remaining code base that could not be achieved via migration tools
3. Testing and defect fixing

Assuming that 500000 (approx 40%) lines of code would need to be modified and the end to end productivity is 100 lines of code per day (assuming on higher side as we have done One Phase), we get:
Number of man days = 500000 / 100 = 5000 man-days
Number of man months = 5000/ 20 = 250 man-months
Considering risk elements of 20%, we upgrade this value to 300 man months.

Conclusion: Thus we see that that total migration of the project would take about 375 man-months i.e. 7500 man-days, giving a productivity of 160 LOC per person per day, which is a higher value compared to Industry standards of 70-80 LOC per person per day. But one has to consider that there is fair bit of automation using the available tools.(assumed to be 60%).

Just a couple of points more before i end:

1. Just as the cost of building a one storey is not the same as building a 100 storey, similarly the effort/cost too varies with the change in size. In software this is largely due to the increase in communication channels with the increase in team size.

2. Cone of Uncertainity: At the initial stages, according to Caper Jones, the estimate could vary from +4x to -.25x (assuming x is the exact estimate). This usually tapers down in later stages and is around 1.2x during designs stage. So either do not give an early commitment on estimate or be on your best if you have to do it.