0% found this document useful (0 votes)
13 views46 pages

20 Software Maintenance 2024

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
13 views46 pages

20 Software Maintenance 2024

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 46

What is Maintenance ?

MAINTENANCE IS THE ACTIVITY ASSOCIATED WITH KEEPING


OPERATIONAL COMPUTER SYSTEMS CONTINUOUSLY IN TUNE
WITH THE REQUIREMENTS OF USERS & DATA PROCESSING
OPERATION

Software Maintenance is any work done to a computer program


after its first installation and implementation in an
operational environment
• Software maintenance encompasses
– Error correction
– Enhancement of capabilities
– Deletion of obsolete capabilities
– Optimization

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 ?

• To ensure that modification does not affect other portions of


the program.

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

Software Maintenance process is expensive and risky - and


is very CHALLENGING!

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

• The environmental changes include


– Rules, laws and regulations that affect the system
– Data formats of interfaces
– Hardware configurations changes
– Systems software (like OS, compiler, etc.) changes

8
Perfective Maintenance
All insertions, deletions, modifications, extensions &
enhancements made to a system to improve software
performance, maintainability or understandability

Perfective maintenance is performed


– to augment or fine-tune the software
– to make the code easier to understand & work with
– to optimize the code to run faster / use storage efficiently

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

– Often the program is written by another person or group of


persons.
– Often the program is changed by person who did not
understand it clearly.
– Program listings are not structured.
– High staff turnover.
– Information gap.
– Systems are not designed for change.

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%

Table 1: Distribution of maintenance effort


13
Kinds of maintenance requests

1 New reports 40.8%


2 Add data in existing reports 27.1%
3 Reformed reports 10%
4 Condense reports 5.6%
5 Consolidate reports 6.4%
6 Others 10.1%

Table 2: Kinds of maintenance requests

14
Potential Solutions to Maintenance Problems

• Complete replacement of the system


• Maintenance of existing system
• Budget and effort reallocation
Starting on Maintenance

• Read and understand


– SRS, Design documents, Previous maintenance documents &
Minutes of the user meetings
• Study the hardware platform, the underlying system
software and all useful software utilities
• Study the operational procedures (Guidelines &
Standards)
• Familiarize with the working procedures of the
maintenance team (standards & tools to be used)

16
The Maintenance Process

Fig. The software maintenance


process
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

• Modified Program Testing


– The fourth phase consists of testing the modified program
to ensure that the modified program has at least the same
reliability level as before.
• Maintainability
– Each of these four phases and their associated software
quality attributes are critical to the maintenance process. All
of these factors must be combined to form maintainability.

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

• Errors in the program


• Data corruption due to other programs
– inadequate integration testing
• Wrong outputs / results
• Poor documentation (external / internal)
hampering productivity

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.

The steps are :


• identification of the parts of the old system that are
candidates for reuse
• Understanding these system parts
• Modification of the old system parts appropriate to the new
requirements
• Integration of the modified parts into the new system

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

• It is a typical maintenance model developed by B.J.


Taute in 1983 and has eight phases in cycle fashion.

Fig. : Taute maintenance model


31
Software Maintenance
Phases :

1. Change request phase

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

Table 3: Defect repair ratio

33
Estimation of Maintenance Cost
Belady and Lehman Model

▪ This model indicates that the effort and cost can


increase exponentially if
▪ poor software development approach is used and
▪ the person or group that used the approach is no longer
available to perform maintenance.

34
Estimation of Maintenance Cost
Belady and Lehman Model

The basic equation [BELA 76] is


M = P + Ke (c-d)
Where
M : Total effort expended
P : Productive effort that involves analysis, design, coding, testing and
evaluation.
K : An empirically determined constant.
c : Complexity measure due to lack of good design and documentation.
d : Degree to which maintenance team is familiar with the software.

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”.

KLOC added + KLOC deleted


ACT =
KLOC total

Annual Maintenance Effort (AME) = ACT x SDE


Where, SDE : Software development effort in person months
ACT : Annual change Traffic
EAF : Effort Adjustment Factor

AME = ACT * SDE * EAF

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

The development effort = 600 PM


Annual Change Traffic (ACT) = 15%
Total duration for which effort is to be calculated = 10 years
The maintenance effort is a fraction of development effort and is assumed to be constant.

AME = ACT x SDE


= 0.15 x 600 = 90 PM

Maintenance effort for 10 years = 10 x 90 = 900 PM

Total effort = 600 + 900 = 1500 PM

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

Annual change traffic (ACT) = 10%


Software development effort (SDE) = 500 Pm
Using Table of COCOMO model, effort adjustment factor can be calculated given
below :

RELY = 1.15
ACAP = 0.86
AEXP = 0.82
LEXP = 0.95
DATA = 1.08

42
Software Maintenance
Other values are nominal values. Hence,

EAF = 1.15 x 0.86 x 0.82 x 0.95 x 1.08 = 0.832

AME = ACT * SDE * EAF

= 0.1 * 500 * 0.832 = 41.6 PM

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 :

➢ increase confidence in the correctness of the modified program


➢ locate errors in the modified program
➢ preserve the quality and reliability of software
➢ ensure the software’s continued operation

45
Software Maintenance
▪ Development Testing Versus Regression Testing

Sr. Development testing Regression testing


No.

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

You might also like