Abstract The dictionary defines care as, “The work of keeping a thing in right order.” However, this definition does not necessarily fit for a program. Even thought often gets less useful with age, software maintenance is distinct from hardware maintenance because software program does not physically wear out. Software is commonly sent with undiscovered flaws. Therefore, software upkeep is: “The process of altering existing operational software while leaving its key roles intact.” Maintenance typically exceeds 50 % of the systems’ life cycle cost. While software maintenance can be regarded as a quality of energy activity, you will find consequences on quality, reliability, functionality, cost and schedule which could be mitigated through the utilization of parametric estimation techniques.
1. INTRODUCTION Among the biggest problems facing software engineers is the management of change control. It has been estimated that the cost of change control could be between 40 % and 70 % of the life cycle expenses. Software engineers have hoped that new process and new languages would greatly reduce these numbers; however this has not been the case. Basically this is because software program continues to be delivered with some defects. Capers Jones estimates that there are about five bugs per Function Point developed during Development. Watts Humphrey found “… even experienced software engineers typically inject hundred or perhaps more defects per KSLOC. Capers Jones reveals, “A series of studies the defect density of software ranges from 49.5 to be able 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 strategies to estimating software maintenance. A key element to note is that development and management decisions made throughout the development process could substantially impact the developmental cost and the resulting maintenance costs.
2. SOFTWARE MAINTENANCE Maintenance activities include many energy carried out post-delivery and must be distinguished from obstruct modifications that stand for significant design and development effort and supersede a previously released software package. These maintenance activities could be very varied, and it helps to determine just what post-delivery activities are to be incorporated in an appraisal of maintenance work. Maintenance activities, once defined, could very well be assessed in a quite different light than when called only “maintenance”. Even thought software often gets significantly less useful with age and it may be delivered with undiscovered flaws, software maintenance differs from hardware maintenance because software program doesn’t literally wear out. In addition to the undiscovered flaws, it’s common that some number of recognized defects pass from the improvement group to the maintenance team. Accurate estimation of the time and effort necessary to keep delivered a program is aided by the decomposition of the actual effort into the different activities that form the whole process.
3. APPROACHING THE MAINTENANCE ISSUE Maintenance is a complicated and structured process. In the textbook of his, Estimating Software Intensive Systems, the typical software maintenance process is outlined by Richard Stuzke. It’s apparent that the method is a lot more than simply writing brand new code.
The following checklist are useful to explore the realism and correctness of maintenance requirements.
o Which fragments of application will be maintained?
o How very long will the technique need to be maintained?
o Are you estimating entire maintenance problem, or even just incremental maintenance?
o What level of maintenance is required?
o Would be that which has been called maintenance actually a whole new development project?
o Who’ll do the maintenance? Will it be done without chemicals by the original developer? Will there be a distinct staff members? Will there be a standalone organization?
o Will maintainers be using the same resources used during development? Are any proprietary tools necessary for maintenance?
o Just how much Commercial-Off-The-Shelf (COTS) is present? How tightly coupled are the interfaces?
o Some follow-on development may be disguised as maintenance. This should either inflate maintenance figures, otherwise cause shortfalls if simple maintenance gets pushed aside. These questions are going to help you ask whether maintenance has been actually represented.
o Would be the activity really an incremental improvement?
o Would be healthy chunks of the first code being rewritten or changed?
o Will additional staff be introduced to perform the upgrade?
o Would be the maintenance effort schedule regular and quite dull, or perhaps will do it contain staffing humps which look like new development?
4. SANITY CHECKS Although sanity checks should be wanted on a year-by-year foundation, they shouldn’t be attempted for overall development. The reason for this is that maintenance activities can be taken on forever, rendering any life cycle rules useless. As an example, consider Grady (p. 17):
We spend about 2 to 3 times as much effort enhancing and maintaining software program as we spend producing new software.
This and similar observations implement at an organizational levels and higher, but not for a certain project. Any development set with a history would be embroiled in the lengthy tail ends of their numerous delivered projects, still requiring indefinite attention. Listed here are a couple of quick sanity checks:
o One maintainer is able to handle aproximatelly 10,000 lines per season.
o Overall life-cycle effort is typically 40 % development as well as sixty % maintenance.
o Maintenance costs on average are one sixth of yearly development costs.
o Successful systems are maintained for ten to twenty years.
Last but not least, as in development, the amount of code that is new versus modified makes a difference. The better size, that is, the equivalent energy if all of the work were completely new code, is still the main key input for both maintenance and development cost estimation.
5. Five ALTERNATIVE APPROACHES All program estimation techniques have to be ready to model the theory along with the possible real world result. The real life scenario would be that after a while, the overlay of changes upon changes makes software increasingly tough to maintain and thus much less useful. Maintenance effort estimation techniques range from the easy quality of effort method, through much more careful analysis and development practice adjustments, to the utilization of parametric types to use historical data to project future needs.
5.1 Degree of Effort As well as sometimes the case in the development atmosphere, software maintenance could be modeled as a degree of effort activity. Given the repair category activities plus the great variance which they present, this approach clearly has deficiencies. In this approach, a degree of energy to maintain software is dependent on type and size.
5.2 Degree of Effort Plus Stuzke suggested that software upkeep starts with basic level of effort (minimum people needed to use a core competency and then that that basic core staff must be modified by assessing 3 extra factors; setup management, quality assurance, and project management. His process addressed some of the additional factors affecting software maintenance.
5.3 Maintenance Change Factor Software Cost Estimation with COCOMO II (Boehm 2000) proposes a deceivingly basic, and also rather useful methodology for determining annual maintenance. Maintenance is among the menu selections in the menu bar. In COCOMO II Maintenance entails the procedure for modifying existing operational software while leaving its primary functions intact. This process excludes:
re-development and o Major re design (more than 50 % new code) of a new software product performing substantially the same functions.
o Design and development associated with a sizeable (more than 20 % of the resource instructions comprising the existing product) interfacing software program which involves relatively small redesigning of the present merchandise.
o Data processing technique operations, data entry, and changes of values in the database.
The maintenance calculations are a lot based upon the Maintenance Change Factor (mcf) and The Maintenance Adjustment Factor (MAF). The MCF is comparable to the Annual change Traffic in COCOMO81, except that upkeep periods other than a year might be used. The ensuing maintenance effort estimation formula matches the COCOMO II Post Architecture development model.
As said previously, three cost drivers for maintenance differ from development. Those cost drivers are a software application reliability, modern programming practices, and schedule. COCOMO II assumes that enhanced investment in software reliability and use of modern programming habits during software development has an excellent positive effect upon the maintenance phase.
Yearly Maintenance Effort = (Annual Change Traffic) * (Original Software Development Effort)
The quantity Original Software Development Effort describes the entire effort (person months or another unit of measure) expended throughout development, whether or not a multi year project.
The multiplier Annual Change Traffic is the proportion of the overall software program to be changed during the year. This is relatively straightforward to obtain from engineering estimates. Developers often maintain change lists, or even have a feeling of proportional change being necessary even before development is done.
5.4 Managing Software Maintenance Costs by Developmental Techniques and Management Decisions During Development
When it involves maintenance, “a penny spent is a pound saved.” Better development techniques (even if much more expensive) may substantially reduce maintenance effort, and reduce total life cycle cost. The more hard work put into expansion, the less necessary in maintenance. As a good example, the application development price tag and also routine is significantly impacted (reduced) by permitting the number of defects delivered mature. This schedule and cost reduction is a lot more than offset by the increased maintenance cost. The following discussion is a good example of exactly how management decision may significantly affect/reduce software maintenance expenses.
Lloyd Huff and George Novak of Lockheed Martin Aeronautics inside their paper “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 lower 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 cost estimates)
5.5 A Parametric Assessment of Software Maintenance
Parametric models like SEER for maintenance is allowed by Software to be modeled in either of two ways:
Estimating maintenance as a part of the whole lifecycle cost. Picking out the right Maintenance category parameters will include an approximation of maintenance efforts with the improvement estimate for the private software program. Breakdowns of development vs. maintenance effort are shown by many reports and charts. This strategy is better utilized to assess life cycle expenses for every software program.
Estimating maintenance as a separate pursuit. Using the proper maintenance parameters for the software to be looked after you can model the maintenance efforts as a separate activity. This method will allow you to tweak your upkeep estimate by adjusting parameters. Maintenance size needs to be the same as development specifications, but should be entered as all pre existing code. This strategy may also be practical in breaking away full job maintenance costs from project development costs.
A wide variety of info is included by a good parametric estimate for maintenance. Crucial info for doing a software maintenance estimate is going to be size or even amount of a software application that will be taken care of, the quality of that software program, the quality and availability of the documentation, and the type or amount of routine maintenance that will be achieved. Lots of organizations don’t really estimate maintenance costs; they just have a financial budget for software maintenance. In this situation, a parametric model should be used to compute exactly how much maintenance can basically be done with the specified budget.
Planning and estimating for maintenance are serious activities if the program is required to operate properly throughout its expected life. Despite a limited budget, a weight loss program can be made to work with the resources available in essentially the most powerful, productive manner. Looking at the diagram above, you can see that not only will be the many inputs that will impact the maintenance, but you will find several main outputs that offer the info necessary to plan a booming maintenance effort.
6. Conclusion The conclusions from this post are:
o Software maintenance can be modeled using a simplistic method like Level of Effort Staffing, but this particular system has significant drawbacks.
o Software maintenance costs are generally significantly affected by management decisions throughout the developmental process.
o Software maintenance is correctly estimated with the use of parametric processes.
o Software maintenance is best modeled when progress and management decisions are in addition to parametric cost estimation techniques.