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. 25