focusguest editors’ introduction

Software Evolution
Tom Mens, Université de Mons

Yann-Gaël Guéhéneuc, École Polytechnique de Montréal

Juan Fernández-Ramil, The Open University, UK

Maja D’Hondt, Imec

M
odern society depends heavily on software systems. Software can enable or
even accelerate human, social, economic, and technological changes. Soft-
ware systems must often reflect these changes to adequately fulfill their roles
and remain relevant to stakeholders, but the number of new requirements
and maintenance requests often grows faster than software owners’ abilities to implement
them. Evolving and maintaining these systems is therefore critical and, consequently, most
developers work on maintaining, incrementally enhancing, and adapting existing systems.
After two decades of growing interest in soft- one order of magnitude between the yearly publica-
ware evolution and related topics (see the side- tion rates in the 1990s and those of the last decade.
bar “Software Evolution Concepts and Termin- This special issue brings this important topic
ology”), many research groups are now working further into the spotlight by providing a sample of
in this area and producing a growing body of recent research results with tools, lessons, and pat-
knowledge (see the sidebar “Related References terns that are applicable to real-world cases. We
and Further Reading”). In May 2010, Google hope that this will stimulate further consideration,
Scholar reported that for 2009, 70 publications awareness, and research into software evolution.
had “software evolution” in the title, and more
than 900 had “software evolution” somewhere in Lehman’s Laws
the text. Google Scholar data also shows, for these Practitioners involved in software evolution are
evolution-related publications, an increase of almost likely to face, knowingly or not, some of the con-

22 IEEE SOFT WARE Published by the IEEE Computer Society 0 74 0 -74 5 9 / 10 / $ 2 6 . 0 0 © 2 0 10 I E E E

Related References and Further Reading on Software Evolution
Books tion, IEEE CS Press, 2005, pp. 13–22; doi: 10.1109/
■■ Software Evolution, T. Mens and S. Demeyer, eds., IWPSE.2005.7.
Springer, 2008. ■■ M. Petrenko et al., “Teaching Software Evolution
■■ Software Evolution and Feedback—Theory and ■ in Open Source,” Computer, vol. 40, no. 11, 2007,
Practice, N. Madhavji, J. Fernández-Ramil, and pp. 25–31; doi: 10.1109/MC.2007.402.
D. Perry, eds., Wiley, 2006. ■■ A. van Deursen et al., “Model-Driven Software
■■ Program Evolution: Processes of Software Change, Evolution: A Research Agenda,” Proc. Int’l Workshop
M.M. Lehman, L.A. Belady, eds., Academic Press, on Model-Driven Software Evolution (MoDSE07),
1985; ftp://ftp.umh.ac.be/pub/ftp_infofs/1985/ Vrije Universiteit Amsterdam, 2007, pp. 334–350;
ProgramEvolution.pdf. www.cs.vu.nl/csmr2007/workshops/p19.pdf.
■■ H.M. Sneed, “The Drawbacks of Model-Driven
Website Software Evolution,” Proc. Int’l Workshop
■■ The European Research Consortium for Informatics Model-Driven Software Evolution (MoDSE07),
and the Mathematics (ERCIM) Working Group on Vrije Universiteit Amsterdam, 2007; www.cs.vu.nl/
Software Evolution hosts a wiki with PhD theses, csmr2007/workshops/p9.pdf.
events, projects, tools, terminology, and more at ■■ M. Godfrey and D. German, “The Past, Present
http://wiki.ercim.eu/wg/SoftwareEvolution. and Future of Software Evolution,” Proc. Int’l Conf.
Software Maintenance, IEEE CS Press, 2008; doi:
Articles 10.1109/FOSM.2008.4659256.
■■ M.M. Lehman, “Programs, Life Cycles, and Laws of
Software Evolution,” Proc. IEEE, IEEE Press, vol. 68, Standards and Similar Sources
no. 9, 1980, pp. 1060–1076. ■■ ISO/IEC 14764 IEEE Std. 14764-2006, Software Engi-
■■ E.J. Chikofsky and J.H. Cross, “Reverse Engineering neering—Software Life Cycle Processes—Maintenance,
and Design Recovery: A Taxonomy,” IEEE Software, IEEE, 2006; doi: 10.1109/IEEESTD.2006.235774.
vol. 7, no. 1, 1990, pp. 13–17; doi: 10.1109/52.43044. ■■ The Guide to the Software Engineering Body of ■
■■ K.H. Bennett and V.T. Rajlich, “Software Maintenance Knowledge (SWEBOK; www.swebok.org) includes
and Evolution: A Roadmap,” Proc. Conf. Future of a chapter on software maintenance, including
Software Eng., ACM Press, 2000, pp. 73–87; doi: measurement, planning, and support.
10.1145/336512.336534. ■■ The IT Infrastructure Library (ITIL; www.itil-officialsite.
■■ N. Chapin et al., “Types of Software Evolution and com/home/home.asp) consists of concepts and good
Software Maintenance,” J. Software Maintenance IT management practices. Software project manag-
and Evolution: Research and Practice, vol. 13, no. 1, ers can use ITIL in planning and organizing software
2001, pp. 3–30; doi: 10.1002/smr.220. maintenance processes (for example, service support
■■ T. Mens et al., “Challenges in Software Evolution,” and delivery, software asset management, and other
Proc. 8th Int’l Workshop on Principles of Software Evolu- practical aspects of IT management).

straints implied by the laws of software evolution it’s a vendor or the open source community, must
Meir M. Lehman introduced in the 1970s. These still implement the changes.
laws or, rather, empirical hypotheses, suggest that
any actively used software system must continually Articles in This Issue
change to satisfy its stakeholders. On the basis of Software evolution spans a wide range of topics
such changes, the system gradually degrades over within software engineering. ����������������
This special is-
time because such changes are likely to increase its sue opens with two invited and complementary
complexity. If the complexity isn’t controlled (for perspectives on software evolution by two well-
example, via refactoring in object-oriented systems known authors in software engineering, Kent
or restructuring), then evolution costs can escalate, Beck and Barry Boehm. Boehm argues that the
leading to even more complex changes—a vicious time of “one software evolution process fits all” is
circle—until the software owners must make a over and provides guidelines to select the most ap-
radical decision, such as reengineering, migration, propriate evolution-friendly process under various
redevelopment, or replacement. But even replace- circumstances. Beck acknowledges the inevitabil-
ment by an off-the-shelf system doesn’t avoid the ity and difficulty of evolving a software design.
need for evolution: the software’s owner, whether He reminds us of the various factors that software

July/August 2010 I E E E S O F T W A R E 23
Software Evolution Concepts and Terminology
We present a short glossary of important terms in software A legacy software system is any system that significantly
evolution to accompany the contributions to this special issue. resists modifications and changes while remaining of signifi-
Software maintenance is different from the maintenance cant value for its owner. The system might have been devel-
of physical goods because it normally leads to a changed or oped using an outdated programming language or an obso-
improved software system. Physical goods maintenance seeks lete development method. Most likely, it has changed hands
to restore the item or entity (for example, an airplane or a several times and shows many signs of degradation.
car) as close as possible to factory condition. Software doesn’t Reengineering is “the examination and alteration of a
wear out but it “degrades” through suboptimal “quick fixes” subject system to reconstitute it in a new form and the subse-
and through an increasing number of unfulfilled requirements. quent implementation of the new form. Reengineering gener-
Nontrivial software isn’t free from defects: some maintenance ally includes some form of reverse engineering (to achieve a
is always required as long as the software is in use. more abstract description) followed by some form of forward
Software evolution is also different from the evolution engineering or restructuring. This may include modifications
of physical goods. It’s mainly concerned with changes in a to fulfill new requirements not met by the original system.”4
software system over versions or releases of the same sys- Forward engineering is “the traditional process of moving
tem, while physical goods tend to evolve over “generations from high-level abstractions and logical, implementation-inde-
of products” (that is, there’s little or no evolution of a specific pendent designs to the physical implementation of a system.”4
physical product). Restructuring is “the transformation from one representa-
There are various definitions of software evolution and tion form [of a software system] to another, at the same rela-
software maintenance. The ISO/IEC/IEEE 14764:2006 stan- tive abstraction level, while preserving the subject system’s
dard states that software maintenance is “the totality of activi- external behavior (functionality and semantics).”4
ties required to provide cost-effective support to a software Refactoring is the object-oriented specialization of restruc-
system.”1 This standard includes pre-delivery (planning and turing. When applied to source code, the goal of both is to
logistics) and post-delivery activities (actual software modi- improve the internal structure (for example, reduce complex-
fication) as part of maintenance work. One view considers ity) of software to make it easier to understand and modify.
both evolution and maintenance as synonyms that cover all Reverse engineering is “the process of analyzing a subject
the work done to update and fix a software system after its system to identify its components and their interrelationships
first release. Some practitioners might find it more natural to and to create representations of the system in another form or
refer to evolution when functionality or some other aspect of at a higher level of abstraction. Reverse engineering generally
the software is improved, with maintenance referring mainly involves extracting design artifacts and building or synthesiz-
to essential adaptations and fixes to keep the software run- ing abstractions that are less implementation-dependent.”4
ning. Keith H. Bennett and Václav T. Rajlich consider evolu-
tion a stage of the software life cycle.2 A complementary References
view is to consider software maintenance as wider and more 1. ISO/IEC 14764 IEEE Std. 14764-2006, Software Engineering—Soft-
ware Life Cycle Processes—Maintenance, IEEE, 2006; doi: 10.1109/
encompassing than software evolution. The latter concerns IEEESTD.2006.235774.
updating and changing the code and other technical artifacts, 2. K.H. Bennett and V.T. Rajlich, “Software Maintenance and Evolution: A
while maintenance also includes regression testing, adminis- Roadmap,” Proc. Conf. Future of Software Eng., ACM Press, 2000, pp.
73–87; doi: 10.1145/336512.336534.
trative, and support activities such as help desks and technical 3. N. Chapin et al., “Types of Software Evolution and Software Mainte-
support. Ned Chapin and his colleagues provide a compre- nance,” J. Software Maintenance and Evolution: Research and Practice,
hensive classification of software maintenance and evolution vol. 13, no. 1, 2001, pp. 3–30; doi: 10.1002/smr.220.
4. E.J. Chikofsky and J.H. Cross, “Reverse Engineering and Design Recov-
work,3 beyond the classical corrective, preventative, adaptive, ery: A Taxonomy,” IEEE Software, vol. 7, no. 1, 1990, pp. 13–17; doi:
and perfective in the ISO/IEC/IEEE 14764:2006 standard. 10.1109/52.43044.

developers and managers must consider when driven modernization, reengineering legacy sys-
evolving systems (such as cost, time, and risk), in- tems, program refactoring, reverse engineering,
cluding the need to keep a system operational dur- and software quality assessment and improvement
ing its actual evolution, which is particularly rel- during evolution.
evant to some critical applications. Joris Van Geet and Serge Demeyer highlight
This special issue also includes five peer- the difficulties of applying mature techniques for
reviewed articles that provide samples of industri- software evolution in practice. They indirectly jus-
ally relevant research results aimed at facilitating tify the need for increased technological transfer
various aspects of software evolution. They cover between research and practice. For example, al-
model-driven software evolution, architecture- though researchers have studied feature identifica-

24 IEEE SOFT WARE w w w. c o m p u t e r. o rg /s o f t w a re

tion and other techniques for years, industry’s ac- About the Authors
ceptance of such techniques is low, mostly because
of the lack of out-of-the-box implementations. Tom Mens is a professor directing the Software Engineering Lab at the Institut
d’Informatique, Faculty of Sciences, Université de Mons. His research interests are in formal
By highlighting the need for a more practical ap- foundations and automated tool support for software evolution, as well as in model-driven
proach to software evolution, Javier Luis Cánovas software engineering. Mens has a PhD in software evolution from Vrije Universiteit Brussel.
Izquierdo and Jesús García Molina illustrate how He’s a member of IEEE, the IEEE Computer Society, the ACM, the European Research Consor-
tium for Informatics and Mathematics (ERCIM), and the European Association of Software
the architecture-driven modernization initiative by Science and Technology (EASST). He co-edited Software Evolution (Springer, 2008) with
the OMG (Object Management Group) can con- Serge Demeyer. Contact him at [email protected].
cretely help in evolving legacy PL/SQL (Procedural
Language/Structured Query Language) code to
Yann-Gaël Guéhéneuc is an associate professor in the Department of Computing
Java code. Engineering and Software Engineering at Ecole Polytechnique of Montreal where he leads
Eric Bouwers and Arie van Deursen discuss the Ptidej (pattern trace identification, detection, and enhancement in Java) team. In 2009,
when to perform evolution, while introducing a the Natural Sciences and Engineering Research Council awarded him the Research Chair Tier
II on software patterns and patterns of software. His research interests include evaluating
lightweight approach to monitor a system’s ar- and enhancing the quality of object-oriented programs by promoting the use of patterns,
chitecture. How to perform evolution has been at the language-, design-, and architectural level. Guéhéneuc has a PhD in software
the subject of much research work, and Gustavo engineering from the University of Nantes. He’s a member of IEEE, the European Research
Consortium for Informatics and Mathematics (ERCIM), and the Order of the Engineers of
Soares, Rohit Gheyi, Dalton Serey, and Tiago Mas- Quebec. Contact him at [email protected].
soni present a tool that evaluates whether an applied
refactoring appears to be harmless by automati-
Juan Fernández-Ramil is a lecturer in the computing department at The Open
cally generating relevant test cases, which can then University, UK, where he’s involved in distance teaching of software management and
be executed to check that the system’s behavior is relational databases. His research interests include software metrics, software maintenance
preserved and, consequently, added to the system’s productivity, and code decay assessment. Fernández-Ramil has a PhD in computing from
Imperial College London. He co-edited Software Evolution and Feedback: Theory and Practice
overall test suite. These approaches give developers (Wiley, 2006) and co-authored Managing the Software Enterprise: Software Engineering and
confidence that they’re performing the right kind of Information Systems in Context (Cengage Learning EMEA, 2007). Contact him at j.f.ramil@
evolution at the right moment. They can also help open.ac.uk.
convince managers that the time is right to perform
evolution tasks.
Maja D’Hondt is a program manager at Imec Belgium, an independent research center
However, managers could still consider that evo- for microelectronics and information and communication technology. She’s responsible for
lution tasks, technically sound, are a waste of time. developing software technology for adaptive resource management in embedded and high-
Hongyu Zhang and Sunghun Kim address this di- performance systems. Additionally, she’s a guest professor at the Vrije Universiteit Brussel.
D’Hondt has a PhD in computer science from Vrije Universiteit Brussel. Contact her at
lemma by showing how to visualize defect trends [email protected].
and study patterns that might appear. They do so
through the simple means of C-charts, which are
commonly used in statistical quality control.

I
Mercy Frederickson for promptly and professionally
f you want to find out more, we provide a answering the many emails and queries, and help-
ing out when needed. ����������
Yann-Gaël Guéhéneuc
�����������������
is sup-
list of recommended articles and books in ported by the Fonds Québécois de la Recherche sur
the sidebar “Related References and Further la Nature et les Technologies (FQRNT), the Natural
Reading.” You could also attend one of the annual Sciences and Engineering Research Council, and the
Canada Research Chair Tier II in Software Patterns
conferences or workshops covering this topic, such and Patterns of Software. Part of Juan Fernandez-
as the IEEE International Conference on Software Ramil’s work related to this special issue was fund-
Maintenance (ICSM), the IEEE European Confer- ed by the Belgian Fonds de la Recherche Scientifique
(FRS—FNRS) through postdoctoral grant number
ence on Software Maintenance and Reengineering 2.4519.05. Tom Mens is supported by Action de Re-
(CSMR), or the International Workshop on Prin- cherche Concertée AUWB-08/12-UMH19 “Model-
ciples of Software Evolution (IWPSE). Driven Software Evolution” funded by the Ministère
de la Communauté française—Direction genérale de
l’Enseignement non obligatoire et de la Recherche
scientifique (Belgium), and by the project Technolo-
Acknowledgments gies d’Information et de Télécommunication (TIC)
We thank all the authors who contributed to this co-funded by the European Regional Development
special issue as well as the anonymous reviewers Fund and the Walloon Region (Belgium).
and the administrative staff of IEEE Software. Our
IEEE Software mentor, Martin Robillard, contrib-
uted his experience and insights into many aspects of
this issue’s preparation. We’re also grateful to editor-
in-chief Hakan Erdogmus, lead editor Dale Strok, Selected CS articles and columns are also available
content editor Brian Brannon, and administrator for free at http://ComputingNow.computer.org.

July/August 2010 I E E E S O F T W A R E 25