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:
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:
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:
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:
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.
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:
The gmStudio report titles and output file names are listed below:
|Code Scan Reports|
|Source GUI Scan||[MigName]-SrcGUI.tab|
|Source Code Scan||[MigName]-SrcScan.tab|
|.NET Build Logs||[MigName]-BldLog.tab|
|Interface File Headers||[MigName]-LibHeaders.tab|
|Interface File ProgIds||[MigName]-LibProgIds.tab|
|Semantic Model Reports|
|Migration Project List||gmProjects.tab|
|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.
There are three ways to run gmStudio reports:
Once you have your code into .NET, Visual Studio offers several useful reports. See Code Analysis and Code Metrics in the Visual Studio documentation.
.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.|