Download Software Maintenance and Evolution: Understanding the Processes and Challenges - Prof. Mar and more Study notes Software Engineering in PDF only on Docsity!
cmsc435 - 1
Maintenance
Why maintenance?
All successful software gets changed. Two processes are at work. First, as a software product is found to be useful, people try it in new cases at the edge of or beyond the original domain. The pressures for extended function come chiefly from users who like the basic function and invent new uses for it.
Second, successful software survives beyond the normal life of the machine vehicle for which it is first written. If not new computers, than at least new disks, new displays, new printers come along; and the software must be conformed to its new vehicles of opportunity. —Fred Brooks, No Silver Bullet
cmsc435 - 3
What is software maintenance
l Software maintenance is defined as the process of modifying a software system or component after delivery to correct faults, improve performance or other attributes, or adapt to a changed environment. Software maintenance can consume as much as 90 percent of all the total effort expended on a system in its lifetime. Some computer scientists prefer to use the term evolution rather than maintenance to indicate that a product normally and naturally evolves over time.
l Software is the only technology where the equivalent of adding a new wing to a building is called “maintenance.”
l Program evolution dynamics is the study of the
processes of system change.
l After major empirical studies, Lehman and
Belady proposed that there were a number of
‘laws’ which applied to all systems as they
evolved.
l There are sensible observations rather than
laws. They are applicable to large systems
developed by large organizations. Perhaps less
applicable in other cases.
Program evolution dynamics
cmsc435 - 7
Lehman’s system types
l S-system: formally defined, derivable from a
specification
l P-system: requirements based on approximate
solution to a problem, but real-world remains
stable
l E-system: embedded in the real world and
changes as the world does
l Modifying a program after it has been put into
use.
l Maintenance does not normally involve major
changes to the system’s architecture.
l Changes are implemented by modifying
existing components and adding new
components to the system.
Software maintenance
cmsc435 - 9
l The system requirements are likely to change while the system is being developed because the environment is changing. Therefore a delivered system won't meet its requirements! l Systems are tightly coupled with their environment. When a system is installed in an environment it changes that environment and therefore changes the system requirements. l Systems MUST be maintained therefore if they are to remain useful in an environment.
Maintenance is inevitable
Examples of change during software development
Activity from which initial change results Artifacts requiring consequent change Requirements analysis Requirements specification System design Architectural design specification Technical design specification Program design Program design specification Program implementation Program code Program documentation Unit testing Test plans Test scripts System testing Test plans Test scripts System delivery User documentation Training aids Operator documentation System guide Programmer guide Training classes
cmsc435 - 13
System evolution vs. decline
l Is the cost of maintenance too high?
l Is the system reliability unacceptable?
l Can the system no longer adapt to further change, and within a reasonable amount of time?
l Is system performance still beyond prescribed constraints?
l Are system functions of limited usefulness?
l Can other systems do the same job better, faster or cheaper?
l Is the cost of maintaining the hardware great enough to justify replacing it with cheaper, newer hardware?
Laws of software evolution
l Continuing change: leads to less utility
l Increasing complexity: structure
deteriorates
l Fundamental law of program evolution:
program obeys statistically-determined
trends and has invariants
l Conservation of organizational stability:
global activity rate is invariant
l Conservation of familiarity: release content is
invariant
cmsc435 - 15
Types of maintenance
l Corrective: maintaining control over day-to-
day functions (fixing problems)
l Adaptive: maintaining control over system
modifications (adding functionality)
l Perfective: perfecting existing functions –
refactoring (redesign)
l Preventive: preventing system performance
from degrading to unacceptable levels (adding
additional internal checks)
Maintenance classes
l Williams uses the
percentages 61%,18%,
17%, 4% instead of the
numbers here. But the
relative values are in the
same order. Perfective
maintenance dominates the
cost.
cmsc435 - 19
Factors affecting maintenance effort
l Application type l System novelty l Turnover and maintenance staff ability l System life span l Dependence on a changing environment l Hardware characteristics l Design quality l Code quality l Documentation quality l Testing quality
Measuring maintainability
l Necessary data:
time at which problem is reported time lost due to administrative delay time required to analyze problem time required to specify which changes are to be made time needed to make the change time needed to test the change
time needed to document the change
• Desirable data:
ratio of 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
cmsc435 - 21
Fog index
F = 0 4. × (^) number of sentencesnumber of words +percentage of words of 3 or more syllables
Automated maintenance tools
l Text editors
l File comparators
l Compilers and linkers
l Debugging tools
l Cross-reference generators
l Static code analyzers
l Configuration management repositories
cmsc435 - 25
Four (unfortunate) truths
l Source code is king. [Why? Because…]
l Documentation is untrustworthy. [It is not
kept up to date.]
l Bug tracking database stores knowledge.
l Reproduction is essential to obtaining a
solution. [Reproducing is also important to
ensure that the problem was a real problem
and not a perceived one or caused by external
sources such as software interactions.]
Key points
l Use a mini-development iterative enhancement cycle (analysis, design, code, test) when making and verifying any code changes. Maintenance is an error-prone process which can cause the injection of new faults – new faults which might cause more problems than the original problem – if the maintenance engineer is not careful and thorough. l Avoid the quick-fix process for software maintenance to avoid the introduction of increased program complexity and unforeseen ripple effects. If you cannot avoid it, reanalyze the fix via a more systematic process once the crisis is over. l In organizations that have change control boards, complete a software change request form and submit to this board for approval of proposed adaptive, perfective, and preventative maintenance. l Complete a fault report for all needed corrective maintenance to describe a reported problem. Update this form with a detailed description of what was changed and why l Use maintainability metrics to signal when maintenance costs are becoming excessive and when it is time for some preventative maintenance.
