gmStudio was initially created to help us deliver large-scale custom migration services to our clients. Early in our discussions with these clients, we were always asked two questions:
Unfortunately, most teams do not have a useful notion of how big or "complex" their systems are, let alone what they want their systems to become as a result of the migration. The requirements were typically little more than this:
Given the lack of clear requirements, we had our work cut out for us to come up with accurate cost and time estimates. We leveraged our toolset to help us gather information on the source system -- the idea being that if we can build a sufficient knowledgebase of what the system is in VB6/ASP, then we can use it as a framework for planning the work to reproduce the system in .NET. Our assessment process and reporting tools were the results of this experience.
You cannot know how far you have to travel until you know where you are starting from and decide where you are going. Beware that assessment work alone does not tell you how to solve your problems, it only helps you understand them better. You must still develop an understanding of what the new platform has to offer -- both the good and the bad -- and agree on which designs will work well for your application. You will have to do this design work no matter if you plan to use tools or start from scratch. The source code assessment helps you know what you are getting into. Using tools helps you implement and experiment with new designs in a more systematic and efficient fashion.
Simple Estimation Model
Creating Estimates from metrics looks simple enough:
R = X * Y where: X = number of "units" of a given type to be migrated (applications, components, forms, methods, lines of code, etc.) Y = cost for migrating a unit of X (amount of resources needed to complete one unit of migration)
R = total resources needed to do the migration of all units of X
For example: if your your application has 100 forms and you decide that each form will take an average of 20 hours to migrate then you will need 2000 hours to migrat the application.
Clearly, this approach is too simplistic. You will want to account for a few other factors to boost your accuracy:
So, no matter what, it is very likely that your initial estimates will be very rough and depending on your style they will have some degree of error. You will certainly want to refine the numbers as you progress.
Fortunately, gmStudio can produce a collection of extremely detailed reports and help you do other types of adhoc analysis. These data can help you map out a set of finite migration tasks that can each be assigned a reasonable work estimate.
We usually estimate a project in up to four Phases.
|1||The First Phase is a Standard Upgrade: providing .NET code that Builds in .NET and meets a few other general, objective measures of completeness and quality. The first phase will be a "direct translation" leveraging simpler, out-of-the-box capabilities. Given a well-formed, complete source codebase, a skilled gmStudio user can completed a Standard Upgrade fairly easily.|
The Second Phase is the Custom Upgrade: providing code that contains specific upgrade features, but still objectively measurable technical code quality. Upgrade features are of four types:
Delivering each Custom Upgrade feature requires definition, analysis, design, implementation and verification with a corresponding effort. Upon completing the Second Phase you will have a .NET code that is ready for final optimization and integration testing.
|3||The Third Phase of the methodology is an Optimized and Verified Upgrade: providing an integrated runnable .NET code meeting the specific functional (correctness, performance) requirements that are in scope.|
|4||The final phase is Transition: providing .NET code that is running in production and being efficiently maintained on the .NET platform. The emphasis on the translation tool is very strong in the beginning phases and shifts to an emphasis on testing and manual maintenance processes in the later phases.|
A final word of caution on estimation. There are many factors beyond the size and complexity of the source code that can have a very large impact on time and cost. These other factors are often dynamic and very difficult to quantify. In practice most teams must manage these factors carefully to keep the pace and cost of the project within expectations.