1 4 I E E E S o f t w a r e J u l y / A u g u s t 1 9 9 8 0 7 4 0 - 7 4 5 9 / 9 8 / $ 1 0 . 0 0 © 1 9 9 8 I E E E

egacy systems present a fundamental challenge to those who own andoperate them: they have begun to age but continue to provide vitalservices. They were designed following requirements and an imple-mentation approach that existed earlier in the organization’s life cycle.

Then they were released into environments different from those planned. Now,years and sometimes decades later, they are still expected to operate efficiently,solve problems, and incorporate changes in technology and business practices formany years to come.

Because legacy software systems are so crucial to an organization’s survival, theyare not retired or redesigned without compelling reasons. Major changes require ahuge investment in new technology, with the significant risk that the new systemsmay fail to deliver the required services. Therefore, organizations maintain func-tionality, correct defects, and upgrade legacy systems to keep up with changingbusiness conditions.

Norman F. Schneidewind, Naval Postgraduate School

Christof Ebert, Alcatel Telecom

The quest ion o f whether to mainta in , redes ign, or re t i rea legac y sys tem do es not have an easy answer. Th is fo cussec t ion examines legac y sys tems f rom severa l p ersp ec t ives,and t wo case s tud ies i l lus t ra te some of the cha l lenges indea l ing wi th ag ing but necessar y so f t ware sys tems.

L

Guest Editors’ Introduction

Preserve orRedesign Legacy Systems?

Preserve orRedesign Legacy Systems?

.

J u l y / A u g u s t 1 9 9 8 I E E E S o f t w a r e 1 5

Keeping legacy systems up to date involves twolevels of change. One is technological, such as mov-ing a system from a mainframe to desktops on alocal area network. The other entails modifying theapplication to increase its functionality or ease ofdata access. Indeed, it is sometimes difficult to drawthe line between preserving a legacy system bymaking a few enhancements or completely re-designing it.

In any event, cost is the essential driver for re-designing a legacy system. Cost and schedule over-runs cause many redesign projects to be aban-doned. If the risk of redesigning a system appearstoo high, the legacy system is preserved.

However, there are plenty of reasons not to pre-serve legacy systems. For all aging systems, stabil-ity decreases over time. Modifying the legacy sys-tem therefore becomes increasingly cumbersomebecause those maintaining it don’t always under-stand the impact of smallchanges on the overall architec-ture. Response time to changesand corrections increases due tothe need to preserve existingfunctionality. New functionalityis difficult to add and engineers are reluctant to doso because any change requires extensive regres-sion tests.

We must therefore evaluate legacy systemsbased on whether they are

♦ flexible enough to handle changes in require-ments and

♦ adaptable enough to handle new requirements.Increasingly, organizations are considering alter-

natives to maintaining a legacy system until it is nolonger supportable. Some have begun redevelop-ing or replacing their systems with commercial prod-ucts (such as COTS) where available. This means,however, that organizations must face the prospectof maintaining commercial products and the re-quired interfaces between them.

HOW LONG SHOULDSOFTWARE LIVE?

What business reasons exist for keeping a legacysystem? Why design for maintainability instead ofredesigning systems wholesale? What factors influ-ence whether to install new software or spend ad-ditional effort on the legacy software?

Our Point-Counterpoint section addresses these

issues. Nicholas Zvegintzov argues that softwareshould live longer—that organizations should putmore effort into maintaining and updating them—while John Munson asserts that systems far outlivetheir usefulness. Obviously, the truth lies betweenthese extremes and depends on many factors. Themajor question is, what is software’s optimal life-time? A legacy system might be more stable com-pared to a new design, but over time each smallchange introduces new defects caused by ripple ef-fects that are difficult to find and correct. The cost ofmaintaining a legacy system could eventually ex-ceed the cost of installing a new system.

Munson likens legacy software systems to oldhouses. Obviously, nice century-old houses with asignificant history exist in most cities. Their designdid not include many of today’s amenities, but theysurvived with changes needed to keep them ingood shape and thus allow their owners to enjoy

living in them. However, other houses—some builtmuch later—were demolished because they nolonger served their owners’ needs. While a naturallife span seems to exist for construction work as wellas for software, initial quality will affect a system’slongevity, just as a well-built house will last longer.

EMERGENCE OF COMPONENT-BASEDSYSTEMS

Information technology applications are nolonger monolithic blocks. Increasingly, software en-gineers compile components with heterogeneousorigins. Organizations outsource many of thesecomponents, some of them COTS, while engineersdesign others in-house. Object-oriented languagessuch as Java, together with glue languages such asVisual Basic, facilitate building componentware. Assystems grow, changes in the components may be-come necessary—but this could be difficult with anoutside vendor’s components. The user may haveto wait until the next vendor release to obtain thedesired functionality.

Thus the future maintainability of COTS andcomponents developed in-house is called intoquestion. How do testers prepare for regression

A legacy system might be more stablecompared to a new design, but over timeeach small change introduces new defects.

.

1 6 I E E E S o f t w a r e J u l y / A u g u s t 1 9 9 8

testing of such components? Jeffrey Voas answersthese questions and suggests ways to emphasizethe maintainability of component-based systemsduring the design process.

LESSONS FROM A RESTORATION

Spencer Rugaber and Jim White address thepractical aspects of maintaining a legacy system.Using the interesting analogy of the restorationof the Sistine Chapel, they discuss the restorationof an automatic call distribution system. Althoughtelecommunications switching systems have along history of successful operation as legacy sys-tems, we know little about why they succeed.

Rubager and White offer some insight as theydescribe both the upgrading of the entire systemwithin the existing architecture and the manycomponent improvements. Lessons learned in-clude the need for tool support, knowledge dis-semination, and project management.

LEGACY SYSTEM STABILITY

Many models provide techniques for evaluatingthe reliability of new software by measuring detec-tion and correction of defects. In the last article inthis Focus section, Norman Schneidewind presentsa unified approach for assessing the stability of themaintenance process in terms of the reliability andrisk of deploying software. He shows the results of

evaluating the NASA Space Shuttleflight software, a highly reliable sys-tem that has grown in functional-ity over the last 15 years.

SEEKING MIDDLEGROUND

There is no universal answer tothe question of whether to pre-serve or redesign a legacy system,because the costs and benefits willdiffer in each case. The same ap-plies to the related question of howlong to maintain a legacy systembefore redesigning or replacing it.Most organizations do not rush toreplace legacy systems because

their very survival may depend on the system’s con-tinued operation.

If the decision were entirely in the users’ hands,they would maintain systems longer than ispresently the case. However, like automobile andconsumer appliance manufacturers, informationtechnology suppliers engage in a policy of plannedobsolescence. While the new technology is fre-quently innovative and attractive to users, the newhardware, operating systems, and application pro-grams are incompatible with their legacy systems.This forces users to eventually replace their systemsto take advantage of the new technology.

However, it is not necessary to choose one ex-treme or the other. A third alternative maintainsthe existing system while developing a replace-ment system. This permits thorough inspectionand testing before putting the new system into ser-vice. It may also be possible to install the replace-ment system in stages, thus minimizing disruptionto the existing system. Of course, this alternativeassumes there are resources available to maintainthe existing system while developing its replace-ment. If this is the case, organizations can capital-ize on new technology without incurring the riskof redesigning and replacing the existing systemwhile it is operational. ❖

ACKNOWLEDGMENTThe authors acknowledge the ideas contributed by

Twyla B. Courtot of AT&T Solutions.

F O R M O R E I N F O R M A T I O N . . .A good source of additional information on legacy systems and

maintenance is the annual Proceedings of the International Conference

on Software Maintenance, published by the IEEE Computer Society

Press, Los Alamitos, Calif., http://computer.org/cspress/catalog0.htm.

A good book for practitioners is Practical Software Maintenance:

Best Practices for Managing Your Software Investment, by Thomas M.

Pigoski, John Wiley & Sons, New York, 1997.

For a standard on maintaining software, look at the IEEE Standard

for Software Maintenance, IEEE Std 1219-1992, Institute of Electrical and

Electronics Engineers, New York, June 2, 1993. On the Web, start at

http://standards.ieee.org/.

Last, consult the theme issue on maintenance in the Proceedings of

the IEEE, Vol. 77, No. 4, April 1989.

.

J u l y / A u g u s t 1 9 9 8 I E E E S o f t w a r e 1 7

Norman F. Schneidewind is professor ofInformation Sciences and director of theSoftware Metrics Research Center at theNaval Postgraduate School. He devel-oped the Schneidewind software relia-bility model used by NASA to assist inpredicting the reliability of the SpaceShuttle’s software. Previously, Schneide-

wind held several technical management positions in thecomputer industry, where he directed IT projects in both thepublic and private sectors.

Schneidewind received a BSEE from the University ofCalifornia, Berkeley, an MSEE and MSCS from San Jose StateUniversity, and an MSOR and PhD with a major in operationsresearch from the University of Southern California. He is aLife Fellow of IEEE.

About the Authors

Christof Ebert has been with Alcatel inAntwerp, Belgium, since 1994. He is cur-rently a software engineering processgroup leader in Alcatel’s SwitchingSystems Division, where he is responsi-ble for the software metrics program. Hisresearch interests include software met-rics, software process analysis and im-

provement, and requirements engineering.Ebert earned a PhD in software engineering from the

University of Stuttgart. He is a member of IEEE, GI, VDI, andAlpha Lambda Delta honor society. He is also a member of theIEEE Software Editorial Board.

Address questions about this article to Schneidewind at Code IS/Ss, Naval Postgraduate School, Monterey, CA 93943; e-mailnschneid@nps.navy.mil.

September/October IssueAutonomous Space Systems

To enable more frequent and more intensive space exploration missions at lower cost, NASA’snew era of solar system exploration is being designed around the concept of sustained intelligentpresence on the space platforms themselves. AI, spacecraft engineering, mission design, softwareengineering, and system engineering all have a role to play in these developments.

Guest edited by JPL’s Richard Doyle, this issue will feature articles on spacecraft planning,scheduling & resource management; spacecraft executives; onboard science data analysis andknowledge discovery; software architectures for spacecraft autonomy; and testing and validationof autonomy software – and more!

Also appearing in upcoming issues • Configuration: From Mass Production to Mass Customization• Self-Adaptive Software• Knowledge Representation: Ontologies• Intelligent Agents: The Crossroads between AI and Information Technology• Intelligent Vehicles

IEEE Intelligent Systems (formerly IEEE Expert) covers the full range of intelligent system develop-ments for the AI practitioner, researcher, educator, and user.

IEEE Intelligent SystemsIEEE

...AND MORE!

AI IN HEALTH CAREINTELLIGENT AGENTSSELF-ADAPTIVE SOFTWAREDATA-MINING TOOLSINTELLIGENT VEHICLES

AUTONOMOUS SPACE SYSTEMS

& the i r app l i cat ions

IEEE

.