Software Maintenance

Software Maintenance
 Software Maintenance

What is Software Maintenance?

Software Maintenance is a very broad activity that includes error
corrections, enhancements of capabilities, deletion of obsolete capabilities,
and optimization.

2
 Software Maintenance

Categories of Maintenance

• Corrective maintenance
This refer to modifications initiated by defects in the software.

• Adaptive maintenance
It includes modifying the software to match changes in the ever changing
environment.

• Perfective maintenance
It means improving processing efficiency or performance, or restructuring
the software to improve changeability. This may include enhancement of
existing system functionality, improvement in computational efficiency etc.
3
 Software Maintenance

• Other types of maintenance

There are long term effects of corrective, adaptive and perfective changes.
This leads to increase in the complexity of the software, which reflect
deteriorating structure. The work is required to be done to maintain it or to
reduce it, if possible. This work may be named as preventive
maintenance.

4
 Software Maintenance

Corr
ectiv
e (2 1 Perfective
%)
Adaptive
Preventive
Corrective

Prev
ent iv
e (4
%) Perf e
ct ive
(50 %
)

Ada
ptive
(2 5
%)

Fig. 1: Distribution of maintenance effort

5
 Software Maintenance

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.

6
 Software Maintenance

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

7
 Software Maintenance

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

8
 Software Maintenance

Potential Solutions to Maintenance Problems

) Budget and effort reallocation

) Complete replacement of the system

) Maintenance of existing system

9
 Software Maintenance
The Maintenance Process

Fig. 2: The software

maintenance process

10
 Software Maintenance

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

11
 Software Maintenance

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

12
 Software Maintenance

Maintenance Models
• Quick-fix Model
This is basically an adhoc approach to maintaining software. It is a fire
fighting approach, waiting for the problem to occur and then trying to fix it
as quickly as possible.
Problem
found

Fix it

Fig. 3: The quick-fix model

13
 Software Maintenance

• Iterative Enhancement Model

) Analysis

) Characterization of proposed modifications

) Redesign and implementation

14
 Software Maintenance

Analyze existing system

Redesign current Characterize

version and proposed
implementation modification
s

Fig. 4: The three stage cycle of iterative enhancement

15
 Software Maintenance

• Reuse Oriented Model

The reuse model has four main steps:

1. Identification of the parts of the old system that are candidates for
reuse.
2. Understanding these system parts.
3. Modification of the old system parts appropriate to the new
requirements.
4. Integration of the modified parts into the new system.

16
 Software Maintenance

Old system New system

Requirements analysis Requirements analysis

Components
Design library Design

Source code Source code

Test data Test data

Fig. 5: The reuse model

17
 Software Maintenance

• Boehm’s Model

Boehm proposed a model for the maintenance process based upon

the economic models and principles.

Boehm represent the maintenance process as a closed loop cycle.

18
 Software Maintenance

Management decisions

Proposed changes Approved changes

Change
Evaluation
implementation

Results New version of

software

Fig. 6: Boehm’s model

19
 Software Maintenance
• Taute Maintenance Model
It is a typical maintenance model and has eight phases in cycle fashion. The
phases are shown in Fig. 7

Fig. 7: Taute maintenance model

20
 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

21
 Software Maintenance

Estimation of maintenance costs

Phase Ratio

Analysis 1

Design 10

Implementation 100

Table 3: Defect repair ratio

22
 Software Maintenance

• Belady and Lehman Model

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.

23
 Software Maintenance

Example – 9.1

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)

24
 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)
(8-0.9)
= 500 + 0.3e
= 500 + 363.59 = 863.59 PM
(ii) maintenance team has poor understanding of the project (d=0.1)

M = P + Ke (c-d)
(8-0.1)
= 500 + 0.3e
= 500 + 809.18 = 1309.18 PM

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

ACT = KLOCadded + KLOCdeleted

KLOCtotal

AME = ACT x SDE

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

AME = ACT * SDE * EAF

26
 Software Maintenance

Example – 9.2

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 ?

27
 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 = 900PM

Total effort = 600 + 900 = 1500 PM

28
 Software Maintenance

Example – 9.3

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 Analyst
3. capability (ACAP) : high Application
4. experience (AEXP) : Very high
5. Programming language experience (LEXP) : high

Other multipliers are nominal. Calculate the Annual Maintenance Effort

(AME).

29
 Software Maintenance
Solution

Annual change traffic (ACT) = 10%

Software development effort (SDE) = 500 Pm
Using Table 5 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

30
 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

31
 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

32
 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 We perform regression testing many times
software product over the life of the software product.
5. Performed in crisis situations, under greater
Performed under the pressure of
release date of the software time constraints.

33
 Software Maintenance

• Regression Test Selection

Regression testing is very expensive activity and consumes significant
amount of effort / cost. Many techniques are available to reduce this effort/
cost.

1. Reuse the whole test suite

2. Reuse the existing test suite, but to apply a regression test

selection technique to select an appropriate subset of the test suite
to be run.

34
 Software Maintenance

Fragment A Fragment B
(modified form of
S1 y = (x - 1) * (x + 1) S1’ A)
y = (x -1) * (x + 1)
S2 if (y = 0) S2’ if (y = 0)
S3 return (error) S3’ return (error)
S4 else S4’ else

 1  1 
S5 return   S5’ return  
 y−3

Fig. 8: code fragment A and B

35
 Software Maintenance

Test cases

Test number Input Execution History

t1 x=1 S1, S2, S3

t2 x = -1 S1, S2, S3

t3 x=2 S1, S2, S5

t4 x=0 S1, S2, S5

Fig. 9: Test cases for code fragment A of Fig. 8

36
 Software Maintenance

If we execute all test cases, we will detect this divide by zero fault. But we
have to minimize the test suite. From the fig. 9, it is clear that test cases t3
and t4 have the same execution history i.e. S1, S2, S5. If few test cases have
the same execution history; minimization methods select only one test case.
Hence, either t3 or t4 will be selected. If we select t4 then fine otherwise fault
not found.
Minimization methods can omit some test cases that might expose fault in
the modified software and so, they are not safe.

A safe regression test selection technique is one that, under certain

assumptions, selects every test case from the original test suite that can
expose faults in the modified program.

37
 Software Maintenance

• Selective Retest Techniques

Selective retest techniques may be more economical than the “retest-all”
technique.
Selective retest techniques are broadly classified in three categories :
1. Coverage techniques : They are based on test coverage criteria.
They locate coverable program components that have been modified,
and select test cases that exercise these components.

2. Minimization techniques: They work like coverage techniques,

except that they select minimal sets of test cases.

3. Safe techniques: They do not focus on coverage criteria; instead they

select every test case that cause a modified program to produce
different output than its original version.

38
 Software Maintenance

Rothermal identified categories in which regression test selection

techniques can be compared and evaluated. These categories are:

Inclusiveness measures the extent to which a technique chooses test

cases that will cause the modified program to produce different output than
the original program, and thereby expose faults caused by modifications.
Precision measures the ability of a technique to avoid choosing test cases
that will not cause the modified program to produce different output than
the original program.
Efficiency measures the computational cost, and thus, practically, of a
technique.
Generality measures the ability of a technique to handle realistic and
diverse language constructs, arbitrarily complex modifications, and realistic
testing applications.
39
 Software Maintenance

Reverse Engineering
Reverse engineering is the process followed in order to find difficult,
unknown and hidden information about a software system.

40
 Software Maintenance

• Scope and Tasks

The areas there reverse engineering is applicable include (but not limited to):

1. Program comprehension
2. Redocumentation and/ or document generation
3. Recovery of design approach and design details at any level of
abstraction
4. Identifying reusable components
5. Identifying components that need restructuring
6. Recovering business rules, and
7. Understanding high level system description

41
 Software Maintenance
Reverse Engineering encompasses a wide array of tasks related to understanding
and modifying software system. This array of tasks can be broken into a number of
classes.

) Mapping between application and program domains

Problem/
applicatio
n domain

Mapping

Programming/
implement
domain

Fig. 10: Mapping between application and domains program

42
 Software Maintenance

) Mapping between concrete and abstract levels

) Rediscovering high level structures

) Finding missing links between program syntax and

semantics
) To extract reusable component

43
 Software Maintenance

• Levels of Reverse Engineering

Reverse Engineers detect low level implementation constructs and replace

them with their high level counterparts.

The process eventually results in an incremental formation of an overall

architecture of the program.

44
Software Maintenance

Fig. 11: Levels of abstraction

45
 Software Maintenance

Redocumentation
Redocumentation is the recreation of a semantically equivalent
representation within the same relative abstraction level.

Design recovery
Design recovery entails identifying and extracting meaningful higher level
abstractions beyond those obtained directly from examination of the source
code. This may be achieved from a combination of code, existing design
documentation, personal experience, and knowledge of the problem and
application domains.

46
 Software Maintenance

Software Re-Engineering
Software re-engineering is concerned with taking existing legacy systems
and re-implementing them to make them more maintainable.

The critical distinction between re-engineering and new software

development is the starting point for the development as shown in Fig.12.

47
 Software Maintenance

Existing
System
softwar
specific
ation e
system

Understanding
Design and
implementa and
tion transformation

New system Re-engineered

system

Fig. 12: Comparison of new software development with re-engineering

48
 Software Maintenance

The following suggestions may be useful for the modification of the legacy
code:
Study code well before attempting changes
Concentrate on overall control flow and not coding
Heavily comment internal code
Create Cross References
Build Symbol tables
Use own variables, constants and declarations to localize the effect
Keep detailed maintenance document
Use modern design techniques

49
 Software Maintenance

• Source Code Translation

1. Hardware platform update: The organization may wish to
change its standard hardware platform. Compilers for the original
language may not be available on the new platform.

2. Staff Skill Shortages: There may be lack of trained

maintenance staff for the original language. This is a particular
problem where programs were written in some non standard
language that has now gone out of general use.
3. Organizational policy changes: An organization may decide to
standardize on a particular language to minimize its support
software costs. Maintaining many versions of old compilers can
be very expensive.

50
 Software Maintenance

• Program Restructuring

1. Control flow driven restructuring: This involves the imposition

of a clear control structure within the source code and can be
either inter modular or intra modular in nature.

2. Efficiency driven restructuring: This involves restructuring a

function or algorithm to make it more efficient. A simple example
is the replacement of an IF-THEN-ELSE-IF-ELSE construct with
a CASE construct.

51
Software Maintenance

Fig. 13: Restructuring a program

52
 Software Maintenance

3. Adaption driven restructuring: This involves changing the

coding style in order to adapt the program to a new programming
language or new operating environment, for instance changing
an imperative program in PASCAL into a functional program in
LISP.

53
 Software Maintenance

Configuration Management
The process of software development and maintenance is controlled is
called configuration management. The configuration management is
different in development and maintenance phases of life cycle due to
different environments.

• Configuration Management Activities

The activities are divided into four broad categories.
1. The identification of the components and changes
2. The control of the way by which the changes are made
3. Auditing the changes
4. Status accounting recording and documenting all the activities
that have take place
54
 Software Maintenance

The following documents are required for these activities

Project plan
Software requirements specification document
Software design description document
Source code listing
Test plans I procedures I test cases
User manuals

55
 Software Maintenance
• Software Versions
Two types of versions namely revisions (replace) and variations (variety).

Version Control :

A version control tool is the first stage towards being able to manage
multiple versions. Once it is in place, a detailed record of every version of
the software must be kept. This comprises the

Name of each source code component, including the variations and

revisions
The versions of the various compilers and linkers used
The name of the software staff who constructed the component
The date and the time at which it was constructed

56
 Software Maintenance

• Change Control Process

Change control process comes into effect when the software and
associated documentation are delivered to configuration management
change request form (as shown in fig. 14), which should record the
recommendations regarding the change.

57
Software Maintenance

Fig. 14: Change request form

58
 Software Maintenance

Documentation
Software documentation is the written record of the facts about a
software system recorded with the intent to convey purpose, content
and clarity.

59
 Software Maintenance
• User Documentation
S.No. Document Function
1. Provides general description of system’s functions.
System Overview
2.
Installation Guide Describes how to set up the system, customize it to
local hardware needs and configure it to particular
hardware and other software systems.
3. Provides simple explanations of how to start using
Beginner’s Guide
the system.
4. Provides in depth description of each system facility
Reference Guide
and how it can be used.
5. Enhancement Booklet Contains a summary of new features.
6. Quick reference card Serves as a factual lookup.
7.
System administration Provides information on services such as net-
working, security and upgrading.

Table 5: User Documentation

60
 Software Maintenance

• System Documentation

It refers to those documentation containing all facets of system, including

analysis, specification, design, implementation, testing, security, error
diagnosis and recovery.

61
 Software Maintenance
• System Documentation
S.No. Document Function
1. Describes the objectives of the entire system.
System Rationale
2.
SRS Provides information on exact requirements of
system as agreed between user and developers.
3. Provides description of:
SpecificationI Design
(i) How system requirements are implemented.
(ii) How the system is decomposed into a set of
interacting program units.
(iii) The function of each program unit.
4.
Implementation Provides description of:
(i) How the detailed system design is expressed in
some formal programming language.
(ii) Program actions in the form of intra program
comments.

62
 Software Maintenance

S.No. Document Function

5.
System Test Plan Provides description of how program units are
tested individually and how the whole system is tested
after integration.
6.
Acceptance Test Plan Describes the tests that the system must pass
before users accept it.
7.
Data Dictionaries Contains description of all terms that relate to the
software system in question.

Table 6: System Documentation

63
Reference

• Software Engineering -KK Aggarwal and Yogesh

Singh.
• Software Engineering: A Practitioner's
Approach- Roger S. Pressman