Abstract The dictionary defines upkeep as, “The work of keeping a product in right order.” However, this definition does not always fit for a program. Software maintenance is different from hardware maintenance because software program doesn’t actually wear out, but often gets less useful with age. Software is commonly delivered with undiscovered flaws. Therefore, software maintenance is: “The process of altering existing operational software while passing on to its key roles intact.” Maintenance typically exceeds fifty % of the systems’ life cycle cost. While software maintenance could be treated as a quality of energy activity, you will find consequences on quality, functionality, reliability, cost and schedule which could be mitigated through the utilization of parametric estimation techniques.
1. INTRODUCTION Among the biggest challenges facing software engineers is the management of change control. It’s been estimated that the price of change management could be between forty % and 70 % of the life cycle expenses. Software engineers have hoped that new languages and new process would greatly reduce these numbers; however this has not been the case. Essentially this’s because software program is still delivered with a significant number of defects. Capers Jones estimates that there’re aproximatelly five bugs per Function Point developed during Development. Watts Humphrey found “… even experienced software engineers generally inject hundred or perhaps more defects per KSLOC. Capers Jones says, “A series of studies the defect density of a software application ranges from 49.5 in order to 94.5 errors per 1000 lines of code.” The purpose of this article will be to first review the fundamentals of software maintenance and to present alternative techniques to estimating software upkeep. A key component to note is that development and management decisions made throughout the development process can substantially affect the developmental price tag and the resulting maintenance costs.
2. SOFTWARE MAINTENANCE Maintenance activities include a number of effort carried out post-delivery and needs to be distinguished from obstruct modifications which represent considerable development and design energy and supersede a previously released software program. These maintenance activities is extremely different, and it helps you to determine precisely what post delivery activities are to be incorporated in an estimate of maintenance work. Maintenance activities, once defined, can easily be examined in a pretty different light than when called simply “maintenance”. Although software often gets less useful with age and it could be delivered with undiscovered flaws, software maintenance differs from hardware maintenance because software does not actually wear out. Along with the undiscovered flaws, it is widespread that some number of known defects pass from the development organization to the repairs and maintenance group. Accurate estimation of the time and effort needed to keep delivered software is aided by the decomposition of the general effort into the various activities that constitute the whole process.
3. APPROACHING THE MAINTENANCE ISSUE Maintenance is a structured and complicated process. In the textbook of his, Estimating Software Intensive Systems, the typical software maintenance process is outlined by Richard Stuzke. It’s clear that the process is much more than just writing completely new code.
The following checklist enables you to check out the realism and accuracy of maintenance requirements.
o Which fragments of software program will be maintained?
o How long will the technique need to be maintained?
o Are you estimating entire maintenance problem, or perhaps just incremental maintenance?
o What level of upkeep is required?
o Will be that which has been called maintenance in fact a new development project?
o Who will do the maintenance? Will it be accomplished organically by the first developer? Will there be a separate staff members? Will there be a standalone organization?
o Will maintainers be using similar equipment used during development? Are any proprietary resources necessary for maintenance?
o The amount of Commercial-Off-The-Shelf (COTS) is present? How tightly coupled would be the interfaces?
o Some follow on development may be disguised as maintenance. This may either inflate maintenance figures, or else cause shortfalls if basic maintenance gets pushed aside. These questions will help you ask whether maintenance is being actually represented.
o Would be the exercise really an incremental improvement?
o Actually are good chunks of the initial code being rewritten or changed?
o Will added staff be brought in to execute the upgrade?
o Will be the maintenance effort schedule regular and quite flat, or even does it consist of staffing humps which look like new development?
4. SANITY CHECKS Although sanity inspections can be sought on a year-by-year schedule, they should not be attempted for overall development. The reason for this is that maintenance activities can be carried on indefinitely, rendering any life cycle rules useless. As an example, consider Grady (p. 17):
We spend aproximatelly two to 3 times as much effort enhancing and maintaining software program as we spend creating new software.
This and similar observations apply at an organizational level and higher, however, not for a particular job. Any development set with a the historical past would be embroiled in the long tail ends of their numerous delivered projects, still wanting long attention. Allow me to share a couple of quick sanity checks:
o One maintainer can handle aproximatelly 10,000 lines per year.
o Overall life-cycle effort is typically 40 % development as well as sixty % maintenance.
o Maintenance costs typically are one-sixth of yearly development costs.
o Successful systems tend to be maintained for ten to 20 years.
Last but not least, as in development, the volume of code which is new as opposed to modified is important. The effective size, that’s, the equivalent energy if all the work were completely new code, is also the key input for both maintenance and development cost estimation.
5. 5 ALTERNATIVE APPROACHES All program estimation methods need to be able to model the theory and also the likely actual result. The real life scenario is that after a while, the overlay of changes upon changes makes software increasingly hard to maintain and thus much less useful. Maintenance effort estimation techniques range from the easy quality of energy method, through much more careful analysis and development practice modifications, to the utilization of parametric types in order to use historical data to project later needs.
5.1 Degree of Effort As is often the case in the development environment, software maintenance can be modeled as a degree of effort activity. Considering the repair category activities and also the great variance which they present, this approach clearly has deficiencies. In this approach, a quality of effort to maintain software is based on type and size.
5.2 Degree of Effort Plus Stuzke suggested that software maintenance starts with elementary level of energy (minimum folks needed to use a core competency then that that basic core staff need to be modified by assessing three more factors; setup management, quality assurance, and project management. Some of the additional factors affecting software maintenance were addrest by his process.
Although also quite useful methodology for determining annual maintenance, 5.3 Maintenance Change Factor Software Cost Estimation with COCOMO II (Boehm 2000) proposes a deceivingly simple. Maintenance is among the menu selections in the selection bar. In COCOMO II Maintenance entails the procedure for modifying existing operational software while giving its primary tasks intact. This process excludes:
re-development and o Major re design (more than 50 % brand new code) of a new software product performing substantially the same functions.
o Design and development of a sizeable (more than 20 % of the source instructions comprising the present product) interfacing software program which requires fairly very little redesigning of the existing product.
o Data processing system operations, data entry, and modification of values in the database.
The maintenance calculations are heavily based upon the Maintenance Change Factor (mcf) and The Maintenance Adjustment Factor (MAF). The MCF is akin to the Annual modification Traffic in COCOMO81, except that maintenance periods apart from 1 year may be used. The ensuing maintenance energy estimation system is equivalent to the COCOMO II Post Architecture development model.
As said previously, three price drivers for maintenance differ from expansion. Those cost drivers are a program reliability, modern programming practices, and schedule. COCOMO II assumes that improved investment in a program reliability and use of modern programming habits during software development has a strong positive effect upon the maintenance phase.
Annual Maintenance Effort = (Annual Change Traffic) * (Original Software Development Effort)
The quantity Original Software Development Effort refers to the entire effort (other unit or person months of measure) expended throughout advancement, even if a multi year project.
The multiplier Annual Change Traffic is the proportion of the entire software program to be modified during the season. This is reasonably straightforward to get from engineering estimates. Developers usually maintain change lists, or even have a feeling of proportional switch being needed while before development is finished.
5.4 Managing Software Maintenance Costs by Developmental Techniques as well as Management Decisions During Development
When it comes to maintenance, “a penny invested is a pound saved.” Better development strategies (even if more expensive) can considerably reduce maintenance effort, and reduce overall life cycle cost. The more energy put into advancement, the less required in maintenance. As an example, the program development cost and also routine can be significantly impacted (reduced) by permitting the number of defects delivered grow. This cost and schedule reduction is more than offset by the increase in maintenance cost. The following discussion is a good example of exactly how management decision can substantially affect/reduce software maintenance costs.
Lloyd Huff and George Novak of Lockheed Martin Aeronautics within their cardboard “Lockheed Martin Aeronautics Performance Based Software Sustainment for the F 35 Lightning II” propose a series of development plus management decision designed to impact and reduce software maintenance costs. An eight step process to estimate and control software maintenance are proposed by them. Their proposed steps are:
1. Strive for Commonality
2. Apply Industrial Engineering Practices to Software
4. Adopt a Holistic Approach to Sustainment
5. Develop Highly Maintainable Systems and Software
6. Manage the Off-the-Shelf Software
7. For the Unexpected
8. Analyze and Refine the software Sustainment Business Case (use Parametric program sustainment expense estimates)
5.5 A Parametric Assessment of Software Maintenance
Parametric models like SEER for Software allow maintenance to be modeled in possibly of two ways:
Estimating maintenance as a part of the whole lifecycle cost. Choosing the right Maintenance category parameters are going to include an estimation of maintenance attempt with the development estimate for the private software program. Charts and a number of reports show breakdowns of development vs. maintenance effort. This strategy is better used to assess life cycle costs for each individual software program.
Estimating maintenance as a distinct pursuit. Using the appropriate maintenance parameters for the software program to be maintained you are able to model the maintenance attempt as a distinct pursuit. This procedure will allow you to fine tune your upkeep estimate by adjusting parameters. Maintenance size needs to be the same as development sizing, but should be entered as all pre existing code. This technique can also be useful in breaking away total project maintenance expenses from project development costs.
An excellent parametric estimate for maintenance includes a wide variety of info. Information that is critical for doing a software maintenance estimate would be the size or amount of a software application which will be taken care of, the quality of that software program, the quality and availability of the documentation, and the type or amount of maintenance that will be accomplished. Lots of organizations don’t really estimate maintenance costs; they basically end up with a financial budget for software maintenance. In this instance, a parametric design should be used to compute how much maintenance can in fact be carried out with the given budget.
estimating and Planning for maintenance are critical activities in case the software is needed to work effectively throughout its expected life. Even with a limited budget, a weight loss plan could be made to make use of the resources available in the most powerful, effective manner. Taking a look at the diagram above, you can see that not just are the multiple inputs that will affect the maintenance, but you will find several crucial outputs that offer the info needed to plan a booming maintenance effort.
6. Conclusion The conclusions of this article are:
o Software maintenance can be modeled using a simple method as Level of Effort Staffing, but this technique has significant drawbacks.
o Software maintenance costs are generally significantly impacted by management decisions throughout the developmental process.
o Software maintenance can be accurately estimated with the use of parametric processes.
o Software maintenance is perfect modeled when progress and management decisions are in addition to parametric cost estimation techniques.