One of the most important tasks for an upgrade project is planning how to implement and deliver the upgrade work in a way that accelerates project velocity to produce initial results that users can understand and test. This article describes an approach for using gmStudio to facilitate planning an incremental upgrade that delivers a large system in pieces – engaging users earlier and avoiding a "big bang" deployment at the end of the effort. Note: there are several ways to do this, but this approach assumes you want to move to production subsets of functional new code and phase out the old system incrementally.
Upgrade project scope may be described in terms of the legacy AS-IS and the desired TO-BE states of the system. Many teams begin with a simplistic requirement: "we want to upgrade from VB6 to .NET". OK... but the problems are in the details and the "VB6 to .NET" requirement must be unpacked and defined in detail.The AS-IS side of the scope can be revealed by static analysis on the legacy system code. The TO-BE scope requires analysis and decisions regarding options -- ROI, risk, etc. And even after you have pinned down your AS-IS and TO-BE, you must still answer the question of HOW: how will you do the work (schedule, staffing); how will you use gmStudio; how will you verify results; and how will you transition the new system to your users in production?
The question of transition can be particularly difficult. Large systems that have emerged over decades of development usually contain hundreds of forms and numerous complex operations done by dozens of different types of users. Most organizations are not comfortable with a "big bang" transition where the newly upgraded system replaces the legacy system in its entirety all at once. These organizations prefer an incremental transition that impacts one group of users at a time, often along functional/departmental lines. The order and nature of technical work needed to enable an incremental transition can be determined by the following steps:
1) functional scope definition: users identify functional parts of the system they use and how they use them (e.g., user stories)
2) functional scope prioritization: users set the desired order for transitioning functional parts of the system into production
3) technical scope analysis: for each functional part, and in the order desired, the technical team must identify the technical upgrade features needed to support the transition.
The functional view of a system is a black box: it describes what the system does but does not explain the technical platform services behind the scenes. However, system modernization is deliberately based on technical objectives. To determine technical scope from functional scope, one must look inside the box. Figuring out where in the box to look can be done using four features of gmStudio:
1) VB6 Instrumentation
2) Reference Reporting
3) Source GUI Scan Reporting
4) Source Scan Reporting
VB6 Instrumentation is the process of adding logic to a VB6 application such that running the application reveals information about what is happening behind the scenes. Properly instrumented code can be used in two ways:
This process will modify each VBP by adding a reference to a module called containing the settings and functions for logging services.
The process will also modify every VB6 code file referenced by each VBP adding trace logging calls to the subs and functions. Note,
properties are not instrumented, but this could be added by modifying
gmStudio includes a facility for instrumenting a VB6 system. Two files are used:
instrument.gmsl: a gmSL script that contains logic for instrumenting VB6 code
instrument.xml:a gmPL script that specifies the set of VBPs referencing the VB6 code to instrument
The steps for using these scripts are as follows:
See instrument.xml in the sample rules folder for the latest notes on using these scripts
gmStudio generates .NET code from a detailed model of the source code and other inputs. This model is extremely detailed and may also be used to generate other outputs including the References Report. Each Reference Report record provides information on both the type of symbol referenced and also the location where the reference is made. Reference Reports only include references in logic code, not in GUI designer code. Reference Reports are tab-delimited files that can be very large. They may be loaded into a relational database system to facilitate analysis.
gmStudio can produce detailed reports of the GUI designer information in a VB6 code. Each GUI Scan Report record provides information on both the type of GUI designer property being set and also the location where the property is set. GUI Scan Reports are tab-delimited files that can be very large. They may be loaded into a relational database system to facilitate analysis. GUI Scan Records must be combined with Reference Report records to create a comprehensive body of reference data including both logic code and GUI designer code.
gmStudio can produce detailed reports of locations of patterns in a VB6 code. The default set of patterns used with this report can be used to identify the locations of potential language incompatibilities in the VB6 code. Each Code Scan Report record provides information on both the type of pattern found and the location where the pattern is found. Code Scan Reports are tab-delimited files that can be very large. They may be loaded into a relational database system to facilitate analysis.\
The reports described above contain information for an entire VBP or set of VBPs. This is useful for identifying the overall AS-IS state of a legacy application. This overall AS-IS information is a critical factor in planning the upgrade project, but it does not lend itself to identifying subsets of work needed for each functional subset of the system. In order to get a subset of AS-IS state, we must use the
method list produced by the instrumented code and use it to filter the reports. The various reports filtered on the list of methods in the trace log, provides details on the COM, Win32, and potential language incompatibilities in the subset of source code executed in the functional test. The upgrade solution must address these issues in order to make the .NET code meet coding standards and ready for functional testing. Addressing the issues means doing things like replacing COM/Win32 APIs with .NET APIs, reworking language incompatabilities and making other structural changes and optimizations.
Assuming the reports have been loaded into a relational database, the
method list may be used as shown in the following query:
The analysis work described above allows the Upgrade Team to break upgrade planning into more manageable, understandable pieces. It can provide AS-IS context to help the team focus and prioritize the TO-BE and HOW decisions required to estimate the project. AS-IS, TO-BE, and HOW decisions impact the cost, risk and effort of the project. Estimating the full effort may still be difficult for several reasons. For example, the first increment in an incremental transition requires more behind the scenes technical, procedural, and business decisions. It is a good idea to limit the functionality of the first increment to allow getting all of this worked out. Also, beware that not all increments of a legacy system are equal: some increments will bring new types of technical upgrade challenges while others will be technically the same as those already completed. And, since the increments are, by definition, different in terms of functionality, testing procedures and effort can vary significantly. Also, one should expect project efficiency to increase as the Upgrade Solution and the Upgrade Team mature. The bottom line is this: accurate project estimation requires synthesis of many difficult-to-quantify variables. The approach here will help provide some scale and organize that work but you must still account for the details of your specific requirements and organization.