SEN 401 SOFTWARE MAINTENANCE

Introduction

After completing the hectic and time consuming process of developing and testing a software
application, taking measures to ensure its maintenance is quite sensible and important. Nowadays,
software maintenance is widely accepted as part of Software Development Life Cycle (SDLC). It
is the process of modifying and updating software application after its delivery to improve its
performance, correct any new defects and adapt the product according to the modified
environment. The purpose of software maintenance is to preserve the value of software over time
which can be accomplished by:

• Expanding the customer base.

• Enhancing software’s capabilities.

• Omitting obsolete capabilities.

• Employing newer technology

Software Maintenance is a very broad activity that occurs soon after the development is completed.
It optimizes system performance by reducing errors, eliminating unnecessary development and
applying innovations; it is the process of modifying a software product after it has been delivered
to the customer. The main purpose of software maintenance is to modify and update software
applications after delivery to correct faults and to improve performance.

Software maintenance is a part of the Software Development Life Cycle whose purpose is to
modify and continuously update software applications to eliminate all possible errors,
malfunctions, to improve work efficiency and better system performance. Its primary goal is to
modify and update software application after delivery to correct errors and to improve
performance. Software is a model of the real world. When the real world changes, the software
require alteration wherever possible.

Software maintenance is the process of changing, modifying, and updating software to keep up
with customer needs. Software maintenance is done after the product has been launched for several
reasons including improving the software overall, correcting issues or bugs, to boost performance,
and more.

Software Maintenance is an inclusive activity that includes error corrections, enhancement of

capabilities, deletion of obsolete capabilities, and optimization. Software maintenance includes
optimization of software performance by applying advanced development, reducing errors, and
eliminating useless development. Solution development can take about 2 years to build a system,
while software maintenance management is an ongoing activity
The Institute of Electrical and Electronics Engineers (IEEE) describes software maintenance as
the modification of software after delivery to the user. The reasons for these changes include
correcting faults, improving performance, and adapting the software to changes in requirements.

In software engineering, software maintenance is the process of enhancing and optimizing

deployed software (software release), as well as remedying defects. Software maintenance is one
of the phases in the software development process, and follows deployment of the software into
the field. The software maintenance phase involves changes to the software in order to correct
defects and deficiencies found during field usage as well as the addition of new functionality to
improve the software's usability and applicability.

Software maintenance involves a number of specific techniques. One technique is static slicing,
which is used to identify all the program code that can modify some variable. It is generally useful
in refactoring program code and was specifically useful in assuring Y2K compliance.

The software maintenance phase is an explicit part of the waterfall model of the software
development process which was developed during the structured programming movement of
computer programming. The other major model, the spiral model developed during the object
oriented movement of software engineering makes no explicit mention of a maintenance phase.
Nevertheless, this activity is notable, considering the fact that two-thirds of a software system's
lifetime cost involves maintenance.

In a formal software development environment, the developing organization or team will have
some mechanisms to document and track defects and deficiencies. Software just like most other
products, is typically released with a known set of defects and deficiencies. The software is
released with the issues because the development organization decides the utility and value of the
software at a particular level of quality outweighs the impact of the known defects and deficiencies.
The known issues are normally documented in a letter of operational considerations or release
notes so that the users of the software will be able to work around the known issues and will know
when the use of the software would be inappropriate for particular tasks.

With the release of the software, other, undocumented defects and deficiencies will be discovered
by the users of the software. As these issues are reported into the development organization, they
will be entered into the defect tracking system.

The people involved in the software maintenance phase are expected to work on these known
issues, address them, and prepare for a new release of the software, known as a maintenance
release, which will address the documented issues.

Software Maintenance Fundamentals

This section introduces the concepts and terminology that form an underlying basis to
understanding the role and scope of software maintenance. The topics provide definitions and
emphasize why there is a need for maintenance. Categories of software maintenance are critical to
understanding its underlying meaning.

Definitions and Terminology

Software maintenance is defined as the modification of a software product after delivery to correct
faults, to improve performance or other attributes, or to adapt the product to a modified
environment. The standard also addresses maintenance activities prior to delivery of the software
product, but only in an information appendix of the standard.

The IEEE/EIA 12207 standard for software life cycle processes essentially depicts maintenance as
one of the primary life cycle processes, and describes maintenance as the process of a software
product undergoing “modification to code and associated documentation due to a problem or the
need for improvement. The objective is to modify the existing software product while preserving
its integrity”.

Nature of Maintenance

Software maintenance sustains the software product throughout its operational life cycle.
Modification requests are logged and tracked, the impact of proposed changes is determined, code
and other software artifacts are modified, testing is conducted, and a new version of the software
product is released. Also, training and daily support are provided to users. Pfleeger states that
“maintenance has a broader scope, with more to track and control” than development.

A maintainer is defined by IEEE/EIA 12207 as an organization which performs maintenance

activities, sometimes refer to individuals who perform those activities, contrasting them with the
developers.
IEEE/EIA 12207 identifies the primary activities of software maintenance as: process
implementation; problem and modification analysis; modification implementation; maintenance
review/acceptance; migration; and retirement.

Maintainers can learn from the developer’s knowledge of the software. Contact with the
developers and early involvement by the maintainer helps reduce the maintenance effort. In some
instances, the software engineer cannot be reached or has moved on to other tasks, which creates
an additional challenge for the maintainers. Maintenance must take the products of the
development, code, or documentation, for example, and support them immediately and
evolve/maintain them progressively over the software life cycle.

Need for Maintenance

The need for Software Maintenance

Software maintenance is needed for several reasons which are listed below:

 Correction of errors: The most important part of the service is the correction of errors or
in other words 'bugs'. It is very important that the software works without problems. We
recommend setting this task as a priority. This process contains the search for errors in the
code and their correction. Problems can occur in hardware, operating systems, or any piece
of software. This should be done without prejudice to the remaining functions of the
existing software.
 Improving opportunities for a changing environment: This part of the service is
important for improving the current functions and for making the system compatible for
changing the environment. It extends the capabilities of programs, work patterns, hardware
upgrades, compilers, and all other aspects that affect the workflow of the system. Increase
system performance by using a technically updated solution and regularly using software
maintenance services.
 Remove obsolete functions: Functionalities that are no longer used and unnecessarily
occupy the space in the solution actually reduce the efficiency of the system. Therefore,
the removal of obsolete functions is necessary. These user interface and coding elements
are removed and replaced with new functions using the latest tools and technologies. This
change makes the system adaptive to cope with changing circumstances.
 Performance improvement: Improving system performance in order to meet new
requirements. Data and encoding constraints as well as reengineering are part of software
maintenance. This prevents the solution from being vulnerable. This is not any
functionality that works in operations, but it evolves to stop harmful actions, such as
hacking. Others are:
 Adapt programs so that different hardware, software, system features, and
telecommunications facilities can be used

 Changing hardware/software requirements

 To improve system efficiency
 To optimize the code to run faster
 To modify the components
  To reduce any unwanted side effects
 Implement enhancement

Maintenance is needed to ensure that the software continues to satisfy user requirements.
Maintenance is applicable to software developed using any software life cycle model (for example,
spiral). The system changes due to corrective and non-corrective software actions.

The maintainer’s activities comprise four key characteristics, according to Pfleeger:

 Maintaining control over the software’s day-to-day functions

 Maintaining control over software modification
 Perfecting existing functions
 Preventing software performance from degrading to unacceptable levels

Majority of Maintenance Costs

Maintenance consumes a major share of software life cycle financial resources. A common
perception of software maintenance is that it merely fixes faults. However, studies and surveys
over the years have indicated that the majority, over 80%, of the software maintenance effort is
used for non-corrective actions. Understanding the categories of software maintenance helps to
understand the structure of software maintenance costs. Also, understanding the factors that
influence the maintainability of a system can help to contain costs. Pfleeger presents some of the
technical and non-technical factors affecting software maintenance costs, as follows:

 Application type
 Software novelty
 Software maintenance staff availability
 Software life span
 Hardware characteristics
 Quality of software design, construction, documentation and testing

Evolution of Software

Lehman first addressed software maintenance and evolution of systems in 1969. Over a period of
twenty years, his research led to the formulation of eight “Laws of Evolution”. Key findings
include the fact that maintenance is evolutionary developments, and that maintenance decisions
are aided by understanding what happens to systems (and software) over time. Others state that
maintenance is continued development, except that there is an extra input (or constraint)–existing
large software is never complete and continues to evolve. As it evolves, it grows more complex
unless some action is taken to reduce this complexity.

Since software demonstrates regular behavior and trends, these can be measured. Attempts to
develop predictive models to estimate maintenance effort have been made, and, as a result, useful
management tools have been developed.
Categories of Maintenance

Maintenance consists of four parts:

 Corrective maintenance: Reactive modification of a software product performed after

delivery to correct discovered problems. It deals with fixing bugs in the code. Detection of
errors and mistakes in the existing solution and their correction to ensure the effective
operation of the system. Corrective software maintenance is what one would typically
associate with the maintenance of any kind. Correct software maintenance addresses the
errors and faults within software applications that could impact various parts of your
software, including the design, logic, and code. These corrections usually come from bug
reports that were created by users or customers – but corrective software maintenance can
help to spot them before your customers do, which can help your brand’s reputation.

 Adaptive maintenance: Modification of a software product performed after delivery to keep

a software product usable in a changed or changing environment. It deals with adapting the
software to new environments. Modifying the software to match changes in the ever-
changing environment. Some changes are made to the system to ensure its compatibility
with changing environments. Adaptive software maintenance becomes important when the
environment of your software changes. This can be brought on by changes to the operating
system, hardware, software dependencies, Cloud storage, or even changes within the
operating system. Sometimes, adaptive software maintenance reflects organizational
policies or rules as well. Updating services, making modifications to vendors, or changing
payment processors can all necessitate adaptive software maintenance
 Perfective maintenance: Modification of a software product after delivery to improve
performance or maintainability. It deals with updating the software according to changes
in user requirements. Checks on the fine-tuning of all elements of the system, the
functionality and capabilities to improve system performance. Perfective software
maintenance focuses on the evolution of requirements and features that existing in your
system, enhancement of existing system functionality, improvement in computational
efficiency, etc. As users interact with your applications, they may notice things that you
did not or suggest new features that they would like as part of the software, which could
become future projects or enhancements. Perfective software maintenance takes over some
of the work, both adding features that can enhance user experience and removing features
that are not effective and functional. This can include features that are not used or those
that do not help you to meet your end goals.

 Preventive maintenance: Modification of a software product after delivery to detect and

correct latent faults in the software product before they become effective faults. It deals
with updating documentation and making the software more maintainable. Helps prevent
potential system vulnerabilities. Preventative Software maintenance helps to make changes
and adaptations to your software so that it can work for a longer period of time. The focus
 of the type of maintenance is to prevent the deterioration of your software as it continues
to adapt and change. These services can include optimizing code and updating
documentation as needed. Preventative software maintenance helps to reduce the risk
associated with operating software for a long time, helping it to become more stable,
understandable, and maintainable.

All changes to the system can be characterized by these four types of maintenance. Corrective
maintenance is ‘traditional maintenance’ while the other types are considered as ‘software
evolution’.

Key Issues in Software Maintenance

A number of key issues must be dealt with to ensure the effective maintenance of software. It is
important to understand that software maintenance provides unique technical and management
challenges for software engineers. Trying to find a fault in software containing 500K lines of code
that the software engineer did not develop is a good example. Similarly, competing with software
developers for resources is a constant battle. Planning for a future release, while coding the next
release and sending out emergency patches for the current release, also creates a challenge. The
following section presents some of the technical and management issues related to software
maintenance. They have been grouped under the following topic headings:

 Technical issues
 Management issues
 Cost estimation and Measures

Technical Issues
Limited understanding

Limited understanding refers to how quickly a software engineer can understand where to make a
change or a correction in software which this individual did not develop. Research indicates that
some 40% to 60% of the maintenance effort is devoted to understanding the software to be
modified. Thus, the topic of software comprehension is of great interest to software engineers.
Comprehension is more difficult in text-oriented representation, in source code, for example,
where it is often difficult to trace the evolution of software through its releases/versions if changes
are not documented and when the developers are not available to explain it, which is often the
case. Thus, software engineers may initially have a limited understanding of the software, and
much has to be done to remedy this.

Testing

The cost of repeating full testing on a major piece of software can be significant in terms of time
and money. Regression testing, the selective retesting of a software or component to verify that
the modifications have not caused unintended effects, is important to maintenance. As well,
finding time to test is often difficult. There is also the challenge of coordinating tests when different
members of the maintenance team are working on different problems at the same time. When
software performs critical functions, it may be impossible to bring it offline to test.
Impact analysis

Impact analysis describes how to conduct, cost effectively, a complete analysis of the impact of a
change in existing software. Maintainers must possess an intimate knowledge of the software’s
structure and content. They use that knowledge to perform impact analysis, which identifies all
systems and software products affected by a software change request and develops an estimate of
the resources needed to accomplish the change. Additionally, the risk of making the change is
determined. The change request, sometimes called a modification request (MR) and often called a
problem report (PR), must first be analyzed and translated into software terms. It is performed
after a change request enters the software configuration management process. Arthur states that
the objectives of impact analysis are:

 Determination of the scope of a change in order to plan and implement work

 Development of accurate estimates of resources needed to perform the work
 Analysis of the cost/benefits of the requested change
 Communication to others of the complexity of a given change

The severity of a problem is often used to decide how and when a problem will be fixed. The
software engineer then identifies the affected components. Several potential solutions are provided
and then a recommendation is made as to the best course of action.

Software designed with maintainability in mind greatly facilitates impact analysis.

Maintainability

How does one promote and follow up on maintainability issues during development? The IEEE
[IEEE610.12-90] defines maintainability as the ease with which software can be maintained,
enhanced, adapted, or corrected to satisfy specified requirements. ISO/IEC defines maintainability
as one of the quality characteristics (ISO9126-01).

Maintainability sub-characteristics must be specified, reviewed, and controlled during the software
development activities in order to reduce maintenance costs. If this is done successfully, the
maintainability of the software will improve. This is often difficult to achieve because the
maintainability sub-characteristics are not an important focus during the software development
process. The developers are preoccupied with many other things and often disregard the
maintainer’s requirements. This in turn can, and often does, result in a lack of system
documentation, which is a leading cause of difficulties in program comprehension and impact
analysis. It has also been observed that the presence of systematic and mature processes,
techniques, and tools helps to enhance the maintainability of a system.

Management Issues
Alignment with organizational objectives

Organizational objectives describe how to demonstrate the return on investment of software

maintenance activities. Bennett states that “initial software development is usually project-based,
with a defined time scale and budget. The main emphasis is to deliver on time and within budget
to meet user needs. In contrast, software maintenance often has the objective of extending the life
of software for as long as possible. In addition, it may be driven by the need to meet user demand
for software updates and enhancements. In both cases, the return on investment is much less clear,
so that the view at senior management level is often of a major activity consuming significant
resources with no clear quantifiable benefit for the organization.”

Staffing

Staffing refers to how to attract and keep software maintenance staff. Maintenance is often not
viewed as glamorous work. Deklava provides a list of staffing-related problems based on survey
data. As a result, software maintenance personnel are frequently viewed as “second-class citizens”
and morale therefore suffers.

Process

Software process is a set of activities, methods, practices, and transformations which people use
to develop and maintain software and the associated products. At the process level, software
maintenance activities share much in common with software development (for example, software
configuration management is a crucial activity in both). Maintenance also requires several
activities which are not found in software development. These activities present challenges to
management.

Organizational aspects of maintenance

Organizational aspects describe how to identify which organization and/or function will be
responsible for the maintenance of software. The team that develops the software is not necessarily
assigned to maintain the software once it is operational.

In deciding where the software maintenance function will be located, software engineering
organizations may, for example, stay with the original developer or go to a separate team (or
maintainer). Often, the maintainer option is chosen to ensure that the software runs properly and
evolves to satisfy changing user needs. Since there are many pros and cons to each of these options,
the decision should be made on a case-by-case basis. What is important is the delegation or
assignment of the maintenance responsibility to a single group or person, regardless of the
organization’s structure.

Outsourcing

Outsourcing of maintenance is becoming a major industry. Large corporations are outsourcing

entire portfolios of software systems, including software maintenance. More often, the outsourcing
option is selected for less mission-critical software, as companies are unwilling to lose control of
the software used in their core business. Carey reports that some will outsource only if they can
find ways of maintaining strategic control. However, control measures are hard to find. One of the
major challenges for the outsourcers is to determine the scope of the maintenance services required
and the contractual details. McCracken states that 50% of outsourcers provide services without
any clear service-level agreement. Outsourcing companies typically spend a number of months
assessing the software before they will enter into a contractual relationship. Another challenge
identified is the transition of the software to the outsourcer.

Software Maintenance Cost Factors

There are two types of cost factors involved in software maintenance.

These are

 Non-Technical Factors
 Technical Factors

Non-Technical Factors

1. Application Domain

 If the application of the program is defined and well understood, the system requirements
may be definitive and maintenance due to changing needs minimized.
 If the form is entirely new, it is likely that the initial conditions will be modified frequently,
as user gain experience with the system.

2. Staff Stability

 It is simple for the original writer of a program to understand and change an application rather than
some other person who must understand the program by the study of the reports and code listing.
 If the implementation of a system also maintains that systems, maintenance costs will reduce.
 In practice, the feature of the programming profession is such that persons change jobs regularly.
It is unusual for one user to develop and maintain an application throughout its useful life.

3. Program Lifetime

 Programs become obsolete when the program becomes obsolete, or their original hardware is
replaced, and conversion costs exceed rewriting costs.

4. Dependence on External Environment

 If an application is dependent on its external environment, it must be modified as the climate

changes.
 For example:
 Changes in a taxation system might need payroll, accounting, and stock control programs to be
modified.
 Taxation changes are nearly frequent, and maintenance costs for these programs are associated with
the frequency of these changes.
 A program used in mathematical applications does not typically depend on humans changing the
assumptions on which the program is based.

5. Hardware Stability
  If an application is designed to operate on a specific hardware configuration and that configuration
does not changes during the program's lifetime, no maintenance costs due to hardware changes will
be incurred.
 Hardware developments are so increased that this situation is rare.
 The application must be changed to use new hardware that replaces obsolete equipment.

Technical Factors

Technical Factors include the following:

Module Independence

It should be possible to change one program unit of a system without affecting any other unit.

Programming Language

Programs written in a high-level programming language are generally easier to understand than
programs written in a low-level language.

Programming Style

The method in which a program is written contributes to its understandability and hence, the ease
with which it can be modified.

Program Validation and Testing

 Generally, more the time and effort are spent on design validation and program testing, the
fewer bugs in the program and, consequently, maintenance costs resulting from bugs
correction are lower.
 Maintenance costs due to bug's correction are governed by the type of fault to be repaired.
 Coding errors are generally relatively cheap to correct, design errors are more expensive
as they may include the rewriting of one or more program units.
 Bugs in the software requirements are usually the most expensive to correct because of the
drastic design which is generally involved.

Documentation

 If a program is supported by clear, complete yet concise documentation, the functions of

understanding the application can be associatively straight-forward.
 Program maintenance costs tends to be less for well-reported systems than for the system
supplied with inadequate or incomplete documentation.
Maintenance Cost Estimation

Software engineers must understand the different categories of software maintenance as discussed
above, in order to address the question of estimating the cost of software maintenance. For
planning purposes, estimating costs is an important aspect of software maintenance.

Cost estimation

It was mentioned in “Impact Analysis”, that impact analysis identifies all systems and software
products affected by a software change request and develops an estimate of the resources needed
to accomplish that change.

Maintenance cost estimates are affected by many technical and non-technical factors.
ISO/IEC14764 states that “the two most popular approaches to estimating resources for software
maintenance are the use of parametric models and the use of experience”. Most often, a
combination of these is used.

Parametric models

Some work has been undertaken in applying parametric cost modeling to software maintenance.
Significance is that data from past projects are needed in order to use the models. Jones discusses
all aspects of estimating costs, including function points (IEEE14143.1-00), and provides a
detailed chapter on maintenance estimation.

Experience

Experience, in the form of expert judgment (using the Delphi technique, for example), analogies,
and a work breakdown structure, are several approaches which should be used to augment data
from parametric models. Clearly the best approach to maintenance estimation is to combine
empirical data and experience. These data should be provided as a result of a measurement
program.

Software Maintenance Measurement

Grady and Caswell discuss establishing a corporate-wide software measurement program, in

which software maintenance measurement forms and data collection are described. The Practical
Software and Systems Measurement (PSM) project describes an issue-driven measurement
process that is used by many organizations and is quite practical.

There are software measures that are common to all endeavors, the following categories of which
the Software Engineering Institute (SEI) has identified: size; effort; schedule; and quality. These
measures constitute a good starting point for the maintainer.
Specific Measures

Abran presents internal benchmarking techniques to compare different internal maintenance

organizations. The maintainer must determine which measures are appropriate for the organization
in question. IEEE1219-98 suggests measures which are more specific to software maintenance
measurement programs. That list includes a number of measures for each of the four sub-
characteristics of maintainability:

 Analyzability: Measures of the maintainer’s effort or resources expended in trying to

diagnose deficiencies or causes of failure, or in identifying parts to be modified
 Changeability: Measures of the maintainer’s effort associated with implementing a
specified modification
 Stability: Measures of the unexpected behavior of software, including that encountered
during testing
 Testability: Measures of the maintainer’s and users’ effort in trying to test the modified
software

Certain measures of the maintainability of software can be obtained using available commercial
tools.

Maintenance Process

Software Maintenance Process and activities

The software maintenance process involves various software maintenance techniques that can
change according to the type of maintenance and the software maintenance plan in place.

IEEE provides a framework for sequential maintenance process activities. It can be used in
iterative manner and can be extended so that customized items and processes can be included.

These activities go hand-in-hand with each of the following phase:

1. Identification & Tracing – The process of determining what part of the software needs to be
modified (or maintained). This can be user-generated or identified by the software developer itself
depending on the situation and specific fault. It involves activities pertaining to identification of
requirement of modification or maintenance
2. Analysis – The process of analyzing the suggested modification including understanding the
potential effects of such a change. This step typically includes cost analysis to understand if the
change is financially worthwhile. The modification is analyzed for its impact on the system
including safety and security implications.
3. Design – New modules, which need to be replaced or modified, are designed against
requirement specifications set in the previous stage. Test cases are created for validation and
verification. Designing the new changes using requirement specifications
4. Implementation – The process of implementing the new modules by programmers. The new
modules are coded with the help of structured design created in the design step
5. System Testing – Integration testing is done among newly created modules. Integration testing
is also carried out between new modules and the system. Before being launched, the software and
system must be tested. This includes the module itself, the system and the module, and the whole
system at once.
6. Acceptance Testing- After testing the system internally, it is tested for acceptance with the
help of users. If at this state, user complaints some issues they are addressed or noted to address in
next iteration. Users test the modification for acceptance. This is an important step as users can
identify ongoing issues and generate recommendations for more effective implementation and
changes.
7. Delivery – Software updates or in some cases new installation of the software. This is when
the changes arrive at the customers’ end, the system is deployed all over the organization either by
small update package or fresh installation of the system

8. Maintenance management - Configuration management is an essential part of system

maintenance. It is aided with version control tools to control versions, semi-version or patch
management

As already noted, many maintenance activities are similar to those of software development.
Maintainers perform analysis, design, coding, testing, and documentation. They must track
requirements in their activities just as is done in development, and update documentation as
baselines change. ISO/IEC14764 recommends that, when a maintainer refers to a similar
development process, he must adapt it to meet his specific need. However, for software
maintenance, some activities involve processes unique to software maintenance.

Unique activities

There are a number of processes, activities, and practices that are unique to software maintenance,
for example:

 Transition: a controlled and coordinated sequence of activities during which software is

transferred progressively from the developer to the maintainer.
 Modification Request Acceptance/Rejection: modification request work over a certain
size/effort/complexity may be rejected by maintainers and rerouted to a developer.
 Modification Request and Problem Report Help Desk: an end-user support function that
triggers the assessment, prioritization, and costing of modification requests.
 Impact Analysis.
 Software Support: help and advice to users concerning a request for information (for
example, business rules, validation, data meaning and ad-hoc requests/reports).
 Service Level Agreements (SLAs) and specialized (domain-specific) maintenance
contracts which are the responsibility of the maintainers.
Supporting activities

Maintainers may also perform supporting activities, such as software maintenance planning,
software configuration management, verification and validation, software quality assurance,
reviews, audits, and user training.

Maintenance planning activity

An important activity for software maintenance is planning, and maintainers must address the
issues associated with a number of planning perspectives:

 Business planning (organizational level)

 Maintenance planning (transition level)
 Release/version planning (software level)
 Individual software change request planning (request level)

At the individual request level, planning is carried out during the impact analysis. The
release/version planning activity requires that the maintainer:

 Collect the dates of availability of individual requests

 Agree with users on the content of subsequent releases/versions
 Identify potential conflicts and develop alternatives
 Assess the risk of a given release and develop a back-out plan in case problems should
arise
 Inform all the stakeholders

Whereas software development projects can typically last from some months to a few of years, the
maintenance phase usually lasts for many years. Making estimates of resources is a key element
of maintenance planning. Those resources should be included in the developers’ project planning
budgets. Software maintenance planning should begin with the decision to develop a new system
and should consider quality objectives (IEEE1061-98). A concept document should be developed,
followed by a maintenance plan.

The concept document for maintenance should address:

 The scope of the software maintenance

 Adaptation of the software maintenance process
 Identification of the software maintenance organization
 An estimate of software maintenance costs

The next step is to develop a corresponding software maintenance plan. This plan should be
prepared during software development, and should specify how users will request software
modifications or report problems. Software maintenance planning is addressed in IEEE 1219 and
ISO/IEC 14764. ISO/IEC14764 provides guidelines for a maintenance plan.
Finally, at the highest level, the maintenance organization will have to conduct business planning
activities (budgetary, financial, and human resources) just like all the other divisions of the
organization.

Software configuration management

The IEEE Standard for Software Maintenance, IEEE 1219, describes software configuration
management as a critical element of the maintenance process. Software configuration management
procedures should provide for the verification, validation, and audit of each step required to
identify, authorize, implement, and release the software product.

It is not sufficient to simply track Modification Requests or Problem Reports. The software product
and any changes made to it must be controlled. This control is established by implementing and
enforcing an approved software configuration management (SCM) process. SCM for software
maintenance is different from SCM for software development in the number of small changes that
must be controlled on operational software. The SCM process is implemented by developing and
following a configuration management plan and operating procedures. Maintainers participate in
Configuration Control Boards to determine the content of the next release/version.

Software quality

It is not sufficient, either, to simply hope that increased quality will result from the maintenance
of software. It must be planned and processes implemented to support the maintenance process.
The activities and techniques for Software Quality Assurance (SQA), V&V, reviews, and audits
must be selected in concert with all the other processes to achieve the desired level of quality. It is
also recommended that the maintainer adapt the software development processes, techniques and
deliverables, for instance testing documentation, and test results.

Techniques for Maintenance

This subarea introduces some of the generally accepted techniques used in software maintenance.

Program Comprehension

Programmers spend considerable time in reading and understanding programs in order to

implement changes. Code browsers are key tools for program comprehension. Clear and concise
documentation can aid in program comprehension.

Reengineering

Software Re-engineering 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 etc.
Re-engineering is the reorganizing and modifying existing software systems to make them more
maintainable.

Reengineering is defined as the examination and alteration of software to reconstitute it in a new

form, and includes the subsequent implementation in the new form. Dorfman and Thayer state that
reengineering is the most radical (and expensive) form of alteration. Others believe that
reengineering can be used for minor changes. It is often not undertaken to improve maintainability,
but to replace aging legacy software. Arnold provides a comprehensive compendium of topics, for
example: concepts, tools and techniques, case studies, and risks and benefits associated with
reengineering. The need for reengineering include

To describe a cost-effective option for system evolution.

To describe the activities involved in the software maintenance process.

To distinguish between software and data re-engineering and to explain the problems of data re-
engineering.

Steps involved in Re-engineering:

Inventory Analysis
Document Reconstruction
Reverse Engineering
Code Reconstruction
Data Reconstruction
Forward Engineering

Diagrammatic representation of reengineering

Re-engineering Cost Factors:

The quality of the software to be re-engineered

The tool supports available for re-engineering
The extent of the required data conversion
The availability of expert staff for re-engineering

Advantages of Re-engineering:

Reduced Risk: As the software is already existing, the risk is less as compared to new software
development. Development problems, staffing problems and specification problems are the lots of
problems which may arise in new software development.
Reduced Cost: The cost of re-engineering is less than the costs of developing new software.
Revelation of Business Rules: As a system is re-engineered , business rules that are embedded in
the system are rediscovered.
Better use of Existing Staff: Existing staff expertise can be maintained and extended accommodate
new skills during re-engineering.

Disadvantages 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.

Reverse engineering

Reverse engineering is the process of analyzing software to identify the software’s components
and their interrelationships and to create representations of the software in another form or at
higher levels of abstraction. Reverse engineering is passive; it does not change the software, or
result in new software. Reverse engineering efforts produce call graphs and control flow graphs
from source code. One type of reverse engineering is re documentation. Another type is design
recovery. Refactoring is program transformation which reorganizes a program without changing
its behavior, and is a form of reverse engineering that seeks to improve program structure.

Reverse engineering is a process or method through which one attempts to understand through
deductive reasoning how a previously made device, process, system, or piece of software
accomplishes a task with very little insight into exactly how it does so.

It is a process of recovering the design, requirement specifications and functions of a product from
an analysis of its code
Software Reverse Engineering is a process of recovering the design, requirement specifications
and functions of a product from an analysis of its code. It builds a program database and generates
information from this.

The purpose of reverse engineering is to facilitate the maintenance work by improving the
understandability of a system and to produce the necessary documents for a legacy system.

Reverse Engineering Goals:

Cope with Complexity.

Recover lost information.
Detect side effects.
Synthesise higher abstraction.
Facilitate Reuse.

The 3 stages of reverse engineering

Reverse engineering is taking apart an object to see how it works in order to duplicate or enhance
the object. The practice, taken from older industries, is now frequently used on computer hardware
and software. You can reverse engineer by constructing models that describe the existing software
and the presumed intent. This process of reverse engineering has three main stages:

Implementation Recovery

In implementation recovery, you prepare an initial model that forms the basis for reverse
engineering. Because the initial model will serve as a reference, it should purely reflect the
implementation and have no inferences.

The first task is to browse existing documentation and learn about an application. The resulting
context clarifies the developer’s intent and makes it easier to communicate with application
experts. You should finish this task in a few hours. What you learn is incidental to the actual
reverse engineering, but it is important because it helps you notice more as you proceed.

The next step is to enter the database structure into a modeling tool by typing or automation. Some
tools can read the system tables of an RDBMS and seed a model. If you use these tools, you should
at least skim the database structure to get a feel for the development style.

Design Recovery

During design recovery, you undo the mechanics of the database and perform only straightforward
actions. You should postpone conjecture and interpretation until the analysis-recovery stage.
Typically, you can perform design recovery autonomously, without help from application experts.
During this stage, you resolve three main issues.
Identity. Most often, unique indexes will be defined for the candidate keys of the entity types.
Otherwise, look for unique combinations of data; such data can suggest, but do not prove, a
candidate key. You can also infer candidate keys by considering names and conventions of style.
A suspected foreign key may imply a corresponding candidate key.

Foreign keys. Foreign key (references from one table to another) determination is usually the most
difficult aspect of design recovery. Matching names and data types can suggest foreign keys. Some
DBMSs, such as RDBMSs, let developers declare foreign keys and their referent, but most legacy
applications do not use this capability.

Queries. When queries are available, you can use them to refine your understanding of identity
and foreign keys.

The final product of design recovery still reflects the DBMS paradigm and may include
optimizations and errors. In practice, the model will seldom be complete. Portions of the structure
may be confusing.

Analysis Recovery

The final phase is analysis recovery interpret the model, refine it, and make it more abstract. It is
primarily during this phase that you should consult with available application experts. Analysis
recovery consists of four main tasks.

Clarification. Remove any remaining artifacts of design. For example, an analysis model need not
include file and database access keys; they are merely design decisions and contain no essential
information.

Redundancy. Normally remove derived data that optimize the database design or that were
included for misguided reasons. You may need to examine data before determining that a data
structure is a duplicate.

Errors. Eliminate any remaining database errors. I include this step during analysis recovery
because you must thoroughly understand the database before concluding that the developer erred.
In the earlier stages, an apparent error could instead have been a reasonable practice or the result
of incompletely understanding the database.

Model integration. Multiple information sources can lead to multiple models. For example, it is
common to have a reverse-engineered model from study of the structure and data. A forward-
engineered model might be prepared from a user manual. The final analysis model must fuse any
separate models.
Steps of Software Reverse engineering
Collection of Information: This step focuses on collecting all possible information (i.e., source
design documents etc.) about the software.

Examining the information: The information collected in step-1 as studied so as to get familiar
with the system.

Extracting the structure: This step concerns with identification of program structure in the form
of structure chart where each node corresponds to some routine.

Recording the functionality: During this step processing details of each module of the structure,
charts are recorded using structured language like decision table, etc.

Recording data flow: From the information extracted in step-3 and step-4, set of data flow
diagrams are derived to show the flow of data among the processes.

Recording control flow: High level control structure of the software is recorded.

Review extracted design: Design document extracted is reviewed several times to ensure
consistency and correctness. It also ensures that the design represents the program.

Generate documentation: Finally, in this step, the complete documentation including SRS, design
document, history, overview, etc. are recorded for future use.

Reverse Engineering Tools:

Reverse engineering if done manually would consume lot of time and human labour and hence
must be supported by automated tools. Some of tools are given below:

CIAO and CIA: A graphical navigator for software and web repositories along with a collection
of Reverse Engineering tools.

Rigi: A visual software understanding tool.

Bunch: A software clustering/modularization tool.

GEN++: An application generator to support development of analysis tools for the C++ language.

PBS: Software Bookshelf tools for extracting and visualizing the architecture of programs.

A common example of reverse engineering is to adapt a program written for use with one
microprocessor to another. Other examples include reconstructing lost source code, studying how
a program performs certain operations, improving performance and fixing bugs or correcting errors
when the source code is not available.
Examples of Reverse engineering

Software

A programmer can reverse engineer a software program to understand more about it. They can
create a new program based on the knowledge acquired from the reverse engineering process. They
can also use this technique for software that requires improvement and maintenance. Though a
computer program is not a tangible product, the reverse engineering process is similar. A
programmer can extract the different parts and codes of a software program to understand its
functionality.

Mechanical project

A mechanic can reverse engineer different products, including washing machines, vehicles or air
conditioning units. Without creating a new model, a mechanic can disassemble a non-working part
and find a viable solution. After finding a solution and fixing the malfunction, they can rebuild the
product.

Often, engineers use the backward engineering concept to understand the design of a computer
and its parts. An engineer can deconstruct a computer to replace an existing part with a new part
or run tests on a broken part. This is helpful for people who are new to building computers.

Network security assessment

Reverse engineering is an essential tool for companies that perform network security assessments.
In this process, companies divide their security team into two parts. One team simulates attacks on
software, while the other team monitors the network and reverse engineers the attack by other team
members. The information from the mock attacks can help strengthen the security of a corporate
network.

Construction: In the construction industry, architects use the backward engineering technique to
address a specific challenge with the design of a building. Using large scanners, the engineer or
architect measures the 3D shape of the building or process plant. They can identify potential design
flaws and fix them based on this information.

Migration
During software’s life, it may have to be modified to run in different environments. In order to
migrate it to a new environment, the maintainer needs to determine the actions needed to
accomplish the migration, and then develop and document the steps required to effect the migration
in a migration plan that covers migration requirements, migration tools, conversion of product and
data, execution, verification, and support. Migrating software can also entail a number of
additional activities such as:

 notification of intent: a statement of why the old environment is no longer to be supported,

followed by a description of the new environment and its date of availability;
  parallel operations: make available the old and new environments so that the user
experiences a smooth transition to the new environment;
 notification of completion: when the scheduled migration is completed, a notification is
sent to all concerned;
 post operation review: an assessment of parallel operation and the impact of changing to
the new environment;
 data archival: storing the old software data.

Retirement
Once software has reached the end of its useful life, it must be retired. An analysis should be
performed to assist in making the retirement decision. This analysis should be included in the
retirement plan, which covers retirement requirements, impact, replacement, schedule, and effort.
Accessibility of archive copies of data may also be included. Retiring software entails a number
of activities similar to migration.

Software Maintenance Tools

Introduction

A software maintenance tool is an artifact that supports a software maintainer in performing a task.
The use of tools for software maintenance simplifies the tasks and increases efficiency and
productivity.

There are several criteria for selecting the right tool for the task. These criteria are capability
features, cost/benefit, platform, programming language, ease of use, openness of architecture,
stability of vendor, and organizational culture.

Capability decides whether the tool is capable of fulfilling the task. Once it has been decided that
a method can benefit from being automated, then the features of the tool need to be considered for
the job.

The tool must be analyzed for the benefits it brings against its cost. The benefit indicators of a tool
are quality, productivity, responsiveness, and cost reduction. The environment that the tool runs
on is called the platform.

The language of the source code is called the programming language. It’s important to select a tool
that supports a language that is an industry standard.

The tool should have a similar feel to the ones that the users are already familiar with. The tool
should have the ability to be integrated with different vendors’ tools. This will help when a tool
will need to run with other tools.
The openness of the architecture plays an important role when the maintenance problem is
complex. Therefore, it is not always sufficient to use only one tool. There may need to be multiple
tools running together.

It is also important to consider the vendor’s credibility. The vendor should be capable of supporting
the tool in the future. If the vendor is not stable, the vendor could run out of business and not be
able to support the tool.

Another important factor is the culture of the organization. Every culture has its own work pattern.
Therefore, it is important to take into consideration whether the tool is going to be accepted by the
target users.

The chosen tools must support program understanding and reverse engineering, testing,
configuration management, and documentation.

Selecting a tool that promotes understanding is very important in the implementation of change
since a large amount of time is used to study and understand programs.

Tools for reverse engineering also accomplish the same goal. The tools mainly consist of
visualization tools, which assist the programmer in drawing a model of the system.

Examples of program understanding and reverse engineering tools include the program slicer static
analyzer, dynamic analyzer, cross-referencer and dependency analyzer.

Slicing is the mechanical process of marking all the sections of a program text that may influence
the value of a variable at a given point in the program. Program slicing helps the programmers
select and view only the parts of the program that are affected by the changes. Static analyzer is
used in analyzing the different parts if the program such as modules, procedures, variables, data
elements, objects and classes. A static analyzer allows general viewing of the program text and
generates summaries of contents and usage of selected elements in the program text, such as
variables or objects.

A dynamic analyzer could be used to analyze the program while it is executing. A data flow
analyzer is a static analysis tool that allows the maintainer to track all possible data flow and
control flow paths in the program. It allows analysis of the program to better outline the underlying
logic of the program. It also helps display the relationship between components of the system. A
cross-referencer produces information on the usage of a program. This tool helps the user focus on
the parts that are affected by the change.

A dependency analyzer assists the maintainer to analyze and understand the interrelationships
between entities in a program. Such a tool provides capabilities to set up and query the database
of the dependencies in a program. It also provides graphical representations of the dependencies.
Testing is the most time consuming and demanding task in software maintenance.

Therefore, it could benefit the most from tools. A test simulator tool helps the maintainer
to test the effects of the change in a controlled environment before implementing the change on
the actual system. A test case generator produces test data that is used to test the functionality of
the modified system, while a test path generator helps the maintainer to find all the data flow and
control flow paths affected by the changes.

Configuration management benefits from automated tools. Configuration management and version
control tools help store the objects that form the software system. A source control system is used
to keep a history of the files so that versions can be tracked and the programmer can keep track of
the file changes.

Commercially available products

There are numerous products on the market available for software maintenance. One type

of product is bug tracking tools, which play an important role in maintenance. Bugzilla by the
Mozilla Foundation is an example of such a tool. Other bug tracking products are Test Director by
Mercury Interactive, Silk Radar by Segue Software, SQA Manager by Rational software, and QA
director by Compuware.

ProTeus III Expert CMMS by Eagle Technology, Inc. is a maintenance software package that lets
users schedule preventative maintenance, generate automatic work orders, document equipment
maintenance history, track assets and inventory, track personnel, create purchase orders, and
generate reports. Microsoft Visual Source Safe is a source control system tool that is used by
configuration management.

Products that are specific to programming languages are CCFinder and JAAT which

is specifically designed for JAVA programs. CCFinder identifies code clones in JAVA program.
JAAT executes alias analysis for JAVA programs. For C++ programs, there is a tool called OCL
query-based debugger which is a tool to debug C++ programs using queries formulated in the
object constraint language.

Summary of tools

The task of software maintenance has become so vital and complex that automated support is
required to do it effectively. The use of tools simplifies tasks, increase efficiency and productivity.
There are numerous tools available on the market for maintenance.