Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Assessment and Estimation

gmStudio was initially created to help us deliver large-scale custom migration services to our clients. Early in our discussions with these clients, we were always asked two questions:

  • What is this going to cost? 
     
  • How long is this going to take?

Unfortunately, most teams do not have a useful notion of how big or "complex" their systems are, let alone what they wanted their systems to become as a result of the migration. The requirements were typically little more than this:

  • Our legacy codebase is not well documented, but we have been adding functionality to it for a long time and it is "big"; 
     
  • Our objective is to have a .NET application that does the same things as our legacy application.

Given the lack of good data, We had our work cut out for us to come up with accurate cost and time estimates. We leveraged our toolset to help us gather information on the source system -- the idea being that if we can build a sufficient knowledge base of what the system is in VB6/ASP, then we can use it as a framework for planning the work to reproduce it in .NET. The assessment process and tools described here were the results of this experience.

Some Thoughts on Estimation

Creating Estimates from metrics looks simple enough:

 

   R = X * Y

where:

   R = total amount of resources needed to "do the migration"

   X = number of "units" to be migrated (applications, components,
       fields, lines of code, etc.)

   Y = per unit cost (amount of resources needed to complete one
       unit of migration)

But take care, this is model is too simplistic. You will want to account for a few other factors to boost your accuracy:

  • First, the numbers for X generated from a thorough, systematic inventory of your codebase will probably be much bigger than you think. 
     
  • Second, Whether X is lines of code, forms, systems classes, whatever -- they are not going to require the same effort. 
     
  • Third, even if you set out to different effort levels based on complexity, there will be serious unknowns to contend with and the effort per unit will also decrease as you gain experience. This is particularly true with our methodology, which is specifically designed to be both improvable and repeatable.

No matter what, it is very likely that your initial estimtes will be very rough and depending on your style they may be very high or very low. You will certainly want to refine the numbers as you progress.

Fortunately, gmStudio can produce a collection of extremely detailed reports and do other types of analysis. These data can help you map out a set of finite migration tasks that can each be assigned a reasonable work estimate.

A final word of caution on estimation. There are many factors beyond size and complexity of the code conversion that drive the cost of a migration effort. Keep these in mind as you compute your estimates:

  • Increasing efficiency as the automated migration process is refined 
     
  • Increasing efficiency as the team climbs the .NET learning curve 
     
  • Scope and frequency of delivery cycles you will make or have to work around during the course of the migration effort 
     
  • Quality and volatility of the source codebase entering each cycle 
     
  • Development process and working environment efficiency (e.g., onsite, offsite) 
     
  • Ability to do testing, especially runtime testing in later stages of the methodology 
     
  • Consistency, depth and completeness of technical requirements for each cycle 
     
  • Size and skills of the migration team and their cost of their labor 
     
  • Amount of synergy between the migration and other work in progress

The Role of Design 

 

You cannot know how far you have to travel until you know where you are starting from and decide where you are going.Beware that assessment work alone does not tell you how to solve your problems, it only helps you understand them better. You must still develop an understanding of what the new platform has to offer -- both the good and the bad -- and agree on which designs will work well with that platform. You will have to do this design work no matter if you plan to use tools or start from scratch. The source code assessment helps you know what you are getting into. Using tools helps you implement and experiment with new designs in a more systematic and efficient fashion. 
 

 Reporting Overview

gmStudio can produce a variety of useful reports to help you plan, execute, and measure the progress of your migration effort. There are four classes of reports:

  • Code Scan Reports 
     
  • Project Information Reports 
     
  • Semantic Model Reports 
     
  • Utility Reports

The gmStudio report titles and output file names are listed below:

 

TitleOutput File
Code Scan Reports
Source Structure[MigName]-SrcStruct.tab
Source References[MigName]-SrcRef.tab
Source Members[MigName]-SrcMember.tab
Source GUI Scan[MigName]-SrcGUI.tab
Source Code Scan[MigName]-SrcScan.tab
Iceberg[MigName]-Iceberg.tab
Project Reports
Project Summary[MigName]-MigStat.txt
Metrics Summary[MigName]-Metrics.htm
Migration Set[MigName]-MigSet.tab
Code Bundles[MigName]-Bundle.tab
.NET Build Logs[MigName]-BldLog.tab
Translation Logs[MigName]-TranLog.tab
All Logs[MigName]-AllLog.txt
Interface File Headers[MigName]-LibHeaders.tab
Interface File ProgIds[MigName]-LibProgIds.tab
Semantic Model Reports
Semantic References[MigName]-AnaRef.tab
Semantic Definitions[MigName]-AnaDef.tab
Semantic Symbols[MigName]-AnaSym.tab
Semantic Audit[MigName]-Audit.txt
Utility Reports
Migration Project ListgmProjects.tab
Multi-Unit Scripttran.[MigName]_MultiJob.xml
Target Code Scan[MigName]-BndScan.tab

 

 

Most reports are driven off selected tasks in the Migration Project. You indicate which migration tasks to include in a report by selecting them in the migration panel.

Most reports are authored as tab-delimited text files with the first record containing the column names of the report. These reports are written to files with a .tab extension. A handful of reports aggregate various log files and other data as free-form text files. These reports are written to files with a .txt extension.

Most reports are written to the report folder in your migration workspace. 

 Running Reports

There are three ways to run gmStudio reports:

  1. To run a single report for a set of one of more migration tasks, highlight the desired tasks in the migration panel then select the desired report from the [Reports] menu. The report will only include data for the highlighted migration tasks. The resulting report will be displayed in the associated application (e.g., excel for .tab files, or a text editor for .txt files).
     
  2. To run a set of reports in batch, use the Reports Panel. This Panel allows you to perform a variety of reporting-related operations such as selecting a set of reports and running them in batch or viewing all the report files in the report folder. Click the [Reports] tab on the task details panel at the bottom of the main form.
     
  3. To run a set of reports from one or more migration projects in batch use the command line scripts supplied with the gmStudio Samples. See [INSTALLDIR]\samples\batch\run1set.cmd for details.


 

 .NET Assessment Tools

Once you have your code into .NET, Visual Studio offers several useful reports. See Code Analysis and Code Metrics in the Visual Studio documentation.

 

Key Point:
.NET Code Review
Note that the Build Log report will tabulate code analysis results if they are in the MSBuild log. This can be a convenient way to run an automated code review of your new .NET codebase. See MSDN for additional details on using MSBuild for code reviews.

 

 

  • No labels