CS189A/172 - Winter 2008

offbeatnothingΛογισμικό & κατασκευή λογ/κού

2 Δεκ 2013 (πριν από 3 χρόνια και 6 μήνες)

63 εμφανίσεις


Winter 2008

Lecture 15: Software Maintenance

Software Maintenance

What is software maintenance?

Software maintenance is the process of modifying the software
system or component after the delivery to correct faults, improve
performance or other attributes, or adapt to a change in

Maintenance Is Costly

For most software, software maintenance occupies between 40 to 90
percent of total life cycle costs

A common mistake is to overlook maintenance costs:

In 1950s, when banks were hiring their first full
time programmers
they were worried about what these people will do after the
programs were written

Maintenance is challenging

When US banks introduced ATMs, existing banks had difficulty in
adapting their software to the new system, whereas new banks
writing software from scratch had an easier time

In UK two mergers of financial institutions were canceled due to
problems of integrating software from two different organizations

Types of Software Maintenance

Perfective maintenance

Changes required as a result of user requests to improve some of
the qualities of the software

Adaptive maintenance

Changes needed as a consequence of change in the environment
of the software such as operating system, hardware or change in
the requirements

Corrective maintenance

The identification and removal of faults in the software

Preventive maintenance

Changes made to software to make it more maintainable

Software Maintenance Issues

The important requirement for the client is that changes are
accomplished quickly and cost effectively

The reliability of the software should not be degraded by the changes

A program used in a real world environment has to change or it will
progressively become less useful

As a program keeps evolving its structure tends to become more
complex, extra resources must be devoted to preserving the semantics
and simplifying the structure

When the source code for the software changes, this has a ripple effect
since also the documentation, design and test suites have to change

Organizational Issues

Initial software development is product
oriented where the aim is
to deliver a product within budget and timescale

Software maintenance on the other hand is closer to a service

Some companies choose to outsource maintenance

not a good idea for the core products

outsourcing company will spend sometime assessing the
software before accepting the contract

Service level agreements between the customer and the
maintenance organization are used to define the service to be
provided during maintenance

Unfortunately for software products we are more likely to see
agreements in the form of

rather than

Process Models for Maintenance

Process management is defined as the direction, control and
coordination of work performed to develop a product or perform a

A common process model for software maintenance has four key

Help desk:

The problem is received, a preliminary analysis
undertaken, and if the problem is sensible, it is accepted


A managerial and technical analysis of the problem is
undertaken to investigate and cost alternative solutions


The chosen solution is implemented and tested


The change (along with possibly others) is released to the

IEEE Standard for Software Maintenance

IEEE Standard defines seven stages of software maintenance activity:

Problem Identification




System Test

Acceptance Test


Each of the seven activities have:

input life cycle products: inputs to this activity

output life cycle products: deliverables of this activity

activity definition

control: a set of quality control actions

metrics: the measurements that should be performed

IEEE Standard for Software
Maintenance: Analysis Phase

For example the analysis phase accepts a validated problem report,
initial resource estimates and project and system documentation

Analysis phase has two components

Feasibility analysis: Assess the impact of the modification,
investigate alternative solutions, assess short and long term costs,
compute benefit of making the change

Detailed analysis: Once a particular approach is chosen, in detailed
analysis phase, requirements for the modification, the software
components involved are identified, a test strategy and an
implementation plan is produced

IEEE Standard for Software
Maintenance: Analysis Phase

Analysis phase produces the following deliverables:

Feasibility report for problem reports

Detailed analysis report

Updated requirements

Preliminary modification list

Development, integration and acceptance test strategy

Implementation plan

Technical Aspects of Software

Certain technical issues are common to both software development
and maintenance

configuration management and version control (CVS, RCS)

Some technical issues are unique to software maintenance

to determine the cost of making a change to meet a software
change request

Impact Analysis

Ripple effect propagation is a phenomenon by which changes made to
a software component along the software life cycle (specification,
design, code, or test phase) have a tendency to be felt in other

Impact analysis

the task of assessing the effects for making the set of changes to a
software system

translate the user identified problem into software terms, the
primary components of the system which must be altered to meet
the new requirement

figure out the changes that will be the consequence of the primary
change in all components not just code

Impact Analysis

Most modern programming languages and compilers will do some
static analysis to report the incompatibilities which result from changes
in one part of the code

an automated impact analysis to prevent undesirable ripple effects


Traceability is a degree to which a relationship can be established
between two or more products of the development process, especially
products having a predecessor successor or master subordinate
relationship to one another

If software products are traceable, impact analysis will be easier

when you make a change in your design you would like to figure
out which software components will be effected by that change

Legacy Systems

Legacy systems

typically an old, large, heavily modified system

none of the original developers may still be around

the languages may be out of date

It is estimated that there 70 billion lines of COBOL code in existence
still doing useful work

Legacy Systems

Different options about the maintenance of legacy systems:

keep the legacy software, subcontract the maintenance to
companies who specialize on maintenance of legacy systems

replace parts of the software

implement from scratch

discard software and discontinue

freeze maintenance and phase in a new system

encapsulate the old system and call as a server to the new

reverse engineer the legacy system and develop a new software

Reverse Engineering

Reverse engineering is the process of analyzing a subject system to
identify the system’s components and their inter
relationships, and to
create representations of the system in another form or at a higher
level of abstraction


Producing call graphs or control flow graphs from source code

Generating class diagrams from the source code

Reverse Engineering

Two types of reverse engineering:

Redocumentation: the creation or revision of a semantically
equivalent representation within the same relative abstraction layer

For example adding indentation to the source code

Design recovery: involves identifying meaningful higher level
abstractions beyond those obtained directly by examining the
system itself

Reverse Engineering

The main goal is to help with the program comprehension

Most of the time reverse engineering makes up for lack of good

Documentation required in the implementation phase and the
maintenance phase maybe different

Program documentation written in the implementation phase can be
very useful in the maintenance phase

Javadoc, docgen


During the maintenance phase the product may need to be

Restructuring: the transformation from one representation to
another at the same relative level of abstraction, while preserving
the system’s internal behavior

engineering: The examination and alteration of the subject
system to reconstitute it in a new form, and the subsequent
implementation of the new form



Control flow restructuring to remove “spaghetti code”

Converting monolithic code to use procedures

Identifying modules and abstract data types

removing dead code and redundant variables

simplifying aliased/common or global variables


A reengineering technique called refactoring became quite popular


is a change made to the internal structure of software to
make it easier to understand and modify without changing its
observable behavior

Refactoring: A Example

For example assume that you have a method which looks like:

class Promotion

choosePromotion(Account anAccount) {

switch (anAccount.getType()) {

case SILVER: ...

case GOLD: ...

case PLATINUM: ...



Refactoring: An Example

One can refactor this code by subtyping the

class and
moving the

method to the

This would get rid of the switch statement in the code and make it
easier to maintain

class Account

choosePromotion() { ... }

Refactoring Catalog

The idea is that one can generalize refactoring transformations and
catalog them

similar to design patterns

There is a catalog of refactoring transformations in the following book:

“Refactoring: Improving the Design of Existing Code,” by Martin
Fowler, Addison Wesley

One can use this refactoring catalog to look for refactorings that are
applicable to a software system

Refactoring Catalog

Each entry in the catalog has five parts:

: useful in creating a vocabulary for refactorings

: a summary of the situation where the refactoring would
be needed and a summary of what it does

: why the refactoring should be done, and the
circumstances when it shouldn’t be done

: explaining how to carry out the refactoring

: demonstrating how the refactoring works

Why Reverse or Re
Engineer a System?

Here are some reasons for reverse or re
engineering a software

To enforce product or process standards

To permit better maintenance management

To simplify complex software

Facilitating detection of errors

Removing side effects

Improve code quality

Production of up
date documentation

Preparing full test suites

Improving the performance

Bringing into line with practices elsewhere in the company

To allow major changes to be made

To discover design and requirements specification

To establish a reuse library

To introduce technical innovation such as new user interface