Hubbry Logo
Software maintenanceSoftware maintenanceMain
Open search
Software maintenance
Community hub
Software maintenance
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Software maintenance
Software maintenance
Software maintenance
View on Wikipedia
from Wikipedia

Part of a series on
Software development
Core activities
Paradigms and models
Methodologies and frameworks
Supporting disciplines
Practices
Tools
Standards and bodies of knowledge
Glossaries
Outlines

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 most of the maintenance cost.

Software maintenance is not as well studied as other phases of the software life cycle, despite comprising most of the cost. 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.

History

[edit]

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.[1] 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.[1] The discipline of software maintenance has changed little since then.[2] 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.[2]

Software life cycle

[edit]
Diagram for a traditional software development 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.[3] 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.[4] 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.[5] Its main purpose is to preserve the usefulness of the software, usually in the face of changing requirements.[6]

If conceived of as part of the software development life cycle, maintenance is the last and typically the longest phase of the cycle,[7][8] comprising 80 to 90 percent of the lifecycle cost.[9] Other models consider maintenance separate from software development, instead as part of the software maintenance life cycle (SMLC).[8] SMLC models typically include understanding the code, modifying it, and revalidating it.[8]

Transition from release to maintenance to end of the lifespan

[edit]
Diagram showing the steps for 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.[10] 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.[11] 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.[10]

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.[12]

Change cycle

[edit]

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.[13] This may require input from multiple departments; for example, the marketing team can help evaluate whether the change is expected to bring more business.[14] Software development effort estimation is a difficult problem, including for maintenance change requests,[15] but the request is likely to be declined if it is too expensive or infeasible.[16] If it is decided to implement the request, it can be assigned to a scheduled release and implemented.[16] Although agile methodology does not have a maintenance phase,[17] the change cycle can be enacted as a scrum sprint.[18]

Understanding existing code is an essential step before modifying it.[2] The rate of understanding depends both on the code base as well as the skill of the programmer.[19] Following coding conventions such as using clear function and variable names that correspond to their purpose makes understanding easier.[20] 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.[21] Experienced programmers have an easier time understanding what the code does at a high level.[22] Software visualization is sometimes used to speed up this process.[23]

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.[24] 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.[25] Modification often includes code refactoring (improving the structure without changing functionality) and restructuring (improving structure and functionality at the same time).[26] 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.[27]

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.[2] 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.[28] Revalidation may include code review, regression testing with a subset of unit tests, integration tests, and system tests.[26] The goal of the testing is to verify that previous functionality is retained, and the new functionality has been added.[29]

Categories of software maintenance

[edit]

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.[30]

According to the ISO/IEC 14764 specification, software maintenance can be classified into four types:[31]

  • Corrective maintenance: modification of software to fix a bug or other failure to meet requirements, typically reported by an end user.[31][32]
  • Preventive maintenance: forward-looking modification of software after delivery to ensure it continues to meet requirements or fix problems that have not manifested yet.[33][31] This type of maintenance is performed especially on systems that are required to be highly safe or available.[33] Software rejuvenation is one form of preventative maintenance to clean up state and prevent future problems.[33]
  • Adaptive maintenance: modification of software performed after delivery to ensure its continuing usability in a changed or changing environment.[31][33]
  • Perfective maintenance: enhancement of software after delivery to improve qualities such as user experience, processing efficiency, and maintainability.[33][34] 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.[34] Perfective maintenance may include rewriting documentation, code refactoring, and performance tuning.[33]

According to some estimates, enhancement (the latter two categories) comprises some 80 percent of software maintenance.[35]

Maintainability

[edit]

Maintainability is the quality of software enabling it to be easily modified without breaking existing functionality.[31] According to the ISO/IEC 14764 specification, activity to ensure software maintainability prior to release counts as part of software maintenance.[5] Many software development organizations neglect maintainability, even though doing so will increase long-term costs.[36] 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.[37] A common cause is underestimates in software development effort estimation, leading to insufficient resources allocated to development.[38] One important aspect is having a large amount of automated software tests that can detect if existing functionality is compromised by a change.[31]

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.[39] Software engineering courses do not cover systems as complex as occur in the real world.[40] Development engineers who know that they will not be responsible for maintaining the software do not have an incentive to build in maintainability.[2]

Workforce

[edit]

Maintenance is often considered an unrewarding job for software engineers, who, if assigned to maintenance, were more likely to quit.[41][42] It often pays less than a comparable job in software development.[42] The task is often assigned to temporary workers or lesser-skilled staff,[2][43] although maintenance engineers are also typically older than developers, partly because they must be familiar with outdated technologies.[43] In 2008, around 900,000 of the 1.3 million software engineers and programmers working in the United States were doing maintenance.[44]

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.[45][9] 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.[46] 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.[47] Downsides of offshoring include communication barriers in the form of such factors as time zone and organizational disjunction and cultural differences.[9] Despite many employers considering maintenance lower-skilled work and the phase of software development most suited to offshoring,[9][48] it requires close communication with the customer and rapid response, both of which are hampered by these communication difficulties.[9]

Alternatives to maintenance

[edit]

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.[49] When dealing with these systems, at some point so much technical debt accumulates that maintenance is not practical or economical.[12] Other choices include:

  • Freezing—do no more work on the legacy system.[50] This option may be chosen if the vendor wants to continue to extract revenue as long as possible while avoiding maintenance costs.[12]
  • Outsourcing functionality of the legacy system to a different company, especially if it is not considered a core business function.[50]
  • Discarding the existing legacy system and redeveloping a new application from scratch to fulfill the same purpose as the legacy system.[50] 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.[50]
  • Wrapping the legacy application in an abstraction layer to simplify outdated interfaces.[50] 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.[51] Databases, functions, and entire applications may be wrapped in this way.[52]
  • 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.[53] Migration can take 5 to 10 years, but results in greater flexibility and long-term savings in software maintenance.[54] 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.[55] 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.[55]

Research

[edit]

Despite taking up the lion's share of software development resources, maintenance is the least studied phase of software development.[56][57] 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.[58] As of 2020, automated solutions for code refactoring to reduce maintenance effort are an active area of research,[59] as is machine-learning enhanced maintainability assessment.[60]

References

[edit]

Sources

[edit]
  • Ali, Muhammad; Cheema, Sehrish Munawar; Naz, Ammerha; Pires, Ivan Miguel (2024). "SAMSEF: An Agile Software Maintenance Leveraging Scrum Framework for Improved Efficiency and Effectiveness". Good Practices and New Perspectives in Information Systems and Technologies. Lecture Notes in Networks and Systems. Vol. 989. Springer Nature Switzerland. pp. 126–136. doi:10.1007/978-3-031-60227-6_11. ISBN 978-3-031-60226-9.
  • Alsolai, Hadeel; Roper, Marc (2020). "A systematic literature review of machine learning techniques for software maintainability prediction" (PDF). Information and Software Technology. 119 106214. doi:10.1016/j.infsof.2019.106214.
  • Baqais, Abdulrahman Ahmed Bobakr; Alshayeb, Mohammad (2020). "Automatic software refactoring: a systematic literature review". Software Quality Journal. 28 (2): 459–502. doi:10.1007/s11219-019-09477-y.
  • Madhusudhan, V.; Suma, V.; Rao, Jawahar J. (2017). Software Maintenance: From the Perspective of Effort and Cost Requirement. Proceedings of the International Conference on Data Engineering and Communication Technology. Springer. pp. 759–768. ISBN 978-981-10-1678-3.
  • Rahman, Hanif Ur; da Silva, Alberto Rodrigues; Alzayed, Asaad; Raza, Mushtaq (2024). "A Systematic Literature Review on Software Maintenance Offshoring Decisions". Information and Software Technology. 172 107475. doi:10.1016/j.infsof.2024.107475.
  • Rahman, Hanif Ur; Raza, Mushtaq; Afsar, Palwasha; Khan, Habib Ullah (2021). "Empirical Investigation of Influencing Factors Regarding Offshore Outsourcing Decision of Application Maintenance". IEEE Access. 9: 58589–58608. Bibcode:2021IEEEA...958589R. doi:10.1109/ACCESS.2021.3073315. hdl:10576/37687. ISSN 2169-3536.
  • Reifer, Donald J. (2012). Software Maintenance Success Recipes. CRC Press. ISBN 978-1-4398-5167-8.
  • Tripathy, Priyadarshi; Naik, Kshirasagar (2014). Software Evolution and Maintenance: A Practitioner's Approach. John Wiley & Sons. ISBN 978-0-470-60341-3.
  • Ulziit, Bayarbuyan; Warraich, Zeeshan Akhtar; Gencel, Cigdem; Petersen, Kai (2015). "A conceptual framework of challenges and solutions for managing global software maintenance". Journal of Software: Evolution and Process. 27 (10): 763–792. doi:10.1002/smr.1720.
  • Varga, Ervin (2018). Unraveling Software Maintenance and Evolution: Thinking Outside the Box. Springer. ISBN 978-3-319-71303-8.


Revisions and contributorsEdit on WikipediaRead on Wikipedia

Software maintenance

View on Grokipedia
from Grokipedia
Software maintenance is the process of modifying a software product after delivery to correct faults, improve , or adapt to a changed environment. It encompasses the totality of activities required to provide cost-effective support to a , encompassing both predelivery planning and postdelivery execution to ensure ongoing reliability and functionality. Defined in international standards such as ISO/IEC/IEEE 14764, this discipline addresses the evolution of software throughout its lifecycle, managing changes to meet new requirements or mitigate issues. The four primary types of software maintenance are corrective, adaptive, perfective, and preventive. Corrective maintenance involves reactive fixes for discovered defects or faults in the software. Adaptive maintenance modifies the software to accommodate changes in its , such as hardware upgrades or regulatory shifts. Perfective maintenance enhances attributes like performance, usability, or functionality to better satisfy user needs. Preventive maintenance proactively detects and corrects potential faults to avert future problems and reduce long-term costs. Key activities in software maintenance follow an iterative process outlined in standards like ISO/IEC 14764, including process implementation, problem and modification analysis, , design and coding of changes, testing and validation, review and , and eventual migration or of the software. These activities require tools for program understanding, , and testing to handle technical challenges such as limited or complex dependencies. Economically, software maintenance dominates the total lifecycle costs of software systems, typically accounting for 50% to 80% of expenditures, with the majority dedicated to non-corrective enhancements rather than mere bug fixes. This emphasis underscores its role in sustaining software value amid evolving technologies and user demands, often exceeding initial development costs due to the prolonged operational lifespan of modern applications.

Overview

Definition

Software maintenance is the process of modifying a software product after delivery to correct faults, improve performance or other attributes, or adapt the product to a changed environment. This encompasses a range of activities aimed at ensuring the software remains functional, reliable, and aligned with evolving user needs and technological contexts throughout its operational life. Unlike , which involves the initial creation of new systems from scratch—often termed "greenfield" projects—maintenance focuses on post-deployment modifications to existing, operational software. Development emphasizes , coding, and initial testing to build functionality, whereas maintenance prioritizes sustaining and enhancing deployed systems without disrupting their core . Key terms in software maintenance include fault, synonymous with defect, referring to an in the software that causes unintended behavior and requires correction. A modification request is a formal document or record that identifies proposed changes, such as fixes or enhancements, initiating the maintenance . The release cycle describes the iterative process of implementing approved modifications, testing them, and deploying updates as major or minor versions to users. These terms underpin the structured approach to maintenance, which later categorizes activities such as corrective or adaptive efforts.

Importance and Costs

Software maintenance represents a critical phase in the software lifecycle, often dominating the overall economic burden of software projects. Studies indicate that maintenance activities account for 60-90% of the total software lifecycle costs, far exceeding initial development expenditures. This range has been consistently reported in empirical analyses since the , with Barry Boehm's 1981 work highlighting a typical distribution of approximately 30% for development and 70% for across various systems. The lifecycle cost can be expressed as: Total Cost=Development Cost+Maintenance Cost,\text{Total Cost} = \text{Development Cost} + \text{Maintenance Cost}, where Maintenance Cost≈0.6−0.9×Total Cost\text{Maintenance Cost} \approx 0.6 - 0.9 \times \text{Total Cost}. This economic dominance underscores the strategic necessity of prioritizing maintenance to control long-term project viability. The elevated costs of software maintenance stem from several interconnected factors, including the need for ongoing long-term support to ensure operational stability, the pressure of adapting to evolving user and environmental requirements, and the progressive accumulation of technical debt. Long-term support involves continuous monitoring, updates, and fixes to sustain functionality over extended periods, often spanning decades for enterprise systems. Evolving requirements, driven by business changes or technological shifts, necessitate frequent modifications that compound effort over time. Meanwhile, technical debt—arising from shortcuts or deferred refactoring—builds up, increasing the complexity and effort required for subsequent changes, much like accruing interest on financial obligations. Failure to invest adequately in maintenance exposes organizations to severe risks, including heightened vulnerabilities, failures, and rapid technological . Unmaintained software often harbors unpatched flaws that cybercriminals exploit, leading to breaches as seen in widespread incidents from delayed updates. Non-compliance with evolving standards, such as data protection regulations, can result in fines and legal penalties when outdated systems fail audits. Additionally, renders software incompatible with modern hardware or integrations, stifling and increasing replacement costs.

Historical Development

Origins in the 1970s

The recognition of software maintenance as a distinct phase emerged in the late 1960s and early , driven by the escalating complexity of large-scale software projects that outpaced initial development efforts. IBM's OS/360 operating system, launched in 1966 after a development process involving over 5,000 staff-years and costing more than $500 million, exemplified these challenges, as its intricate design led to persistent bugs, frequent redesigns, and ongoing modifications that blurred the lines between development and post-delivery support. This period, often termed the "," highlighted how such systems required substantial resources for upkeep, with maintenance activities consuming 50% to 70% of total software expenditures by the . A pivotal contribution came in 1972 from analyst R.G. Canning, who in his article "That Maintenance 'Iceberg'" described the underestimation of efforts, likening visible costs to the tip of an iceberg while emphasizing the hidden, substantial burdens of sustaining software in operational environments. Canning argued that extended beyond mere fixes, encompassing adaptations and enhancements that demanded resources comparable to initial development, thereby alerting practitioners to the need for dedicated strategies. Early IEEE publications in the 1970s began to advocate for separating maintenance from development teams to address these issues more effectively, recognizing that post-delivery work required specialized skills distinct from upfront coding. This separation allowed development groups to focus on new projects while maintenance personnel handled ongoing support, a practice increasingly adopted in large organizations like . The first formal definitions of software maintenance appeared in 1976 through E. Burton Swanson's paper "The Dimensions of Maintenance," presented at the IEEE's Second International Conference on Software Engineering, which established it as the modification of software after delivery to correct faults, adapt to changing environments, or improve performance and other attributes. Swanson's work provided a foundational framework, categorizing maintenance into corrective, adaptive, and perfective types, and solidified its status as a critical post-delivery activity separate from the development lifecycle.

Key Milestones and Publications

One of the earliest formal taxonomies for software maintenance was introduced by E. Burton Swanson in 1976, classifying maintenance activities into three primary categories: adaptive (adjusting to environmental changes), corrective (fixing defects), and perfective (enhancing functionality or performance). This framework, presented at the Second International Conference on , provided a foundational structure that influenced subsequent classifications and emphasized maintenance as distinct from development. A significant empirical study was published in 1980 by Bennet P. Lientz and E. Burton Swanson in their Software Maintenance Management: A Study of the Maintenance of Computer Application Software in 487 Installations. Based on a survey of 487 sites, it revealed that accounted for about 50% of the software budget, with roughly 60% dedicated to adaptive and perfective activities rather than corrective fixes, and highlighted common challenges like staff turnover and lack of . This work provided the first large-scale data on maintenance practices and influenced cost management strategies. Building on these early concepts from the 1970s, Barry Boehm's 1983 software maintenance model highlighted the economic implications of maintenance within the software lifecycle, estimating that it accounts for approximately 75% of total costs due to ongoing enhancements and adaptations. Boehm's approach, rooted in constructive cost modeling principles, integrated maintenance into broader lifecycle economics, underscoring the need for predictive tools to manage these expenses effectively. In the 1990s, the (ISO) introduced the ISO/IEC 14764 standard in 1999, which formalized processes for software maintenance, including planning, execution, and evaluation, while classifying maintenance into corrective, adaptive, perfective, and preventive types. This standard was revised in 2006 to align with evolving lifecycle models like ISO/IEC 12207, providing detailed guidance on maintenance management and integrating it with practices. Concurrently, Thomas M. Pigoski's 1996 Practical Software Maintenance: Best Practices for Managing Your Software Investment offered a comprehensive process guide, detailing best practices for maintenance teams, including , impact analysis, and to optimize support. The concept of technical debt emerged in the early 1990s, coined by Ward Cunningham in a 1992 experience report on the WyCash portfolio management system, describing how expedited development decisions accrue future maintenance burdens akin to financial interest. This metaphor gained prominence in the 2000s as software practices evolved toward agile methodologies, with expansions in literature emphasizing strategies to refactor and repay debt to sustain long-term maintainability.

Integration with Software Life Cycle

Role in the Overall Life Cycle

Software maintenance constitutes the culminating and most enduring phase within the software development life cycle (SDLC), ensuring the sustained functionality, adaptability, and relevance of deployed software systems. The SDLC generally comprises sequential or iterative stages, including , system design, (or coding), testing, deployment, and as the final, ongoing phase that supports the software post-release. This phase addresses real-world usage challenges, environmental changes, and enhancement needs, distinguishing it from preceding stages focused on creation and validation. Maintenance often dominates the lifecycle in both duration and resource allocation, typically accounting for 50-75% of total costs across all phases. For typical enterprise software, the total lifespan averages 6-8 years, with the maintenance phase comprising the majority of that duration following initial development, which usually requires 1-2 years. However, for legacy systems in sectors like banking, maintenance can span 20-50 years or more due to stability, integration complexities, and high replacement costs. This extended timeline for legacy systems reflects long-term operational demands of critical applications, such as ERP platforms or financial systems, where decommissioning is rare. The prolonged nature underscores maintenance's role in preserving value over time, with activities continuing until strategic obsolescence or replacement. As of 2025, cloud-native and modern enterprise applications often have shorter lifespans of 3-5 years due to rapid technological evolution, influencing integration approaches. Maintenance exhibits strong interdependencies with earlier SDLC phases, particularly requirements, as operational insights from usage—such as user feedback, performance issues, or regulatory shifts—inform iterative refinements and future iterations. This feedback loop promotes software evolution, allowing enhancements that align with evolving needs without full redevelopment. In practice, unresolved issues from testing or deployment can resurface, reinforcing maintenance's connective function across the lifecycle. The integration of maintenance varies by SDLC model. In the Waterfall model, a linear approach, maintenance follows deployment as a distinct post-development stage, with changes managed reactively after all upfront phases conclude. Conversely, Agile models integrate maintenance seamlessly through iterative sprints and continuous integration, blurring phase boundaries to enable proactive updates and rapid responses to emerging needs throughout the product's life. This contrast highlights how model choice influences maintenance's timing and efficiency in the overall lifecycle.

Transition from Development to Maintenance

The transition from to the maintenance phase marks a critical boundary in the software life cycle, where responsibility for the system shifts from creating new features to sustaining, adapting, and evolving the existing . This ensures continuity, minimizing disruptions while establishing processes for ongoing support. Effective transitions rely on structured activities to transfer artifacts, knowledge, and responsibilities, preventing knowledge silos that could impede long-term viability. Key handover activities include the transfer of comprehensive , such as architectural overviews, comments, and operational manuals, which provide maintainers with essential insights into system design and behavior. sessions, often in the form of workshops or embedded shadowing, facilitate the sharing of tacit expertise from developers to maintenance teams. Additionally, setting up initial bug triage involves configuring issue-tracking tools and defining protocols for prioritizing and resolving defects post-release, ensuring rapid response to early issues. Common challenges during this transition encompass the loss of developer knowledge, particularly when original team members depart without adequate overlap, leading to difficulties in understanding system intricacies. Incomplete or outdated exacerbates these issues, often resulting in substantial initial maintenance overhead as teams spend excessive time reverse-engineering code or reconstructing missing details; case studies indicate this can complicate project starts and increase effort significantly. Such gaps frequently arise from rushed development schedules or agile practices that deprioritize formal artifacts. Best practices to mitigate these challenges emphasize parallel team involvement during late development stages, where maintenance personnel join the project to gain hands-on exposure and contribute to final deliverables. Utilizing tools, such as systems like , supports seamless baseline establishment and change tracking, enabling maintainers to baseline the release and handle the first modification requests efficiently. These approaches, aligned with standards like IEEE/ISO/IEC 14764, promote a structured initiation of the change cycle from the stable release to iterative updates.

End-of-Life Considerations

Software reaches the end of its maintenance lifespan when the costs of continued support outweigh the benefits, often marked by escalating maintenance expenses that can consume up to 75% of total IT budgets for . Unsupported technologies, such as outdated programming languages or operating systems no longer receiving vendor updates, further signal this phase, as seen in official end-of-life announcements from developers that halt patches and feature enhancements. Security risks intensify as unpatched vulnerabilities accumulate, exemplified by the 2017 breach where a from the 1970s exposed 147 million individuals to exploitation. The decommissioning process begins with assessing dependencies and impacts, followed by to ensure business-critical information is transferred to modern systems or archived securely for compliance and future reference. User notification is essential, involving multiple communications to stakeholders about timelines and alternatives to minimize disruptions, often scheduled during low-impact periods with plans in place. Code and configurations are archived, preserving them in repositories or backups while removing associated like databases and networks, adhering to protocols to avoid operational gaps. Typical software lifespans vary by type, with consumer applications often lasting 5-10 years before , while legacy systems in sectors like banking, powered by , can endure 20 years or more—some operational for over 60 years due to their stability and the high cost of replacement. Factors influencing duration include the complexity of the system, evolving regulatory requirements, and technological shifts, with average averaging 6-8 years. After decommissioning, options include full shutdown to eliminate risks or open-sourcing the to enable community-driven support, allowing forks or independent for niche uses while reducing proprietary burdens. This approach has been adopted for some legacy projects to extend utility without ongoing vendor investment, though it requires careful licensing to protect .

Categories of Maintenance

Corrective Maintenance

Corrective maintenance involves the modification of a software product after delivery to identify and resolve bugs, errors, or failures that prevent it from meeting its specified requirements. This reactive approach addresses defects discovered during post-deployment use, such as runtime crashes, incorrect outputs, or security vulnerabilities that were not detected in prior testing phases. According to the ISO/IEC/IEEE 14764 standard, which outlines the categories of software maintenance, corrective maintenance focuses exclusively on rectifying these internal faults to restore functionality without altering the software's intended behavior or adapting to external changes. The process of corrective maintenance typically begins with fault reporting, where users or automated monitoring systems submit details of issues encountered in production. follows, involving techniques like analyzing system logs, reproducing the in a test environment, and using tools to isolate the root cause within the . Once identified, developers implement patches or code fixes, followed by rigorous testing—including unit tests and —to verify the resolution and ensure no new defects are introduced. The updated software is then deployed, often through controlled releases, with of the issue and fix maintained for and future . Corrective maintenance accounts for approximately 20-25% of total software maintenance efforts, though this proportion can be higher—sometimes exceeding 30%—in the early post-release period when latent defects from development are more likely to surface. Common tools supporting this process include debuggers such as GDB, which enable step-by-step code execution and variable inspection to pinpoint faults in compiled programs, and issue trackers like Jira, which facilitate reporting, prioritization, and workflow management for bug resolutions.

Adaptive Maintenance

Adaptive maintenance refers to the modifications made to a after its delivery to ensure it remains functional and compatible with changes in its , including hardware upgrades, operating system updates, or evolving regulatory requirements. This type of maintenance is essential for adapting software to external factors beyond the original development , preventing without altering core functionality. According to IEEE standards, adaptive maintenance specifically makes a usable in a changed environment. Common examples of adaptive maintenance include updating software to support new operating systems, such as migrating from to compatibility, or adjusting applications to run on upgraded hardware like transitioning from on-premises servers to modern processors. Another key instance involves regulatory adaptations, such as modifying data handling processes to comply with updates to the General Data Protection Regulation (GDPR), which may require enhanced or consent mechanisms for . Porting software to new cloud platforms, for example, shifting from (AWS) to to align with organizational infrastructure changes or leverage updated services, also exemplifies this maintenance category. The process of adaptive maintenance typically starts with impact analysis to evaluate how environmental changes affect the software's components, dependencies, and performance. This is followed by , where developers modify the codebase to restore compatibility, often involving updates to APIs, libraries, or configuration files. Finally, compatibility testing is conducted across the new environment to verify functionality, integration, and absence of regressions, ensuring the software meets operational standards before redeployment. Adaptive maintenance generally accounts for about 25% of total software maintenance efforts, though this proportion can increase significantly for legacy systems that face frequent environmental shifts due to outdated architectures. In such cases, the need for repeated adaptations to modern technologies or compliance standards amplifies the resource demands compared to newer, more flexible systems.

Perfective Maintenance

Perfective maintenance refers to the modification of a software product after delivery to improve its performance, maintainability, or other attributes in response to user requests for enhancements. This type of maintenance focuses on adding new features, optimizing for better efficiency, or refining the based on feedback to enhance overall functionality and . According to the IEEE Standard for Software Maintenance, these changes aim to elevate the software's value without addressing environmental adaptations or error corrections. Perfective maintenance typically dominates maintenance efforts, accounting for approximately 50-60% of total time and resources allocated to software upkeep, often surpassing other categories due to ongoing user demands and the need to keep software competitive in evolving markets. This high proportion is evidenced in empirical studies of maintenance distributions, where perfective activities consumed around 60% of efforts in surveyed projects. The drive stems primarily from user feedback highlighting areas for improvement, such as enhancements, and broader pressures to align software with advancing needs. The process for perfective maintenance mirrors general software modification workflows but emphasizes post-release requirement elicitation. It begins with gathering and analyzing new or refined requirements from users, even after initial deployment, to identify enhancement opportunities. This is followed by impact analysis, of the updates, of changes, and rigorous testing, including user to validate improvements in functionality and performance. The ISO/IEC 14764 standard outlines these steps within the broader maintenance process, ensuring enhancements are integrated without disrupting existing operations. Representative examples include incorporating mobile responsiveness into a to better serve users on handheld devices, thereby improving and based on usage . Another common instance is integrating new application programming interfaces (APIs) to enable compatibility with emerging services, such as third-party systems, which expands functionality and meets evolving user expectations for seamless integrations. These enhancements help sustain software relevance in dynamic environments.

Preventive Maintenance

Preventive maintenance in involves proactive activities designed to avert the emergence of faults and enhance long-term system stability without altering current functionality. This includes refactoring code to improve structure and readability, updating dependencies to address vulnerabilities and compatibility issues, and conducting regular code reviews to identify potential weaknesses early. These measures aim to minimize and ensure the software remains robust over time. Key techniques for preventive maintenance leverage automated tools to scale efforts efficiently. Static analysis tools, such as , scan for code smells, security hotspots, and maintainability issues, enabling developers to address them before they lead to failures. Automated refactoring tools like OpenRewrite support large-scale transformations, such as migrating deprecated APIs or optimizing code patterns, reducing manual effort while preserving behavior. These approaches are integrated into development workflows, often through pipelines, to make prevention a routine part of the process. The benefits of preventive maintenance are well-documented in industry studies, particularly in terms of cost efficiency and reliability. By proactively addressing issues, it can reduce future corrective maintenance costs compared to reactive strategies, as planned interventions avoid the escalation of minor problems into major defects. This leads to lower overall and improved , with organizations reporting enhanced and fewer unplanned repairs. In safety-critical domains like aviation software, periodic audits—such as systematic code inspections and compliance checks—are essential applications, ensuring adherence to stringent standards like for airborne systems and preventing catastrophic failures. Preventive maintenance complements perfective enhancements by emphasizing foresight over response, though both contribute to overall code health.

Maintainability

Factors Affecting Maintainability

Maintainability of software is influenced by a range of internal code attributes and external conditions that determine the ease of modification, , and extension over time. Key internal factors include the inherent quality of the , which encompasses , , and , as these directly impact the effort required for comprehension and alteration. Code modularity refers to the division of software into independent, cohesive modules that encapsulate related functionality, reducing interdependencies and facilitating isolated updates without widespread ripple effects. involves clear, consistent naming conventions, logical structure, and avoidance of overly complex constructs, which enable developers to quickly understand and navigate the . Adequate documentation, such as inline comments and external specifications, provides context for implementation decisions and usage, significantly lowering the during maintenance tasks. For instance, maintaining below 10—a measure of the number of linearly independent paths through the —correlates with higher by limiting decision points that complicate testing and error-prone modifications. Design principles further enhance maintainability by promoting architectures that isolate changes and promote reusability. The principles, comprising Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion, guide object-oriented design to create flexible systems where modifications in one component minimally affect others. Similarly, divides the software into distinct layers or modules based on responsibilities—such as presentation, , and data access—to minimize and contain the scope of changes, thereby reducing the risk of unintended side effects during updates. External factors, including legacy codebases and third-party dependencies, often introduce challenges to maintainability. Legacy systems, built with outdated technologies or poor initial practices, accumulate technical debt that increases vulnerability to errors and complicates integration with modern tools. Third-party dependencies, while accelerating development, heighten risks through potential incompatibilities, unpatched vulnerabilities, or supply chain disruptions that propagate issues across the system. Metrics like Halstead's software provide quantitative insights into by assessing code attributes such as and difficulty. measures the total size of the program in terms of unique operators and operands, while difficulty gauges the effort needed to understand or implement it, with higher values indicating greater overhead; these can help predict the cognitive effort for ongoing support.

Strategies to Improve Maintainability

Modular design enhances software maintainability by promoting high isolation between components, which facilitates error location, communication visibility, and easier updates without widespread impacts. This approach decomposes complex systems into smaller, independent modules, reducing and improving overall system comprehension and . Consistent naming conventions further support maintainability by improving and reducing during comprehension and modification tasks. Adopting standards such as camelCase for variables or PascalCase for classes ensures uniformity, minimizing errors in refactoring and . Automated testing with high coverage, typically aiming for over 80% of code paths, bolsters maintainability by enabling rapid verification of changes and early detection of regressions. Such practices allow developers to confidently modify while preserving functionality, as evidenced in frameworks like or pytest that integrate seamlessly into development workflows. Version control systems like improve maintainability by providing a structured history of changes, enabling to stable states and collaborative editing without conflicts. Best practices include frequent, atomic commits with descriptive messages to track evolution and facilitate debugging. pipelines enhance this by automating integration and deployment of small, incremental changes, which reduces integration risks and maintains code quality over time. Tools such as Jenkins or Actions enforce automated builds and tests on every commit, promoting frequent releases and minimizing technical drift. Organizational strategies like mandatory code reviews foster maintainability by catching issues early and enforcing adherence to standards across teams. Reviews typically involve peer evaluation for clarity, , and efficiency, leading to more robust codebases. Tracking using tools like quantifies maintainability risks through metrics such as code smells and remediation effort, allowing prioritization of refactoring efforts. 's analysis generates reports on debt in person-days, helping organizations allocate resources to high-impact areas without disrupting delivery. Refactoring techniques, such as extract method and rename variables, directly reduce complexity and improve long-term . Extract method breaks down lengthy procedures into focused functions, enhancing and reusability while preserving . Renaming variables to descriptive terms eliminates , aiding comprehension in large codebases and supporting automated tools for bulk updates. These methods, when applied iteratively, lower and boost metrics like the maintainability index.

Human and Organizational Aspects

Workforce and Skills Required

Software maintenance relies on a diverse comprising specialized professionals who ensure the ongoing functionality, , and efficiency of software systems. Key roles include maintenance engineers, who focus on diagnosing and resolving defects in existing codebases; support analysts, who handle user-reported issues and provide assistance; and specialists, who integrate maintenance activities with deployment pipelines to facilitate seamless updates. A significant portion of and related jobs involve and support activities, underscoring the scale of this workforce segment. Essential technical skills for these professionals encompass advanced debugging techniques to identify and fix bugs, deep to understand the specific industry context of the software (such as or healthcare), and proficiency in scripting languages like Python and Bash for automating routine maintenance tasks. Beyond technical expertise, are critical, particularly communication abilities that enable effective interaction with end-users, stakeholders, and cross-functional teams to gather requirements and explain resolutions. These competencies ensure that maintenance efforts align with business needs while minimizing disruptions. Emerging trends as of 2025 highlight the growing importance of skills in AI and for and automated code analysis. Training for software maintenance roles often emphasizes formal certifications and hands-on experience with legacy technologies. The (ISTQB) certification, for instance, equips professionals with standardized testing methodologies essential for preventive and corrective maintenance. Additionally, there is a strong focus on skills in outdated but persistent languages like and , which power many critical systems in sectors such as banking and government, requiring ongoing expertise to avoid . The software maintenance workforce continues to grow globally, driven by the proliferation of legacy systems and the need for continuous updates in cloud-based environments. This reflects increasing demand for roles augmented by AI tools that support without replacing human oversight.

Challenges in Maintenance Teams

Maintenance teams in software projects often grapple with organizational hurdles that impede efficiency and long-term sustainability. Knowledge , where expertise is concentrated among a few individuals or isolated groups, hinder collaborative problem-solving and increase dependency risks during personnel changes. These silos emerge as projects scale, limiting the broader team's ability to address maintenance issues promptly and leading to duplicated efforts or overlooked bugs. High turnover rates exacerbate these issues, particularly in support roles where attrition often exceeds industry averages, driven by demanding workloads and limited progression. This churn disrupts continuity, as departing members take institutional knowledge with them, forcing remaining staff to onboard newcomers amid ongoing demands. Underfunding compounds the problem, as budgets typically receive less allocation than new development initiatives, despite maintenance comprising 60-80% of long-term software lifecycle costs. Such disparities result in deferred updates, heightened , and reactive rather than proactive team operations. Outsourcing maintenance to offshore hubs like and introduces additional risks, including communication barriers from time zone differences and cultural nuances that delay issue resolution. High internal turnover and challenges in handling complex legacy systems can lead to inconsistent deliverables and quality issues in these models. These factors can extend project timelines and elevate error rates in cross-border handoffs. Motivation within maintenance teams suffers from the repetitive nature of tasks like bug fixes and patch applications, with 38% of engineers citing too many tedious tasks, including , as a barrier to meaningful work and contributing to burnout. The lack of opportunities for innovation or further erodes engagement, with burnout from repetitive workloads cited as a key factor in developer turnover. This skill gap in areas like advanced highlights the need for targeted , yet resource constraints often prevent it. In 2025, the persistence of post-pandemic has amplified coordination challenges for distributed maintenance teams, with communication breakdowns reducing collaboration efficiency compared to in-office setups. Asynchronous tools help, but unresolved issues in real-time troubleshooting persist, particularly for time-sensitive fixes in global teams.

Modern Approaches and Alternatives

DevOps and Continuous Integration Practices

emerged as a response to the silos between development and operations teams that plagued traditional software maintenance, originating from discussions in 2007–2008 and gaining momentum at the 2009 DevOpsDays conference organized by Patrick Debois. This movement addressed inefficiencies in maintenance by promoting collaboration, automation, and shared responsibility, evolving from agile principles to integrate operations into the development lifecycle. In software maintenance, integrates (CD) practices to enable rapid fixes and updates, automating the release process to production after passing tests, which minimizes downtime and accelerates issue resolution. (IaC) further supports this by allowing maintenance tasks, such as provisioning and configuring environments, to be managed declaratively through code rather than manual processes; tools like Terraform exemplify this by enabling version-controlled, repeatable infrastructure changes across cloud providers. Key DevOps practices in maintenance include automated testing within continuous integration (CI) pipelines, where tools like Jenkins orchestrate build, test, and deployment workflows to catch regressions early, and Actions provide cloud-hosted automation directly integrated with repositories for streamlined maintenance workflows. Additionally, monitoring solutions like facilitate proactive issue detection by collecting time-series metrics from applications and infrastructure, enabling alerting on anomalies before they impact users. These practices yield significant benefits for software maintenance, with high-performing (elite) teams achieving recovery times from failures of less than one hour—2,293 times faster than low performers—and change failure rates of 5%, reducing overall maintenance effort through higher stability and faster iterations. also supports maintenance of cloud-native applications via orchestration tools like , which automates scaling, updates, and self-healing to handle distributed systems efficiently. Recent advancements in include AI-assisted maintenance, where tools automate , in logs, and predictive fault to enhance preventive and perfective maintenance activities. As of 2025, the DORA report on AI-assisted software development notes that AI amplifies organizational strengths in delivery stability by up to 7.2%, though it can exacerbate weaknesses if not managed properly.

Alternatives to Traditional Maintenance

Alternatives to traditional maintenance of legacy software systems often involve strategies that encapsulate, replace, or isolate outdated components to minimize ongoing costs and risks associated with continuous updates. These approaches aim to integrate legacy systems with modern architectures without full-scale overhauls, allowing organizations to leverage existing functionality while transitioning toward sustainable solutions. Key methods include system wrapping, full , and freezing, each tailored to different levels of system complexity and business needs. System wrapping involves creating adapter layers or interfaces around legacy systems to expose their functionalities to new applications, effectively hiding internal complexities and enabling integration with contemporary technologies like web services. This technique, often implemented through , allows multiple similar legacy systems to be unified under a common wrapper, facilitating without altering the core code. For instance, wrappers can translate legacy protocols into modern APIs, reducing burdens by isolating changes to the adapter layer rather than the original system. Full redevelopment, particularly through migration to architectures, replaces monolithic s with modular, scalable components that can be developed, deployed, and maintained independently. This strategy typically follows a structured : assessing the for decomposition, identifying service boundaries based on business capabilities, and incrementally refactoring code into microservices while ensuring data consistency and minimal downtime. Organizations often use patterns like the Strangler Fig to gradually envelop the , allowing parallel operation during transition. Such migrations enhance agility and reduce long-term maintenance by distributing responsibilities across smaller, specialized services. Freezing a entails halting all modifications and shifts to a monitoring-only mode, where the system runs in isolation with continuous surveillance for stability and vulnerabilities. This retain strategy, part of broader cloud migration frameworks like the 7 Rs, is suitable for non-critical systems where the cost of change outweighs benefits, allowing resources to be redirected elsewhere while automated tools track and compliance. However, it requires robust isolation to prevent cascading failures and periodic audits to assess ongoing viability. Migration to cloud platforms via lift-and-shift methods provides another pathway by rehosting on-premises legacy systems directly into environments like AWS or Azure without architectural changes, thereby retiring physical infrastructure while preserving application logic. This approach accelerates relocation by virtualizing servers and databases, often using tools for automated discovery and replication, which can cut deployment time from months to weeks. It serves as a bridge to further optimizations, reducing maintenance overhead through for scaling and backups. For open-source legacy software, alternatives include forking the codebase to create a community-maintained variant or relying on external community support to distribute maintenance efforts. Forking allows organizations to diverge from an unmaintained upstream project, applying custom updates while benefiting from collective contributions, though it risks fragmentation if not coordinated. Community-driven support offloads costs by fixes and enhancements, as seen in ecosystems where end-of-life projects are revived through collaborative forks, ensuring longevity without investment. Notable case studies illustrate these alternatives in practice. During the Y2K crisis around 2000, numerous organizations addressed date-handling flaws in legacy systems through targeted migrations and wrapping techniques, with the U.S. government and enterprises investing in assessments that revealed widespread vulnerabilities in -based mainframes, leading to systematic renovations to avert potential disruptions. In modern contexts, -to- transitions have been pivotal in finance; for example, ING Bank automated the conversion of its mainframe applications to Java using refactoring tools, achieving seamless integration with cloud services and reducing operational costs significantly. Similarly, modernized its UPS-EMS system by transforming 409,568 lines of IBM z/OS into Java on AWS in four months, enhancing scalability for utility management without business interruption. The New York Times also refactored its mainframe codebase to Java and relational databases over two years, enabling agile content delivery while decommissioning legacy hardware. These examples highlight how alternatives can mitigate risks in high-stakes environments like banking and utilities.

Current Research Areas

Current research in software maintenance emphasizes automated techniques to enhance efficiency and reduce costs, particularly in bug detection and management. Automated bug detection has seen significant advancements through AI-driven approaches, such as SynergyBug, which integrates BERT and models to autonomously identify and repair bugs across diverse code sources, achieving higher accuracy in resolving complex issues compared to traditional methods. These efforts address the growing complexity of legacy systems, where manual consumes substantial developer time. Similarly, research on quantification utilizes tools like to measure and prioritize debt items, with a 2023 Sonar study analyzing over 200 projects revealing that incurs an average annual cost of $306,000 for a project of one million lines of code, highlighting the need for proactive repayment strategies. Empirical studies continue to explore the tangible impacts of code quality issues on activities. Investigations into code smells—structural deficiencies in code—demonstrate their correlation with increased effort; for instance, a 2025 bibliometric of publications from 2020 to 2024 found that code smells contribute to higher change proneness and effort in refactoring tasks, with metrics like serving as key predictors. These studies, often drawing from large-scale repositories such as projects, quantify how smell interactions amplify dependencies, thereby elevating the risk of defects during updates. Despite accounting for 50-90% of total software lifecycle costs, it remains under-researched, comprising only a fraction of literature. Methodologies in this domain increasingly rely on systematic literature reviews (SLRs) to evaluate intervention effectiveness, particularly refactoring. A tertiary SLR on code smells and refactoring, covering studies up to 2018, confirms that refactoring improves attributes like understandability and , though its impact varies by smell type. Ongoing SLRs address gaps in long-term outcomes, advocating for integrated metrics that combine static analysis with developer feedback to better guide practices. These directions underscore a shift toward evidence-based tools that mitigate the persistent challenges in sustaining software over time.

Emerging Technologies in Maintenance

and are revolutionizing software maintenance through predictive techniques that anticipate faults before they occur, thereby minimizing and corrective efforts. In , models such as (LSTM) networks analyze historical data patterns to forecast software defects with high precision. For instance, a hybrid model using , LSTM, and dense layers applied to software fault prediction achieved up to 93% accuracy on projects like Xerces as of 2025. Studies from 2025 confirm that such LSTM-based approaches exceed 85% accuracy in software fault prediction, enabling proactive interventions that can reduce maintenance costs by 25-30%. Cloud computing and serverless architectures further streamline maintenance by automating infrastructure management, particularly through auto-scaling features that dynamically adjust resources to demand, thereby decreasing the need for adaptive maintenance tasks like manual scaling or provisioning. exemplifies this with its event-driven execution model, where functions trigger automatically in response to events, facilitating rapid fixes without underlying server oversight. highlights that serverless platforms eliminate deployment and maintenance complexities, allowing developers to focus on code rather than operational upkeep, with operational costs nearing negligible levels compared to traditional setups. Open-source tools integrated with AI are enhancing refactoring and collaborative maintenance efforts. GitHub Copilot, an AI-powered coding assistant, automates by suggesting improvements that enhance readability and reduce complexity, directly supporting long-term maintainability. In community-driven models, tools like Copilot enable distributed open-source projects to accelerate bug fixes and updates, fostering collective ownership and faster iteration cycles. Looking ahead, quantum-resistant updates and technologies promise to secure maintenance processes against emerging threats. standards, such as those standardized by NIST, facilitate seamless software updates that resist quantum attacks, offering a cost-effective alternative to traditional methods with easier long-term maintenance. ensures version integrity by providing an immutable, decentralized ledger for tracking changes, preventing tampering and enhancing traceability in software evolution. These trends, projected to mature by 2030, will integrate with practices to bolster resilient maintenance pipelines.

References

  1. https://ieeecs-media.computer.org/media/education/swebok/swebok-v3.pdf
  2. https://www.iso.org/standard/80710.html
  3. https://www.computer.org/resources/software-maintenance
  4. https://standards.ieee.org/ieee/14764/7701/
  5. https://www.sciencedirect.com/science/article/abs/pii/S0950584911001923
  6. https://www.cs.cmu.edu/afs/cs/academic/class/17654-f01/www/refs/BB.pdf
  7. https://www.baytechconsulting.com/blog/projecting-costs-in-software-maintenance
  8. https://idealink.tech/blog/software-development-maintenance-true-cost-equation
  9. https://www.sonarsource.com/resources/library/technical-debt/
  10. https://www.gao.gov/blog/crowdstrike-chaos-highlights-key-cyber-vulnerabilities-software-updates
  11. https://www.itconvergence.com/blog/the-top-5-risks-of-using-obsolete-and-unsupported-software/
  12. https://www.bitsight.com/blog/outdated-software-issues
  13. https://homes.luddy.indiana.edu/nensmeng/files/ensmenger-mice.pdf
  14. https://spectrum.ieee.org/building-the-system360-mainframe-nearly-destroyed-ibm
  15. https://dl.acm.org/doi/10.5555/800253.807723
  16. https://ieeexplore.ieee.org/document/1702325
  17. https://www.semanticscholar.org/paper/The-dimensions-of-maintenance-Swanson/d14a38783decf5611343c2b551d53ff6ed921721
  18. https://dl.acm.org/doi/book/10.5555/578790
  19. https://www.geeksforgeeks.org/software-engineering/boehms-software-maintenance-model/
  20. https://www.researchgate.net/publication/227302384_Cost_models_for_future_software_life_cycle_processes_COCOMO_20
  21. https://www.iso.org/standard/39064.html
  22. https://dl.acm.org/doi/10.5555/524398
  23. https://www.agilealliance.org/wp-content/uploads/2016/05/IntroductiontotheTechnicalDebtConcept-V-02.pdf
  24. https://ieeexplore.ieee.org/document/10109339
  25. https://aws.amazon.com/what-is/sdlc/
  26. https://www.dau.edu/sites/default/files/Migrated/CopDocuments/SW%2520Cost%2520Est%2520Manual%2520Vol%2520I%2520rev%252010.pdf
  27. https://bespokesoftware.io/blog/what-is-the-lifespan-of-custom-software/
  28. https://appcost.ai/blog/software-development-timeline-guide
  29. https://spectrum.ieee.org/inside-hidden-world-legacy-it-systems
  30. https://www.hotwaxsystems.com/hotwax-blog/what-is-the-life-expectancy-of-custom-software
  31. https://www.ibm.com/think/topics/agile-vs-waterfall
  32. https://www.ninjaone.com/blog/end-of-life-software-management/
  33. https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-app-retirement-best-practices/welcome.html
  34. https://www.linkedin.com/pulse/navigating-end-of-life-guide-decommissioning-software-nghishekwa-4ssqf
  35. https://www.redhat.com/en/blog/decommission-systems
  36. https://www.archondatastore.com/blog/application-decommissioning-retirement/
  37. https://mitosystems.com/software-evolution/
  38. https://www.castsoftware.com/pulse/why-cobol-still-dominates-banking-and-how-to-modernize
  39. https://www.linuxfoundation.org/resources/open-source-guides/winding-down-an-open-source-project
  40. https://www.herodevs.com/blog-posts/navigating-end-of-life-in-open-source-software-challenges-and-triumphs
  41. https://ltsgroup.tech/blog/software-maintenance-guide/
  42. https://www.scnsoft.com/software-development/maintenance-and-support/costs
  43. https://www.atlassian.com/software/jira/features/bug-tracking
  44. https://ieeexplore.ieee.org/document/1167786/
  45. https://www.geeksforgeeks.org/software-engineering/adaptive-maintenance-am-software-engineering/
  46. https://www.pixelcrayons.com/blog/digital-transformation/cloud-migration-gdpr-compliance/
  47. https://teachingagile.com/sdlc/maintenance
  48. https://cpl.thalesgroup.com/software-monetization/four-types-of-software-maintenance
  49. https://anarsolutions.com/application-maintenance-and-enhancements-2/adaptive-maintenance/
  50. https://www.researchgate.net/publication/228535109_Software_maintenance_productivity_and_maturity
  51. https://www.cs.uah.edu/~rcoleman/CS499/CourseTopics/IEEE_Std_1219-1998.pdf
  52. https://cs.gmu.edu/~offutt/softwaretest/edition1/bs-level-syllabus/slides/swe437-1b-maintenanceEvolution-overview.pdf
  53. https://link.springer.com/article/10.1023/A:1025368318006
  54. https://cdn.standards.iteh.ai/samples/80710/9a26fc3a1a464fa286fb85d6c1eeed31/ISO-IEC-IEEE-14764-2022.pdf
  55. https://www.lavalamp.biz/blogs/mastering-code-maintenance-proven-strategies-for-sustainable-software-development/
  56. https://luvina.net/types-of-software-maintenance/
  57. https://www.n-ix.com/types-of-software-maintenance/
  58. https://www.sonarsource.com/solutions/maintainability/
  59. https://docs.openrewrite.org/
  60. https://softwarehouse.all-for-one.pl/topics/reliability-in-aviation-software/
  61. https://www.researchgate.net/publication/261315161_A_Survey_of_Key_Factors_Affecting_Software_Maintainability
  62. http://www.enggjournals.com/ijcse/doc/IJCSE11-03-12-062.pdf
  63. https://learn.microsoft.com/en-us/visualstudio/code-quality/code-metrics-cyclomatic-complexity?view=vs-2022
  64. https://ieeexplore.ieee.org/document/1702388/
  65. https://staff.cs.utu.fi/~jounsmed/doos_06/material/DesignPrinciplesAndPatterns.pdf
  66. https://www.researchgate.net/publication/244446574_Understanding_separation_of_concerns
  67. https://www.sciencedirect.com/science/article/pii/S016412122400298X
  68. https://www.sciencedirect.com/science/article/abs/pii/S0164121208002793
  69. https://dl.acm.org/doi/book/10.5555/540137
  70. https://ieeexplore.ieee.org/document/5221065/
  71. https://dl.acm.org/doi/10.5555/311424
  72. https://kaner.com/pdfs/autosqa.pdf
  73. https://www.tricentis.com/learn/maintainability
  74. https://www.atlassian.com/git/tutorials/what-is-version-control
  75. https://www.git-tower.com/blog/version-control-best-practices
  76. https://www.redhat.com/en/topics/devops/what-is-ci-cd
  77. https://www.perforce.com/blog/kw/static-analysis-ci-cd-pipelines
  78. https://owasp.org/www-project-code-review-guide/assets/OWASP_Code_Review_Guide_v2.pdf
  79. https://blog.palantir.com/code-review-best-practices-19e02780015f
  80. https://docs.sonarsource.com/sonarqube-server/latest/user-guide/code-metrics/metrics-definition/
  81. https://www.sciencedirect.com/science/article/abs/pii/S0950584919302113
  82. https://ieeexplore.ieee.org/iel7/6287639/10005208/10244041.pdf
  83. https://dl.acm.org/doi/10.1145/3712191
  84. https://dl.acm.org/doi/10.1145/3485136
  85. https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm
  86. https://reports.weforum.org/docs/WEF_Future_of_Jobs_Report_2025.pdf
  87. https://stackoverflow.blog/2019/09/30/hidden-and-siloed-knowledge-within-your-organization/
  88. https://www.softwareimprovementgroup.com/knowledge-crisis-in-financial-software/
  89. https://www.skillsoft.com/blog/the-top-10-challenges-it-teams-face
  90. https://flairstech.com/blog/software-maintenance-services-problems
  91. https://ttms.com/it-outsourcing-to-india-8-key-challenges-and-how-to-solve-them/
  92. https://www.index.dev/blog/india-latin-america-eastern-europe-it-outsourcing
  93. https://kitrum.com/blog/it-outsourcing-insights-red-flags/
  94. https://www.prnewswire.com/news-releases/chainguard-research-shows-engineers-struggle-with-burnout-maintenance-and-tool-sprawl-despite-ai-gains-302577843.html
  95. https://engineeringx.org/blog/toil-takes-its-toll-developer-burnout-is-straining-organizational-resources
  96. https://www.coherentsolutions.com/insights/the-impact-of-remote-work-on-software-development-projects
  97. https://lpsonline.sas.upenn.edu/features/rise-remote-work-challenges-and-opportunities-businesses
  98. https://www.atlassian.com/devops/what-is-devops/history-of-devops
  99. https://newrelic.com/blog/nerd-life/devops-name
  100. https://continuousdelivery.com/
  101. https://developer.hashicorp.com/terraform/intro
  102. https://prometheus.io/docs/introduction/overview/
  103. https://octopus.com/blog/2024-devops-performance-clusters
  104. https://dora.dev/research/2025/dora-report/
  105. https://www.researchgate.net/publication/267181092_Approaches_and_techniques_for_legacy_software_modernization
  106. https://ieeexplore.ieee.org/document/4031163/
  107. https://www.researchgate.net/publication/220300651_Encapsulation_of_legacy_software_A_technique_for_reusing_legacy_software_components
  108. https://www.sei.cmu.edu/blog/8-steps-for-migrating-existing-applications-to-microservices/
  109. https://circleci.com/blog/monolith-to-microservices-migration-strategies/
  110. https://www.netapp.com/blog/aws-cvo-blg-strategies-for-aws-migration-the-new-7th-r-explained/
  111. https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html
  112. https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/plan/select-cloud-migration-strategy
  113. https://thenewstack.io/what-to-do-when-critical-open-source-projects-go-end-of-life/
  114. https://softwaremining.com/news/ING-Bank-Mainframe-Modernization.jsp
  115. https://tsri.com/case-studies/att-ups-ems-system-ibm-cobol-to-java-modernization-on-aws
  116. https://aws.amazon.com/blogs/apn/automated-refactoring-of-a-new-york-times-mainframe-to-aws-with-modern-systems/
  117. https://www.nature.com/articles/s41598-025-08226-5
  118. https://www.sonarsource.com/blog/new-research-from-sonar-on-cost-of-technical-debt/
  119. https://www.researchgate.net/publication/394185292_Global_Trends_and_Empirical_Metrics_in_the_Evaluation_of_Code_Smells_and_Technical_Debt_A_Bibliometric_Study
  120. https://www.researchgate.net/publication/343670195_Analysis_Of_Software_Maintenance_Cost_Affecting_Factors_And_Estimation_Models
  121. https://www.sciencedirect.com/science/article/abs/pii/S0164121220300881
  122. https://www.sciencedirect.com/science/article/pii/S1110866525000167
  123. https://www.researchgate.net/figure/Summary-of-Costs-and-Benefits-for-AI-Driven-Predictive-Maintenance_tbl3_386602312
  124. https://docs.aws.amazon.com/lambda/latest/dg/concepts-event-driven-architectures.html
  125. https://dl.acm.org/doi/10.1145/3510611
  126. https://docs.github.com/en/copilot/tutorials/refactor-code
  127. https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-in-the-enterprise-with-accenture/
  128. https://www.nsa.gov/Cybersecurity/Post-Quantum-Cybersecurity-Resources/
  129. https://www.mdpi.com/2076-3417/13/5/3066
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.