UNIVERSITY OF LEICESTER

M.Sc. in Software Engineering - CO7206 System Reengineering

Suggest the main reason behind failure in each of these cases (from Ref#1):

1. A large corporation had two different material management systems as the result of an earlier failed migration effort. These systems were deployed on two different platforms and had a significant amount of functionally redundant code with separate evolution paths. One system was used primarily for online data entry with a local version of the entire database. The second system, which was asynchronously updated by the data entry system, stored the permanent records and performed the primary business functions of materials management. This arrangement resulted in chronic code consistency and runtime synchronization problems between the two systems. As a result, a staff of 10 maintenance programmers was required to spend full time (and substantial overtime), fixing bugs and correcting data inconsistencies. A study was performed that analyzed the work of the maintenance staff, the types of problems being encountered, and the programs that were affected. This study determined, not surprisingly, that data synchronization problems between the two systems were responsible for 80% of the maintenance costs, so it recommended a short-term effort to migrate away from the front-end system. However, the recommendations were turned down. A whole culture had grown up around fixing database inaccuracies, and the associated overtime pay that was required. The existing programmers felt that their jobs were threatened and the management information systems (MIS) manager did not see any clear gain for himself because organizational budgeting considerations made funding of (even short-term) reengineering efforts far more difficult than funding of maintenance. The status quo carried the day and unwarranted maintenance costs continued in the organization.

2. At a bank in 1997, an operations vice president refused to give his operations manager the resources and personnel that he requested to attack the bank's Y2K problems. The vice president saw little reason to address that long-range problem when he had short-range problems to solve. He was scheduled to retire in 1999, so he could not be held accountable for any shortcomings on January 1, 2000.

3. A large system had a history of chronic problems. There was a substantial backlog of trouble reports, with little discernible progress in working down the backlog. When an analysis was done, it was found that the change requests did not have any metrics associated with them, nor was there any indication of ease of change or severity. For example, a typographical error on a page of documentation appeared equal to an error indicating the system could not be initialized. In addition, there was no prior analysis of which modules in the system were relatively error free versus those that had many errors. There was not a repeatable process for making changes. As a result it was virtually impossible to estimate how long minor changes would take to accomplish, much less long-term evolutionary changes. (After a major effort at developing data for the trouble reports, a certain amount of stability was established for the system.)

4. A project with a set of chronic problems was reorganized with new personnel and a new strategy. The new strategy involved reengineering current code to a scaled down set of requirements. As part of this strategy, a new software engineering development environment was employed. The environment consisted of a set of proven tools, each of which was well regarded as among the leaders in its class. However, the plan depended on integrating the tools in a seamless way and on using this environment for production of the system. The schedule called for the environment to be brought up over a weekend. The integration did not work, and production came to a grinding halt. Eventually, a scaled down and more feasible strategy was developed, but the project lost precious time and millions of dollars in getting back on track. The lesson is that even a relatively small part of an overall plan can cause problems if it is on the critical path, and even when individual components are proven, integration aspects can come back to haunt a project.

Ref#1 John Bergey, Dennis Smith and Scott Tilley, Nelson Weiderman and Steven Woods. Why Reengineering Projects Fail, Tech. Rep. CMU/SEI-99-TR-010, Software Engineering Institute, Carnegie Mellon University, April 1999. ²⁵