Module - 5

Maintenance
Re-Engineering
Reverse Engineering
 Maintenance Phase
• ) Maintenance
– Any change to any component of the product
(including documentation after it has passed the
acceptance test
• This is a short chapter
• But the whole course is on maintenance
• Why is maintenance necessary?
 Maintenance Phase Slide 16.3

) Maintenance
– Any change to any component of the product (including
documentation) after it has passed the acceptance test

© The McGraw-Hill Companies, 2002

 Development vs. Maintenance

not directly linked to the real directly driven by the real

world world
freedom constrained by existing
system
defects have no immediate defects disrupt production
effect
methods available system not using current
methods
standards may be enforced shifting standards, if any
 Maintenance Characteristics

 We need to look at maintenance from three different viewpoints:

 the activities required to accomplish the maintenance phase and the

impact of a software engineering approach (or lack thereof) on the
usefulness of such activities

 the costs associated with the maintenance phase

 the problems that are frequently encountered when software

maintenance is undertaken
 Why do needs change?
⚫Given a capability, users see new ways to use it.
⚫Given a system, users see holes and gaps that they
did not anticipate.
⚫When given a system, users may find other things
that they do that might be automated.
⚫Users not involved originally may find uses (along
with special adaptations)

⚫Examples
 Why do needs change
⚫GOVERNMENT and other REGULATION
⚫The “government” is involved in many aspects of
“business”
⚫Taxes (both payroll and other versions of taxation)
⚫Regulation (regulation requires documentation)
⚫Other “outside agencies”
⚫Insurers
⚫Vendors
⚫Customers
How does the environment
change?
⚫Software has a long life – hardware does not
⚫The explosion in hardware capabilities has altered the
need for small storage and processing speed.
⚫Central server with “dumb” terminals gave way to
distributed systems in a client-server environment has
given way to many internet based applications. What’s
next?
Why is it so hard to do
maintenance?
⚫Maintenance folks are rarely the development folks.
⚫People move on, if not from the company perhaps to
new responsibilities.
⚫Our code memory is short lived. Look at code
you wrote 6 months ago and you probably will not
recognize it.
⚫Coders hate to do documentation and documentation I
might write for myself may not make sense to another
reader.
 Types of Maintenance
A. Corrective Maintenance- to repair software faults

a) Changing a system to correct deficiencies in the way meets

its requirements

B. Adaptive Maintenance - to adapt software to a different operating

environment

a) Changing a system so that it operates in a different environment

(computer, OS, etc.) from its initial implementation

C. Perfective Maintenance - to add to or modify the system’s

functionality

a) Modifying the system to satisfy new requirements

D. Preventive Maintenance – to re-engineer and/or re-structuring the

existing software
 Types of Maintenance
Preventive(4%)
4%
Fault repair
(17%)
Corrective

software
Functionality adaption
addition or (18%)
modification Adaptive
(61%)
Perfective
 Types of maintenance (contd)

Corrective maintenance
To correct residual faults
Specification, design, implementation,
documentation, or any other types of faults
On average, 17.5% of maintenance
 Example:
 Types of maintenance (contd)

Perfective maintenance
Client requests changes to improve product effectiveness
Add additional functionality
Make product run faster
Improve maintainability
On average, 60.5% of maintenance
Example:
 Types of maintenance (contd)

Adaptive maintenance
Responses to changes in environment in which product
operates
Product ported to new compiler, operating system,
and/or hardware
Change to tax code
9-digit ZIP codes
On average, 18% of maintenance
Example:
 Types of maintenance (contd)

Perfective maintenance
To re-engineer
Add comments to program
Documentation
 Structure Programming
 Restructuring transformation of the system’s code without
changing its behavior
On average, 4% of maintenance
Example:
 The Maintenance Process
 Maintenance process vary considerably depending on the types of
software being maintained, the development processes used in an
organization and people involved in the process.

Change Impact Release Change System

requests analysis planning implementation release

Fault Flat form System

repair adaptation enhancement
 The Rewards of Maintenance
 Maintenance is a thankless task in every way
Maintainers deal with dissatisfied users
If the user were happy, the product would not need
maintenance
The user’s problems are often caused by the
individuals who developed the product, not the
maintainer
The code itself may be badly written
Maintenance is despised by many software
developers
Unless good maintenance service is provided, the
client will take future development business
elsewhere
Maintenance is the most important phase of
software production, the most difficult—and most
thankless
 Problems in Managing Maintenance
 Changing priorities
 chaotic nature of maintenance requests, the length of
maintenance tasks causing new requests to come along before an
ongoing task is done.
 Inadequate testing methods
 lack of time set aside for testing, of comprehensive test data, of
rigorous testing requirements as a standard for signing off.
 Performance measurement difficulties
 how do you measure individual or group performance?
 System documentation incomplete or non-existent
 training takes a long time for learning an application so
programmers get stuck on one piece of software.
 Adapting to the rapidly changing business environment
 hardware and software also become obsolete .
 Maintenance Side Effects

In this context a side effect implies an error

or undesirable behavior that occurs as the
result of a modification.

the three major areas are

code

data structures

documentation
 Software Rejuvenation

 Re-documentation
Creation or revision of alternative
representations of software
at the same level of abstraction
Generates:
data interface tables, call graphs,
component/variable cross references etc.
 Restructuring
transformation of the system’s code without
changing its behavior
 Software Rejuvenation (cont’d)

 Reverse Engineering
Analyzing a system to extract information about the behavior
and/or structure
also Design Recovery - recreation of design abstractions
from code, documentation, and domain knowledge

Generates:
structure charts, entity relationship diagrams, DFDs,
requirements models

 Re-engineering
Examination and alteration of a system to reconstitute it in
another form
Also known as renovation, reclamation
 How do we improve
maintainability?

⚫Well documented development process.

⚫Why were decisions made?
⚫What is the scope of the existing product? ($$$$)
⚫What were the design decisions specifically?
⚫Standards maintained throughout the coding.
⚫Highly maintainable code is well compartmentalized.
⚫Highly maintainable code uses well understood patterns.

⚫All of the things that have led us to this point in the

course.
 Support includes
⚫A mechanism for customers to report defects
⚫A mechanism for recording and categorizing
defects
⚫minor cosmetic issues may take a back seat to
⚫major functionality issues
⚫A mechanism for systematically correcting defects,
testing resulting code and deploying corrections.

This is all costly to the organization, but a necessary

step.
24
Software Re-engineering

 It is a process of software development which is done to

improve the maintainability of a software system. Re-
engineering is the examination and alteration of a
system to reconstitute it in a new form. This process
encompasses a combination of sub-processes like
reverse engineering, forward engineering,
reconstructing , restructuring etc.
 System re-engineering

⚫ Re-structuring or re-writing part or all of a

legacy system without changing its functionality
⚫ Applicable where some but not all sub-systems
of a larger system require frequent
maintenance
⚫ Re-engineering involves adding effort to make
them easier to maintain. The system may be re-
structured and re-documented
 When to re-engineer

⚫ When system changes are mostly confined to

part of the system then re-engineer that part
⚫ When hardware or software support becomes
obsolete
⚫ When tools to support re-structuring are
available
 Re-engineering advantages

⚫ Reduced risk
• There is a high risk in new software development. There may
be development problems, staffing problems and specification
problems
⚫ Reduced cost
• The cost of re-engineering is often significantly less than the
costs of developing new software

©Ian
Sommervill
Slid
e 2000

e
Reengineering

Business processes

IT
systems Software
Reengineering
applications

12
Reengineering

⚫At some point, the cost to maintain

software becomes too great or the
product is breaking down at an
unacceptable rate.
⚫OR Business needs change and you
need to reengineer processes and
along with that the software systems
that support those processes.
 Business Process
Reengineering (BPR)

Goals broad
categories: cost
reduction
time reduction
quality improvement
empowerment

14
 BPR Principles

⚫Organize around outcomes, not tasks.

⚫Have those who use the output of the process perform the
process.
⚫Incorporate information processing work into the real work
that produces the raw information.
⚫Treat geographically dispersed resources as though they were
centralized.
⚫Link parallel activities instead of integrated their results.
When different
⚫Put the decision point where the work is performed, and build
control into the process.
⚫Capture data once, at its source.
15
Software
Reengineering
Forward inventory
engineering analysis

Data document
restructuring restructuring

code reverse
restructuring engineering

16
Forward engineering and re-
engineering

Software Engineering, 6th edition. Chapter 28

 The Re-engineering Process

Program Modularised Original data

Original
documentation program
program

Reverse
engineering
Data
Source code Program reengineering
translation modularisation

Program
structure
improvement
Structured Reengineered
program data
 Re-Engineering Cost Factors

 The quality of the software to be re-

engineered

 The tool support available for re-engineering

 The extent of the data conversion which is

required

 The availability of expert staff for re-

engineering
 Re-Engineering Approaches

Automated program Program and data

restructuring restructuring

Automated source Automated restructuring Restructuring plus

code conversion with manual changes architectural changes

Increased cost
 Source Code Translation

 Involves converting the code from one

language (or language version) to another

 May be necessary because of:

 Hardware platform update

 Staff skill shortages

 Organisational policy changes

 Only realistic if an automatic translator is

available
Inventory Analysis
⚫build a table that contains all applications
⚫establish a list of criteria, e.g.,
⚫name of the application
⚫year it was originally created
⚫number of substantive changes made to it
⚫total effort applied to make these changes
⚫date of last substantive change
⚫effort applied to make the last change
⚫system(s) in which it resides
⚫applications to which it interfaces, ...
⚫analyze and prioritize to select candidates for
reengineering

17
 Document Restructuring
⚫Weak documentation is the trademark of many legacy
systems.
⚫But what do we do about it? What are our options?
⚫Options …
⚫Creating documentation is far too time consuming. If
the system works, we’ll live with what we have. In
some cases, this is the correct approach.
⚫Documentation must be updated, but we have limited
resources. We’ll use a “document when touched”
approach. It may not be necessary to fully redocument
an application.
⚫The system is business critical and must be fully
redocumented. Even in this case, an intelligent approach
is to pare documentation to an essential minimum. 18
 Advantages and Disadvantages
40
 Reduced Risk:
 Reduced Cost:
 Revelation of Business Rules:
 Better use of Existing Staff of Re-engineering:

 Practical limits to the extent of re-engineering.

 Major architectural changes or radical reorganizing
of the systems data management has to be done
manually.
 Re-engineered system is not likely to be as
maintainable as a new system developed using
modern software Re-engineering methods.
 Key points

⚫ The objective of re-engineering is to improve the

system structure to make it easier to understand
and maintain
⚫ The re-engineering process involves source
code translation, reverse engineering, program
structure improvement, program modularisation
and data re-engineering
⚫ Source code translation is the automatic
conversion of of program in one language to
another ©Ian
Sommervill
Slid
e 2000

e
 Reverse Engineering

 Analysing software with a view to understanding its

design and specification

 May be part of a re-engineering process but may also

be used to re-specify a system for re-implementation

 Builds a program data base and generates information

from this

 Program understanding tools (browsers, cross-

reference generators, etc.) may be used in this process
Reverse engineering

⚫ Analysing software with a view to

understanding its design and specification
⚫ May be part of a re-engineering process but
may also be used to re-specify a system for
re- implementation
⚫ Builds a program data base and generates
information from this
⚫ Program understanding tools (browsers,
cross- reference generators, etc.) may be
used in this process
©Ian
Sommervill
Slid
e 2000

e
44 Objectives of Reverse Engineering

 Coping with complexity.

 Figuring out the side effects.
 Recovering the lost information.
 Higher abstraction synthesis.
45
Reverse Engineering

19
 The Reverse Engineering Process

Program stucture
Automated diagrams
analysis
System
System to be Document Data stucture
information
re-engineered generation diagrams
store
Manual
annotation Traceability
matrices
 Reverse engineering

⚫ Reverse engineering often precedes re-

engineering but is sometimes worthwhile in its
own right
• The design and specification of a system may be reverse
engineered so that they can be an input to the requirements
specification process for the system’s replacement
• The design and specification may be reverse engineered to
support program maintenance
Program structure improvement

⚫ Maintenance tends to corrupt the structure

of a program. It becomes harder and harder
to understand
⚫ The program may be automatically
restructured to remove unconditional
branches
⚫ Conditions may be simplified to make them
more readable
 Key points

⚫ Reverse engineering is the process of deriving

the system design and specification from its
source code
⚫ Program structure improvement replaces
unstructured control constructs with while loops
and simple conditionals
⚫ Program modularisation involves reorganisation
to group related items
⚫ Data re-engineering may be necessary because
of inconsistent data management