Software Evolution and Maintenance

A Practitioner's Approach

Priyadarshi Tripathy, Kshirasagar Naik

• Publisher: Wiley
• Year: 2014
• ISBN:
  9781118960295
• Edition: 1
• Topic: Ciencia de la computación
• Subtopic: Desarrollo de software

Provides students and engineers with the fundamental developments and common practices of software evolution and maintenance Software Evolution and Maintenance: A Practitioner's Approach introduces readers to a set of well-rounded educational materials, covering the fundamental developments in software evolution and common maintenance practices in the industry. Each chapter gives a clear understanding of a particular topic in software evolution, and discusses the main ideas with detailed examples. The authors first explain the basic concepts and then drill deeper into the important aspects of software evolution. While designed as a text in an undergraduate course in software evolution and maintenance, the book is also a great resource forsoftware engineers, information technology professionals, and graduate students in software engineering.

• Based on the IEEE SWEBOK (Software Engineering Body of Knowledge)
• Explains two maintenance standards: IEEE/EIA 1219 and ISO/IEC14764
• Discusses several commercial reverse and domain engineering toolkits
• Slides for instructors are available online

Software Evolution and Maintenance: A Practitioner's Approach equips readers with a solid understanding of the laws of software engineering, evolution and maintenance models, reengineering techniques, legacy information systems, impact analysis, refactoring, program comprehension, and reuse.

1
BASIC CONCEPTS AND PRELIMINARIES

Another flaw in the human character is that everybody wants to build and nobody wants to do maintenance.

—Kurt Vonnegut, Jr.

1.1 EVOLUTION VERSUS MAINTENANCE

In 1965, Mark Halpern introduced the concept of software evolution to describe the growth characteristics of software [1]. Later, the term “evolution” in the context of application software was widely used. The concept further attracted the attentions of researchers after Belady and Lehman published a set of principles determining evolution of software systems [2, 3]. The principles were very general in nature. In his landmark article entitled “The Maintenance ‘Iceberg’,” R. G. Canning compared software maintenance to an “iceberg” to emphasize the fact that software developers and maintenance personnel face a large number of problems [4]. A few years later, in 1976, Swanson introduced the term “maintenance” by grouping the maintenance activities into three basic categories: corrective, adaptive, and perfective [5]. In the early 1970s, IBM called them “maintenance engineers” or “maintainers” who had been making intentional modifications to running code that they had not developed themselves. The main reason for using nondevelopment personnel in maintenance work was to free up the software development engineers or programmers from support activities [6]. In this book, we will use maintainer, maintenance engineer, developer, and programmer interchangeably.

Bennett and Rajlich [7] researched the term “software evolution” and found that there is no widely accepted definition of the term. In addition, some researchers and practitioners used the phrases “software evolution” and “software maintenance” interchangeably. However, key semantic differences exist between the two. The two are distinguished as follows:

• The concept of software maintenance means preventing software from failing to deliver the intended functionalities by means of bug fixing.
• The concept of software evolution means a continual change from a lesser, simpler, or worse state to a higher or better state ([8], p. 1).

Bennett and Xu [9] made further distinctions between the two as follows:

• All support activities carried out after delivery of software are put under the category of maintenance.
• All activities carried out to effect changes in requirements are put under the category of evolution.

In general, maintenance and evolution are generally differentiated as follows [10]:

• Maintenance of software systems primarily means fixing bugs but preserving their functionalities. Maintenance tasks are very much planned. For example, bug fixing must be done and it is a planned activity. In addition to the planned activities, unplanned activities are also necessitated. For example, a new usage of the system may emerge. Generally, maintenance does not involve making major changes to the architecture of the system. In other words, maintenance means keeping an installed system running with no change to its design [11].
• Evolution of software systems means creating new but related designs from existing ones. The objectives include supporting new functionalities, making the system perform better, and making the system run on a different operating system. Basically, as time passes, the stakeholders develop more knowledge about the system. Therefore, the system evolves in several ways. As time passes, not only new usages emerge, but also the users become more knowledgeable. As Mehdi Jazayeri observed: “Over time what evolves is not the software but our knowledge about a particular type of software” ([12], p. 3).

While we are on the topic of maintenance, it is useful to glance at the maintenance of physical systems. Maintenance of physical systems often requires replacing broken and worn-out parts. For example, owners replace the worn-out tires and broken lamps of their cars. Similarly, a malfunctioning memory card is replaced with a good one. On the other hand, software maintenance is different than hardware maintenance. In hardware maintenance, a system or a component is returned to its original good state. On the other hand, in software maintenance, a software system is moved from its original erroneous state to an expected good state [13]. Software maintenance comprises all activities associated with the process of changing software for the purposes of:

• fixing bugs; and/or
• improving the design of the system so that future changes to the system are less expensive.

1.1.1 Software Evolution

Although the phrase “software evolution” had been used previously by other researchers, fundamental work in the field of software evolution was done by Lehman and his collaborators. Based on empirical studies [2, 14], Lehman and his collaborators formulated some observations and they introduced them as laws of evolution. The “laws” themselves have “evolved” from three in 1974 to eight by 1997 [15, 16]. Those laws are the results of studies of the evolution of large-scale proprietary or closed source software (CSS) systems. The laws concern a category of software systems called E-type systems. The eight laws are briefly explained as follows:

1. Continuing change. Unless a system is continually modified to satisfy emerging needs of users, the system becomes increasingly less useful.
2. Increasing complexity. Unless additional work is done to explicitly reduce the complexity of a system, the system will become increasingly more complex due to maintenance-related changes.
3. Self-regulation. The evolution process is self-regulating in the sense that the measures of products and processes, that are produced during the evolution, follow close to normal distributions.
4. Conservation of organizational stability. The average effective global activity rate on an evolving system is almost constant throughout the lifetime of the system. In other words, the average amount of additional effort needed to produce a new release is almost the same.
5. Conservation of familiarity. As a system evolves all kinds of personnel, namely, developers and users, for example, must gain a desired level of understanding of the system’s content and behavior to realize satisfactory evolution. A large incremental growth in a release reduces that understanding. Therefore, the average incremental growth in an evolving system remains almost the same.
6. Continuing growth. As time passes, the functional content of a system is continually increased to satisfy user needs.
7. Declining quality. Unless the design of a system is diligently fine-tuned and adapted to new operational environments, the system’s qualities will be perceived as declining over the lifetime of the system.
8. Feedback system. The system’s evolution process involves multi-loop, multi-agent, multi-level feedback among different kinds of activities. Developers must recognize those complex interactions in order to continually evolve an existing system to deliver more functionalities and higher levels of qualities.

In circa 1988, Pirzada [17] was the first one to study the differences between the evolution of the Unix operating system developed by Bell Laboratories and the systems studied by Lehman and Belady [18]. Pirzada argued that the differences in academic and industrial software development could lead to differences in the evolutionary pattern. In circa 2000, after a gap of 12 years, empirical study of evolution of free and open source software (FOSS) was conducted by Godfrey and Tu [19]. The authors provided the trend of growth of the popular FOSS operating system Linux during 1994–1999. They showed the growth rate to be super-linear that is greater than linear. Robles et al. [20] later replicated the study of Godfrey and Tu and concluded that Lehman’s laws Nos. 3, 4, and 5 do not hold for large-scale FOSS systems such as Linux. These studies reveal the changing nature of both software and software development processes. Lehman’s studies mostly examined proprietary, monolithic systems developed by a team of developers within a company, whereas FOSS systems and their developments follow a different evolution paradigm.

Remark: FOSS is available to all with relaxed or nonexistent copyrights. FOSS is commonly used as a synonym for free software even though “free” and “open” have different semantics. The term “free” means the freedom to modify and redistribute the system under the terms of the original agreement, while “open” means accessibility to the source code.

1.1.2 Software Maintenance

More likely than not, there are defects in delivered software applications, because defect removal and quality control processes are not perfect. Therefore, maintenance is needed to repair those defects in released software. E. Burton Swanson [5] initially defined three categories of software maintenance activities, namely, corrective, adaptive, and perfective. Those definitions were later incorporated into the standard software engineering–software life cycle processes–Maintenance [21] and introduced a fourth category called...