Verification

Quality: Clean, Correct And Conforming to Standards

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:

Correctness: the target code produces the expected behaviors and results.
Conformance: the target code conforms to your organization's development standards.

Types of Testing

Based on the two dimensions of quality, we build quality into every phase of our methodology using the following types of testing:

Preparation Testing: Verifying that the source codebase is well-formed and internally consistent and that it is the correct version to be migrated. Problems may include missing or incorrect VB6/ASP code, Missing #include files, and missing or incorrectly installed COM components.
Translation Testing: Verifying that there are no errors or unexpected warnings or other messages reported during the translation process and that well-formed target code bundles are produced.
Build Testing: Verifying that there are no errors or unexpected warnings reported during the .NET build process and that well-formed .NET assemblies are produced.
Technical Testing: Verifying that the generated code conforms to your .NET development standards and thus meets your requirements for technical quality. .NET development standards may govern matters of coding style, third-party component use, configuration management procedures, security, performance, and scalability -- just to name a few.
Functional Testing: Verifying that the target application runs correctly -- in terms of matching original application behavior.

The Quality Index

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:

Quality Index	Description
Level 0	Preparation-Complete: The migration environment is available and contains a complete, consistent copy of the source codebase. You are ready to begin running standard translations.
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.
Level 4	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.