MAINTENANCE

Software Engineering Roadmap: Chapter 10 Focus

Identify
corporate Keep application useful
practices after delivery
- Fix defects
- Enhance the application
Plan
project

Maintain
Analyze
requirements
Integrate
Design & test system
Implement Test units
 Development
$
Learning Goals of This Chapter
De

• Understand how Maintenance

“Software Maintenance” is defined

• Appreciate the cost of maintenance
• Understand software maintenance issues
• Organize for maintenance
• Use IEEE maintenance standard
• Apply maintenance metrics
 Service a Maintenance Request 1
1. Be prepared to keep required metrics. Include..
– … lines of code added
– … lines of code changed
– … time taken: 1. preparation 2. design 3. code 4. test
2. Ensure that the request has been approved
3. Understand the problem thoroughly
– reproduce the problem
• otherwise get clarification
4. Classify the MR as repair or enhancement
5. Decide whether the implementation requires a
redesign at a higher level
– if so, consider batching with other MR’s
6. Design the required modification
(i.e., incorporate the change)
 Service a Maintenance Request 2

7. Plan transition from current design

8. Assess change’s impact throughout the application
– small changes can have major impact!
9. Implement the changes
10. Perform unit testing on the changed parts
11. Perform regression testing
– ensure changes haven’t compromised existing capabilities
12. Perform system testing with new capabilities
13. Update the configuration, requirement, design and
test documentation
 Software Maintenance Issues

• Management
– Return on investment hard to define
• Process
– Extensive coordination required to
handle stream of Maintenance Requests
• Technical
– Covering full impact of changes
– Testing very expensive compared with
the utility of each change
• focused tests ideal but expensive
• regression testing still required
 Estimate
Estimate
Activity Activity (person-
(person-days)
days)

Estimating the Cost of Servicing a Maintenance Request

1. Understand the problem and identify the 6. Compile and integrate into
2-5 2-3
functions that must be modified or added. baseline

2. Design the changes 1-4 7. Test functionality of changes 2-4

3. Perform impact analysis 1-4 8. Perform regression testing 2-4

9. Release new baseline and

4. Implement changes in source code 1-4 1
report results

5. Change SRS, SDD, STP, configuration

2-6 TOTAL 14 - 35
status

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
 RoadMap to Establish Maintenance (After Pigoski)

1a. Design for

2. Determine main-
maintainability-- section 6.3
tenance scope
1b. Ensure supportability
• all types?
1c. Plan for transition to • corrective only?
maintenance • limited corrective?
1d. Plan post-delivery logistics -- section 2

4. Develop maintenance plan

3. Identify maintainers • Change control approval procedure
• in-house? • Help desk
• contracted? • etc.
-- section 5

5. Estimate costs 6. Perform maintenance

-- table 10.1 -- section 3
2. Types of software maintenance
 Types of Maintenance Lientz & Swanson

• Corrective
Fixing – defect identification and removal
• Adaptive
– changes resulting from operating
system, hardware or DBMS changes
• Perfective
Enhancing – changes resulting from user requests
• Preventative
– changes made to the software to
make it more maintainable
Example of Corrective
Maintenance Request Maintenance Request 78
The computations that ensue when the
player changes the value of a quality, are
supposed to keep the total invariant, but
they do not. For example, if the qualities
are strength = 10, patience = 0.8 and
endurance = 0.8 (sum = 11.6), and the player
adjusts strength to 11, then the result is
strength = 11, patience = 0 and endurance =
0, which do not sum to 11.6.
 Example of Perfective Maintenance Request

Maintenance Request 162

Modify Encounter so that the game
begins with areas and connections a
coordinated style.
 Example of Perfective Maintenance Request

Maintenance Request 162

Modify Encounter so that the game
begins with areas and connections in a
coordinated style. When the player
achieves level 2 status, all areas and
connections are displayed in an
enhanced coordinated style, which is
special to level 2 etc. The art department
will provide the required images.
3. Maintenance techniques
 Impact of MR #162

Requirements Add: “change appearance when

player achieves new levels”

Architecture Accommodate ability to change

global appearance: use
Abstract Factory design
pattern
 Impact of MR #162

Requirements Add: “change appearance when

player achieves new levels”

Architecture Accommodate ability to change

global appearance: use
Detailed design Abstract Factory design
pattern
Interface specs
Add interface methods
Function code for Layout package

Add classes and methods

Module (e.g., package) code as per detailed design

Modify gameplay
System code control code
 Expansion Without Reengineering

Maintenance With and Added Added

7/98 1/99
Without Reengineering

Added Added
The Beginning Product
1/98 7/99
 Expansion Without Reengineering

Maintenance With and Added Added

7/98 1/99
Without Reengineering

Added Added
The Beginning Product
1/98 7/99

Reengineered Expansion
Re-engineering Management Training;
Re-engineering Encounter to Conform
Current Encounter

Software re-
engineering

Play management
version
of Encounter
Re-engineering Encounter to Conform to Management
Training
Current Encounter

Business process Re-engineering

Specify
Write training
Take follow-up
objectives
introductory courses
Senior mgmt. courses
Management
Take Evaluate
Middle intermediate results
Management mgmt. courses
Management
New
simulation adaptation
Management
of Encounter
• Continue to maintain
• Discontinue maintenance and --
1. Replace
Options for
• buy replacement
Dealing with
• OR build replacement
OR Legacy
– reverse engineer legacy system
– or develop new architecture
Systems
– possibly replace in phases

2. Incorporate as integral part of new application

OR • freeze maintenance
3. Encapsulate and use as server
• consider using Adapter design pattern
 Legacy Architectures
Incorporation Encapsulation

New system

Extensions
Legacy Modifications
Application

(fig i)0
 Legacy Architectures
uses...
Incorporation Encapsulation
New system
(fig ed)
New application
Legacy
Adapter 3
Application Adapter 2
New system Adapter 1
Extensions
Legacy Modifications
(fig ew)
Application
New system
wrapper
(fig i) New application
Legacy
Application Adapter 3
Adapter 2
Adapter 1
4. IEEE standard 840-1992
1. Problem identification
1.1 Input 1.2 Process

1.3 Control 1.4 Output IEEE 840-1994

1.5 Quality factors “Software
1.6 Metrics Maintenance”
2. Analysis
Table of Contents
2.1 Input
2.2 Process
2.2.1 Feasibility analysis
2.2.2 Detailed analysis
2.3-2.6 Control, Output,
Quality factors, Metrics.
3. Design
3.1-3.6 Input, Process, Control,
Output, Quality factors, Metrics.
1. Problem identification 4. Implementation
1.1 Input 1.2 Process 4.1 Input
4.2 Process
1.3 Control 1.4 Output 4.2.1 Coding and & testing
1.5 Quality factors
IEEE 840-1994
4.2.3 Risk analysis & review
1.6 Metrics “Software 4.2.4 Test-readiness review
2. Analysis Maintenance” 4.3-4.6 Control, Output,
Table of Contents Quality factors, Metrics.
2.1 Input
2.2 Process 5. System test
2.2.1 Feasibility analysis 5.1-5.6 Input, Process, Control,
2.2.2 Detailed analysis Output, Quality factors, Metrics.
2.3-2.6 Control, Output, 6. Acceptance test
Quality factors, Metrics. 6.1-6.6 Input, Process, Control,
3. Design Output, Quality factors, Metrics.
3.1-3.6 Input, Process, Control, 7. Delivery
Output, Quality factors, Metrics. 7.1-7.6 Input, Process, Control,
Output, Quality factors, Metrics.
Five Attributes of Each Maintenance Step (IEEE)
Step
1. Problem identification
2. Analysis
3. Design
4. Implementation
5. System test
6. Acceptance test
7. Delivery
 Five Attributes of Each Maintenance Step (IEEE)
Step Attributes
1. Problem identification a. Input life cycle arti-
facts for this step
2. Analysis b. Process required for
3. Design this step
c. How the process is
4. Implementation controlled
d. Output life cycle
5. System test artifacts
e. Process quality factors
6. Acceptance test involved
7. Delivery f. Metrics for this step
 IEEE 1219-1992
Maintenance phase 1: Problem Identification

a. Input •The Maintenance Request (MR)

•Assign change number

•Classify by type and severity etc.
b. Process •Accept or reject change
•Make preliminary cost estimate
•Prioritize

•Identify MR uniquely
c. Control •Enter MR into repository

d. Output •Validated MR

e. Selected quality •Clarity of the MR

factors •Correctness of the MR (e.g., type)

•Number of omissions in the MR

f. Selected metrics •Number of MR submissions to date
•Number of duplicate MR's
•Time expected to confirm the problem
 IEEE 1219-1992
Maintenance phase 2: Problem Analysis

a. Input •Original project documentation

•Validated MR from the identification phase

•Study feasibility of the MR

•Investigate impact of the MR
b. Process
•Perform detailed analysis of the work required
•Refine the MR description

•Conduct technical review

•Verify …
c. Control …test strategy appropriate
…documentation updated
•Identify safety and security issues

•Feasibility report
•Detailed analysis report, including impact
•Updated requirements
d. Output •Preliminary modification list
•Implementation plan
•Test strategy

e. Selected quality
factors •Comprehensibility of the analysis

•Number of requirements that must be changed

f. Selected metrics •Effort (required to analyze the MR)
•Elapsed time
 IEEE 1219-1992
Maintenance phase 3: Design

a. Input •Original project documentation

•Analysis from the previous phase

•Create test cases

•Revise …
b. Process …requirements
…implementation plan

•Verify design
c. Control •Inspect design and test cases

•Revised …
…modification list
…detailed analysis
d. Output …implementation plan
•Updated …
…design baseline
…test plans

•Flexibility (of the design)

e. Selected quality •Traceability
factors •Reusability
•Comprehensibility

•Effort in person-hours
f. Selected metrics •Elapsed time
•Number of applications of the change
EncounterEnvironment Package (Before Modification)

GameEnvironment

GameArea GameCharacter

GameAreaConnection

Area EncounterAreaConnection

EncounterEnvironment

EncounterEnvironment
 Client
1..n
EncounterEnvironment EnvironmentFactory
getArea()
Area buildConnection()

Level3Area
Abstract
Factory
Applied to
Encounter

Level3Factory
getArea()
getAreaConnection()
 Client Abstract
1..n Factory
EncounterEnvironment EnvironmentFactory Applied to
getArea() Encounter
Area getConnection()

EncounterAreaConnection

Level1Area Level2Area Level3Area

Level1AreaConnection Level2AreaConnection Level3AreaConnection

«create»

Level1Factory Level2Factory Level3Factory

getArea() getArea() getArea()
getAreaConnection() getAreaConnection() getAreaConnection()
Migration Plan for Level-based Graphics
 Migration Plan for
Level-based Graphics
 IEEE 1219-1992
Maintenance phase 4: Implementation

•Original source code

a. Input •Original project documentation
•Detailed design from previous phase

•Make code changes and additions

b. Process •Perform unit tests
•Review readiness for system testing

•Inspect code
•Verify
c. Control
CM control of new code
Traceability of new code

•Updated …
…software
d. Output
…unit test reports
…user documents

•Flexibility
•Traceability
e. Selected quality
•Comprehensibility
factors •Maintainability
•Reliability

•Lines of code
f. Selected metrics •Error rate
5. The management of maintenance
 A Typical Maintenance
Flow
Written
MR’s

Customer
nominal Proposed
path M. R.’s
Help desk

Approved
M. R.’s

Maintenance Current source Change control board

engineer & documentation

Modified source
& documentation
 A Typical Maintenance
Flow Marketing

nominal Written
path MR’s
Proposed
Customer Maintenance
manager M. R.’s
Help desk

Approved
M. R.’s

Maintenance Current source Change control board

engineer & documentation

Modified source Rejected

& documentation MR’s
1. Interface with customer

Help desk Complaints Marketing

Docu- Patch
ment (optional)
patch
Execute
with
patch
Maintenance
& Patching
 Maintenance
1. Get maintenance request
& Patching
optional
2. Approve changes
Docu- Create
ment patch
3. Plan changes patch
Assess
Coordinate
impact Execute
with
patch
4. Change code and documentation

Implement Test changes

Remove patch
Document
Release Update documentation
patch removal
 Maintenance Patches disadvantage
advantages
s
• Keeps customers • Duplicates work
satisfied in the – patch and final fix both
short run implemented
• Enables continued • Sometimes never replaced
operation and – proper fix deferred forever!
testing without • Complicates final fix
repeated – must remove
prevalence of the • Complicates
defect documentation process
• Avoids masking
other defects
• Enables test of fix
 Ranked Problems in Maintenance (Deklava)

1. Changing priorities 7. Measurement of

2. Testing methods contributions
3. Performance 8. Low morale due to lack
measurement of recognition or
3. Incomplete or non- respect
existent system 9. Lack of personnel,
documentation especially experienced
5. Adapting to changing 10. Lack of maintenance
business requirements methodology,
6. Backlog size standards, procedures
and tools . . . . .
 Top priority . . . Examples of Changing Priorities
. . . at release :
• Make this most bug-free game on the market
– action: eliminate as many defects as possible
. . . two months after release:
• Add more features than our leading
competitor
– action: add enhancements rapidly
. . . six months after release:
• Reduce spiraling cost of maintenance
– action: eliminate most severe defects only
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
6. Qualities in maintenance
 Maintenance Metrics

• Number of lines of code under

maintenance

• Person-months to perform various

maintenance tasks

• Defect count
 Selected Corresponding Metrics
Goal Question Note: The numbered metrics are from the IEEE.

•(1) Fault density

How many problems are •(30) Mean time to failure
affecting the customer? •Break / fix ratio
[ Number of defects introduced by maintenance actions ] / [Number of defects repaired ]

•Fault closure
Average time required to correct a defect, from start of correction work.
How long does it take to •Fault open duration
Average time from defect detection to validated correction.
fix a problem?
Maximize customer
satisfaction Maintenance Metrics Classified by Goal
•Staff utilization per task type:
Average person-months to (a) detect each defect and (b) repair each defect.
•Computer utilization
Where are the Average time / CPU time per defect.
bottlenecks?

Effort and time spent, per defect and per severity category …
o… planning
Optimize effort and Where are resources o… reproducing customer finding
schedule being used? o… reporting error
o… repairing
o… enhancing

Minimize defects Where are defects most

(continue focused •(13) Number of entries and exits per module
development-type testing) likely to be found?
•(16) Cyclotomic complexity
 Predicting Relative Maintenance Effort
Module size as % of total l.o.c.
90
% non-commented l.o.c. in
80 module
70
Expect high
maintenance
60 costs
50
40
Expect low
30 maintenance
costs
20
10
0
Accounts Timesheet Sick day Benefits
Modules:
Received recorder reporter
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
 Managing Maintenance
Example profile of “fixing”-type MR’s
800

700 # MR's received

# MR's completed
600
# MR's cancelled
500 # MR's open

400

300

200

100

0
1993 1994 1995 1996
 Profiles of Open Maintenance Requests

E.g., in April, the average “Fixing”

enhancement MR had MR’s
# weeks
open been open for 8 weeks. Enhancement
10 MR’s

5
ry
y

ua

t
ar

ch

s
gu
ril
br

ne
nu

ay
ar

ly

Au
Ap

Ju
Fe

Ju
Ja

M
M

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
 Profiles of Open Maintenance Requests

E.g., in April, the average “Fixing”

enhancement MR had MR’s
# weeks
open been open for 8 weeks. Enhancement
10 MR’s

5
ry
y

ua

t
ar

ch

s
gu
ril
br

ne
nu

ay
ar

ly

Au
Ap

Ju
Fe

Ju
Ja

M
M
 Effects on Maintainability of Source Code Properties

S OU R C E C OD E

CONTROL STRUCTURE IN F OR M A T ION C O D E D E T A IL

STRUCTURE

S YS T E M C O M P ON E N T S YS T E M C O M P ON E N T S YS T E M C O M P ON E N T

....

From Oman [Om1]

Effects on Maintainability of
Source Code Properties SO URCE CO DE Aspects of source code

C O N T R O L ST R U C T U RE IN F O R M A T IO N C O D E D E T A IL
STRUCTURE

SYSTEM C O M P O N E NT SYSTEM C O M P O N E NT SYSTEM C O M P O N E NT

The maintainability of a product • statement formatting

is affected by this property. -- affects a product’s
maintainability, (but more is
“+” means that more of this not necessarily better)
property usually makes an • vertical spacing
application more maintainable;
• horizontal spacing
“-” means that more of the
property usually makes an • + intra-module
application less maintainable. commenting -- usually,
more comments with the code
make a product more
maintainable
From Oman [Om1]
Effects on Maintainability of Source From Oman [Om1]
S OU R C E C OD E
Code Properties

CONTROL STRUCTURE IN F OR M A T ION C O D E D E T A IL

STRUCTURE

S YS T E M C O M P ON E N T S YS T E M C O M P ON E N T S YS T E M C O M P ON E N T

+modularity -complexity -global data -local data +overall statement

types types program formatting
-complexity +use of formatting
structured -global data -local data vertical
+consistency constructs structures structures +overall spacing
-nesting program
-use of un- +data flow -span of commen- horizontal
-control conditional consistency data ting spacing
coupling branching
+data type +data +module +intra-
+encapsu- -nesting consistency initialized separation module
lation commen-
+cohesion -nesting naming ting
+module -I/O
re-use symbol and
complexity case

Examples:
+modularity + means greater modularity usually makes an application more maintainable;
-span of data means that the greater the scope of data structures, the less maintainable.
7. Summary
 Summary of This Chapter

• “Software Maintenance” = post delivery

• Impact analysis is key
• IEEE standard covers process
– identification, input, process, control, output,
process quality, process metrics
– order similar to development process
• Presents several management challenges
– manage flow of MR’s
– motivate personnel
– ensure all documentation kept up-to-date
• Metrics: plot repairs and enhancements