SOFTWARE

MAINTENANCE

1
 Software Maintenance
Software maintenance is often considered to be
an unpleasant, time consuming, expensive and
unrewarding occupation - something that is carried out
at the end of development only when absolutely
necessary
Modification of a software product after delivery, to
correct faults, to improve performance or other
attributes, or to adapt the product to a modified
environment

Modifying a program after it has been put into use

Maintenance management is concerned with planning
and predicting the process of change
Configuration management is the management of
2
products undergoing change.
Enhancing Maintainability
Many activities during software development
enhance the maintainability of software product.
Analysis activities
Standards and guidelines
Design activities
Implementation activities
Supporting documents

From maintenance view point, the most important

activities that occur during analysis are establishing
standards and guidelines for the project and the work
products to ensure uniformity of the products, setting of
milestones to ensure that the work products are
produced on schedule, specifying quality assurance
etc. 3
 Software maintenance may be performed by the
developing organization, by the customer, or by a third
party on behalf of the customer. In any case the
customer must be given an estimate of the resources
required and likely costs to be incurred in maintaining
the system.

Standards and guidelines: various types of standards

and guidelines can be developed to enhance the
maintainability of software. Standard formats for
requirements documents and design specifications,
structured coding conventions and standardized
formats for the supporting documents like users
manual etc will contribute to the understandability and
hence maintainability of the software. Standards can
be specified by the software quality group. 4
Design activities: Architectural design is concerned
with developing the functional components, conceptual
data structures and interconnections in software
system. Detailed design is concerned with specifying
algorithmic details, concrete data representations and
details of the interfaces among routines and data
structures.

Implementation activities: Implementation, like design,

should have the primary goal of producing software
that is easy to understand and easy to modify.

Supporting documents: Maintenance guide and test

suite description are the two important supporting
documents that should be prepared during the software
development cycle in order to ease maintenance 5
activities.
 Managerial Aspects of Software Maintenance

Successful software maintenance, like all

software engineering activities, requires a combination
of managerial skills and technical expertise. One of the
most important aspects of software maintenance
involves tracking and control of maintenance activities.
Maintenance activity for a software product usually
occurs in response to a change request filed by a user
of the product.
Change requests are usually initiated by users. A
change request may entail enhancement, adaptation or
error correction. A change request is first reviewed by
an analyst, either closes the change request or submits
to the control board the change request, the proposed
fix, and an estimate of the resources required to satisfy
the request. 6
 Managerial Aspects of Software Maintenance

Change control board: The control board reviews and

approves all change requests. The board may deny,
recommend a modified version of change, or approve
the change as submitted. The analyst provides liaison
between the change control and the request initiator.
Approved changes are forwarded to the maintenance
programmers for action in accordance with the priority
and constrains established by the change control
board. The software is modified, revalidated and
submitted to the change control board for approval. If
the change control board approves, the master tapes
and external documents are updated to reflect the
changes, and the modified software is distributed to
user sites as specified by the control board. 7
 Managerial Aspects of Software Maintenance

Change Request Summaries: The status of the change

requests and software maintenance activities should
be summarized on a weekly or monthly basis. The
summary should report emergency problems and
temporary fix in effect since the last report; new change
requests received and their probable dispositional ole
open requests, along with the status of progress and
probable closing date for each; and change requests
that have been closed since the last summary report,
including a description of each closed request and its
disposition. In addition, a maintenance trends summary
should be included in each change request summary; a
trends summary graph showing the number of new
requests and the total number of open requests as a 8
function of time.
 Managerial Aspects of Software Maintenance

Quality Assurance Activities: The quality assurance

group should conduct audits and spots checks to
determine that external documents are properly
updated to reflect modifications. Quality assurance
group monitors change requests, prepares change
request summaries, performs regression testing of
software modifications, provides configuration
management, and retains and protects the physical
media for software products. The group should be
represented on the change control board and should
have sign-off authority for new releases of modified
software products. Change control is administered by
quality assurance personnel.
9
 Managerial Aspects of Software Maintenance

Organizing maintenance programmers: Software

maintenance can be performed by the development
team or my members of separate organization. There
are advantages and disadvantages to both
approaches.
Members of the development team will be intimately
familiar with the product; they will understand the
design philosophy of the system and why it functions
as it does. Also they will take great care to design and
implement the system to enhance maintainability. On
the other hand they will probably be less careful in
preparing the supporting documentation. Also they may
be assigned to new project while retaining the
responsibility for maintenance of the released product.
10
 Managerial Aspects of Software Maintenance

Maintenance by a separate group forces more

attention to standards and high quality documentation.
It is also has the advantage of releasing the
development team to pursue other activities. They can
become highly expert on various details of the product
because they devote their full attention to the product.
However, a morale problem associated with
maintenance programming, and rightly or wrongly a
stigma is often associated with being a “maintenance
programmer”.

A desirable method of organizing maintenance

programming is to periodically rotate programmers
between development and maintenance. 11
 Configuration Management

Configuration management is concerned with

tracking and controlling of the work products that
constitute a software product. Software tools to support
configuration management include configuration
management data base and version control. A
configuration management data base can provide
information concerning product structure, current
revision number, current status and change request
history for each product version.

A version control library may be part of a

configuration management data base or it may be used
as a stand-alone tool.
12
 Source-Code Metrics

A software metric is a measure of some

property of a piece of software or its specifications.
Most of the metrics incorporate easily computed
properties of the source code, such as the number of
operators and operands, the complexity of the control
flow graph, the number of parameters and global
variables in routines and the number of levels and
manner of interconnection of call graph. The
approaches taken to compute a number or set of
numbers that measures the complexity of the code.
Thus a program with measure 10 would be more
complex than a program with measure 5.

13
 The maintenance process
 Maintenance is triggered by change
requests from customers or marketing
requirements
 Changes are normally batched and
implemented in a new release of the system
 Programs sometimes need to be repaired
without a complete process iteration but this
is dangerous as it leads to documentation
and programs getting out of step

14
 The maintenance process

Change Impact System release Change System

requests analysis planning implementa tion release

Perfective Adaptive Corrective

maintenance maintenance maintenance

15
 Change processes

Change Analyze Modify Deliver repaired

requests source code source code system

Fault repair process

Change Change Requirements Software

requests analysis updating development

Iterative development process

16
 System documentation
 Requirements document
 System architecture description
 Program design documentation
 Source code listings
 Test plans and validation reports
 System maintenance guide

17
 Users
Interact with
the System
Maintainer Users
corrects Identify
problems Problem
and makes s&
improvemen Improve
ts ments

The Maintenance Lifecycle

18
 Types of Software Maintenance
 
In order for a software system to
remain useful in its environment it may be
necessary to carry out a wide range of
maintenance activities upon it. Swanson
(1976) was one of the first to examine
what really happens during maintenance
and was able to identify three different
categories of maintenance activity:
19
 Corrective
 
Changes necessitated by actual errors
(defects or residual "bugs") in a system
are termed corrective maintenance. These
defects manifest themselves when the
system does not operate as it was
designed or advertised to do.

20
 Adaptive
 
Any effort that is initiated as a result of
changes in the environment in which a
software system must operate is termed
adaptive change. Adaptive change is a
change driven by the need to accommodate
modifications in the environment of the
software system, without which the system
would become increasingly less useful until
it became obsolete.
21
 Perfective
 
The third widely accepted task is that of perfective
maintenance. This is actually the most common type of
maintenance encompassing enhancements both to the
function and the efficiency of the code and includes all
changes, insertions, deletions, modifications, ex­
tensions, and enhancements made to a system to meet
the evolving and/or expanding needs of the user. A
successful piece of software tends to be subjected to a
succession of changes resulting in an increase in its
requirements. This is based on the premise that as the
software becomes useful, the users tend to experiment
with new cases beyond the scope for which it was
initially developed. Expansion in requirements can take
the form of enhancement of existing system 22

functionality or improvement in computational efficiency.

 Preventive
 
The long-term effect of corrective, adaptive
and perfective change is expressed in Lehman's
law of increasing entropy:
 
As a large program is continuously changed,
its complexity, which reflects deteriorating
structure, increases unless work is done to
maintain or reduce it.
23
Distribution of maintenance effort

Corrective
maintenance
(17%)

Adaptive
maintenance Perfective
(18%) maintenance
(65%)

24
SOFTWARE PROCESS
AND
PROJECT METRICS

25
 Software process and project metrics are
quantitative measures that enable software engineers
to gain insight into the efficiency of the software
process and the projects conducted using the process
framework.
In software project management, we are primarily
concerned with productivity and quality metrics. The
four reasons for measuring software processes,
products, and resources (to characterize, to evaluate,
to predict, and to improve).
Software metrics refers to a broad range of
measurements for computer software. Measurement
can be applied to the software process with the
intention of improving it on a continuous basis.
Measurement can be used throughout the software
project to assist in estimation, quality control, etc
26
 Within the context of software project
management, we are concerned primarily with
productivity and quality metrics.

Measures, Metrics, and Indicators

Measure: provides a quantitative indication of the

size of some product or process attribute
Measurement: is the act of obtaining a measure
Metric: is a quantitative measure of the degree to
which a system, component, or process possesses a
given attribute.
Indication: is a metric or combination of metrics
that provide insight into software process, a software
project or the product itself. 27
Metrics in the process and project domains

Measurement is common place in the

engineering world. Metrics should be collected so that
process and product indicators can be ascertained.

Process indicators enables a software

engineering organization to gain insight into the
efficacy of an existing process. ie Process indicators
enable software project managers to: assess project
status, track potential risks, detect problem area early,
adjust workflow or tasks, and evaluate team ability to
control product quality
28
Process Metrics

Private process metrics (e.g. defect rates by

individual or module) are known only to the individual
or team concerned.
Public process metrics enable organizations to
make strategic changes to improve the software
process.
Metrics should not be used to evaluate the
performance of individuals.

Statistical software process improvement helps

and organization to discover where they are strong and
where are week. 29
Process Metrics

 Number of requests for corrective maintenance

 Average time required for impact analysis
 Average time taken to implement a change
request
 Number of outstanding change requests
 If any or all of these is increasing, this may
indicate a decline in maintainability

30
Project Metrics
 Software process metrics are used for strategic purpose, project

measures are tactical. Project metrics, and the indicators derived

from them are used by a PM and a software team to adapt project
work flow and technical activities
 Software project metrics are used by the software team to adapt

project workflow and technical activities.

 Project metrics are used to avoid development schedule delays, to

mitigate potential risks, and to assess product quality on an on-

going basis.
 Every project should measure its inputs (resources), outputs

(deliverables), and results (effectiveness of deliverables).

31
Software Measurement
 Measurement in the physical world can be categorized into two:

Direct and Indirect. Software metrics can be categorized similarly.

 Direct measures of the software engineering process include cost

and effort applied. Direct measures of the product includes lines

of code produced, execution speed, memory size and defects
reported over some set period of time.
 The cost and effort required to build the software, the number of

code produced and other direct measures are relatively easy to

collect as long as specific conventions for measurement are
established in advance.

32
Software Measurement
 Indirect measures of the product include functionality, quality,

complexity, efficiency, reliability, maintainability, and many other

“…abilities”.
 Indirect measures are more difficult to assess

Size Oriented Metrics

 Derived by normalizing (dividing) any direct measure (e.g. defects

or human effort) associated with the product or project by LOC.

 Size oriented metrics are widely used but their validity and

applicability is widely debated.

33
Function Oriented Metrics
 Function oriented metrics use a measure of the functionality

delivered by the application as a normalization value. Since

functionality cannot be measured directly, it must be derived
indirectly using other direct measures
 Function points are computed from direct measures of the

information domain of a business software application and

assessment of its complexity.
 Once computed function points are used like LOC to

normalize measures for software productivity, quality, and

other attributes.

34
Extended Function Point Metrics
 Function point measure was originally designed to be

applied to business information system application

 Feature points and 3D function points provide a

means of extending the function point concept to

allow its use with real-time and other engineering
applications.
 The relationship of LOC and function points depends

on the language used to implement the software.

35