MOD 7 - Scope of The Software Maintenance Problem

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 56

CMT 311 -

FUNDAMENTALS OF
SOFTWARE
ENGINEERING

MOD 7: Scope of the Software


Maintenance Problem
Software Engineering Roadmap: Module 7 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
MOD 7: Scope of the Software Maintenance Problem 2
Development
$
Learning Objectives De

• Understand how “Software


Maintenance

Maintenance” is defined
• Appreciate the cost of maintenance

• Understand software maintenance issues

• Organize for maintenance

• Use IEEE maintenance standard

• Apply maintenance metrics

MOD 7: Scope of the Software Maintenance Problem 3


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)
MOD 7: Scope of the Software Maintenance Problem 4
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
MOD 7: Scope of the Software Maintenance Problem 5
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

MOD 7: Scope of the Software Maintenance Problem 6


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
MOD 7: Scope of the Software Maintenance Problem 7
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
MOD 7: Scope of the Software Maintenance Problem 8
2. Types of software maintenance
Types of Maintenance Lientz & Swanson
• Corrective
• defect identification and removal
Fixing • Adaptive
• changes resulting from operating system,
hardware or DBMS changes
• Perfective
• changes resulting from user requests
• Preventative
Enhancing • changes made to the software to make it
more maintainable

MOD 7: Scope of the Software Maintenance Problem 10


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.
MOD 7: Scope of the Software Maintenance Problem 11
Example of Perfective Maintenance Request

Maintenance Request 162


Modify Encounter so that the game
begins with areas and connections a
coordinated style.

MOD 7: Scope of the Software Maintenance Problem 12


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.
MOD 7: Scope of the Software Maintenance Problem 13
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

MOD 7: Scope of the Software Maintenance Problem 15


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 control code
code MOD 7: Scope of the Software Maintenance Problem 16
Expansion Without Reengineering

Maintenance With and Without Added Added


Reengineering 7/98 1/99

Added Added
The Beginning Product
1/98 7/99

MOD 7: Scope of the Software Maintenance Problem 17


Expansion Without Reengineering

Maintenance With and Without Added Added


Reengineering 7/98 1/99

Added Added
The Beginning Product
1/98 7/99

Reengineered Expansion

MOD 7: Scope of the Software Maintenance Problem 18


Re-engineering Management Training;
Re-engineering Encounter to Conform

Current Encounter

Software re-
engineering

Play management
version
of Encounter
MOD 7: Scope of the Software Maintenance Problem 19
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
MOD 7: Scope of the Software Maintenance Problem 20
• Continue to maintain
• Discontinue maintenance and --
1. Replace
• buy replacement
• OR build replacement
Options for Dealing
• reverse engineer legacy system with Legacy Systems
OR • or develop new architecture
• possibly replace in phases
2. Incorporate as integral part of new application
• freeze maintenance

OR3. Encapsulate and use as server


• consider using Adapter design pattern

MOD 7: Scope of the Software Maintenance Problem 21


Legacy Architectures

Incorporation Encapsulation

New system

Extensions
Legacy Modifications
Application

(fig i)0

MOD 7: Scope of the Software Maintenance Problem 22


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
MOD 7: Scope of the Software Maintenance Problem 23
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 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.
MOD 7: Scope of the Software Maintenance Problem 25
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 4.2.3 Risk analysis & review
IEEE 840-1994
1.6 Metrics “Software 4.2.4 Test-readiness review
2. Analysis Maintenance” 4.3-4.6 Control, Output,
Table of Contents
2.1 Input Quality factors, Metrics.
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,
MOD 7: Scope of the Software Maintenance Problem
Output, Quality factors, Metrics. 26
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
MOD 7: Scope of the Software Maintenance Problem 27
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
6. Acceptance test e. Process quality factors
involved
7. Delivery f. Metrics for this step
MOD 7: Scope of the Software Maintenance Problem 28
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
MOD 7:expected to Software
Scope of the confirmMaintenance
the problemProblem 29
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
d. Output • Updated requirements
• Preliminary modification list
• Implementation plan
• Test strategy

e. Selected quality
• Comprehensibility of the analysis
factors

• Number of requirements that must be changed


f. Selected metrics • Effort (required to analyze the MR)
• Elapsed
MOD time
7: Scope of the Software Maintenance Problem 30
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
• Verify design
c. Control
• 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
MOD 7: Scope of the Software Maintenance Problem 31
• Number of applications of the change
EncounterEnvironment Package (Before Modification)

GameEnvironment

GameArea GameCharacter

GameAreaConnection

Area EncounterAreaConnection

EncounterEnvironment

EncounterEnvironment
MOD 7: Scope of the Software Maintenance Problem 32
Client
1..n
EncounterEnvironment EnvironmentFactory
getArea()
Area buildConnection()

Level3Area

Abstract Factory Applied


to Encounter

Level3Factory
getArea()
getAreaConnection()
MOD 7: Scope of the Software Maintenance Problem 33
Client
1..n Abstract Factory
Applied to Encounter
EncounterEnvironment EnvironmentFactory
getArea()
Area getConnection()

EncounterAreaConnection

Level1Area Level2Area Level3Area

Level1AreaConnection Level2AreaConnection Level3AreaConnection

«create»

Level1Factory Level2Factory Level3Factory


getArea() getArea() getArea()
getAreaConnection() getAreaConnection() getAreaConnection()
MOD 7: Scope of the Software Maintenance Problem 34
Migration Plan for Level-based Graphics

Phas e 2: Introduce Subclas ses of Area a nd …Connecti on


Start: Existing Model

EncounterEnvironment EncounterEnvironment
Area

EncounterA reaConnection

Area

EncounterAreaConnection

Level1Area Level2Area Level3Area

Level1AreaConnection Level2AreaConnection Level3AreaConnection

MOD 7: Scope of the Software Maintenance Problem 35


Phase 2: Introduce Subclasses of Area and …Connection
Migration Plan for Level-based Graphics EncounterEnvironment

Area

Encounter AreaConnection

Start: Existing Model


Level1Area Level2Area Level3Area
EncounterEnvironment

Area

EncounterA reaConnection

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()

MOD 7: Scope of the Software Maintenance Problem 36


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
MOD 7: Scope of the Software Maintenance Problem 37
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
MOD 7: Scope of the Software Maintenance Problem 39
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
MOD 7: Scope of the Software Maintenance Problem 40
1. Interface with customer

Help desk Complaints Marketing

Docu- Patch
ment (optional)
patch
Execute
with
patch
Maintenance
& Patching

MOD 7: Scope of the Software Maintenance Problem 41


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
MOD 7: Scope of the Software Maintenance Problem 42
Maintenance Patches
advantages disadvantages
• Keeps customers • Duplicates work
satisfied in the short • patch and final fix both
run implemented
• Enables continued • Sometimes never replaced
operation and • proper fix deferred forever!
testing without • Complicates final fix
repeated • must remove
prevalence of the
defect • Complicates documentation
process
• Avoids masking
other defects
• Enables test of fix

MOD 7: Scope of the Software Maintenance Problem 43


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 respect
3. Incomplete or non- 9. Lack of personnel,
existent system especially experienced
documentation 10. Lack of maintenance
5. Adapting to changing methodology, standards,
business requirements procedures and
tools . . . . .
6. Backlog size

MOD 7: Scope of the Software Maintenance Problem 44


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

MOD 7: Scope of the Software Maintenance Problem 45


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
MOD 7: Scope of the Software Maintenance Problem 47
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.
• Fault open duration
How long does it take to
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
o … reporting error
schedule being used? o … repairing
o … enhancing
Minimize defects
(continue focused Where are defects most
• (13) Number of entries and exits per module
development-type likely to be found?
• (16) Cyclotomic complexity
testing) MOD 7: Scope of the Software Maintenance Problem 48
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
maintenance
30 costs
20
10
0
Accounts Timesheet Sick day Benefits
Modules:
Received recorder
MOD 7: Scope of the Software Maintenance Problem reporter 49
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
MOD 7: Scope of the Software Maintenance Problem 50
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

ne
br
nu

ay
ar

ly

Au
Ap

Ju
Fe

Ju
Ja

M
MOD 7: Scope of the Software Maintenance Problem 51
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

ne
br
nu

ay
ar

ly

Au
Ap

Ju
Fe

Ju
Ja

M
MOD 7: Scope of the Software Maintenance Problem 52
Effects on Maintainability of Source Code Properties

SOURCE CODE

CONTROL STRUCTURE IN F O R M A T IO N C O D E D E T A IL
STRUCTURE

S YS T E M COM PONENT S YS T E M COM PONENT S YS T E M COM PONENT

....

From Oman [Om1]

MOD 7: Scope of the Software Maintenance Problem 53


Effects on Maintainability of
Source Code Properties SOURCE CODE 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] MOD 7: Scope of the Software Maintenance Problem 54
Effects on Maintainability of Source Code From Oman [Om1]
Properties SOURCE CODE

CONTROL STRUCTURE IN F O R M A T IO N C O D E D E T A IL
STRUCTURE

S YS T E M COM PONENT S YS T E M COM PONENT S YS T E M COM PONENT

+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 +data flow program
-use of un- -span of commen- horizontal
-control conditional consistency data spacing
ting
coupling branching +data type +data +intra-
consistency +module
+encapsu- -nesting initialized separation module
lation -nesting commen-
+cohesion naming ting
+module -I/O
re-use complexity symbol and
case

Examples:
+modularity + means greater modularity usually makes an application more maintainable;
MOD 7: Scope of the Software Maintenance Problem 55
-span of data means that the greater the scope of data structures, the less maintainable.
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

MOD 7: Scope of the Software Maintenance Problem 56