This section describes how gmStudio helps measure the quality of a migration effort.
One of the most frequently asked questions regarding our approach is: "How good is the resulting code?". This is an extremely important question as it drives total cost of ownership of your .NET codebase after the migration effort. As important as this is, it can be difficult to answer because quality can be a slippery subject. Different teams, different applications, and different requirements lead to different definitions for what is "good" quality and, of course, the standard for quality changes over time. For example, we assume that at one point using VB6 for your mission-critical applications was an accepted standard, but now depending on VB6 is considered risky and is probably a clear violation of standards.
In order to facilitate a productive discussion about quality, we must frame it in terms of two objective measures:
Based on the two dimensions of quality, we build quality into every phase of our methodology using the following types of testing:
Another way we look at quality is in terms of a quality index or quality milestones. As we move through the tuning cycles of the migration effort, we produce code of increasing quality for the target platform. The five levels of code quality that we expect to achieve in our process are referred to as the code quality index:
Preparation-Complete: The migration environment is available and contains a complete, consistent copy of the source codebase.
|Level 1||Translation-Complete: All statements of the source code translate into target code statements and the resulting code meets generally accepted standards of well-formed syntax on the target platform. The resulting target projects are complete and well-formed and they load cleanly in the Visual Studio .NET IDE for further development. One of the first things you should check is the existence of "CallByName" calls in the generated code. CallByNames indicate that the types of some of the object/Variant variables could not be determined and the object.member references were not recognized. There are a number of techniques to help the tool with type inference (refactor/fixtype, registry-libname, registry-progid, refactor/callbyname).|
You are ready to begin a detailed assessment of the generated code and to develop a plan for your upgrade.
|Level 2||Build-Complete: All statements/constructs of the target code compile with no compiler errors. In addition, specialized project elements (e.g., Forms) are accessible through their specialized editors provided by the target development environment. Build Complete is an important milestone because it means you can begin to use contemporary .NET tools that work on compiled assemblies, not source code, and it also means that you can begin testing the application to identify and eliminate runtime defects.|
It is our intention to produce Build-Complete codes in a completely automated manner right out of the box. We feel this is a reasonable baseline level of functionality for a migration tool: if the source code builds with VB6/ASP/COM, the target code should build in .NET.
You are ready to begin implementing your re-egnineering rules.
|Level 3||Technical-Upgrade-Complete: The technical design of the target application fits the migration team's architecture and development standards on the target platform. |
You are ready to begin resolving runtime issues.
Functionally Correct: The target application yields correct results on the target platform. Congratulations!
The application is ready for Cut-Over and ultimately deployment to production and ongoing maintenance and enhancement on the .NET platform.