Paper:
Authors:
Source:
Summary:
“Iterative Reengineering of Legacy Functions”
Alsessnandro Bianchi, Danilo Caivano, Vittorio Marengo, Giuseppe
Visaggio
IEEE International Conference on Software Maintenance 2001; (7-9
Nov 2001), pp 632-641
Michele Biddy
Summary
This paper is proposing a new methodology for reengineering legacy systems. The
approach, Iterative Reengineering, claims to overcome the common issues faced when
converting an older system to a new one, such as maintenance and accessing data during
the conversion process. This methodology introduces the concept of gradually converting
the system by its components/functions over a period of time, instead of all at once. This
is accomplished by:





Continuing to use the original Legacy functions and database.
Create a new database and gradually restore the Legacy functions that have no
inter-dependencies to the new system to access the new database, and then delete
them from Legacy system.
Reconstruct the restored functions and have them still access the new database.
Create a UI that will allow the user to interact with all
When the entire system is converted, remove the legacy database.
The main goal of this methodology is to keep the data intact, as it is the most important
aspect of the system. To accomplish this, the process is done in gradual increments by
slowly moving components over to the new system and phasing out the legacy system.
This process allows the Legacy system to still be used and maintained to keep operations
flowing.
How does this affect us?
This paper discusses converting an entire Legacy system over to a new platform, by
reengineering it by the functions. We are not trying to reengineer our entire system, just
update what is necessary to make it ANSI C++ compliant and able to run a newer
version of Solaris. We are not reengineering the entire program. The paper also discusses
gradually moving it to the new system in small increments as to not disable the program
from daily operations. Our system is not running at all and is not actively being used by
anyone, so we have the freedom of porting it over however we see fit.
Strengths/Weaknesses:
I think that this approach is most logical that I have heard about so far. They recognize
the fact that keeping the integrity of the data is extremely important, as is not
interrupting the usage of the system. It would have been nice if they would have
considered using their methodology on smaller systems, or ones that had minimal
conversion or corrections to be made. Not all upgrades need to be done on entire systems
and it would be nice to see different approaches on just making minimal upgrades.