Editing Software maintenance (section)

===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}}