Software maintenance includes correcting errors, enhancing capabilities, removing outdated features, and optimizing performance. It refers to any work done on software after it begins operating. Maintenance typically spans 20 years and includes corrective, adaptive, perfective, and preventive activities. Challenges to maintenance include programs written in isolation without documentation, changes made by people unfamiliar with the code, and lack of design for change. Effective maintenance requires understanding programs, testing modified code, budgeting resources, and configuration management to control and document changes over time.

1. Software Maintenance
 Software maintenance includes error corrections,
enhancement of capabilities, deletion of obsolete capabilities
and optimization
 Any work done to change the software after it is in operation is
considered to be maintenance work
 Maintenance may span for 20 years
Categories of Maintenance
Corrective Maintenance
 Modifications initiated by defects
 Design error, logic error and coding error defects
 Design errors due to incorrect, incomplete or
misunderstood change request
 Faulty logic flow and incomplete test data
 Data processing errors
 Emergency fixes like patching come to the rescue in
case of system failure
 Patching causes ripple effect(change in one part of
the system may cause unpredictable change in other
parts)
Adaptive Maintenance
 Modifications to match changes in environment
 Business rules, govt policies and work patterns
 Changes in hardware, software platform-compiler
and operating system
Perfective Maintenance
 Improving efficiency and performance
 Enhancement of existing system functionality
 Making product cleaner structured and better
documented

2. Other Types of Maintenance
 Preventive Maintenance: to correct long term
effects of corrective, adaptive and perfective
changes over time
 Making program easier to understand
 Includes code restructuring, code optimization and
documentation updating
 Confined to Organization
Problems
During
Maintenance
 Program written by other person in isolation
 Program changed by a person who did not
understand it properly
 Program listings are not structured
 Maintained by persons who are not original authors
contributing to ripple effect
 Some problems become clear when system is in use
 Systems are not designed for change
Solutions to
Maintenance
Problems
 Budget and effort Allocation: More time and
resources to be invested in design of more
maintainable systems
 Complete Replacement of System: IF maintaining
cost = developing cost

3.  Maintenance of existing system if replacement not
possible
Phases of
Maintenance
Process
 Phase 1-Program Understanding: It is based on the
complexity, documentation and self-descriptiveness
of the program
 Phase 2- Generating Maintenance Proposal: It is
affected by extensibility (it is the measure of the
extent to which program can support extensions)
 Phase 3- Account for Ripple Effect: Stability of
system is affected by Ripple effect. Stability is
defined as the resistance to amplification of changes
 Phase 4- Modified Program Testing: Program
testability is defined as measure of effort required
to adequately test program according to well
defined testing criterion
Maintenance Models
Quick-Fix Model
 Ad hoc approach to maintaining software
 Fix without detailed analysis for long term
effect
 No or little documentation
 Done due to pressure of deadlines and
for quick fixes
Iterative EnhancementModel

4.  Based on philosophy that changes in
software system throughout its lifetime
are iterative process
 Requires complete documentation
 Done in three stages- 1.Analysis
2.Characterization
of proposed modification
3. Redesign and
Implementation
 Supports code Reuse
 In first iteration problem is identified and
in next iteration it is addressed
 Problem is the full documentation is not
always available
Reuse Oriented Model
It involves reuse of old system and steps are
1. Identify parts of old system that can be
reused
2. Understand these parts
3. Modify appropriate to new requirements
4. Integration of modified parts
Boehm’s Model
 Based on economic models and principles
 Maintenance is represented as a closed
loop cycle
 Maintenance is driven by Manager

5. Taute MaintenanceModel
It consists of 8 phases which are described
below
 Change request Phase: Maintenance
team gets request which is then
identified and a unique number assigned
 Estimate Phase: Devoted to have
reasonable estimate of time and effort
required
 Schedule Phase: Identify the change
requests for next schedule
 Programming Phase: source code
modified to implement change
 Test Phase: Old and new test cases are
made. Regression Testing is done
 Documentation Phase: System and User
documents are updated to main co-
relation

6.  Release Phase: Software product
delivered and acceptance testing is
carried out
 Operation Phase: Software placed under
normal Operation
Estimation
of
Maintenance
Costs
Belady And Lehman Model
 Effort and cost can increase
exponentially if poor software
development approach is used.
 M = P + Ke(c-d)
M: Total Effort Expended
P : Productivity Effort in Design,
Coding and Testing (Person-Months)
K: Constant
c: Complexity measure because
of bad design and documentation
d: Degree to which maintenance
team is familiar to software
Boehm Model
 ACT stands for Annual Change
Traffic
 It is defined as “The fraction of
Software Product source
instructions which undergo change

7. during a year either through
addition, deletion or modification
 ACT = (KLOCadded
+KLOCdeleted)/KLOCtotal
 (Annual Maintenance Effort) AME =
ACT*SDE*EAF
 SDE: Software Development Effort
in person-months
 EAF: Effort Adjustment Factor
Regression
Testing
Small changes in one part of system may have subtle
undesired effect in other unrelated parts
 Regression testing is the process of retesting the
modified parts of the software and ensuring that no
new errors have been introduced into the previously
tested code
 It increases confidence in program correctness,
located errors, preserve quality and ensure software
continued operation
 Make use of existing test suites
 Retest affected components that have been
modified
 Budget gives no time for regression testing
 Performed many times in software lifetime and
mainly in crisis situation
Selective Retest Techniques
 Better than retest-all technique

8.  Partition existing test suite containing
reusable, retestable and obsolete test cases
 Obsolete test case specify incorrect input-
output relation(SpecificationObsolete) or no
longer exercise program
components(Coverage-Obsolete)
 Three categories of Selective Retest
Techniques are:
1. Coverage Technique:Locate coverable
program components that have been
modified
2. MinimizationTechnique:Select minimal
set of test cases
3. Safe Techniques:Select every test case
 Categories in which techniques are classified
are:
Inclusiveness: Extent of exposing fault
Precision: Ability to avoidchoosing test case
that will not cause errors
Efficiency: Measures computationalcost
Generality:Ability to handleDiverse language
Reverse
Engineering
 Process to find difficult, unknown and hidden
information about software
 Recover information from existing code or
documentation

9.  Used in program comprehension, redocumentation,
recovery of design approach, identifying reusable
components and components that need
restructuring, high level description of system
 Divided into various classes given below
 Mapping from application domain to program
domain
 Mapping between concrete and abstract level
 Rediscovering high level structure
 Missing link between program and semantics
 Extract Reusable component
Levels of Reverse
Engineering
 Redocumentation: Recreation of semantically
equivalent representation with same abstraction
 To create alternative view and hierarchical data flow
 Improve Documentation
 Generate documentation for newly generated
program
 Design Recovery: Identify and Extract higher level
abstraction from source code
 To develop non-identical applications
Componentsof Reverse
Engineering Tool
 Restructurer detects poorly structured code
fragments
 Cross reference lists places where variable is defined
 Static analyzer detects anomalous constructs
 The text editor and simple tools
RIGI
 Interactive graphical editor

10.  Extract system components and relationship from
source code
 Create Subsystem from flow graph using Graph
Editor
 Evaluating subsystem for cohesion and coupling and
iterating until satisfactory subsystem have been
created
Refine language Tools
 Family of Interactive, extensible workbenches for
analyzing and reengineering code in programming
languages
 Customizable to any programming language
 Interactive source code navigation
 Generation of structure charts
 Online viewing and printing of reports
 Export design information to forward-engineering
CASE tools
Software
RE-Engineering
 Concerned with taking existing legacy(old systems)
systems and re-implementing them to make them
more maintainable
 Redocumented, Restructured
 Translated to modern programming language
 Migrate to new Platform(client-server)
Source Code Translation
 Needed for:
 Hardware platform Update
 Staff Skill shortage

11.  Organizational Policy Changes
 REFINE system is powerful tool for this task
 It recognizes patterns in source code
Program Restructuring
 Done to change form without changing semantics
 Some techniques are:
1.Control Flow Driven restructuring: imposition of
clear control structure within source code
2.Efficiency Driven: Restructuring a function like
changing IF-ELSE to Switch
3,Adaption Driven: Changing coding style to adapt
program to a new programming language
Configurati
on
Management
 Software is configuration of software components
released in form of executable codes
 If source code of software is modified without effect
on executable equivalent then exact representation
may not exist
 The process by which software maintenance and
development is controlled is called configuration
management
 It is concerned with development of procedures and
standards for cost effective managing and
controlling changes in an evolving software system

12. ConfigurationManagement
Activities
 Divided into 4 parts:
1. Identification of Component and Changes
2. Control of way by which changes are made
3. Auditing Changes
4. Status accounting- recording and documenting
activities taken place
 Document Required:-
1. Project Plan
2. SRS
3. SDD(Software Design Description)
4. Test plans/cases
5. User Manuals
Software versions
 Two types of versions will be there namely:
revisions(replace) and variations (variety)
 Version Control Tools: It helps to manage multiple
versions of file. It comprises of:
 Name of each source code component (variations
and revisions)
 Versions of various compilers and linkers used
 Name of software staff who constructed component
 Date and time it was constructed
Change Control Process
 Change request form is used to record
recommendations regarding the change
 Recommendations include: Proposed change,
Estimated costs and how to implement change
 Submitted to CCA(Change Control Authority)

13.  Revised software is revalidated by SQA(Software
Quality Assurance) team to ensure that change has
not adversely affected other parts of system
Documenta
tion
 Written record of facts about software system
 Used to convey purpose, content and clarity of
software system.
 User Documentation: Description of functions of
system without reference to how functions are
implemented
 Like System Overview, Installation Guide, Beginner’s
Guide, Reference Guide
 System Documentation: It includes SRS,
implementation, System test plan and Acceptance
Test Plan
 Three levels of Documentation:
1. User Manual: What system does without going
into details
2. Operator’s Manual: How to use system and
how to recover from faults
3. Maintenance manual: Functional specification,
design , code listing and test data results