Your SlideShare is downloading. ×
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply



Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Maintenance Reasons for changes to software • Customer initiates changes due to changes in law, alterations to policy, changes to interfacing systems • Developers initiate changes due to component failure reports, detection of defects, changes to systems environment • Product support considerations: product on multiple platforms, multiple product versions, different customized product versions Laws of program evolution • Continuing change A program undergoes continuing change or becomes progressively less useful • Increasing complexity As an evolving program is changed, its complexity, which reflects deteriorating structure, increases unless work is done to reduce the same • The fundamental law of program evolution Program evolution is subject to a dynamic that makes the programming process self- regulating with statistically determinable trends • Conservation of organization stability The global activity rate in a project supporting an evolving program is statistically invariant • Conservation of familiarity The release content (changes, additions, deletions) of the successive releases of the evolving program is statistically invariant Categories of Software Maintenance Corrective Maintenance: Aims to correct errors Adaptive Maintenance: Changes the system to react to changes in the environment Preventive Maintenance: Involves documenting, commenting, or even re-implementing some part of software Perfective Maintenance: It improves the efficiency and/or effective of the system, or improves the maintainability Development time Vs Maintenance time=20:80 Problems during maintenance
  • 2. • Often the program is written by another person • Often the program is changed by a person who did not understand it properly • Program listings are not structured • High staff turnover • Some problems become clearer only when a system is in use • Some systems are not designed for change Potential solutions to maintenance problems • Budget and effort reallocation: More time should be invested during development • Complete replacement of system: if the cost of system maintenance is high • Enhancement of existing system Software maintenance cost factors • Non-technical • Application domain • Staff stability • Program lifetime • External environment • Hardware stability • Technical • Programming language • Programming style • Programming validation and testing • Documentation Structured Vs Unstructured maintenance Structured Unstructured • Based on component level design • Based on object maintenance • Recent approach • Earlier approach • No such break-up is created • A common process framework is • Regression tests are conducted and established software is again released • Regression tests are impossible to • Software Configuration management is conduct implemented • Software Configuration management is not implemented Automated Maintenance Tools • Text Editors • File Comparators • Compilers and linkers • Debugging Tools • Cross-reference Generators • Static code Analyzers • Configuration Management Repositories Estimation of maintenance cost • COCOMO Model
  • 3. Annual change traffic (ACT)= KLOC added + KLOC deleted KLOC total Maintenance cost=ACT * Development cost • Belady and Lehman Model M=P+K e(c-d) where M: Total effort expended on maintenance P: Productive effort that involves analysis design, coding, testing & evaluation K: An empirically determined constant c: Complexity measure due to lack of good design d: degree to which maintenance team is familiar with the software Measuring Maintenance • Environment dependent measures which describe the degree and effectiveness of maintenance • Mean time to repair • Total change implementation time to total number of changes implemented • Number of unresolved problems • Time spent on unresolved problems • Percentage of changes that introduce new faults • Number of components modified to implement a change • Internal attributes affecting maintainability • Cyclomatic number • Readability measure (fog index) • F=0.4*number of words+% of words of 3 or more syllables No. of sentences Software Rejuvenation It tries to increase the overall quality of an existing system, by looking back at it’s workproducts to try to derive additional information or to reformat them in a more understandable way. There are several aspects of software rejuvenation to consider: • Redocumentation • Restructuring: Code restructuring and Data restructuring • Reverse engineering is performed to understand Internal data structures, Database Structures, User Interfaces and Processing. • Reengineering