TilleySmith96 |
PublicReengineering Wiki |
|
| The Reengineering Center in the Software Engineering Institute at Carnegie Mellon University has produce a number of comprehensive works. Their most notable
contribution describes a number of factors affecting projects which they have observed, including:
Program understanding is critical to the success of reengineering monolithic legacies;
Understanding is hampered by lack of documentation, turnover of staff and the difficulties of recovering the total architecture.
Maintenance staff have the greatest understanding of the legacy, but their time is in high demand.
Unfinished systems are particularly problematic.
An in-depth analysis of the legacy is a vital pre-requisite to being able to plan and cost the reengineering project.
Deployment and transitioning the systems is often not properly planned.
Testing may contribute a higher burden than in new system development.
There may well be resistance to change.
Upward compatibility must be considered.
Reverse engineering is most commonly employed to gain system understanding. This can include expert consultation and usage observation.
Useful tools exist to navigate the legacy code and extract structural information, execution flows and even language conversion.
Language conversion is rarely perfect.
Adding function is a common reengineering goal - error correction usually carries a lower priority.
Other goals are improved performance and scaleabiliy and obsolescence (including problems with compatibility, maintenance and interoperability).
Requirements creep always happens. Plans need to be able to accommodate mid-term corrections.
Tools exist to provide objective assessment of legacy code and other artifacts. Results can help reengineering/redevelopment decisions.
Seemingly innocuous issues such as lack of data separation or documentation can severely affect the project.
COTS systems are enablers not miracles.
As much as half reengineering project time can be spent on documentation.
Typical critical success factors for a reengineering project are: the system can perform and function better; users were not adversely affected; and the customer
perceives better value than would have been attainable through a new development.
It is important to understand the users to avoid unnecessary reengineering.
Metric should be used with care and it is risky to compare between organisations.
Rapid prototyping of the UI helps early buy-in by users.
It is challenging to maintain the legacy as the reengineered artifact is being developed.
The target must be more amenable to reengineering than the legacy or the project has not succeeded.
They suggest a template for cataloguing case studies - smacks of patterns but doesn't quite get there.
Related pages: Bibliography |
| This page last edited on 29 October 1999 |