Unit 5

Software Maintenance:

Software maintenance is modification of a software product after delivery to correct faults, to

improve performance or other attributes or to adopt the product to a modified environment.

Aim of Software Maintenance

Software maintenance activity can have following different aims:

1. To enhance the software by changing its functions.

2. To adopt the software to cope with changes in the environment.
3. To correct errors.
4. To update the software in removing the future problems.

Necessity of Maintenance

Software maintenance is becoming an important activity of a large number of software

organizations. When the hardware platform is changed, and a software product performs
some low-level functions, maintenance is necessary. Also, whenever the support environment
of a software product changes, the software product requires rework to cope up with the
newer interface. For instance, a software product may need to be maintained when the
operating system changes. Thus, every software product continues to evolve after its
development through maintenance efforts. Therefore it can be stated that software
maintenance is needed to correct errors, enhance features, port the software to new platforms,
etc.

Types of Software Maintenance

There are basically three types of software maintenance. These are:

1. Corrective: Corrective maintenance of a software product is necessary to rectify the

bugs observed while the system is in use.
2. Adaptive: A software product might need maintenance when the customer need the
product to run on new platforms, on new operating systems, or when they need the
product with new hardware or software.
3. Perfective: A software product needs maintenance to support the new features that
users want it to support, to change different functionalities of the system according to
customer demands, or to enhance the performance of the system.
4. Preventive: It involves the activities to update the software in expectation of any
future problems.

Problems associated with software maintenance:

Software maintenance work typically is much more expensive than what it should be and
takes more time than required. In software organizations, maintenance work is mostly carried
out using ad-hoc techniques. The primary reason being that software maintenance is one of
the most neglected areas of software engineering. Even though software maintenance is fast
becoming an important area of work for many companies as the software products of yester
years age, still software maintenance is mostly being carried out as fire-fighting operations,
rather than through systematic and planned activities.

Software maintenance has a very poor image in industry. Therefore, an organization often
cannot employ bright engineers to carry out maintenance work. Even though maintenance
suffers from a poor image, the work involved is often more challenging than development
work. During maintenance it is necessary to thoroughly understand someone else’s work and
then carry out the required modifications and extensions.

Another problem associated with maintenance work is that the majority of software products
needing maintenance are legacy products. Before correcting or modifying a program, the
programmer must first understand it. The programmer also must understand the impact of the
intended change. Few problems are:

1. Often the program is written by another person or group of persons working over the
years in isolation from each other.
2. Often the program is changed by person who did not understand it clearly.
3. Systems are not designed for change. If there is hardly any scope for change,
maintenance will be very difficult.
4. Lack of traceability
5. Lack of code comment
6. Obsolete legacy systems

Solutions to Maintenance Problems

The possible solutions of maintenance problems are: budget and effort reallocation, complete
replacement of the existing system, and enhancement of existing systems.

Software Maintenance Cost:

It is well known that maintenance efforts require about 60% of the total life cycle cost for a
typical software product. However, maintenance costs vary widely from one application
domain to another. For embedded systems, the maintenance cost can be as much as 2 to 4
times the development cost.

Boehm [1981] proposed a formula for estimating maintenance costs as part of his COCOMO
cost estimation model. Boehm’s maintenance cost estimation is made in terms of a quantity
called the Annual Change Traffic (ACT). Boehm defined ACT as the fraction of a software
product’s source instructions which undergo change during a typical year either through
addition or deletion.
where, KLOCadded is the total kilo lines of source code added during maintenance.
KLOCdeleted is the total KLOC deleted during maintenance. Thus, the code that is changed,
should be counted in both the code added and the code deleted. The annual change traffic
(ACT) is multiplied with the total development cost to arrive at the maintenance cost:

maintenance cost = ACT × development cost.

Most maintenance cost estimation models, however, yield only approximate results because
they do not take into account several factors such as experience level of the engineers, and
familiarity of the engineers with the product, hardware requirements, software complexity,
etc.

Re-Engineering

Re-engineering is the process of modifying the internal mechanisms of a system or program

or data structures of a system or program without changing its functionality. Much of the
software we depend on today is on average 10 to 15 years old. Even when these programs
were created using the best design and coding techniques known at the time and most were
not], they were created when program size and storage space were principle concerns. They
were then migrated to new platforms, adjusted for changes in machine and operating system
technology and enhanced to meet new user needs—all without enough regard to overall
architecture. The result is the poorly designed structures, poor coding, poor logic, and poor
documentation of the software systems we are now called on to keep running.

So change is inevitable when computer based systems are built, therefore, we must develop
mechanisms for evaluating, controlling and making modifications. So to this we need to do
the maintenance that is re-engineering or predictive maintenance.

Benefits of Software Re-Engineering

Software re-engineering offers the following benefits:

1. Lower Cost: Many times re-engineering having the lower cost than new system
development.
2. Lower Risks: Software re-engineering is based on incremental improvement of
systems, rather than radical system replacement with reduce the risk of losing critical
software.
3. Better use of Existing staff

Software Reverse Engineering

Software reverse engineering is the process of recovering the design and the requirements
specification of a product from an analysis of its code. The purpose of reverse engineering is
to facilitate maintenance work by improving the understandability of a system and to produce
the necessary documents for a legacy system. Reverse engineering is becoming important,
since legacy software products lack proper documentation, and are highly unstructured. Even
well-designed products become legacy software as their structure degrades through a series of
maintenance efforts.

The first stage of reverse engineering usually focuses on carrying out cosmetic changes to the
code to improve its readability, structure, and understandability, without changing of its
functionalities. A process model for reverse engineering has been shown in fig. 14.1.

A program can be reformatted using any of the several available prettyprinter programs
which layout the program neatly. Many legacy software products with complex control
structure and unthoughtful variable names are difficult to comprehend. Assigning meaningful
variable names is important because meaningful variable names are the most helpful thing in
code documentation. All variables, data structures, and functions should be assigned
meaningful names wherever possible. Complex nested conditionals in the program can be
replaced by simpler conditional statements or whenever appropriate by case statements.

After the cosmetic changes have been carried out on a legacy software, the process of
extracting the code, design, and the requirements specification can begin. These activities are
schematically shown in fig. 14.2. In order to extract the design, a full understanding of the
code is needed. Some automatic tools can be used to derive the data flow and control flow
diagram from the code. The structure chart (module invocation sequence and data
interchange among modules) should also be extracted. The SRS document can be written
once the full code has been thoroughly understood and the design extracted.
What Steps can be applied to reverse engineering for an existing database structure?

The following steps may be used to define the existing data model to reengineering a new
database model:

1. Build an initial object model

2. Determine candidate keys
3. Refine the tentative classes
4. Define generalizations
5. Discover associations.

How do I understand the working of an existing user interfaces?

To fully understand an existing user interface, the structure and behavior of the interface must
be specified. Three basic questions that must be answered as reverse engineering of the UI:

1. What are the basic actions that the interface must process?
2. What is a compact description of the behavioral response of the system to these
actions?
3. What is meant by replacement or more precisely what concept of equivalence of
interfaces is relevant here?

Distinguish between Reverse, Forward and Re-Engineering:

Software reengineering is a two level process. It is comprised of

1. Reverse Engineering and

2. Forward Engineering

The first level of software reengineering processes is referred to as reverse engineering

because it generate the design and specification from the code so that we can modify or
enhance the legacy code. Reverse engineering should be realized as a preventive software
maintenance measure when the software documentation is not complete or no longer in
existence or available.

Re-engineering is not the same as reverse engineering but reverse engineering is part of it to
develop better understanding of a system.

The second level of software reengineering process is referred to as forward engineering. The
objective of forward engineering is to modify the software part of existing system until they
are really state if the art which includes functional software modifications.

Change Control

Change control involves procedures and tools to bring order to the change process. Larger
project have the change control board (CCB), whose responsibility is to review and approve
or disapprove the changes. To control the changes in software, we have a change control
process.

Change request is submitted and evaluated to assess technical merit, potential side effects,
overall impact on other configuration objects and system functions, and the projected cost of
the change. The results of the evaluation are presented as a change report, which is used by a
change control authority (CCA)—a person or group who makes a final decision on the status
and priority of the change. An engineering change order (ECO) is generated for each
approved change. The ECO describes the change to be made, the constraints that must be
respected, and the criteria for review and audit. The object to be changed is "checked out" of
the project database, the change is made, and appropriate SQA activities are applied. The
object is then "checked in" to the database and appropriate version control mechanisms
(Section 9.4) are used to create the next version of the software.

The "check-in" and "check-out" process implements two important elements of change
control—access control and synchronization control. Access control governs which software
engineers have the authority to access and modify a particular configuration object.
Synchronization control helps to ensure that parallel changes, performed by two different
people, don't overwrite one another. The change control process is illustrated schematically in
the figure are as follows:

Version Control:
Software Configuration Management

Configuration management is the art of identifying, organizing, and controlling modifications

to the software being built by a programming team. The goal is to maximize productivity by
minimizing mistakes. Software configuration management (SCM) is an umbrella activity that
is applied throughout the software process. Because change can occur at any time, SCM
activities are developed to (1) identify change, (2) control change, (3) ensure that change is
being properly implemented, and (4) report changes to others who may have an interest.

The output of the software process is information that may be divided into three broad
categories: (1) computer programs (both source level and executable forms); (2) documents
that describe the computer programs (targeted at both technical practitioners and users), and
(3) data (contained within the program or external to it). The items that comprise all
information produced as part of the software process are collectively called a software
configuration.

Software configuration management is a set of activities that have been developed to manage
change throughout the life cycle of computer software. SCM can be viewed as a software
quality assurance activity that is applied throughout the software process. We examine major
SCM tasks and important concepts that help us to manage change.

Baselines

The IEEE defines a baseline as: A specification or product that has been formally reviewed
and agreed upon, that thereafter serves as the basis for further development, and that can be
changed only through formal change control procedures.
In the context of software engineering, a baseline is a milestone in the development of
software that is marked by the delivery of one or more software configuration items and the
approval of these SCIs that is obtained through a formal technical review.

Software Configuration Items

We have already defined a software configuration item as information that is created as part
of the software engineering process. In the extreme, a SCI could be considered to be a single
section of a large specification or one test case in a large suite of tests. More realistically, an
SCI is a document, a entire suite of test cases, or a named program component.

SCIs are organized to form configuration objects that may be catalogued in the project
database with a single name. A configuration object has a name, attributes, and is
"connected" to other objects by relationships.

Version Control

Version control combines procedures and tools to manage different versions of configuration
objects that are created during the software process. One representation of the different
versions of a system is the evolution graph. Each node on the graph is an aggregate object,
that is, a complete version of the software. Each version of the software is a collection of
SCIs (source code, documents, data), and each version may be composed of different
variants.

CASE Computer Aided Software Engineering

CASE provides the software engineer with the ability to automate manual activities and to
improve engineering insight. Like computer-aided engineering and design tools that are used
by engineers in other disciplines, CASE tools help to ensure that quality is designed in before
the product is built.

Building Blocks for CASE

Computer aided software engineering can be as simple as a single tool that supports a specific
software engineering activity or as complex as a complete "environment" that encompasses
tools, a database, people, hardware, a network, operating systems, standards, and myriad
other components. The building blocks for CASE are illustrated in Figure.
The environment architecture, composed of the hardware platform and system support
(including networking software, database management, and object management services),
lays the ground work for CASE. But the CASE environment itself demands other building
blocks. A set of portability services provides a bridge between CASE tools and their
integration framework and the environment architecture. The integration framework is a
collection of specialized programs that enables individual CASE tools to communicate with
one another, to create a project database, and to exhibit the same look and feel to the end-user
(the software engineer). Portability services allow CASE tools and their integration
framework to migrate across different hardware platforms and operating systems without
significant adaptive maintenance.

However, most CASE tools in use today have not been constructed using all these building
blocks. In fact, some CASE tools remain "point solutions." That is, a tool is used to assist in a
particular software engineering activity (e.g., analysis modeling) but does not directly
communicate with other tools, is not tied into a project database, is not part of an integrated
CASE environment (ICASE). Although this situation is not ideal, a CASE tool can be used
quite effectively, even if it is a point solution. When individual tools provide facilities for
data exchange (most do), the integration level is improved slightly. Such tools produce output
in a standard format that should be compatible with other tools that can read the format.

Single-source integration occurs when a single CASE tools vendor integrates a number of
different tools and sells them as a package. Although this approach is quite effective, the
closed architecture of most single-source environments precludes easy addition of tools from
other vendors.

At the high end of the integration spectrum is the integrated project support environment
(IPSE). Standards for each of the building blocks described previously have been created.
CASE tool vendors use IPSE standards to build tools that will be compatible with the IPSE
and therefore compatible with one another.

CASE Tools

• Business process engineering tools.

• Process modeling and management tools.
 • Project planning tools.
• Risk analysis tools.
• Project management tools.
• Requirements tracing tools.
• Metrics and management tools.
• Documentation tools.
• System software tools.
• Quality assurance tools.
• Database management tools
• Software configuration management tools
• Analysis and design tools
• prototyping and simulation tools
• Interface design and development tools
• Prototyping tools
• Programming tools
• Web development tools
• Integration and testing tools
• Static analysis tools
• Dynamic analysis tools
• Test management tools
• Client/server testing tools
• Reengineering tools

Integrated CASE Environment