Estimating the Costs of a Reengineering Project
Harry M. Sneed
Anecon GmbH, Vienna Austria
Institut für Wirtschaftsinformatik, University of Regensburg, Bavaria
Email: Harry.Sneed@T-Online.de
Abstract: Accurate estimation of project costs is an essential prerequisite to making a reengineering project. Existing systems are usually reengineered because it is cheaper to reengineer them than to redevelop or to replace them. However, to make this decision, management must know what the reengineering will cost. This contribution describes an eight step tool supported process for calculating the time and the costs required to reengineer an existing system. The process is derived from the author’s 20 year experience in estimating reengineering projects and has been validated by several real life field experiments in which it has been refined and calibrated.
Keywords: Reengineering, cost estimation, risk analysis, software measurement, gap analysis.
It has been 15 years since the first studies on the economics of software reengineering projects appeared and since then a great deal of research has been done and a wide range of practical experience gathered.[1] At that time, reengineering projects were being calculated on the basis of the size alone, without consideration of complexity and quality. In the meantime, we have learned a lot more about how the complexity and quality of the software effect reengineering costs. The topic of estimating the costs of a reengineering project has also become more important to decision makers in industry since they have other alternatives to choose from.
Reengineering is an alternative to redevelopment, to purchasing a standard package or to doing nothing at all. Therefore, management wants to know, what the return on investment is for each alternative.
Without having a cost estimation it is not possible to compute the ROI. So analysts are obliged to come up with a figure in a very short period of time with a minimum of effort. This paper presents a tool supported procedure for coming up with such an estimate.

1. The objectives of reengineering
To get started it is necessary to define the goals of a software reengineering project, since it is not clear to all exactly what reengineering means. There are basically three possible strategies to reengineer software. These are:

Proceedings of the 12th Working Conference on Reverse Engineering (WCRE’05)

1095-1350/05 $20.00 © 2005 IEEE

encapsulation, renovation and migration [2]

1.1 Encapsulation
In the case of encapsulation the goal is to reuse existing components in another environment.
Components of an existing system are wrapped and bound into a new system. There should be a minimum of change to the code, at most the interfaces have to be revised. No effort is made to improve the quality of the software. It is reused as it is. The change rate to the software must be well under 20%. Thus, the costs and the risks are minimal, but this applies to the benefits as well. [3]

1.2 Renovation
In the case of renovation the goal is to raise the quality and to reduce the complexity of an existing system. The software remains in its native environment, but maintenance costs should go down and the service to the user should improve.
After renovation it should be possible to process change requests in less time, to correct errors with less effort and to provide new releases in shorter intervals. All of this is possible, because the code and/or the architecture are in a better condition.
Restructuring and refactoring are techniques applied to attain this end. [4]
Software structures are simplified, redundant code removed, large classes broken up into many smaller ones and the interdependencies among modules reduced. Hard coded data can be taken out of the code and database accesses relocated to an access shell. In refactoring existing classes, the number of attributes and the size of the existing methods should be reduced. The goal here is to reduce complexity. These are only a few samples of what can be done to improve the quality of an existing system. In all cases the degree of change is significant. It can vary between 20 and 50%, depending upon how many program features are altered. The costs and risks go up accordingly. The more the code is altered, the greater the error probability. 1.3 Migration

3. Eight steps to a cost estimation

In the case of migration, the goal is to move the existing system as a whole from the one environment into another. More than often this entails a language conversion, for instance from
Assembler to COBOL or from COBOL to Java.
There may also be a database conversion, e.g. from a networked database to a relational one. This can be done with or without quality improvement measures. The greater the degree of change, i.e. the wider the gap between the old language and the new one, the higher are the costs and risks. This is particularly true in moving procedural programs to an object-oriented language. The whole framework has to be exchanged so that in the end only the elementary code blocks remain, e.g. the paragraphs in COBOL or the Do blocks in PL/I. They can be reused as methods in the new framework. Here between 50 and 100% of the code and data is affected. So this strategy has the greatest potential for higher benefits, but it also has the greatest risk of failure and demands the highest costs. [5]

In the method practiced by the author there are 8 steps to systematic cost estimation. These are:
1. Analysis of the reengineering requirements
2. Analysis of the existing system
3. Transformation of the source metrics
4. Computation of the adjusted system size
5. Definition of the quality goals
6. Calibration of the productivity data
7. Analysis of the risks and computation of the risk factor 8. Calculation of the effort and time required. (See
Fig. 1.)

2. Selecting a reengineering strategy
Before even starting an analysis of the costs and benefits of a reengineering project, it is absolutely necessary to first clear with the user which strategy he desires to pursue. The object of the analysis – the existing system – will be the same in all cases, but the costs, risks and benefits will vary tremendously depending on the reengineering strategy selected.
It may be that the responsible managers will ask for a comparative study of all three alternatives, in order to support their decision. It may also be that they are already sold on one particular strategy and that they only want a cost estimation for that. In any case, the goals of the reengineering project must be clear before estimation can be made.

Questionnaire

1
RE-Requirements
Analysis

Goals
2

Source
Code

Sourcecode
Analysis

Deficiencies,
Metrics,
Documents

Analysis results 3
Metric
transformation

Quality requirements 4

Quantity &
Complexity &
Quality

Compute adusted size

5
Define Quality &
Complexity
Goals

6
Calibrate
the
Productivity

7
Analyze
Risks

Calc-DB

3.1 Analysis of the reengineering requirements To collect the user requirements the author uses a questionnaire with three classes of reengineering requirements size requirements, complexity requirements and quality requirements.
The size requirements are an inventory of all the system components effected by the reengineering project. This includes among others number of source files number of online transactions number of batch processes number of database tables number of user and system interfaces number of workflow procedures, etc.
This inventory provides a basis for the following system analysis.
The complexity requirements are an assessment of the user of the complexity of the current system as opposed to that of the proposed system. For this, the user rates the complexity of the environment, the data structures, the system architecture, the code and the system interfaces on a nominative scale of for both the current and the desired software. The analyst can then make a gap analysis of the distance between the current complexity and the desired complexity. This will give a first impression of the degree to which the complexity should be reduced. The greater the gap, the higher the costs.[6]

8
Project effort in PMs
Calculation

Project time in CMs

Figure 1: Reengineering Estimation Process

Proceedings of the 12th Working Conference on Reverse Engineering (WCRE’05)

1095-1350/05 $20.00 © 2005 IEEE

The main goal of the questionnaire is to sound out what the user really wants. In reengineering for quality improvement this is particularly important, since quality means different things to different

people. The quality requirements are in effect the degree to which the quality of the software should be raised. The user is asked to rate the overall quality characteristics which can be effected by the reengineering. These include among others the performance, the usability, the maintainability, the reliability and the interoperability.
The user rates these quality characteristics taken from the ISO Standard 9126 on a similar nominative scale of for both the current and the desired software. [7] This again provides an opportunity to make a gap analysis of the difference between the degree to which the quality requirements are fulfilled by the current system and the degree to which they should be fulfilled. The greater the distance between the Ist and the Soll, the greater will be the reengineering effort.
The degree of quality requirement fulfillment is captured by a gap score (G) indicating the width of the gap between the current system and the reengineered system where G = Desired Score –
Current Score. The Score is obtained by assigning weights to the nominative ratings very high = 5 high = 4 medium = 3 low = 2 very low = 1 and summing them up. A negative result indicates that there is no need to renovate the software, a low result indicates there is no pressing need to renovate, a high result, i.e. a result greater than half of the total number of points, indicates an acute need to renovate the system. [8]
The combined gap score of the complexity and the quality differences together with the size of the target system in total software artifacts gives a first impression of how much the reengineering effort will cost. With this data one can make an analogy: with previous reengineering projects in order to obtain an upper and a lower bound for the costs.
In any case, it is absolutely necessary to obtain a consensus with the owners of a software system before embarking on a reengineering project. One of the main reasons for reengineering projects to fail is because of unclear or disputed goals. This justifies spending time to involve the owners, which is the primary purpose of the questionnaire. By responding to the questions, the users are forced to reflect upon want they want to achieve.

Proceedings of the 12th Working Conference on Reverse Engineering (WCRE’05)

1095-1350/05 $20.00 © 2005 IEEE

Source
Library

DB Schemas
Masks
JCL Procedures
Programs

unloading
Utility

Source
Members

Analysis
Parameter

Code
Checking
Rules

Source
Analyser

Measurement

Checking

QA

=

Deficiency
Report
Rule Violations

Software
Analysis

+

Measures

Metric
Report

SoftCalc

Quantity metrics
Complexity metrics
Quality metrics

Figure 2: Static Source Analysis

3.2 Analysis of the existing system
After analyzing the requirements, the user may decide that there is insufficient benefit to be gained or that the whole thing is simply too expensive. If, however, he decides to proceed, the next step is to analyze the software itself. This has to be done automatically within a few days otherwise it will be too expensive.
The tools for performing this task are static analyzers.[9] Since the user system will normally contain many languages – Assembler, COBOL,
PL/I, C++, Java, XML, SQL, BMS, HTML, etc. – there must be an analyzer for each language. The important thing is that the results of the analysis are the same. The analyzer should provide a report on all the deficiencies found in the code as well as a metric report on the counts of all the software features. The metric report contains also key complexity and quality metrics extracted from the code including coupling cohesion cyclomatic complexity class complexity modularity testability reusability maintainability portability Of particular interest to a migration project is the convertibility metric which is based on the proportion of 1:1, 1:m and m:m convertable statements. [10] From these metrics a median system complexity and a median system quality are derived. The size of the system is counted in different units of measure including lines of code statements data-points object-points function-points.
The SoftAnal tool used by the author has a common user interface and a generic framework for analyzing, checking and measuring all of the common programming languages from Assembler to Java and C#, as well as all of the common database schemas and both the data interface description languages and the user interface languages from CICS-BMS to HTML and XSL. It also processes most JCL languages. The important aspect of this tool is that all of the results are comparable and in a common format. (see Figure 2)
The key metrics of the target system are written out in an XML file which can then be exported to the cost estimation and risk analysis tools. Creating bridges between different tools performing different tasks is an essential part of the estimation process.
Both the metrics mentioned and the tools for obtaining them have all been described in previous papers over the past 20 years. [11]

3.3 Transformation of source metrics

0.552
0.515
0.640

Figure 3: Metric Export Data to SoftCalc
Behind SoftCalc is a metric database with three tables: a table of size metrics a table of complexity metrics a table of quality metrics. [12]
In each of the three tables there is a row for each source module, database table, user interface, system interface and workflow control procedure with a column for each metric. When new sources are analyzed new rows are added. When sources are reanalyzed, the existing rows are overwritten.
There is also a graphical user interface to the metric database which allows the user to view and, if necessary, to change the database contents. (see
Figure 4.) In addition, the user can assign weights from 0.5 to 2 to the individual complexity and quality metrics so as to influence their impact on the cost estimation.

In the third step the results of the source analysis are transferred to another tool – SoftCalc – for the purpose of making the final cost estimation. The metrics obtained from the source analysis are stored in an XML file. This file is read in by the SoftCalc tool and the metrics moved to a relational table.
This is done via an XSLT transformation. (see
Figure 3)

151
133
30

0.657
0.138
0.500
0.920
0.476
0.341
0.960
0.595
0.573

0.366
0.813
0.831
0.500
0.900
0.544

Proceedings of the 12th Working Conference on Reverse Engineering (WCRE’05)

1095-1350/05 $20.00 © 2005 IEEE

Figure 4: GUI to edit Database Contents

3.4 Computation of adjusted system size
The adjusted system size is the raw size in lines of code, statements, data-points, object-points and function-points multiplied by the complexity factor and the quality factor. The complexity factor (CF) is the average system complexity (SC) divided by the median complexity (MC). On a rational scale the average system complexity is a coefficient on a scale of 0 to 1 with a median complexity of 0.5. It is obtained by taking the average of the individual complexity metrics after they have been weighted by the analyst. For instance, coupling may be weighted by 1.5 and the cyclomatic complexity by
0.5, implying that the coupling metric will have

three times the weight of the cyclomatic complexity metric. In a case where the average system complexity is
0.65 the complexity factor will be

CF

SC
MC

0.65
1.3
0.5

The quality factor (QF) is the average system quality (SQ) divided into the median quality (MQ),
On a rational scale the median quality is a coefficient on a scale of 0 to 1, with 0.5 being the median quality. It is obtained by taking the average of the individual quality metrics after they have been weighted by the analyst. For instance, convertibility may be weighted by 2 and testability by 1, implying that convertibility has two times the weight of testability.
In a case where the average system quality is 0.45 the quality factor will be

QF

MQ
SQ

0.5
1.1
0.45

If the raw size of the system in statements is 50,000 statements, then the adjusted size will be

Size x CF x QF or
50,000 x 1.3 x 1.1 = 71,000 stmts
The same applies to the other size metrics – function-points, object-points, data-points, etc. In this way the complexity and the quality of the existing software has a significant, but bounded impact on the size of the reengineering task.
Dividing the median value of 0.5 by or into the actual value from 0.1 to 0.9 gives an adjustment factor of 0.55 to 1.8, meaning 45% less to 80% more effort. This bounding is based on the practical experience of the author in some 18 reengineering projects. [13] Both of the adjustments described above are, of course, done automatically by the
SoftCalc tool.
Quality Char.
Before After Increase
Modularity
0.50
0.60 +0.20
Testability
0.46
0.60 +0.33
Reusability
0.52
0.58 +0.11
Convertablity
0.60
0.52 0.17
Interoperability 0.52
0.52 +0.00
Maintainability 0.48
0.64 +0.33
Quality Increase
1
+0.80 = 1.8
Figure 5: Quality Increase Definition

Proceedings of the 12th Working Conference on Reverse Engineering (WCRE’05)

1095-1350/05 $20.00 © 2005 IEEE

3.5 Definition of quality goals
Having computed the adjusted size of the software to be reengineered, it is then the task of the analyst to set the quality goals and the influence factors.
For this purpose the SoftCalc tool has another two tables the table of desired quality features and the table of influence factors.
The table of desired quality features includes all of the quality features which are measurable in the source code – modularity, reusability, testability, convertibility, portability, maintainability, etc. Here it is up to the user to assign those quality ratings he would like for the reengineered system to have, for instance, a modularity of 0.75 and a reusability of
0.6. The tool will then compute the difference between the quality rating of each feature for the existing system and what assigned to each feature of the desired system. If the existing modularity is
0.55 and the desired modularity is 0.75 then the gap is 0.2. There may also be negative gaps when the desired quality is less than the actual quality.
In any case, the quality adjustment factor (QA) is the sum of the individual quality gaps plus 1. If the gap scores are 0.2 for modularity, 0.1 for reusability, 0.3 for testability, 0.3 for maintainability and -0.17 for convertability, than the quality adjustment factor will be 1.8, implying that an additional 80% of effort will be required to raise the quality of the system. The greater the gap between the quality of the existing system and that of the targeted system, the greater will be the effort to close that gap. [14]

3.6 Calibration of productivity data
The productivity data is derived either from the literature or from previous projects. Productivity is defined here as the relationship between adjusted system size and person days required to reengineer a system of that size. It is obtained by dividing the adjusted size by the number of days booked against the project. If it took 600 person days to reengineer, test and deliver a system containing 60,000 statements then the productivity is 100 statements per person-day. The same is applied to each of the size metrics. If the system with 60,000 statements were to have 3,000 function-points, then the productivity would be 5 function-points per day.
Systems should be categorized by size in: small systems 1,000,000 statements.

For each size category there will be an average productivity for systems of that size. [15]
The SoftCalc tool has a facility for importing the effort required to complete a project in person days from any time reporting system. Since SoftCalc also computes the adjusted sizes of the systems, it is easy for it to set up and update the productivity table which has a column for each size metric and a row for each size category.
Productivity can be influenced by specific project conditions such as the degree of tool support the amount of travel required the access to testing facilities the communication facilities the process maturity the working conditions, etc.
It is hard to predict their exact influence on the project, although most of the conventional estimation methods try to do just that. The
Function-Point Method has 14 influence factors
[16] and COCOMO-II has 20.[17] Function-Point rates them on a scale of 0-5. Cocomo rates them on a scale of 0.7 to 1.4. In Function-Point the sum of the influence factors is taken. In COCOMO the product is used. Selecting and predicting the impact of such influence factors on the costs of a project is probably the most difficult challenge of cost estimation. In SoftCalc a table is provided for the influence factors, but it is left to the user to identify which factors he wants to be considered and how they should be weighted. The weights are added together and divided by the average weight to obtain a project influence factor of 0.5 to 1.5 with 1 as a median. The productivity is then multiplied by that influence factor. In this way, a productivity of 100 statements per day could be increased to 150 by an influence factor of 1.5 and decreased to 50 by an influence factor of 0.5. It is the experience of the author that estimators must be very careful with the use of project influence factors. They are really only recommended when the current project radically differs from the previous ones. Otherwise, it is best to rely on the previous, unadjusted productivity rates. [18]

3.7 Analysis of risks and computation of the risk factor
All projects involve some degree of risk, however, the risks of a reengineering project are much less than those of a new development. The low risk and low costs of reengineering are the main reason for choosing this approach in the first place. Never the

Proceedings of the 12th Working Conference on Reverse Engineering (WCRE’05)

1095-1350/05 $20.00 © 2005 IEEE

less, there are some risks involved as pointed out by this author in a contribution to the WCRE-1999.
[19] Primary among these risks are loss of performance system incompability and lack of acceptance by the programming staff.
These risks can have a severe impact on both the costs and the duration of a project. Therefore, it is up to the analyst to consider and to weigh them.
The SoftCalc tool provides the analyst with a table for identifying and assessing project risks. There is a row for every potential risk with the following columns: risk identifier risk name risk probability (RP) risk impact (RI) risk reduction possibility (RR) risk factor (RF)
Risk Name
RP RI
RR
Performance
0.40 0.50 0.25
Acceptance
0.36 0.75 0.20
Compatability
0.24 0.60 0.20
Feasability
0.10 0.60 0.80
Total Risk
Figure 6: Risk Analysis Table

RF
1.15
1.22
1.12
1.01
1.57

The risk probability is the percentage of chance that the risk will occur, e.g. there may be a 40% chance that there will be a performance bottleneck in the new environment. The risk impact is the degree to which costs can be increased. If the risk materializes, it may vary from 1 to 100%. The risk reduction possibility is the degree to which the risk can be reduced by preventative measures. It may also vary from 1 to 100%, but it must, of course, be less than the risk impact, otherwise this is not a risk.
The risk factor (RF) is computed as follows, where
RP = risk probability, RI = risk impact and RR = risk reduction rate. If the risk of a performance bottleneck is 40%, the risk impact on the costs of the project is 50% and the possibility of reducing that risk is by 25% then the risk factor will be
RF =

1+ [ (RP x RI) x (1-RR) ]
1 + [ (0.4 x 0.5) x (1- 0.25) ] = 1.15

This is repeated for every individual risk. The overall risk adjustment factor (RA) is the product of the individual risk factors. If the performance risk is
1.15, the incompatibility risk 1.12 and the acceptance risk 1.22 then the risk adjustment factor will be 1.57, implying that the estimate should be increased by 57% to cover the potential risks identified. [20]

3.8 Calculation of the effort and time required In the final step the tool SoftCalc calculates the effort and the time required to make the project. To compute the effort required the adjusted system size
(AS) is first multiplied by the quality adjustment factor (QA). The result is then divided by the adjusted productivity factor (AP) to give the basic effort required. If risks are involved this basic effort will be adjusted by the risk adjustment factor (RA).
The final effort is:
Effort = [ (AS x QA) / AP ] x RA
In the case where the adjusted size is 71K statements, the quality adjustment 1.8, the adjusted productivity 200 statements per day and the risk adjustment factor 1.57 the effort will be 50.2 PMs.
Effort = [ (71.000 x 1.8) / 200 ] x 1.57 = 1003 person days or 50.2 person months
To obtain the time required, a modified COCOMO algorithm is used. [21] The standard COCOMO equation for computing the duration of a development product is
0.35

2.5 (person months)
Since reengineering allows a much greater degree of parallelism, the multiplier is changed to 1.5 to take account of this compression. Thus for reengineering projects the time is calculated as
0.35

1.5 (person months)
That means it will take

Effort in person months.......50.20
Computer time (hours).......6018.00
Total Costs..............€480000.00
___________________________________
Minimal project time ....5.9 Months
Optimal project staff....8.3 Person

Figure 7: Results of a SoftCalc Calculation

4. Illustration of the estimation method
To illustrate this method a case study was performed with PhD students at the University of
Szeged. The task was to reengineer the billing component of a stock brokerage application system written in C and to convert it to C++. In doing so it was intended to raise the quality by at least 25%.
The only risk involved was that of performance loss, but this had a high probability of 80% and a cost impact of at least 30%. The productivity of 12 object points per day was taken from a previous project. The static analysis of the code provided the following size metrics
11.318 lines of code
3.377 statements
121 function-points
1.198 data-points
1.132 object-points
The median complexity was 0.689 and the median quality 0.452. The complexity factor was computed as 0.689 / 0.5 = 1.38 and the quality factor was computed as 0.5 / 0.452 = 1.11. The size in object plans was then adjusted to
1.132 x 1.38 x 1.11 = 1734 object-points.

0.35

1.5 (50.2)

= 5.9 calendar months

to complete our reengineering project for 71.000 adjusted statements with a quality increase of 80%.
(see Figure 7).
Calculation parameters:
Size Unit: Statements
Daily Productivity: 200 Statements
Overhead:0.15 Change Rate:1.80
MaxTime to complete: 8 months
___________________________________
Number of Data Objects ..........36
Number of Interfaces ............42
Number of Processes..............25
Number of original Stmts......50000
Number of adjusted Stmts......71000
Stmts adjusted by quality....127800
Stmts adjusted by influences.127800
Quality Increase Factor........1.80
Influence Factor ..............1.00
Risk Factor....................1.57
___________________________________

Proceedings of the 12th Working Conference on Reverse Engineering (WCRE’05)

1095-1350/05 $20.00 © 2005 IEEE

In the following step the size was further adjusted by the quality improvement factor of 1.25 derrived from the gap analysis to 2168 object-points.
The productivity of 16 object-points per person day was reduced to 12.8 because of the negative influence factor of 0.8 or 20% less productivity for working with inexperienced students in a university environment. This resulted in a raw effort of
2168 / 12.8 = 169 person days.
The risk factor was computed as
1 + [ (0.8 x 0.3) x (1-0.4) ] = 1.14 where 0.8 = risk probability
0.3 = risk impact
0.4 = risk reduction

Adjusting for risk changed the estimated effort to
169 x 1.14 = 192 days or 9 person months of effort.
Using the modified COCOMO time equation
0.35

1.5 (9) resulted in a time estimate of 3.7 months.
The reengineering task was then assigned to three groups of three students apiece. The task required 2 months for one group, i.e 6 person months, and 2.5 months for the other two, i.e. 7.5 person months, so that in all cases the actual effort and time was less then that estimated. On the other hand the quality goal of 25% increase was not reached by any of the groups. The highest quality increase was by 17%.
The code was converted from C to C++ by breaking it up into classes with virtual interfaces, by refactoring the large C functions into smaller methods and by introducing some base classes, but the code quality as measured by the static analyzer did not increase significantly. To have made substantial quality improvements would have cost much more effort, probably more than 3 person months. This would have then surpassed the original effort estimation of 9 person months. [22]

5. Experience with the estimation of reengineering projects
The author has already reported on the outcome of
13 reengineering projects of which 9 were finished on time and within budget. The size of the systems ranged from 50,000 to 500,000 statements. The duration of the projects ranged from 6 months for the smaller ones to 20 months for the largest.
Actually the smaller projects were more difficult to calculate than the larger ones, because of rigging up costs and variable productivity. It was shown that reengineering projects are much more likely to be calculated accurately than development projects where the risks of underestimating are much greater. According to the Standish group studies only 18% of the development projects are finished on time and within project. Some 57% never come to a conclusion. However, this is definitely not true for reengineering projects. [23]
The decisive advantage of reengineering projects is that the scope of the project is defined by the existing system. The existing system can be analyzed and measured and can serve as a base reference for relative quality improvements. The demand to achieve high quality can only be met relative to a point of reference, e.g. high compared to what? The existing system provides that reference point.

Proceedings of the 12th Working Conference on Reverse Engineering (WCRE’05)

1095-1350/05 $20.00 © 2005 IEEE

Since reporting on the 13 projects in 1999 the author has been called upon to estimate another seven reengineering projects. Of these only three were actually carried out. In three others the project remain pending. The user managers are not able to decide what to do. In the seventh case, the user decided to replace the existing system with a standard package. User companies have become very reluctant to take risks, so they are more likely to do nothing at all rather than take a risk of failure.
Of the three actually carried out, only one of them exceeded the effort estimated, whereas two exceeded the time estimated. The effort was exceeded by 12% whereas the time was exceeded by more than 30%. The time estimation based on the COCOMO equation is no longer really applicable. It seems to be much more difficult to estimate time than effort, or it could be that the relation between the two is not as stable as Boehm assumed it to be. In any case there is need for improvement here. [24].

6. Conclusion and future work
The author has been estimating reengineering projects since his first report on that topic appeared in 1984. [25] Ever since, he has striven to improve his estimation techniques. This paper has presented the results of that work after 20 years of refinement and calibration, trial and error. It is clear that there are still many factors not considered. Every estimation approach uses only a subset of the potential measurements which could have an influence on the outcome of the project. Like the universe in which we live, the dimensions of the estimation problem are not infinitive but they are growing faster than our ability to comprehend them.
Thus there will never be a comprehensive, all encompassing estimation method. There will be only practical approaches based on the experience of those which created them within a limited domain of application. The smaller that domain is, the greater the accuracy of the method. For that reason the author has limited his estimation approach to the reengineering domain, a domain for which he is familiar.
Even within this limited domain, there is still much to be done. As pointed out before, there is a need to revise and refine the time estimation. Studies are required on the relation between effort and time in reengineering projects. There is also a need to study more closely the impact of quality improvement on maintenance effort. The experience of the author has been that users are reluctant to pay for quality improvement because they are unable to quantify their benefits. The effect of the environment and, in

particular, the effect of tools upon productivity must be analyzed. [26]
Finally, there is still much to be done in assessing what effect risks have on the project schedule. Here there is a definitive need for more empirical studies.
In light of these many open issues, it is clear that the method presented here can only be considered as just another stage in a continual leaning process.

References:
[1] Sneed, H.: „Economics of Software Reengineering“,
Journal of Software Maintenance, Vol. 3, Nr. 3, Sept.
1991, s. 163
[2] Sneed, H.: „Planning the Reengineering of Legacy
Systems“, IEEE Software, Jan. 1995, p. 24
[3] Sneed, H.: “Encapsulating Legacy Software for Reuse in Client/Server Systems” in Proc. of WCRE-96,
IEEE Computer Society Press, Monterey CA, 1996,
p. 104
[4] Fowler, M.: Refactoring – improving the design of existing code, Addison-Wesley, Reading, MA., 1999,
p. 53
[5] Brodie, M./ Stonebraker, M.: Migrating Legacy
Systems, Morgan Kaufman Publishers, San
Francisco, 1995, p. 8
[6] Teng, J.T,C./Jeong, S.R.´/Grover, V.: “Profiling successful Reengineering Projects”, Comm. Of ACM,
Vol. 41, No. 6, June 1998, p. 96
[7] Dromey, D.: “A Model for evaluating Software
Product Quality”, IEEE Trans. on S.E., Vol. 21, No.
2, Feb., 1995, p. 146
[8] Bianchi,A./Caivano,D./Marengo,V./Visaggio,G.:
“Iterative Reengineering of Legacy Systems”, Trans. on S.E. Vol. 29, No. 3, March 2003, p. 225
[9] Sneed,H./Merey,A.: “Automated Software Quality
Assurance”, IEEE Trans. on S.E. , Vol. 11, No. 9,
Sept. 1985, p. 909
[10]Sneed, H.: “Measuring Reusability of Legacy
Software Systems“, Software Process – Improvement and Practice, Wiley Pub., No. 4, March, 1998, p. 43
[11]Sneed, H.: „Understanding Software through
Numbers“, Journal of Software Maintenance, Vol. 7,
No. 6, Dec. 1995, p. 405
[12]Sneed, H.: “Constructing an XML-based Metric
Database” Proc. of 12th Int. Workshop on Software
Metrics, Magdeburg, Okt, p.89
[13]Sneed, H.: “Bank Application Reengineering and
Conversion at the Union Bank of Switzerland”, Proc. of ICSM-1991, IEEE Computer Society Press,
Sorrento, Oct. 1991, p. 60
[14]Tahvildari, L./ Kontogiannis, K.: Improving design quality using meta-pattern transformations – a metricbased approach, Journal of Software Maintenance &
Evolution, Vol. 14, No. 4, Oct., 2004, p. 331
[15]Anselmo, D./Ledgard,H.: “Measuring Productivity in the Software Industry”, Comm. Of ACM, Vol. 46,
No. 11, Nov. 2003, p.121
[16]Albrecht, A./Gaffney, J.: „Software Function,
Sources, Lines of Code and Development Effort
Prediction“, IEEE Trans. on S.E., Vol 9, Nr. 6 Juni
1983, p. 639

Proceedings of the 12th Working Conference on Reverse Engineering (WCRE’05)

1095-1350/05 $20.00 © 2005 IEEE

[17]Boehm, B. u.a.: Software Cost Estimation with
COCOMO-II, Prentice-Hall, Englewood Cliffs, N.J.,
1999, p. 36
[18]Abdel-Hamid, T.: “Adapting, correcting and perfecting Software estimates – A maintenance metaphor”, IEEE Computer, March, 1993, p. 20
[19]Sneed, H.: “Risks involved in Reengineering
Projects”, Proc. of 6th IEEE Conference on Reverse
Engineering, IEEE Computer Society Press, Atlanta,
Oct. 1999, p. 204
[20]Wallace,L./Keil, M.: “ Software Project Risks and their effects on Outcomes”, Comm. Of ACM, Vol.
47, No. 4, April 2004, p.68
[21]Chulani, S./Boehm, B./ Steece, B.: “Bayesian
Analysis of Empirical Software Engineering Cost
Models”, IEEE Trans. on S.E., Vol. 25, No. 4, July,
1999, p. 573
[22]Sneed, H.: “Aufwandsschätzung im Software
Rengineering”, Wirtschaftsinformatik, Band 6, Dec.
2003, p. 599
[23]Standish Group: CHAOS - The Cost of IT project failures, in PC-Week, Nr. 16, Jan 1995, p. 3
[24]Chan, T./Chung, S.L./ Ho, T.H.: “An Economic
Model to Estimate Software Rewriting and replacement Times, IEEE Trans. on S.E., Vol. 22, No.
8, August, 1996, p. 580
[25]Sneed, H.: “Software Renewal – a case study” IEEE
Software, Vol. 1, No. 3, July 1984, p. 56
[26]Bruckhaus, T./Madhavji, N./Janssen, I./Henshaw, J.:
“The Impact of Tools on Software Productivity”,
IEEE Software, Sept. 1996, p. 29

This document was created with Win2PDF available at http://www.daneprairie.com.
The unregistered version of Win2PDF is for evaluation or non-commercial use only.

Proceedings of the 12th Working Conference on Reverse Engineering (WCRE’05)

1095-1350/05 $20.00 © 2005 IEEE