Chapter 3: Software Maintenance

Process

Omar MeqdadiSE 3860 Lecture 3

Department of Computer Science and Software Engineering University of Wisconsin-Platteville

2

Topic Covered

Maintenance Types Maintenance Prediction Maintenance Process

3

Maintenance Types

Corrective Maintenance: correcting errors and bugs Adaptive Maintenance: adapting to changes in the

environment (both hardware and software) Example: Porting KDE system from Qt3 to Qt4

Perfective Maintenance: adapting to changing user requirements Example: performance improvements, new requirements

Preventive Maintenance: increasing the system’s maintainability Example: Re-Engineering , Refactoring , and updating

documentation

4

Maintenance Types

5

Distribution of Maintenance Types(Lientz and Swanson)

corrective 21%

adaptive 25%

preventive 4%

perfective 50%

Maintenance Prediction

Maintenance prediction is concerned with assessing which parts of the system may cause problems and have high maintenance costs Change acceptance depends on the maintainability of the

components affected by the change Implementing changes degrades the system and reduces its

maintainability Maintenance costs depend on the number of changes and

costs of change depend on maintainability

Maintenance Prediction

Change Prediction

Change Prediction The number of required changes Understanding of the relationships between a system and

its environment Tightly coupled systems require changes whenever the

environment is changed Factors influencing this relationship are

Number and complexity of system interfaces Number of inherently volatile system requirements The business processes where the system is used

9

Maintenance Process

Request for change Planning phase Software comprehension Impact analysis Implementation of the change Focus of the change Change propagation Verification Documentation

Maintenance Process

Change Requests

Change requests are requests for system changes from users, customers or management

In principle, all change requests should be carefully analysed as part of the maintenance process and then implemented

In practice, some change requests must be implemented urgently Fault repair Changes to the system’s environment Urgently required business changes

Change Request Management

Change Management to uniquely identify, describe and track the status of each requested change

Change requests and their status are recorded and tracked in a Change Management Tracking System Manage the system release Analysis of the types and frequency of defects Communicate to maintainers, managers and clients

Project Management and the Quality Assurance team receive information about the status of the Change Requests

More details in Chapter 4

Impact of Change

Evaluate Change Requests Identify all systems/system components affected by a

change request Evaluation of many risks associated with the change Complexity of the change

Estimate Resources develops an estimate of the

Resources needed to accomplish the change Time and schedule Cost and efforts

Measuring Impact of Change

To measure the impact of a change, you need: Program (Software ) Comprehension Size of required changes

LOC Number of functions, routine , and classes that will be

touched

Historical information Productivity Rate, Average LOC per Routine

Time required to complete the system changes

Measuring Impact of Change

Types of System Changes Types of Change Impacts

Requirements changes Affect design, coding, and testingDocument update

Design changes Affect coding and testsAffect associated components Affect system architectureAffect related component interactions

Implementation changes Affect test cases, test data, test scriptsAffect test specification.Code change impact s

- Test changes Affect other tests.

Affect test documentation

Document changes Affect other documents.

Measuring Impact of Change

Program Comprehension (Covered in Chapters 8,9, &10) The words "understanding" and "comprehension" are used as

synonyms 50-90% of the maintenance time is spent in comprehension

Fjelstad-Hamlen found that programmers: studied the program 3.5 times longer than the documents Spent more time in comprehension than in implementing

enhancements

Comprehension is affected by Comprehensibility of the program Skills of the maintainer Information needs and sources

Measuring Impact of Change

Methodologies: Work product: any development artifact whose change is

significant Horizontal traceability: relationships of components across

collections of work products Vertical traceability: relationships among parts of a work

product More details in Chapters: 8,9, & 10

Measuring Impact of Change

Example: Horizontal Traceability

Change Implementation

Change Implementation

Example: Corrective Maintenance includes all repairs of defects in an existing system

Locateerror

Designerror repair

Repairerror

Re-testprogram

Testresults Specification Test

cases

Change Implementation

Example: Corrective Maintenance Defects types:

Requirements specification errors Design errors Coding errors

Facts: 80% of all problems stem from requirements and design Repairing a defect has a 20-50% change of introducing

another defect Person who makes the repair is not generally the person who

wrote the code

Change Implementation

Example: Preventive Maintenance Polish or refine the quality of the software or the

documentation Re-engineering ( Chapters 6 & 7)

Rewriting and upgrading documentation Restructuring poorly written code

Fact Preventive maintenance reduces the system future

maintenance costs

Change Implementation

Example: Adaptive Maintenance Modify software to adapt to changes in the hardware or

software environment Real Examples:

Porting the KDE (K Desktop Environment) system from Qt3 to support Qt4

Modifying ABB industrial systems to deal with changes in the VxWorks and Microsoft Visual Studio (2003 to 2005)

Change Implementation

Example: Adaptive Maintenance

Change Testing

Only modified components need to be reviewed Develop new test cases that exercise the changes Existing and new test cases are required to test the

changes Test results are compared against previous test results

(Regression Testing) More details in Chapters 11 & 12

System Release

Deliver the system to the user System release includes:

Documentation Source code Hardware Training materials Backup procedures

System Release Planning

Determine the contents of a system release (incremental approach)

Establish the schedule of system releases Communicates between maintainers and users Plan hardware, operational procedures and backup

procedures More details in Chapter 4