The Community for Technology Leaders
Green Image
Issue No. 01 - January (1995 vol. 12)
ISSN: 0740-7459
pp: 24-34
As the manager of a small software-reengineering company, I am continually confronted with the task of justifying reengineering. The user wants to know what the benefits are. Why reengineer old Cobol or Fortran when there are so many attractive fourth- generation and object-oriented languages on the market? That is why I have chosen to address business issues in this article -- not because the technical problems of transforming code and data structures are not important but because they may be irrelevant if you are not able to make a business case for solving them. There is nothing worse for a technician than to be working on a solution to some problem for years, only to discover that the problem was incorrectly stated from the beginning. I have developed a five- step reengineering planning process, starting with an analysis of the legacy system and ending with contract negotiation. The five major steps are project justification, portfolio analysis, cost estimation, cost-benefit analysis, and contracting.
Harry M. Sneed, "Planning the Reengineering of Legacy Systems", IEEE Software, vol. 12, no. , pp. 24-34, January 1995, doi:10.1109/52.363168
99 ms
(Ver 3.1 (10032016))