What is Software Maintenance?

Introduction

Software maintenance is a critical aspect of the software lifecycle. While the term
"maintenance" might seem unusual when applied to software, as software doesn’t wear out
like physical objects, it encompasses a range of activities performed to ensure the software
remains useful and functional over time. Maintenance involves correcting errors, enhancing
capabilities, removing obsolete functions, and optimizing performance. Essentially, any work
done to change software after it is operational is considered maintenance, aiming to preserve
and enhance the software's value by expanding its customer base, meeting new requirements,
improving usability, and incorporating newer technology. Unlike development, which may
take 1-2 years, maintenance can span up to 20 years.

Categories of Software Maintenance

Software maintenance can be divided into four main categories:

1. Corrective Maintenance:
o Definition: Modifications initiated by defects in the software.
o Sources of Defects: Design errors, logic errors, and coding errors.
 Design Errors: Changes that are incorrect, incomplete, or
misunderstood.
 Logic Errors: Invalid tests and conclusions, faulty logic flow.
 Coding Errors: Incorrect implementation of detailed logic design.
o Actions: Restoring operation after system failure, often through emergency
fixes or "patching."
o Challenges: Patching can increase program complexity and cause unforeseen
ripple effects, affecting other parts of the program unpredictably.
2. Adaptive Maintenance:
o Definition: Modifying software to match changes in the environment (e.g.,
business rules, government policies, hardware/software platforms).
o Examples: Moving software to a different hardware or software platform,
adapting to policy changes like the introduction of the Euro in banking
systems.
o Purpose: Ensures that the software continues to function correctly in a
changing environment.
3. Perfective Maintenance:
o Definition: Enhancements to improve processing efficiency, performance, or
software restructuring to improve changeability.
o Examples: Adding new functionalities, improving computational efficiency,
such as providing a new data entry module or message handling facility.
o Outcome: Making the product better, faster, smaller, better documented, and
cleaner structured.
4. Other Types of Maintenance (Preventive Maintenance):
o Definition: Initiated to reduce software complexity and facilitate future
maintenance.
o Activities: Code restructuring, code optimization, and documentation
updating.
 o Rationale: Prevents the software from becoming overly complex and difficult
to maintain, ensuring future maintenance is easier and more efficient.
o Challenges: This type of maintenance is often internal and may not receive
external requests, hence less frequent.

The Maintenance Process in Software Engineering

Introduction

Software maintenance is a critical activity that ensures the continued functionality,

performance, and relevance of software after its initial deployment. The process involves a
series of steps that maintenance personnel must follow to modify software effectively. This
includes understanding the program, making necessary changes, accounting for ripple effects,
and thoroughly testing the modified software. The maintenance process can be broadly
divided into four phases: program understanding, generating maintenance proposals,
accounting for ripple effects, and testing the modified program.

Phases of the Maintenance Process

 1. Program Understanding
o Objective: To analyze and comprehend the software to be modified.
o Key Attributes:
 Complexity: Measures the effort required to understand the program,
often based on control or data flow.
 Documentation: Quality and completeness of the program
documentation.
 Self-Descriptiveness: How clear and easy the program is to read,
understand, and use.
o Importance: Understanding the software thoroughly is essential for making
accurate and effective modifications.
2. Generating Particular Maintenance Proposal
o Objective: To create a specific proposal for implementing the maintenance
objectives.
o Key Attributes:
 Extensibility: The extent to which the program can support extensions
and new functionalities.
o Process: Requires a clear understanding of both the maintenance objectives
and the software to be modified. This phase involves identifying the exact
changes needed to correct errors, add new capabilities, delete obsolete
features, or optimize performance.
3. Ripple Effect
o Objective: To account for all potential impacts of the proposed modifications
on other parts of the program.
o Key Attributes:
 Stability: The program’s resistance to the amplification of changes.
o Considerations:
 Logical/Functional Effects: Changes may affect the logic and
functionality of the program.
 Performance Effects: Modifications might impact the program’s
performance.
o Importance: Ensuring that changes do not introduce new errors or negatively
impact other parts of the software is crucial for maintaining program integrity.
4. Modified Program Testing
o Objective: To ensure that the modified program maintains or improves its
reliability and functionality.
o Key Attributes:
 Testability: The effort required to adequately test the program.
o Process: Employing cost-effective testing techniques to verify that
modifications meet the required criteria without degrading the software’s
performance or introducing new issues.
o Importance: Testing confirms that the modifications achieve the desired
objectives and that the software remains stable and reliable.

Maintainability
  Definition: Maintainability is the ease with which software can be understood,
corrected, adapted, and/or enhanced.
 Key Factors:
o Understandability: Directly impacts maintainability; the easier the program is
to understand, the easier it is to maintain.
o Attributes Contribution: Complexity, documentation, self-descriptiveness,
extensibility, stability, and testability all contribute to overall maintainability.
 Qualitative Definition: Maintainability can be defined as the ease with which
software can be modified to correct faults, improve performance, or adapt to a
changed environment.

Taute Maintenance Model

Introduction

The Taute Maintenance Model, developed by B.J. Taute in 1983, provides a structured
approach to software maintenance. It is widely regarded for its simplicity and effectiveness.
The model consists of eight phases, organized in a cyclic fashion, to address various
maintenance activities such as corrective, adaptive, perfective, and preventive maintenance.

Phases of the Taute Maintenance Model

1. Change Request Phase:

 o Objective: To initiate the maintenance process.
o Process:
 The maintenance team receives a formal change request from the
client.
 The request is categorized (corrective, adaptive, perfective, or
preventive).
 A unique identification number is assigned to the request.
o Importance: Ensures that each request is tracked and managed systematically.
2. Estimate Phase:
o Objective: To estimate the resources required for the change.
o Process:
 Estimation of time and effort needed for the change.
 Impact analysis on the existing system to minimize ripple effects.
o Challenges:
 Making accurate estimates is difficult but essential for planning.
o Importance: Provides a basis for scheduling and resource allocation.
3. Schedule Phase:
o Objective: To plan the implementation of the change.
o Process:
 Identifying change requests for the next scheduled release.
 Preparing necessary planning documents.
o Importance: Ensures that changes are organized and prioritized for efficient
execution.
4. Programming Phase:
o Objective: To implement the requested change.
o Process:
 Modifying the source code to incorporate the change.
 Updating relevant documents such as design documents and manuals.
 Producing a test version of the modified source code.
o Importance: Ensures that changes are correctly implemented and
documented.
5. Test Phase:
o Objective: To verify the correctness of the modification.
o Process:
 Performing regression testing to ensure that the modification does not
introduce new issues.
 Using existing test cases and designing new ones if necessary.
o Importance: Ensures that the software remains reliable and functional after
changes.
6. Documentation Phase:
o Objective: To update system and user documentation.
o Process:
 Preparing or updating documents based on the changes made.
o Importance: Maintains consistency between the code and its documentation,
facilitating future maintenance.
7. Release Phase:
o Objective: To deliver the updated software to the customer.
o Process:
 Delivering the new software product along with updated
documentation.
  Conducting acceptance testing with the users.
o Importance: Ensures that the customer receives a fully functional and
documented product.
8. Operation Phase:
o Objective: To place the software under normal operation.
o Process:
 Deploying the software for regular use.
 Initiating a new change request process if additional problems or
enhancement needs arise.
o Importance: Ensures that the software continues to meet user needs and can
be further maintained as required.

Reverse Engineering

Introduction

Reverse Engineering is a process used to uncover difficult, unknown, and hidden information
about a software system. It has become increasingly important due to the lack of proper
documentation in many software products, the unstructured nature of some systems, and the
degradation of structure through multiple maintenance efforts. Effective maintenance
activities require a comprehensive understanding of the software system, which can be
facilitated by reverse engineering.

Scope and Tasks

The primary purpose of reverse engineering is to recover information from existing code or
any intermediate documents. It includes any activity that requires program understanding at
any level. The tasks involved in reverse engineering can vary significantly depending on the
goals of the extracted information. Some key areas where reverse engineering is applicable
include:

1. Program Comprehension: Understanding the software to facilitate maintenance and

enhancements.
2. Redocumentation and Document Generation: Creating or updating documentation
to reflect the current state of the software.
3. Recovery of Design Approach and Details: Understanding the design at any level of
abstraction.
4. Identifying Reusable Components: Finding components within the software that
can be reused in other systems.
5. Identifying Components for Restructuring: Detecting parts of the software that
need restructuring for better performance or maintainability.
6. Recovering Business Rules: Extracting the business logic embedded in the software.
7. Understanding High-Level System Descriptions: Gaining a high-level overview of
the system for strategic planning and decision-making.

Reverse engineering tasks can be grouped into several classes, each focusing on different
aspects of understanding and modifying software systems:
 1. Mapping Between Application and Program Domains:
o Objective: Reconstruct the mapping from the application domain (problem
domain) to the program domain (implementation domain).
o Process: Analyze the software to understand how it represents real-world
problems and solutions.
2. Mapping Between Concrete and Abstract Levels:
o Objective: Move backward from concrete implementation details to high-
level abstract representations.
o Process: Extract high-level design and architecture from detailed code and
implementation artifacts.
3. Rediscovering High-Level Structures:
o Objective: Detect the original purpose and high-level structure of the
program.
o Process: Analyze the software to identify its original goals and structure,
which may have been lost or altered over time due to maintenance activities.
4. Finding Missing Links Between Program Syntax and Semantics:
o Objective: Determine the semantics of a program from its syntax.
o Process: Analyze the syntax of the code to infer its meaning and intended
behavior, especially important in systems with lost original semantics or in
object-oriented languages lacking a strong formal basis.
5. Extracting Reusable Components:
o Objective: Identify and extract reusable components to increase productivity
and improve product quality.
o Process: Use reverse engineering tools and methods to access and extract
components that can be reused in other projects.

Reverse Engineering Tools

Introduction: Reverse engineering involves analyzing software to extract knowledge or

design information from the application. Performing this manually can be time-consuming
and labor-intensive, making the process costly and impractical. Reverse engineering tools
assist in this process by automating various tasks, thereby making the process more efficient
and less expensive. Rugaber identifies four basic components of a reverse engineering tool:

1. The Restructurer: Detects poorly structured code fragments and replaces them with
equivalent structured code.
2. The Cross Referencer: Lists the places where each variable is defined and used.
3. The Static Analyzer: Detects anomalous constructs such as uninitialized variables
and dead code.
4. The Text Editor and Other Simple Tools: Support browsing and editing of the
source code.

These tools may also include graphical user interfaces and other visualization tools to
enhance usability.

Rigi System: The Rigi System is an interactive graph editor that provides a graphical
representation of software systems. It follows several phases in reverse engineering:

1. Extraction Phase:
 o Automatic Extraction: This phase involves parsing the source code to extract
system components and relationships, which are then stored in a repository.
2. Creating Subsystems:
o Subsystem Hierarchies: Using a graph editor, subsystem hierarchies are built
on top of the initial call graphs. Subsystems are grouped into composite
subsystems, and these hierarchies can be documented as views, providing
snapshots of various reverse engineering states.
o Computing Interfaces: Interfaces between subsystems are computed by
analyzing and propagating the dependencies extracted from the source code.
3. Evaluating Subsystems:
o Cohesion and Coupling: Subsystems are evaluated for cohesion and
coupling, iterating until satisfactory subsystems are created. This helps in
identifying hot-spots for maintenance and candidate modules for
reengineering.

Limitations:

 Rigi does not model the dynamic aspects of software systems.

 Its performance for object-oriented languages is uncertain.

Refine Language Tools: Refine Language Tools, marketed by Reasoning Systems, Inc., are
interactive, extensible workbenches for analyzing and reengineering code in languages such
as Ada, C, COBOL, and FORTRAN. These tools are customizable to suit any particular
version of the programming language and come with a fully documented reengineering API
for building customizations. Key features include:

1. Interactive Source Code Navigation: Allows users to navigate through the source
code interactively.
2. Report Generation: Generates set/use reports, structure charts, and identifier
definition reports.
3. Viewing and Printing Reports: Provides online viewing and Postscript printing of
all reports.
4. Consistent Interface and Format: Ensures a consistent graphical user interface and
standardized report format.
5. Exporting Design Information: Enables exporting design information to forward-
engineering CASE tools.

Software Re-Engineering

Introduction

Software re-engineering involves taking existing legacy systems and re-implementing them
to enhance maintainability. This process is necessary as legacy systems, which are old
systems that must still be maintained, can become unmanageable and expensive over time
due to constant enhancements, bug fixes, and piecemeal solutions. Legacy systems often lack
proper documentation, may be poorly structured, and were not designed for change, making
them difficult to understand and maintain. Re-engineering addresses these issues by
transforming the system to improve its structure, documentation, and adaptability to new
technologies.

Distinction Between Re-Engineering and New Software Development

Re-engineering differs from new software development primarily in its starting point. In new
software development, the process begins with a system specification, followed by design
and implementation to create a new system. In contrast, re-engineering starts with an existing
software system, which acts as the specification for the re-engineered system. This approach
leverages the existing system as a foundation for improvement, rather than building from
scratch.

Factors Affecting Re-Engineering Costs

The cost of re-engineering depends on several factors, including:

 The extent of work required

 The quality of the existing software
 The availability of tool support
 The extent of data conversion needed
 The availability of expert staff

Suggestions for Modifying Legacy Code

To effectively modify legacy code, consider the following suggestions:

 Study the code thoroughly before making changes.

 Focus on overall control flow rather than individual coding details.
 Heavily comment on internal code to clarify functionality.
 Create cross-references and build symbol tables for easier navigation.
 Use your own variables, constants, and declarations to localize the impact of changes.
 Maintain detailed documentation of all maintenance activities.
 Apply modern design techniques to improve structure and readability.

Source Code Translation

Source code translation involves converting the code from one programming language to
another. This can be done manually or using automation tools. Common reasons for source
code translation include:

1. Hardware Platform Update: The organization may switch to a new hardware

platform for which compilers for the original language are unavailable.
2. Staff Skill Shortages: There may be a lack of maintenance staff skilled in the original
language, especially if it is outdated or non-standard.
3. Organizational Policy Changes: The organization may decide to standardize on a
particular language to reduce support costs.
Translation can be performed using sophisticated tools like the REFINE system, which
incorporates pattern matching and program transformation capabilities to automate parts of
the translation process.

Program Restructuring

Program restructuring involves transforming the system's representational form without

altering its semantics or functionality. The goal is to make the program more readable,
maintainable, and efficient. There are several types of restructuring techniques:

1. Control Flow Driven Restructuring: This technique imposes a clear control

structure within the source code, making it more readable and easier to understand. It
can be inter-modular or intra-modular.

Example:

pascal
Copy code
IF Score >= 75 THEN Grade := 'A'
ELSE IF Score >= 60 THEN Grade := 'B'
ELSE IF Score >= 50 THEN Grade := 'C'
ELSE IF Score >= 40 THEN Grade := 'D'
ELSE Grade := 'F'

Restructured using a CASE statement:

pascal
Copy code
CASE Score OF
75..100: Grade := 'A';
60..74: Grade := 'B';
50..59: Grade := 'C';
40..49: Grade := 'D';
ELSE Grade := 'F'
END;

2. Efficiency Driven Restructuring: This technique involves restructuring functions or

algorithms to improve their efficiency. For example, replacing an IF-THEN-ELSE-IF
construct with a CASE construct to reduce the number of boolean evaluations.
3. Adaption-Driven Restructuring: This technique adapts the program to a new
programming language or operating environment. For example, transforming
imperative code in PASCAL into functional code in LISP or adapting a program to a
parallel processing environment.

Regression Testing

Introduction: Software inevitably changes, regardless of how well it is initially written and
designed. To ensure that these changes work correctly and do not negatively impact other
parts of the software, retesting is essential. This is necessary because small changes in one
part of a software can have subtle, undesired effects in other seemingly unrelated parts.
Definition: Regression testing is the process of retesting modified parts of the software and
ensuring that no new errors have been introduced into previously tested code. It involves
testing both the modified code and other parts of the program that may be affected by the
changes.

Purpose: Regression testing serves several critical purposes:

1. Increase Confidence: It increases confidence in the correctness of the modified

program.
2. Locate Errors: It helps locate errors in the modified program.
3. Preserve Quality and Reliability: It helps preserve the quality and reliability of the
software.
4. Ensure Continued Operation: It ensures the software's continued operation.

Process:

1. Constructing a Test Plan: Similar to development testing, regression testing

involves constructing a test plan that describes how the software should be tested after
modifications.
2. Designing Test Cases: Test cases are designed to meet the requirements of the test
plan. These test cases include those that test the new changes and those that test the
unmodified parts of the software to ensure they still function correctly.
3. Running Test Cases: The suite of test cases is executed to check for new errors in the
modified code and to verify that the existing functionalities are not broken.

Importance:

 Confidence in Modifications: By verifying that modifications do not introduce new

errors, developers can be more confident in their changes.
 Error Detection: Regression testing helps in the early detection of errors introduced
during maintenance and enhancement.
 Software Quality: Consistent regression testing helps maintain the overall quality of
the software, ensuring that both new and existing functionalities work as intended.
 Reliability: Ensures that the software remains reliable over time, even after multiple
modifications.

Challenges:

 Time-Consuming: Regression testing can be time-consuming, especially for large

systems with extensive test suites.
 Resource-Intensive: It requires significant resources, including skilled testers and
automated testing tools.
 Test Maintenance: The test cases themselves need to be maintained and updated
regularly to reflect changes in the software.
Configuration Management

Introduction: Configuration management involves managing and controlling changes to

software components throughout the software development and maintenance lifecycle. It
ensures that changes are made in a controlled manner to maintain the integrity and reliability
of the software system.

Software Components: Software components are released in the form of executable code,
while the supplier organization retains the source code. The source code represents an
executable equivalent, but changes to the source code may not always affect the executable
versions in use. Without strict controls, the source code that exactly represents a particular
executable version may be lost.

Configuration Management in Development and Maintenance: Configuration

management differs in the development and maintenance phases due to different
environments. In development, changes are made in a controlled environment, whereas in
maintenance, changes are made in a live system used by a large user base. Therefore,
configuration management in maintenance is concerned with developing procedures and
standards to effectively manage and control changes in an evolving software system.

Configuration Management Activities: Configuration management activities are divided

into four broad categories:

1. Identification: Identifying software components and changes.

2. Control: Controlling the way changes are made.
3. Auditing: Auditing changes to ensure compliance with standards and procedures.
4. Status Accounting: Recording and documenting all activities that have taken place.

Required Documents: Several documents are required for configuration management

activities, including:

 Project plan
 Software requirements specification document
 Software design description document
 Source code listing
 Test plans/procedures/test cases
 User manuals

Recording Changes: All components of the system's configuration, along with their
relationships and dependencies, are recorded. Any change, whether it is an addition, deletion,
or modification, must be recorded, and its impact on the rest of the system's components
should be checked. After a change is made, a new configuration is recorded.

Responsibilities and Audits: It is essential to assign responsibilities for every procedure and
process, and management must conduct audits to ensure these responsibilities are carried out
effectively. Audits help in maintaining the integrity and reliability of the software system.
Software Versions

Introduction: During software maintenance, there are typically multiple versions of the
software system and its components. Managing these versions is crucial for effective
maintenance and evolution of the software.

Types of Versions:

1. Revisions: These involve replacing an existing version with a new one. Revisions are
common during maintenance when bugs are fixed or new features are added.
2. Variations: These refer to different varieties or versions of a component that exist
concurrently. Variations can occur due to customization or different configurations.

Version Control: Version control tools are essential for managing multiple versions of
software components. These tools keep a detailed record of every version of the software,
including:

 Names of source code components, including variations and revisions

 Versions of compilers and linkers used
 Names of software staff who constructed the component
 Dates and times of construction

Benefits of Version Control:

1. Tracking Changes: Version control allows tracking changes made to the software
over time, which is crucial for understanding the evolution of the software.
2. Reverting Changes: It enables reverting to previous versions of the software in case
new changes introduce unexpected issues.
3. Collaboration: Version control facilitates collaboration among team members by
providing a centralized repository for managing code changes.
4. Auditing and Compliance: It helps in auditing changes and ensuring compliance
with organizational standards and policies.
5. Branching and Merging: Version control systems often support branching and
merging, allowing for parallel development efforts and later integration of changes.
Change Control Process

Introduction: The change control process is a systematic approach to managing changes to

software and associated documentation. It ensures that changes are assessed, approved,
implemented, and validated in a controlled manner to minimize risks and maintain the
integrity of the software system.

Key Steps in the Change Control Process:

1. Change Request Form: When a change is proposed, a change request form is filled
out. This form includes details such as the requester, proposed change, components
affected, estimated costs, and change assessment.
2. Submission to Change Control Authority (CCA): The change request form is
submitted to the Change Control Authority (CCA), which is responsible for reviewing
and approving changes. The CCA evaluates the change based on its impact, cost, and
feasibility.
 3. Change Approval: If the CCA approves the change, it is implemented in the
software. The change may involve modifying code, updating documentation, or
making configuration changes.
4. Revalidation: After the change is implemented, the Software Quality Assurance
(SQA) team revalidates the software to ensure that the change has not introduced any
new issues or affected other parts of the software adversely.
5. Incorporation into New Version: Once the change is validated, it is incorporated
into a new version of the software. The updated software is then handed over to the
software configuration team for distribution and deployment.

Benefits of Change Control Process:

 Risk Management: The change control process helps manage risks associated with
software changes by ensuring that changes are carefully assessed and validated before
implementation.
 Consistency: It ensures that changes are applied consistently and according to
established procedures, reducing the likelihood of errors or inconsistencies.
 Traceability: The process provides a clear audit trail of all changes, including the
reasons for the change, approvals, and implementation details.
 Compliance: It helps ensure compliance with organizational policies, regulatory
requirements, and quality standards.
 Improved Communication: By documenting and formalizing the change process,
the change control process improves communication among stakeholders involved in
the change management process.