Abstract The dictionary defines upkeep as, “The work of maintaining something in proper order.” However, this definition does not necessarily fit for software. Although often gets a lesser amount of useful with age, software maintenance differs from hardware maintenance because software doesn’t physically wear out. Software is typically sent with undiscovered flaws. Thus, software maintenance is: “The practice of changing existing operational software while passing on to its primary tasks intact.” Maintenance usually exceeds fifty percent of the systems’ life cycle expense. While software maintenance can be regarded as a level of energy activity, you will find consequences on quality, functionality, reliability, cost and schedule that may be mitigated through the use of parametric estimation techniques.
1. INTRODUCTION Among the biggest issues facing software engineers is the management of change control. It has been estimated that the price of change management can be between 40 % and 70 % of the life cycle expenses. Software technical engineers have hoped that new languages and new process would greatly reduce these numbers; however this hasn’t been the case. Fundamentally this is because application is delivered with many defects. Capers Jones estimates that there are about five bugs per Function Point developed during Development. Watts Humphrey found “… even experienced software engineers generally inject hundred or even a lot more defects per KSLOC. Capers Jones states, “A sequence of scientific studies the defect density of an application ranges from 49.5 to 94.5 errors per thousand lines of code.” The purpose of this article is usually to first review the fundamentals of software maintenance and to present alternative techniques to estimating applications maintenance. A crucial ingredient to note is that development as well as management decisions made during the development process could significantly affect the developmental cost and the ensuing maintenance costs.
2. SOFTWARE MAINTENANCE Maintenance activities include all effort carried out post delivery and really should be distinguished from obstruct modifications which represent considerable development and design effort and supersede a previously released software program. These maintenance activities is extremely different, and it really helps to identify exactly what post delivery activities are to be included in an estimation of maintenance effort. Maintenance activities, once defined, may be examined in a pretty different light than when called just “maintenance”. Although software often gets a lesser amount of useful with age and it might possibly be delivered with undiscovered flaws, software maintenance is different from hardware maintenance because software doesn’t literally wear out. Along with the undiscovered flaws, it’s common that quite a few number of recognized defects pass from the development group to the maintenance team. Accurate estimation of the effort needed to help maintain delivered a program is aided by the decomposition of the overall effort into the various 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 is apparent that the method is much more than simply writing new code.
The following checklist can be used to explore the realism and reliability of maintenance requirements.
o Which portions of program is maintained?
o How long will the technique need to be maintained?
o Are you estimating entire maintenance problem, or just incremental maintenance?
o What levels of maintenance is required?
o Is that which has been called maintenance actually a whole new development project?
o Who will do the maintenance? Will it be accomplished naturally by the original developer? Will there be a separate team? Will there be a separate organization?
o Will maintainers be making use of the same equipment used during development? Are any proprietary resources needed for maintenance?
o How much Commercial-Off-The-Shelf (COTS) is present? How tightly coupled are the interfaces?
o Some follow-on development might be disguised as maintenance. This should either inflate maintenance figures, or else cause shortfalls if basic maintenance gets pushed aside. These questions will help you ask whether maintenance is being honestly represented.
o Is the activity truly an incremental improvement?
o Are good chunks of the first code being rewritten or changed?
o Will extra staff be introduced to perform the upgrade?
o Will be the maintenance effort schedule regular and also pretty dull, or will do it possess staffing humps that are like new development?
4. SANITY CHECKS Although sanity checks can be sought on a year-by-year schedule, they should not be attempted for overall development. The reason for this’s that maintenance activities could be carried on forever, rendering any life-cycle rules useless. As an example, consider Grady (p. 17):
We spend aproximatelly two to three times as much effort enhancing and maintaining software program as we spend creating brand new software.
This similar observations and apply at an organizational levels and higher, but not for a particular task. Any development set having a the historical past will be embroiled in the long tail ends of their many delivered projects, still requiring long attention. Listed here are a couple of quick sanity checks:
o One maintainer is able to handle aproximatelly 10,000 lines per year.
o Overall life cycle effort is typically forty % development as well as 60 % maintenance.
o Maintenance costs typically are one sixth of per annum development costs.
o Successful systems are often maintained for ten to twenty years.
Last but not least, as in development, the amount of code which is fresh compared to modified is important. The effective size, that’s, the equivalent energy if all the work were new code, is still the main key input for both maintenance and growth cost estimation.
5. 5 ALTERNATIVE APPROACHES All program estimation techniques must be able to model the theory along with the probable real world result. The real world situation is that over time, the overlay of modifications upon changes makes software increasingly tricky to maintain and thus much less useful. Maintenance effort estimation methods vary from the simple level of energy method, through much more thoughtful analysis and development practice modifications, to the use of parametric types to use historical data to project coming needs.
5.1 Degree of Effort As well as often the case in the development atmosphere, software maintenance could be modeled as a level of effort activity. With the repair category activities as well as the great variance which they show, this particular approach definitely has deficiencies. In this approach, a degree of energy to maintain software is dependent on type and size.
5.2 Level of Effort Plus Stuzke proposed that software maintenance starts with basic level of energy (minimum individuals needed to use a core competency then that that basic core staff have to be modified by assessing 3 extra factors; configuration management, quality assurance, and project management. Some of the additional factors affecting software maintenance were addrest by his process.
Even thought also very 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 menu bar. In COCOMO II Maintenance entails the procedure for modifying existing operational software while leaving its main 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 functions.
o Design and development associated with a sizeable (more than twenty % of the resource instructions comprising the current product) interfacing software system which involves relatively little redesigning of the current product.
o Data processing technique operations, data entry, and adjustment of values in the database.
The maintenance calculations are a lot based upon the Maintenance Change Factor (The Maintenance and mcf) Adjustment Factor (MAF). The MCF is akin to the Annual change Traffic in COCOMO81, except that upkeep periods apart from 1 year may be used. The resulting maintenance effort estimation formulation matches the COCOMO II Post Architecture development model.
As stated earlier, three price drivers for maintenance differ from advancement. Those cost drivers are a software application reliability, schedule, and modern programming practices. COCOMO II assumes that enhanced investment in a software application reliability and use of contemporary programming practices during software development has an excellent positive effect upon the maintenance phase.
Annual Maintenance Effort = (Annual Change Traffic) * (Original Software Development Effort)
The amount Original Software Development Effort describes the total effort (person-months or other unit of measure) expended throughout advancement, even though a multi year project.
The multiplier Annual Change Traffic is the proportion of the general software to be customized during the year. This is somewhat straightforward to obtain from engineering estimates. Developers often maintain change lists, or perhaps have a sense of proportional switch to be expected while before development is finished.
5.4 Managing Software Maintenance Costs by Developmental Techniques and Management Decisions During Development
When it comes to maintenance, “a penny spent is a pound saved.” Better advancement strategies (even if much more expensive) may substantially reduce maintenance effort, and reduce overall life cycle cost. The greater amount of hard work put into advancement, the less needed in maintenance. As a good example, the software program development cost and schedule is significantly impacted (reduced) by letting the selection of defects delivered grow. This schedule and cost reduction is a lot more than offset by the increased maintenance cost. The following discussion is a good example of how management decision can substantially affect/reduce software maintenance costs.
Lloyd Huff and George Novak of Lockheed Martin Aeronautics in their cardboard “Lockheed Martin Aeronautics Performance Based Software Sustainment for the F-35 Lightning II” propose a series of development and management decision designed to impact and minimize software application maintenance costs. They propose an eight step process to estimate and control software maintenance. 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. Plan for the Unexpected
8. Analyze and Refine the software Sustainment Business Case (use Parametric application sustainment expense estimates)
5.5 A Parametric Assessment of Software Maintenance
Parametric models like SEER for Software allow maintenance to be modeled in both of two ways:
Estimating maintenance as a part of the total lifecycle cost. Selecting the appropriate Maintenance category parameters are going to include an estimate of maintenance efforts with the development estimate just for the individual software program. Charts and a few reports show breakdowns of development vs. maintenance effort. This approach is better used to consider life cycle expenses for each software program.
Estimating maintenance as a distinct undertaking. Using the correct maintenance parameters for the software program to be taken care of you can model the maintenance attempt as a distinct activity. This strategy is going to allow you to fine tune your maintenance estimate by adjusting parameters. Maintenance size has to be the same as progress sizing, but should be entered as all pre existing code. This strategy can also be useful in breaking away overall project maintenance fees from project development expenses.
A wide range of info is included by a very good parametric estimate for maintenance. Essential info for doing a software maintenance estimate is the size or amount of software that will likely be taken care of, the quality of which software, the quality and supply of the documentation, and the type or even amount of servicing that will be achieved. Many businesses don’t actually estimate maintenance costs; they merely enjoy a budget for software maintenance. In this situation, a parametric design must be utilized to calculate exactly how much maintenance can basically be done with the specified budget.
estimating and Planning for maintenance are serious activities if the software program is needed to operate correctly throughout its expected life. In spite of a tight budget, a weight loss program could be put forth to use the resources available in likely the most powerful, effective manner. Looking at the diagram above, you can see that not only will be the multiple inputs that will affect the maintenance, but there are a number of crucial outputs that provide the information necessary to plan a booming maintenance effort.
6. Conclusion The conclusions of this article are:
Though this particular method has significant drawbacks, o Software maintenance can be modeled using a simplistic method like Level of Effort Staffing.
o Software maintenance costs are usually significantly affected by management decisions throughout the developmental process.
o Software maintenance can be correctly estimated with the use of parametric processes.
o Software maintenance is best modeled when growth and management decisions are in addition to parametric cost estimation techniques.