Editing Software maintenance (section)

==Software life cycle==
[[File:Traditional software development life cycle diagram.png|thumb|upright=2.5|center|Diagram for a traditional [[software development life cycle]] from 1988]]
Despite [[software testing|testing]] and [[Software quality assurance|quality assurance]], virtually all software contains [[software bug|bugs]] where the system does not work as intended. Post-release maintenance is necessary to remediate these bugs when they are found.{{sfn|Tripathy |Naik|2014|p=4}} 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.{{sfn|Tripathy |Naik|2014|pp=5-6}} 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.{{sfn|Tripathy |Naik|2014|p=26}} Its main purpose is to preserve the usefulness of the software, usually in the face of changing requirements.{{sfn|Madhusudhan ''et al.''|2017|p=761}}

If conceived of as part of the [[software development life cycle]], maintenance is the last and typically the longest phase of the cycle,{{sfn|Varga|2018|p=3}}{{sfn|Tripathy |Naik|2014|p=7}} comprising 80 to 90 percent of the lifecycle cost.{{sfn|Ulziit ''et al.''|2015|p=764}} Other models consider maintenance separate from software development, instead as part of the software maintenance life cycle (SMLC).{{sfn|Tripathy |Naik|2014|p=7}} SMLC models typically include understanding the code, modifying it, and revalidating it.{{sfn|Tripathy |Naik|2014|p=7}} 
===Transition from release to maintenance to end of the lifespan===
[[File:Software retirement diagram.png|thumb|upright=1.5|Diagram showing the steps for [[Application retirement|software retirement]]]]
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.{{sfn |Reifer|2012|p=22}} 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.{{sfn |Reifer|2012|p=21}} 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.{{sfn |Reifer|2012|p=22}} 

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]].{{sfn|Tripathy |Naik|2014|p=89}}

===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.{{sfn|Madhusudhan ''et al.''|2017|p=763}} This may require input from multiple departments; for example, the marketing team can help evaluate whether the change is expected to bring more business.{{sfn|Tripathy |Naik|2014|p=120}} [[Software development effort estimation]] is a difficult problem, including for maintenance change requests,{{sfn|Madhusudhan ''et al.''|2017|p=762}} but the request is likely to be declined if it is too expensive or infeasible.{{sfn|Tripathy |Naik|2014|p=123}}  If it is decided to implement the request, it can be assigned to a scheduled release and implemented.{{sfn|Tripathy |Naik|2014|p=123}} Although [[Agile software development|agile methodology]] does not have a maintenance phase,{{sfn|Ali ''et al.''|2024|p=126}}  the change cycle can be enacted as a [[scrum (software development)|scrum sprint]].{{sfn|Ali ''et al.''|2024|p=130}} 

Understanding existing code is an essential step before modifying it.<ref name=Offutt/> The rate of understanding depends both on the code base as well as the skill of the programmer.{{sfn|Tripathy |Naik|2014|p=296}} Following coding conventions such as using clear function and variable names that correspond to their purpose makes understanding easier.{{sfn|Tripathy |Naik|2014|pp=296-297}} 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.{{sfn|Tripathy |Naik|2014|p=309}} Experienced programmers have an easier time understanding what the code does at a high level.{{sfn|Tripathy |Naik|2014|p=297}}  [[Software visualization]] is sometimes used to speed up this process.{{sfn|Tripathy |Naik|2014|pp=318-319}} 

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]].{{sfn|Tripathy |Naik|2014|pp=85-86}} 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.{{sfn|Tripathy |Naik|2014|p=86}} Modification often includes [[code refactoring]] (improving the structure without changing functionality) and restructuring (improving structure and functionality at the same time).{{sfn|Tripathy |Naik|2014|p=94}} 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.{{sfn|Tripathy |Naik|2014|p=59}}

An additional problem with maintenance is that nearly every change to code will introduce new bugs or unexpected [[ripple effect]]s, which require another round of fixes.<ref name=Offutt/> 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.{{sfn|Reifer |2012|p=5}}  Revalidation may include [[code review]], [[regression test]]ing with a subset of [[unit test]]s, [[integration test]]s, and [[system test]]s.{{sfn|Tripathy |Naik|2014|p=94}} The goal of the testing is to verify that previous functionality is retained, and the new functionality has been added.{{sfn|Tripathy |Naik|2014|p=98}}