Software maintenance
Encyclopedia
Software Maintenance in software engineering
is the modification of a software product after delivery to correct faults, to improve performance or other attributes.
A common perception of maintenance is that it merely involves fixing defects
. However, one study indicated that the majority, over 80%, of the maintenance effort is used for non-corrective actions (Pigosky 1997). This perception is perpetuated by users submitting problem reports that in reality are functionality enhancements to the system.
Software maintenance and evolution
of systems was first addressed by Meir M. Lehman in 1969. Over a period of twenty years, his research led to the formulation of Lehman's Laws (Lehman 1997). Key findings of his research include that maintenance is really evolutionary development and that maintenance decisions are aided by understanding what happens to systems (and software) over time. Lehman demonstrated that systems continue to evolve over time. As they evolve, they grow more complex unless some action such as code refactoring is taken to reduce the complexity.
The key software maintenance issues are both managerial and technical. Key management issues are: alignment with customer priorities, staffing, which organization does maintenance, estimating costs. Key technical issues are: limited understanding, impact analysis
, testing, maintainability measurement.
The survey showed that around 75% of the maintenance effort was on the first two types, and error correction consumed about 21%. Many subsequent studies suggest a similar magnitude of the problem. Studies show that contribution of end user is crucial during the new requirement data gathering and analysis. And this is the main cause of any problem during software evolution and maintenance. So software maintenance is important because it consumes a large part of the overall lifecycle costs and also the inability to change software quickly and reliably means that business opportunities are lost.
Impact of key adjustment factors on maintenance (sorted in order of maximum positive impact)
Not only are error-prone modules troublesome, but many other factors can degrade performance too. For example, very complex “spaghetti code” is quite difficult to maintain safely.
A very common situation which often degrades performance is lack of suitable maintenance tools, such as defect tracking software, change management software, and test library software. Below describe some of the factors and the range of impact on software maintenance.
Impact of key adjustment factors on maintenance (sorted in order of maximum negative impact)
There are a number of processes, activities and practices that are unique to maintainers, for example:
These have since been updated and ISO/IEC 14764 presents:
There is also a notion of pre-delivery/pre-release maintenance which is all the good things you do to lower the total cost of ownership of the software. Things like compliance with coding standards that includes software maintainability goals. The management of coupling and cohesion of the software. The attainment of software supportability goals (SAE JA1004, JA1005 and JA1006 for example). Note also that some academic institutions are carrying out research to quantify the cost to ongoing software maintenance due to the lack of resources such as design documents and system/software comprehension training and resources (multiply costs by approx. 1.5-2.0 where there is no design data available.).
Software engineering
Software Engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software...
is the modification of a software product after delivery to correct faults, to improve performance or other attributes.
A common perception of maintenance is that it merely involves fixing defects
Software bug
A software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways. Most bugs arise from mistakes and errors made by people in either a program's...
. However, one study indicated that the majority, over 80%, of the maintenance effort is used for non-corrective actions (Pigosky 1997). This perception is perpetuated by users submitting problem reports that in reality are functionality enhancements to the system.
Software maintenance and evolution
Software evolution
Software evolution is the term used in software engineering to refer to the process of developing software initially, then repeatedly updating it for various reasons.-General introduction:...
of systems was first addressed by Meir M. Lehman in 1969. Over a period of twenty years, his research led to the formulation of Lehman's Laws (Lehman 1997). Key findings of his research include that maintenance is really evolutionary development and that maintenance decisions are aided by understanding what happens to systems (and software) over time. Lehman demonstrated that systems continue to evolve over time. As they evolve, they grow more complex unless some action such as code refactoring is taken to reduce the complexity.
The key software maintenance issues are both managerial and technical. Key management issues are: alignment with customer priorities, staffing, which organization does maintenance, estimating costs. Key technical issues are: limited understanding, impact analysis
Change impact analysis
Change impact analysis is defined by Bohner and Arnold as "identifying the potential consequences of a change, or estimating what needs to be modified to accomplish a change", and they focus on IA in terms of scoping changes within the details of a design...
, testing, maintainability measurement.
The importance of software maintenance
In the late 1970s, a famous and widely cited survey study by Lientz and Swanson, exposed the very high fraction of life-cycle costs that were being expended on maintenance. They categorized maintenance activities into four classes:- Adaptive – dealing with changes and adapting in the software environment
- Perfective – accommodating with new or changed user requirements which concern functional enhancements to the software
- Corrective – dealing with errors found and fixing it
- Preventive – concerns activities aiming on increasing software maintainability and prevent problems in the future
The survey showed that around 75% of the maintenance effort was on the first two types, and error correction consumed about 21%. Many subsequent studies suggest a similar magnitude of the problem. Studies show that contribution of end user is crucial during the new requirement data gathering and analysis. And this is the main cause of any problem during software evolution and maintenance. So software maintenance is important because it consumes a large part of the overall lifecycle costs and also the inability to change software quickly and reliably means that business opportunities are lost.
Impact of key adjustment factors on maintenance (sorted in order of maximum positive impact)
| Maintenance Factors | Plus Range |
|---|---|
| Maintenance specialists | 35% |
| High staff experience | 34% |
| Table-driven variables and data | 33% |
| Low complexity of base code | 32% |
| Y2K and special search engines | 30% |
| Code restructuring tools | 29% |
| Re-engineering tools | 27% |
| High level programming languages | 25% |
| Reverse engineering tools | 23% |
| Complexity analysis tools | 20% |
| Defect tracking tools | 20% |
| Y2K “mass update” specialists | 20% |
| Automated change control tools | 18% |
| Unpaid overtime | 18% |
| Quality measurements | 16% |
| Formal base code inspections | 15% |
| Regression test libraries | 15% |
| Excellent response time | 12% |
| Annual training of > 10 days | 12% |
| High management experience | 12% |
| HELP desk automation | 12% |
| No error prone modules | 10% |
| On-line defect reporting | 10% |
| Productivity measurements | 8% |
| Excellent ease of use | 7% |
| User satisfaction measurements | 5% |
| High team morale | 5% |
| Sum | 503% |
Not only are error-prone modules troublesome, but many other factors can degrade performance too. For example, very complex “spaghetti code” is quite difficult to maintain safely.
A very common situation which often degrades performance is lack of suitable maintenance tools, such as defect tracking software, change management software, and test library software. Below describe some of the factors and the range of impact on software maintenance.
Impact of key adjustment factors on maintenance (sorted in order of maximum negative impact)
| Maintenance Factors | Minus Range |
|---|---|
| Error prone modules | -50% |
| Embedded variables and data | -45% |
| Staff inexperience | -40% |
| High code complexity | -30% |
| No Y2K of special search engines | -28% |
| Manual change control methods | -27% |
| Low level programming languages | -25% |
| No defect tracking tools | -24% |
| No Y2K “mass update” specialists | -22% |
| Poor ease of use | -18% |
| No quality measurements | -18% |
| No maintenance specialists | -18% |
| Poor response time | -16% |
| No code inspections | -15% |
| No regression test libraries | -15% |
| No help desk automation | -15% |
| No on-line defect reporting | -12% |
| Management inexperience | -15% |
| No code restructuring tools | -10% |
| No annual training | -10% |
| No reengineering tools | -10% |
| No reverse-engineering tools | -10% |
| No complexity analysis tools | -10% |
| No productivity measurements | -7% |
| Poor team morale | -6% |
| No user satisfaction measurements | -4% |
| No unpaid overtime | 0% |
| Sum | -500% |
Software maintenance planning
The integral part of software is the maintenance part which requires accurate maintenance plan to be prepared during software development and should specify how users will request modifications or report problems and the estimation of resources such as cost should be included in the budget and a new decision should address to develop a new system and its quality objectives [1].The software maintenance which can last for 5–6 years after the development calls for an effective planning which addresses the scope of software maintenance, the tailoring of the post delivery process, the designation of who will provide maintenance, an estimate of the life-cycle costs [2].Software maintenance processes
This section describes the six software maintenance processes as:- The implementation process contains software preparation and transition activities, such as the conception and creation of the maintenance plan; the preparation for handling problems identified during development; and the follow-up on product configuration management.
- The problem and modification analysis process, which is executed once the application has become the responsibility of the maintenance group. The maintenance programmer must analyze each request, confirm it (by reproducing the situation) and check its validity, investigate it and propose a solution, document the request and the solution proposal, and, finally, obtain all the required authorizations to apply the modifications.
- The process considering the implementation of the modification itself.
- The process acceptance of the modification, by confirming the modified work with the individual who submitted the request in order to make sure the modification provided a solution.
- The migration process (platform migrationSoftware migrationLegacy Modernization, or Software modernization, refers to the conversion, rewriting or porting of a legacy system to a modern computer programming language, software libraries, protocols, or hardware platform...
, for example) is exceptional, and is not part of daily maintenance tasks. If the software must be ported to another platform without any change in functionality, this process will be used and a maintenance project team is likely to be assigned to this task. - Finally, the last maintenance process, also an event which does not occur on a daily basis, is the retirement of a piece of software.
There are a number of processes, activities and practices that are unique to maintainers, for example:
- Transition: a controlled and coordinated sequence of activities during which a system is transferred progressively from the developer to the maintainer;
- Service Level AgreementService Level AgreementA service-level agreement is a part of a service contract where the level of service is formally defined. In practice, the term SLA is sometimes used to refer to the contracted delivery time or performance...
s (SLAs) and specialized (domain-specific) maintenance contracts negotiated by maintainers; - Modification Request and Problem Report Help Desk: a problem-handling process used by maintainers to prioritize, documents and route the requests they receive;
- Modification Request acceptance/rejection: modification request work over a certain size/effort/complexity may be rejected by maintainers and rerouted to a developer.
Categories of maintenance in ISO/IEC 14764
E.B. Swanson initially identified three categories of maintenance: corrective, adaptive, and perfective.These have since been updated and ISO/IEC 14764 presents:
- Corrective maintenance: Reactive modification of a software product performed after delivery to correct discovered problems.
- Adaptive maintenance: Modification of a software product performed after delivery to keep a software product usable in a changed or changing environment.
- Perfective maintenance: Modification of a software product after delivery to improve performance or maintainabilityMaintainabilityIn engineering, maintainability is the ease with which a product can be maintained in order to:* isolate defects or their cause* correct defects or their cause* meet new requirements* make future maintenance easier, or* cope with a changed environment...
. - Preventive maintenance: Modification of a software product after delivery to detect and correct latent faults in the software product before they become effective faults.
There is also a notion of pre-delivery/pre-release maintenance which is all the good things you do to lower the total cost of ownership of the software. Things like compliance with coding standards that includes software maintainability goals. The management of coupling and cohesion of the software. The attainment of software supportability goals (SAE JA1004, JA1005 and JA1006 for example). Note also that some academic institutions are carrying out research to quantify the cost to ongoing software maintenance due to the lack of resources such as design documents and system/software comprehension training and resources (multiply costs by approx. 1.5-2.0 where there is no design data available.).
See also
- Software maintainerSoftware maintainerIn free and open source software, a software maintainer is usually one or more people who build source code into a binary package for distribution, commit patches, or organize code in a source repository....
- Software archaeologySoftware archaeologySoftware archaeology or software archeology is the study of poorly documented or undocumented legacy software implementations, as part of software maintenance...
- Software developmentSoftware developmentSoftware development is the development of a software product...
- Computer softwareComputer softwareComputer software, or just software, is a collection of computer programs and related data that provide the instructions for telling a computer what to do and how to do it....
- Search Based Software Engineering
- Journal of Software Maintenance and Evolution: Research and PracticeJournal of Software Maintenance and Evolution: Research and PracticeThe Journal of Software Maintenance and Evolution: Research and Practice, previously known as the Journal of Software Maintenance: Research and Practice, publishes refereed papers on software maintenance and software evolution. Contributors include practitioners and researchers...