Unit 5: Chapter 7

Software Maintenance

7.0. Structure of the Unit

1. Unit Outcomes
2. Software Maintenance
3. Software Maintenance Process
4. Maintenance Models
5. Reverse Engineering
6. Softvware Re-engincering
7. Software Configuration Management
8. Agile Method
9. Extreme programming
10. Rapid application development
11. Clean Room Software Development
12. Component-Based Software Development
13. Self-Assessment Questions and Activities
14. Multiple-Choice Questions
15. Keys to Multiple-Choice Questions
16. Summary of the Unit

7.1. Unit Outcomes

After the successful completion of this unit, the student will be able to:

1 Understand the software as an evolutionary entity and recognize the need for maintenance.
Classify maintenance and estimate the cost of maintenance.
3 Analyze the features of software re-engincering and reverse engincering.
4 Understand rapid application development.
Discuss agile methods.

7.2. Management of Maintenance

Software maintenance is necessary for making changes to a software product after its delivery to the client.
Every software product needs maintenance once it is in use. The hardware, the components, and the
interface of the software necd revision if the platform is changed or new. An cnhanced operating system
requires the lower componcnt of the software to be advanced. Software maintenance is a necessity to fix
errors due to regular or extensive usage by the client. The software changes due to business status changes
or users' expectations. Software evolution refers to the modification of the characteristics of a software
product over generations. The reasons for software evolution are changes in the requirements of the client's
business. Defects in the existing system or changes in the system environment result in software evolution.
Some parts of the software may create errors such as incorrect operations or computation. Some of the non
functional requirements may get neglected in the developed software. Software evolution is a must to
respond to the demands of change. Software evolution is essential as organizations invest a large amount
of money in a business and they would prefer modification of the existing system rather than developing a
new system from scratch. Software maintenance is a general process of modifying a software product after
it is delivered to the client. The modifications or changes may be necessary for the following reasons:

To correct coding bugs.

2. To accommodate major changes in the design.
3 To manage the new requirements.
4. To migrate legacy or old software.

Software maintenance is classified as follows.

Corrective Maintenance: Corrective maintenance is related to correcting the faults and errors of a
software product. After the system is put in use, the customers give reports of the bugs if any. These
errors may be in the requirements, design, or coding of a system.
2. Adaptive Maintenance: Adaptive maintenance is used when the software environment changes. For
example, a customer may use a new operating system, or a new web or mobile app-based platform to
run the product. Adaptive maintenance is necessary when the hardware is included in the existing
system.
3 Perfective Maintenance: Perfective maintenance is required when the requirements and the features
of the system are advanced. The user may realize some new requirements or features that evolve the
developed software. Removing unwanted features and enhancing the system with the user's expericnce
are the goals of this type of maintenance.
4. Preventive Maintenance: Perfective maintenance is required when the requirements and the features
of the system are advanced. The user may realize some new requirements or features that evolve the
developed software. Removing unwanted features and enhancing the system with the user's experience
are the goals of this type of maintenance.

After creating a complex software system, software developers constantly need to be on the lookout to
correct and improve their software to remain competitive and relevant. New changes or modifications can
be included using the maintenance process.

7.3. Maintenance Process

Software maintenance is a major stage in SDLC. The process used for maintaining software is a process as
shown in Figure 7.1
 Analysis of
Modifying Prepare test Select a test
existing Software cases case
software

Test
Release new
modified
version
software
Figure 7.1 Maintenance Process

The maintenance process is called Software Maintenance Life Cycle (SMLC). There are seven phases in
SMLC as given below. These phases are executed iteratively, and the phase can be used for developing the
custom product.
1. ldentification Phase: In this phase, a request for modifying software is identified for further
processing. The maintenance activity is finalized using the system itself, via error messages or, by
users.

2. Analysis Phase: In this phase, the scope of the modification is determined, and the plan is prepared
for estimating resources, documentation, and storage information.
3. Design Phase: In this phase, new designs as per modified requirements are prepared. For cach new
design, test cases are prepared. The verification and validation process is followed after revising the
design.
4 Implementation Phase: In this phase, the new code is written as per the modified design. The new
features, configuration, and support for updates are given in this phase.
5. System Testing Phase: System testing is like regression testing. This testing is done for the new
modules to verify whether there are any bugs, errors, or defects.
6 Acceptance Testing Phase: A newly developed software system is reviewed by the user or a third
party. The focus of this step is to check whether all the features are as per the modified requirements.
7. Delivery Phase: In this phase, the modified software is deployed at the user's workplace. This phase
includes guidelines and manuals for using the modified software. The final testing of the system is
done by the client after the system is delivered.

Software process maintenance is represented as an abstraction using various models as given below.

7.4. Maintenance Process Models

The software maintenance process models are divided into two categories.

1) Maintenance Process Model 1: The first model is used when small changes are required in the
code and are documented. In this process model, a few team members collect the requirements,
analyze them, and formulate the strategy. The existing system is useful for modification and
debugging of errors. This is shown in Figure 7.2.
 collect changes
in requirements

Analyze the
changes

Develop the new

strategies

Apply new code

to the existing
Code

Update Integrate
Document and Test

Figure 7.2. Maintenance Process Model -I

2) Maintenance Process Model 2: When the requiremnent changes considerably, the amount of
rework is more. The modification in the software is done by combining reverse and forward
engincering. This process is known as software re-engineering. The legacy products are reverse
engincered to get module specifications. The specifications are further used to generate the design.
The design is then explored to produce requirements and new requirements are added. Thus, a
combination of processes such as software reverse and forward engincering, reconstructing, etc. is
known as software reengineering. Different models are given below.

Quick-Fix Models: In this model, a quick method is used to fix the problem after identifying the
defect. This work is low-cost, and the modification does not have a large influence on the overall
software system structure.

Boehm's Model: In this model, the maintenance process is performed in a closed loop based on
the cconomic model and risks.

Iterative Development Model: In this model, the maintenance process is iterative. The existing
system is analyzed, and changes are included to form a new system. The system changes are
documented from the beginning, a good design is maintained, and the complexity is reduced.
Re-use oriented Model: In this model, existing componcnts are re-used. These parts are modificd
or enhanced based on the new requirements. Modified parts are combincd to form a new system.
Computer-aided software engincering (CASE) tools are commonly used in re-use-oriented models
for maintenance.
7.5. Reverse Engineering
The maintenance of the software can be efficiently achieved by a good understanding of a system. A well
documented legacy system can be casily maintaincd. A legacy system is outdated computing software
and/or hardware that is still in use. The system still meets the needs it was originally designed for but doesn't
allow for growth. For example, Windows 7 officially became a legacy operating system in January 2020
after Microsoft stopped security updates and support for it. Common Business-Oriented Language or
COBOL is still used 55 years after its development. Several legacy systems are not well structured or there
may be wear and tear in the software due to continuous maintenance efforts or lack of documentation.
Reverse engineering helps in such cases with the maintenance of the software. A reverse engineering
process can be used in such situations. Reversc engincering is the process of recovering the design,
requirement specification, and functions of a product from the analysis of code. The Reverse Engineering
process is presented as shown in Figure 7.3.

Requirement
Specification

Design

Mocdule
Sp ation

Code

Figure 7.3. Reverse Engincering Process

In reverse engineering, the code is improved for better readability, understanding, and structure.
In many legacy software, the programs are not in proper structure. With the help of reverse
cngincering, identifiers, and data structures, are given meaningful names.
In the reverse enginecering process, the functionality is not changed.
Complex statements are simplified, and nested loops are replaced with multiple condition
statements. These changes are known as cosmetic changes.
In the reverse engincering process, the code is analyzed completely. The different modules and
their interface are understood.

The design can be cxtracted using tools such as structure charts, DFDs, and control flow diagrams.
In the last step, the SRS is written based on the design.

The benefits of the software reverse engineering are given below.

Understand the complexity.
Find out the side effects.

Recover the lost information.

Create new products.

" Explore reusability.
7.6. Software Re-engineering
Software re-engineering is a process where the existing software is reorganized and modificd for efficient
maintenance. It hclps in software evolution and adds quality to the product. Software re-engineering
identifies the activities in the software maintenance process. It reduces the risks and costs of software
development. The software re-engineering model is shown in Figure 7.4.
 Change
Requirements

Requirement Requirement
Specification Specification Forward
Reverse Engineering
Engineering

Design Design

Module
Module pecification
|Specification

Code Code

Figure 7.4. Software Re-cngincering

Some of the drawbacks of the software re-cngineering process are shown below.
Software re-engincering keeps challenges in its maintenance.
Some steps such as data management or modification in software architecture should be done
manually.
Some software products cannot be re-engincered.
7.7. Software Configuration Management
Software configuration refers to the state of the source code, design, SRS, test reports, user manual, or guide
used by software engineers during the SDLC. The state of the software product changes during its
development and testing. The software gets changed due to various reasons such as release, version, and
revision of the software. Software is released newly if there is any new bug or new functionality or small
changes in its usage and technology. For example, the addition of new features to correct a particular error
in the Windows operating system and the release of a new product.

If there is a major change in the hardware and technology in which the software product is working or the
functionality of the product is drastically changed then the software configuration is revised. For example,
the new version of Android updates for supporting new features, Version Windows 95, Windows 2000,
Windows XP, Windows 10, etc. is the version of theWindows Operating system. The software also requires
revision. If there are minor bugs or errors, then the software is revised in its configuration. For example,
revision in the typesetting features in MS Office. This release, version, and revision lead to software
configuration management.

Software Configuration Management vs Software Maintenance

Software configuration management (SCM) includes controlling different versions of the developed
software and managing changes or modifications based on the client's feedback. SCM is done using suitable
automated tools and a software quality control team. One important task in SCM is communicating changes.
With the help of SCM, the integrity of the configuredelements can be maintained. The important activities
in SCM are control versions, changes in the system, auditing, and incorporating changes in the software.
SCM is different from software maintenance. When the software is updated on a regular period, many
people are working in a team. The authors involved in the project may be gecographically distributed and
work simultaneously. If there are changes in user requirements, and policy, budget, schedules need to be
accommodated. Software maintenance is the process of changing, modifying, and updating software to
keep up with customer needs. Maintenance is performed on the software once it is put in operation. SCM
is performed when the software project starts and ends only when the software is taken out for operation.
SCM is performed during the software development life cycle, whereas software maintenance is after the
software product is completely developed.

7.8. Agile Methodology

In the carly 90s, software development was done using systematic planning including project planning,
quality control, requirement analysis, design, usage of CASE tools, etc. This software process was suitable
for large and complex projects handled by team members working across the country in different teams. In
this plan-driven approach, there was an overhead of managing many people, excess documentation, and
delays in planning and designing. This type of approach was not suitable for small and medium-sized
projects, because more time was spent on how the software development process rather than on actual
design and development. The plan-driven approach was also unsuitable for the system with frequently
changing requirements. The different drawbacks of the heavyweight plan-driven development approach
must lead to the development of agile methods
Agile methods focus more on software than design, planning, and documentation. Agile methods are based
on an incremental development approach and are suitable for developing projccts with rapidly changing
requirements. Important features of agile methods are as follows:
DQuick delivery of softwarc products.
2)Long-term software activities and documentation are avoided.
3)Individuals interact over software tools and processes.
4)Focus is on the development of software than documentation.
5)Clients are involved in the process.
6)Responses are given to the changes than following a plan.

The principles of Agile methods are listed in Table 7.1.

Principle Description
Client's Customers are involved in the software development process.
Involvement New requirements are added based on the client's feedback
Incremental Software is developed using small increments, every new
Delivery requirement is added to the increment.
People and Instead of a predefined process, the capacities of persons are
Process identified, and work is assigned.
Address Changes are accommodated in the ongoing software.
Changes
Simple The software process is less complex, and the focus is more
Approach on the software than the plan.
Table 7.1 Principles of Agile Methods

Agile methods are uscful in the following applications.

 1)Small and medium software products.
2)Customized software products with fewer rules and regulations.
3)Applications where there is transparency for customers
4)Prioritics are flexible.
5)Software delivery and improvement are continuous.

Agile methods are used in small or medium-sized teams, but it is difficult to expand for large systems.
Software systems need safety and security features. Agile methods require a lot of modification. For
critical systems like chemical plants, security alarms, medical applications, etc. agile methods nced to be
scaled. In practice, some of the difficulties faced in agile systems are:

1. Client's participation in the software process may not be possible due to the client's interest and
participation. Clients may not be able to spare time with the development team.
2. Some of the team members may not be able to do intense work in agile systems. Due to more pressure,
they may not be able to interact with other team members.
3. Ifthe priorities of the work to be done change frequently, then there may bea delay in the software
process.
4. Simplicity requires extra work. Every team member may not be able to simplify the system.

In practice, agile and plan-driven development methods can be used in a hybrid approach.
7.9. Extreme Programming
Extreme programming (XP) is the commonly known agile development method. It was namcd extreme
because the activiics in the agile methods are pushed to an extreme level. The different phases of XP are
shown in Figure 7.2.

Collect User
Divide scenarios into Plan product
scenarios for a
number of tasks release
product release

Evaluate Release Develop and Test

System Software Software

Figure 7.5: Extreme Programming

In XP, requirements are represented as scenarios or user stories, and they are implemented as a set of tasks.
These tasks are tested, and software is released. The developed system is evaluated, and user feedback is
taken. In XP, new versions are built many times per day. After every two weeks, increments are delivered
to customers. Important features of XP are given below.
1. XP is based on incremental development; user stories are uscd as a base for a new function.
2. Customers are involved in the acceptance test of the developed software parts.
3. People work in a group of two. This is known as pair programming. Here people can exchange
knowledge with each other.
4. Frequent software relcases help in fulfilling the client's requirements.
5. Simplicity is maintained.

7.10. Rapid Application Development

the l980s. It is based
RAD stands for Rapid Application Development Model. RAD is proposed by IBM in
is
on prototyping and iterative development with no specific planning involved. Thc software product
techniques. The
developed in a short period (60-90 days). This model uses powerful development tools and
components or functions are developed in parallel as if they were mini projects. The developments are time
boxed, delivered, and then assembled into a working prototype. This can quickly give the customer
Customer
something to see and use and provide feedback regarding the delivery and their requirements.
different stages of RAD are given
requirements are gathered through workshops or focus groups. The
below.

Gather requirements. Analyze and plan requirements.

Prepare Design
Get user feedback.

Construction: In this step. the prototype is refined using automated powerful tools to get a final product.
is also checked in this
Cutover: The interconnection of different modules is verified. User acceptance
step.

A RAD model is presented in Figure 7.6.

Gather
Requirements

Plan
Requirements
Analyze
Design
Code
Team
Test
Team 2

Implement Implement .- Develop

Module 1 Module 2 Module N

Integrate
Modules

Test the
Sofrware
Product
Figure 7.6: Rapid Application Development
7.11. Clean Room Software Development
Cleanroom software development is a software development method that uses the formal method to
overcome defects in the software. The word 'Cleanroom' is used in semiconductor fabrication units where
the environment is ultraclean. This approach aims to develop zero-defect software. This method is different
from traditional software development. Cleanroom software development leads to several benefits such as
improved quality, increased productivity, and improved software maintainability.

System
Specification using
Formal Method
Determine Prepare Verify Code)
Integrate
Software
Increments
Structured >using Formal Increments
Program Method
Identify
Operations Design Test
Statistical Inegrated
Test System

Figure 7.7 Cleanroom Process

A clean room software development is presented in Figure 7.7. The Cleanroom approach to software
development is bascd on five key strategies:

1. Formal specification: The software under development is specified using a formal method. One
commonly uscd method is a state-transition model that shows system responses to stimuli. The
stimulitrigger the changes in the states as per the spccification.
2. Incremental development: The cleanroom process is used for the parts of the software. The software
is considered a set of increments and cach increment is developed separately. Each increment is
validated to check whether it is meeting the customer's requirements.
3. Structured programming: The requirement specification is implemented using a limited number of
abstract methods. The requirements are converted into a set of steps so that there is a correct
transformation into a program code.
4. Static verification: Code inspection and review methods are used for static verification. Here the
software testing methods are not used.
5. Statistical testing of the system: The testing of the integrated software increments is done
statistically. This will help to determine the reliability of the software.

7.12. Component-based Software Development

Component-based software development includes CASE means Computer-Aided Software Engineering.
CASE tools provide automated support in software engincering. The different activities such as gathering
requirements, preparing software design, developing code, and testing can be performed with the help of
CASE tools. The software configuration and project management are also supported by CASE tools.
The advantages of using CASE tools are thcy can be used at a low cost. There is no development from
scratch for developing quality software with CASE tools. The productivity of the software development
gets improved and is collectively stored as toolkits in a common environment. The tools with common
information are integrated into a central repository. For example, a data dictionary can be used as a CASE
tool for storing elementary and composite data. The CASE environment is different from than programming
environment. In the programming environment, the tools are available only for coding e.g., Java Virtual
Machine supporting Java on different platforms, databases, web, ctc. The CASE tools environment is for
all the phases of SDLC. A collection of CASE tools is shown in Figure 7.8.

Coding Project
Support Management Prototyping|

Consistent Configuration
Analysis Management
Central

Document
Repository Structured
Generation diagram
facilities

Format Query and

Structured Changing Report
Analysis facilities facilities

Figure 7.8 CASE Tools

Prototyping CASE tools are used for requirements. Prototyping CASE tools are used to understand user
interaction, data storage, and retrieval, the control flow in the program, data processing at different steps,
ete. during requirement collection.
Structurcd analysis and design CASE tools are uscd for drawing software design diagrams with less
effort. Many hierarchical levels can be analyzed using CASE tools. The tools must support casy
navigation and consistency during the design. E.g., flow chart maker tools, UML diagram tools for use
case diagrams, sequence diagrams, etc. in object-oriented design.
CASE tools cannot be directly used to write code. The commonly used programming languages use
CASE tools for database tables, interfaces, records, or the outer skeleton of the customized software to be
developed. Eclipse and Cscope are used in searching code in C, and Adobe Edge Inspect tool is used in
web page development.
CASE tools must support the testing of reqirements and design. The test plan generation must be
supported by the CASE tools. The SoapTest is a CASE tool that allows users to validate the functions,
unit testing, and functional testing. SoapTest rapidly creates regression tests.
7.12.1 CASE Tools Architecture:
The architecture ofa typical modern CASE environment consists of three components. These components
are connected to the central repository.
1. User interface

2. Toolset
 3. Object management system (OMS)

Users can learn how to access the different tools with the help of the interface. This helps in reducing the
overhead of learning efforts for a CASE tool. OMS is used to map the different entities of software such as
requirements, design, code, text data, and project plans to the storage management system or repository.
E.g., in the relational database management system, the relationships between cntities, attribute declaration,
initialization, types of relationships, ete. can be mapped using the OMS.
The repository consists of di fferent CASE tools used in the requirements, design, coding, and testing phases
of software. CASE Tools Classification is shown in Figure 7.9.

Planning

Analysis Upper CASE

Design Integrated
CASE

Implementation
Lower CASE
Testing

Maintenance

Figure 7.9: CASE Tools Classification

Case tools can be divided based on the components given below.
1. Upper Case Tools - Upper CASE tools are used in requirement collection, planning, analysis, and
design stages of SDLC.
2. Lower Case Tools - Lower CASE tools are used in the coding, testing, and maintenance phases of
SDLC.
3. Integrated Case Tools - Integrated CASE tools are useful in all the stages such as requirement
specification, design, coding, testing, and documentation.

7.12.2 Advantages and Drawbacks of CASE Tools

CASE tools are beneficial in cost-saving at different phases of SDLC. CASE tools improve speed and
reduce the time for any software development activity. Preparing software design manually is time
consuming and tedious. CASE tools help in the consistent and complete designing of the software.
The cost of development can be saved up to 30 to 40%. As the CASE tools are alrcady undergone testing.
the quality of work is better than any newly developed program. The CASE tools are useful in generating
consistent documentation. There are fewer chances of having a human error due to the central repository.
Preparing software design using CASE tools is easier than the manual or other geometric methods.
The different phases of SDLC are systematic and consistent due to the usage of the CASE tools.
This saves a lot of maintenance costs. The overall working of the SDLC is structured and systematic with
the help of CASE tools.
Some of the drawbacks of the CASE tools are: The staff using the CASE tools must
be given training on
using the tool for the respective phase of the SDLC. In many situations, staff will resist the use of the CASE
tool. The size of the project may not be suitable for the CASE tool in certain cases. The level of quality
using CASE tools may not be desirable in certain applications.
7.13. Self-assessment Questions and Activities
Q1. Explain software maintenance.
Q2. Compare forward and reverse engincering.
Q3. Discuss the importance of software re-engineering.
Q4. What is the Software Configuration Management process? Why is it
necessary?
05. What is the agile method in software development?

Q6. Explain RAD with a suitable diagram.

07. Witha suitable diagram explain extreme programming.
O8. What is cleanroom software development? Explain in brief.
09. Discuss CASE tools with the architecture.
Ql0. List the advantages and drawbacks of CASE tools.
7.14. Multiple-Choice Questions
1. Which of the following is not a maintenance method?
a. Adaptive maintenance
b, Corrective maintenance
c. Preventive maintenance
d. Consistent maintenance

2. In the maintenance phase, the type of software testing performed is:

a. Integration testing
b. System testing
c. Regression testing
d. Acceptance testing
3. The method of generating the requirement specifications from the code is known as:
a. Re-engineering
b. Reverse cngineering
C Next reengincering
d. Forward engincering
4. Legacy system term is used for:
a. Discarded systems
b. New system