UNIT-5

INTRODUCTION
• Software maintenance is the last stage of s/w life
cycle .
• After the product has been released, the
maintenance phase keeps the s/w up to date with
environment changes & changing user
requirements.
• It consumes about 40-70% of the cost of the entire
life cycle.
• Maintenance can only happen efficiently if the
earlier phases are done properly.
 SOFTWARE MAINTENANCE
• Software Maintenance is a very broad activity that includes
error corrections, enhancements of capabilities, deletion of
obsolete capabilities, and optimization.

• As per IEEE, it is a modification of s/w product after delivery

to correct faults, to improve performance or other attributes
or to adapt the product to a modified environment.

• As per ISO, it is a set of activities performed when s/w

undergoes modifications to code & associated
documentation due to a problem or the need for
improvement or adaptation.
 NEED FOR MAINTENANCE
• Software Maintenance is needed for:-
– Correct errors.
– Change in user requirement with time.
– Changing hardware/software environment.
– To improve system efficiency
– To optimize the code to run faster
– To modify the components.
– To eliminate any unwanted side effects.
Thus, the maintenance is needed to ensure that the system continues to satisfy user
requirements
• AIM of Software Maintenance
-----------To correct errors.
-----------To enhance the s/w by changing its functions.
------------To update the s/w.
----------To adapt the s/w to cope with changes in the environment.
CATEGORIES OF SOFTWARE MAINTENANCE
• There are four types of software maintenance:

1. Corrective maintenance :
This refer to modifications initiated by defects in the software.

2. Adaptive maintenance:
It includes modifying the software to match changes in the ever changing environment.

3. Perfective maintenance:
It means improving processing efficiency or performance, or restructuring the software to
improve changeability. This may include enhancement of existing system functionality,
improvement in computational efficiency etc.
4. Preventive maintenance:
It is the process by which we prevent our system from being obsolete. It involves the
concept of reengineering & reverse engineering in which an old system with an old
technology is re-engineered using new technology. This maintenance prevents the system
from dying out.
SOFTWARE MAINTENANCE

Fig: Distribution of maintenance effort

The Maintenance Process
• Program Understanding
The first phase consists of analyzing the program in
order to understand.

• Generating Particular Maintenance Proposal

The second phase consists of generating a particular
maintenance proposal to accomplish the
implementation of the maintenance objective.

• Ripple Effect
The third phase consists of accounting for all of the
ripple effect as a consequence of program modifications.
• Modified Program Testing
The fourth phase consists of testing the modified program to ensure that
the modified program has at least the same reliability level as before.

• Maintainability
Each of these four phases and their associated software quality
attributes are critical to the maintenance process. All of these factors
must be combined to form maintainability.
How easy is to maintain a program depends on how easy is to
understand it.
COST OF MAINTENANCE
• To estimate maintenance cost, two models have been proposed. They
are:
1. Belady and Lehman model
2. Boehm model
 Belady and Lehman Model

This model indicates that the effort and cost can increase
exponentially if poor Software development approach is used &
the person or group that used the approach is no longer available
to perform maintenance. The basic equation is given by:

Where,
M : Total effort expended
P : Productive effort that involves analysis, design, coding, testing and
evaluation.
K : An empirically determined constant.
c : Complexity measure due to lack of good design and documentation.
d : Degree to which maintenance team is familiar with the software.
Example
Solution
Boehm Model
 Introduction to Re-engineering
• Re-engineering means to re-implement
systems to make more maintainable.
• In this, the functionality & architecture of the
system remains the same but it includes
redocumenting, organizing, modifying &
updating the system.
• When re-engineering principles are applied to
business process then it is called Business
Process Reengineering (BPR).
 Steps in Re-engineering
• The steps involved in re-engineering are-
– Goal setting
– Critical analysis of existing scenario such as process, task, design,
methods etc.
– Identifying the problems & solving them by new innovative thinking.

In other words, it uses new technology to gain a significant

breakthrough improvement.
 Advantages of Re-engineering
--------Lower costs
--------Lower risks
--------Better use of existing staff
--------Incremental development
 Software RE-Engineering
• The principles of re-engineering when applied to s/w
development processes , it is called s/w reengineering.
• Acc to IBM user group guide, “the process of modifying
the internal mechanism of a system or program or the
data structures of a system or program without changing
its functionality”. Software re-engineering is concerned
with taking existing legacy systems and re-implementing
them to make them more maintainable.
• The critical distinction between re-engineering and new
software development is the starting point for the
development as shown in Fig
 Disadvantages of Re-engineering
• Major architectural changes or radical
reorganizing of the system data management
has to be done manually.
• Re-engineered system is not likely to be as
maintainable as a new system developed
using modern s/w engineering methods.
 Reverse Engineering
• Reverse engineering is the process followed in
order to find difficult,
unknown and hidden
information about a
software system.
The reverse engineering process is shown in fig. The
process starts with an analysis phase. During this
phase, the system is analyzed using automated tools
to discover its structure. They add information to this,
which they have collected by understanding the
system. This information is maintained as a directed
graph that is linked to the program source code.

Information store browsers are used to compare the

graph structure & the code & to annotate the graph
with extra information. Documents of various types
such as program & data structure diagrams &
traceability matrices. Traceability matrices show where
entities in the system are defined and referenced.
 Reverse Engineering tasks
Reverse Engineering encompasses a wide array of tasks related to
understanding and modifying software system. This array of tasks can be
broken into a number of classes. Few of these are discussed below:

1. Mapping between application and program domains

2.Mapping between concrete and abstract levels

3. Rediscovering high level structures
4. Finding missing links between program syntax and semantics
5. To extract reusable component
 Levels of Reverse Engineering
• Reverse Engineers detect low level
implementation constructs and replace them
with their high level counterparts.
• The process eventually results in an
incremental formation of an overall
architecture of the program.
Fig: Levels of abstraction
Advantages of Reverse Engineering
• It concentrates on recovering the lost
information from the programs
• It provides the abstract information from the
detailed source code implementation.
• It improves system documentation that is
either incomplete or out of date.
• It detects the adverse effects of modification
in the s/w system.
 Difference between Reverse, Forward &
Reengineering
• Reverse Engineering
It performs transformation from a large abstraction
level to a higher one.
• Forward Engineering
It performs transformation from a higher abstraction
level to a lower one.
• Reengineering
It transforms an existing s/w system into a new but
more maintainable system.
The Constructive Cost Model (COCOMO)

It is a hierarchy of software costs estimation models, which include basic, intermediate &
detailed sub models.
 BASIC MODEL

It aims at estimating small

to medium sized software
projects.

Three modes of
development are
considered in this model:
organic, semidetached and
embedded.
Comparison of three COCOMO models
 Basic model
• Basic COCOMO model takes the form –

where E is effort applied in Person-Months

and D is the development time in months and
the coefficients ab, bb, cb, db are given in table.
Basic COCOMO Coefficients
Example
Example
 Intermediate Model
• The basic model allowed for a quick and rough
estimate, but it resulted in a lack of accuracy.

• Boehm introduced an additional set of 15 predictors

called cost drivers in the intermediate model to take
account of the software development environment.

• Cost drivers are used to adjust the nominal cost of a

project to the actual project environment, hence
increasing the accuracy of the estimate.
The multiplying factors for all 15 cost drivers are multiplied to get
the effort adjustment factor(EAF).
 Detailed COCOMO Model
• It offers a means for processing all the project characteristics to
construct a s/w estimate. The detailed model introduces two more
capabilities:

– Phase sensitive effort multiplier: Some phases are more

affected than others by factors defined by the cost drivers. The
detailed model provides a set of phase sensitive effort multipliers
for each cost driver. This helps in determining the manpower
allocation for each phase of the project.

– Three-level product hierarchy: Three product levels are

defined. These are module, subsystem and system levels.
The ratings of the cost drivers are done at appropriate level, i.e
the level at which it is most susceptible to variation.
 CONFIGURATION MANAGEMENT
ACTIVITIES

• The software may be considered as configurations of software

components. These software components are released in the
form of executable code whereas supplier company keeps the
source code. This source code is the representation of an
executable equivalent.

• Source code can be modified without any effect upon

executable versions in use. If strict controls are not kept, the
source code which is the exact representation of a particular
executable version may no longer exist.

• The means by which the process of software development and

maintenance is controlled is called configuration management.
Functions of SCM
• Identification
• Change Control
• Status Accounting
• Auditing

Goals of SCM are-

– SCM activities are planned.
– Changes to identified software work products are controlled.
– Affected groups & individuals are informed of the status and content
of s/w baselines.
– Selected s/w work products are identified, controlled and available.
• Identification -identifies those items whose configuration needs to be
controlled, usually consisting of hardware, software, and documentation.

• Change Control - establishes procedures for proposing or requesting

changes, evaluating those changes for desirability, obtaining authorization
for changes, publishing and tracking changes, and implementing changes.
This function also identifies the people and organizations who have
authority to make changes at various levels.

• Status Accounting -is the documentation function of CM. Its primary

purpose is to maintain formal records of established configurations and
make regular reports of configuration status. These records should
accurately describe the product, and are used to verify the configuration
of the system for testing, delivery, and other activities.

• Auditing -Effective CM requires regular evaluation of the configuration. This

is done through the auditing function, where the physical and functional
configurations are compared to the documented configuration. The
purpose of auditing is to maintain the integrity of the baseline and release
configurations for all controlled products
 Following documents are required -
• Project plan
• SRS document
• Software design description document
• Source code listing
• Test plans/ procedures/ test cases.
• User manuals
 Change Control Process
• Change control involves procedures and tools to bring order in the change process.
Larger projects have a formal change control board (CCB), whose responsibility is to
review and approve or disapprove change.

– It is the CCB responsibility to provide the mechanism to maintain orderly change processes.
For a large software engineering project, uncontrolled change rapidly leads to chaos. For such
projects, change control combines human procedures & automated tools to provide a
mechanism for the control of change. Offer a mechanism for accepting changes that enhance
the product while rejecting those that degrade it.
– Offer revision control & backup safety for work products during their formative
development.
– Facilitate changes to work products during their initial formative development while avoiding
unnecessary overhead or formality.
– Permit for formal acceptance of work products after their initial formative development has
been finished.
– Permit all parties materially affected by proposed changes to accepted work products to
assess the resource, schedule or product impact of the changes.
 Software Version Control
• During software maintenance at least two
versions of the software system are produced ,
one being the old version and the other one
or more new versions.
• As a s/w system comprises of s/w components,
there will also be two or more versions of each
component that has been changed. Thus, the
software maintenance team has to cope with
multiple versions of the software
• A version control tool is the first stage towards being able to manage multiple versions.
Once, it is in place, a detailed record of every version of the software must be kept.
This comprises the-
– Name of each source code component, including the variations and revisions
– The versions of the various compilers and linkers used
– The name of the software staff who constructed the component
– The date and the time at which it was constructed

• A version control system is a repository of files . Every change made to the source is
tracked, along with who made the change, why they made it and references to
problems fixed or enhancements introduced, by the change.

• User’s may wish to compare today’s version of some s/w with yesterday’s version or last
year’s version. Since version control system keep track of every version of the s/w, this
becomes a straightforward task. Version control activity is divided in four sub-activities:
1. Identifying new versions
2. Numbering scheme : It will have the following format
Version X.Y.Z…
3. Visibility
4. Tracking
1. Identifying new versions: A s/w configuration item (SCI) will get a new version no.
when there has been a change to its established baseline. Each previous version
will be stored in a corresponding directory like version 0, version1, version2 etc.

2. Numbering scheme: It will have the following format

Version X.Y.Z…

• (X) denotes the entire SCI. Therefore, changes made to the entire configuration
item, or changes large enough to warrant a completely new release of the item,
will cause the first digit to increase.
• (Y) denotes the component of SCI. this digit will sequentially increase if a change is
made to a component or multiple components.
• (Z) denotes the section of the component of a SCI. This no. will only be visible if a
component of an SCI can be divided into individual sections. Changes made at this
level of detail will need a sequential change of third digit.

3. Visibility: the version no. can be seen either in frame or below the title.

4. Tracking : the best way to keep track of the different versions is with a version
evolution graph.
 CASE Tools
• CASE stands for Computer Aided Software Engineering. It means, development and
maintenance of software projects with help of various automated software tools.
• Computer aided software engineering tool assist software engineering managers &
practitioners in every activity associated with the software process.

• Thus, a CASE tool means any tool used to automate some activity associated with software
development. Many CASE tools are available. Some of these CASE tools assist in phase
related tasks such as specification, structure analysis, design, coding, testing etc; and others
to non-phase activities such as project management and configuration management.
• CASE tools are software programs that are designed to assist human programmers with the
complexity of the processes & the artifacts of software engineering.
• As we know, software engineering is a systematic approach to the development, operations,
maintenance & retirement of software.
• The major limitations of using CASE tools are:
– Cost
– Learning Curve
– Tool mix
• Software engineering mainly includes the following processes, which may be aided by CASE:-
– Translation of user needs into software requirements.
– Transformation of software requirements into design specifications.
– Implementation of design into code.
– Testing of the code for the operational use.
Documentation. A CASE tool must have the following characteristics in order to be used
efficiently:
Characteristics:

• A standard methodology

• Flexibility

• Strong Integration

• Integration with testing software

• Support for reverse engineering

• On-line help
• A standard methodology: A CASE tool must support a standard software
development methodology and standard modeling techniques. In the present
scenario most of the CASE tools are moving towards UML.

• Flexibility: Flexibility in use of editors and other tools. The CASE tool must offer
flexibility and the choice for the user of editors' development environments.

• Strong Integration: The CASE tools should be integrated to support all the
stages. This implies that if a change is made at any stage, for example, in the
model, it should get reflected in the code documentation and all related design
and other documents, thus providing a cohesive environment for software
development.

• Integration with testing software: The CASE tools must provide interfaces for
automatic testing tools that take care of regression and other kinds of testing
software under the changing requirements.

• Support for reverse engineering: A CASE tools must be able to generate

complex models from already generated code.
 Categories of CASE Tools:

• Sometimes CASE tools are classified in to following categories due

to their activities:
– UPPER CASE Tools
– LOWER CASE Tools
– INTEGRATED CASE Tools

Upper CASE tools: They support the analysis and the design
phase. They include tools for analysis modeling, reports and forms
generation.

Lower CASE tools: They support the coding phase, configuration

management, etc.

Integrated CASE tools: It is known as I-CASE and also supports

analysis, design and coding phases.
Positioning of CASE tools in a Software Application development:
CASE Environment
• Although individual CASE tools are useful, the true power of a
tool set can be realized only when these set of tools are
integrated into a common framework or environment. CASE
tools are characterized by the stage or stages of software
development life cycle on which they focus. Since different tools
covering different stages share common information, it is
required that they integrate through some central repository to
have a consistent view of information associated with the
software development artifacts. This central repository is
usually a data dictionary containing the definition of all
composite and elementary data items. Through the central
repository all the CASE tools in a CASE environment share
common information among themselves. Thus a CASE
environment facilities the automation of the step-by-step
methodologies for software development. A schematic
representation of a CASE environment is shown in fig.
Advantages and Disadvantages of CASE
Tools:
Software Risk Management
Risk :
“Risk is a problem that may cause some loss or
threaten the success of the project, but which
has not happened yet”.
Types of Risks
---Development Process Risks
– are development errors, natural disasters,
disgruntled (dissatisfied) employees and poor
management objectives.
--Product Risks
– Includes Project risks, Technical risks, Business risks
• Risk Identification
With the identification phase, several activities occur. The main activities
are:
– Identify risks
– Define risk attributes
– Documentation
– Communicate

• Risk Analysis
The main activities in this phase are –
– Group similar risks
– Determine risk drivers
– Determine source of risks
– Estimate risk exposure
– Evaluate against criteria
• Risk Planning
– Risk avoidance
– Risk minimization
– Risk Contingency Plans
END OF UNIT-5

****All the Best****