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:
- Continuing change. Unless a system is continually modified to satisfy emerging needs of users, the system becomes increasingly less useful.
- 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.
- 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.
- 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.
- 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.
- Continuing growth. As time passes, the functional content of a system is continually increased to satisfy user needs.
- 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.
- 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...
