Implications of Software Maintenance on Cost and Schedule : Abstract The dictionary defines maintenance as, “The job of keeping things in the right order.” However, this definition is not always suitable for software. Software maintenance differs from hardware maintenance in that software does not suffer physical damage, but often becomes less useful as it ages.
Software usually ships with undiscovered flaws. Therefore, software maintenance is: “The process of modifying existing operational software while leaving its main functions intact.” Maintenance typically exceeds fifty percent of the system’s life cycle cost. While software maintenance can be treated as a level of business activity, there are consequences on quality, functionality, reliability, cost and schedule that can be reduced through the use of parametric estimation techniques.
1. INTRODUCTION One of the biggest challenges facing software engineers is change control management. It is estimated that change control costs can range between 40% and 70% of life cycle costs. Software engineers hope that new languages and new processes will greatly reduce these numbers; But this is not the case. Basically this is because the software still ships with a large number of defects.
Capers Jones estimates that there are about 5 bugs per Function Point created during Development. Watts Humphrey found “…even experienced software engineers typically inject 100 or more defects per KSLOC. Capers Jones says, “A series of software defect density studies ranged from 49.5 to 94.5 errors per thousand lines of code.” this article is the first to review the fundamentals of software maintenance and present an alternative approach to estimating software maintenance A key element to note is that development and management decisions made during the development process can significantly affect the resulting development costs and maintenance costs.
2. SOFTWARE MAINTENANCE Maintenance activities include all work performed post-delivery and should be distinguished from block modifications that represent significant design and development efforts and replace previously released software packages. These maintenance activities can vary widely, and it helps to identify exactly what post-delivery activities should be included in the maintenance effort estimate.
Maintenance activities, once defined, can be evaluated in a very different way than if they were simply called “maintenance”. Software maintenance differs from hardware maintenance in that the software does not physically wear out, but software often becomes less useful as it ages and may come with undiscovered flaws.
In addition to undiscovered defects, typically a number of known defects move from the development organization to the maintenance group. Accurate estimation of the effort required to maintain the delivered software is aided by breaking down the overall effort into the various activities that make up the entire process.
3. APPROACHING MAINTENANCE PROBLEMS Maintenance is a complex and structured process. In his textbook, Estimating Software Intensive Systems, Richard Stuzke outlines the typical software maintenance process. It’s clear that the process is more than just writing new code.
The following checklist can be used to explore the realism and accuracy of maintenance requirements.
o Which software will be maintained?
o How long does the system need to be maintained?
o Do you expect all maintenance issues, or just additional maintenance?
o What level of maintenance is required?
o Is so-called maintenance actually a new development project?
o Who will do the maintenance? Will it be done organically by the original developer? Will there be separate teams? Will there be a separate organization?
o Will maintainers use the same tools used during development? Are there any proprietary tools required for maintenance?
o How many Commercial-Off-The-Shelf (COTS) are there? How close is the interface?
o Some advanced developments may be disguised as maintenance. This will increase the number of treatments, or cause shortages if basic maintenance is neglected. These questions will help you ask if maintenance is fairly represented.
o Is the activity really a gradual improvement?
o Is a healthy snippet of the original code being rewritten or changed?
o Will additional staff be brought in to make repairs?
o Is the maintenance effort schedule regular and fairly flat, or is there a staff hump that looks like a new development?
4. OBLIGATION CHECKS Although sanity checks should be carried out annually, they should not be carried out for overall development. The reason for this is that maintenance activities can be performed indefinitely, rendering lifecycle rules useless. For example, consider Grady (p. 17):
We spend about 2 to 3 times more effort maintaining and improving software than we spend creating new software.
These and similar observations apply at the organizational level and higher, but not to a specific project. Any development group with history will be involved at the long end of the many projects they provide, still needing unlimited attention. Here are some quick sanity checks:
o One maintainer can handle about 10,000 rows per year.
o Overall lifecycle effort typically 40% development and 60% maintenance.
o The average maintenance cost is one-sixth of the annual development cost.
o Successful systems are usually maintained for 10 to 20 years.
Finally, as in development, the amount of code that is new versus modified makes a difference. The effective measure, i.e. the same effort if all the work was new code, is still the main input for the estimation of development and maintenance costs.
5. FIVE ALTERNATIVE APPROACHES All software estimation techniques must be capable of modeling theoretical and probable real-world outcomes. The real world scenario is that over time, change overlays on changes make the software increasingly difficult to maintain and thus less useful. Maintenance effort estimation techniques range from simple effort level methods, through more thoughtful analysis and modification of development practices, to the use of parametric models to use historical data to project future requirements.
5.1 Effort Level As is sometimes the case in a development environment, software maintenance can be modeled as an activity level of effort. Given the categories of remedial activities and the large differences they represent, this approach clearly has drawbacks. In this approach, the level of effort to maintain the software is based on its size and type.
5.2 Effort Level Plus Stuzke proposes that software maintenance starts with a basic level of effort (minimum people required to have core competencies and then that basic core staff should be modified by assessing three additional factors; configuration management, quality assurance, and project management. affecting software maintenance.
5.3 Estimating Software Costs of Change Factors of Maintenance with COCOMO II (Boehm 2000) proposes a very simple, but also quite useful, methodology for determining annual maintenance. Maintenance is one of the menu options in the menu bar. In COCOMO II Maintenance includes the process of modifying existing operational software while leaving its main functions intact. This process does not include:
o Massive redesign and redevelopment (over 50% new code) of new software products that perform almost the same functions.
o Design and development of a sufficiently large interface software package (more than 20% of the source instructions comprise the existing product) requiring relatively little redesign of the existing product.
o Operation of data processing systems, data entry and modification of values in databases.
Maintenance calculation is based on Maintenance Change Factor (MCF) and 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 stated earlier, the three cost drivers for maintenance differ from development. The cost drivers are software reliability, modern programming practices and schedules. COCOMO II assumes that increased investment in software reliability and use of modern programming practices during software development has a strong positive effect on the maintenance phase.
Annual Maintenance Effort = (Annual Change Traffic) * (Original Software Development Effort)
Quantity of Original Software Development Effort refers to the total effort (person-months or other unit of measure) expended during development, even if the project is multi-year.
The Annual Traffic Change Multiplier is the overall proportion of software that will be modified during the year. This is relatively easy to obtain from engineering estimates. Developers often maintain a change list, or feel that a proportional change is needed even before development is complete.
5.4 Managing Software Maintenance Costs with Development Techniques and Management Decisions During Development
In terms of maintenance, “a penny spent is a pound saved.” Better development practices (even if more expensive) can significantly reduce maintenance efforts, and reduce overall lifecycle costs. The more effort put into development, the less is required in maintenance.
For example, software development costs and schedules can be significantly affected (reduced) by allowing the number of proposed defects to increase. These cost and schedule reductions were more than offset by increased 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 designed to impact and reduce software maintenance costs. They propose an eight-step process for estimating and controlling software maintenance. The steps they propose are:
1. Strive for Commonality
2. Applying Industrial Engineering Practices to Software
4. Adopt a Holistic Approach to Sustainability
5. Develop Highly Maintainable Systems and Software
6. Manage Off-the-shelf Software
7. Plan for the Unexpected
8. Analyze and Improve the Software Sustainability Business Case (use Parametric software sustainability cost estimates)
5.5 Software Maintenance Parametric Assessment
Parametric models such as SEER for Software allow maintenance to be modeled in one of two ways:
Estimating maintenance as part of total life cycle costs. Selecting the appropriate Maintenance category parameter will include estimated maintenance effort with development estimates for each software program. Several reports and charts show a breakdown of development vs. maintenance efforts. This method is best used to evaluate the life cycle costs for each individual software program.
Think of maintenance as a separate activity. Using the appropriate maintenance parameters for the software to be maintained, you can model maintenance efforts as separate activities. This method will allow you to fine-tune your treatment estimate by adjusting the parameters.
The maintenance measure must be the same as the development measure, but must be included as all pre-existing code. This method can also be useful in breaking down the total project maintenance costs from the project development costs.
A good parametric estimate for maintenance includes a wide range of information. Important information for completing a software maintenance estimate is the size or amount of software to be maintained, software quality, documentation quality and availability, and the type or amount of maintenance to be performed.
Many organizations don’t really estimate maintenance costs; they only have budget for software maintenance. In this case, a parametric model should be used to calculate how much maintenance can actually be done with the given budget.
Estimation and planning for maintenance are essential activities if software is required to function properly throughout its expected life. Even with a limited budget, plans can be made to use the available resources in the most efficient and productive way. Looking at the diagram above, you can see that not only are there several inputs that affect maintenance, but there are several key outputs that provide the information needed to plan a successful maintenance effort.
6. Conclusion The conclusions of this article are:
o Software maintenance can be modeled using simple methods 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 estimated accurately using a parametric process.
o Software maintenance is best modeled when development and management decisions are combined with parametric cost estimation techniques.
REFERENCES  Software Maintenance Concepts and Practices (Second Edition) by Penny Grubb and Armstrong Takang, World Scientific, 2005.
 Estimating Software Intensive Systems; Richard Stuzke, 2005, Addison-Wesley.
 Lloyd Huff, George Novak; Lockheed Martin Aeronautics; Lockheed Martin Aeronautics Performance Based Software Sustainment for the F-35 Lightning II.
 G. Edward Bryan, “CP-6: Measurement of Quality and Productivity in the 15-Year Life Cycle of Operating Systems,” Journal of Software Quality 2, 129-144, June 1993.
 Software Size, Estimation, and Risk Management; Daniel D. Galorath, Michael W. Evans, 2006, Auerbach Publications.