Assessment and Analysis
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.
What does Assessment and Analysis mean?
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.
When I’m defining the scope of my project, what are the main ideas I should take in to consideration?
The main considerations for defining a migrations project scope are:
- Identifying Components That Must Be Upgraded
- Identifying Obsolete Components
- Managing Upgrade Expectations
What do I have to know to create an effective project plan?
The following are some considerations that you should keep in mind during planning:
- Identifying Components Requiring Significant Upgrade Effort
- Quantifying the Amount of Code to Upgrade
- Determining Upgrade Order
- Assessing the Necessary Technical Expertise
- Estimating Time and Cost
- Defining Priorities
What are some of the common reasons that people have for upgrading from Visual Basic 6.0 to Visual Basic .NET?
- Minimizing Organizational Disruption
- Leveraging Existing Knowledge Capital
- Reducing Risk
- Maximizing Return on Investment
- Achieving Functional Equivalence
- Dealing with an End to Official Support for Visual Basic 6.0
What are some of the common technical objectives for performing an upgrade?
- Adding New Functionality
- Achieving Better Performance and Scalability
- Accelerating the Development Process
- Consolidating to a Single Framework
- Ease of Deployment
What is the best way for me to view and extract information about upgrading my application to Visual Basic .NET?
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.
What are two techniques used for assessing an application usage?
Two techniques for doing this are: use case analysis and input/output analysis.
What do you mean by Use Case 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.
What do you mean by Inputs/Outputs Analysis?
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.
Why is an Application Analysis so important?
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.
How does the Visual Basic 6.0 Upgrade Assessment Tool work?
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.
What is the Assessment Tool main goal?
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.
What types of Visual Basic 6.0 projects can the Assessment Tool analyze?
The assessment tool can analyze the following types of Visual Basic 6.0 project types:
- Standard EXE: Standard features and functionality are considered when making estimations that are based on average productivity values.
- Internet Information Services (IIS) application: The application is analyzed in the standard way.
- Application that uses distributed components: The usage of distributed functionality is identified and accumulated to estimate the upgrade cost of this feature.
What is the first aspect I need to consider in an application analysis?
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.
How are the Source Code Metrics defined?
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.
How can the assessment tool help me capture Source Code Metrics?
The assessment tool helps to capture source code metrics by producing a report of the number of lines of code in a project.
How are Source Code Lines classified by the assessment tool?
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.
What happens with the features that are not supported by the Upgrade Wizard?
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.
How can the Assessment Tool assist me regarding those unsupported features?
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.
What dependencies does the assessment tool identify?
The assessment tool identifies the dependencies between the application components analyzing different aspects of the source code, including:
- Application references: Explicit references to user components indicate that there is a dependence relationship between different user projects.
- Variable declarations: When a variable is declared using a type that is defined in a different module or project, a dependence relationship between different modules or projects is established.
- Member accesses: Member accesses also produce dependences between subroutines, functions, or properties.
Is it possible that I can encounter with some missing elements after the initial upgrade preparation?
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.
How are the missing elements identified?
Missing elements are identified according to the user defined modules and explicit references included in the analyzed projects.
What steps do I need to include when estimating effort?
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.
What are the main elements to determine the cost of the upgrade?
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.
How does the Assessment Tool shows the upgrade effort?
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.
What are the phases to be considered while estimating a project’s effort?
The different phases to be estimated relate directly to the steps of the upgrade procedure. In summary, the items to be estimated are:
- Project kickoff: This includes the estimated time for the upgrade project kick-off meeting. Typically, it is not a large value. It serves as a reminder that these cost estimates have a well-defined scope. It also reminds you of the many things that you must do before the upgrade project begins, such as training, research, and purchasing software and hardware, which are not included here.
- Application preparation: This includes the estimated time for the setup and verification of the development environment of the original application. This includes compilation of the original application to verify that it is complete and source code modifications to accelerate the conversion process later on.
- Application conversion: This includes the estimated time for the execution of the upgrade wizard and completing the upgrade with manual changes.
- Testing and debugging: This includes the estimated time for the execution of the original test cases and fixing any run-time errors.
- Project management: This includes the estimated time for administrative tasks related to scheduling and management.
- Configuration management: This includes the estimated time for configuration management of the products obtained throughout the entire upgrade process.
What is the first aspect to be considered when estimating the upgrade effort?
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.
How does the assessment tool presents the effort and cost estimates?
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.”
What is the Application Preparation phase?
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.
What tasks does the Application Conversion phase include?
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).
What is Green Code?
Green code is the name for the unmodified code generated by the upgrade wizard that serves as the initial code base for the upgrade.
What does the Testing and Debugging phase include?
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.).
Is the assessment tool’s estimate accurate for any project?
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.
How can the assessment tool be configured?
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.