UNIT 6

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
Software Engineering 1
CO
 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.

Software Engineering 2
CO
 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.

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.

Software Engineering 3
CO
Software Engineering 4
CO
 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.

Software Engineering 5
CO
 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.

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.

Software Engineering 6
CO
 Efficiency improvements Making the software run
faster or use resources more efficiently.

Software Engineering 7
CO
 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.

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.

Software Maintenance Process

Software Engineering 8
CO
 Program Understanding
The first step consists of analyzing the program to understand.
Generating a Particular maintenance problem
The second phase consists of creating a particular maintenance
proposal to accomplish the implementation of the maintenance
goals.
Ripple Effect
The third step consists of accounting for all of the ripple effects as a
consequence of program modifications.
Modified Program Testing
The fourth step consists of testing the modified program to ensure that
the revised application has at least the same reliability level as prior.
Maintainability
Each of these four steps and their associated software quality
attributes is critical to the maintenance process. All of these methods
must be combined to form maintainability.

Software Engineering 9
CO
 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.

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.

Software Engineering 10
CO
 Quick Fix Model: A Band-Aid Approach
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:

 Identify the Issue: A critical problem emerges, disrupting the

software's functionality or causing significant issues.

 Immediate Solution: The team rapidly implements a temporary fix

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

 Minimal Testing: Limited testing is conducted to ensure the quick

fix doesn't worsen the existing situation but often overlooks
potential side effects.

 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.
Software Engineering 11
CO
 Simplicity: Easy to understand and implement, requiring minimal
planning and documentation.

Software Engineering 12
CO
 Cost-Effective Short Term): Initial implementation is often
quick and inexpensive, especially for smaller issues.

Why is it still used?

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
 In 1983 Boehm proposed a model for the maintenance process
based upon economic models and principles.

 Economic decisions are a major driving force behind many

processes.
Software Engineering 13
CO
  Boehm's thesis was that economic models and principles
could not only improve productivity in maintenance but also
help understanding of the

Software Engineering 14
CO
 process.

 Boehm represents the maintenance process as a closed loop cycle.

 He theorize that it is the stage where management decisions are

made that drives the process.

 In this stage, a set of approved changes is determined by applying

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

 The approved changes are accompanied by their own budgets

which will largely determine the extent and type of resource
expended.

Osborne's Model
 Another approach is proposed by Osborne .

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

 Where as, other models tend to assume some facet of an ideal

situation - the existence of full documentation.

Software Engineering 15
CO
  Example-Osborne's model makes allowance for how things are
rather than how we would like them to be.

 The maintenance model is treated as continuous iterations of the

software life- cycle with.

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

 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.

 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;

Software Engineering 16
CO
 a software quality assurance program which establishes quality
assurance requirements;

a means of verifying that maintenance goals have been met;

performance review to provide feedback to managers

Iterative Enhancement Model

 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.

 It is similar to the evolutionary development paradigm during pre-

installation.

 Originally proposed as a development model but well suited to

maintenance.

 The motivation for this model was the environment where

requirements were not fully understood and a full system could not
be built.

 Adapted for maintenance, the model assumes complete

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

 The model is effectively a three-stage cycle -

Analysis.

Characterization of proposed modifications.

Redesign and implementation

Software Engineering 17
CO
 The Reuse-Oriented Model
 This model is based on the principle that maintenance could be
viewed as an activity involving the reuse of existing program
components.

 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

 Detailed framework is required for the classification of

components and the possible modifications.

 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.

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

ESTIMATION OF MAINTENANCE COSTS

Software Engineering 18
CO
 Belady and Lehman Model

Software Engineering 19
CO
 This model indicates that the effort and cost can increase
exponentially if poor software
development approach is used and the person or group that used the
approach is no longer
available to perform maintenance.

Boehmʼs Model
Boehm used a quantity called Annual Change Traffic ACT which is
defined as:

Software Engineering 20
CO
 “The fraction of a software productʼs source instructions which
undergo change during a
year either through addition, deletion or modificationˮ.

Software Engineering 21
CO
 Reverse engineering -
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 at

higher levels of abstraction

Purpose and Objectives of Reverse Engineering:

Purpose:

Software Engineering 22
CO
 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

Software Engineering 23
CO
 changes.

Software Engineering 24
CO
 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 Engineering 25
CO
 1. Redocumentation

Definition Recreates a semantically equivalent representation of a

system at the same abstraction level.

Goals:

 Create alternative views to enhance understanding (e.g.,

generate hierarchical data flow or control flow diagrams).

 Improve existing documentation, which often becomes

outdated or was never properly developed.

 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 Engineering 26
CO
  Recover meaningful higher-level design abstractions.

 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 Engineering 27
CO
 Benefits:

 The recovered specification supports software maintenance

even without access to the source code.

 It helps maintainers gain the necessary understanding to

modify the system.

 A well-represented specification can aid in the

development or maintenance of similar systems.

 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 Engineering 28
CO
 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:

 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.

 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.

 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 Engineering 29
CO
 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:

 Reverse engineering Understanding the existing system and

representing it in a new form.

 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):

 Encapsulation

 Transformation

 Normalization

 Interpretation

 Abstraction

Remaining 3 layers (forward engineering):

6. Causation
7.Regeneration
8. Certification

Applications of SCORE/RM:

 Helps maintainers understand code, generate documentation,

and make the code more maintainable.

Software Engineering 30
CO
  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 Engineering 31
CO
 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.

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.
Software Engineering 32
CO
 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.

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.
Software Engineering 33
CO
 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.

Alternative Documentation Classification Macro's Scheme):

Software Engineering 34
CO
 User Manuals: Describe system functionality without
implementation or operational details.

Operator Manuals: Explain system usage and fault recovery.

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.

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

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:

Software Engineering 36
CO
 Managing maintenance personnel for increased productivity, job
satisfaction, and system quality (through personnel selection,
motivation, team structure, education, and training).

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
Software Engineering 37
CO
 avoid stifling innovation.

Software Engineering 38
CO
 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.

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:

Software Engineering 39
CO
 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:

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-

Software Engineering 40
CO
 approaches are detailed:

A. Module Ownership:

Software Engineering 41
CO
 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.

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.
Software Engineering 42
CO
 Disadvantages: Increased coordination costs and
overhead among different application domains.

II. Separate Maintenance Department:

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.
A different attempt
to improve software quality is based on International Standards
Organization ISO 9000
Series standards.

Software Engineering 43
CO