Software Maintenance in Software Engineering

Over a period of time, the developed software system may need modifications according to the changing user requirements. Such being the case, maintenance becomes essential. The software maintenance process comprises a set of software engineering activities that occur after the software has been delivered to the user.

Sometimes, maintenance also involves adding new features and functionalities (using latest technology) to the existing software system. The primary objective of software maintenance is to make the software system operational according to the user requirements and fix errors in the software. The errors arise due to nonfunctioning of the software or incompatibility of hardware with the software. When software maintenance is to be done on a small segment of the software code, software patches are applied. These patches are used to fix errors only in the software code that contains errors.

Software maintenance is affected by several constraints such as increase in cost and technical problems with hardware and software. This chapter discusses how software maintenance assists the present software system to accommodate changes according to the new requirements of users.

Basics of Software Maintenance

Software does not wear out or get tired. However, it needs to be upgraded and enhanced to meet new user requirements. For such modifications in the software system, software maintenance is performed. IEEE defines maintenance as ‘a process of modifying a software system or component after delivery to correct faults, to improve performance or other attributes or to adapt the product to a changed environment.’ The objective is to ensure that the software is able to accommodate changes after the system has been delivered and deployed.

To understand the concept of maintenance properly, let us consider an example of a car. When a car is ‘used’, its components wear out due to friction in the mechanical parts, unsuitable use, or by external conditions. The car owner solves the problem by changing its components when they become totally unserviceable and by using trained mechanics to handle complex faults during the car’s lifetime. Occasionally, the owner gets the car serviced at a service station. This helps in preventing future wear and tear of the car. Similarly, in software engineering the software needs to be ‘serviced’ so that it is able to meet the changing environment (such as business and user needs) where it functions. This servicing of software is commonly referred to as software maintenance, which ensures that the software system continues to perform according to the user requirements even after the proposed changes have been incorporated. In addition, software maintenance serves the following purposes.

1.   Providing continuity of service: The software maintenance process focuses on fixing errors, recovering from failures such as hardware failures or incompatibility of hardware with the software, and accommodating changes in the operating system and the hardware.

2.    Supporting mandatory upgrades: Software maintenance supports upgradations, if required, in a software system. Upgradations may be required due to changes in government regulations or standards. For example, if a web-application system with multimedia capabilities has been developed, modification may be necessary in countries where screening of videos (over the Internet) is prohibited. The need for upgradations may also be felt to maintain competition with other software that exist in the same category.

3.    Improving the software to support user requirements: Requirements may be requested to enhance the functionality of the software, to improve performance, or to customize data processing functions as desired by the user. Software maintenance provides a framework, using which all the requested changes can be accommodated.

4.     Facilitating future maintenance work: Software maintenance also facilitates future maintenance work, which may include restructuring of the software code and the database used in the software.

Changing a Software System

As stated earlier, the need for software maintenance arises due to changes required in the software system. Once a software system has been developed and deployed, anomalies are detected, new user requirements arise, and the operating environment changes. This means that after delivery, software systems always evolve in response to the demands for change.

The concept of software maintenance and evolution of systems was first introduced by Lehman, who carried out several studies and proposed five laws based on these studies. One of the key observations of the studies was that large systems are never complete and continue to evolve. Note that during evolution, the systems become more complex, therefore, some actions are needed to be taken to reduce the complexity. The five laws stated by Lehman are listed in Table and discussed below.

1.     Continuing change: This law states that change is inevitable, since systems operate in a dynamic environment, as the systems’ environment changes, new requirements arise and the system must be modified. When the modified system is re-introduced into the environment, it requires further modifications in the environment. Note that if a system remains static, after a period of time it will not be able to serve the users’ ever-changing needs. This is because the system may become outdated after some time.

2.    Increasing complexity: This law states that as a system changes, its structure degrades (often observed in legacy systems). To avoid this problem, preventive maintenance should be used, where only the structure of the software is improved without adding any new functionality to it. However, additional costs have to be incurred to reverse the effects of structural degradation.

3.     Large software evolution: This law state~ that for large systems, software evolution is largely dependent on management decisions because of organizational factors, which are established earlier in the development process. This is true for large organizations, which have their own internal bureaucracies that control the decision-making process. The rate of change of the system in these organizations is governed by the organization’s decision-making processes. This determines the gross trends of the system maintenance process and limits the possible number of changes to the system.

Organizational stability: This law states that changes to resources such as staffing have unnoticeable effects on evolution. For example, productivity may not increase by assigning new staff to a project because of the additional communication overhead. Thus, it can be said that large software development teams become unproductive because the communication overheads dominate the work of the team.

4.      Conservation of familiarity: This law states that there is a limit to the rate at which new functionality can be introduced. This implies that adding a large increment of functionality to a system in one release, may certainly introduce new system faults. If a large increment is introduced, a new release will be required ‘fairly quickly’ to correct the new system faults. Thus, organizations should not budget for large functionality increments in each release without taking into account the need for fault repair.

                                                      Table Lehman Laws

Lehman’s observations have been accepted universally and are taken consideration when planning the maintenance process. However, it may be that one of the laws is ignored when some particular business decision is For example, it may be mandatory to carry out several major system changes in a single release for marketing and sales reasons.

Legacy System

The term ‘legacy system’ describes an old system, which remains in operation within an organization. These systems were developed according to the ‘dated development practice’ and-technology existing before the introduction of structured programming. Process models and basic principles such as modularity, coupling, cohesion, and good programming practice emerged too late for them. Thus, these systems were developed according to ad hoc processes and often used programming techniques, which were not amenable for developing large systems.  The combination of employing dated processes, techniques, and technology resulted in undesirable characteristics in legacy systems, which are listed in Table.

                                       Table Legacy System Characteristics

Legacy systems are generally associated with high maintenance costs. The root cause of this expense is the degraded structure that results from prolonged maintenance. Systems with contrived structures are invariably complex and understanding them requires considerable effort. System understanding (a prerequisite for implementing changes) is particularly expensive, as it relies on individuals grasping a sufficient depth of understanding of the system.

Legacy systems were not designed to accommodate changes. This is because of the following reasons.

1.   Short lifetime expectancy: At the time of their commission, it was not anticipated that legacy systems would be used for so many decades.

2.   Failure of process models to treat evolution as an important activity: Evolution requirements, for example, can be extracted from business goals, but according to traditional practice, future requirements are largely ignored during the specification phase of the development.

3.   Constraints present at the time of development: When legacy systems were developed, the memory and processing power were limited that constrained the software design decisions. Techniques were used to make efficient use of these resources, but at the expense of maintainability it has been observed that to develop ‘long-lived’ software systems, ease of maintainability is a prerequisite.

Often organizations face a dilemma known as legacy dilemma, which states that ‘a legacy system, which is business critical, must remain operational, in some form, within its organization. However, continued maintenance of the system is expensive and the scope for effectively implementing further change is heavily constrained. Moreover, the costs of replacing the system from scratch are prohibitively high.’

The Components of a Legacy System

The ‘evolveability’ of a legacy system is determined by the parts that constitute the legacy system.

These parts can be categorized as given here.

1.    Business: Represents a business perspective of legacy systems. Business goals are the long-term objectives for an organization, which heavily influence the evolveability of a legacy system. Business goals generate future requirements for the software systems that support the business. Note that if the business goals are thorough in nature, it is difficult to implement the changes. Also, thorough changes can only be accommodated after extensive rework.

2.   Organizational: Includes both the development and operational organizations involved with the legacy system. The development organization is responsible for maintaining the system. Note that it is difficult to evolve a system if the individuals who mail1.tained the system retire or when poor documentation exists. The operational organization is the organization which is supported by the legacy system. That is, a legacy system provides services to its operational organization. An organization’s attitude to change affects the system’s evolveability. For example, workforces in some organizations are unwilling to accept change if it is imposed by the senior management.

3.    Technical: Categorizes the legacy system into application software, system software, and hardware. When a system’s hardware is no longer supported, it would be wise to replace the hardware instead of investing further. Also, the condition and quality of application software (including its documentation) is a significant factor in determining how a legacy system can evolve. For example, a contrived software architecture, or inconsistent documentation implies that the system cannot evolve readily.

Software Maintenance Prediction

Since unexpected maintenance costs may lead to an unexpected increase in costs, it is important to predict the effect of modifications in the software system. Software maintenance prediction refers to the study of software maintainability, the modifications in the software system, and the maintenance costs that are required to maintain the software system. Various maintenance predictions and the questions associated with them.

Various predictions are closely related and specify the following.

1.     The decision to accept a system change depends on the maintainability of the system components affected by that change up to a certain extent.

2.    Implementation of changes results in degradation of system structure as well as reduction in system maintainability.

3.     Costs involved in implementing changes depend on the maintainability of the system components.

To predict the number of changes requested for a system, the relationship between the system and its external environment should be properly understood. To know the kind of relationship that exists, organizations should assess the following.

1.     Number and the complexity involved in the system interface. More interfaces mean more complexity, which in turn means more demand for change.

2.   Number of system (volatile) requirements. Changes required in organizational policies and procedures tend to be more volatile than the requirements based on a particular domain.

3.    Number of business processes in which the system operates. More business processes implies more demands for system change.

To predict maintainability of a software system, it is important to consider the relationship among the different components and the complexity involved in them. Generally, it is observed that a software system having complex components is difficult and expensive to maintain. The complexity in a software system occurs due to the size of procedures and functions, the size and the number of modules, and the nested structures in the software code. On the other hand, a software system developed by using good programming practices reduces not only the complexity but also the effort required in software maintenance. As a result, such software systems minimize the maintenance cost. For maintaining the individual components in software systems, it is essential to identify the complexity measurements of components.

After a system has been put into operation, several process metrics are used to predict the software maintainability. Process metrics, which may be useful for assessing maintainability, are listed below.

1.     Corrective maintenance: Sometimes, more errors are introduced rather than being repaired during the maintenance process. This shows decline in maintainability.

2.  Average time required for impact analysis: Before starting the software maintenance process, it is essential to analyze the impact of modifications in the software system. This is known as impact analysis, which reflects the number of components affected by the change.

3.   Number of outstanding change requests: If the number of outstanding change requests increases with time, it may imply decline in maintainability.

4.   Average time taken to implement a change request: This involves activities· concerned with making changes to the system and its documentation rather than simply assessing the components which are affected. If the time taken to implement a change increases, it may imply a decline in maintainability.

Factors Affecting Software Maintenance

Many factors directly or indirectly lead to high maintenance costs. A software maintenance framework is created to determine the affects of these factors on maintenance. This framework comprises user requirements, organizational and operational environment, maintenance process, maintenance personnel, and the software product (see Table). These elements interact with each other based on three kinds of relationships, which are listed below.

                    Table Components of Software Maintenance Framework

1.    Relationship of software product and environment: In this relationship, the software product changes according to the organizational and operational environment. However, it is necessary to accept only those changes which are useful for the software product.

2.      Relationship of the software product and user: In this relationship, the software product is modified according to the new requirements of users. Hence, it is important to modify the software that is useful and acceptable to users after modification.

3.   Relationship of software product and software maintenance team: In this ‘relationship, the software maintenance team members act as mediators to keep track of the software product. In other words, the software maintenance team analyzes the modifications in other elements of software maintenance framework to determine their effect on the software product. These elements include user requirements, organizational and operational environments, and the software maintenance process. All these elements affect the modifications in software and are responsible for maintaining software quality.

Generally, users have little knowledge of the software maintenance process due to which they can be unsupportive to the software maintenance team. Also, users may have some misconceptions such as software maintenance is like hardware maintenance, changing software is easy, and changes cost too much and are time consuming.

If user requirements need major changes in the software, a lot of time may be consumed in implementing them. Similarly, users may opt for changes that are not according to the software standards or policies of a company. This situation creates a conflict between users and the software maintenance team.

To implement user requirements in software, the following characteristics should be considered.

1.         Feasible: User requirements are feasible if the requested change is workable in the software system.

2.         Desirable: Before implementing new changes, it is important to consider whether the user modification request is necessary.

3.     Prioritized: In some cases, the user requirements may be both feasible and desirable. However, these requirements may not be of high priority at that time. In such a situation, the user requirements can be implemented later.

The working of software is affected by two kinds of environments, namely, organizational environment and operational environment. The organizational environment includes business rules, government policies, taxation policies, work patterns, and competition in the market. An organization has its own business rules and policies, which should be incorporated in the software maintenance process. The operational environment includes software systems (such as operating systems, database systems, and compilers) and hardware systems (such as processor, memory, and peripherals).

In both the environments, scheduling of the maintenance process can create problems. The scheduling is affected by various factors such as urgent requirement of the modified software, allocation of less amount of time to modify the software, and the lack of proper knowledge on how to implement user requirement in software.

Changes are implemented in the software system by following the software maintenance process (also known as software maintenance life cycle). The facets of a maintenance process which affect the evolution of software or contribute to high maintenance costs are listed below.

1.    Error detection and correction: It has been observed that error-free software is virtually non-existent. That is, a software product tends to contain some kind of ‘residual’ errors. If these errors are uncovered at a later stage of software development, they become more expensive to fix. The cost of fixing errors is even higher when errors are detected during the maintenance phase.

2.     Difficulty in capturing change (and changing) requirements: Requirements and user problems become clear only when a system is in use. Also users may not be able to express their requirements in a form, which is understandable to the analyst or programmer.

3.     Software engineering paradigm shift: Older systems that were developed prior to the advent of structured programming techniques may be difficult to maintain.

Software Product

The software developed for users can be for general use or specific use. For example, MSOffice is a software application that is generic in nature and may be used by a wide range of people. On the other hand, the payroll system may be customized according to the needs of the organization. However, the problem occurs when software is to be maintained. Generally, the aspects of a software product that contribute to the maintenance cost/ challenge are listed below.

1.   Difficulty of the application domain: The requirements of applications that have been widely used and well understood are less likely to undergo substantial modifications than those that have been recently developed.

2.   Inflexibility in programs: While modifying software, it should be checked for the flexibility of change and reuse. This is because the inflexible software products are more prone to failures.

3.   Quality of the documentation: Documentation is essential for understanding the requirements, software design, and how these requirements are converted into the software code. The unavailability of up-to-date systems documentation affects maintenance productivity adversely.

Software Maintenance Team

The group of individuals responsible for the software maintenance is referred to as the software maintenance team, which mayor may not comprise the development team that ‘built’ the software. Often, a separate maintenance team (comprising analysts, designers, and programmers) is formed to ensure that a system performs its functions properly. This team is employed as it has been observed that generally developers do not keep documentation up-to-date, leading to the need of more individuals or resources to tackle a problem. This results in a long time-gap between the time when a problem occurs and when it is fixed.

Various functions performed by the software maintenance team are listed below.

1. Locating information in system documentation
2. Keeping system documentation up-to-date
3. Improving system functionalities to adapt new environment
4. Enhancing system to perform new functions according to the user’s needs
5. Detecting root cause of failures, if any
6. Handling changes made to the system.

The aspects of a maintenance team that lead to high maintenance costs are listed below.

1.     Staff turnover: Generally, it is observed that when the staff turnover (the ratio of number of individuals that leave the organization during a specified period of time) is high, the software maintenance is not performed properly. This is because employees who originally worked on software products are replaced by new personnel who spend a substantial proportion of the maintenance effort in understanding the system.

2.   Domain expertise: Sometimes, the maintenance team may have little or no knowledge about the system domain and the application domain they are working in. This problem is worsened if documentation is not maintained or is not up-to-date. All this may lead to delay in implementing the changes requested by the user.