Reengineering an Existing System
By Russ Finney
If the task at hand is to take an existing system and turn it into a new and improved version - watch out! This is a recipe for wild promises, incredible claims, and generally career ending commitments. Just because the system already exists doesn't mean that fantastic time savings will occur during its redevelopment. Time savings are completely dependent on:
- the complexity of the system
- the familiarity of the team with the system
- the required modifications
- the time needed to specify the modifications
- the time needed to understand the system itself.
The last item on the list is the real show stopper! Nine times out of ten, the team starts by basing their changes on system assumptions and perceptions. And in many cases, it takes about as much time to figure out what a specific program is doing as it would have taken to specify a new program to replace it (and even these conclusions can turn out to be nothing more than informed guesses on the part of the analyst)!
So where is all the hype coming from? Do miracle re-engineering tools really exist? The answer is yes and no. Redevelopment aids do exist and many of them are quite powerful - but they do not replace analyst and programmer thinking (the most time consuming part). What these tools do provide is structural and visual aids which make comprehension easier. These may be in the form of CASE tool knowledge base (dictionary) loaders, program restructuring utilities, or system documentation generators.
Probably the most effective redevelopment tools currently available are the various data base management system data definition language conversion programs. These can take data definitions for one DBMS and translate them into the required form for a new DBMS. This can truly be a time saver if the team's mission is to merely convert the processing from one database manager to another (but even in this situation every program may require modifications to incorporate the correct database access calls).
The moral here is to plan for a complete analysis, design, and construction based approach. The business clients will probably need to be involved to assist in identifying the required business functionality changes during the analysis phase. An iterative prototyping approach may be required to validate proposed screen changes during the design phase. Some form of modification specifications will need to be created to identify the program changes during the construction phase. In addition, the required review and testing time must be considered.
Hopefully, all of the available tools were used to make the process of creating a new forward based design easier. This will especially be true if the current system functionality can be captured as visual models in CASE tools for examination and eventual redesign.
Copyright © 1999, Russ Finney, All Rights Reserved