Week-3: Taxonomy of Software Maintenance and Evolution

Software Re-engineering
(SREE)
Course Code: SESE4143

Iqra Tahir
[email protected]
 3- Perfective
Change
Perfective change is a modification undertaken to expand
the existing requirements of a system.

• enhancement of system functionality

• withdrawal of existing functionality

Perfective maintenance performed Modification of a software product

to improve the performance, after delivery to improve performance
maintainability, or other attributes of or maintainability [IEEE Std. 1219-
a computer program [IEEE Std. 1994]
610.12-1994].
 • Perfective maintenance: The
purpose of perfective
maintenance is to make a variety
of improvements, namely, user
experience, processing efficiency,
Intention-based Classification of Software Maintenance

and maintainability.
• Examples of perfective
maintenance are:
• the program outputs can be made
more readable for better user
experience;
• the program can be modified to
make it faster, thereby increasing
the processing efficiency;
• and the program can be
restructured to improve its
readability, thereby increasing its
maintainability.
• Activities for perfective
maintenance include restructuring
of the code, creating and updating
documentations, and tuning the
system to improve performance.
• It is also called “reengineering”.
Perfective maintenance
Perfective changes, or "enhancements", are all changes
made to the system to accommodate the needs of the
users.
Simply put, if something was not in the original design or
specification and the user wants it added to the system, it
is classified as a perfective change. All the new user
requirements are of this type.
 Example of Perfective
maintenance
 A robot cuts metal into even pieces.
 Enhancement: A robot will cut metal into uneven pieces.
 An automation product controls the production of pancakes.
 Enhancement: It will also bake muffins.
 A robot cuts metal into even pieces but it takes one hour to do it.
 Enhancement: A robot will do it in half an hour.
 An automation product will no longer bake pancakes.
 Enhancement: Remove this functionality.
 4- Preventive
Change
Preventive maintenance performed for the purpose
of preventing problems before they occur [IEEE
Std. 610.12-1994].

 Growing complexity.
 Deteriorated structure.
 Inconsistent documentation.
Preventive change is a modification
There is no such definition [IEEE Std.
undertaken to prevent malfunctions or
1219-1994]
to improve maintainability of the
software.
 • Preventive maintenance: The
purpose of preventive maintenance
is to prevent problems from
occurring by modifying software
Intention-based Classification of Software Maintenance

products.
• Basically, one should look ahead,
identify future risks and unknown
problems, and take actions so that
those problems do not occur.
• Preventive maintenance is very
often performed on safety critical
and high available software systems.
• The concept of “software
rejuvenation” is a preventive
maintenance measure to prevent,
or at least postpone, the
occurrences of failures (crash) due
to continuously running the
software system.
• It involves occasionally terminating
an application or a system, cleaning
its internal state, and restarting it.
• Rejuvenation may increase the
downtime of the application;
however, it prevents the occurrence
of more severe failures.
Example of Preventive Action
• Maintenance performed for the purpose of preventing
problems before they occur.
• For safety-critical systems such as the space shuttle or
aircraft systems, it is very important to prevent problems.
• A preventive change in a car would be putting the top up
on a convertible to avoid rain flooding the interior
Example of Preventive
Action
The structure of the system is very complex. It takes a lot of time to
understand the system.
Preventive change: You rewrite the system or part of it so that it is
better structured.

After being executed for a very long time, the system’s behaviour
becomes strange.
Preventive action: Switch off the system and start it again.
 • Kitchenham et al. organize
maintenance modification
activities into two categories:
• Corrections
Activity-based Classification of

Activities in this category are

designed to fix defects in the
system, where a defect is a
discrepancy between the
expected behavior and the actual
behavior of the system.
Software Maintenance

• Enhancements
Activities in this category are
designed to effect changes to the
system.
It is further divided into three
subcategories as follows:
– enhancement activities that
modify some of the existing
requirements implemented
by the system;
– enhancement activities that
add new system
requirements; and
– enhancement activities that
modify the implementation
without changing the
requirements implemented
by the system.
 Figure 2.1 Groups or clusters and their types
Evidence-based Classification of Software Maintenance

• Twelve types of maintenance

activities were grouped into four
clusters.
• Modifications performed, detected,
or observed on four aspects of the
system being maintained are used as
the criteria to cluster the types of
maintenance activities:
• the whole software;
• the external documentation;
• the properties of the program code; and
• the system functionality experienced by
the customer.
 Classification of maintenance
activities is based on
changes in the four kinds of
entities
• the whole software;
• the external documentation;
• the properties of the
program code; and
• the system functionality
Evidence-based Classification of Software Maintenance

experienced by the customer

Evidence of changes to those
entities is gathered by
comparing the appropriate
portions of the software
before the activity with the
appropriate parts after the
execution of the activity.
 • Training: This means training the
stakeholders about the
implementation of the system.
• Consultive: In this type, cost and
length of time are estimated for
maintenance work, personnel
run a help desk, customers are
assisted to prepare maintenance
work requests, and personnel
make expert knowledge about
the available resources and the
system to others in the
organization to improve
efficiency.
• Evaluative: In this type, common
activities include reviewing the
program code and
documentations, examining the
Evidence-based Classification of Software Maintenance

ripple effect of a proposed

change, designing and executing
tests, examining the
programming support provided
by the operating system, and
finding the required data and
debugging.
 • Reformative: Ordinary activities in
this type improve the readability
of the documentation, make the
documentation consistent with
other changes in the system,
prepare training materials, and
add entries to a data dictionary.
• Updative: Ordinary activities in
this type are substituting out-of-
date documentation with up-to-
date documentation, making
semi-formal, say, in UML to
document current program code,
and updating the documentation
with test plans.
• Groomative: Ordinary activities in
this type are substituting
Evidence-based Classification of Software Maintenance

components and algorithms with

more efficient and simpler ones,
modifying the conventions for
naming data, changing access
authorizations, compiling source
code, and doing backups.
 • Preventive: Ordinary
activities in this type
perform changes to
enhance maintainability,
and establish a base for
making a future transition
to an emerging technology.
• Performance: Activities in
performance type produce
results that impact the user.
Those activities improve
system up time and replace
Evidence-based Classification of Software Maintenance

components and algorithms

with faster ones.
• Adaptive: Ordinary activities
in this type port the
software to a different
execution platform, and
increase the utilization of
COTS components.
 • Reductive: Ordinary
activities in this type drop
some data generated for the
customer, decreasing the
amount of data input to the
system, and decreasing the
amount of data produced by
the system.
• Corrective: Ordinary activities
in this type are correcting
identified bugs, adding
defensive programming
strategies, and modifying the
ways exceptions are handled.
• Enhancive: Ordinary activities
in this type are adding and
modifying business rules to
enhance the system’s
functionality available to the
customer, and adding new
data flows into or out of the
software.
E v id e n c e -b a s e d C la s s ifi c a tio n o fS o ftw a re M a in te n a n c e
Evidence-based Classification of Software Maintenance
• Sometimes, an objective evidence may be found to be ambiguous. In that
case, clusters have their designated default types for use. The overall default
type is evaluative, if there are ambiguities in an activity.
 Software Maintenance

• The concept of software maintenance means preventing software

from failing to deliver the intended functionalities by means of bug
fixing.
• Maintenance does not involve making major changes to the
architecture of the system. maintenance means keeping an installed
system running with no change to its design.
• For example, bug fixing must be done and it is a planned activity.
SDLC Cost Assessment
The hierarchical ways of software maintenance
Kitchenham described maintenance modifications in a hierarchical
ways based on the concept of activity:
1. Activities to make corrections: If there are discrepancies between
the expected behavior of a system and the actual behavior, then some
activities are performed to eliminate or reduce the discrepancies.
2. Activities to make enhancements: A number of activities are
performed to implement a change to the system, thereby changing the
behavior or implementation of the system.
This category is subdivided into three types:
1. enhancements that change existing requirement,
2. enhancements that add new system requirements, and
3. enhancements that change the implementation but not the
requirements.
Categories of Maintenance Concepts

The four categories and the concepts that influence the maintenance
process have been illustrated in the following Fig. 2.3.

Overview of concept categories affecting software maintenance

 Maintained Product
The maintained product dimension is characterized by three concepts:
• Product: A product is a coherent collection of several different artifacts. Source
code is the key component of a software product.

• Product upgrade: Baseline is an arrangement of related entities that make up

a particular software configuration. Any change or upgrade made to a software
product relates to a specific baseline.
An upgrade can create a new version of the system being maintained, a patch code
for an object, or even a notice explaining a restriction on the use of the system.

• Artifacts: A number of different artifacts are used in the design of a software

product. One can find the following types of artifacts: textual and graphical
documents, component off-the-shelf products, and object code components.

The key elements of the maintained product are size, age, application type,
composition and quality.
Maintained Product
 Maintenance Types
Four types of maintenance activities are defined:

• Investigation activity: This kind of activities evaluate the impact of making a

certain change to the system.
• Modification activity: This kind of activities change the system’s
implementation.
• Management activity: This kind of activities relate to the configuration
control of the maintained system or the management of the maintenance process.
• Quality assurance activity: This kind of activities ensure that modifications
performed on a system do not damage the integrity of the system.

Activity: An activity accepts some artifacts as inputs and produces new or

changed artifacts.
Artifacts: Artifacts include plans, documents, system representations, and source
and object code items. Artifacts are created during the software development
process and changed during maintenance.
Maintenance Organization Processes

Two different levels of maintenance processes are followed within

a maintenance organization:

• Individual-level maintenance processes followed by

maintenance personnel to implement a specific change request, and

• Organization-level process followed to manage the change

requests from maintenance personnel, users, and customers/clients.
Maintenance Organization Processes

Three major elements of a maintenance organization are

• Event management: The stream of events, namely, all the change requests
from various sources, received by the maintenance organization is handled in an
event management process.

• Configuration management: A system’s integrity is maintained by

means of a configuration management process. Integrity of a product is
maintained in terms of its modification status and version number.

• Change control system: Evaluation of results of investigations of

maintenance events is performed in a process called change control. Based on
the evaluation, the organization approves a system change.
Maintenance Organization Processes

• A maintenance organization handles maintenance change requests from:

1. Users,
2. Customers, and
3. maintainers.

• After an initial investigation of a change request, a management process is

put in place for approving change activities.
• Approval of a change request is normally the responsibility of a change
control board.
• A proposed modification activity is scheduled only after the modification is
approved by the board and an Service Level Agreement (SLA) is signed with
the client.
• Service level agreement (SLA) is a contract between the customers and the
providers of a maintenance service. Performance targets for the maintenance
services are specified in the SLA.
Maintenance Organization Processes

In general, maintenance organizations use three different support levels to

organize the staff:

• Level 1: This group files problem reports and identifies the technical support
person who can best assist the person reporting a problem.

• Level 2: This level includes experts who know how to communicate with
users and analyze their problems. These people recommend quick fixes and
temporary workarounds.

• Level 3: This level includes programmers who can perform actual changes to
the product software.
 Peopleware

• Maintenance activities cannot ignore the human element, because software

production and maintenance are human intensive activities.

• The three people-centric concepts related to maintenance are as follows:

1. Maintenance organization: This is the organization that maintains

the product(s).

2. Client organization: A client organization uses the maintained

system.

3. Human resource: Human resource includes personnel from the

maintenance and client organizations.
Peopleware

Finally, the following user and customer issues affect maintenance:

• Size: The size of the customer base and the number of licenses they hold
affect the amount of effort needed to support a system.

• Variability: High variability in the customer base impacts the scope of

maintenance tasks.

• Common goals: The extent to which the users and the customer have
common goals affect the SLAs.

Ultimately, customers fund maintenance activities.

If the customers do not have a good understanding of the requirements of
the actual users, some SLAs may not be appropriate to the end
users.
 Evolution of Software Systems

• The term evolution was used by Mark I. Halpern in circa 1965

to define the dynamic growth of software.

• It attracted more attention in the 1980s after Meir M. Lehman

proposed eight broad principles about how certain types of
software systems evolve.

• Bennett and Rajlich researched the term “software evolution,”

but found no widely accepted definition of the term.

• Some researchers and practitioners used the term software

evolution as a substitute for the term software maintenance.
 Evolution of Software Systems

Lowell Jay Arthur distinguished the two terms as follows:

• Maintenance means preserving software from decline or failure.
• Evolution means a continuously changing software from a worse state to a
better state.
• Software evolution is like a computer program, with inputs, processes, and
outputs.
• Keith H. Bennett and Jie Xu use maintenance for all post-delivery support,
whereas they use evolution to refer to perfective modifications - modifications
triggered by changes in requirements.
Inputs and outputs of software evolution
© Wiley 1988
 Evolution of Software Systems

Software evolution is studied with two broad, complementary approaches:

• Explanatory (What/Why):

1. This approach attempts to explain the causes of software evolution,

the processes used, and the effects of software evolution.
2. The explanatory approach studies evolution from a scientific view point.

• Process improvement (How):

1. This approach attempts to manage the effects of software evolution by

developing better methods and tools, namely, design, maintenance,
refactoring, and reengineering.
2. The process improvement approach studies evolution from an engineering
view point.
The importance of categorising
software changes

To acquire knowledge about the different maintenance

tasks.
 When correcting changes you do not produce new software.
To set priorities to change requests.
 Enhancements are more prioritised than minor problems.
 Serious problems more prioritised than enhancements,
To estimate the cost of different modification tasks.
 Corrective maintenance should cost as little as possible.
To estimate the quality & reliability of the system.
 We should strive to minimise the number of defects.
Prioritizing change requests
Priority 1 (urgent)
Must make the change in order to continue operations.
Emergency repairs that must be implemented immediately
Altering tax tables to be compatible with tax law changes that have to be
included in the next release.
Priority 2 (critical)
The change should be made without delay as it may be associated with a
known defect that is seriously degrading system functionality or performance.
For example, error flags that keep popping up on the display
The CCB should assess this change at its next meeting and take appropriate
action to facilitate a rapid solution.
Prioritizing change requests
Priority 3 (major)
The change should be made, but delays in the
repair are tolerable.
For example, the speed in which data are filtered
could be considerably improved by replacing the
current algorithm with another more efficient one.
Even though the current algorithm gets the job
done, it does so very slowly.
Prioritizing change requests
Priority 4 (minor)
The change should be made when there are time
and resources to do it.
For example, reports are untidy and need to be
reformatted for clarity and consistency.
Although users can live with what exists, they are
asking for the change to be made because existing
reports are confusing and lead to errors.