20 Software Maintenance 2024
20 Software Maintenance 2024
1
Why Maintenance ?
• Changes in user requirement with time
• Program / System problems (faults)
• Changing hardware/software environment
• To improve system efficiency and throughput
2
Objective of Maintenance ?
3
Maintenance Efforts
• Nearly 80% of a system’s lifetime costs is spent in
maintenance
• A software person spends more than 50% of time in
maintenance
• Approximately 90% of the software lifetime is spent in
maintenance
4
Maintenance Activities
• Determine what changes will be made to what components
of existing system
• Understand the structure & purpose of the affected
components (impact analysis)
• Modify the components
• Test the resulting product to verify the correctness of the
changes
• Eliminate any unwanted side effects resulting from
modification (regression testing)
• Control the distribution of new version (change control &
configuration management)
5
Types of Maintenance
• Corrective Maintenance
• Adaptive Maintenance
• Perfective Maintenance
• Preventive Maintenance
6
Corrective Maintenance
Any changes necessitated by actual errors
(faults) in a system.
• This type of maintenance
– is to eliminate any deviations from specifications
– is usually a reactive process
– may be due to errors in design, logic & coding
7
Adaptive Maintenance
Any effort initiated as a result of changes in the
environment in which a software system must operate
8
Perfective Maintenance
All insertions, deletions, modifications, extensions &
enhancements made to a system to improve software
performance, maintainability or understandability
9
Preventive Maintenance
It is a periodic activity. Also, used to prevent
failures from an identified potential fault
Activities include
– file directory and source list management
– documentation checks
– review of standards and efficiency
– staggered system enhancements
• Typically done
– once in 6 months for daily & weekly running systems
– once an year for a system used 2-4 times in a year
– whenever the project-in-charge is being replaced
10
Pre-requisites for Maintenance
• Availability & understanding of following documents
– Current source listing
– Test Data (Unit & System test data)
– SRS & Design Documents
– User & Operations Manual
11
Problems During Maintenance
12
Maintenance is Manageable
• A common misconception about maintenance is that
it is not manageable.
• Report of survey conducted by Lientz & Swanson
gives some interesting observations:
1 Emergency debugging 12.4%
2 Routine debugging 9.3%
3 Data environment adaptation 17.3%
4 Changes in hardware and OS 6.2%
5 Enhancements for users 41.8%
6 Documentation Improvement 5.5%
7 Code efficiency improvement 4.0%
8 Others 3.5%
14
Potential Solutions to Maintenance Problems
16
The Maintenance Process
• Program Understanding
– The first phase consists of analyzing the program in order to
understand.
• Generating Particular Maintenance Proposal
– The second phase consists of generating a particular
maintenance proposal to accomplish the implementation of
the maintenance objective.
• Ripple Effect
– The third phase consists of accounting for all of the ripple
effect as a consequence of program modifications.
18
Maintenance Process
19
Common types of changes / errors
1. User related
2. Operation related
3. System / Program related
4. Hardware / Software update related
20
1. User related changes
• Input / Output format changes
• Processing logic changes
• New reports required
• New capabilities expected from the system
21
2. Operation related problems
• Hardware system failure due to power failures, voltage
fluctuations or pack corruption - leading to corrupt data
– Check Restart / Backup procedures
– Check for current backup & see if that is processed
• Outdated operations procedures
• Program fault leading to data corruption
• Unexpected growth of data file sizes leading to operational
problems
22
3. System/Program related faults
23
4. Hardware/Software update related changes
• Latest version of processor / operating system
• Updates of the product to suit the current market
trends
24
Maintenance Models
25
Maintenance Models: Quick-Fix Model
• This is adhoc fire-fighting approach, waiting for the
problem to occur and then trying to fix it as quickly
as possible
• Fixes may be done without detailed analysis of the
long-term effects
26
Maintenance Models: Iterative Enhancement Model
• Changes in the software system throughout its
lifetime are an iterative process
• The model is effectively a three-stage cycle
– Analysis
– Characterization of proposed modification
– Redesign and implementation
27
Maintenance Models: Reuse Oriented Model
• This model is based on the principle that maintenance could
be viewed as an activity involving the reuse of existing
program component.
28
Maintenance Models: Boehm’s Model
• This models emphasizes that management decisions drives
the maintenance process.
• Boehm sees the maintenance manager’s task as one of
balancing the pursuit of the objectives of maintenance
against the constraints imposed by the environment in
which maintenance work is carried out.
Process :
• A set of approved changes is determined by applying
particular strategies and cost-benefit evaluations to a set of
proposed changes
• The approved changes are accompanied by their own
budgets which will largely determine the extent and type of
resources expanded
29
Maintenance Models: Boehm’s Model
Management Decisions
Approved changes
proposed Changes
Evaluation
Change
Results
Implementation
New Version of
Software
Software in Use
30
Software Maintenance : Taute Maintenance Model
2. Estimate phase
3. Schedule phase
4. Programming phase
5. Test phase
6. Documentation phase
7. Release phase
8. Operation phase
32
Software Maintenance
Estimation of maintenance costs
Phase Ratio
Analysis 1
Design 10
Implementation 100
33
Estimation of Maintenance Cost
Belady and Lehman Model
34
Estimation of Maintenance Cost
Belady and Lehman Model
35
Software Maintenance
Example –
The development effort for a software project is 500 person months. The
empirically determined constant (K) is 0.3. The complexity of the code is
quite high and is equal to 8.
Calculate the total effort expended (M) if
(i) maintenance team has good level of understanding of the project (d=0.9)
(ii) maintenance team has poor understanding of the project (d=0.1)
36
Software Maintenance
Solution
Development effort (P) = 500 PM
K = 0.3
C=8
(i) maintenance team has good level of understanding of the project (d=0.9)
M = P + Ke (c-d)
= 500 + 0.3e(8-0.9)
= 500 + 363.59 = 863.59 PM
(ii) maintenance team has poor understanding of the project (d=0.1)
M = P + Ke (c-d)
= 500 + 0.3e(8-0.1)
= 500 + 809.18 = 1309.18 PM
37
Software Maintenance
▪ Boehm Model
Boehm used a quantity called Annual Change Traffic (ACT).
“The fraction of a software product’s source instructions which undergo change during a
year either through addition, deletion or modification”.
38
Software Maintenance
Example
Annual Change Traffic (ACT) for a software system is 15% per year. The development
effort is 600 PMs. Compute estimate for Annual Maintenance Effort (AME). If life time of
the project is 10 years, what is the total effort of the project ?
39
Software Maintenance
Solution
40
Software Maintenance
Example
A software project has development effort of 500 PM. It is assumed that 10% code will be
modified per year. Some of the cost multipliers are given as:
1. Required software Reliability (RELY) : high
2. Date base size (DATA) : high
3. Analyst capability (ACAP) : high
4. Application experience (AEXP) : Very high
5. Programming language experience (LEXP) : high
Other multipliers are nominal. Calculate the Annual Maintenance Effort (AME).
41
Software Maintenance
Solution
RELY = 1.15
ACAP = 0.86
AEXP = 0.82
LEXP = 0.95
DATA = 1.08
42
Software Maintenance
Other values are nominal values. Hence,
AME = 41.6 PM
43
Guidelines for Maintenance
• Plan the modification
– Study the change request
– Document all possible solution to implement changes
– Use a working copy of the program
– Keep track of all the changes
• Use programming standards
• Keep program / file structure changes minimal
• Test modified programs
• Update test data
• Document all the changes
Manuals; Log Files
44
Software Maintenance
Regression Testing
Regression testing is the process of retesting the modified parts of the software and
ensuring that no new errors have been introduced into previously test code.
“Regression testing tests both the modified code and other parts of the program that may be
affected by the program change. It serves many purposes :
45
Software Maintenance
▪ Development Testing Versus Regression Testing
1. We create test suites and test plans We can make use of existing test suite and test plans
2. We test all software components We retest affected components that have been
modified by modifications.
3. Budget gives time for testing Budget often does not give time for regression
testing.
4. We perform testing just once on a software We perform regression testing many times over the
product life of the software product.
5. Performed under the pressure of release date Performed in crisis situations, under greater time
of the software constraints.
46