DIRECTORATE OF CORRESPONDENCE COURSES
KURUKSHETRA UNIVERSITY
KURUKSHETRA
Master of Computer Applications (Part-II)
Paper No. MCA-DE-26 Writer: Sh. Rakesh Kumar
Lesson No. 8 Vetter: Dr. Ashok Kumar
Software Maintenance
The term software maintenance is used to describe the activities that occur following delivery of a software product to the customer. The maintenance phase of the system life cycle is the time period in which a software product performs useful works. Typically the development cycle for a system spans 1 to 2 years, while the maintenance phase spans 5 to 10 years.
In common speech, the term maintenance means to fix things that break or wear out. In software there is no wear and tear; it is either wrong from the beginning or we decide later that we want to do something different.
Maintenance activities involve making enhancement to system, adapting products to new environments, and correcting problems. Because changes are inevitable, a mechanism must be developed for evaluating, controlling and making modifications. The purpose of software maintenance is to preserve its value over time by enhancing the customer base, meeting additional requirements, making it easier to use and more efficient and employing newer technology.
Categories of Maintenance:
There is no reason to assume that changes will not be there. As the specification of computer system changes, external world changes, so must the system themselves. There are three different categories of software maintenance with very blurred distinctions between them:
1. Corrective maintenance:
It is evident that it is virtually impossible to detect all the errors during the testing phase of the software. Those errors may occur during the operational use of the software. So corrective maintenance is concerned with fixing reported errors in the software. Coding errors are relatively cheap to correct. Design errors are more expensive as they may involve the rewriting of the several program components. Requirement errors are most expensive to repair because of the extensive system redesign, which may be necessary.
In the event of system failure due to an error, actions are taken to restore operations of the software system. Due to the management pressure, sometime maintenance personnel use the emergence fix instead of following the proper maintenance process that results in an increased complexity of software and unforeseen ripple effects (i.e. a change in one part of a program may affect other sections of the software). This is often due to lack of time to carry out a thorough impact analysis before effecting the change.
2. Adaptive maintenance:
Changes in the environment are inevitable. So whenever the environment changes, the software are to be modified to adapt it according to the environment. So adaptive maintenance means changing the software to some new environment such as a different hardware platform or use with a different operating system. The software functionality does not radically change. This type of maintenance includes any work initiated as a consequence of moving the software to a different hardware or a software platform-compiler, operating system or a new processor.
3. Perfective maintenance
Perfective maintenance activities involve making enhancements to software products i.e. implementing new functional or non-functional system requirements, improving user displays and modes of interaction, upgrading external documents and internal documentation, or upgrading the performance characteristics of the system. These requirements are generated by software customers as their organization or business changes.
4. Preventive maintenance:
There are long term effects of corrective, adaptive and perfective maintenance. This leads to increase in the software complexity, which reflects deteriorating structure. The work is required to be done to maintain it or to reduce it, if possible. This work may be termed as preventive maintenance. These activities include code restructuring,. Code optimzation, and documentation updating. The intention of these activities is to make program easier to understand and hence facilitating future maintenance. Due to a number of changes in the software the complexity of the source code can increase to an unmanageable level, so a complete restructuring of the code is required. Code optimization is performed to enable the program to run faster or to make more efficient use of storage. Updating user and system documentation is often necessary when any part of software is changed. The documents affected by the change should be modified to reflect the current state of the system.
It is well established that maintenance activities consume a large portion of the total life cycle budget. It is not uncommon for software maintenance to account for 70 percent of total system life cycle costs (with development requiring 30 percent). As a general rule of thumb, the distribution of effort for software maintenance includes 60 percent of the maintenance budget for enhancement, 20 percent each for adaption and correction.
It id difficult to find up-to-date figures for the relative efforts devoted to these different types of maintenances. A survey by Lientz and Swanson discovered that about 65% of maintenance was pefective, 18% adaptive and 17% corrective as shown in the above figure.
If maintenance consumes 70 percent of the total life-cycle effort devoted to a particular software product, and if 60 percent of maintenance goes to enhancing the product, then 42 percent of the total life-cycle effort for that product is dedicated to product enhancement. Given this pespective, it is apparent that the product delivered to the customer at the end of the development cycle is only the initial version of the system. Some authors have suggested that the appropriate life-cycle model for software is development ->evolution -> evolution -> evolution …*
Problems during Maintenance
This perspective makes it apparent that the primary goal of development should be production of maintainable system. The high cost of the maintenance is due to a number of problems listed below:
1. Maintenance is not as rewarding as exciting as developing systems. It is perceived as requiring neither skill nor experience.
2. Users are not fully cognizant of the maintenance problem or its high cost.
3. Few tools and techniques are available for maintanence.
4. A good test plan is lacking.
5. Standards, procedures and guidelines are poorly defined and enforced. The programs being maintained may have been developed many years ago without modern techniques. They may be unstructured and optimized for efficiency rather than understandability.
6. Maintenance is viewd as a necessary evil, often devegated to junior programmers. There is particularly no maintenance manager job classification in the MIS field.
7. Programs are often maintained without care for structure and documentation. As a system is changed, its structure tends to degrade. This makes the system harder to understand and make further changes difficult as the programs become less cohesive.
8. There are minimal standards for maintenance.
9. Programmer expects that they will not be in their current commitment by the tie their programs go into the maintenance cycle.
10. Changes made to a program may introduce new faults, which trigger further change requests. New faults may be introduced because the complexity of the system may make it difficult to assess the effects of a change.
11. The links between a program and its associated documentation are sometimes lost during the maintenance process. The documentation may therefore be an unreliable aid to program understanding.
Possible solutions to maintenance problems:
A number of possible solutions have been suggested to maintenance problems. Such as
(1) Budget and effort reallocation.
(2) Complete replacement of existing system
(3) Enhancement of existing system.
It is suggested that more time and resources should be invested during development and hence making the system more maintainable rather than allocation the resources to maintain a difficult to maintain system. If the cost of maintenance is too high, it is better to replace it by a new system but the cost and risk associated with complete system replacement are very high which is not a viable option sometimes. So sometimes a better approach is to maintain existing system. The current system may need to have the potential to evolve to a higher state, providing more sophisticated user-driven functionalities, the capability of developing cutting edge technology and of allowing the integration of other systems in a cost-effective manner.
The maintenance process:
The maintenance process is triggered by a set of change request from system users, managers or customers. Once maintenance objective is established, the maintenance personnel must first understand what they are to modify. Then they must modify the program to satisfy the maintenance objectives. The cost and impact of these changes are assessed. If the proposed changes are accepted, a new release of the system is planned. This release will usually involve elements of adaptive, corrective and perfective maintenance. The changes are implemented and validated and a new version of the system is released. An overview of the maintenance process is given below:
Software Maintenance process (An overview)
In some system, to keep it functional every time is utmost necessary. So there is a lot of management pressure on the maintenance personnel. Change requests sometimes relates to system problems that must be tackled urgently. For example a fault in the system may have to be quickly remedied to allow normal business to continue. In this type of situation, it is difficult to follow the normal maintenance process. At that time the maintenance process will be as follows:
The Fault Repair Process
This emergency repair approach is sometimes necessary if the reported problems affect system availability. However, the danger of this approach is that design documents are not updated. The code and design gradually becomes out of step. It is difficult to avoid this happening because maintenance engineers may be pressurized to deal with new emergency fixes to the software. If an engineer who made the code changes leaves the team before the design is updated, it is then difficult for his or her replacement to retrofit the necessary design changes.
A further problem with emergency system repair is that they have to be completed as quickly as possible. A workable solution rather than best solution as far as system structure is concerned may be chosen. This accelerates the process of software aging so that future changes become progressively more difficult.
Rather than view the maintenance as a separate process, it should normally be considered as an iteration of the development process. New requirements must be formulated and validated, components of the system must be redesigned and implemented and part or all of the system must be tested. This implies a process model shown below:
Maintenance as iterative development
This iterative development process is effective when changes are not urgent and can be batched. If emergency code repairs have to be carried out, the problem of document inconsistency and degraded structure can be avoided if he change request for the repair remains outstanding after the code faults have been fixed. It can then be implemented more carefully after further analysis.
Analysis activities during software maintenance involve understanding the scope and effect of desired change, as well as constraints on making the changes. Design during maintenance involves redesigning the product to incorporate the desired changes. The changes then must be implemented, internal documentation of the code must be updated, and new test cases must be designed to assess the adequacy of the modification. Also the supporting documents (requirements, design specifications, test plan, principles of operations, user’s manuals etc.) must be updated to reflect the changes. Updated version of the system then be distributed to various customer’s cites.
Enhancing maintainability during development:
Many activities performed during software development enhance the maintainability of the product. Some of these activities are listed below:
Analysis activities
The analysis phase is concerned with identifying the functional and non-functional requirements (constraints) of the users. Following analysis activities are helping in making understandable and modifiable software:
Ø Develop standards and guidelines: Various types of standards and guidelines can be developed to enhance the maintainability of software. Standard formats for requirements documents and design specifications, structured programming conventions, and standardized format for supporting documents such as the test plan, the installation manuals, and the user manuals contribute to the understandability and hence the maintainability.
Ø Set milestones for the supporting documents to ensure that the work products are produced on schedule.
Ø Specify quality assurance procedures to ensure the development of high quality products.
Ø Identify likely product enhancements that will most likely occur following the initial delivery of the system.
Ø Determine resources required for maintenance (personnel, equipment, and floor space).
Ø Estimate maintenance cost.
High-level design activities
High-level design is concerned with identifying the modules in the software, conceptual data structures, and interconnection between the modules. Following high-level design activities affect the maintainability of the software:
Ø Emphasize clarity and modularity as design criteria. The criteria may include coupling, cohesion, efficiency considerations, interface to existing software, features in the machine architecture etc.
Ø Design to ease likely enhancements
Ø Use standard notations to document data flow, functions, structures and interconnections. These forms of design documentation aid the software maintainer who must understand the software product well enough to modify if and re-validate it.
Ø Observe the principles of information hiding, data abstraction, and top-down hierarchical decomposition. These concepts are appropriate mechanisms for achieving a clearly understandable, modular and easily modified system structure.
Detailed design activities
Detailed design is concerned with specifying the algorithm for modules identified in the high-level design, data representations and details of the interfaces among the modules. Following detailed design activities will affect the maintainability of the software: