Size Based Estimation For Legacy Applications

Gerald Varghese / Venkatachalam Narayana Iyer

TABLE OF CONTENTS

ABSTRACT .................................................................................................... 2
INTRODUCTION............................................................................................ 3
SOFTWARE ESTIMATION - AN OVERVIEW ............................................................................................... 3
INDUSTRY FOLLOWED ESTIMATION MECHANISMS .................................................................................. 3
Analogy Estimation............................................................................................................................ 3
Parametric Estimation....................................................................................................................... 3
Bottom Up ......................................................................................................................................... 4
Expert Judgment................................................................................................................................ 4
PREDICTION MODELS ............................................................................................................................. 5
DATA COLLECTION ................................................................................................................................ 5
LEGACY SYSTEMS ................................................................................................................................. 6
ESTIMATION MODELS BASED ON PROJECT CLASSIFICATION ..................................................................... 6
Development Projects ........................................................................................................................ 6
Maintenance...................................................................................................................................... 8
Testing Projects................................................................................................................................. 9
SNAPSHOT ON USEFUL TOOLS ............................................................................................................... 10
Microsoft Excel for statistical data analysis and prediction .............................................................. 10
Minitab............................................................................................................................................ 10
CONCLUSION.............................................................................................. 11
REFERENCE ................................................................................................ 11

Page 1 of 11

Abstract
This paper is meant to give an overview of the different size based estimation mechanisms,
which could be most suited for legacy applications. This paper will touch up on the different
industry known estimation mechanisms, with focused details on Analogy and Parametric
models of estimation. The project experiences from development, maintenance & bug fixing
kind of projects for the legacy applications have been considered while preparing this paper.
The estimation practices that gave the best results for legacy applications have been analyzed
and implemented. The paper describes the practical methodologies, which have been piloted
in the various projects that have been executed in our organization. The paper will talk about
the different situations/projects best suited for each of the types of estimation. Statistical
methodologies of linear, quadratic and cubic models, which can be used for estimation, will be
detailed. Statistical features of Microsoft Excel and other statistical analysis tools like MiniTab
will also be discussed. An insight to predictive management will also be covered. Predictive
management will discuss about predicting the remaining time, mid way through the project
execution period. Practicing the modus operandi mentioned in the paper helps in interactions
with the different stakeholders in a more professional and robust manner, as the entire
communication will be based on quantitative data.
The paper shares the estimation
experience gained from executing legacy projects and supports the readers with some of the
best practices to be adopted for estimation in legacy projects.
Keywords:
Estimation, Legacy applications, Analogy, Parametric model, Predictive, Statistical Analysis

Page 2 of 11

Introduction
Software Estimation - An Overview
During the initiation of any software project, one of the key challenges faced by project
managers is with respect to estimating the effort required for execution of the project.
Especially in this highly competitive world of Software market, the ability to come up with an
accurate estimate for the project is one of the most desired competencies from any project
manager.
One of the major inputs for the project manager in deciding the estimated effort is the SIZE of
the work product coming out of the project. The accuracy in the projects effort estimate will
depend on how accurately the size of the deliverables is estimated. One of the contributing
factors for failure of software projects is that many projects get estimated based on the
personal working methods/experience of the project managers. There is lot of information
available in the knowledge base industry on estimating the projects. A few of the industry
standard practices and estimation mechanisms are listed hereby.

Industry Followed Estimation Mechanisms

During the project planning phase, once the list of activities is identified, the next step is to
estimate the duration required for each activity. This paper focuses on this part of project
management process. Different project managers follow different methodologies/process for
this, which includes

Analogy Estimation

Parametric Estimation
o Function Point (FP) Based
o Lines Of Code (LOC) Based

Bottom Up

Expert Judgment

Analogy Estimation
This methodology is based on the gut feelings (or unaided intuition) of the person who is
doing the estimation process with/without some unclear data from older projects. At the
project level, a number is judiciously arrived at and distributed across all the activities
involved in the project. The project is compared in complexity with another completed project
that may be of the similar type. The basis of estimation is to characterize the project for which
the estimate is to be made and then to use this characterization to find other similar projects
that have already been completed. The effort estimation is then done based on the known
effort values for these completed projects. A previous experience in a similar assignment could
be an added advantage and could help contribute towards the accuracy of the estimate, but in
a subjective manner. Documented historic data as such, will not be used much while
estimating using this mechanism. It is the most commonly used estimation strategy for effort
based software development/maintenance estimation. For estimation, one needs to determine
how best to characterize the project (define variables that might have to be measured on
different scales), determine similarity and relate projects for comparison and finally, how
much one should depend on the effort values from analogous projects for the estimation of
the new project.

Parametric Estimation
The key focus in this type of estimation is on identifying the parameters that contribute
towards the size required for the tasks in the project.
Function Point (FP) based:
Function point is a measure of the size of the software application measured from a functional
or user point of view. It is independent of computer language, but depends on development
methodology, technology and capability of the project team used to develop the application.
Function point tends to be useful in data oriented application. It is not restricted to estimation
of code alone. FP could be used for all class of software, any combination of languages, quality

Page 3 of 11

and productivity. It also gives a value added analysis and opportunities for software contracts
and discussion with clients.
FP required for the project might not be calculated accurately until the requirement analysis is
completed. (Software Requirement Specifications are baselined). Estimation method based on
function points is derived from different metrics. The approach is to identify the number of
unique function types as external inputs, external outputs, queries, external files or interfaces
and internal files. Each of these are then individually assessed for complexity and given a
weight-age value that might vary from 3 to 15. Unadjusted Function Point (UPF) is calculated
as the sum of the product of each function type with its weighting value. Then adjusted FP is
calculated as the product of UFP and technical complexity factor (TCF). TCF is the sum of the
entire complexity factor based on their degree of influence on the system measured
(Environmental Factor).
The factor, Function Point being an imaginary unit, would never end up in an all time perfect
estimation solution. It always depends on the definition attached to it and hence is hard to
automate and difficult to compute. The weight-age given to the function types is subjective
and do not fit on real time systems. The International Function Point Users Group (IFPUG)
manages, regulates and issues updates to these standards, making function points fully
documentable and traceable.
Lines Of Code (LOC) based:
LOC based estimation is typically related with effort. It is easy to determine, automate and
enforce. The LOC is counted excluding the comments and code created by application
generators. Simple to measure estimation method and is more familiar and understandable
but is less accurate than FP.
Stating the size of an application in LOC would not be a good measure for understanding any
system. The basic assumption is that all lines would be of the same complexity. It is language
dependent and may not be easily understood, as there is no way to express the difference
between complexity and functionality! Especially for projects where a piece of application is
getting modified, it is easier to measure the size of project using impacted lines of code rather
than FP.

Bottom Up
Detailed activity list needs to be known beforehand. The components identified are estimated
by the responsible person. Then the individual estimates are summed to get the overall cost of
the project. Consumes lot of time to estimate based on the components. Components level
requirements needs to be known, which may not be applicable for a maintenance task. It
requires the same kind of estimation to be performed on the different components by the
responsible person. This method introduces a very high risk, as there is no system level focus
during the estimation. This kind of estimation is costly.

Expert Judgment
This method is also known as Delphi technique for software estimation. Estimated effort is
just the decision made by a group of expert heads during the estimation. It is mostly practiced
when no historical data is available, but people experienced in similar work are. Expert
judgment could also be supported by historical data, process guidelines and checklists. But
purely depends on the persons involved in estimation, their personal characteristics and past
experience. Judgment is based on the observable requirements that are uninfluenced by
emotions or personal prejudices. The whole process of estimation could be a group discussion
among the experts that ends with an estimated effort that convinces everyone. The
effectiveness of the estimation is solely based on the skill of the people and their role in the
process of estimation. The variables for this combination strategy with combined estimate
would depend upon Number of Experts, the individuals estimation accuracy, the degree of
biases among the experts, inter-correlation between the experts estimates. Expert judgment
could be more accurate than most of the practiced estimation methods when environment
changes are not considered and the estimation need to be done on a simple system.

Page 4 of 11

Prediction Models
Most organizations in this industry have various types of processes to collect and document
the different project data. This data effectively becomes the historical data when estimating
future projects. During the estimation phase, different techniques have to be looked into for
doing proper predictions. Prediction basically is done using statistical data analysis and other
statistical extrapolation techniques.
Statistical extrapolation is typically done by plotting the different data points in a graph and
connecting the data points using one or other form of mathematical curves/equations. The
curves/equations could be first-degree (alias Linear curves), second-degree (alias Quadratic
curves) or even third-degree (alias Cubic curves). The curves plotted are extended for
futuristic predictions. The unknown co-ordinates for any known parameter can be found out
using the curve that is plotted. The process mentioned here is termed as Defining the
prediction model. The linear curve plotted adopts first-degree prediction model, the quadratic
curve adopts second-degree prediction model and like wise. The higher the degree of the
prediction model, the higher the accuracy of the prediction as well. These prediction models
are used in parametric based estimation.
In the subsequent sections of the paper, focus will be given to the different types of prediction
models in detail. The focus will be on a step-by-step approach, which helps in the size based
estimation of different types of projects. One of the success factors contributing towards the
accuracy in the prediction models is the DATA that goes into defining the prediction model.

Data Collection
During the execution of any project, there needs to be focused thoughts on what data needs
to be collected. The data collected needs to be detailed to an extent that it could be used for
similar projects. Again, the detail to which data collected should not be an overhead to the
project execution team as well. The project execution management needs to identify optimum
mechanisms for performing the data collection procedures.
A lot of thought needs to be applied on what all data needs to be collected. From a future
project estimation perspective, the size of the application developed and the effort taken for
completing the application, mandatorily needs to be captured and has to go to the
organizations historical database. Again, the effort captured needs to be categorized based
on the different phases of the project, if applicable.
If the project involves a lot of repeated and similar set of activities, the activities needs to be
categorized and data collected at the least component level to facilitate future decision
making. Considering a project involving similar changes to 1000 programs, the programs
needs to be classified into various categories like simple program, programs with average
complexity and highly complex programs or so. The categorization may be based on the
predefined set of attributes related to the program like total lines of code, number of database
operations, number of screen/report interfaces etc. The effort required and the size for each
program needs to be collected and documented. After collecting data for, say first 100
programs, the collected data can be analyzed for making valuable decisions regarding the
remaining 900 programs including expected effort required for completing the remaining 900
programs. This example will be detailed to the next level in the Maintenance projects
section.
A typical problem, a few organizations in this industry face is collecting the required and
accurate data. The performing teams needs to be oriented towards the importance of
collecting data in an accurate manner. The team needs to be appraised on how the data
collected is going to benefit their organization in future projects. Once the team is aware of
how important the data collected is, how the data is going to be used etc., accurate data
collection process will automatically be part of the project execution system.

Page 5 of 11

Legacy Systems
During the evolution of computers, IBM had a lot of focus in Mainframes and AS400 systems.
Most of the early day computerization giants went for the then available options like
Mainframes and AS400. The systems were robust and were able to serve the business of the
corporate giants to a great extent. The systems running on these machines are pretty old,
running continuously for 20 to 30 years. Even during these days of technological revolutions,
there is some reluctance in completely converting the massive systems running on the legacy
systems to high end latest technologies. Though companies may not invest much into these
systems in developing new applications from scratch, there is lot of focus on maintaining
the existing systems. This includes some amount of enhancements to an extent. Lot of focus
is provided towards testing the enhanced systems as well to ensure the enhancements dont
impact the execution of their existing business processes.

Estimation models based on Project Classification

The projects has been basically classified here as

Development projects
Maintenance/Enhancement projects
Testing Projects

Development Projects
Typically in legacy systems, size of applications developed depends mainly on the number of
functionalities to be implanted in the application that is being developed. Each of these
applications can be drilled down to program level for better analysis and monitoring. Say in
Mainframe systems, the programs will be in COBOL and in AS400, the program will be in
RPG/RPGLE. These programs will be interfacing with maps/screens and reports. These
primarily are the mechanism of user inputs and outputs in legacy system.
With some amount of technical effort, project performing organizations can come up with
generalized templates for typical Inquiry/Update/Reporting programs. During the
development of new programs, these templates could be used for building up on them. These
acts as effective code re-use to an extent and save lot of productive time during project
execution. The size of new programs will primarily depend on the number of
inputs/outputs/interfaces, the program has. The project manager needs to identify the right
parameters in technical terms that contribute towards the size of the application. Say,
introduction of new screen will add 50 lines of code to the program. Again, the number of
fields in the screen does matter. The detail to which the requirements are available will help
in coming up with an accurate estimate of the size of the application.
Once certain number of programs is developed, their data needs to be collected and
consolidated for further analysis. The data analysis will be oriented towards identifying the
extent of correlation identified parameters has with respect to the size of the programs. So,
the first step in data analysis is identifying the individual parameter correlation to the size of
the program. This could be done by doing simple statistical analysis or by using some tools
which help in identifying correlation between two variables. A correlation of 0.7 and above is
considered excellent.
There will be some parameters with correlation value much less than 0.7. Inference should be
that, those parameters are not contributing significantly to the size of the program and could
be ignored during subsequent data collection/estimation. A different set of new parameters
could be added for further data analysis. An overall correlation considering all the parameters
together also needs to be calculated to check whether there is a high correlation. Overall
correlation will consider the impact on one parameter on another parameter as well. These
are the preliminary steps involved in defining the prediction model. An illustration is provided
on the subsequent page.

Page 6 of 11

Some organizations use Function Points (FP) for estimating development projects. The
illustration shown in Table 1 is a customized way of data collection and data analysis using
Lines Of Code to define the size of application. Organizations needs to put thoughts into
coming up with similar customized mechanisms which suits best, the type of projects
executed.
Once after identifying the factors which has good correlation, individually and together with
other parameters, the next step is to define the prediction model. As discussed earlier,
different types of curves (linear, quadratic or cubic) can be plotted for the data. With the
increase in degree of curve, the accuracy will increase, but will require more effort in coming
up with the prediction model. Judiciously, the prediction model has to be baselined and all
further estimation needs to be based on this prediction model. Special care needs to be taken
to ensure that the data used in defining the model is continuously appended with more real
time data as more programs are worked up on.
Illustration on data analysis and defining a prediction model
Table 1 documents the data of few programs in the form of a list of parameters contributing to
the size of application and the size of the programs measured in lines of code (LOC).
Table 1

Update files
count
0
1
0
0
0

Input files
count
1
2
2
10
4

Windows
count
1
1
0
1
1

Screen
count
1
2
1
2
1

Report
count
0
0
0
1
1

Algorithm
Complexity
1
2
1
1
2

Calculation
Complexity
1
1
1
1
2

LOC
792
1292
671
2430
1380

Individual correlations of each of the parameters with respect to LOC are listed in Table 2.
This is calculated using CORREL function in Excel, which is explained in the last section of this
document.
Table 2

0.178

0.560

0.661

0.198

0.896

0.885

0.818

Prediction model definition (Table 3) in this illustration is done using LINEST function (Gives
the equation of a straight line in Excel. LINEST is an array function, giving a set of tabular
values as the output. How to use this function is explained in the last section of the document.
Table 3

539.03
156.22
0.99
46.74
18245661.42

558.17
134.83
236.14
3.00
167291.49

912.85
420.99
#N/A
#N/A
#N/A

-41.69
102.20
#N/A
#N/A
#N/A

-91.19
128.71
#N/A
#N/A
#N/A

49.30
39.29
#N/A
#N/A
#N/A

12.47
63.59
#N/A
#N/A
#N/A

The first element in the third row gives the overall correlation value considering all the
parameters together. In this example, the value is 0.99, which shows excellent overall
correlation (though some of the individual correlation values are less than 0.7). The values in
the first row are the coefficient to be used while defining the prediction curve. Using the first
row values, the equation of the curve (to be used for predicting LOC) is derived as:
LOC = 539.03 * calculation complexity + 558.17 * algorithm complexity + 912.85 * printer
41.69 * screen 91.19 * windows + 49.3 * input files + 12.47 * update files + 161.81

Page 7 of 11

161.81
396.66
#N/A
#N/A
#N/A

Maintenance
Now let us consider the next type of project, the most common type of projects on legacy
systems. Even the maintenance work comes in different styles; it could be just Field
Expansion projects, Maintenance work similar to Y2K projects, File Replacement projects or
even Application Enhancements. In these types of projects, the amount of work involved in
the system can be typically measured by understanding how much part of the application is
impacted. At program level, this can be measured with Impacted Lines Of Code or ILOC.
In these types of projects, one significant factor to be considered is the impact percentage.
This is the ratio of the size of the application impacted to the total size of the application. This
is the ratio of total ILOC from all the impacted programs to the total LOC of all the impacted
programs.
Let us go back to the example of 1000 programs mentioned in the data collection section in
this document. Consider that similar activity is to be performed in 1000 programs. The
project team needs to collect the data for initial set of say 100 programs. Again, this could be
put into different categories like simple, average & complex programs. From each of these
programs, the ILOC, LOC and the effort required for modifications needs to be captured
considering the different categories. With this information, the different impact percentage for
these categories can be identified. Knowing the LOC of the remaining 900 programs classified
into the different categories, the impacted size of the remaining can be predicted. From the
data for the initial 100 programs, the productivity factor for each category is known and with
this information, the effort required for the remaining 900 programs can be predicted with a
lot of accuracy.
Illustration on estimation for maintenance projects
Table 4
Total ILOC Till Date
Total LOC till date
Total Hours till date
Impact % (Ratio of ILOC to LOC)

500
15000
250
3.33%

Assumed for 1st 100 pgms

Assumed for 1st 100 pgms
Assumed for 1st 100 pgms
= 500 * 100 / 15000

Total No: of Programs

Total No: of Programs completed

1000
100

Average LOC / Program

Expected LOC for remaining pgms

150.00
135000.00

= 15000 / 100
= (1000 100) * 150

Expected ILOC for remaining pgms

4500

= 135000 * 3.33%

Productivity (ILOC / Hr)

= 500 / 250

Time Required for completing the

remaining programs (Hrs)

2250

= 4500 / 2

The methodology explained in Table 4 is a simple prediction model; it could be enhanced by

having sub categories and performing the same process at the sub category level for more
accurate results. For example, out of the 1000 programs, 300 programs are classified as
simple, 400 programs classified as medium complexity and 300 programs are classified as
highly complex. In such a case, there will be different Impact % and productivity values
calculated for each of the categories. Ultimately, time required to complete simple, medium
and highly complex programs is calculated separately. Summing them will give the
information at project level.

Page 8 of 11

The mechanisms mentioned here are really helpful in effective communication with the
different stakeholders. The stakeholders could be clients, project sponsors, senior
management or any other affected party in the project. This process could be performed at
different stages in project for more quantitative control on the project. This gives a lot of
information on how the project is performing (in terms of completion), how much more/less
number of human resources is needed for the remaining phase of the project and many
similar areas. Communication using quantitative values will have a distinct effect compared to
subjective communications. This process when performed during the execution phase of the
project can be termed as re-estimation. The key factor to be remembered here is that
estimation/re-estimation is basically performed on the size parameter of the work involved.
Clients will get the assurance that they are charged for a defined size of work rather than in
vague terms. Such objective measurements give a lot of punch for all negotiations on the
projects with the clients and give a lot of confidence to the clients on the project performing
organization as well.

Testing Projects
Testing of any application has different phases. It includes understanding the business of the
system, creating unit, integration and system test scripts, creating test data, performing
testing, documenting the results etc. Out of this, there are some steps like test scripts
creation, testing etc. which are really dependent on the size of the application. During the
project performing periods, some of these steps are combined together for easy management.
For example, understanding the business and creating the test scripts could be clubbed
together. Similar is the case with creating test data, testing and documenting the test results.
So, data needs to be collected only at this group level for proper prediction based on the size
of application.
The size of a testing project is primarily decided by the number of test cases to be tested.
This again is dependent on the number of lines of code to be tested. If testing is performed
on a newly developed application, all the lines of code will have to be tested whereas in the
case of enhancements/maintenance projects, only the impacted lines of code needs to be
tested. In either case, the test scripts could be categorized as unit test scripts, integration
scripts and system test scripts.
The organization needs to collect and consolidate data on testing project also. Specifically
with respect to estimation, the historical data should consist of information on how many test
cases were created for how many lines of code or impacted code, along with the effort
required for creating the same. Similar data should be available for performing the testing
process also. Linear prediction model could be easily applied on this historical data for
predicting the projects estimate. Again, the estimation here is based on size of the work
involved like the number of test cases created and executed. Effectively, using the prediction
models, the effort required for creating and performing the different test cases can be
estimated in a very efficient and effective manner.
Summarizing the discussed points, the key steps to be performed for effective prediction,
Identify the parameters contributing to the size of applications
Identify the detail at which data will be (practically) collected accurately and analyzed
Statistically evaluate how much identified parameters contribute to the size
Define the prediction model based on correlating parameters
Apply the prediction model to predict future work
These methodologies hold good at both organization level and project level. Some
organizations do have dedicated group of people to perform these practices. In other cases,
the project managers could apply these practices for effective project management.

Page 9 of 11

Snapshot on useful tools

Microsoft Excel for statistical data analysis and prediction
Microsoft Excel comes with a lot of functions for performing statistical data analysis. It has
many built-in functions facilitating statistical analysis for finding beta distribution, covariance,
for forecasting using fisher transformation etc. An overview of the functions that would be
used for the prediction model is discussed here.
CORREL function usage:
CORREL function helps us calculate correlation coefficient of any two data sets. Correlation
indicates how one factor affects another. The parameters for the CORREL function are:
1. An array of known Xs (For e.g.: update files count or input files count values).
2. An array of known Ys (For e.g. the LOC values)
After having a table with a list of known Xs and Ys in excel, select any cell, click the Insert
menu and select Function option. Select CORREL function and select the array of cells
corresponding to the all Xs as the first parameter to the function and Ys as the second
parameter. Pressing OK will give the correlation between X and Y in the selected cell.
LINEST function usage:
To find the equation of the line (y=m1x1+m2x2++b) that fits the best for the data, LINEST
function is used. It calculates the coefficients for the equation for the line by using the least
squares method. The Y is the desired LOC and the Xs are the different parameter values
(Update files count, input files count etc) with m acting as weight-age value. The LINEST
function returns an array that describes the line (i.e. the linear curve)
The usage of LINEST function is bit different from the usage of CORREL function. The
parameters for LINEST function are
1. An array of known Ys (Known LOCs)
2. An array of all known parameters (X1s, X2s) (update file count, input files count etc.)
3. Logical value. Enter TRUE, to force the constant b to be non zero.
4. Logical value. Enter TRUE, to let the function return additional regression statistics.
In Excel, select 5 rows and that many columns as one more than the total parameters used.
Choose the LINEST function and select the array of cells corresponding to LOC (Ys) as the first
parameter, the array of cells corresponding to all Xs as the second parameter and TRUE for
the third and fourth parameter. Third parameter = True is needed when a constant in the
equation for the curve is preferred. Coefficients listed on the first row of the output are in the
reverse order of the parameters as mentioned in the equation related to illustration in Table 3.

Minitab
Minitab is a pure statistical analysis tool introduced into the market by the MINITAB Inc. This
tool has lot of features which helps in doing basic statistical analysis, regression analysis,
analysis of variance, statistical process control, measurement system analysis, design of
experiments, reliability or survival analysis, multivariate analysis, time series and forecasting,
simulation and distribution and many more. (These are with reference to version 1.4 of
Minitab). For quantitative management at project level, knowing all the details in Minitab may
not be required, but few features like correlation analysis, probabilistic analysis etc are really
handy. If the organization has focused approach (with a dedicated team) on quantitative data
management at organizational level, the expertise on these tools could add a lot of value in
effectively managing the data that is collected and consolidated. Such an organization will be
able to present itself to the market with more predictive power and will always have a specific
competitive edge over its competitors.

Page 10 of 11

Conclusion
The different estimation mechanisms currently in practice in the software industry are
discussed with pros and cons for each. The significance of Prediction Model is briefed with the
highlight on the importance of accurate data collection and analysis. The role, precise data
from projects, play for statistical data analysis is emphasized. The paper has brought out
different size based estimation mechanisms for Development, Maintenance and Testing
projects that are most suited for legacy applications. An attempt has been made here to
prepare/help the project managers to face some of the key challenges faced during project
execution like project estimation, quantitative data analysis etc. in a better way. Prediction
model based on project classification helps having greater grip on the project by managing it
in a quantitative and predictive way. The methodologies explained (like Re-estimation) also
facilitate effective communication on the progress of the project to all stakeholders. Team
would predict whether they would be able to complete the project on time with the current set
of resources. A group competent to perform these practices at an organization level is really
an asset to the organization allowing it to stand apart in comparison with its competitors.
Prediction using the models is more accurate as the data used for defining the model has the
constraints consideration built-in. Usage of these models doesnt demand things like expert
opinion, there by making the model lot more scalable and effective to be used in all scenarios
for the current teams competency. The only requirement for this model is that it requires
good collection of data to embark on. This model makes effective management of a project in
legacy system at ease.

Reference
The contents in this document have been basically drafted from the experience gained while
working with different legacy projects. The knowledge acquired over long time has been
shared herewith. That is why a descriptive reference section is provided instead of any
specific reference points.

Page 11 of 11