Software Maintenance

Type notes

UNIT 1

Software Maintenance
Process of modifying existing software after it's been deployed to fix defects,
improve performance, or enhance functionality.
Why We Need Software Maintenance:

Bug Fixes: Software is complex, and errors (bugs) inevitably arise. Fixing
these bugs ensures the software works as intended and avoids user
frustration or data loss.

Performance Optimization: Software can become slow or inefficient over

time, especially with increased data or user activity. Maintenance addresses
these issues to maintain optimal performance.

Security Patches: Vulnerabilities can be discovered in software, leaving it

open to attack. Applying security patches proactively helps protect the
software and user data.

Functionality Enhancement: User needs evolve, and new features or

functionalities are often requested. Maintenance allows for adding these
enhancements to improve the software's usefulness.

Adapting to Changing Environment: Software operates within a constantly

changing environment, including operating systems, hardware, and other
software. Maintenance ensures compatibility and smooth integration.

Extending Software Life: By addressing issues and adding new features,

maintenance can extend the lifespan of software, saving the cost and effort of
developing a new system.

Software Maintenance 1
 Benefits of Software Maintenance:

Improved reliability and stability: Reduced errors and increased uptime.

Enhanced performance: Faster execution, better resource utilization.

Enhanced security: Reduced vulnerability to attacks.

Increased user satisfaction: Improved functionality and user experience.

Extended software lifespan: Reduced cost and effort compared to developing

new software.

Classification of Software Changes

To maintain and evolve software, different types of changes are required.
1. Corrective Change

Purpose: Fix defects in the software, such as bugs or errors.

Types of errors:

Design errors: Incorrect changes or misunderstandings during design.

Logic errors: Incorrect implementation, faulty logic, or incomplete testing.

Coding errors: Mistakes in the code, incorrect use of programming logic.

Common issues:

Emergency fixes (patching): Quick fixes done under pressure, which can
cause more problems later by increasing complexity.

Increased complexity: Over time, emergency fixes can lead to "spaghetti

code" (complicated and hard-to-understand code), making the software
harder to maintain.

2. Adaptive Change

Purpose: Modify the software to fit new environments or external changes.

Examples of environment changes:

Business rules: Changes in company policies.

Software Maintenance 2
 Government regulations: New laws or policies that require software
updates.

New hardware or software: Moving the software to a new operating

system, hardware, or updating to new versions of supporting software like
databases.

Common adaptations:

Migrating code: Moving from old to new platforms, like shifting from
sequential processing to parallel processing.

System upgrades: Modifying the software to work with new compilers or

operating systems, improving performance or saving resources.

3. Perfective Change

Purpose: Enhance or expand the software’s functionality based on user

needs.

Why it’s done: As users experiment with the software, they often request new
features or improvements beyond its original design.

Examples:

Feature enhancements: Adding new modules like a data entry system.

Efficiency improvements: Making the software run faster or use

resources more efficiently.

4. Preventive Change

Purpose: Prevent future problems by improving the software’s structure and

maintainability.

Why it’s needed: Over time, multiple corrective and adaptive changes can
lead to structural degradation, making the software harder to maintain.

Common tasks:

Code restructuring: Simplifying the code to make it easier to understand

and maintain.

Code optimization: Improving the code so it runs faster or uses fewer

resources.

Software Maintenance 3
 Documentation updates: Updating system and user documentation after
changes to keep everything aligned with the current state of the software.

Avoiding ripple effects: Sometimes, changes to one part of the software can
unexpectedly affect other parts. Techniques like modularization (dividing the
software into smaller parts) and information hiding (limiting data visibility) can
reduce these risks.

Ongoing Support
Ongoing support involves providing services to address non-programming-related
requests.

It ensures successful communication, training, and provision of business

information to users. Here's a breakdown:

1. Effective Communication

Importance: Communication between maintenance teams and end-users is

crucial for successful software changes.

Customer-intensive: Maintenance is heavily customer-focused because

many changes are driven by user requests.

Customer satisfaction: Resources spent on communication help justify the

changes made by ensuring customers are satisfied.

Software Maintenance 4
 Building rapport: Establishing good relationships improves understanding and
reduces the risk of misinterpreting user requests.

Aligning business and technical decisions: Effective communication ensures

that technical changes do not conflict with business needs, increasing the
likelihood of successful outcomes.

User involvement: Increased involvement of users in the maintenance

process enhances the chances of success and user satisfaction.

Risk of failure: Poor communication can lead to misunderstandings and

software failure.

2. Training of End-Users

Objective: Provide users with the skills and knowledge to use the system
effectively.

Methods of training:

Manuals: Typically provided but may be inadequate or hard to understand.

On-line help and telephone queries: Used when manuals are insufficient.

On-site visits: Can be arranged if remote assistance fails.

Short courses: Formal or informal training sessions to help users deal with
problems.

User group training:

Peer group training through user groups (e.g., for CAD software users).

Users share experiences and learn from each other, forming a symbiotic
relationship.

3. Providing Business Information

Purpose: Help users make informed business decisions by supplying timely

and accurate information.

Examples:

A company planning database enhancements may need information on

costs.

Software Maintenance 5
 With accurate information, the company can decide whether to enhance
the current system or replace it entirely.

Economic Implications of Modifying Software

1. High Proportion of IT Resources on Maintenance

Observation: A significant portion of the IT industry’s resources is devoted to

maintaining legacy systems.

Studies: Multiple studies confirm that a large percentage of resources are

consumed by maintenance, similar to development costs.

2. Costs of Software Maintenance

Research: Maintenance costs vary across industries, ranging from 49%

(pharmaceutical company) to 75% (automobile company).

Expectation: Despite advancements in software engineering methodologies,

maintenance costs have not decreased significantly since the 1970s.

3. Development vs. Maintenance Ratio

Studies Show: The development-to-maintenance ratio remains high across

various sectors, indicating little reduction in costs over time.

4. Types of Maintenance Effort

Lientz and Swanson Study: The following distribution was reported in 487
data processing organizations:

1. Corrective Maintenance: 20% of effort.

2. Adaptive Maintenance: 25% of effort.

3. Perfective Maintenance: 50% of effort.

4. Preventive Maintenance: 5% of effort.

5. Context Variations in Maintenance Costs

Consideration: These percentages can vary depending on:

Application type.

Expertise of maintenance personnel.

Software Maintenance 6
 Quality of accompanying documentation.

Specific environment factors.

6. Feasibility Analysis for Cost Estimation

Approach: Estimating maintenance costs beforehand can help decide whether

to enhance or replace a system.

Cost Estimation Models:

1. Boehm's COCOMO Model: Used to estimate software maintenance costs.

2. COCOMO II Model: An updated version, providing more detailed cost

analysis.

Nomenclature and Image Problems in Software Maintenance

Here's a breakdown of the key points from the text:

1. The Misnomer "Maintenance":

The term "maintenance" is considered inaccurate for software due to its

evolutionary nature.

Traditional maintenance implies fixing deterioration, while software changes

involve adaptation and enhancements.

Corrective changes represent only a small portion of the total maintenance

effort.

2. Alternative Terminology:

Authors propose terms like "software evolution", "post-delivery evolution", and

"support" to better capture the dynamic nature of software development.

Software Evolution: Encompasses all phases, including pre-delivery stages.

Post-Delivery Evolution: Specifically refers to changes after software is in live

use.

3. Negative Image of Software Maintenance:

The term "maintenance" contributes to a perception of software maintenance

as less creative and skilled than development.

Software Maintenance 7
 This perception undervalues the complex work involved in maintaining
software.

4. Consensus and Terminology:

Lack of consensus on software maintenance terminology further exacerbates

the negative image.

Some argue that "maintenance" can be used as long as its meaning is

understood within the software engineering context.

5. Importance and Focus on Maintenance:

Despite the challenges, software maintenance is crucial for keeping systems

operational and meeting evolving user needs.

Increasing industry demands are forcing a greater focus on improving

maintenance practices.

Software Maintenance Framework (SMF)

The (SMF) highlights the complexities and costs associated with software
maintenance due to evolving user needs and other influencing factors.

Components of the Framework

1. User

Definition: Refers to individuals utilizing the system, independent of their role

in development or maintenance.

Modification Requests: Users may request changes for various reasons,

leading to:

Progressive Work: Refining existing functions or introducing new features.

Anti-Regressive Work: Improving program structure, documentation, and

understandability.

Evolution of the System: Software systems tend to evolve post-deployment to

meet users' changing needs.

2. Environment

Software Maintenance 8
 Types of Environments:

Operating Environment: Comprises hardware and software platforms

impacting the system.

Organisational Environment: Influenced by business rules, government

regulations, and market competition.

Operating Environment Factors:

Hardware Innovations: Upgrades may require changes in compilers or

software to ensure compatibility.

Software Innovations: Modifications in operating systems or database

management systems can necessitate updates to existing software.

Organisational Environment Factors:

Change in Policies: Changes in business rules (e.g., VAT) require

corresponding software modifications.

Market Competition: Organizations modify software to gain a competitive

edge, enhancing customer satisfaction and expanding their client base.

3. Maintenance Process

Capturing Change Requirements: Understanding necessary changes can be

challenging; user needs often become clear only during system usage.

Variation in Programming Practice: Different approaches to coding can lead

to inconsistencies and difficulties if guidelines are not followed.

Paradigm Shift: Transitioning to modern programming practices may require

restructuring or rewriting older programs that do not use current techniques.

'Dead' Paradigms: Many systems are built on outdated concepts, limiting their
adaptability to user needs over time.

Error Detection and Correction: All software has residual errors, which
become more costly to fix the later they are found in the lifecycle.

4. Software Product

Dynamic Nature: Software is rarely static; it evolves continuously, influencing

maintenance challenges.

Software Maintenance 9
 Maturity of Application Domain: Well-established applications (e.g., payroll)
typically experience fewer changes than emerging systems (e.g., medical
information).

Quality of Documentation: Outdated or missing documentation complicates

maintenance, as modifications often occur without corresponding updates.

Malleability of Software: The flexible nature of software can lead to

unintended consequences from ad hoc changes.

Inherent Quality: The evolution of software is closely tied to its design and
structure.

5. Maintenance Personnel

Staff Turnover: High turnover can result in maintenance being performed by

those unfamiliar with the original system, complicating understanding.

Comprehension Challenges: A significant portion of maintenance time is

spent understanding existing code, especially if documentation is lacking.

Domain Expertise: Lack of knowledge about the system or application domain

can lead to unintended ripple effects from changes.

Working Practices: The methods used for making changes significantly affect
future maintenance ease. Factors include:

A maintainer's desire for creativity or clever solutions.

Use of undocumented assumptions or design decisions.

Potential solutions to maintenance problems:

1. Budget and Effort Reallocation

Observation: Maintenance often costs as much as new software

development.

Approach: Instead of developing systems that are difficult to maintain, more

resources should be allocated upfront to build maintainable systems.

Key Methods:

Software Maintenance 10
 1. Advanced Requirement Specification Approaches: Using better
requirement methods leads to more clarity and easier maintainability.

2. Design Techniques and Tools: Leveraging advanced design tools and

techniques improves maintainability.

3. Quality Assurance Standards: Adopting standards like ISO 9000 ensures

better quality and maintainability.

4. Maintenance Standards: Utilizing maintenance-focused standards early in

the software lifecycle improves future maintenance efforts.

Supporting Evidence: Only recently have empirical studies (like the FEAST
projects) started to validate the benefits of investing in maintenance during the
development phase.

2. Complete Replacement of the System

Consideration: Although it might seem logical to replace legacy systems if

maintenance costs are as high as new development, this option is risky and
costly.

Challenges:

1. Economic Constraints: Maintenance tasks (corrective and preventive) are

performed incrementally, with relatively smaller costs spread over time,
making it more financially manageable than a complete replacement.

2. Residual Errors in New Systems: New systems are not guaranteed to

work better than old ones, and may introduce new errors or bugs.

3. Knowledge and Information in Old Systems:

Legacy systems contain valuable business knowledge and operational

information.

Old systems serve as a repository of assumptions, paradigms, and

functions that can inform future developments.

Replacing them risks losing this valuable knowledge base, which could
be useful for future projects and avoid “reinventing the wheel.”

Example: A survey by Tamai and Torimitsu found that many organizations

abandoned system replacement due to high costs.

Software Maintenance 11
 3. Enhancement of the Existing System

Challenge: Complete replacement is often not viable due to the cost and risk
involved.

Approach:

Enhancing the current system to evolve with more advanced features and
technologies is a more practical solution.

Existing systems, despite being old, are still valuable assets due to their
embedded technical knowledge and working culture.

Key Goals:

1. Sophisticated User-Driven Functionality: The system must evolve to

meet more complex user needs.

2. Integration of Cutting-Edge Technology: Implementing modern

technologies within the existing system to keep it relevant.

3. System Integration: Allowing the existing system to integrate easily with

other systems in a cost-effective manner.

Techniques & Tools: Methods, tools, and management practices are

necessary to enhance and maintain legacy systems, providing a framework for
achieving long-term value from the system.

Context: This framework addresses the “maintenance crisis” where existing

systems cannot be easily abandoned or replaced but need to evolve.

Maintenance Process Models

The need for maintenance-conscious models has been recognised for some
time but the current situation is that maintenance models are neither so well
developed nor so well understood as models for software development.

Software Maintenance 12
 The generic stages in a maintenance-conscious model (Figure 5.10) compared
with the traditional development model appear similar on the surface but
within the stages there are great differences in emphasis and procedure.

There is more effort required and very different emphases on the early stages,
and conversely less effort required in the later stages, of the maintenance
model as opposed to the development model.

Quick Fix Model: A Band-Aid Approach

Software Maintenance 13
 Also known as the "firefighting" or "hack and patch" model.

It is a reactive approach to software maintenance.

It focuses on immediately resolving urgent issues without a thorough analysis

or planning, prioritizing expediency over long-term sustainability.

How it works:

1. Identify the Issue: A critical problem emerges, disrupting the software's

functionality or causing significant issues.

2. Immediate Solution: The team rapidly implements a temporary fix to address

the immediate problem, aiming to get the system operational as quickly as
possible.

3. Minimal Testing: Limited testing is conducted to ensure the quick fix doesn't
worsen the existing situation but often overlooks potential side effects.

4. Deploy and Repeat: The quick fix is deployed, potentially masking underlying
issues and contributing to a growing technical debt. The cycle repeats with
each new problem, creating a vicious cycle of short-term solutions.

Advantages of the Quick Fix Model:

Immediate Resolution: Offers a rapid solution to urgent problems, preventing

severe business disruptions.

Simplicity: Easy to understand and implement, requiring minimal planning and

documentation.

Cost-Effective (Short Term): Initial implementation is often quick and

inexpensive, especially for smaller issues.

Why is it still used?

Software Maintenance 14
 Pressure to Deliver: Organizations under tight deadlines or facing critical
production issues may prioritize quick fixes to keep operations running.

Lack of Resources: Limited budget, staffing, or expertise can limit the ability
to implement a more structured approach.

Urgency Over Quality: The focus on immediate results can overshadow the
importance of long-term software health.

Long-Term Problems:

Technical Debt: The accumulation of quick fixes creates technical debt,

making future maintenance increasingly difficult and costly.

Code Complexity: Unplanned changes and patches can lead to messy, poorly
documented code, hindering comprehension and further development.

Increased Risk: Unforeseen consequences and side effects from quick fixes
can introduce new vulnerabilities and bugs.

Limited Scalability: The quick fix model is ill-suited for complex systems or
large-scale maintenance projects, leading to unmanageable codebases.

Unstable Software: Constant patches can create a fragile system prone to

unexpected errors and unpredictable behavior.

Loss of Innovation: Reactive maintenance diverts resources from essential

tasks like feature development, innovation, and improvement.

Boehm's Model
1. In 1983 Boehm proposed a model for the maintenance process based upon
economic models and principles.

2. Economic decisions are a major driving force behind many processes.

3. Boehm's thesis was that economic models and principles could not only
improve productivity in maintenance but also help understanding of the
process.

4. Boehm represents the maintenance process as a closed loop cycle.

Software Maintenance 15
 5. He theorize that it is the stage where management decisions are made that
drives the process.

6. In this stage, a set of approved changes is determined by applying particular

strategies and cost-benefit evaluations to a set of proposed changes.

7. The approved changes are accompanied by their own budgets which will
largely determine the extent and type of resource expended.

Osborne's Model
1. Another approach is proposed by Osborne .

2. The difference between this model and the others is that it deals directly with
the reality of the maintenance environment.

3. Where as, other models tend to assume some facet of an ideal situation - the
existence of full documentation.

4. Example-Osborne's model makes allowance for how things are rather than
how we would like them to be.

Software Maintenance 16
 5. The maintenance model is treated as continuous iterations of the software life-
cycle with.

6. at each stage, provision made for maintainability to be built in.

7. If good maintenance features already exist, for example full and formal
specification or complete documentation, all well and good, but if not,
allowance is made for them to be built in.

7. Osborne hypothesises that many technical problems which arise during

maintenance are due to inadequate management communications and control,
and recommends a strategy that includes:

the inclusion of maintenance requirements in the change specification;

a software quality assurance program which establishes quality assurance

requirements;

Software Maintenance 17
 a means of verifying that maintenance goals have been met; performance

review to provide feedback to managers

Iterative Enhancement Model

1. Proposed based on the belief that the implementation of changes to a
software system throughout its lifetime is an iterative process and involves
enhancing such a system in an iterative way.

2. It is similar to the evolutionary development paradigm during pre-installation.

3. Originally proposed as a development model but well suited to maintenance.

4. The motivation for this model was the environment where requirements were
not fully understood and a full system could not be built.

5. Adapted for maintenance, the model assumes complete documentation as it

relies on modification of this as the starting point for each iteration.

6. The model is effectively a three-stage cycle -

Analysis.

Characterization of proposed modifications.

Redesign and implementation

Software Maintenance 18
 The Reuse-Oriented Model
1. This model is based on the principle that maintenance could be viewed as an
activity involving the reuse of existing program components.

2. The reuse model described by Basili has four main steps:

Identification of the parts of the old system that are candidates for reuse,

Understanding these system parts,

Modification of the old system parts appropriate to the new requirements,

Integration of the modified parts into the new system

3. Detailed framework is required for the classification of components and the

possible modifications.

4. With the full reuse model the starting point may be any phase of the life-cycle
- the requirements, the design, the code or the test data - unlike other models.

5. For example, in the quick-fix model, the starting point is always the code.

Aims of Program Comprehension

The ultimate purpose of reading and comprehending programs is to be able

successfully to implement requested changes.

This entails acquiring information about certain aspects of the software

system such as the

Software Maintenance 19
 a. Problem Domain

1. Being able to capture domain knowledge is now considered a far more

important area than

2. In order to effect change or simply to estimate the resource required for a

maintenance task, knowledge of the problem domain in general and the sub-
problems in particular is essential so as to direct maintenance personnel in the
choice of suitable algorithms, methodologies and tools.

3. The selection of personnel with the appropriate level of expertise and skills is
another aspect.

4. Information can be obtained from various sources - the system

documentation, or the program source code.

b. Execution Effect

1. At a high level of abstraction- the maintenance personnel need to know (or be

able to predict) what results the program will produce for a given input without
necessarily knowing which program units contributed to the overall result or
how the result was accomplished.

Software Maintenance 20
 2. At a low level of abstraction - they need to know the results that individual
program units will produce on execution.

3. Knowledge of data flow, control flow and algorithmic patterns can facilitate the
accomplishment of these goals

c. Cause - Effect Relation

1. knowledge of this relation is important in a number of ways -

It allows the maintenance personnel to reason about how components of a

software product interact during execution.

It enables a programmer to predict the scope of a change and any knock-on

effect that may arise from the change.

The cause-effect relation can be used to trace the flow of information through
the program. The point in the program where there is an unusual interruption
of this flow may signal the source of a bug

d. Product-Environment Relation

1. A product is a software system.

2. An environment is the totality of all conditions and influences which act from
outside upon the product

3. It is essential for the maintenance personnel to know not only the nature but
the extent of the relation.

4. This knowledge can be used to predict how changes in these elements will
affect the product in general and the underlying programs in particular

e. Decision-Support Features

1. Software product attributes such as complexity and maintainability are

examples that can guide maintenance personnel in technical and management
decision-making processes like option analysis, decision making, budgeting
and resource allocation.

2. Measures of the complexity of the system can be used to determine which

components of the system require more resource for testing.

Software Maintenance 21
 3. The maintainability of the system may be used as an indicator of its quality.

4. Reverse engineering can be used to study the system to be understood in

order to extract these kinds of information

5. Chikofsky and Cross define reverse engineering as the 'process of analyzing a

subject system to identify the system's components and their
interrelationships and create representations of the system in another form or
a higher level of abstraction'

Maintainers and Their Information Needs

It is not essential that every member of a maintenance project team
understands every aspect of the system being maintained.

Members of the maintenance team - managers, analysts, designers and

programmers - all have different comprehension or information needs
depending on the level at which they function

A. Managers

1. One of the responsibilities of management is making decisions.

2. Managers need to have decision-support knowledge in order to make

informed decisions.

3. The level of understanding required will depend on the decision to be taken.

4. Managers do not necessarily have to know the architectural design of the

system or the low-level program implementation details in order to carry out
their duties.

5. Example - to be able to estimate the cost and duration of a major

enhancement, knowledge of the size of the programs is required

B. Analyst

1. Analyst requires an understanding of the problem domain in order to

undertake tasks such as

Software Maintenance 22
 determining the functional and non-functional requirements.

to establish the relationship between the system and the elements of its
environment.

2. During maintenance, the analysts would be concerned with knowing how

changes in this environment would affect the system .

3. Example, new government regulations or a new operating system

4. Prior to implementing the change, the analyst needs to have a global view of
the system.

5. The analyst is also required to determine the implications of change on the

performance of a system.

6. analysts do not need the local view - a picture of localized parts of the system
and how they are implemented.

C. Designers

1. The design process of a software system can take place at two levels:

Architectural design results in the production of functional components,

conceptual data structures and the interconnection between various
components.

Detailed design results in the detailed algorithms, data representations, data

structures and interfaces between procedures or routines

2. During maintenance, the designer's job is to:

extract this information and determine how enhancements could be

accommodated by the architecture, data structures, data flow and control flow
of the existing system;

go through the existing source code to get a rough idea of the size of the job,
the areas of the system that will be affected, and the knowledge and skills that
will be needed by the programming team that does the job

Software Maintenance 23
 D. Programmers

1. Maintenance programmers are required to know the execution effect of the

system at different levels of abstraction, the causal knowledge and knowledge
of the product-environment relation.

2. At a higher level of abstraction, the programmer needs to know the function of

individual components of the system and their causal relation.

3. At a lower level of abstraction the programmer needs to understand 'what

each program statement does, the execution sequence

Comprehension Process Models: Key Points

Step 1: Read about the program:

Goal: Develop an overall understanding of the system.

Methods: Browse documentation (specification, design, structure charts, flow

diagrams).

Challenges: May be skipped if documentation is inaccurate, outdated, or non-

existent.

Step 2: Read the source code:

Goal: Understand the program's structure, data types, and algorithms.

Methods: Analyze the source code (global and local views).

Tools: Static analyzers (produce cross-reference lists for identifiers).

Importance: Often the primary source of information about a system,

especially when documentation is unreliable.

Step 3: Run the program:

Goal: Analyze the program's dynamic behavior in action.

Methods: Execute the program and obtain trace data.

Benefits: Reveals characteristics of the system that are difficult to understand

by reading the source code alone.

Software Maintenance 24
 Mental Models: Key Points
What is a mental model?

A mental representation of a phenomenon (target system) used to understand

and predict its behavior.

Examples: how a TV works, the behavior of liquids, an algorithm.

The complexity and accuracy of the model depends on the user's information
needs.

How are mental models formed?

Based on observation, inference, and interaction with the target system.

Continuously evolve as more information is acquired.

Influenced by user's prior experience and technical background.

What are the characteristics of mental models?

May contain insufficient, contradictory, or unnecessary information.

Doesn't need to be complete, but should convey key information about the
target system.

Software Maintenance 25
 For software, should at least embody the software's functionality.

How do mental models apply to programmers?

Different programmers use different strategies to understand (form mental

models of) programs.

Cognitive structures and processes influence these strategies.

In essence, a mental model is a tool that helps us make sense of the world
around us. It allows us to predict, explain, and interact with complex systems.

Program Comprehension Strategies

1. A program comprehension strategy is a technique used to form a mental
model of the target program.

2. The mental model is constructed by combining information contained in the

source code and documentation with the assistance of the expertise and
domain knowledge that the programmer brings to the task.

Top-Down Model

1. The belief of this model is that an understander starts by comprehending the

top-level details of a program, such as what it does when it executes, and
gradually works towards understanding the low-level details such as data
types, control and data flows and algorithmic patterns in a top-down fashion.

2. Example- top-down comprehension model is that proposed by Brooks The

key features of Brooks' model are:

It views the structure of the knowledge being understood as organized into

distinct domains linking the problem domain (represented by the functionality
of the system) and the programming domain (represented by the program);

Program comprehension involves reconstructing knowledge about these

domains and the relationship between them. The reconstruction process is
top-down, involving creation, confirmation and refinement of hypotheses on
what a program does and how it works.

Software Maintenance 26
 3. The cognitive structure and cognitive process of a mental model resulting
from a top-down strategy can be explained in terms of a design metaphor.

4. Software development in its entirety can be considered to be a design task

which consists of two fundamental processes - composition and
comprehension .

5. Composition entails mapping what the program does in the problem domain,
into a collection of computer instructions of how it works in the programming
domain, using a programming language.

6. Comprehension is the reverse of composition. It is a transformation from the

programming domain to the problem domain involving the reconstruction of
knowledge about these domains (including any intermediate domains) and the
relationship between them.

Bottom-Up I Chunking Model

1. Using this strategy, the programmer successively recognizes patterns in the

program.

2. These are iteratively grouped into high-level, semantically more meaningful

structures .

3. The high-level structures are then chunked together into even bigger
structures in a repetitive bottom up fashion until the program is understood.

4. The chunking process tends to be faster for more experienced programmers

than novices because they recognise patterns more quickly.

Software Maintenance 27
 The main weaknesses of both the top-down and bottom-up comprehension
strategies are:

1. failure to take into consideration the contribution that other factors such as the
available support tools make to understanding.

2. the fact that the process of understanding a program rarely takes place in
such a well-defined fashion as these models portray. On the contrary,
programmers tend to take advantage of any clues they come across in an
opportunistic way.

Opportunistic Model

1. When using this model the understander makes use of both bottom-up and
top-down strategies, although not simultaneously.

2. According to this model, comprehension hinges on three key and

complementary features.

A knowledge base: This represents the expertise and background knowledge

that the maintainer brings to the understanding task.

Software Maintenance 28
 A mental model: This expresses the programmer's current understanding of
the target program.

An assimilation process: This describes the procedure used to obtain

information from various sources such as source code and system
documentation.

3. When maintainers need to understand a piece of program, the assimilation

process enables them to obtain information about the system.

4. This information then triggers the invocation of appropriate plans from the
knowledge base to enable them to form a mental model of the program to be
understood

Factors affecting program understanding -

1. Expertise:

Impact: Expertise significantly influences program comprehension.

Explanation: Experts store knowledge in larger, more organized chunks,

enabling them to quickly recognize problems and recall solutions.

Result: Experienced programmers grasp programs faster and more easily.

2. Implementation Issues:

General Impact: Various implementation choices affect program

maintainability and comprehension.

Specific Factors:

Problem Complexity: A complex problem translates to a complex program.

Naming Style: Meaningful names act as "beacons" aiding understanding.

Comments: Well-written comments clarify code intent and purpose.

Nesting Levels: Excessive nesting makes programs harder to follow.

Clarity & Readability: Code should be easy to read and comprehend.

Simplicity: Simple code is generally easier to understand.

Software Maintenance 29
 Decomposition Mechanism: Well-structured modularity enhances
understanding.

Information Hiding: Encapsulation of data and logic improves clarity.

Coding Standards: Consistent coding practices promote readability.

3. Naming Style:

Psychological Argument: Names act as clues for understanding program

structure and operations.

Empirical Evidence: Limited and inconclusive; some studies show impact on

novices, but not experts.

Possible Reasons:

Focus on Specific Activities: Some studies focus on specific tasks, limiting

generalizability.

Vocabulary Problem: Individual understanding of terms may vary.

Intuition: Meaningful names undoubtedly contribute to better understanding.

Recommendation: Use informative, concise, and unambiguous names to

minimize the "vocabulary problem."

4. Comments:

Purpose: Comments within code provide information about program

functionality, design decisions, assumptions, algorithms, and data, aiding
understanding.

Types:

Prologue comments: Describe overall program or module goals.

In-line comments: Explain specific code sections and how they achieve
goals.

Importance: Comments act as "beacons," guiding comprehension, especially

when code is the only source of information.

Empirical Evidence: Studies on the impact of comments on comprehension

are equivocal, likely due to experimental limitations and the complex nature of
programming.

Software Maintenance 30
 Key Point: The quality of comments matters more than simply their presence
or absence. Comments should provide useful, additional information.

5. Decomposition Mechanism:

Challenge: Program complexity can hinder understanding.

Solutions: Decomposition techniques help manage complexity.

Modular Decomposition: Breaking large systems into manageable modules,

facilitating understanding and localized change management.

Structured Programming: Using high-level languages that aim to reduce

program size and complexity, enhancing readability and comprehension.

Benefits: Modular and structured programs are easier to comprehend, making

them more maintainable.

6. Documentation:

Importance: Comprehensive documentation is crucial for understanding

software systems, especially when original authors are unavailable.

Types:

System Documentation: Covers overall system design, architecture, and

functionality.

User Manuals: Guides users on program usage.

API Documentation: Specifies how to interact with program components.

Code Comments: Clarify specific code sections.

Challenges: Documentation may be inaccurate, outdated, or nonexistent,

requiring reliance on internal code comments.

7. Organization & Presentation of Programs:

Importance: Programs should be organized and presented in a way that

promotes readability and understanding.

Techniques:

Indentation: Emphasizes logical structure and relationships between code

elements.

Software Maintenance 31
 Spacing: Using blank lines and white spaces to separate code segments
and comments.

Boxing & Shading: Highlighting key aspects and relationships within the
code.

Benefits: Clearer expression of program structure, improved readability, and

easier identification of "beacons" for comprehension.

8. Comprehension Support Tools:

Purpose: Tools aid in understanding by providing insights and analysis.

Examples:

Book Paradigm: Documents source code using book-like features

(sections, chapters, indexing) to enhance comprehension.

Pretty-Printers: Enforce consistent code layout for improved readability.

Static Analyzers: Detect potential issues and code smells, aiding

comprehension.

Browsers: Facilitate navigation and exploration of code.

9. Evolving Requirements:

Reality: Requirements are dynamic, not static, and evolve throughout the
software lifecycle.

Challenges: Changing requirements can introduce complexity and make

understanding existing code difficult.

Solutions:

Impact Analysis: Assess the effects of requirement changes on the

system.

Negotiation: Recognize the importance of negotiation in resolving

conflicting requirements.

Vision: Develop a vision for how requirements will evolve to handle change
effectively.

Software Maintenance 32
 Implications of Comprehension Theories and Studies
No Single Best Strategy: There is no definitive best program understanding
strategy.

Impact on Maintenance Activities: Comprehension strategies significantly

impact:

Knowledge acquisition

Performance on modification tasks

Effectiveness of training programs

Design choices for programming languages, tools, and documentation

Formulation of guidelines and recommendations for best practices

Knowledge Acquisition and Performance

Knowledge Needs: The type of knowledge required for program modification

varies depending on the change (local vs. global).

Strategy Impact: The comprehension strategy used directly influences:

Knowledge acquired (depth and type)

Speed and accuracy of information retrieval

Overall success of modification tasks

Education and Training

Importance of Training: Maintainers need to be taught about different

program understanding strategies.

Benefits of Training: Training helps maintainers:

Choose appropriate strategies for specific tasks and environments

Evaluate the effectiveness of their usual strategies

Improve overall comprehension skills

Design Principles

Mental Model Formation: Successful comprehension relies on forming

accurate mental models of the program.

Software Maintenance 33
 Design Implications: Understanding comprehension processes informs
design choices, including:

Programming language features that support mental model building

Documentation standards that facilitate comprehension

Tools that provide support for various comprehension approaches (top-

down, bottom-up, opportunistic)

Guidelines and Recommendations

Evidence-Based Guidelines: Empirical studies provide a basis for guidelines

on:

Programming practices (e.g., modular design)

Documentation standards

Selection of techniques, methods, and tools

Importance of Evidence: Empirical evidence strengthens the credibility and

effectiveness of guidelines and recommendations.

UNIT 2
Reverse engineering -
The process of analyzing a subject system to:

1. identify the system's components and their interrelationships and

2. create representations of the system in another form or at higher levels of

abstraction

Purpose and Objectives of Reverse Engineering:

Purpose:

Software Maintenance 34
 Understand a software system in terms of its functionality, implementation,
and architecture.

Objectives:

Recover lost information:

Retrieve missing or outdated documentation (requirements, design).

Reconstruct the original system specification and design from existing

code.

Facilitate migration between platforms:

Extract system design and specification using reverse engineering.

Apply forward engineering to adapt the system to a new platform.

Improve or provide documentation:

Generate new or augment existing documentation using specialized tools.

Provide alternative views of the system (data flow, control flow, entity-
relationship diagrams).

To provide alternative views:

Redocumentation tools generate various diagrams (e.g., data flow, control

flow) to offer different perspectives of the system.

Extract reusable components:

Identify and extract reusable components from existing code.

Promote code reuse and improve software development efficiency.

Cope with complexity:

Abstract relevant information related to modifications, ignoring irrelevant

aspects.

Reduce complexity by providing automated support for function and data

abstractions.

Detect side effects:

Analyze system architecture to predict potential side effects of changes.

Software Maintenance 35
 Identify logic and data flow problems that could lead to unexpected
behavior.

Reduce maintenance effort:

Provide a means to understand existing code and improve documentation.

Reduce time spent on understanding the system, allowing faster and more
efficient maintenance.

Levels of RE

Software Maintenance 36
 1. Redocumentation

Definition: Recreates a semantically equivalent representation of a system at

the same abstraction level.

Goals:

1. Create alternative views to enhance understanding (e.g., generate

hierarchical data flow or control flow diagrams).

2. Improve existing documentation, which often becomes outdated or was

never properly developed.

3. Generate documentation for newly modified programs to aid future

maintenance (preventive maintenance).

Purpose: Helps maintainers and developers better understand and work with
the system by improving or providing documentation.

2. Design Recovery

Definition: Identifies and extracts higher-level abstractions beyond what can

be directly obtained from source code.

Sources: Combines insights from source code, design documents, personal

experience, and knowledge of the problem and application domains.

Goals:

Software Maintenance 37
 1. Recover meaningful higher-level design abstractions.

2. The resulting design can be used for future system modifications or for
developing similar applications.

Approaches:

Language-based approaches: Focus on recognizing design decisions

through programming language constructs like control structures,
variables, procedures, modules, and class hierarchies.

Domain-based approaches: Use knowledge of problem-solving

techniques (e.g., searching, sorting) to recognize standard design
elements. Experienced programmers can recognize these "clichés" to
reconstruct designs.

Examples:

Extracting and restructuring designs from large systems with intermodular

relationships.

The design can be reused for other non-identical systems like building a
spell checker from an existing word processor.

3. Specification Recovery

Definition: Recovers the original system specification, often required when

shifting to a new paradigm (e.g., moving from structured programming to
object-oriented programming).

Process: Involves abstracting meaningful higher levels of information beyond

the design or source code, sometimes using backward transformations.

Sources: Combines information from source code, design documentation,

domain knowledge, and past experience.

Representation:

Should be in a form that can be easily reimplemented in another

programming language or paradigm (e.g., mathematical functions in Z++
or object classes).

Object class representation is particularly useful for migrating systems to

object-oriented platforms.

Software Maintenance 38
 Benefits:

1. The recovered specification supports software maintenance even without

access to the source code.

2. It helps maintainers gain the necessary understanding to modify the

system.

3. A well-represented specification can aid in the development or

maintenance of similar systems.

4. Sometimes using the specification offers more benefits than working

directly with source code.

4. Conditions for Reverse Engineering

No Strict Rules: There are no hard-and-fast criteria for when reverse

engineering should be applied.

Indicators: Certain program features may signal a need for reverse

engineering.

Commercial Motives: Reverse engineering is usually driven by commercial

needs, such as maintaining, upgrading, or migrating a system.

Understanding Over Modification: Reverse engineering doesn’t directly

modify the system; instead, it facilitates understanding by abstracting the
system to an equivalent or higher level.

Software Maintenance 39
 Supporting technique:
1. Forward Engineering

Traditional software development approach.

Proceeds from requirements through design to detailed implementation.

Opposite of reverse engineering and not covered in depth here.

2. Restructuring

Definition: Transforming a system's form while maintaining functionality and

semantics.

Purpose: Prevents complexity buildup due to repeated modifications and

improves system maintainability.

Focuses on improving the physical state of the code in line with a given
standard.

Types of Restructuring:

1. Control-flow-driven restructuring:

Imposes a clear control structure in the code.

Can be done within a single module (intra-modular) or across multiple

modules (inter-modular).

Example: Restructuring 'spaghetti code' to adhere to structured

programming principles.

2. Efficiency-driven restructuring:

Focuses on making the code more efficient.

Example: Replacing an IF-THEN-ELSIF-ELSE construct with a CASE

construct to minimize Boolean evaluations.

3. Adaption-driven restructuring:

Adapts code to new programming languages or environments.

Example: Converting a program from Pascal to Lisp or transforming

sequential code to run in a parallel environment.

Other Restructuring Targets:

Software Maintenance 40
 Besides source code, other system representations like requirements
specifications, data models, and design plans can also be restructured.

Tools: Some automatic restructuring tools exist, though fully automating the
process is challenging.

3. Reengineering

Definition: Examining and modifying a target system to apply changes or

improvements.

Involves two steps:

1. Reverse engineering: Understanding the existing system and representing

it in a new form.

2. Forward engineering: Implementing new requirements to create an

enhanced system.

SCORE/RM Model (Source Code Reengineering Model by Colbrook et al.):

A layered model used for source code reengineering, involving 8 layers.

First 5 layers (reverse engineering):

1. Encapsulation

2. Transformation

3. Normalization

4. Interpretation

5. Abstraction

Remaining 3 layers (forward engineering):

6. Causation
7. Regeneration
8. Certification

Applications of SCORE/RM:

1. Helps maintainers understand code, generate documentation, and make

the code more maintainable.

Software Maintenance 41
 2. Supports retrospective specification of a system based on available
source code.

Benefits of reverse engineering:

1. Maintenance Benefits

Facilitates System Understanding:

Reverse engineering tools help recapture design history and provide

documentation, aiding in understanding complex systems.

Reduces the time required to understand a program, lowering maintenance

costs.

Corrective Change:

Abstracting unnecessary details gives clearer insight into parts of the

program needing correction.

Helps identify defective components and residual errors.

Reverse engineering outputs, like cross-reference tables, structure charts,

data flow, and control flow diagrams, assist in tracing and modifying the
correct variables and identifying areas likely to be affected by changes.

Adaptive/Perfective Change:

Reverse engineering provides a broad view of the system, showing major

components and their interrelationships.

This helps in understanding where new requirements fit and how they
relate to existing components.

Extracted design and specification information can be used for system

enhancements or new product development.

Preventive Change:

Reverse engineering is beneficial for future system maintenance by

preventing issues before they occur.

2. Software Reuse

Software Maintenance 42
 Definition:

Software reuse refers to applying knowledge from an existing system

(e.g., source and object code) to develop or maintain other systems.

Component Reuse:

Components derived from reverse engineering processes can be reused

in other systems.

These components may require modifications before reuse.

Practical Use:

Software reuse is an important aspect that follows from reverse

engineering techniques and is discussed further in the next chapter.

3. Reverse Engineering and Associated Techniques in Practice

Practical Applications:

Reverse engineering, along with reengineering and restructuring, has been

successfully applied in various sectors of the computing industry.

Used in Large Systems:

These techniques have been used to manage very large and complex
software systems in different organizations.

Reuse and Reusability

Reuse

It refers to the act of using existing software components (modules, routines,

objects, etc.) in new software development projects.

It's essentially taking something you've already built and using it again.

Reusability

It is the property of a software component that makes it suitable for reuse.

It's a design and implementation characteristic that enables components to be

used in different contexts without significant modifications.

Software Maintenance 43
 Benefits of Reuse:

Reduced Development Time: By leveraging existing components, developers

can significantly shorten development cycles.

Improved Quality: Reusing well-tested components generally leads to more

reliable and robust software.

Lower Development Costs: Reducing development time and improving quality

ultimately translates into lower project costs.

Increased Consistency: Using the same components across multiple projects

promotes consistency and standardization.

Factors that Contribute to Reusability:

Well-Defined Interfaces: Components with clear and unambiguous interfaces

are easier to integrate into different systems.

Modularity: Components that are independent and self-contained are more

reusable.

Abstraction: Abstracting away from specific details allows components to be

applied in various situations.

Portability: Components that can be easily adapted to different platforms and

environments enhance their reusability.

Documentation: Thorough documentation makes it easier for developers to

understand and utilize existing components.

Testability: Components that are easily testable and have comprehensive test
cases facilitate confidence in their reuse.

Role of Reusability in Maintenance:

Easier Maintenance: When components are reusable, changes made to one

component can be propagated to all its instances, simplifying maintenance
efforts.

Reduced Maintenance Costs: The benefits of reusability in development

carry over to maintenance, resulting in lower maintenance costs.

Software Maintenance 44
 Improved Maintainability: Reusing well-defined components makes
codebases easier to understand and maintain, ultimately leading to a more
maintainable system.

Objectives and Benefits of Software Reuse:

1. Increase Productivity:

Reduce Development Time & Effort: Reusing existing code, designs, and
knowledge eliminates the need to start from scratch for every project.

Faster Maintenance Cycles: Reusable components are easier to understand

and modify, leading to quicker fixes and enhancements.

Lower Development Costs: Reduced development time and effort translate to

lower overall project costs.

Justification for Reuse: The time spent searching for, understanding,

adapting, and incorporating a reusable component should be significantly less
than developing it from scratch.

2. Increase Quality:

Fewer Errors: Reusable components are typically well-tested and proven to

meet specific requirements, reducing the risk of residual errors.

Improved Reliability: Tested and proven components contribute to greater

overall software reliability and robustness.

Focus on "Good" Components: The concept of reuse emphasizes the use of

high-quality, well-designed code and components.

3. Facilitate Code Transportation:

Machine-Independent Components: Using standards (internal, national, or

international) allows for creating code that can be easily transported across
different machines and software environments.

Reduced Adaptation Effort: Portable components minimize the time and

resources needed to adapt code for new platforms or environments.

Software Maintenance 45
 Focus on Portability: The goal is to create code that can be readily used in
various settings with minimal modifications.

Reuse Benefits:
Challenges & Success:

Not Always Feasible: Achieving all reuse objectives simultaneously on every

project is not always possible due to constraints and project specifics.

Benefits Outweigh Challenges: The potential benefits of successful reuse

often outweigh the challenges, leading to significant improvements in software
development and maintenance.

Benefits of Reuse:
1. Reduction in Maintenance Time & Effort:

Easy to Understand and Modify: Reusable components are designed for

generality, manageable size, and consistent style, making them easier to read,
understand, and modify.

Reduced Learning Curve: Familiarity with reused code over time leads to a
faster learning curve for developers.

Perfective Changes: Perfective changes (improvements and enhancements)

often involve incorporating new components readily available from reuse
libraries, further reducing maintenance effort.

Significant Cost Savings: Maintenance consumes a large portion of software

development budgets, and reuse significantly reduces maintenance costs,
especially for perfective changes.

2. Improved Maintainability:

Desirable Characteristics: Reusable components often exhibit characteristics

crucial for maintainability, including generality, high cohesion, low coupling,
consistent programming style, modularity, and adherence to standards.

Enhanced Maintainability: Efforts to improve the reusability of software

components directly contribute to their maintainability.

Software Maintenance 46
 Approaches to Reuse
Two Main Approaches:

Composition-Based Reuse: Assemble atomic building blocks (e.g., modules,

routines, objects) into a target system.

Components retain their basic characteristics after reuse.

Examples: UNIX pipes, object-oriented inheritance.

Generation-Based Reuse: Use active components (generators) to create a

target system.

The generated output might not resemble the generator program.

Examples: Application generators, transformation-based systems,

language-based systems.

1. Composition-Based Reuse:

Mechanisms: Techniques like UNIX pipes and object-oriented inheritance

"glue" components together.

Black-Box Reuse: Reuse components without modification; only the

component's purpose is known.

Examples: Standard libraries (e.g., MathLibO, InOut in Modula-2).

White-Box Reuse: Reuse components after modification; both purpose and

implementation are accessible.

Examples: Modifying source code in languages like Modula-2.

2. Generation-Based Reuse:

Application Generator Systems: Use specifications to automatically generate

applications.

Examples: yacc (generates parsers), Neigbors' Draco system (domain-

specific software product generation).

Transformation-Based Systems: Convert high-level specifications into

operational programs through stages.

Software Maintenance 47
 Types of transformation: Step-wise refinement, linguistic transformation.

Examples: SETL language (transforms specifications into a lower-level

language called LITTLE).

Evaluation of Generation-Based Systems:

Hybrid Nature: Many systems combine features of multiple generation-based

categories.

Example: Neigbors' Draco system exhibits aspects of both application

generators and transformation systems.

Domain Analysis
Types of Reuse:

Horizontal Reuse: Components applicable across many different domains

(e.g., algorithms, data structures).

Vertical Reuse: Components targeted at specific problem areas or application

domains.

Domain Analysis:

Purpose: Identify, capture, and organize information relevant to a specific

domain to facilitate reuse.

Process: Study the needs and requirements of applications within a domain,

identify and describe objects and operations, and define constraints on their
interactions.

Implementation: Convert these descriptions into reusable code modules in a

programming language.

Domain Expert: Performed by an expert with experience in the specific

domain.

Importance: Especially valuable for organizations specializing in particular

software systems.

Software Maintenance 48
 Advantages of Domain Analysis:

Valuable Asset: Creates a repository of domain-specific information that can

be used for training and knowledge transfer.

Reduces Turnover Impact: Minimizes the loss of expertise due to staff

turnover by capturing and organizing domain knowledge.

Challenges of Domain Analysis:

Upfront Investment: Requires a substantial initial investment, which might not

be justified immediately.

Long-Term Benefits: The full benefits of domain analysis (increased

productivity, reduced maintenance costs) may not be realized until later.

Components Engineering
Composition-Based Reuse:

Goal: Create new systems by assembling existing components.

Software Maintenance 49
 Two Approaches:

Design for Reuse: Deliberately create components for multiple uses.

Reverse Engineering: Extract reusable components from existing

systems.

Characteristics of Reusable Components:

Adaptability: Design for modifications throughout the component's lifecycle.

Shielding: Minimize the impact of changes on the core functionality.

Strong Design: Apply principles that promote both evolvability and reuse.

1. Design Principles for Reusability:

Generality: Design components usable across a wide range of applications.

Balance: Achieve the right balance between broad applicability and actual
benefit.

Cohesion: Ensure internal elements of a component are tightly related.

Coupling: Keep components independent to minimize interdependence.

Interaction: Minimize user interaction while promoting interaction with utility

functions.

Standardization: Apply standards for UI design, programming style, data

structures, and documentation.

Abstraction: Separate data manipulation logic from data itself.

Interoperability: Enable components to work seamlessly with other systems.

Problems with Reuse Libraries:

Granularity vs. Size: Finding the optimal balance between small,

understandable components and efficient library management.

Search: Effectively finding the desired component within a large library.

Classification: Organizing and representing components for easy discovery.

Specification & Flexibility: Specifying both component behavior and allowable

usage constraints for white-box reuse.

Software Maintenance 50
 2. Reverse Engineering:

Purpose: Extract reusable components from existing systems not originally

designed for reuse.

Technique: Analyze and understand existing code to identify reusable parts.

Benefits: Leverages existing codebases to create reusable assets.

3. Components-Based Processes:

Addressing Expertise Concentration: Counteracts the reliance on a few

specialists for system maintenance.

Skill Shift: Emphasizes skills related to components services and library

maintenance.

Cross-Domain Focus: Components often span technological and business

domains, requiring broader expertise.

Standardization: Initiatives like the OMG's Model-Driven Architectures and de

facto standards like Java promote interoperability.

International Standards: The OMG's Software Process Engineering

Metamodel provides a standard framework for process engineering.

Reuse Process Model Explained:

1. Traditional Top-Down Life-Cycle Models & Reuse:

Problem: Traditional models (like waterfall) don't integrate reuse effectively.

Reasons:

Reuse is not inherently top-down.

Reuse requires broader project scope and knowledge.

Reuse involves more than just code, requiring multi-level abstraction.

Domain analysis for reuse is crucial, but not always addressed.

2. Refinement of Life-Cycle Models for Reuse:

Need: "Reuse-conscious" models are needed to integrate reuse effectively.

Software Maintenance 51
 Propositions: Several models have been proposed to address this.

Simos Model: Focuses on development, but principles apply to maintenance.

3. Prieto-Diaz and Freeman's Reuse Model:

Assumption: Software engineers already understand the problem and

specifications.

Approach: Algorithm-based model.

4. Kang's Generic Reuse/Reusability Model:

Purpose: Addresses the failure of traditional models to handle reuse.

Approach: Refines DOD-STD-2167A lifecycle (waterfall).

Steps:

Step 1: Problem understanding

and solution structuring using
existing components.

Step 2: Reconfiguring solution

to maximize reuse at current
and future phases.

Step 3: Preparing reusable

components: acquiring,
modifying, instantiating, or
developing new ones.

Step 4: Integrating completed

components into next phase
products.

Step 5: Evaluating reusability

of developed and adapted
components.

5. Advantages of Kang's Model:

Software Maintenance 52
 Multi-project View: Encourages reuse across projects.

6. Applicability to Maintenance:

While Kang's model focuses on development, it can be applied to

maintenance as well.

Accommodating a Reuse Process Model:

1. Challenges of Adopting Reuse:

Resistance to change in existing software engineering processes.

Potential destabilization of organizational culture.

2. Solution: Gradual Integration:

Encourage reuse by assisting personnel in applying it within existing phases.

Integrate a reuse model (like Kang's) without discarding the current model.

Factors that Impact upon Reuse

1. Technical Factors Impacting Reuse:

Software Maintenance 53
 Programming Languages: Using multiple languages hinders component
reuse. Solution: Mandate a single language for projects.

Information Representation: Poor design information representation

discourages reuse. Solution: Represent knowledge in a modular, reusable
format.

Reuse Library: Populating and managing large reusable component libraries is

expensive and time-consuming.

Reuse-Maintenance Vicious Cycle: As the library grows, managing it

becomes a maintenance problem. Solution: Use good design principles for
both components and the library.

2. Non-Technical Factors Impacting Reuse:

Initial Capital Outlay: Setting up and managing reusable component libraries

is costly.

"Not Invented Here" Factor: Software engineers often prefer to develop their
own code. Solution: Foster a culture that values and encourages reuse.

Commercial Interest: Profit-driven software creators may not release their

components for public use.

Education: Managers may lack the software engineering knowledge to

recognize the benefits of reuse.

Project Co-ordination: Lack of coordination between projects leads to

duplication. Solution: Implement a multi-project view for development and
maintenance.

Legal Issues: Reusing public software libraries raises legal questions.

Objectives of Software Measurement:

1 Evaluation:

Purpose: Determine the best-suited method, program library, or tool for a

given task.

Example: Evaluating the suitability of a reusable component from a library.

Software Maintenance 54
 2 Control:

Purpose: Manage software change requests efficiently and within budget.

Key Principle: "You cannot control what you cannot measure." (DeMarco)

3 Assessment:

Purpose: Characterize and evaluate the state of a software system or

process.

Examples:

Determining the economic feasibility of continued system maintenance.

Evaluating the effectiveness of the maintenance process.

4 Improvement:

Purpose: Enhance software system or process characteristics like quality and

productivity.

Method: Use objective measurements to:

Assess and monitor improvements.

Set targets and track progress.

Take corrective actions if necessary.

5 Prediction:

Purpose: Forecast aspects of software product, process, and cost.

Examples:

Predicting the time required to implement a change using code measures.

Using measures to allocate resources for maintenance projects.

Identifying program complexity and potential change impact.

Example Measures:
1. Size

Lines of Code (LOC):

Software Maintenance 55
 Definition: Number of program lines excluding comments and blank lines.

Measurement: Expressed in thousands of lines of code (KLOC).

Focus during maintenance: 'Delta' LOC - number of lines added or

modified.

Advantages: Easy to determine, correlates with effort and error density.

Disadvantages: No standard, language-dependent, simplistic, doesn't

reflect cost or productivity.

Formula:
LOC = Total program lines- Comment lines - Blank lines

2. Complexity

Definition: Difficulty of maintaining, changing, and understanding programs.

Key Concept: Increasing complexity in code is a major challenge for

maintainers.

Measures: Combine elements like program structure, semantic content,

control flow, data flow, and algorithmic complexity.

Commonly Used Measures:

McCabe's Cyclomatic Complexity:

Definition: Number of linearly independent paths through a program's

flow graph.

Formula: v(F) = e - n + 2
where:

v(F) = cyclomatic number

e = total number of edges

n = total number of nodes

Interpretation: A high cyclomatic number (above 10) indicates

significant complexity.

Halstead's Difficulty Measure:

Software Maintenance 56
 Definition: Evaluates the effort required to understand and modify a
program.

Formula: E = n1 * N2 * (log2(n1 + n2) / 2 * n2)

where:

E = program effort

n1 = number of unique operators

n2 = number of unique operands

N1 = total number of operators

N2 = total number of operands

Benefits of Complexity Measures:

Identify complex sections requiring simplification.

Estimate time needed for understanding and modification.

Guide testing by highlighting critical paths in the program flow graph.

Limitations of Complexity Measures:

Oversimplification: May not capture all facets of complexity.

Interpretation: Requires careful consideration and context.

Dependence on code structure: May not reflect complexity introduced by

design choices.

3. Quality in General

"Fitness for purpose" - meets user expectations.

Applies to both software product and maintenance process.

Measured using metrics like change requests and fault detection.

4. Product Quality

Change Requests: Number of user-reported issues in the first year after

release.

Indicates customer satisfaction and potential maintenance workload.

Fault Detection: Number of unique bugs found after release.

Software Maintenance 57
 Higher number indicates potential quality issues.

Frequency of the same fault indicates its severity.

5. Process Quality

Schedule: Deviation from planned delivery time.

Negative percentage = delayed delivery.

Positive percentage = early delivery.

Productivity: Number of code changes divided by staff-days spent.

Measures efficiency of the maintenance process.

6. Understandability

Ease of grasping program functionality and implementation.

Influenced by code, documentation, maintenance process, and personnel.

Measured using:

Complexity (McCabe, Halstead)

Documentation quality

Code consistency and conciseness

Generally inversely proportional to complexity.

7. Maintainability

Ease of understanding, correcting, adapting, and enhancing software.

Measured using:

MTTR (Mean Time To Repair): Time needed to implement a change.

Internal code attributes (e.g., modularity)

Often estimated using complexity and readability metrics.

8. Cost Estimation

Methods:

Historical Data: Using past projects as a reference.

Software Maintenance 58
 Mathematical Models: (COCOMO, COCOMO II) which consider various
cost drivers.

Person-Months: Time spent to modify a program.

Guidelines for Selecting Maintenance Measures

1. Well-Defined Objectives:

Clarity is Key: Clearly define what you want to achieve with the measures.

Goal-Driven Selection: Objectives determine the measures used and data

collected.

2. Personnel Involvement:

Transparency: Communicate the purpose of measurement clearly to

everyone involved.

Purposeful Use: Ensure measures are used for their intended purpose,
avoiding misuse or misinterpretation.

Avoid Punitive Application: People should feel measures are for improvement,
not punishment.

3. Ease of Use:

User-Friendliness: Measures should be easy to implement and manage.

Time Efficiency: Minimize time spent on administration.

Unobtrusiveness: Don't disrupt normal workflow.

Automation Potential: Consider automating data collection for efficiency.

Additional Notes:

Fitness for Purpose: The measures should be relevant to the specific

maintenance goals.

Low Implementation Cost: Weigh the value of the measures against the cost
of implementing them.

Sensitivity: Measures should be sensitive enough to detect meaningful

changes in the maintenance process.

Software Maintenance 59
 UNIT 3 CONFIGURATION MANAGEMENT

Change Control:

Sequence of events from change request to approval/rejection.

Activities include: priority selection, problem reproduction, code analysis,

change incorporation, design & testing, quality assurance.

Ensures controlled changes with predictable effects.

Formal procedures can be time-consuming; less formal approaches are

sometimes appropriate for experienced teams.

Responsibilities of Management in Change Control:

Change Decision: Change Control Board analyzes change requests for

validity, costs, and benefits. Balances cost vs. benefit. Approves or rejects
requests. Uses change request forms for documentation.

Implementation Management: Assesses ramifications of changes (started

during costing).

Quality Verification: Implements quality control before releasing new

versions.

Documentation: Crucial for reproducibility of older versions or specific

functionalities. Supports parallel team work. Strict procedures for checking
out, editing, and checking in code modules are needed.

Software Maintenance 60
 Documentation:

Essential for management and control.

Makes processes and procedures visible, enabling effective control.

Starts when the system need is conceived and continues until the system is
decommissioned.

Categories of Software Documentation:

User Documentation: Describes system functions without implementation

details.

System Documentation: Describes all system aspects, including analysis,

specification, design, implementation, testing, security, error handling, and
recovery. Further divided into individual documents covering specific aspects.

Software Maintenance 61
 Alternative Documentation Classification (Macro's Scheme):

User Manuals: Describe system functionality without implementation or

operational details.

Operator Manuals: Explain system usage and fault recovery.

Software Maintenance 62
 Maintenance Manuals: Detail functional specifications, design, code, test
data, and results. This classification is largely equivalent to the user/system
documentation scheme.

Factors Influencing Documentation Variation:

Development Methodology: Different development approaches lead to

different documentation types.

Customer Category: Customers (e.g., end-users, developers, resellers)

receive different documentation subsets (user manuals vs. full system
documentation and source code).

System Version: Upgrades require additional documentation (enhancement

booklets, upgrade instructions).

Challenges of Documentation Diversity:

No prescriptive list of required documents exists due to variations in

nomenclature and content across systems and organizations.

Inconsistent naming conventions make it difficult to switch between systems

and find information quickly, especially problematic for software maintainers
facing backlogs.

International documentation standards could mitigate these issues.

Role of Software Documentation:

Program Comprehension: Enables understanding and modification of

software, crucial for maintenance, especially with staff turnover. Documents
provide rationale, functionality, and development details. Brooks' theory
emphasizes the use of program text and documents to form hypotheses about
program function, cautioning against excessive or contradictory
documentation.

User Guidance: Serves as the primary system introduction for users. Provides
system capabilities description, installation/customization instructions, and
malfunction handling information.

Software Maintenance 63
 System Complement: Integral part of the software system. Essential for
ensuring the software meets requirements and is maintainable.

Producing and Maintaining Quality Documentation:

Continuous updates are essential to reflect maintenance activities. Document

inspection may be the only way to understand software details and
development rationale. Good documentation facilitates this.

Maintenance cost is proportional to documentation effectiveness (describing

system function and logic).

Guidelines for Producing Good Documentation:

Clear and understandable writing style (active voice, manageable chunks,

varied explanations).

Adherence to document standards (cover sheets, fonts, styles,

numbering).

Quality assessment process to ensure standard conformance.

Procedures to ensure documentation is updated concurrently with system

updates.

Good design methodologies (structured programming, meaningful

identifiers, consistent style) reduce the need for extensive low-level
documentation.

Management Responsibilities in Software Maintenance:

Focus on Large, Complex Systems: Management is crucial for large,
organizationally integrated systems with evolutionary capabilities and
requiring many personnel. Maintenance personnel are central to their success.

Management Goals: Ensure satisfactory system quality and timely, cost-

effective changes. This involves:

Managing maintenance personnel for increased productivity, job

satisfaction, and system quality (through personnel selection, motivation,
team structure, education, and training).

Software Maintenance 64
 Organizing maintenance tasks for productivity, cost control, and high-
quality system delivery (depending on organizational modes).

Enhancing Maintenance Productivity:

Choosing the Right People: Most important factor for increased productivity.
This includes improving the image of maintenance work, offering competitive
compensation, and aligning organizational and maintenance goals.

Motivating Maintenance Personnel: Crucial for retaining experienced staff

and preventing team collapse. This involves:

Rewards: Structured reward systems (promotions) are more effective than

ad-hoc bonuses for long-term retention and motivation.

Supervision: Providing adequate technical supervision and support for

inexperienced staff.

Assignment Patterns: Rotating personnel between maintenance and

development tasks to avoid stagnation and leverage cross-functional
experience.

Recognition: Acknowledging the value of maintenance contributions to

the organization.

Career Structure: Providing a career path comparable to development to

improve the perceived value of maintenance work.

Communication: Essential two-way information flow between management

and personnel. Management must provide the framework, and staff must
provide feedback on progress.

Adequate Resources: Providing state-of-the-art tools, a suitable working

environment, and the right number of staff (avoiding over-stretching).
Management must stay aware of new developments to avoid stifling
innovation.

Domain Knowledge: Managers need a strong understanding of the

maintenance process and its cost implications at each stage to guide it
effectively. Knowledge of the cost of code analysis, for example, is essential.

Software Maintenance 65
 Maintenance Team Structures:
I. Maintenance Team Structure and Productivity:

A stable team is crucial for productivity; constant personnel changes hinder

efficiency due to onboarding time.

II. Maintenance Team Types:

A. Egoless Programming Team: Collaborative, collegiate approach; focuses

on collective problem-solving and openness to criticism. Minimizes ego-
driven conflicts.

B. Chief Programmer Team: Structured, hierarchical approach with clear

leadership and defined roles; emphasizes discipline and functional separation.
Ensures code understanding by multiple individuals.

III. Maintenance Team Approaches (Martin & McClure):

A. Temporary Team: Informal, task-specific team formed for short-term needs

(e.g., code review). Leadership rotates; may compromise quality, morale, and
user satisfaction.

B. Permanent Team: Formal, ongoing team for long-term system evolution.

Includes roles like maintenance leader, co-leader, user liaison, administrator,
and programmers. Promotes specialization, communication, and a
collaborative environment.

IV. Optimal Team Composition:

Regardless of team type, a mix of experienced and junior personnel is

essential. Management should actively attract high-quality individuals to
maintenance roles.

Personnel Education and Training:

Traditional Neglect: Software maintenance education and training have

historically been neglected.

Changing Trend: A growing recognition of the importance of maintenance

education is leading to more dedicated courses and resources.

Objectives of Maintenance Education:

Software Maintenance 66
 Raise Awareness: Improve understanding of maintenance processes, the
differences between development and maintenance, and the critical role of
maintenance in organizational success. This is crucial for both managers
and programmers.

Enhance Recognition: Highlight the vital and valuable nature of effective

maintenance within organizations, focusing on its contribution to system
success and customer satisfaction.

Education and Training Strategies:

University Education: Integrating comprehensive software maintenance

into software engineering curricula, moving beyond superficial coverage.

In-service Training: Providing ongoing training opportunities within

organizations.

Self-Tuition: Individuals learning through self-study and available

resources.

Conferences and Workshops: Offering opportunities for networking, idea

exchange, and collaborative work identification. However, cost can limit
accessibility.

Hands-on Experience: Real-world maintenance work on large systems is

invaluable for skill development.

Organisational Modes
I. Combined Development and Maintenance: This approach integrates
development and maintenance responsibilities within the same team or
organizational unit. Several sub-approaches are detailed:

A. Module Ownership:

Mechanism: Team members are assigned ownership of specific software

modules. They are responsible for all changes within their assigned
modules.

Advantages: Fosters deep expertise in individual modules.

Software Maintenance 67
 Disadvantages: Lacks overall system-level responsibility, potential for
uneven workload distribution, difficulties in handling enhancements due to
unknown dependencies between modules, and challenges in enforcing
consistent coding standards across the entire system.

B. Change Ownership:

Mechanism: Individuals are responsible for complete changes, regardless

of the modules involved. This includes analysis, design, implementation,
and testing.

Advantages: Encourages adherence to system-wide standards, ensures

the integrity of changes, allows for independent coding and testing of
individual changes, and promotes thorough code inspection.

Disadvantages: Requires extensive training for new personnel (as they

need to understand the entire system), and individuals handle a series of
short-term, transient responsibilities rather than long-term ownership.

C. Work-Type (W-Type):

Mechanism: The team is organized into departments based on work type

(e.g., analysis, design, implementation, testing).

Advantages: Develops specialized skills and knowledge within each

department.

Disadvantages: Increased coordination costs and overhead due to the

need to integrate the work of different departments.

D. Application-Type (A-Type):

Mechanism: Teams are organized based on the application domain (e.g.,

health information systems, office automation).

Advantages: Develops specialized knowledge within specific application

areas.

Disadvantages: Increased coordination costs and overhead among

different application domains.

II. Separate Maintenance Department:

Software Maintenance 68
 Mechanism: Maintenance activities are handled by a dedicated department
distinct from the development department.

Advantages: Clear accountability for maintenance tasks, allows developers to

focus on new projects, facilitates and motivates more thorough acceptance
testing after development, and promotes better end-user service.

Disadvantages: Potential for demotivation among maintenance personnel due

to perceived lower status, developers losing crucial system knowledge after
handing over to the maintenance team, increased coordination costs and
communication complexities between development and maintenance, and
potential duplication of communication channels.

III. Mitigation Strategy: Maintenance Escorts:

To address the drawbacks of separate maintenance departments, some
organizations employ "maintenance escorts." These are developers who
temporarily join the maintenance team during the system's initial installation
phase. They provide support and knowledge transfer, helping to ensure smooth
operation. Sometimes, these escorts transition to become permanent members of
the maintenance team.

UNIT 4
I. Software Quality and Maintainability:

Quality is defined as "fitness for purpose" but should encompass several

factors impacting maintainability (correctness, portability, testability, usability,
reliability, efficiency, integrity, reusability, interoperability).

Standards (e.g., IEEE 1219-1993, TICKIT) are important for ensuring quality and
maintainability throughout the software lifecycle.

II. Key Quality Factors Affecting Maintainability:

Software Maintenance 69
 A. Fitness for Purpose: The system meets its specified requirements. Hard
(measurable) requirements are crucial for evaluating changes and determining
effective solutions. Vague requirements hinder maintainability.

B. Correctness: Reducing errors through structured development and

maintenance minimizes corrective maintenance efforts.

C. Portability: Ability to move the system between hardware, operating

systems, programming languages, and geographic locations. Promoting
portability enhances maintainability by avoiding platform-specific code.

D. Testability: Ease of testing enables effective change implementation; good

requirements and up-to-date documentation are essential.

E. Usability: A system must be used to warrant maintenance.

F. Reliability: System dependability; varies in importance based on

application; linked to user trust.

G. Efficiency: Optimal use of resources; explicit requirements for speed and

storage are key for addressing performance-related changes.

H. Integrity: 1) Security from unauthorized access; 2) Consistency and

reproducibility of the system configuration for maintainability.

I. Reusability: Ability to reuse components in future systems or enhancements

(discussed extensively elsewhere in the text).

J. Interoperability: Ability to interact with other systems; seamless data

exchange is vital; commercial advantages favor interoperability.

I. Evolution of Programming Languages:

First-generation languages (1GLs): Machine code (binary), highly machine-

specific, requiring deep hardware understanding.

Second-generation languages (2GLs): Assembly languages, using symbolic

addresses instead of raw memory locations; less machine-dependent than
1GLs.

Third-generation languages (3GLs): High-level languages (e.g., Pascal,

COBOL, Ada, Modula-2), machine-independent, standardized, procedural, but

Software Maintenance 70
 complex and time-consuming to use. C is considered a borderline case, closer
to assembly language than a typical 3GL.

Fourth-generation languages (4GLs): Developed to address 3GL limitations,

aiming for ease of use and faster development, often used by non-
programmers.

II. Fourth-Generation Languages (4GLs):

Purpose: To reduce reliance on professional programmers, allowing faster

application development and results for end-users.

Types: A wide range of tools including query languages (SQL), report

generators, graphics languages, decision-support languages (Oracle, Ingres),
application generators, and more. Many 4GLs combine features from multiple
categories (e.g., FOCUS).

Characteristics:

Non-procedural (specifying what instead of how): Examples include

application generators and query languages.

Ease of use (relative to 3GLs).

Database management system integration.

Fewer lines of code needed compared to 3GLs.

Intelligent default assumptions.

Online operation oriented.

(Mostly) structured code encouraged.

Easier code understanding.

Easier debugging.

Shorter learning curve.

Faster results (compared to 3GLs, but evidence may be lacking).

Automated documentation.

III. Impact of 4GLs on Software Maintenance:

Software Maintenance 71
 Increased Productivity: Faster implementation of changes due to
conciseness.

Cost Reduction: Shorter development and maintenance times lead to lower

costs.

Ease of Understanding: Easier comprehension of code for maintenance

personnel.

Automatic Documentation: Reduces manual documentation efforts.

Reduced Workload: Empowers end-users to handle modifications, lightening

the load on professionals.

IV. Weaknesses of 4GLs:

Application-Specific: Limited to specific application domains, hindering

adaptability and enhancement.

Proprietary: Vendor lock-in and code reuse challenges due to lack of

compatibility.

Overhyped Ease of Use: While simpler than 3GLs, 4GLs still require some
programming knowledge; ease of use can lead to poorly designed,
unmaintainable code.

Poor Design Potential: Ease of use can lead to poorly designed and
documented systems if used by individuals lacking software engineering
expertise or understanding of the business problem.

OBJECT ORIENTED PARADIGMS

I. Evolution of Programming Paradigms:

Early Procedural Programming: Analogous to the waterfall model; suitable for

well-defined, mathematically based problems; methods like 'code-and-fix'
and 'quick-fix' were common.

Limitations of Procedural Programming: Became insufficient for increasingly

complex, interconnected systems with undefined start and end points (e.g.,
global telecommunication systems).

Software Maintenance 72
 Emergence of Object-Oriented Programming (OOP): Developed to handle the
complexity of large, dynamic systems (air traffic control, airline reservations,
etc.). Addresses the limitations of procedural approaches for large-scale
software development and maintenance. Procedural programming remains
relevant within the context of OOP for smaller, well-defined components.

II. Object-Oriented Decomposition and Comprehension:

Complexity Management: The inherent complexity of large software systems

necessitates decomposition to manage comprehension. Human cognitive
limits restrict the ability to understand entire systems simultaneously.

Decomposition Approaches:

Algorithmic Decomposition (Top-Down Structured Design): Views the

system as a process or collection of algorithms, breaking it down into
subprocesses represented as procedures, functions, or modules. Has
weaknesses, including representation differences between design and
implementation phases.

Object-Oriented Decomposition: Views the system as a collection of

interacting objects. Each object has unique behavior and communicates
via message-passing. This approach is better suited to modeling complex,
real-world systems.

III. Core Concepts of OOP:

Objects and Classes: The real world is modeled as a set of objects with
attributes (characteristics) and operations (actions). Objects with similar
attributes belong to a class; each object is an instance of its class.

Inheritance: Objects inherit attributes from their class. Subclasses inherit

attributes and behaviors from their parent classes.

Encapsulation: Hiding implementation details behind a well-defined interface.

Promotes code reusability and maintainability. Similar to using separate
definition and implementation modules.

IV. Advantages of OOP for Maintenance:

Common Real-World View: OOP provides a clearer transformation from

analysis to implementation, reducing errors.

Software Maintenance 73
 Smaller Systems: Code reuse through common mechanisms leads to smaller,
more manageable systems.

Resilience to Change: OOP systems are more easily adaptable and evolvable.

Reduced Risks: Incremental development from smaller, tested components

mitigates risks associated with complex systems.

Code Reusability: Objects and components can be stored in libraries and

reused, increasing productivity and software quality.

V. Challenges of OOP Adoption:

Legacy Code: A large amount of existing code needs maintenance, and

converting it to OOP might not always be cost-effective.

Education and Training: Insufficient training and education on OOP in the past
hampered widespread adoption. Retraining existing personnel is expensive
and time-consuming.

Language Selection: Choosing the right OOP language is crucial but can be
risky before the paradigm is fully established.

VI. Migration to Object-Oriented Platforms:

Approaches:

Rewrite: Starting from scratch with an OOP approach (suitable only for
small systems).

Object-Oriented Analysis as Springboard: Using OOP analysis but

implementing in a non-OOP language initially, then migrating later.
Reduces the risk of choosing an unsuitable language.

Abstraction Engineering and Object Wrapping: Modeling an existing

system as a set of objects, identifying reusable components, and creating
wrappers to provide interfaces for these objects in OOP languages.
Preserves investment in existing systems while enabling OOP benefits.

VII. Retraining Personnel:

Necessity: Retraining existing personnel in OOP is crucial to leverage their

existing knowledge and experience.

Challenges: Retraining is expensive and time-consuming.

Software Maintenance 74
 MAINTENANCE TOOLS

Criteria for Selecting Tools

I. Capability:

Essential Functionality: The tool must effectively support the intended

maintenance tasks.

Prior Manual Verification: Any technique automated by the tool should first be
proven functional without automation. Automation won't fix inherently flawed
methods.

II. Features:

Beyond Basic Functionality: The tool should offer features beyond the core
task, similar to how a word processor includes spell check, thesaurus, etc.
Consider the required features and rate their importance.

Tailored Features: Select a tool with features relevant to specific maintenance

needs.

III. Cost and Benefits:

Cost-Benefit Analysis: Thoroughly evaluate the tool's cost against its

potential benefits (improved quality, productivity, responsiveness, cost
reduction).

Impact Assessment: Consider the tool's effect on various aspects of the

organization, including workflow and inter-group collaboration.

IV. Platform Compatibility:

Hardware and Software: Ensure the tool is compatible with the organization's
existing hardware and software infrastructure (e.g., IBM mainframes, PCs,
Unix/Linux).

V. Programming Language Support:

Industry Standards: Prioritize tools supporting widely used languages (e.g.,

Java, C++, Python) to ensure long-term usability and avoid vendor lock-in.

Software Maintenance 75
 Paradigm Shifts: In the event of migrating to a new programming paradigm
(e.g., object-oriented), ensure the tool supports the target language.

VI. Ease of Use:

User Familiarity: Tools with a familiar interface (e.g., menu-driven vs.

command-line) are more likely to be readily adopted.

Usability Testing: Consider user training and the potential learning curve.

VII. Openness of Architecture:

Integration with Other Tools: Prioritize tools that can be integrated with other
software tools from different vendors for flexibility and extensibility.

Avoid Vendor Lock-in: Avoid proprietary tools that restrict integration and limit
choices.

VIII. Vendor Stability:

Company Reputation: Research the vendor's reputation and stability to

minimize the risk of support issues if the company goes out of business.

Open Architecture Mitigation: This concern is less critical if the tool has an
open architecture, allowing for easier switching to alternative solutions.

IX. Organizational Culture:

Work Patterns and Processes: The tool should align with the organization's
existing workflow and culture to maximize adoption and minimize disruption.
Consider user training and integration within existing processes.

Taxonomy of Tools
I. Program Understanding and Reverse Engineering Tools: These tools help you
grasp how existing software works:

Program Slicer: Shows you only the code parts affecting a specific variable.
Like zooming in on a relevant section.

Static Analyzer: Examines the code without running it, providing an overview
of its structure (modules, functions, variables). Think of it as a code map.

Software Maintenance 76
 Dynamic Analyzer: Watches the code while it runs, showing you what paths
the program takes. Like tracking a car's route.

Data Flow Analyzer: Traces where data goes in the code, crucial for seeing
how changes might affect other parts. Like tracing a river's path.

Cross-Referencer: Creates an index showing where each variable or function

is used. Like a code dictionary.

Dependency Analyzer: Shows the relationships between different parts of the

code. Highlights what depends on what.

Transformation Tool: Converts code from one format to another (like text to a
diagram), making it easier to understand.

II. Tools to Support Testing: Tools to check if changes work correctly:

Simulator: Creates a fake environment to test changes safely before putting

them into the real system.

Test Case Generator: Automatically creates test scenarios based on your

requirements.

Test Path Generator: Figures out all the possible ways your code could run,
making sure you test all scenarios.

III. Tools to Support Configuration Management: Tools to track code versions

and changes over time:

Source Code Control System (SCCS): A system to manage different versions

of code, like Git or SVN. Prevents multiple people from making conflicting
changes at the same time.

Other Utilities: Basic file management tools ( ls , dir , find ) also help organize
the project's files.

IV. Other Important Tools:

Documentation Tools: Tools to create and update the software's

documentation.

Complexity Assessment Tools: Tools that measure how complicated the code
is, helping to find areas that are more prone to bugs.

Software Maintenance 77