Software maintenance is the modification of software after delivery.
Software maintenance is often considered lower skilled and less rewarding than new development. As such, it is a common target for outsourcing or offshoring. Usually, the team developing the software is different from those who will be maintaining it. The developers lack an incentive to write the code to be easily maintained. Software is often delivered incomplete and almost always contains some bugs that the maintenance team must fix. Software maintenance often initially includes the development of new functionality, but as the product nears the end of its lifespan, maintenance is reduced to the bare minimum and then cut off entirely before the product is withdrawn.
Each maintenance cycle begins with a change request typically originating from an end user. That request is evaluated and if it is decided to implement it, the programmer studies the existing code to understand how it works before implementing the change. Testing to make sure the existing functionality is retained and the desired new functionality is added often comprises the majority of the maintenance cost.
Software maintenance is not as well studied as other phases of the software life cycle, despite comprising the majority of costs. Understanding has not changed significantly since the 1980s. Software maintenance can be categorized into several types depending on whether it is preventative or reactive and whether it is seeking to add functionality or preserve existing functionality, the latter typically in the face of a changed environment.
In the early 1970s, companies began to separate out software maintenance with its own team of engineers to free up software development teams from support tasks. In 1972, R. G. Canning published "The Maintenance 'Iceberg, in which he contended that software maintenance was an extension of software development with an additional input: the existing system. The discipline of software maintenance has changed little since then.[1] One twenty-first century innovation has been companies deliberately releasing incomplete software and planning to finish it post-release. This type of change, and others that expand functionality, is often called software evolution instead of maintenance.[1]
Despite testing and quality assurance, virtually all software contains bugs where the system does not work as intended. Post-release maintenance is necessary to remediate these bugs when they are found. Most software is a combination of pre-existing commercial off-the-shelf (COTS) and open-source software components with custom-written code. COTS and open-source software is typically updated over time, which can reduce the maintenance burden, but the modifications to these software components will need to be adjusted for in the final product. Unlike software development, which is focused on meeting specified requirements, software maintenance is driven by events—such as user requests or detection of a bug. Its main purpose is to preserve the usefulness of the software, usually in the face of changing requirements.
If conceived of as part of the software development life cycle, maintenance is the last and typically the longest phase of the cycle, comprising 80 to 90 percent of the lifecycle cost. Other models consider maintenance separate from software development, instead as part of the software maintenance life cycle (SMLC). SMLC models typically include understanding the code, modifying it, and revalidating it.
Frequently, software is delivered in an incomplete state. Developers will test a product until running out of time or funding, because they face fewer consequences for an imperfect product than going over time or budget. The transition from the development to the maintenance team is often inefficient, without lists of known issues or validation tests, which the maintenance team will likely recreate. After release, members of the development team are likely to be reassigned or otherwise become unavailable. The maintenance team will require additional resources for the first year after release, both for technical support and fixing defects left over from development.
Initially, software may go through a period of enhancements after release. New features are added according to user feedback. At some point, the company may decide that it is no longer profitable to make functional improvements, and restrict support to bug fixing and emergency updates. Changes become increasingly difficult and expensive due to lack of expertise or decaying architecture due to software aging. After a product is no longer maintained, and does not receive even this limited level of updating, some vendors will seek to extract revenue from the software as long as possible, even though the product is likely to become increasingly avoided. Eventually, the software will be withdrawn from the market, although it may remain in use. During this process, the software becomes a legacy system.
The first step in the change cycle is receiving a change request from a customer and analyzing it to confirm the problem and decide whether to implement the change. This may require input from multiple departments; for example, the marketing team can help evaluate whether the change is expected to bring more business. Software development effort estimation is a difficult problem, including for maintenance change requests, but the request is likely to be declined if it is too expensive or infeasible. If it is decided to implement the request, it can be assigned to a scheduled release and implemented. Although agile methodology does not have a maintenance phase, the change cycle can be enacted as a scrum sprint.
Understanding existing code is an essential step before modifying it.[1] The rate of understanding depends both on the code base as well as the skill of the programmer. Following coding conventions such as using clear function and variable names that correspond to their purpose makes understanding easier. Use of conditional loop statements only if the code could execute more than once, and eliminating code that will never execute can also increase understandability. Experienced programmers have an easier time understanding what the code does at a high level. Software visualization is sometimes used to speed up this process.
Modification to the code may take place in any way. On the one hand, it is common to haphazardly apply a quick fix without being granted enough time to update the code documentation. On the other hard structured iterative enhancement can begin by changing the top-level requirements document and propagating the change down to lower levels of the system. Modification often includes code refactoring (improving the structure without changing functionality) and restructuring (improving structure and functionality at the same time). Unlike commercial software, free and open source software change cycles are largely restricted to coding and testing, with minimal documentation. Open-source software projects instead rely on mailing lists and a large number of contributors to understand the code base and fix bugs efficiently.
An additional problem with maintenance is that nearly every change to code will introduce new bugs or unexpected ripple effects, which require another round of fixes.[1] Testing can consume the majority of maintenance resource for safety-critical code, due to the need to revalidate the entire software if any changes are made. Revalidation may include code review, regression testing with a subset of unit tests, integration tests, and system tests. The goal of the testing is to verify that previous functionality is retained, and the new functionality has been added.
The key purpose of software maintenance is ensuring that the product continues to meet usability requirements. At times, this may mean extending the product's capabilities beyond what was initially envisioned.
According to the ISO/IEC 14764 specification, software maintenance can be classified into four types:
According to some estimates, enhancement (the latter two categories) comprises some 80 percent of software maintenance.
See main article: Maintainability. Maintainability is the quality of software enabling it to be easily modified without breaking existing functionality. According to the ISO/IEC 14764 specification, activity to ensure software maintainability prior to release counts as part of software maintenance. Many software development organizations neglect maintainability, even though doing so will increase long-term costs. Technical debt is incurred when programmers, often out of laziness or urgency to meet a deadline, choose quick and dirty solutions rather than build maintainability into their code. A common cause is underestimates in software development effort estimation, leading to insufficient resources allocated to development. One important aspect is having a large amount of automated software tests that can detect if existing functionality is compromised by a change.
A challenge with maintainability is that many software engineering courses do not emphasize it, and give out one-and-done assignments that have clear and unchanging specifications. Software engineering courses do not cover systems as complex as occur in the real world. Development engineers who know that they will not be responsible for maintaining the software do not have an incentive to build in maintainability.[1]
Maintenance is often considered an unrewarding job for software engineers, who, if assigned to maintenance, were more likely to quit. It often pays less than a comparable job in software development. The task is often assigned to temporary workers or lesser-skilled staff,[1] although maintenance engineers are also typically older than developers, partly because they must be familiar with outdated technologies. In 2008, around 900,000 of the 1.3 million software engineers and programmers working in the United States were doing maintenance.
Companies started separate teams for maintenance, which led to outsourcing this work to a different company, and by the turn of the twenty-first century, sometimes offshoring the work to another country—whether as part of the original company or a separate entity. The typical sources of outsourcing are developed countries such as the United States, the United Kingdom, Japan, and Australia, while destinations are usually lower-cost countries such as China, India, Russia, and Ireland. Reasons for offshoring include taking advantage of lower labor costs, enabling around-the-clock support, reducing time pressure on developers, and to move support closer to the market for the product. Downsides of offshoring include communication barriers in the form of such factors as time zone and organizational disjunction and cultural differences. Despite many employers considering maintenance lower-skilled work and the phase of software development most suited to offshoring, it requires close communication with the customer and rapid response, both of which are hampered by these communication difficulties.
In software engineering, the term legacy system does not have a fixed meaning, but often refers to older systems which are large, difficult to modify, and also necessary for current business needs. Often legacy systems are written in obsolete programming languages, lack documentation, have a deteriorating structure after years of changes, and depend on experts to keep it operational. When dealing with these systems, at some point so much technical debt accumulates that maintenance is not practical or economical. Other choices include:
Despite taking up the lion's share of software development resources, maintenance is the least studied phase of software development. Much of the literature has focused on how to develop maintainable code from the outset, with less focus on motivating engineers to make maintainability a priority., automated solutions for code refactoring to reduce maintenance effort are an active area of research, as is machine-learning enhanced maintainability assessment.