HYBRID RE-ENGINEERING

Custom Track Hybrid Re-engineering

The Custom track of Hybrid Re-engineering, shown in Figure 6, is similar to

traditional re-engineering since new code is derived from the existing legacy system. In
this track, reverse engineering is first performed. Those functions that are not satisfied
by COTS packages or through translated code must be identified, and its requirements
and design extracted. Forward engineering is then performed. This begins with
requirements analysis, with the objective of identifying requirements that are not
needed. The process is then similar to any development process, beginning with
developing a new design, with object-oriented structure if desired, then implementing
the code and doing comprehensive testing. The advantages to the custom track is that
the resulting code should meet its requirements exactly. The developed code should be
of high quality and well structured requiring little maintenance.

Figure 6: Custom Track Hybrid Re-engineering

The disadvantages are similar to standard software development, in that the code
might not be reliable requiring additional testing, and that the development/testing
process may exceed time and cost budgets. Custom code has the same inherent risks
that any code has, to quality, reliability, and schedule. Since most of the functions of the

DEPARTMENT OF I.T. 1 D.B.N.C.O.E.T,YTL.

 HYBRID RE-ENGINEERING

legacy system identified as unique to the system will be done with custom code, the risk
is that one of the unique features will not be identified and hence the functionality of the
new system will be incomplete. Features identified as critical to the system that are
accomplished with custom code will require extensive testing. Metrics for this track are
a combination of both process and product metrics. Prior to reverse engineering, the
quality of the existing system should be evaluated for later comparison to the target
system (as discussed previously). Effort expended should be tracked to assist in the
evaluation of the cost to re-engineer. This can also be used to approximate schedule
completion using the estimate that 60% of the time is in reverse engineering. Once
requirements are re-specified, their quality can be evaluated to determine testability.
Also discussed previously was the use of function points as a means of calculating the
rate of functionality transfer to the target system. Code analysis tools can be used to
evaluate the quality of the code as it is being developed and identify the risks. In testing,
discrepancy or error rates help in evaluating reliability. In this track, both the
functionality and the quality are compared between the existing system and the target
system.

HYBRID RE-ENGINEERING APPROACH

Hybrid re-engineering requires an approach similar to traditional re-engineering,

but with additional considerations. When starting to re-engineer, initial justifications for
re-engineering such as costs and quality are developed and expectations, such as return
on investment, are stated. An analysis of the legacy system should be done to determine
the feasibility of hybrid reengineering. The analysis of the legacy system should provide
a guideline in identifying optimal strategies (translation, COTS, etc.), and projecting the
cost of the target system. Once the decision on using a hybrid reengineering approach is

made, additional analysis is needed. The first step in a hybrid re-engineering approach is
to investigate the requirements and constraints of the development. These factors
include setting a time table for reverse and forward engineering. Time must be built in

DEPARTMENT OF I.T. 2 D.B.N.C.O.E.T,YTL.

 HYBRID RE-ENGINEERING

to investigate available COTS, including hands on testing of the COTS. While forward
engineering development time should decrease with the use of COTS and the translation
of code, additional time will be needed for testing the integration and interface of the
products of the three tracks. Budget constraints must also be considered; how much can
be spent on COTS that provide required features versus those that provide desired
features. Management mandated and organization needs must also be identified. As the
three tracks are developed, tradeoffs will be necessary so it is important to prioritize
requirements The next step is to do an in-depth analysis of the legacy system, focusing
on functionalities and code segments suitable for each of the three tracks (Translation,
Custom, COTS). In generic re-engineering, an analysis of the existing system is usually
done to provide an evaluation of the quality of the existing system and maintenance
costs. This information is used to justify the costs and improvements at the conclusion
of the re-engineering effort. While these reasons are still relevant in hybrid
reengineering, additional features of the legacy system must now be investigated.
During the assessment of the legacy system, sections and functionalities must be
identified. These must be further assessed to determine what documentation is available
to identify the required features versus what is no longer needed or what users have
become accustomed to. Code sections must be ordered by the cost of maintenance, and
the quality of the current structure. Functions that are unique to this project must be
identified. All of these components will be used to identify which hybrid re-engineering
track will be applied to the code section. Once the code has been divided into the
development tracks, each track will proceed independently as discussed. The schedule
for track completion will differ based on tasks. As the tracks conclude various tasks, the
merging of the final products can begin. For example, the custom glue can be started
once the COTS have been selected. Training on these packages can also begin. Once the
system is complete and all tracks merged, two tasks remain: testing and justification.

First, comprehensive System and Integration testing must be performed to ensure

all components work together as a cohesive unit and to ensure all functionality of the
existing system was transferred to the new system. Second, justification for the re-

DEPARTMENT OF I.T. 3 D.B.N.C.O.E.T,YTL.

 HYBRID RE-ENGINEERING

engineering is usually required – do the benefits gained justify the cost. Some
anticipated benefits, such as improved maintenance and operational costs, can only be
demonstrated indirectly through the improved quality. Improved quality can initially be
demonstrated by a metric analysis of the legacy system compared to the new system. As
the new system is put into operation, additional metrics can be used to verify the
improvements.

HYBRID RE-ENGINEERING RISKS

All software development has inherent risks to schedule and cost. Hybrid re-
engineering, as a software development methodology, is also susceptible to them.
Hybrid re-engineering, because of its composition of the three diverse development
tracks, is subject to all of the risks that were discussed within each track description.
Also, Hybrid re-engineering as a unique software reengineering methodology has
additional risks to functionality and quality; the functionality of the existing system
must be preserved in the new system, and the quality must improve, implying a
decrease in operational and maintenance costs. With all of the risks in Hybrid
reengineering, why bother, why not just treat it as a new software development effort
and omit the re-engineering all together? Because of the benefits.

HYBRID RE-ENGINEERING BENEFITS

In general, re-engineering is performed as opposed to building a new system

because of the invisible business application procedures and logic that are built into the
software. These processes might be deeply embedded in business procedures as simple
as a field length or as complicated as a mathematical algorithm; the only source of this

information is in the legacy code. A second justification for re-engineering versus

building is the development and maintenance costs of the legacy system; the time spent
developing logic and components should not be wasted. In re-engineering, the existing

DEPARTMENT OF I.T. 4 D.B.N.C.O.E.T,YTL.

 HYBRID RE-ENGINEERING

system is re -implemented and instilled with good software development

methodologies, properties, and new technology while maintaining existing
functionality. Reliability and maintainability are also improved. Hybrid re-engineering
has the additional benefits of reduced development schedule, hence reduced costs. The
development schedule is shortened first by minimizing the amount of reverse
engineering (recall, reverse engineering is 60% of the effort). The translation track uses
minimal reverse engineering time since work is done in the lowest level (Figure 2). The
use of COTS decreases the forward engineering development and test time and thus the
costs. The use of properly selected COTS also increases the reliability since these
packages have been extensively tested.

HYBRID RE-ENGINEERING METRICS

Metrics, when properly applied, provide managers information about their project
to help mitigate risks.[5] It is logical therefore, to discuss some of the re-engineering
phases where metrics provide valuable information. Previously we have identified
metrics applicable for each track in hybrid re-engineering. In this section, we will
discuss metrics applicable to the entire project, not just one track. Metrics provide
information on the quality, functionality, and on track selection, a prime areas of risk.
At the start of the re-engineering effort, the legacy system must be quantified. There are
two objectives: identify the amount of functionality and the quality of the existing
system. By quantifying the functionality, scheduling estimates are more accurate;
during development, completion can be estimated by the percentage of functionality
transferred to the new system. Functionality is also important at the conclusion of the
project, measuring how much functionality is contained within the new system. The
SATC and others are working with function points as a means of estimating
functionality. Function points are comparable across languages, and time estimates

based on function points are available.[6] For COTS packages, functionality might be
measured by the number of requirements satisfied. Quality is harder to measure and few

DEPARTMENT OF I.T. 5 D.B.N.C.O.E.T,YTL.

 HYBRID RE-ENGINEERING

software developers agree totally on the ppropriate metrics. The SATC has a group of
metrics it applies to projects to evaluate the quality. These metrics evaluate the project
at the module level (procedure, function, class or method). The size is measured by
counting the number of executable statements. The readability is measured by the
comment percentage. The complexity is measured by the cyclomatic complexity
(McCabe). The coupling is measured by the calling complexity (fan in / fan out).[8]
Although there are many other metrics available, these have been successfully applied
to many projects at GSFC NASA. One final measure of quality is the reliability, the
number of errors found, and the projected number of errors remaining. These metrics
can be used for both the translation track and the custom code track. When the
components are combined, the numbers of erro the projected number of errors
remaining can be applied to the whole system

FUTURE WORK

The field of software re-engineering is new, and its risks and metrics are not well
understood. The newest area, hybrid re-engineering, is even less well known. The
SATC is working to define metrics to quantify the quality of legacy systems and of the
re-engineered products, and to provide reliable measures of progress. It is in this last
area, the measure of progress, that we are experimenting with function points.

SUMMARY

DEPARTMENT OF I.T. 6 D.B.N.C.O.E.T,YTL.

 HYBRID RE-ENGINEERING

The number of large systems being built from scratch is diminishing, while the
number of legacy systems in use is very high. Rapid changes in the computer industry
continually introduce new hardware and software making older systems obsolescent and
difficult to maintain. Businesses do not want to re-develop from scratch; too many
business decisions are built into the legacy systems. Hence re-engineering. But project
development is always short on time and money, making the need to look at alternatives
necessary. The use of COTS packages is seen as a way to increase reliability while
decreasing development and test time. Translation of code is a means of decreasing time
and cost. This has resulted in a combination of the development methods into a form of
hybrid re-engineering.

REFERENCES :-

[1] Pressman, R. “SOFTWARE ENGINEERING - A Practioners Approach”, 5th Edition

[2] Albrecht, A., Gaffney, J. “Software Function, Source Lines of Code, and
Development Effort Prediction: A Software Science Validation”, IEEE Transactions on
Software Engineering, 11/83.

[3] Arnold, R., Software Reengineering, IEEE Computer Society Press, 1993.

DEPARTMENT OF I.T. 7 D.B.N.C.O.E.T,YTL.