Maintenance Issues in Software Engineering

advertisement

MAINTENANCE ISSUES IN SOFTWARE ENGINEERING

Praveen Chandra Kidambi pck001@latech.edu

Department of Computer Science

Louisiana Tech University

Abstract

There is an increasing demand for significant change to software systems to meet ever-changing user requirements and specifications. Such changes include fixing errors, adding enhancements, and making optimizations. Software maintenance involves making such changes to existing software. Software maintenance is one of the significant phases in the software development life-cycle. This paper overviews software maintenance, its relevance, problems encountered while maintaining software, and the available solutions to these problems. The importance of software maintenance in the software development process is highlighted, mentioning benefits of software maintenance and problems faced when the same is not implemented effectively.

Introduction

In the early days of computing, software maintenance was only a small part in the software life cycle. As the years went by, more and more software was produced, showing the fact that software does not die simply. Most of the new software produced was based on earlier versions which resulted in recognition of maintenance as a major activity. In the 1980s, it was evident that old architectures were severely constraining new designs, and hence software maintenance was taking more effort than initial development in some sectors.

Software maintenance is defined as

“the process of modifying a software system or component after delivery to correct faults, improve performances or other attributes, or adapt to a changed environment”

[1]. The maintenance phase in software development is generally considered as a post-delivery activity – it starts when the system is released to the customer or when the system becomes operational. However, several maintenance engineers believe that software maintenance should start well before a system becomes operational in order to make maintenance fairly easier. Considering software maintenance as a post-delivery activity is one of the reasons that make maintenance hard.

Therefore, keeping in mind that maintenance actually starts from the pre-delivery stage of software development, software maintenance is also defined as

“the totality of activities required to provide cost-effective support to a software system. Activities are performed during the pre-delivery stage as well as the post-delivery stage. Pre-delivery activities include planning for post-delivery operations, supportability, and logistics determination.

Post-delivery activities include software modification, training, and operating a help desk” [2].

Maintenance of a software system should be carried out in a careful manner so as to increase the maintainability of that system.

“Software maintainability is the ease with which software can be understood, corrected, adapted and enhanced”

[1].

1

Categories of software maintenance

Software maintenance activities can be broadly divided into the following four standard categories [1]:

Corrective maintenance: Corrective maintenance involves correction of discovered faults and errors after the software has been delivered to the customer. The expenses involved in corrective maintenance are always bore by the supplier.

Adaptive maintenance: Adaptive maintenance involves modifications to the software required by changes in the operating environment such as operating system upgrades etc.

The customer and the supplier share the cost for this maintenance activity.

Perfective maintenance: Perfective maintenance involves modification of a software product performed after delivery to improve performance or maintainability. The cost of this maintenance activity is shared by the supplier and the customer depending on the contract between them.

Preventive maintenance: Preventive maintenance may be undertaken on a system in order to anticipate future problems and make subsequent maintenance easier.

Apart from the four categories mentioned above, other categories are also defined by some sources as follows:

Emergency maintenance: Emergency maintenance is the unscheduled corrective maintenance performed to keep a system operational.

Enhancements: Software enhancements include addition of new features or functionalities to an existing system. Adequate planning is necessary to determine the new features to be added so as to protect the system from degrading in the long run. The funding for enhancements almost always comes from the customer.

Costs and challenges of software maintenance

Software maintenance accounts to a majority amount of the overall software development budget. Several surveys indicate that software maintenance consumes 60% to 80% of the total life cycle costs. These surveys also show that a significant amount of maintenance costs are due to software enhancements rather than corrections.

Most problems that are associated with software maintenance can be traced to deficiencies of the software development process. Generally in the software engineering process, the development part of the software is done by a software engineer who may not contribute to the maintenance part. Here, the maintenance engineer, responsible for maintaining the software or application, has to get acquainted with the detailed design, relevant documentation, functioning of the source code etc. Also, the estimation of maintenance cost and effort is a very important part of the planning process since maintenance costs amount for a significant portion of the overall software development life-cycle cost. Also, estimate of maintenance effort helps to plan adequate maintenance staff.

There are several technical and managerial problems encountered while maintaining software. The problems [2] that are more challenging and which contribute significantly to the costs of software maintenance are:

2

Program Comprehension: To maintain a piece of software, which involves changing and adding new features to the software, a thorough understanding of the structure, functionality and behavior of the system being modified should be gained by the maintenance engineer. Modification proposals to accomplish the objectives of maintenance can be generated only when the attributes of system mentioned above are understood. Hence, considerable amount of time should be spent by maintenance engineers to read and understand the code, the relevant documentation to have a better perspective on its logic, purpose and structure.

Impact Analysis: The impact that a process of changing a piece of software can have on the rest of the system is analyzed. This is a major challenge faced in the maintenance phase to determine the effects of a proposed modification on other parts of the system.

The task involves assessing the appropriateness of a proposed modification and evaluating the risks associated with its implementation, including estimates of the effects on resources, effort and scheduling. It also involves the identification of the system’s parts that need to be modified as a consequence of the proposed modification.

Regression Testing: The process of testing a system after it has been modified is called regression testing. This type of testing is necessary to confirm that the system is free of any errors after it has been modified and also to ensure that the rest of the system has not been affected by the modification of the piece of software that was intended to be changed. Regression testing differs from the testing performed during development because a set of test cases may be available for reuse.

Maintenance Activities

Several activities are performed in the maintenance phase depending on the user requirements or problems or errors present in the existing system. Some of the activities

[3] are described below:

Defect Repairs: Defect repairs are undertaken when a system has to be kept in operation after a crash occurs in a system. The expense for defect repairs is covered by the software group that built the software application. A crash or an error is bound to occur in a system making defect repairs unavoidable. Estimation of defect repairs is determined by the following factors: a) Abeyant defects: This type of defects is based on some unique combination of events. Software maintainers, sometimes, cannot make the same problem to occur in order to find the defect. Hence the costs for finding and repairing such type of defects are more expensive than doing the same for normal defects. Also, the time consumption in the process of finding and repairing abeyant defects is significantly more. b) Invalid defects: Some of the defects which are reported by the clients are not caused by the software which has been developed by the software team. Rather, these defects are caused by hardware failure on the client’s end, by other software used by the client or simply when the client himself has made a mistake.

3

c) Bad fix injection: Repairing a defect may result in creation of a new defect. This type of defects is surprisingly common. These defects occur due to a bad fix. Bad fixes can be avoided if the repairs are performed carefully and if the application itself is well structured making maintenance repairs easier. d) Duplicate defects: Multiple users may report the same defect which can be fixed only once. However, a lot of customer-support time is devoted to dealing with these duplicates.

Error-prone Module Removal: A large number of software bugs may be present in a system which may not be randomly distributed in the system. Most of these bugs may be present together in portions called error-prone modules. These modules are difficult to maintain as they may never be removed because of bad fix injections that may occur when trying to fix them. Maintenance of error-prone modules demands high cost.

Customer Support: The communication between the customer and the defect repair team is done under customer support. This communication is mostly initialized by the customer when he/she comes across a problem in the software. The customer support team notifies the maintenance team to fix the problem stated by the customer.

Code restructuring: Code restructuring is used to make maintenance easy. If the code for a software is too complex and may generate errors in the future, then the code has to be modified to make it simpler so that the software in turn out to be a well-structured one which reduces the chances of generating defects or errors.

Migration across platforms: This activity may be classified under the adaptive maintenance process. Migration projects involve moving an application from one platform to another. Commercial organizations usually implement migration projects in order to expand markets by expanding the platform on which the software works.

Conversion to new architectures: An application may need to be converted into another form in order to interface with a different file structure or database. Conversion projects may be very beneficial to the users since the software system will expand and be compatible with various system architectures.

Performance optimization: When a system has to perform high transaction applications, care has to be taken to minimize delays in transactions. This is done by optimizing projects by finding out the sections of the system which slow down processing.

Enhancements: Enhancements to existing software are done upon request from the user and hence are funded by the user. Enhancements include addition of new features to the software. Enhancements are classified into major enhancements and minor enhancements depending upon the extent to which the software is modified.

4

Maintenance Process Models

There are some general models [4] in the software maintenance process which are discussed below:

Quick-fix model: This model captures the need to concentrate on code first before making the necessary changes in the accompanying documentation. Ideally, after the code has been changed the requirement, design, testing and any other form of available documents impacted by the modification should be updated.

Evolutionary life cycle model: These models suggest that a system should be individually developed in builds such that each of these builds completes, corrects, and refines the requirements of previous builds taking feedback of users in consideration. An example of the Evolutionary life cycle model is iterative enhancement according to which design and implementation of successively larger solutions can be eased by structuring a problem. The construction of a new build stated in this model begins with the analysis of the existing system’s requirements, code and accompanied documentation. In other words, the system is redesigned based on an analysis in the evolutionary life cycle. The main advantage of the iterative enhancement method is that as the code is modified the accompanying documentation also gets updated.

Full-reuse model: In the full re-use model, analysis of requirements and design of the new modified system is done. Also taken into consideration are the appropriate requirements, design, code and tests of the earlier versions of the existing system.

However, the iterative enhancement starts with the analysis of the existing system, which is the major difference with the full-reuse model. To implement the full-reuse model, the documentation relating to previous versions of the existing system has to be stored for reference.

Each of the models mentioned above have their own advantages/disadvantages and are suited for various types of systems. For example, Canfora[2] compares the quick-fix model with the iterative enhancement model and concludes that maintenance changes are done faster when implementing the iterative enhancement model. Also, the maintainability degrades faster when the quick-fix model is used. However, quick-fix model can be used when time is a factor in the maintenance process. The iterativeenhancement model is well suited for systems that have a long life and evolve over time; it supports the evolution of the system in such a way to ease future modifications. On the contrary, the full-reuse model is more suited for the development of lines of related products. It tends to be more costly on the short run, whereas the advantages may be sensible in the long run; organizations that apply the full-reuse model accumulate reusable components of all kinds and at many different levels of abstractions and this makes future developments more cost effective.

Process models – Phases in software maintenance

Various sources have described process models for software maintenance. In these models, maintenance is divided into activities or phases. The order in which these phases have to be executed is also defined. Most of the time, these phases are interconnected which means that some phases have to provide deliverables to the next phases that

5

follow. Dividing the maintenance process into phases or activities is very important for the process to be successful. Both the IEEE and ISO have defined their own set of phases that are implemented in the maintenance process.

The phases that are defined by the IEEE standard [3] are as follows:

1.

Problem or modification identification: In this phase, the customer or the user sends in the request for change (also known as modification request – MR). The phase also includes decisions on whether to accept or reject the request sent from the customer.

2.

Analysis: The overall maintenance plan is sketched out which includes the design, implementation and test of the system to be modified. Also analyzed in this phase are the alternative solutions, if any, for modifying the system in an efficient way, keeping the cost and other impacts in mind.

3.

Design: The changes or the modifications that have to be made to the existing system are designed in this phase. The input to this phase is the result of the analysis phase and also the details of the existing system which includes the appropriate documentation.

4.

Implementation: This phase includes activities involving coding, implementation, testing, integration of modified code, analysis of risks etc.

5.

Regression/system testing: After the modifications are made to the existing system, tests are conducted on the new system to ensure that the new system is free of any errors and also to monitor whether the new system has met its new specifications.

6.

Acceptance testing: This type of testing involves the customers or the end users to use the system and point out errors, if any, which would be reported to the maintenance team, in order to make further changes.

7.

Delivery: The modified system is released to the customer in this phase.

Maintenance management

Management, in general, can be defined as “the process of designing and maintaining an environment in which individuals, working together in groups, accomplish efficiently selected aims” [2]. Management consists of five functions which are as follows:

1.

Planning: Determining the appropriate actions that have to be taken and setting objectives for these actions is done in the planning function. Allocation of adequate resources is also considered in this function.

2.

Organizing: Roles and responsibilities are assigned to personnel in this function.

3.

Staffing: Adequate training is given to the selected people in order to improve their knowledge and skills.

4.

Leading: The maintenance phase is generally considered to be an uninteresting phase to most software maintainers. Hence, some kind of motivation is required to morally boost the personnel responsible for maintenance. Leading is creating a work environment that will assist and motivate people.

5.

Controlling: Monitoring performance, measuring planned goals and controlling maintenance staff is implemented.

6

Maintenance organizations

Particular care must be taken to plan the transition of a system from the development team to the maintenance organization which is a very critical element of the life cycle of a software system. There are three types of organizational structures which are designed and set up by maintenance organizations:

Functional organizations: These types of organizations are hierarchical in nature and are broken down into different functional units. The main weakness with this organization is the lack of central point of responsibility in the middle level of the hierarchy. A single point of responsibility is present at the highest level of the hierarchy, making the individual functions focus only on their goals rather than on the overall objective of the project.

Project organizations: Project organizations, on the other hand, have managers responsible for each function into which the organization is divided. All the necessary resources are acquired by the manager for his/her project team. Advantage of this type of organization is good control over the project team and quick decision making. However, starting a team takes considerable amount of time and also, resources may be inefficiently used.

Matrix organizations: These types of organizations are a mixture of functional organizations and project organizations. There may be one or more managers assigned to an individual project team which results in a person responding to multiple managers.

This may lead to conflicts and ambiguity in plans stated by the managers for a single project.

There are two popular areas related to software maintenance. The two processes that are frequently used in the maintenance phase are:

1. Reverse Engineering and 2. Reengineering

Reverse Engineering

Reverse engineering involves the identification or recovery of program requirements and/or design specifications that can aid in understanding and modifying the program [7]. The objective of reverse engineering is to study the underlying features like requirements, design etc. of a software system or recover and record critical information about the system. The system information may include the following: the system structure, the system’s functionality, the dynamic behavior of the system, the design process of the system, the construction, modules, documentation, and the test suites of the system.

The purposes for undertaking reverse engineering process are separated into different issues as follows:

Quality issues which include simplification of complex software, removing errors from software thus increasing the quality of the software.

Management issues which include increase in programming standard and to implement better software maintenance techniques.

7

Technical issues which include making major changes in a piece of software to be implemented and to discover and record the design of the system.

Reverse engineering is very important for the rest of the maintenance process including reengineering. Reverse engineering recovers abstract representation of the existing software system which has to be reengineered. This representation can be useful for subsequent reengineering or even reimplementation. When using reverse engineering, the following problems have to be solved:

Source code may be poorly structured and relevant documentation may be out of date.

Design specifications may be incomplete.

Existing system may be developed with inconsistent principles resulting in the difficulty to extract sufficient information.

Re-engineering

Re-engineering is defined as “the examination and alteration of a subject system to reconstitute it in a new form and the subsequent implementation of the new form” [2].

Reengineering can also be defined as “any activity that: improves one’s understanding of software, or prepares or improves the software itself, usually for increased maintainability, reusability, or evolvability” [2].

Reengineering involves implementing various techniques in analyzing and redesigning an existing system from the extracted information by the reverse engineering process. Reengineering tries to regenerate the abstract view of the system after which the forward engineering activities realize the system into new form.

Figure: Reverse Engineering, Reengineering and Forward Engineering [Source 7]

(Processes implemented in the Software maintenance phase)

The reverse engineering process extracts elements and important information from an existing system. The reengineering process uses this extracted information for analysis

8

and redesign and tries to identify the components that have to be reused and the parts that need to be redesigned or replaced. After the final design has been created in the reengineering process, the forward engineering process takes over in implementing this design and finally testing the new modified system.

Conclusion

The overviews of software maintenance, its related problems have been discussed in this paper. The significance of maintenance phase in the software development life cycle has been discussed, highlighting the fact that maintenance contributes to a large extent in the software engineering process. The modern software systems, which are built at present, are subject to change in near future. This demands the need for maintenance to upgrade these systems to meet ever-increasing user requirements and also, to be compatible with the latest technologies available. As the software systems grow in size, age and complexity, their maintenance also becomes complex requiring combined efforts of groups of software engineers. As a result, maintenance is considered as an individual phase in the software development process. The assumption that maintenance phase is a post-delivery activity has been erased. With the emerging maintenance process models and extensive use of processes like reverse engineering and reengineering, software maintenance is considered as both a pre-delivery and a post-delivery activity. Extensive planning is needed for maintenance, starting from the development stage of software life cycle.

References

[1] Successful Evolution of Software Systems by Hongji Yang and Martin Ward; Boston

Artech House, Inc.,2003.

[2] Software Maintenance by Gerardo Canfora and Aniello Cimitile (University of

Sannio), Nov. 2003.

[3] Estimating Software Maintenance by Arun Mukhija (University of Zurich), Jan. 2003

[4] Advances in Software Maintenance Management: Technologies and Solutions by

Macario Polo et al; Hershey, PA Idea Group Publishing, 2003.

[5] Fundamental Laws and Assumptions of Software Maintenance by Adam Porter

(University of Maryland), 1997.

[6] Web: http://www.utdallas.edu/rbanker/Mgtsci4p.pdf

[7] Reengineering and Reengineering Patterns by Daniel Gjorwell et al, 2002.

9

Download