Class of 2021/22
Software Maintenance
CS 410-Lecture 01
INTRODUCTION TO SOFTWARE MAINTENANCE AND
EVOLUTION
Presenter: Thomas [Introduction to Software maintenance/evolution]
Course objectives
Given the lectures series, slides and readings,
students should be able to demonstrate physically the
process of software maintenance in both legacy and
modern system in three hours
students should be able to perform software maintenance
activities in subjected software in three days
students should be able to demonstrate physically the
process of intelligent software maintenance for prediction,
analysis etc. using machine learning software in three
hours
Presenter: Thomas [Introduction to Software maintenance/evolution]
Summary of Discussion This Semester
• Overview of Software Maintenance and Evolution:
Introduction, Forms of Maintenance, Laws of Software
Evolution, Software Reengineering, Software Maintenance
Models, Change control Management, Change Impact Analysis,
Version control systems, Release planning.
• Analysis of Software Artifacts: Program slicing, Refactoring.
• Introduction to Mining Techniques: Machine learning, Data
mining, Text mining, Temporal mining.
• Mining Software Repositories: Visualization, Defect prediction,
Mining process and social data.
Presenter: Thomas [Introduction to Software maintenance/evolution]
Summary of discussion this trimester
• Software Maintenance Metrics: Statistical background and
metrics, Software Maintenance Process and Products Metrics,
Software Maintenance Complexity, Regression testing
• Software
Management
Concerns/decision:
Software
Maintenance Improvement, Redesign, Continue Maintenance or
Discontinue Software, how and when to migrate to New
Software Acquisition, Software Maintenance Standards,
• Maintenance Tools: Selecting Software for software
Maintenance tool, Integrated Tool, Software Maintenance Tools
Categorization, Example of Software Maintenance Tools in Each
in each Category
Presenter: Thomas [Introduction to Software maintenance/evolution]
Some References
1. Ian Sommerville, (2007) “Software Engineering”, 8th Edition,
Addison Wesley,
2. Ian Sommerville, (2010) “Software Engineering”, 9th Edition,
Pearson Education
3. Stamelos I., Schaefer I. (2014) Software Reuse for Dynamic
Systems in the Cloud and Beyond, Springer
4. Grubb, Penny & Armstrong A Takang (2003) Software
Maintenance: Concepts and Practice (Second Edition), ISBN
981-238-426-X(pbk), World Scientific Press.
5. Mens, Tom and Serge Demeyer (eds) (2008) Software Evolution,
Springer
6. Diehl, Stephan (2007) Software Visualization, Springer
Presenter: Thomas [Introduction to Software maintenance/evolution]
Prerequisite and delivery model
• Prerequisite: CS 315: Software Testing and Quality
Assurance
• Delivery: 28 hrs lecture, 14 hrs tutorial/seminar, 7 hrs
assignment, 14 hrs independent studies
Presenter: Thomas [Introduction to Software maintenance/evolution]
Introduction
• Organizations have huge investments in their software systems they are critical business assets.
• To maintain the value of these assets to the business, they must
be changed and updated.
• The majority of the software budget in large companies is
devoted to evolving existing software rather than developing new
software.
Presenter: Thomas [Introduction to Software maintenance/evolution]
Distribution of Software Maintenance
Cost
• Reports suggest that the cost of maintenance is high. A study on
estimating software maintenance found that the cost of
maintenance is as high as 67% of the cost of entire software
process cycle.
On an average, the cost of
software maintenance is
more than 50% of all SDLC
phases. There are various
factors, which trigger
maintenance cost go high,
such as:
Presenter: Thomas [Introduction to Software maintenance/evolution]
What affects Software Maintenance Cost
• The standard age of any software is considered up to 10 to 15
years.
• Older software, which were meant to work on slow machines
with less memory and storage capacity cannot keep themselves
challenging against newly coming enhanced software on
modern hardware.
• As technology advances, it becomes costly to maintain old
software.
• Most maintenance engineers are newbie and use trial and error
method to rectify problem.
Presenter: Thomas [Introduction to Software maintenance/evolution]
What affects Software Maintenance Cost
• Often, changes made can easily hurt the original structure of
the software, making it hard for any subsequent changes.
• Changes are often left undocumented which may cause more
conflicts in future.
• Structure of Software Program
• Programming Language
• Dependence on external environment
• Staff reliability and availability
Presenter: Thomas [Introduction to Software maintenance/evolution]
Reasons for Software Change
• Software maintenance is widely accepted part of SDLC now a
days. It stands for all the modifications and updations done
after the delivery of software product. There are number of
reasons, why modifications are required, some of them are
briefly mentioned below:
Client Requirements - Over the time, customer may ask for
new features or functions in the software.
Host Modifications - If any of the hardware and/or platform
(such as operating system) of the target host changes,
software changes are needed to keep adaptability.
Presenter: Thomas [Introduction to Software maintenance/evolution]
Reasons for Software Change
• Software maintenance is widely accepted part of SDLC now a
days. It stands for all the modifications and updations done
after the delivery of software product. There are number of
reasons, why modifications are required, some of them are
briefly mentioned below:
Market Conditions - Policies, which changes over the time,
such as taxation and newly introduced constraints like, how to
maintain bookkeeping, may trigger need for modification.
Organization Changes - If there is any business level change
at client end, such as reduction of organization strength,
acquiring another company, organization venturing into new
business, need to modify in the original software may arise
Presenter: Thomas [Introduction to Software maintenance/evolution]
“Organization &
“Host
Client & Market
modifications” conditions Changes
”
Reasons for Software Change Ex.
• New requirements emerge when the software is used;
• The business environment changes;
• Errors must be repaired;
• New computers and equipment is added to the system;
• The performance or reliability of the system may have to be
improved.
• A key problem for organizations is implementing and
managing change to their existing software systems.
Presenter: Thomas [Introduction to Software maintenance/evolution]
Forms of Maintenance
• Repair software faults (corrective maintenance)
 Changing a system to correct deficiencies in the way meets its
requirements.
• Adapt software to a different operating environment (adaptive
maintenance)
 Changing a system so that it operates in a different environment
(computer, OS, etc.) from its initial implementation.
• Add to or modify the system’s functionality (perfective maintenance)
 Modifying the system to satisfy new requirements.
• Improve the program structure and system performance(preventive
maintenance)
 Rewriting all or parts of the system to make it more efficient and
maintainable.
Presenter: Thomas [Introduction to Software maintenance/evolution]
Software evolution and software
maintenance
• Defn: can be viewed in two broad and narrow perspective
• Broad definition of software evolution:
It refers to the study and management of the process of making
changes to software over time.
In this definition, software evolution comprises
Development, Maintenance, Reengineering activities
• Narrow definition of evolution: Sometimes, software evolution
is used to refer to the activity of adding new functionality to
existing software.
• Software maintenance refers to the activity of modifying
software after it has been put to use in order to maintain its
usefulness.
Presenter: Thomas [Introduction to Software maintenance/evolution]
Type of Changes
“Evolution”
“Reengineering”
“Maintenance”
• Repair software faults
 Changing a system to correct deficiencies in the way meets its
requirements.
• Adapt software to a different operating environment
 Changing a system so that it operates in a different environment
(computer, OS, etc.) from its initial implementation.
• Add to or modify the system’s functionality
 Modifying the system to satisfy new requirements.
• Improve the program structure and system performance
 Rewriting all or parts of the system to make it more efficient and
maintainable.
Presenter: Thomas [Introduction to Software maintenance/evolution]
Software Evolution Laws and Their
Description
• The evolution of a software system is a task where we deal with the
modification of a software product. And If a software system does
not support changes, it will gradually lapse into uselessness
 Laws about the evolution of Software System Characteristics
(ESSC)
(1974) Continuous change: Embedded-types (E-type) systems
must be continually adapted else they become progressively
less satisfactory.
(1980) Continuing growth: The functional content of an Etype system must be continually increased to maintain user
satisfaction with the system over its lifetime.
Presenter: Thomas [Introduction to Software maintenance/evolution]
Software Evolution Laws and Their
Description
 (1974) Increasing complexity: As an E-type system evolves, its
complexity increases unless work is done to maintain or reduce it.
 (1996) Declining quality: Stakeholders will perceive an E-type
system to have declining quality unless it is rigorously maintained
and adapted to its changing operational environment.
 Laws referring to the Organizational or Economic Resource
Constraints (OERC)
 (1980) Conservation of familiarity: During the active life of an
evolving E-type system, the average content of successive releases is
invariant.
 (1980) Conservation of organizational stability: The average
effective global activity rate in an evolving E-type system is
invariant over a product’s lifetime.
Presenter: Thomas [Introduction to Software maintenance/evolution]
Software Evolution Laws and Their
Description
 Meta-Laws (ML)
(1974) Self regulation: The evolution process of E-type
systems is self regulating, with a distribution of product and
process measures over time that is close to normal.
(1996) Feedback system: The evolution processes in E-type
systems constitute multi-level, multi-loop, multi-agent
feedback systems and must be treated as such to achieve
significant improvement over any reasonable baseline.
Presenter: Thomas [Introduction to Software maintenance/evolution]
Maintenance Activities
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.
Presenter: Thomas [Introduction to Software maintenance/evolution]
Maintenance Activities
• These activities go hand-in-hand with each of the following
phase:
Identification & Tracing - It involves activities pertaining to
identification of requirement of modification or maintenance.
It is generated by user or system may itself report via logs or
error messages. Here, the maintenance type is classified also.
Analysis - The modification is analyzed for its impact on the
system including safety and security implications. If probable
impact is severe, alternative solution is looked for. A set of
required modifications is then materialized into requirement
specifications. The cost of modification/maintenance is
analyzed and estimation is concluded.
Presenter: Thomas [Introduction to Software maintenance/evolution]
Maintenance Activities
• These activities go hand-in-hand with each of the following
phase:
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.
Implementation - The new modules are coded with the help
of structured design created in the design step.Every
programmer is expected to do unit testing in parallel.
System Testing - Integration testing is done among newly
created modules. Integration testing is also carried out
between new modules and the system. Finally the system is
tested as a whole, following regressive testing procedures.
Presenter: Thomas [Introduction to Software maintenance/evolution]
Maintenance Activities
• These activities go hand-in-hand with each of the following
phase:
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.
Delivery - After acceptance test, the system is deployed all
over the organization either by small update package or fresh
installation of the system. The final testing takes place at
client end after the software is delivered.
Presenter: Thomas [Introduction to Software maintenance/evolution]
Software Re-engineering
• When we need to update the software to keep its to the current
market, without impacting its functionality, it is called
software re-engineering. It is a thorough process where the
design of software is changed and programs are re-written.
• Legacy software cannot keep tuning with the latest technology
available in the market. Likewise, as the hardware become
obsolete, updating of software becomes a headache. Even if
software grows old with time, its functionality does not.
• For example, initially Unix was developed in assembly
language. When language C came into existence, Unix was reengineered in C, because working in assembly language was
difficult.
Presenter: Thomas [Introduction to Software maintenance/evolution]
Software Re-engineering
Re-Engineering Process
Decide what to re-engineer. Is it whole
software or a part of it?
Perform Reverse Engineering, in order to
obtain specifications of existing
software.
Restructure Program if required. For
example, changing function-oriented
programs into object-oriented
programs.
Re-structure data as required.
Apply Forward engineering concepts in
order to get re-engineered software.
Presenter: Thomas [Introduction to Software maintenance/evolution]
Terms in Software Re-engineering
• Reverse Engineering
• Program Restructuring
• Forward Engineering
Presenter: Thomas [Introduction to Software maintenance/evolution]
Terms in Software Re-engineering
• Reverse Engineering
It is a process to achieve system specification by thoroughly
analyzing, understanding the existing system. This process
can be seen as reverse SDLC model, i.e. we try to get higher
abstraction level by analyzing lower abstraction levels.
An existing system is previously implemented design, about
which we know nothing. Designers then do reverse
engineering by looking at the code and try to get the design.
With design in hand, they try to conclude the specifications.
Thus, going in reverse from code to system specification.
It is the process of design recovery which involves analyzing a program in an effort to
create a representation of the program at some abstraction level higher than source code
Presenter: Thomas [Introduction to Software maintenance/evolution]
Detailed View of RE
View of RE
Terms in Software Re-engineering
Program stucture
diagrams
Automated
analysis
System
information
store
System to be
re-engineered
Document
generation
Manual
annotation
Presenter: Thomas [Introduction to Software maintenance/evolution]
Data stucture
diagrams
Traceability
matrices
Terms in Software Re-engineering
• Reverse Engineering
There are two types of reverse engineering;
In the first type, the source code is available, but highlevel aspects of the program are no longer available.
– The efforts that are made to discover the source code
for the software that is being developed is known as
reverse engineering.
In the second case, the source code for the software is no
longer available;
– here, the process of discovering the possible source
code is known as reverse engineering.
Presenter: Thomas [Introduction to Software maintenance/evolution]
Terms in Software Re-engineering
• Reverse Engineering
 Reverse Engineering Tools
Once again, it is the process of analyzing the software to
determine its components and their relationships.
Can be accomplished by making use of some tools that are
categorized into debuggers or disassemblers, hex editors,
monitoring and decompile tools:
– Disassemblers –It is a program that translates the
executable file (convert binary code ) to the assembly
language and also used to extract strings, imported and
exported functions, libraries etc.
The disassemblers convert the machine language into a
user-friendly format
The most popular disassembler is IDA Pro.
Presenter: Thomas [Introduction to Software maintenance/evolution]
Terms in Software Re-engineering
• Reverse Engineering
 Reverse Engineering Tools
– Debuggers – This tool expands the functionality of a
disassembler by supporting the CPU registers, the hex
duping of the program, view of stack etc. Using debuggers,
the programmers can set breakpoints and edit the assembly
code at run time. Debuggers analyse the binary in a similar
way as the disassemblers and allow the reverser to step
through the code by running one line at a time to investigate
the results.
– Hex Editors – These editors allow the binary to be viewed
in the editor and change it as per the requirements of the
software. There are different types of hex editors available
that are used for different functions.
Presenter: Thomas [Introduction to Software maintenance/evolution]
Terms in Software Re-engineering
• Reverse Engineering
 Reverse Engineering Tools
– PE and Resource Viewer – The binary code is
designed to run on a windows based machine and has
a very specific data which tells how to set up and
initialize a program. All the programs that run on
windows should have a portable executable that
supports the DLLs the program needs to borrow from.
– For more on Reverse Engineering
Presenter: Thomas [Introduction to Software maintenance/evolution]
Terms in Software Re-engineering
• Reverse Engineering
 Requirement When Reverse Engineering
In order to reverse engineer a software you need to have:
– knowledge in the field where you want to apply the reverse
engineering;
 E.g. If you reverse any network applications, you
should know the principals of the inter-process
communications, the network structure itself, the
structure of the network packets that you are about to
see, connections and the order you are about to see
them, etc.
 If you are reversing the crypto algorithms, you should
have the knowledge in the crypto science and know the
basics or the most popular algorithms that are often
used in the field - it may help you to save some extra
time while researching.
Presenter: Thomas [Introduction to Software maintenance/evolution]
Terms in Software Re-engineering
• Program Restructuring
It is a process to re-structure and re-construct the existing
software. It is all about re-arranging the source code, either in
same programming language or from one programming
language to a different one. Restructuring can have either
source code-restructuring and data-restructuring or both.
Re-structuring does not impact the functionality of the
software but enhance reliability and maintainability. Program
components, which cause errors very frequently can be
changed, or updated with re-structuring.
The dependability of software on obsolete hardware platform
can be removed via re-structuring.
Presenter: Thomas [Introduction to Software maintenance/evolution]
Terms in Software Re-engineering
• Forward Engineering also known as reclamation or
renovation
Forward engineering is a process of obtaining desired
software from the specifications in hand which were
brought down by means of reverse engineering. It assumes
that there was some software engineering already done in
the past.
Forward engineering is same as software engineering
process with only one difference – it is carried out always
after reverse engineering.
Presenter: Thomas [Introduction to Software maintenance/evolution]
Terms in Software Re-engineering
• Forward Engineering also known as reclamation or
renovation
It is the traditional process of moving from high-level
abstractions and logical, implementation-independent designs
to the physical implementation of a system
System
specification
Design and
implementation
Ne w
system
Forward engineering
System specification: Program specification from reverse
Engineering
Existing
Understanding and
Re-engineered
Design
and
Implementation:
Forward
Engineering
software system
transformation
system
New system: Reengineered system
Software re-engineering
Presenter: Thomas [Introduction to Software maintenance/evolution]
Software Re-engineering
• Restructuring or rewriting part or all of a system without
changing its functionality
• Software re-engineering is concerned with taking existing
legacy systems and re-implementing them to make them more
maintainable.
Applicable when some (but not all) subsystems of a larger
system require frequent maintenance
Reengineering involves putting in the effort to make it easier
to maintain
The reengineered system may also be restructured and should
be redocumented
Presenter: Thomas [Introduction to Software maintenance/evolution]
Software Re-engineering
• When ?
When system changes are confined to one subsystem, the
subsystem needs to be reengineered
When hardware or software support becomes obsolete
When tools to support restructuring are readily available
Presenter: Thomas [Introduction to Software maintenance/evolution]
The Software Re-engineering Process
Program
documentation
Original
program
Modularised
program
Original data
Reverse
engineering
Program
modularisation
Source code
translation
Data
reengineering
Program
structure
improvement
Structured
program
Reengineered
data
Presenter: Thomas [Introduction to Software maintenance/evolution]
Advantages of Software Re-engineering
• Reduced risk
There is a high risk in new software development. There may
be development problems, staffing problems and specification
problems.
• Reduced cost
The cost of re-engineering is often significantly less than the
costs of developing new software.
Presenter: Thomas [Introduction to Software maintenance/evolution]
Software Maintenance Models
•
•
•
•
•
•
•
A task-oriented software maintenance model
Quick-fix Model
Iterative Enhancement Model Analysis
Reuse oriented Model
Boehm’s Model
Taute Maintenance Model
An iterative development process
Presenter: Thomas [Introduction to Software maintenance/evolution]
Software Maintenance Models
• A task-oriented
maintenance model
 defines how
various tasks in a
chain are to be
performed in the
context of the
maintenance
objectives and
constraints of the
maintenance project
• More on task
oriented model
Presenter: Thomas [Introduction to Software maintenance/evolution]
Software Maintenance Models
• Quick-fix Model
This is basically an adhoc approach to maintaining software.
It is a firefighting approach, waiting for the problem to occur
and then trying to fix it as quickly as possible.

For more onQuick-fix model
Presenter: Thomas [Introduction to Software maintenance/evolution]
Software Maintenance Models
The three stage
cycle of iterative
enhancement
• Iterative Enhancement Model
Analysis
Characterization of proposed modifications
Redesign and implementation
Presenter: Thomas [Introduction to Software maintenance/evolution]
Software Maintenance Models
• Reuse Oriented Model
This has four steps
1. Identification of the parts of the old system that are
candidates for reuse.
2. Understanding these system parts.
3. Modification of the old system parts appropriate to the
new requirements.
4. Integration of the modified parts into the new system.
Presenter: Thomas [Introduction to Software maintenance/evolution]
Software Maintenance Models
• Reuse Oriented Model
• For more on reuse model
Presenter: Thomas [Introduction to Software maintenance/evolution]
Software Maintenance Models
• Boehm’s Model
Boehm proposed a model for the maintenance process based
upon the economic models and principles.
Boehm represent the maintenance process as a closed loop
cycle.
Presenter: Thomas [Introduction to Software maintenance/evolution]
Software Maintenance Models
• Taute Maintenance Model
It is a typical maintenance model and has eight phases in
cycle fashion.
Phases
1. Change request phase
2. Estimate phase
3. Schedule phase
4. Programming phase
5. Test phase
6. Documentation phase
7. Release phase
8. Operation phase
Presenter: Thomas [Introduction to Software maintenance/evolution]
Distribution of Maintenance Effort
Presenter: Thomas [Introduction to Software maintenance/evolution]