Abstract The dictionary defines maintenance as, “The work of keeping something in proper order.” However, this definition does not necessarily fit for software. BNH Software maintenance is different from hardware maintenance because software doesn’t physically wear out, but often gets less useful with age. Software is typically deliver with undiscovered flaws. Therefore, software maintenance is: “The process of modifying existing operational software while leaving its primary functions intact.” Maintenance typically exceeds fifty percent of the systems’ life cycle cost . While software maintenance can be treated as a level of effort activity, there are consequences on quality, functionality, reliability, cost and schedule that can be mitigated through the use of parametric estimation techniques.

1. INTRODUCTION One of the greatest challenges facing software engineers is the management of change control. It has been estimate that the cost of change control can be between 40% and 70% of the life cycle costs . Software engineers have hoped that new languages and new process would greatly reduce these numbers; however this has not been the case. Fundamentally this is because software is still delivered with a significant number of defects. Capers Jones estimates that there are about 5 bugs per Function Point create during Development . Watts Humphrey found “… even experienced software engineers normally inject 100 or more defects per KSLOC .

Capers Jones says, “A series of studies the defect density of software ranges from 49.5 to 94.5 errors per thousand lines of code .” The purpose of this article is to first review the fundamentals of software maintenance and to present alternative approaches to estimating software maintenance. A key element to note is that development and management decisions made during the development process can significantly affect the developmental cost and the resulting maintenance costs.

2. SOFTWARE MAINTENANCE Maintenance activities include all work carried out post-delivery and should distinguished from block modifications which represent significant design and development effort and supersede a previously released software package. These maintenance activities can be quite diverse, and it helps to identify exactly what post-delivery activities are to included in an estimate of maintenance effort. Maintenance activities, once defined, may evaluated in a quite different light than when called simply “maintenance”. Software maintenance is different from hardware maintenance because software doesn’t physically wear out, but software often gets less useful with age and it may delivered with undiscovered flaws.

In addition to the undiscovered flaws, it is common that some number of known defects pass from the development organization to the maintenance group. Accurate estimation of the effort require to maintain deliver software is aided by the decomposition of the overall effort into the various activities that make up the whole process.

3. APPROACHING 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. It is apparent that the process is more than just writing new code.

The following checklist can used to explore the realism and accuracy of maintenance requirements.

• Which pieces of software will maintained?
• How long will the system need to maintained?
• Are you estimating the entire maintenance problem, or just incremental maintenance?
• What level of maintenance is require?
• Is that which is being call maintenance in fact a new development project?
• Who will do the maintenance? Will it done organically by the original developer? Will there be a separate team? Will there be a separate organization?
• Will maintainers be using the same tools used during development? Are any proprietary tools require for maintenance?
• How much Commercial-Off-The-Shelf (COTS) is there? How tightly coupled are the interfaces?
• Some follow-on development may disguised as maintenance. This will either inflate maintenance figures, or else cause shortfalls if basic maintenance gets push aside. These questions will help you ask whether maintenance is being honestly represent.
• Is the activity really an incremental improvement?
• Are healthy chunks of the original code being rewritten or changed?
• Will additional staff brought in to perform the upgrade?
• Is the maintenance effort schedule regular and fairly flat, or does it contain staffing humps that look like new development?