Understanding the Cost of Software Maintenance

The International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) defines software maintenance as the modification of a software product after delivery, typically for the purpose of correcting faults or improving performance. Understanding what software maintenance entails is crucial for preventing critical events and managing costs, especially given the accelerating rate of hardware obsolescence and the various factors that affect software maintenance costs.

While software itself doesn’t wear out, users expect it to run on the latest platforms and operating environments. Furthermore, feature enhancements are always in high demand when software has a large number of regular users. Software thus continues to evolve through maintenance after its initial development.

What is Software Maintenance?

The software maintenance process is the process of updating, modifying, and ensuring the continued performance of software applications after their initial release. This ongoing process involves a range of activities, including bug fixing, performance optimization, security updates, and adapting the software to changing user needs and technological advancements. Effective software maintenance is crucial to ensure the software remains relevant, efficient, and secure, and to prevent technical debt from accumulating. By regularly maintaining software, organizations can extend its lifespan, improve user satisfaction, and reduce long-term costs.

Types of Software Maintenance

There are four primary types of software maintenance, each addressing different aspects of maintaining and improving software:

1. Corrective Maintenance: This type of maintenance involves identifying and fixing errors or bugs in the software. It is a reactive approach, addressing problems as they arise. Corrective maintenance ensures that the software continues to function correctly and efficiently, minimizing disruptions for users.
2. Adaptive Maintenance: Adaptive maintenance focuses on adapting the software to changes in the environment, such as updates to the operating system or hardware changes. It is a proactive approach, ensuring the software remains compatible with the evolving technological landscape. This type of maintenance is essential for keeping the software up-to-date with the latest technological advancements.
3. Perfective Maintenance: Perfective maintenance involves enhancements and optimizations to improve the software's functionality or performance. It is a proactive approach, refining the software based on user feedback and changing requirements. This type of maintenance helps in adding new features, improving user experience, and ensuring the software meets the evolving needs of its users.
4. Preventive Maintenance: Preventive maintenance is a proactive strategy to identify and address potential issues before they impact the software's performance. By anticipating and resolving potential problems, preventive maintenance helps minimize the occurrence of critical issues, ensuring the software remains reliable and efficient.

Corrective Maintenance Types

The layperson often believes that maintenance is only a small portion of software’s total cost of ownership (TCO), but this is rarely the case. Maintenance frequently accounts for at least 70 percent of the software’s TCO, but this figure can be significantly higher. In the case of embedded software, maintenance is typically 65 to 80 percent of the TCO.

Understanding software costs, particularly software maintenance cost factors, is crucial as they significantly impact the total cost of ownership. These factors include general influences and the impact of different sourcing models, such as in-house versus outsourced maintenance.

A study conducted by Lientz and Swanson during the late 1970s remains highly influential in describing the maintenance cost of software. This study classifies software maintenance services into the following four classes:

• Adaptive
• Perfective
• Corrective
• Preventive

Adaptive maintenance modifies the software so that it can handle changes in its environment such as the database management system (DBMS) and operating system (OS). Perfective maintenance makes changes to accommodate new or modified user requirements, including functional enhancements. Corrective maintenance diagnoses and fixes errors, often those identified by users. Preventive maintenance corrects defects that have yet manifested themselves, thus increasing the software’s reliability.

Lientz and Swanson showed perfective maintenance accounts for over half of all maintenance effort. Furthermore, three-fourths of all maintenance is either perfective or adaptive maintenance. While it’s commonly believed that most maintenance is corrective, this category accounts for less than a fourth of all maintenance. Preventative maintenance is only three percent of the total maintenance. Subsequent studies show a similar distribution of effort. The chart below shows the proportion of total maintenance time by maintenance type:

Dr. Berry Boehm proposed the Constructive Cost Estimation Model (COCOMO) in 1981 to estimate software maintenance cost. The basic model is still in use today, although the specific scoring algorithms have been revised several times to reflect new information and technological advances. This model estimates the annual maintenance cost of the project from the total development costs.

The bulk of this procedure deals with estimating the development cost when the project hasn’t been completed yet. On cases where the project is complete, the development cost should already be known with a high degree of confidence. Once the development cost is available, estimating the annual maintenance cost is relatively straightforward.

KLOC

The first step in estimating development costs under COCOMO is calculating its size, which is traditionally measured in thousands of lines of code (KLOC). KLOC is one of the simplest metrics for estimating an application's size, which is why it's also one of the most popular. You can easily determine this metric by simply counting the total number of lines of source code, excluding comments and header lines. Even if you need to obtain the KLOC count for many modules, this method is still easier to calculate than any of the other metrics.

While KLOC is easy to calculate at the end of the project, you can only estimate it at the beginning of the project. Project managers typically accomplish this task by first dividing the software design into modules and then dividing those modules into submodules. They continue this process until the divisions reach the leaf level, allowing them to estimate the KLOC needed to code each leaf-level module with relative accuracy.

Function Point

A Function Point (FP) is a metric that Allan Albrecht at IBM defined in 1979 to estimate the size of software. It has slowly gained in popularity over the years since it has several advantages over LOC such as its ability to estimate the size of software directly from the specification. In comparison, KLOC can only be determined after developers have completed the software.

The idea behind FPs is that software size is directly related to the number of functions it performs, meaning a product with more functions the larger size. A function is defined as a group of code that accepts input and produces output. The figure below illustrates the data flow of a simple function:

This example shows an issue book function that you might find in library automation software. This function accepts the book title as input and displays the book's location and number of copies available as output. The number of input and output values then provides an indication of the number of functions the software supports.

Unadjusted Function Point

Albrecht also postulated that the unadjusted function points (UFP) are dependent on the number of inquiries, files, and interfaces the software uses. The following equation shows this relationship for modern software:

UFP = (number of inputs)*4 + (number of outputs)*5 + (number of inquiries)*4 + (number of files)*10 + (number of interfaces)*10.

This equation is a weighted sum of these five characteristics, meaning the factor associated with each characteristic indicates its relative importance. For example, the number of interfaces has a factor of 10, so this characteristic is twice as important as the number of outputs, which has a factor of only 5. Researchers have validated these weights over many projects.

Inputs

A group of related data items counts as one input, rather than an individual data item. Assume for this example that an employee payroll application requires employee data as input, including items like name, address, and phone number. This group of items would likely be considered as one input since they all pertain to the same employee.

Output

Each output is a single printed report, screen display, or error message. As with inputs, a group of related data items counts as only one output.

Inquiries

Inquiries are distinct interactive queries from the user. They consist of user commands requiring a response from the software.

Files

Each logical file that the software uses counts as a file. These files contain logically related data so they may be physical files or data structures.

Interfaces

An interface must exchange information with other systems to be counted. They include communication links and physical media.

Technical Complexity Factor

Once you've computed the UFP, you'll need to establish a value for the technical complexity factor (TCF) to calculate the FP that will provide an estimate for the cost of software maintenance. The TCF requires you to assign a rating on each of the following 14 influencing factors:

• Data communications
• Distributed functions
• Performance
• Heavily used configuration
• Transaction rate
• On-line data entry
• End-user efficiency
• On-line update
• Complex processing
• Reusability
• Installation ease
• Operational ease
• Multiple sites
• Facilitate change

The rating scale for these influencing factors ranges from 0 for no influence at all to 5 for essential. These scores are then totaled to provide a Degree of Influence (DI) score ranging from 0 to 70. The TCF can then be calculated as 0.65 + 0.01 * DI. Multiply the UFP by the TCF to get the FP.

Effort Adjustment Factor

The next step in the COCOMO formula is calculating the effort adjustment factor (EAF), which requires you rate the importance of 15 cost drivers in four attribute categories. The attribute categories include product, hardware, personnel, and project. The rating scale for each cost driver has six levels, including very low, low, nominal, high, very high, and extra high. Each of these levels has an associated value known as an effort multiplier for each driver, which generally ranges from 0.9 to 1.4. A rating with a dash (-) means that rating doesn't apply for that driver. The following table shows these effort multipliers:

Multiply the effort multipliers together to obtain the EAF. The following equation will then provide the effort needed to develop the software:

E=a*EAF*(Size)^b

In the above equation, E is the effort in person-months and Size is the size of the project in KLOC or FP. The values a and b depend on the type of software project as follows:

Once you have estimated the total effort needed to develop the software, you can allocate that effort among the team members. Multiply the effort of each team member by their total compensation for that time period to get the cost of that team member's effort. Add these costs for each team member to obtain the total cost of effort for the project.

Maintenance Cost

COCOMO uses a quantity called Annual Change Traffic (ACT), which is the average fraction of the software product’s total instructions that are added or deleted each year, and it plays a crucial role in estimating software maintenance costs. For example, an ACT of 0.5 means that an average of half the software’s instructions are added or deleted each year.

ACT may be calculated by dividing the sum of the KLOCs added and KLOCs deleted by the total lines of code. However, this calculation doesn’t take into account factors such as software complexity, hardware requirements, the maintainers’ familiarity with the project, or their level of general experience. You can also calculate ACT by dividing the sum of the FPs added and deleted by the total number of FPs. Multiply the ACT by the total development cost to estimate the annual maintenance cost.

Factors Affecting Software Maintenance

Factors affecting software maintenance play a crucial role in determining the overall expenditure. Many other factors can influence the cost of maintaining software. In practice, organizations that develop software usually modify standard models like COCOMO to fit their particular processes, especially if software development is one of their core competencies. In these cases, the customized models have typically been modified and validated repeatedly to ensure they provide usable results with the additional metrics available. These metrics are usually specific to the organization, project, and development environment.

Complexity

Software complexity is one of the primary cost drivers for maintenance. While the standard models take complexity into account, the many types of complexity in software may require extra scrutiny for some projects. Simple measures of complexity include the number of modules and average module size. More formal measures include McCabe's cyclomatic complexity and Halstead's data complexity. The collection of metrics can greatly increase the reliability of these measures, although this process may not be cost-effective.

The extent to which the software's logic is located in a single place is another type of complexity. This property affects the cohesion and coupling of modules, which can have a direct effect on maintenance requirements. Additional software properties that may require additional adjustments include the number of releases, variants, and versions of the software.

Documentation

Documentation has a great effect on maintenance efforts, especially if the maintenance team is new to the project. The quality of documentation is particularly important for minimizing the maintenance learning curve, including its accuracy, completeness, and readability. In-source comments can provide greater detail on the technical aspects such as definitions, data structures, and functions. They also provide an error history, which is valuable information for engineers who want to make changes to that module. The ability to trace design decisions is another characteristic of documentation that significantly affects maintenance.

Project Size

Researchers have found that the relationship between software size and developer effort is frequently non-linear, which contradicts the assumptions of standard cost models. These studies used Data Environment Analysis (DEA) to analyze the effect of size and productivity to show that larger projects often require less developer effort than expected, especially for the largest ten percent of projects. These findings indicate that grouping smaller maintenance actions together can lower overall maintenance costs. The possibility of scaling maintenance efforts makes work efficiency a possible metric to consider when estimating costs.

Application Type

The software's general type and application area can significantly affect the amount of maintenance it requires. For example, administrative, embedded, and real-time systems have distinct maintenance requirements. A major change in the application area such as migrating from standard invoicing to the latest local sports will also require major maintenance to implement. Some types of app maintenance are unusually sensitive to changes in the operating environment, especially if they have restrictions on their efficiency, timing, and memory usage.

Programming Standards

Software projects vary greatly in their use of established programming standards, including graphical user interfaces (GUI), databases, and programming languages. The reuse of components from other software is another factor that maintenance costs models may not take into account. Standards such as naming conventions also have a greater effect on maintenance requirements, especially when the team maintaining the software is not the same one that originally developed it.

Human Resources

The quality of human resources is a critical maintenance factor that standard models fail to take into account. For example, the availability of the original developers can greatly reduce maintenance requirements when a different team maintains the code, especially if the software is poorly documented. The relevance of the maintenance team's technical work experience is also a significant factor, including both general maintenance experience and experience with the software's particular application area.

Regulations

Regulatory compliance in data security is another metric that can increase the cost of maintenance for some organizations. While many of these regulations apply to all organizations that handle personally identifiable information (PII), those in the health and finance sectors also have their own compliance requirements. These regulations change frequently, requiring additional adaptive maintenance. Furthermore, regulatory compliance can place rigid boundary conditions on acceptable maintenance solutions.

Technical Factors

Technical factors that can affect maintenance costs include modernization techniques and support technologies like reverse engineering that can improve the quality of code. Implementing version cycles allows software engineers to change software more quickly in response to new customer requirements. Technical advances also include the development of new metrics to improve maintainability. Other possibilities include the elimination of obsolete code.

Software Properties

Many software properties can significantly affect maintenance estimates. Some projects use other units such as thousands of delivered source instructions (KDSI) and tokens to measure software size. This situation requires engineers to convert these units into units such as KLOC or FP before they can estimate maintenance costs with standard models. Older systems also tend to require more maintenance than these models predict.

Maintenance Process Models

Software that uses an applied maintenance process may require specific adjustments to its maintenance estimate. These considerations include the quality and sufficiency of the configuration management (CM) tools used. Process models for correcting errors may also require developers to collect feedback from users in the form of error reports.

Business Processes

An examination of business processes often presents an opportunity to reduce maintenance costs. For example, organizations may assume they know what their customer’s needs are, rather than using their actual needs to drive development. Maintenance can also take advantage of technological advances to improve processes.

User Requirements

User requirements that you should consider when projecting maintenance costs include volatility restrictions. In these cases, users may not want the software’s ACP to exceed a certain value each year, meaning that developers aren’t allowed to change more than a certain number of lines of code during that time.

Additionally, implementing strategies to reduce software maintenance costs and minimize maintenance costs can significantly lower overall expenses related to software upkeep.

Signs You Need to Invest in Maintenance

If you’re unsure whether your software needs maintenance, here are some signs to look out for:

• Frequent Crashes or Errors: If your software is experiencing frequent crashes or errors, it’s a clear indication that it needs maintenance. These issues can disrupt your business operations and frustrate users, making it essential to address them promptly.
• Compatibility Issues: When your software is no longer compatible with the latest operating systems or devices, it can lead to significant inefficiencies. Ensuring your software is up-to-date with the latest technological advancements is crucial for maintaining its functionality.
• Security Vulnerabilities: Software that is vulnerable to security threats or has been hacked poses a significant risk to your business. Regular maintenance helps in identifying and fixing security loopholes, protecting your data and systems from potential breaches.
• Inefficiencies in Meeting Business Needs: If your software is no longer meeting your business needs or is causing inefficiencies, it’s time to invest in maintenance. Updating and optimizing the software can help in aligning it with your current business processes and goals.
• Outdated Software: Software that is outdated and no longer supported by the vendor can lead to numerous issues, including lack of updates and security patches. Investing in maintenance ensures your software remains supported and functional.

If you’re experiencing any of these issues, it’s likely that your software needs maintenance to ensure it continues to run smoothly and efficiently.

Optimizing Software Maintenance

Optimizing software maintenance is crucial to reduce costs, improve efficiency, and ensure the software remains relevant. Here are some strategies to optimize software maintenance:

1. Regular Updates: Regularly update the software to ensure it remains compatible with the latest technologies and security patches. Keeping the software up-to-date helps in mitigating security risks and improving performance.
2. Proactive Monitoring: Implement proactive monitoring to identify potential issues before they become critical. Utilizing automatic site monitoring tools, like Uptime Robot and Site 24 x 7, can streamline the process of error detection and documentation, ultimately saving companies time and resources during software maintenance. By continuously monitoring the software, organizations can detect and address problems early, reducing the need for extensive corrective maintenance.
3. Efficient Bug Tracking: Streamline bug tracking and resolution processes to minimize the resources dedicated to corrective maintenance. Efficient bug tracking systems help in quickly identifying and fixing issues, improving the overall maintenance process.
4. Rightsizing Computing Resources: Identify resources that can be downsized or optimized to reduce unnecessary spending. By rightsizing computing resources, organizations can ensure they are not over-provisioning, which helps in reducing maintenance costs.
5. Terminating Unused Resources: Ensure that unused resources are terminated to avoid unnecessary costs. Regularly reviewing and terminating unused resources can significantly reduce maintenance expenses and improve efficiency.

Sourcing Models for Software Support

There are three primary sourcing models for software support, each with its own advantages and considerations:

1. In-house Software Maintenance: Managing software maintenance in-house, using internal resources and expertise. This model provides greater control over the maintenance process and allows for quicker response times. However, it may require significant investment in skilled personnel and infrastructure.
2. Fully Outsourced Software Maintenance: Outsourcing all software maintenance to a third-party provider. This model can be cost-effective and allows organizations to leverage the expertise of specialized maintenance providers. However, it may result in less control over the maintenance process and potential communication challenges.
3. Hybrid Model: A combination of in-house management and outsourced support resources. The hybrid model offers a balance between control and cost-efficiency, allowing organizations to retain critical maintenance functions in-house while outsourcing less critical tasks to external providers.

Finding a Software Engineer for Maintenance

Finding the right software engineer for maintenance can be a daunting task, but here are some tips to help you get started:

• Experience in Software Maintenance and Development: Look for engineers with a proven track record in software maintenance and development. Their experience will be invaluable in understanding the intricacies of your software and ensuring effective maintenance.
• Portfolio and References: Check their portfolio and ask for references to gauge their expertise and reliability. A strong portfolio and positive references are good indicators of their capability to handle your software maintenance needs.
• Necessary Skills and Expertise: Ensure the engineer has the necessary skills and expertise to work on your software. This includes familiarity with the programming languages, frameworks, and tools used in your software development.
• Freelance Engineer or Development Company: Consider whether you want to hire a freelance engineer or a software development company. Freelancers can be more flexible and cost-effective, while development companies can offer a broader range of services and support.
• Maintenance Process: Ask about their maintenance process and how they will ensure your software is updated and secure. A well-defined maintenance process is crucial for timely updates, bug fixes, and security patches.

By following these tips, you can find a qualified software engineer to help you maintain your software and ensure it continues to meet your business needs.

Best Practices for Software Maintenance

Here are some best practices for software maintenance to ensure efficiency and effectiveness:

1. Regularly Review and Update Documentation: Ensure that documentation is up-to-date and accurate to reduce dependency on specific employees. Comprehensive documentation helps new team members quickly understand the software and reduces the learning curve.
2. Implement a Proactive Maintenance Strategy: Identify and address potential issues before they become critical. Proactive maintenance helps in preventing major disruptions and ensures the software remains reliable and efficient.
3. Use Automated Tools: Leverage automated tools to streamline maintenance processes and reduce manual effort. Automation can improve the accuracy and speed of maintenance tasks, leading to cost savings and improved efficiency.
4. Prioritize User Feedback: Prioritize user feedback to ensure the software remains relevant and efficient. Regularly collecting and acting on user feedback helps in identifying areas for improvement and enhancing user satisfaction.
5. Continuously Monitor and Evaluate: Continuously monitor and evaluate the software's performance to identify areas for improvement. Regular evaluation helps in maintaining high performance and addressing issues promptly.

By following these best practices, organizations can optimize their software maintenance processes, reduce costs, and ensure their software remains effective and up-to-date.

Common Challenges in Software Maintenance

Software maintenance can be a complex and challenging process, but here are some common challenges to be aware of:

• Technical Debt: This refers to the cost of implementing quick fixes or workarounds that need to be revisited later. Accumulating technical debt can lead to more significant issues down the line, making it essential to address it proactively.
• Legacy Code: Outdated code that is no longer supported or maintained can be a significant hurdle in software maintenance. Legacy code often requires extensive refactoring to bring it up to modern standards.
• Security Vulnerabilities: Weaknesses in the software that can be exploited by hackers pose a serious threat. Regular maintenance helps in identifying and fixing these vulnerabilities, ensuring the software remains secure.
• Compatibility Issues: Issues that arise when software is not compatible with the latest operating systems or devices can disrupt functionality. Keeping the software updated with the latest technological advancements is crucial for maintaining compatibility.
• Budget Constraints: Limited budget available for software maintenance can restrict the scope of maintenance activities. Efficiently allocating resources and prioritizing critical maintenance tasks can help in managing budget constraints.

By being aware of these challenges, you can better plan and prepare for software maintenance and ensure that your software continues to run smoothly and efficiently.

Summary

Projecting costs is one of the most challenging requirements of software development. Maintenance costs can be particularly difficult to estimate with the use of lean methodologies like Agile, which don't make a clear distinction between development and maintenance. Project managers are often in the position of needing to project maintenance costs before the project has even entered development.

A number of standardized models for accomplishing this task are now available. These models generally require the user to quantify many aspects of the project, which is typically difficult to do. It's particularly hard to provide a meaningful number to complexity due to the many ways of measuring this property. The complexity of software development also means that standard models fail to consider many factors that greatly affect the effort needed to maintain software.

Choosing the right software solution is crucial for effective cost management, as it can mitigate the challenges and costs associated with maintaining outdated systems while allowing for future growth and customization.