Projecting Costs in Software Maintenance
May 21, 2020 / Bryan Reynolds
Reading Time: 10 minutes
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. The importance of software maintenance is becoming increasingly important due to the accelerating rate of hardware obsolescence.
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.
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 60 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.
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 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 maintenance costs. 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.
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.
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.
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.
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 are distinct interactive queries from the user. They consist of user commands requiring a response from the software.
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.
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
- Heavily used configuration
- Transaction rate
- On-line data entry
- End-user efficiency
- On-line update
- Complex processing
- 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:
|Required software reliability
|Size of application database
|Complexity of the product
|Run-time performance constraints
|Volatility of the virtual machine environment
|Required turnabout time
|Software engineer capability
|Virtual machine experience
|Programming language experience
|Application of software engineering methods
|Use of software tools
|Required development schedule
Multiply the effort multipliers together to obtain the EAF. The following equation will then provide the effort needed to develop the software:
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.
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. 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.
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.
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 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.
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.
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.
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.
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.
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 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.
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.
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 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.
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.