Software maintenance

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. 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. ==Software life cycle==

from 1988 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. Transition from release to maintenance to end of the lifespan 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. Change cycle 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. 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. Testing can consume most of the 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. ==Categories of software maintenance==

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: • Corrective maintenance: modification of software to fix a bug or other failure to meet requirements, typically reported by an end user. • Preventive maintenance: forward-looking modification of software after delivery to ensure it continues to meet requirements or fix problems that have not manifested yet. This type of maintenance is performed especially on systems that are required to be highly safe or available. Software rejuvenation is one form of preventative maintenance to clean up state and prevent future problems. • Adaptive maintenance: modification of software performed after delivery to ensure its continuing usability in a changed or changing environment. • Perfective maintenance: enhancement of software after delivery to improve qualities such as user experience, processing efficiency, and maintainability. Perfective maintenance is necessary if other types of maintenance are carried out, because modification of an existing code base will otherwise increase complexity and cause the existing structure to deteriorate. Perfective maintenance may include rewriting documentation, code refactoring, and performance tuning. According to some estimates, enhancement (the latter two categories) comprises some 80 percent of software maintenance. ==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 maintainability index can be calculated with certain formulae from lines-of-code measures, McCabe measures and Halstead complexity measures. The measurement and tracking of maintainability are intended to help reduce or reverse a system's tendency toward "code entropy" or degraded integrity, and to indicate when it becomes cheaper and/or less risky to rewrite the code than it is to change it. 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. ==Workforce==

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, 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. ==Alternatives to maintenance==

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: • Freezing—do no more work on the legacy system. This option may be chosen if the vendor wants to continue to extract revenue as long as possible while avoiding maintenance costs. • Outsourcing functionality of the legacy system to a different company, especially if it is not considered a core business function. • Discarding the existing legacy system and redeveloping a new application from scratch to fulfill the same purpose as the legacy system. However, this approach is inefficient due to discarding a working system, and with this approach there is a danger that the new system will not fulfill changing business requirements. • Wrapping the legacy application in an abstraction layer to simplify outdated interfaces. The source code is not modified but the new interface allows a tried and tested component to be accessed by newer applications. This approach does not fix any of the issues with maintaining a legacy system. Databases, functions, and entire applications may be wrapped in this way. • Migrating the legacy system to a new platform, which can reduce the expense of new software development by reusing the implementation, design, specification, and requirements of the legacy system. Migration can take 5 to 10 years, but results in greater flexibility and long-term savings in software maintenance. As much as 80 percent of the expense is in testing; that is, ensuring that the new system has the same output as the old system. After the new system is finished, there needs to be a transition from the old system to the new system with minimum disruption to business functions. ==Research==

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. == See also ==