SOFTWARE MAINTENANCE

Lect. 07
 IEEE/EIA 1219 Maintenance Process

The standard focuses on a seven-phases:

1. Problem Identification.
2. Analysis.
3. Design.
4. Implementation.
5. System Test.
6. Acceptance Test.
7. Delivery.

Seven phases of IEEE maintenance process ©IEEE, 2004

 IEEE/EIA 1219 Maintenance Process

Each of the seven activities has five associated attributes as follows:

1. Activity definition: This refers to the implementation process of the activity.

2. Input: This refers to the items that are required as input to the activity.
3. Output: This refers to the items that are produced by the activity.
4. Control: This refers to those items that provide control over the activity.
5. Metrics: This refers to the items that are measured during the execution of the activity.
 IEEE Maintenance Process

PROBLEM IDENTIFICATION PHASE

• A request for change to the software is normally made by the users of the software system or the customers,
and it starts the maintenance process.
• The request for change (CR) is submitted in the form of a modification request (MR) for a correction or for
an enhancement. MR & CR are used interchangeably.
• Activities included in this phase are as follows:
• Reject or accept the MR,
• Identify and estimate the resources needed to change the system; and
• Put the MR in a batch of changes scheduled for implementation.

Note: Modification Request (MR) and Change Request (CR).

 IEEE Maintenance Process

ANALYSIS PHASE
The process is viewed to have two major components: feasibility analysis and detailed analysis.
• First, feasibility analysis is performed to:
• determine the impact of the change;
• investigate other possible solutions including prototyping;
• determine the benefits of making the change.
• The second phase identifies:
• the software components involved;
• an overall test strategy; and
• an implementation plan.
 IEEE Maintenance Process

DESIGN PHASE
Activities of this phase are as follows:
1. Identify the affected software components.
2. Modify the software components.
3. Document the changes.
4. Create a test suite for the new design.
5. Select test cases for regression testing.
 IEEE Maintenance Process

IMPLEMENTATION PHASE
The activities executed in this phase are:
• Writing new code and performing unit testing,
• Integrating changed code,
• Conducting integration and regression testing,
• Performing risk analysis, and
• Reviewing the system for test-readiness.
 IEEE Maintenance Process

SYSTEM TEST PHASE

In this phase tests are performed on the full system to ensure that the modified system complies with the original
requirements as well as the new modifications.
System-level testing comprises a broad spectrum of testing activities:
• Functionality testing
• Robustness testing
• Stability testing
• Load testing
• Performance testing
• Security testing and
• Regression testing.
 IEEE Maintenance Process

ACCEPTANCE TEST PHASE

Acceptance testing is performed on a completely integrated system, and it involves customers, users, or their
representatives.
The main objective of acceptance testing is to assess the overall quality of the system, rather than actively
identify defects.
An important concept in acceptance testing is the customer’s expectation from the system.
 IEEE Maintenance Process

DELIVERY PHASE
In this phase, the changed system is released to customers for installation and operation.
Included in this phase are the following activities:
• Notify the user community
• Perform installation and training
• and Develop an archival version of the system for backup.
Software Configuration Management
 Software Configuration Management

• The concept of configuration management (CM) was developed to manage changes in large systems.
• Software Configuration Management (SCM) is applied to software products.
o It handles the control of all product items and changes to those items.
o The product items include document, executable software, source code, hardware, and disks.

• SCM accrues two kinds of benefits to an organization:

• SCM ensures that development processes are traceable and systematic so that all changes are
precisely managed.
• SCM enhances the quality of the delivered system and the productivity of the maintainers.
 Software Configuration Management

• The objectives of SCM are to:

• Uniquely identify every version of every software at various points in time.
• Retain past versions of documentations and software.
• Provide a trail of audit for all modifications performed.
• Throughout the software life-cycle, maintain the traceability and integrity of the system changes.
 Software Configuration Management

Projects benefit from effective SCM as follows:

1. Confusion is reduced and order is established.
2. To maintain product integrity, the necessary activities are organized.
3. Correct product configurations are ensured.
4. Quality is ensured – and better quality software consumes less maintenance efforts.
5. Productivity is improved, because analysts and programmers know exactly where to find any piece of the
software.
6. Conformance with requirements is enabled.
7. A reliable working environment is provided.
8. Compliance with standards is enhanced.
Software Configuration Management (SCM) PROCESS

A process for implementing SCM

 Software Configuration Management (SCM) PROCESS

PLANNING
Planning is begun with two activities:
1. Define the SCM process, and
2. Establish procedures.
• A key step during planning is the identification of the stakeholders.
• The stakeholders in a configuration management are the maintainers, development engineers, test engineers,
quality assurance auditors, users, and the management.
• Various SCM tools are used to maintain configuration history and facilitate the SCM process flow. Examples
of such tools are CVS (concurrent version system) and Clearcase.
 Software Configuration Management (SCM) PROCESS

ESTABLISHING BASELINE

• Once an SCM program plan is in place, the next step is identification of items (code, data, and documents)
that are the subject of configuration control.
• After the configuration items identified, a software baseline library is established to make the set of
configurable items publicly available.
• The library, called repository, is the heart of the SCM system.
• The repository has information about all the baselined items.
 Software Configuration Management (SCM) PROCESS

ESTABLISHING BASELINE

The process of baseline (or re-baseline for a change) involve the following activities:
1. Create a snapshot of the current version of the product and its configuration items, and allocate a
configuration identifier to the entire configuration.
2. Allocate version numbers to the configuration items and check in the configuration.
3. Store the approved authority information as part of meta data in the repository.
4. Broadcast all the above information to the stakeholders.
5. To accurately identify the configuration version, design a schema of words, numbers, or letters for common
types of configuration items.
 Software Configuration Management (SCM) PROCESS

CONTROLLING, DOCUMENTING AND AUDITING

After establishing a baseline, it is important to:

1. keep the actual and the documented configuration identical;
2. ensure that the baseline complies with a project’s configuration described in the requirements document.
 Software Configuration Management (SCM) PROCESS

CONTROLLING, DOCUMENTING AND AUDITING

• The stakeholders specified in the SCM plan review and evaluate all changes to the configuration.
• After their evaluations, both approvals and disapprovals are documented.
• Approved changes are tracked until they are verified .
• Next, the appropriate baseline is revised in conjunction with all relevant documents, and reports are
generated.
• At regular intervals, records and products are audited.
• The three steps in the cycle, namely, controlling, documenting, and auditing, are repeatedly executed
throughout the lifetime of the project.
 Change Request

• A change request (CR), also called a modification request (MR), is a vehicle for recording information
about a system defect, requested enhancement, or quality improvement.
• Change requests are placed under the control of a change management system.
• Change management systems control changes by an automated system in the form of work-flow.
• The basic objective of change management is to uniquely identify, describe, and track the status of each
requested change.
 Change Request Workflow

The objectives of change management are as follows:

• Provide a common method for communication among stakeholders.
• Uniquely identify and track the status of each CR. This feature simplifies progress reporting and
provides better control over changes.
• Maintain a database about all changes to the system. This information can be used for monitoring and
measuring metrics.
 Change Request Workflow

• A change request describes the desires and needs of users which the system is expected to implement.
• While describing a CR, two factors need to be taken into account:
• Correctness of CRs, and
• Clear communication of CRs to the stakeholders.

CRs need to be represented in an unambiguous manner, and made available in a centralized repository.
 Change Request Workflow

The life-cycle of a CR has been illustrated in following figure, by means of a state-transition diagram.
Each state represents a distinct stage in the life-cycle of a CR.

State transition diagram of a CR