Beruflich Dokumente
Kultur Dokumente
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
• 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
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Estimate
Estimate
Activity Activity (person-
(person-days)
days)
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 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
• 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.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Example of Perfective Maintenance Request
Modify gameplay
System code control code
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Expansion Without Reengineering
Added Added
The Beginning Product
1/98 7/99
Expansion Without Reengineering
Added Added
The Beginning Product
1/98 7/99
Reengineered Expansion
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
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
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
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
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
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)
d. Output
•Validated MR
e. Selected quality
factors •Clarity of the MR
•Correctness of the MR (e.g., type)
•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
•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
EncounterEnvironment
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
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
«create»
Area
Area
EncounterAreaConnection
EncounterAreaConnection
Area
EncounterAreaConnection
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
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
IEEE 1219-1992
Maintenance phase 4: Implementation
•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
Modified source
& documentation
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
A Typical Maintenance Flow
Marketing
nominal Written
path MR’s
Proposed
Customer Maintenance
manager M. R.’s
Help desk
Approved
M. R.’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
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
• Defect count
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Selected Corresponding Metrics
Goal Question
Note: The numbered metrics are from the IEEE.
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
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
400
300
200
100
0
1993 1994 1995 1996
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Profiles of Open Maintenance Requests
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Profiles of Open Maintenance Requests
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Effects on Maintainability of Source Code Properties
SOURCE CODE
....
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