Maintenance

10.
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
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
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
1. Introduction
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
RoadMap to Establish Maintenance (After Pigoski)
1a. Design for maintainability-
2. Determine main-
- 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
• buy replacement
Options for
Dealing with
• OR build replacement
OR – reverse engineer legacy system
Legacy
– 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
1.5 Quality factors IEEE 840-1994
1.6 Metrics “Software
2. Analysis Maintenance”
2.1 Input Table of Contents
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
1.3 Control 1.4 Output 4.2 Process
1.5 Quality factors 4.2.1 Coding and & testing
1.6 Metrics IEEE 840-1994
4.2.3 Risk analysis & review
2. Analysis “Software 4.2.4 Test-readiness review
2.1 Input Maintenance” 4.3-4.6 Control, Output,
Table of Contents Quality factors, Metrics.
2.2 Process
2.2.1 Feasibility analysis 5. System test
2.2.2 Detailed analysis 5.1-5.6 Input, Process, Control,
2.3-2.6 Control, Output, Output, Quality factors, Metrics.
Quality factors, Metrics. 6. Acceptance test
3. Design 6.1-6.6 Input, Process, Control,
3.1-3.6 Input, Process, Control, Output, Quality factors, Metrics.
Output, Quality factors, Metrics. 7. Delivery
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
factors •Clarity of the MR
•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

b. Process •Investigate impact of the MR
•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
d. Output •Updated requirements
•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

b. Process •Revise …
…requirements
…implementation plan
c. Control •Verify design
•Inspect design and test cases
•Revised …
…modification list
d. Output …detailed analysis
…implementation plan
•Updated …
…design baseline
…test plans
e. Selected quality •Flexibility (of the design)
factors •Traceability
•Reusability
•Comprehensibility
f. Selected metrics •Effort in person-hours
•Elapsed time
•Number of applications of the change
EncounterEnvironment Package (Before Modification)
GameEnvironment
GameArea GameCharacter
GameAreaConnection
Area EncounterAreaConnection
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
Phase 2: Introduce Subclasses of Area a nd …Connection

Start: Existing Model
Area
Area
Level1Area Level2Area Level3Area
Level1AreaConnection Level2AreaConnection Level3AreaConnection

Migration Plan for Phase 2: Introduce Subclasses of Area and …Connection
Level-based Graphics EncounterEnvironment
Area
Start: Existing Model Encounter AreaConnection
EncounterEnvironment Level1Area Level2Area Level3Area

Area
Level1AreaCon nection Level2AreaCon nection Level3AreaCon nection
Phase 3: Introduce The ...Builder Class and Subclasses Final Phase: Activate buildArea() and buildAreaConnection()
EncounterEnvironment EnvironmentFactory EncounterEnvironment EnvironmentFactory
getArea() getArea()
Area Area
EncounterAreaConnection EncounterAreaConnection
Level1Area Level2Area Level3Area Level1Area Level2Area Level3Area
Level1AreaConnection Level2AreaConnection Level3AreaConnection Level1AreaConnection Level2AreaConnection Level3AreaConnection
Level1Factory Level2Factory Level3Factory Level1Factory Level2Factory Level3Factory

getArea() getArea() getArea() getArea() getArea() getArea()
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
c. Control •Verify
CM control of new code
Traceability of new code
•Updated …
d. Output …software
…unit test reports
…user documents
•Flexibility
e. Selected quality •Traceability
factors •Comprehensibility
•Maintainability
•Reliability
•Lines of code
f. Selected metrics
•Error rate
5. The management of maintenance
A Typical Maintenance Flow
Written
MR’s
nominal Proposed
Customer
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
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Graphics reproduced with permission from Corel.
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
advantages disadvantages
• 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
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.
How many problems are •(1) Fault density

affecting the customer? •(30) Mean time to failure
•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 Where are resources o… reproducing customer finding
and schedule being used? o… reporting error
o… repairing
o… enhancing
Minimize defects
(continue focused Where are defects most
development-type likely to be found? •(13) Number of entries and exits per module
testing) •(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
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
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
Effects on Maintainability of Source Code Properties
SOURCE CODE
CONTROL STRUCTURE INFORMATION CODE DETAIL

STRUCTURE
SYSTEM COMPONENT SYSTEM COMPONENT SYSTEM COMPONENT
....
From Oman [Om1]

Effects on Maintainability of
Source Code Properties SOURCE CODE Aspects of source code

STRUCTURE
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]
SOURCE CODE
Code Properties

STRUCTURE
+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

Maintenance

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Maintenance

Încărcat de

Drepturi de autor:

Formate disponibile

10.

• Understand how Maintenance

“Software Maintenance” is defined

7. Plan transition from current design

Estimating the Cost of Servicing a Maintenance Request

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

5. Change SRS, SDD, STP, configuration

4. Develop maintenance plan

5. Estimate costs 6. Perform maintenance

Maintenance Request 162

Maintenance Request 162

Requirements Add: “change appearance when

Architecture Accommodate ability to change

Requirements Add: “change appearance when

Architecture Accommodate ability to change

Add classes and methods

Maintenance With and Added Added

Maintenance With and Added Added

Business process Re-engineering

•Assign change number

•Number of omissions in the MR

a. Input •Original project documentation

•Study feasibility of the MR

•Conduct technical review

•Number of requirements that must be changed

a. Input •Original project documentation

•Create test cases

Level1Area Level2Area Level3Area

Level1AreaConnection Level2AreaConnection Level3AreaConnection

Level1Factory Level2Factory Level3Factory

Phase 2: Introduce Subclasses of Area a nd …Connection

Level1Area Level2Area Level3Area

Level1AreaConnection Level2AreaConnection Level3AreaConnection

Level-based Graphics EncounterEnvironment

Start: Existing Model Encounter AreaConnection

EncounterEnvironment Level1Area Level2Area Level3Area

Level1Area Level2Area Level3Area Level1Area Level2Area Level3Area

Level1AreaConnection Level2AreaConnection Level3AreaConnection Level1AreaConnection Level2AreaConnection Level3AreaConnection

Level1Factory Level2Factory Level3Factory Level1Factory Level2Factory Level3Factory

•Original source code

•Make code changes and additions

Maintenance Current source Change control board

Maintenance Current source Change control board

Modified source Rejected

Help desk Complaints Marketing

Implement Test changes

1. Changing priorities 7. Measurement of

• Number of lines of code under

• Person-months to perform various

How many problems are •(1) Fault density

700 # MR's received

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

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

CONTROL STRUCTURE INFORMATION CODE DETAIL

SYSTEM COMPONENT SYSTEM COMPONENT SYSTEM COMPONENT

From Oman [Om1]

CONTROL STRUCTURE INFORMATION CODE DETAIL

SYSTEM COMPONENT SYSTEM COMPONENT SYSTEM COMPONENT

The maintainability of a product • statement formatting

CONTROL STRUCTURE INFORMATION CODE DETAIL

SYSTEM COMPONENT SYSTEM COMPONENT SYSTEM COMPONENT