Software Maintenance and Computer

Aided Software Engineering (CASE)

(Lecture 12)

Mayank Singh

1
Introduction

Software maintenance:
any modifications to a software
product after it has been delivered to
the customer.

Software maintenance is an
important activity for many
organizations.

2
Introduction

Maintenance is inevitable for almost
any kind of product.

Most products need maintenance:
due to wear and tear caused by use.

Software products do not need
maintenance on this count.

3

ACT = KLOCadded + KLOCdelected / KLOCtotal

Maintenance Cost = ACT * total

development cost
Introduction

Many people think
only bad software products need
maintenance.

The opposite is true:
bad products are thrown away,
good products are maintained and
used for a long time.

5
Introduction

Software products need
maintenance for three
reasons:
corrective
adaptive
perfective

6
Corrective

Corrective maintenance of a
software product:
to correct bugs observed
while the system is in use.
to enhance performance of
the product.

7
Adaptive

A software product needs
maintenance (porting) when
customers:
need the product to run on new
platforms,
⌧or, on new operating systems,
need the product to interface
with new hardware or software.
8
Perfective

Perfective maintenance:
to support new features
required by users.
to change some functionality
of the system due to customer
demands.

9
Maintenance Effort
Distribution

Perfective
Adaptive
Corrective

10
Causes for maintenance

During development:
Software not anticipated to last
very long (e.g., Y2K problem).

Rate of hardware obsolescence:
immortality of software products
maintenance necessary for
software performing low-level
functions.
11
Causes for
maintenance

Users want existing software

to run on new platforms:
to run in new environments,
and/or with enhanced features.

12
Causes for
maintenance

Whenever other software it
works with change:
maintenance is needed to cope
up with the newer interface.
For instance, a software product
may need maintenance when the
operating system changes.

13
Software evolution

Every software product continues
to evolve after its development:
through maintenance efforts.

Larger software products stay in
operation for longer time:
because of high replacement
cost.

14
Laws of Maintenance

There will always be a lot

of old software needing
maintenance.

Good products are
maintained, bad products
are thrown away.
15
Laws of Maintenance

Lehman’s first Law:

“Software products must
change continuously, or
become progressively less
useful.”

16
Laws of Maintenance

Lehman’s Second Law

“When software is maintained,
its structure degrades,
unless active efforts are
made to avoid this
phenomenon.”

17
Laws of Maintenance

Lehman’s Third Law:

“Over a program’s life
time,
its rate of development is
approximately constant.”

18
Other Laws of
Maintenance

All large programs will
undergo significant changes
during operation phase of
their life cycle,
regardless of apriori
intentions.

19
Legacy code--- Major
maintenance problems

Unstructured code (bad programs)

Maintenance programmers have:
insufficient knowledge of the system
or the application domain.
Software maintenance has a bad
image.

Documentation absent, out of date,
or insufficient.
20
Insufficient knowledge

Maintenance team is usually
different from development
team.
even after reading all documents
⌧it is very difficult to understand
why a thing was done in a certain
way.
Also there is a limit to the rate at
which a person can study
documents
⌧and extract relevant information
21
Bad image of
maintenance?

Maintainers are skilled not only in
writing code:
proficient in understanding others’
code
detecting problems, modifying the
design, code, and documentation
working with end-users

22
Maintenance
Nightmares

Use of gotos

Lengthy procedures

Poor and inconsistent naming

Poor module structure

Weak cohesion and high coupling

Deeply nested conditional statements

Functions having side effects

23
How to do better
maintenance?

Program understanding

Reverse engineering

Design recovery

Reengineering

Maintenance process models

24
Maintenance activities

Two types of activities:
Productive activities:
⌧ modification of analysis, design,
coding, etc.
Non-productive activities:
⌧understanding system design,
code, etc.

25
Software Reverse
Engineering

By analyzing a program

code, recover from it:
the design and the
requirements specification.

26
Software Reverse
Engineering

Reverse engineering is an important
maintenance technique:
several existing software
products are unstructured,
lack proper documentation,
were not developed using
software engineering principles.

27
Software Reverse
Engineering

First carry out cosmetic
changes to the code to
improve:
readability,
structure,
understandability.

28
Cosmetic changes
Assign Meaningful
Reformat Program
Names

Simplify
Conditions

Simplify
Replace GOTOs
Processing

29
Cosmetic Changes

Reformat the program:
use any pretty printer program
layout the program neatly.

Give more meaningful names
to:
 Variables, data structures, and
functions.
30
Cosmetic Changes

Replace complex and nested
conditional expressions:
simpler conditional
statements
whenever appropriate use
case statements.
31
Software Reverse
Engineering

In order to extract the design:
fully understand the code.

Automatic tools can be used to
help derive:
data flow and control flow
diagrams from the code.

32
Software Reverse
Engineering

Extract structure chart:
module invocation sequence and data
interchange among modules.

Extract requirements specification:
after thoroughly understanding the
code.
design has been extracted.

33
Software Maintenance
Process Models

Maintenance activities are not unique:
depend on the extent of
modifications required,
also, depend on condition of the
product:
⌧how structured it is,
⌧how well documented it is, etc.

34
Software Maintenance Process
Model - 1

When the required changes are

small and simple:
the code can be directly modified
changes reflected in all relevant
documents.
more elaborate activities are required
when required changes are not trivial.

35
Software Maintenance Process
Model - 1

Gather Change Requirements

Analyze Change Requirements

Devise Code Change Strategies

Apply Code Change Strategies

Update Documents Integrate and Test

36
Software Maintenance Process
Model 1

Start by gathering change

requirements.

Analyze change
requirements
formulate strategies for code
change.

37
Software Maintenance Process
Model 1

Formulating strategies for code

change:
presence of few members of the
original development team
⌧helps in reducing cycle time,
⌧especially for unstructured and
inadequately documented code.

38
Software Maintenance Process
Model 1

Availability of a working old system

at the maintenance site:
greatly helps the maintenance team
provides a good insight into the
working of the old system
can compare the working of the
modified system with the old system.

39
Software Maintenance Process
Model 1

Debugging the system under

maintenance becomes easier:
program traces of both the
systems can be compared to
localize bugs.

40
Software Maintenance Process
Model -2

For complex maintenance

projects, software reengineering
needed:
a reverse engineering cycle
followed by a forward engineering
cycle.
with as much reuse as possible
from existing code and other
documents. 41
Maintenance Process
Model 2

Preferable when:
amount of rework is significant
software has poor structure.

Can be represented by a reverse
engineering cycle:
followed by a forward engineering
cycle.

42
Software reengineering

Many aging software products

belong to this category.

During the reverse engineering,
the old code is analyzed
(abstracted) to extract the module
specifications.

43
Software reengineering

The module specifications are analyzed
 to produce the design.

The design is analyzed (abstracted)
 to produce the original requirements
specification.

The change requests are then applied to
the requirements specification:
arrive at the new requirements
specification.
44
Software reengineering

Forward engineering is carried

out to produce the new code.

During design, module
specification, and coding:
substantial reuse is made from
the reverse engineered products.

45
Process model for Software
reengineering

Change Requirements

Requirements New Requirements

Specification Specification

Design Design

Code Code

46
Software reengineering

Advantages of
reengineering:
produces better design than
the original product,
produces required
documents,
often results in higher
efficiency. 47
Software reengineering

Efficiency improvements are

brought about by better design.
However, this approach is more
costly than the first approach.

An empirical study indicates:
process 1 is preferable when amount
of rework is no more than 15%.

48
Software reengineering

Reengineering is preferable when:

amount of rework is high,
product exhibits high failure rate.
product difficult to understand.

49
Change Control Process

50
Computer Aided Software
Engineering (CASE)

CASE tools help in

software development
and maintenance.

CASE is a much talked about
topic in software industries.

52
CASE and Its Scope

CASE tool is a generic term:
denotes any form of automated
support for software engineering.

In a more restrictive sense:
a CASE tool automates some
software development activity.

53
CASE and Its Scope

Some CASE tools assist in phase-
related tasks:
specification, structured analysis,
design, coding, testing, etc.

Other tools help non-phase
activities:
project management and
configuration management.

54
Objectives of CASE

To increase productivity

To help produce better quality
software at lower cost.

56
CASE Environment

Although individual CASE tools

are useful:
true power of a tool set can be
realized only when:
⌧all CASE tools are integrated
together.

57
CASE Environment

Tools covering different stages
of life cycle share information
(data):
they should integrate through
some central repository (store)
consistent view of development
information.

58
CASE Environment

The central repository is the
data dictionary:
contains definition of all
composite and elementary data
items.
through this repository all
CASE tools share information.
59
Programming Environment

A CASE environment helps:

automate step-by-step methodologies.

In contrast to CASE environment:
a programming environment
denotes tools supporting coding
phase alone.

60
Schematic representation of
architecture of CASE environment

Consistency
- Testing
checker

Project
Central Structured
Manageme
Repository Design
nt

Coding Structured
Support Configurati Analysis
Document on
Generation Manageme
nt

61
Benefits of CASE

A key benefit of using CASE
environment:
cost saving through all developmental
phases.

Studies carried out to measure the
impact of CASE usage:
cost saving between 30% to 40%.

63
Benefits of CASE

Use of CASE tools leads to
improvements in quality:
becomes easy to iterate through
different software development
phases.
chances of human error is reduced.
CASE tools help produce higher
quality and consistent documents.

64
Benefits of CASE

Data relating to a software
product are maintained in a
central repository:
redundancy in the stored data is
reduced.
chances of inconsistent
documentation is reduced.

65
Benefits of CASE

CASE tools lead to cost saving
in software maintenance effort:
traceability and consistency
checks,
systematic information capture
during various development
phases.

66
Software Project Planning
Software Project Planning
Software Project Planning
Software Project Planning
Software Project Planning
Software Project Planning
Software Project Planning
Software Project Planning
Software Project Planning
Software Project Planning
Software Project Planning
Software Project Planning
Software Project Planning
Software Project Planning
Software Project Planning
Software Project Planning
Software Project Planning
Software Project Planning
Software Project Planning
SCM
Software Risk Management
Software Risk Management
Software Risk Management
Software Risk Management
Software Risk Management
Software Version Control
Software Version Control
Resource Allocation Model