Translation with SnowConvert
Edit, Debug & Deploy
Automated Test Case Generation
Metadata Analysis
Source Code Management
Migration and Other Snowflake Services
Get Up and Running with Snowpark
Using the SnowConvert Trial
Build a Cross-Platform Object Inventory
Translation with SnowConvert
Edit, Debug & Deploy
Automated Test Case Generation
Metadata Analysis
Source Code Management
Migration and Other Snowflake Services
Get Up and Running with Snowpark
Using the SnowConvert Trial
Build a Cross-Platform Object Inventory
A successful Visual Basic 6 to .NET upgrade project plan depends on careful analysis and assessment, that is, determining how best to upgrade your applications to the Microsoft .NET framework and how much it will cost to do this. The Visual Basic to .NET Upgrade Assessment Tool, developed by Mobilize.NET, gathers the required information to deliver a realistic cost and effort estimate for the VB to .NET upgrade, thus minimizing potential risks during the execution and increasing your return on investment. In Chapter 3, you will learn about this and other tools that will help you through the process, in order to obtain an accurate VB to .NET migration analysis and assessment.
Assessment and Analysis usually mean two things: determining how best to upgrade your applications to the Microsoft .NET Framework and how much it will cost to do this.
The main considerations for defining a migrations project scope are:
The following are some considerations that you should keep in mind during planning:
The first way to view the application is based on how it is used. In this case, you will have to look at the environment in which the application executes, who the users are and how they use the application, and what features the users actually use.
The second way to view the application is to analyze its content. This includes the features that it offers, the technologies that it uses to provide those features, the code that was written to manipulate the technologies, and the interactions between all these pieces.
Two techniques for doing this are: use case analysis and input/output analysis.
A very common technique for describing the requirements of software applications is through use cases. A use case is a document that describes one particular scenario where that system is or will be used.
A use case usually consists of text describing a set of steps that lead to the completion of a specific task.
A classic way to describe computer software is by means of cataloging the full set of data that it receives and the full set of data that it produces. This technique is a simple but effective way of creating a formal specification for the behavior and the usefulness of an application.
Inputs are anything that is entered into the application by an employee, a client, or a user of any other kind, or an external application.
The original application analysis is an essential part of an upgrade project. It provides a better understanding of the application to be upgraded and produces information necessary for planning and decision making.
After deciding the best way to upgrade your application, application analysis and assessment determine how much effort is actually needed to upgrade your applications to functionally-equivalent .NET applications.
The Visual Basic 6.0 Upgrade Assessment Tool, built by Mobilize.NET , works as a measuring instrument for an application upgrade effort. This tool analyzes the application components and the relationships between them from an upgrade perspective, which considers elements, constructs, and features that consume significant resources during an upgrade project.
The main goal of the assessment tool is to analyze Visual Basic 6.0 projects and obtain information useful for planning the upgrade to Visual Basic .NET and for estimating the cost of the upgrade.
The assessment tool can analyze the following types of Visual Basic 6.0 project types:
The first aspect to be considered in the application analysis is the inventory of resources and components involved in the upgrade process, which includes modules, third-party components, and intrinsic components.
Some of these components are user-defined, and their implementation needs to be upgraded In addition to the source code that uses them.
Typically, the size of an application is defined in terms of the lines of code. Also, the application source code can be classified and counted according to the origin of the code; for example, the assessment tool is able to identify code lines related to visual component declarations, comments, blank lines, and user-written code.
The assessment tool helps to capture source code metrics by producing a report of the number of lines of code in a project.
Source code lines are classified by the assessment tool as a result of analyzing all the content of the application modules. Each line is parsed and classified to determine how many visual lines, code lines, and comment lines are written in the Visual Basic 6.0 projects processed. Visual lines are lines that were generated by Visual Studio.
The Upgrade Wizard, built by Mobilize.NET for Microsoft, upgrades some of the language constructs and intrinsic and third-party components. However, there are features that are not fully supported by the standard migration engine and require certain level of manual work to be converted to Visual Basic .NET. The Visual Basic Upgrade Companion, available from Mobilize.NET , supports many features that are not supported by the Upgrade Wizard.
When an application is upgraded, the unsupported features produce different types of errors in the target application. Compilation or run-time errors can be produced and user intervention will be required to fix them.
The assessment tool detects the unsupported features by analyzing the code and searching for code patterns that will produce upgrade issues after the application is migrated. The estimation worksheet has a Config-EWI tab where the cost and effort values associated with this issue can be reviewed and adjusted according to specific needs. The values that are inserted in this tab are derived from Mobilize.NET's experience in Visual Basic upgrade projects.
The assessment tool identifies the dependencies between the application components analyzing different aspects of the source code, including:
After the initial upgrade preparation steps are complete, it is possible that some of the application components are not yet available on the computer where the automated upgrade is going to take place.
Missing elements are identified according to the user defined modules and explicit references included in the analyzed projects.
When estimating effort, you need to include all the steps of the upgrade from the initial analysis of the requirements up to the deployment of the application and retraining of developers and users if necessary.
After you have an estimate of effort, you have the most important piece to estimate the cost of the upgrade. However, the cost of the upgrade also depends on other elements. One such element is the cost of the people that do the work. Different parts of the upgrade require people with different profiles. Project administrators, developers, testers, and architects all cost different amounts of money.
Other things to keep in mind are training, hardware, software licenses, and any interruptions to your business or the cost of avoiding those interruptions when you switch to the new version of your application.
The effort estimation reports (Effort – Total, Effort – By Task, Effort – By Resource Type, and Effort – EWIs) generated by the assessment tool provide configurable parameters that help fine-tune a calculation of the effort and time required to complete the upgrade of a project. This report is created along with all the application’s technology details.
It is important to understand the concept of effort in the upgrade context. The effort of each task is expressed in hours that correspond to normalized time, that is, it corresponds with the time that the task would take if it was executed using average resources. If there is a highly experienced programmer in charge of that task, it will be finished in less time. In addition to average resources provided by default, the Effort Estimation report includes parameters such as junior developer, junior tester, senior developer, and senior tester; each with a different cost per hour.
The different phases to be estimated relate directly to the steps of the upgrade procedure. In summary, the items to be estimated are:
The inventory of the application is the first aspect to be considered when estimating the upgrade effort. This inventory will provide a general vision of the projects and modules to be upgraded.
A complete summary of the effort and cost estimations can be found on the Effort–Total worksheet in the Microsoft Excel workbook that is generated by the assessment tool. The estimates are based on projects that are as close as possible to typical. The formulas and weights are based on Mobilize.NET's vast experience with real upgrade projects and accurately reflect that experience.
The Effort – Total worksheet is divided into three sections, representing the phases of an upgrade project: “Application preparation”, “Application conversion”, and “Testing and debugging.”
In the context of the assessment tool’s estimations, the definition of application preparation is broadened to include everything from the moment that you are preparing the computers the upgrade will be performed on up to just before the upgrade wizard runs for the last time to generate the initial code that will be used as the source base for the new Visual Basic .NET application.
The application conversion phase includes all the tasks required to get the green code to functional equivalence: Upgrade Wizard execution, manual resolution of EWIs, code review (integration, compilation and debugging) and administrative tasks (e.g.: scheduling and resource assignment).
Green code is the name for the unmodified code generated by the upgrade wizard that serves as the initial code base for the upgrade.
This last phase includes all the quality assurance tasks that must be preformed to ensure that the application is functionally equivalent to the original application. All the tasks in this phase are calculated as percentages of the total effort in the Application Conversion phase. These tasks are: test case creation (to be used for quality assurance and to verify functional equivalence), test case execution, run-time error correction (bug fixes, workarounds, etc.) and administrative tasks (bug management, test case management, regression testing, etc.).
No, this is an estimate that you must fully review and customize before you use it in your own project estimations. Although almost every aspect of your application is covered somewhere in this workbook and each has an associated weight indicating the effort required to upgrade that particular aspect, the weights for some aspects are left at zero. This means that the assessment tool does not consider that all aspects are important to the estimation. The aspects that do have weights for effort and cost have values that may not be appropriate for your organization. Also, remember that every upgrade project is different, and although similar worksheets to this one have been used in real upgrade projects, there are always new things to consider or assumptions built into estimate worksheets that do not apply to every project. It is likely that you will have to make some adjustments before applying this estimation to your own projects.
For example, there’s a Resource Costs worksheet, which specifies how much it costs for different types of people to work on the upgrade project. These values change from country to country, from business to business, and even from month to month, so you will probably have to review them.
There are several tabs at the MainReport.xls file that is produced by the assessment tool that contain its configuration settings. The Config – General tab allows you to configure the estimated effort for specific upgrade issues, such as correcting and verifying every 1,000 lines of code. Resource costs can be found in the Config – By Resources tab. They represent an estimation of development resources required to resolve an upgrade issue. The Config – Fixed Tasks table introduces a set of processes to be accomplished in any upgrade project by the resources listed on the Config – By Resource tab. And finally, the Config – EWIs tab displays information about the upgrade estimates for EWIs.
9130 Jollyville Rd, Suite 175
Austin, TX 78759
Call us: +(425) 609-8458
info@wearegap.com
