Software
Maintenance
OBJECTIVES
• To appreciate need of Software maintenance
performed.
• To understand reasons for change taking place in a
software system.
• To appreciate the concept of legacy system.
• To know Software maintenance prediction.
• To list various factors which adversely affect
software maintenance.
• To know types of software maintenance, viz.
corrective, adaptive, perfective, and preventive
maintenance.
• To understand the Software maintenance life cycle.
OBJECTIVES
•To know various software maintenance models, viz.
quick-fix, iterative enhancement and reuse model.
• To understand various techniques for maintenance,
such as configuration management, impact analysis
and software rejuvenation.
• To list various tools that assist in maintaining the
software.
• To appreciate need for technology change
management, which is a process of identifying,
selecting and evaluating new technologies.
• To understand software maintenance
documentation.
CONTENTS
•
•
•
•
•
•
•
•
Basics of software maintenance
Types of software maintenance
Software maintenance life cycle
Software maintenance Models
Techniques for maintenance
Tools for Software maintenance
Technology change management(TCM)
Software maintenance documentation.
BASICS OF SOFTWARE MAINTENANCE
IEEE defines maintenance as :
A process of modifying a software system or
component after delivery to correct faults, to
improve performance or other attributes, or to
adapt the product to a changed environment’.
‘
• In software engineering a software needs to be
‘serviced’ so that it is able to meet the changing
environment (such as business and user needs)
where it functions this servicing of software.
 Providing Continuity of Service
Fixing errors, recovering from failures, such as hardware
failures or incompatibility of hardware with software, and
accommodating changes in the operating system and the
hardware.
 Supporting Mandatory Upgrades
Due to changes in government regulations or students to
maintain competition with other software that exist in the
same category.
 Improving the Software to Support User Requirements
To enhance functionality in a software, to improve
performance .
 Facilitating Future Maintenance Work
Include restructuring of the software code and database
used in the software.
 Improving the Software to Support User Requirements
To enhance functionality in a software, to improve
performance .
 Facilitating Future Maintenance Work
Include restructuring of the software code and database
used in the software.
Changing a Software System
•Software maintenance and evolution of system was first
introduced by Lehman.
•One of the key observations of the studies was that large
system are never complete and continue to evolve and as
these system evolve, they become more complex unless
some actions are taken to reduce the complexity.
•Lehman stated five laws for software maintenance and
evolution of large systems.
Lehman Laws for software maintenance and evolution of
large systems
Law
Description
Law of continuing
change
A program that is used in a real-world environment
necessarily must change or become progressively less
useful in that environment.
Law of increasing
complexity
As an evolving program changes, its structure tends to
become more complex. Extra resources must be devoted to
preserving and simplifying the structure.
Law of conservation
of familiarity
For E-Systems to efficiently continue to evolve a deep
understanding of how the system functions, and why it has
been developed to function in that manner, must be
preserved at all costs.
The incremental change in each release over the life time of
the system is approximately constant.
Law of conservation
of organizational
stability
Over a program’s lifetime, its rate of development is
approximately constant and independent of the resources
devoted to system development.
Lehman Laws for software maintenance and evolution of
large systems
Law
Description
Law of self regulation
Global E-type system evolution processes are selfregulating, and distribution of product and process
measures close to normal.
Law of continuing
growth
E-type system’s functional capability must be continually
enhanced to maintain user satisfaction over system lifetime,
BUT expansion of the system size can have negative affects
to the ability to be comprehended along with its ability to
evolve.
Law of declining
quality
Poorly modified systems lead to introduction of defects; &
The quality of E-type systems will appear to be declining as
newer products emerge.
Law of feedback
system
To sustain continuous change or evolution, & to minimize
threats of software decay & loss of familiarity, feedback to
monitor the performance is must.
Feedback helps to collect metrics on the systems and
maintenance efforts performance.
Legacy Systems
• Were developed before the introduction of structured
programming .
• Process models and basic principles such as modularity
coupling, cohesion, good programming practice
emerged too late for them.
• Legacy system are generally associated with high
maintenance costs.
• The root cause of this expense is the degraded structure
that results from prolonged maintenance.
Legacy System Characteristics
Characteristics
Description
High maintenance
cost
Results due to combination of other system
factors, such as complexity, poor documentation
and lack of inexperienced personnel.
Complex software
Results due to structural degradation, which
must have occurred over a legacy system’s
lifetime of change.
Obsolete support
software
Support software may not be available for a
particular platform, or no longer be supported by
its original vendor or any other organization.
Obsolete hardware
Legacy system’s hardware may have been
discontinued.
Legacy System Characteristics
Characteristics
Description
Lack of technical
expertise
Original developers of a legacy system are
unlikely to involved with its maintenance today.
Business critical
Many legacy system are essential for the proper
working of the organizations which operate
them.
Poorly documented
Documentation is often missing or inconsistent.
Poorly understood
As a consequence of system complexity and
poor documentation, software maintainers often
understand the legacy system poorly.
Software Maintenance Prediction
Software Maintenance Prediction
The various predictions shown in the figure are closely
related and specify the following:
• The decision to accept a system change depends on the
maintainability of the system components affected by that
change up to a certain extent.
• Implementing change degrades the system structure and
hence reduces its maintainability.
• Costs involved in implementing change depend on the
maintainability of system components.
Process metrics are used to predict software maintainability.
Some of the useful Process metrics are:
Corrective maintenance:
While fixing failures some times more errors are
introduced rather than being repaired. This shows decline
in maintenance.
• Average time required for impact analysis:
The time that goes into analysis of impact of modifications
before starting the software maintenance.
• Number of outstanding change requests:
Increasing number of outstanding change requests with
time implies decline in maintainability.
• Average time to implement a change request:
If the time taken to implement the change in software and
its documentation, rather than impact assessment,
increases, it implies decline in maintainability.

Components of Software Maintenance Framework
Components
Features
User requirements
• Request for additional functionality, error
correction, capability and improvement in
maintainability.
• Request for non-programming
related support.
Organizational
Environment
• Change in business policies.
• Competition in market.
Operational
Environment
• Hardware platform.
• Software specifications.
Components of Software Maintenance Framework
Components
Features
Maintenance Process
• Capturing requirements
• Variation in programming and working
practices.
• Paradigm shift.
• Error detection and correction.
Software Product
• Quality of documentation.
• Complexity of programs.
• Program Structure.
Software Maintenance
team
• Staff turnover.
• Domain expertise.
Factors Affecting Software Maintenance
• Relationship of Software product and
Environment
• Relationship of Software product and User
• Relationship of Software product and Software
Maintenance team
Software Maintenance team
 Software Maintenance Team:
 Various functions performed by the Software






Maintenance team are:
Locating information in system documentation
Keeping system documentation up-to-date
Extending existing functions to accommodate new or
changing requirements
Adding new functions to the system
Finding the source of system failures or problems
Managing change to the system as they are made.
 The aspects of a maintenance team that lead to high maintenance
costs are:
 Staff turnover
 Domain expertise
TYPES OF SOFTWARE MAINTENANCE
• Corrective maintenance is concerned with fixing
reported errors in the software.
• Adapting maintenance means changing the software
to some new environment, such as adapting a new version
of an operating system.
• Perfective maintenance involves implementing new
functional or non-functional requirements.
• Preventive maintenance involves implementing,
changes to prevent occurrence of errors.
Types of Software Maintenance
Phases of Software Maintenance Life Cycle
Attributes of Software
Maintenance Life
Cycle
Attributes of SMLC
Phases
Input
Process
Control
Output
Problem
identification
phases
• Modification request
•Assign change number
•Classify modification
request
• Accept or reject
change
• Prioritize
• Uniquely identified
modification request
• Enter modification
request in repository
• Validated
modification
request
• Validated Process
determinations
Analysis
phases
• Project document
• Repository
information
• Validated
modification
request
• Feasibility analysis
• Detailed analysis
•Conduct technical
review
• Verify test strategy
• Verify whether the
documentation is
updated or not
• Identify security
issues
• Feasibility report
• Detailed analysis
report
• Updated requirements
• Preliminary
modification
list
• Test strategy
Design
phases
• Project document
• Source code
• Databases
• Analysis phases
output
• Software test cases
• Revise requirements
• Revise
implementation
plan
• Software inspections/
reviews
• Verify design
• Revised modification
list
• Revised detailed
analysis
• Updated test plan
Phases
Input
Process
Control
Output
Implementation
phases
• Source code
• System documentation
• Results of design
phases
• Software
code
• Unit test
• Test
preparation
review
• Software
inspections/
review
• Updated Software
• Updated design
documents
• Updated test documents
• Updated user documents
• Test preparation review
report
System test
phase
• Updated software
documentation
• Test preparation
review report
• Updated System
• Functional
test
• Interface
testing
• Test
preparation
review
• Software code
listing
• Modification
request
• Test
documentation
• Test system
• Test reports
Acceptance
test phase
• Test preparation
review report
• Full integrated system
• Acceptance test plans
• Acceptance test cases
• Acceptance test
procedures
• Acceptance
test
• Interoperability
test
• Acceptance
test
• Acceptance test report
Delivery
phase
• Tested/ accepted system
• Installation
• Training
• Version
description
document
• Version description
document
SOFTWARE MAINTENANCE MODELS
• Quick-fix model.
• Boehm’s model
• Osborne’s model
• Iterative enhancement model.
• Reuse-oriented model.
• Identify problem & fix it as
quickly as possible
• No analysis of effects is made,
and there is little or no
documentation to use
• Gets work done quickly with
lower cost
• In Quick-fix model starting
point of maintenance is always
source code.
Quick-fix
Model
Boehm's model: Economic Model
• Maintenance process represented as a closed loop cycle
• Maintenance process is driven by the maintenance manager’s
decisions, which are based on the balancing of objectives against the
constraints
• It is the stage where management decisions are made that drives the
process
• In the stage, asset 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
Osborne’s Model
• It deals directly with the reality of the maintenance
environment, where as other models tend to assume some
facet of an ideal situation - the existence of full
documentation, for example.
• The maintenance model is treated as continuous iterations
of the software life-cycle with, at each stage, provision made
for maintainability to be built in.
• If good maintenance features already exist, for example full
and formal specification or complete documentation, all well
and good, but if not, allowance is made for them to be built
in.
• Many technical problems which arise during maintenance
are due to inadequate management communications and
control
The Model
Iterative Enhancement Model
This model requires
complete
documentation as
starting point of each
iteration
Analyze
Existing System
It is similar to
evolutionary
development
paradigm
It is a three
stage cycle
Redesign
Current Version
& Implement
Characterize
Proposed
Modifications
Existing documentation for each stage is:
- Requirement documentation, Design Documentation, Source code
documentation, & Test documentation
Iterative Enhancement Model
The Reuse-Oriented Model
 Maintenance is viewed as the activity
involving the reuse of existing
program components.
 It builds a component library for
reusing requirements, design, source
code, and test-data.
 A detailed framework is required for
classification of components for
reuse.
Reuse-oriented Model
Component Library
The Reuse-oriented Model has 4 main steps:
 Identifying the parts of the old system which
have the potential for reuse,
 Fully understanding the system parts,
 Modifying the old system parts according to the
new requirements, and
 Integrating the modified parts into the new
system.
TECHNIQUES FOR MAINTENANCE
Configuration Management
• In organizations Configuration Control Board (CCB) is
constituted to oversee the entire change process.
• Request for change is received on a formal change request
form.
• The change control form should include information about
how the system works, nature of the problem, and how the
new (expected) system should work.
• The request for change is reported to the Configuration
Control Board.
• The representative of CCB meets the user to discuss the
problem.
Configuration Management – Cont….
 When the user requests for a reported failure, the CCB
discusses the source of the problem.
 If the requested change is an enhancement, the CCB
discusses the parts or the components that will be affected
by the change.
 In both the cases, developers describe the scope of change
and the expected time to implement them.
 Finally, all the relevant documentation is updated
according to the requested change.
 The developers then record all the changes made to the
operational system in a change report to keep track of the
next release or version of the software system.
Software Versions
 Version control implies the process by which the contents
of the software, hardware, or documentation are revised.
 Not that the software configuration management manages
how the versions differ, who made the changes, and why
they were made.
 The records, such as name of the component, date and
time, version status, and account of all changes are
managed.
 This helps the software configuration management to
identify the current version and the revised number of the
operational system.
Impact Analysis
Impact analysis is used to evaluate risks associate with change.
Includes estimating effect on effort schedule, and resources.
Impact analysis is also used to determine the consequences of
making modifications in the software system and to analyze
the cost and benefits of the modifications.
Advantages of Impact Analysis are:
• To understand situations when the modifications required in
the software system affect large segments of software code or
several components of the software.
• To understand relationship of the components that are to be
modified along with the structure of the software.
• To record the history of modification, which helps in
maintaining quality in the software system.
Software Rejuvenation
 May include enhancing or completely replacing a software
system. To preserve or increase the software quality, and
its maintainability while keeping the costs low.
 Four types of software rejuvenation exist, namely:
o
o
o
o
redocumentation,
restructuring,
reverse engineering, and
re-engineering.
Redocumentation
To produce additional information, which helps the software
maintenance team to understand and refer to the code.
In source code, components size, component calls, calling
parameters, and control paths are examined to understand
what and how code does it.
The output of static code analysis is either graphical or
textual, which can be used to assess whether or not
redocumentation is required.
Restructuring
Involves transformation of unstructured code into structured
code.
Restructuring involves the following steps:
 Static analysis is performed, which provides information
that is used to represent code as directed graph or
associative (semantic) network. The representation may or
may not be in a human readable form; thus, an automated
tool is used.
 Transformation techniques are used to refine (simplify) the
representation.
 Refined representation is interpreted and used to generate
the structured code.
Reverse Engineering
Focuses on providing information about the specification and
design information using the software code.
Reverse Engineering involves the following steps:
• Source code is collected with the help of an automated tool
used for reverse engineering. This tool is used to represent
the structure and the naming information of variable,
functions and other components in the software code.
• Static analysis is performed.
• Some methods, such as ‘structure analysis and design’
methods are used. These methods are used to extract
information such as data dictionaries, data-flow, control
flow, and entity relationship (ER) diagram for the reverse
engineering technique.
Re-engineering : is extension of reverse engineering :
Re-engineering refers to the systematic transformation of the
present software system into a new form to make quality
improvements in operation, system capability, functionality,
and achieving high performance at low costs.
Reverse Engineering involves the following steps:
 The system is reverse engineered and represented
internally for human and computer modifications.
 The software system is corrected and completed. This
includes updating internal specification and design.
 Using new specification and design, a new system is
generated.
Software Maintenance Tools
Name
Description
File comparators
Compares two files or systems and maintains the record for the
differences in files. In addition, it determines whether the two files or
the systems are identical or not.
Compilers and
linkers
Compilers are used to check syntax errors and (in some cases) locate
the type of errors. When the code is compiled , a linker is used to link
code with other components, which are required for executing the
program. Linkers sometimes are used to track the version numbers of
the components so that appropriate versions are linked together.
Debugging
Allows to trace the logic of the program and examines the contents of
the registers and memory areas.
Cross-reference
generators
Assures that the changes in code are in compliance with the existing
code. When a change to a requirement is requested, this tool enables
one to know which other requirements, design, and code components
will be affected.
Static code analyzers
Measures information about the code attributes, such as number of
lines of codes, number of spanning paths and so on. This can be
calculated when the new versions of system are developed.
TECHNOLOGY CHANGE MANAGEMENT (TCM)
• To incorporate new technology into business activities,
technology change management is used.
• Technology change management is a process of
identifying, selecting and evaluating new technologies
(such as tools, methods, and process) to incorporate the
most effective technology in a software system.
Software Maintenance Documentation
1.0 Scope
1.1 Application
2.0 Content
2.1 System description
2.2 System diagram
2.3 System logic and date flow
2.4 program/data module
description
- Structured charts
- Module names
- Functions and calling
procedure
- Data structure description
- Program module inputs
- program outputs
- Program interfaces
- Tables
- Files
- Structured pseudocode
2.5 Operating environment
- Hardware
- Supporting software
+ Operating System
+ Compiler/ assembler
+ Other software
- Database
2.6 Software maintenance procedures
- Programming conventions
- Source library maintenance
procedures
- Test and verification procedures
Types of user Documentation Associated with Software System
Modified
Evaluators
System
Administrator
Novice
users
Experience
d users
System
Administrator
Users
Functional
Description
Installation
Guide
User
Manual
Reference
Manual
System
Administrator
Guide
Release
Note
Description
of Services
Provided
How to
Install
the
System
Getting
Started
with the
System
Details of
all
System
Facilities
How to
Operation
and
Maintain
the System
Informat
ion
about
bug fixes
System
Types of User Documentation Associated with Software System Modified
Adapted from:
1- Software Engineering: Principles and Practice, By Rohit Khurana,
Vikas Publishing House, Delhi
& Practices, 2nd edition, by Penny Grubb and
Armstrong A. Takang
2- Software Maintenance Concepts