This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these template messages)(Learn how and when to remove this template message)
|Paradigms and models|
|Methodologies and frameworks|
|Standards and Bodies of Knowledge|
A common perception of maintenance is that it merely involves fixing defects. However, one study indicated that over 80% of maintenance effort is used for non-corrective actions. This perception is perpetuated by users submitting problem reports that in reality are functionality enhancements to the system. More recent studies put the bug-fixing proportion closer to 21%.
Software maintenance and evolution of systems was first addressed by Meir M. Lehman in 1969. Over a period of twenty years, his research led to the formulation of Lehman's Laws (Lehman 1997). Key findings of his research include that maintenance is really evolutionary development and that maintenance decisions are aided by understanding what happens to systems (and software) over time. Lehman demonstrated that systems continue to evolve over time. As they evolve, they grow more complex unless some action such as code refactoring is taken to reduce the complexity.
In the late 1970s, a famous and widely cited survey study by Lientz and Swanson, exposed the very high fraction of life-cycle costs that were being expended on maintenance. They categorized maintenance activities into four classes:
The survey showed that around 75% of the maintenance effort was on the first two types, and error correction consumed about 21%. Many subsequent studies suggest a similar magnitude of the problem. Studies show that contribution of end user is crucial during the new requirement data gathering and analysis. And this is the main cause of any problem during software evolution and maintenance. So software maintenance is important because it consumes a large part of the overall lifecycle costs and also the inability to change software quickly and reliably means that business opportunities are lost.   
The key software maintenance issues are both managerial and technical. Key management issues are: alignment with customer priorities, staffing, which organization does maintenance, estimating costs. Key technical issues are: limited understanding, impact analysis, testing, maintainability measurement.
Software maintenance is a very broad activity that includes error correction, enhancements of capabilities, deletion of obsolete capabilities, and optimization. Because change is inevitable, mechanisms must be developed for evaluation, controlling and making modifications.
So any work done to change the software after it is in operation is considered to be maintenance work. The purpose is to preserve the value of software over the time. The value can be enhanced by expanding the customer base, meeting additional requirements, becoming easier to use, more efficient and employing newer technology. Maintenance may span for 20 years, whereas development may be 1-2 years.
An integral part of software is the maintenance one, which requires an accurate maintenance plan to be prepared during the software development. It should specify how users will request modifications or report problems. The budget should include resource and cost estimates. A new decision should be addressed for the developing of every new system feature and its quality objectives. The software maintenance, which can last for 5–6 years (or even decades) after the development process, calls for an effective plan which can address the scope of software maintenance, the tailoring of the post delivery/deployment process, the designation of who will provide maintenance, and an estimate of the life-cycle costs. The selection of proper enforcement of standards is the challenging task right from early stage of software engineering which has not got definite importance by the concerned stakeholders.
This section describes the six software maintenance processes as:
There are a number of processes, activities and practices that are unique to maintainers, for example:
E.B. Swanson initially identified three categories of maintenance: corrective, adaptive, and perfective. The IEEE 1219 standard was superseded in June 2010 by P14764. These have since been updated and ISO/IEC 14764 presents:
There is also a notion of pre-delivery/pre-release maintenance which is all the good things you do to lower the total cost of ownership of the software. Things like compliance with coding standards that includes software maintainability goals. The management of coupling and cohesion of the software. The attainment of software supportability goals (SAE JA1004, JA1005 and JA1006 for example). Note also that some academic institutions[who?] are carrying out research to quantify the cost to ongoing software maintenance due to the lack of resources such as design documents and system/software comprehension training and resources (multiply costs by approx. 1.5-2.0 where there is no design data available).
Impact of key adjustment factors on maintenance (sorted in order of maximum positive impact)
|Maintenance Factors||Plus Range|
|High staff experience||34%|
|Table-driven variables and data||33%|
|Low complexity of base code||32%|
|Y2K and special search engines||30%|
|Code restructuring tools||29%|
|High level programming languages||25%|
|Reverse engineering tools||23%|
|Complexity analysis tools||20%|
|Defect tracking tools||20%|
|Y2K “mass update” specialists||20%|
|Automated change control tools||18%|
|Formal base code inspections||15%|
|Regression test libraries||15%|
|Excellent response time||12%|
|Annual training of > 10 days||12%|
|High management experience||12%|
|HELP desk automation||12%|
|No error prone modules||10%|
|On-line defect reporting||10%|
|Excellent ease of use||7%|
|User satisfaction measurements||5%|
|High team morale||5%|
Not only are error-prone modules troublesome, but many other factors can degrade performance too. For example, very complex “spaghetti code” is quite difficult to maintain safely. A very common situation which often degrades performance is lack of suitable maintenance tools, such as defect tracking software, change management software, and test library software. Below describe some of the factors and the range of impact on software maintenance.
Impact of key adjustment factors on maintenance (sorted in order of maximum negative impact)
|Maintenance Factors||Minus Range|
|Error prone modules||-50%|
|Embedded variables and data||-45%|
|High code complexity||-30%|
|No Y2K of special search engines||-28%|
|Manual change control methods||-27%|
|Low level programming languages||-25%|
|No defect tracking tools||-24%|
|No Y2K “mass update” specialists||-22%|
|Poor ease of use||-18%|
|No quality measurements||-18%|
|No maintenance specialists||-18%|
|Poor response time||-16%|
|No code inspections||-15%|
|No regression test libraries||-15%|
|No help desk automation||-15%|
|No on-line defect reporting||-12%|
|No code restructuring tools||-10%|
|No annual training||-10%|
|No reengineering tools||-10%|
|No reverse-engineering tools||-10%|
|No complexity analysis tools||-10%|
|No productivity measurements||-7%|
|Poor team morale||-6%|
|No user satisfaction measurements||-4%|
|No unpaid overtime||0%|
None of the audio/visual content is hosted on this site. All media is embedded from other sites such as GoogleVideo, Wikipedia, YouTube etc. Therefore, this site has no control over the copyright issues of the streaming media.
All issues concerning copyright violations should be aimed at the sites hosting the material. This site does not host any of the streaming media and the owner has not uploaded any of the material to the video hosting servers. Anyone can find the same content on Google Video or YouTube by themselves.
The owner of this site cannot know which documentaries are in public domain, which has been uploaded to e.g. YouTube by the owner and which has been uploaded without permission. The copyright owner must contact the source if he wants his material off the Internet completely.