Abstract The dictionary defines maintenance as, “The work of keeping something in order.” However, this definition is not necessarily suitable for software. Software maintenance differs from hardware maintenance because software does not wear out physically, but often becomes less useful with age. Software usually comes with undiscovered flaws. Software maintenance is therefore: “The process of modifying existing operational software while keeping primary functions intact.” Maintenance typically accounts for more than fifty percent of the systems lifecycle costs. While software maintenance can be viewed as a level of effort, there are quality, functionality, reliability, cost, and schedule implications that can be mitigated through the use of parametric estimation techniques.
1 INTRODUCTION One of the biggest challenges software engineers face is change control management. It is estimated that the cost of change control can be between 40% and 70% of the life cycle cost. Software engineers have hoped that new languages and new processes would significantly reduce this number; however, this has not been the case. Essentially, this is because software still ships with a significant number of defects. Capers Jones estimates that about 5 bugs per feature point were made during development. Watts Humphrey found “… even experienced software engineers normally inject 100 or more defects per KSLOC. Capers Jones says,” A series of studies where software defect density ranges from 49.5 to 94.5 errors per thousand lines of code. This article is intended to first discuss the fundamentals of software maintenance and present alternative approaches to estimating software maintenance. An important element to note is that development and management decisions made during the development process can have a significant impact. on the development costs and the resulting maintenance costs.
2. SOFTWARE MAINTENANCE Maintenance activities include all work performed after delivery and should be distinguished from block modifications that represent significant design and development effort and replace a previously released software package. These maintenance activities can be quite diverse, and it helps to determine exactly which activities should be included in a maintenance effort estimate after delivery. Once maintenance activities are defined, they can be assessed in a very different light than when they are simply referred to as “maintenance”. Software maintenance differs from hardware maintenance in that software does not physically wear out, but software often becomes less useful as it ages, and it can come with undiscovered flaws. In addition to the undetected flaws, it is common for a number of known flaws to go from the development organization to the maintenance group. An accurate estimate of the effort required to maintain the delivered software is aided by the breakdown of the overall effort into the different activities that make up the whole process.
3. APPROACH TO THE MAINTENANCE ISSUE Maintenance is a complicated and structured process. In his textbook, Estimating Software Intensive Systems, Richard Stuzke outlines the typical software maintenance process. Obviously, the process is more than just writing new code.
The following checklist can be used to examine the realism and accuracy of maintenance requirements.
o Which software is maintained?
o How long does the system need to be maintained?
o Do you estimate the entire maintenance problem, or only incremental maintenance?
o What maintenance is required?
o Is that what maintenance is actually called a new construction project?
o Who does the maintenance? Will it be done organically by the original developer? Will there be a separate team? Will there be a separate organization?
o Will the administrators use the same tools that were used during development? Are own tools required for maintenance?
o How many Commercial-Off-The-Shelf (COTS) is there? How closely are the interfaces linked?
o Some follow-up developments can be disguised as maintenance. This will either boost maintenance figures or lead to shortages if basic maintenance is discarded. With these questions, you can ask yourself whether alimony is fairly represented.
o Is the activity really a step-by-step improvement?
o Are healthy parts of the original code being rewritten or changed?
o Will additional personnel be recruited to perform the upgrade?
o Is the maintenance effort schedule regular and reasonably flat, or does it include a workforce schedule that looks like newly developed?
4. HEALTH CHECKS While health checks should be pursued from year to year, they should not be attempted for overall development. The reason for this is that maintenance work can be carried out endlessly, making life cycle rules useless. As an example, consider Grady (p. 17):
We spend about 2-3 times as much effort on maintaining and improving software as we do on creating new software.
These and similar observations apply at the organizational level and higher, but not for a specific project. Any development group with a history will be caught up in the long tail of their many completed projects, which still require indefinite attention. Here are a few quick health checks:
o One maintainer can process approximately 10,000 lines per year.
o The total life cycle effort is typically 40% development and 60% maintenance.
o Maintenance costs are on average one sixth of the annual development costs.
o Successful systems are typically maintained for 10 to 20 years.
Finally, as with development, the amount of code that is new or modified makes a difference. The effective size, that is, the equivalent effort if all the work was new code, is still the most important input for both development and maintenance costs.
5. FIVE ALTERNATIVE APPROACHES All estimation software techniques must be able to model the theory and likely outcome in the real world. The real scenario is that the overlay of changes on changes makes software increasingly difficult to maintain and thus less useful over time. Maintenance effort estimation techniques range from the simplistic effort level method, through more thoughtful analysis and adjustments to development practice, to using parametric models to use historical data to project future needs.
5.1 Degree of exertion As is sometimes the case in the development environment, software maintenance can be modeled as a level of effort. Given the repair category of activities and the large variance they show, this approach has clear shortcomings. In this approach, the effort to maintain software is based on size and type.
5.2 Degree of exertion Plus Stuzke suggested that software maintenance should start with a basic effort (the minimum of people needed to have a core competency, and then that basic core personnel should be adjusted by assessing three additional factors: configuration management, quality assurance, and project management. affect software maintenance.
5.3 Maintenance change factor Software Cost Estimation with COCOMO II (Boehm 2000) proposes a deceptively simple, but also quite useful methodology to determine annual maintenance. Maintenance is one of the menu choices in the menu bar. In COCOMO II, Maintenance includes the process of modifying existing operational software while keeping primary functions intact. This process excludes:
o Major redesign and redevelopment (more than 50% new code) of a new software product with essentially the same functions.
o Design and development of an extensive (more than 20% of the source instructions consisting of the existing product) interfacing software package that requires relatively little redesign of the existing product.
o Data processing system operations, data entry and change of values in the database.
The maintenance calculations are strongly based on the Maintenance Change Factor (MCF) and the Maintenance Adjustment Factor (MAF). The MCF is similar to the Annual Traffic Change in COCOMO81, except that maintenance periods other than one year can be used. The resulting maintenance effort estimation formula is the same as the COCOMO II Post Architecture development model.
As mentioned earlier, three development maintenance cost factors differ. Those cost factors are software reliability, modern programming methods and planning. COCOMO II assumes that increased investments in software reliability and the use of modern programming practices during software development have a strong positive effect on the maintenance phase.
Annual maintenance effort = (Annual change traffic) * (Original software development effort)
The amount of Original software development effort refers to the total effort (man-months or other unit of measure) expended during development, even if it is a multi-year project.
The Annual Change Traffic multiplier is the portion of the total software that must be changed during the year. This is relatively easy to obtain from technical estimates. Developers often keep change lists or feel that proportional changes are needed even before development is complete.
5.4 Management of software maintenance costs through development techniques and management decisions during development
When it comes to maintenance, “a cent spent is a pound saved.” Better development practices (even if they are more expensive) can significantly reduce maintenance effort and lower overall life cycle costs. The more effort is put into development, the less maintenance is required. For example, the cost and schedule of software development can be significantly impacted (reduced) by growing the number of defects delivered. This reduction in costs and planning is more than offset by the increase in maintenance costs. The following discussion is an example of how management decisions can significantly affect / reduce software maintenance costs.
Lloyd Huff and George Novak of Lockheed Martin Aeronautics, in their paper “Lockheed Martin Aeronautics Performance Based Software Sustainment for the F-35 Lightning II”, propose a series of development and management decisions to influence and reduce software maintenance costs. They propose an eight-step process to estimate and monitor software maintenance. Their suggested steps are:
1. Strive for commonality
2. Apply industrial engineering practices to software
4. Apply a holistic approach to sustainability
5. Develop highly maintainable systems and software
6. Manage the standard software
Plan for the unexpected
8. Analyze and refine the Business Case Software Sustainment (use parametric cost estimates for software maintenance)
5.5 A parametric assessment of software maintenance
With parametric models such as SEER for Software, maintenance can be modeled in two ways:
Estimate maintenance as part of the total life cycle cost. Choosing the correct parameters for the maintenance category involves an estimate of the maintenance effort with the development estimate for the individual software program. Several reports and charts show breakdowns of development vs. maintenance effort. This method is best used to evaluate the life cycle costs for each individual software program.
Estimate maintenance as a separate activity. Using the correct maintenance parameters for the software to be maintained, you can model the maintenance effort as a separate activity. This method allows you to refine your maintenance estimate by adjusting parameters. Maintenance size must be the same as development size, but entered as any pre-existing code. This method can also be useful for extracting the total project maintenance costs from the project development costs.
A good parametric estimate for maintenance covers a wide range of information. Critical information for completing a software maintenance estimate is the size or amount of software that will be maintained, the quality of that software, the quality and availability of the documentation, and the type or amount of maintenance that will be performed. Many organizations do not really estimate maintenance costs; they just have a budget for software maintenance. In this case, a parametric model must be used to calculate how much maintenance can actually be performed with the specified budget.
Maintenance estimation and planning are critical activities if the software is to function properly during its expected life. Even with a limited budget, a plan can be made to use the available resources in the most efficient and productive way. If you look at the diagram above, you can see that not only do the many inputs affect maintenance, but there are also several important outputs that provide the information needed to plan a successful maintenance.
6. Conclusion The conclusions of this article are:
o Software maintenance can be modeled using a simplistic method such as Level of Effort Staffing, but this technique has significant drawbacks.
o Software maintenance costs can be significantly affected by management decisions during the development process.
o Software maintenance can be accurately estimated using parametric processes.
o Software maintenance is best modeled when development and management decisions are linked to parametric cost estimation techniques.
REFERENCES  Software Maintenance Concepts and Practices (Second Edition) by Penny Grubb and Armstrong Takang, World Scientific, 2005.
 Estimate software intensive systems; Richard Stuzke, 2005, Addison-Wesley.
 Lloyd Huff, George Novak; Lockheed Martin Aviation; Lockheed Martin Aeronautics Performance Based Software Sustainment for the F-35 Lightning II.
 G. Edward Bryan, “CP-6: Quality and Productivity Measures in the 15-Year Life Cycle of an Operating System”, Software Quality Journal 2, 129-144, June 1993.
 Software sizing, estimation and risk management; Daniel D. Galorath, Michael W. Evans, 2006, Auerbach Publications.