Introduction to Software Maintenance. Software Maintenance Definition One of the phases in the software development process, and follows deployment

Introduction to Software Maintenance

Software Maintenance Definition One of the phases

in the software development process, and follows deployment of the software into the field.

http://cnx.org/content/m14719/latest/

SE, Maintenance, Hans van Vliet, ©2008

Growth of maintenance problem 1975: ~75,000 people n maintenance (17%)

1990: 800,000 (47%)

2005: 2,500,000 (76%)

2015: ??

Lehman’s 3rd law: a system that is used, will change

(Numbers from Jones (2006))

Growth of Maintenance Problem

http://www.clarityincode.com/software-maintenance/

Purpose of Maintenance enhancing and optimizing deployed software

(software release), as well as remedying/fixing defects.

Purpose of Maintenance (formal) Corrective (remedying/fixing )

defect identification and removal Adaptive (remedying/fixing )

responds to environmental changes, such as porting to new hardware or a different OS, but without affecting functionality.

Perfective (enhancing / optimizing ) any functionality changes to meet new

requirements, as well as performance improvements.

Preventive (enhancing / optimizing) improve maintainability itself, such as refactoring an

awkward design or adding comments.

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. 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.

Maintenance Process Model

Software Maintenance is a Process is the process of enhancing and optimizing

deployed software (software release), as well as remedying/fixing defects.

Maintenance Process Model: quick-fix an ad hoc approach

an unreliable model It is a 'firefighting' approach

waiting for the problem to occur and trying to fix it as quickly as possible,

Why people use quick-fix model pressure of deadlines and resources

If customers are demanding the correction of an error, for example, they may not be willing to wait for the organization to go through detailed and time consuming stages of risk analysis.

Often, a company will release a quick fix as a temporary measure. The real solution will be implemented, along with

other corrections and enhancements, as a major upgrade at a later date.

Maintenance Process Model: Boehm's Model maintenance process based upon economic models and

principles. management decisions are made that drives the process.

Maintenance Process Model: Osborne's Model it deals directly

with the reality of the maintenance environment.

Maintenance techniques

Impact of MR #162

Requirements

Architecture

Add: “change appearance when player achieves new levels”

Accommodate ability to change global appearance: use Abstract Factory design pattern

http://en.wikipedia.org/wiki/Abstract_factory_pattern

Impact of MR #162

Requirements

Architecture

System code

Interface specs

Detailed design

Function code

Module (e.g., package) code

Add: “change appearance when player achieves new levels”

Accommodate ability to change global appearance: use Abstract Factory design pattern

Add interface methods for Layout package

Add classes and methods as per detailed design

Modify gameplay control code

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

Maintenance With and Without Reengineering

Expansion Without Reengineering

Added1/98

Added7/99

Added7/98

Added1/99

The Beginning Product

Maintenance With and Without Reengineering

Reengineered Expansion

Expansion Without Reengineering

Added1/98

Added7/99

Added7/98

Added1/99

The Beginning Product


Continue to maintain Discontinue maintenance and --

1. Replace buy replacement OR build replacement

reverse engineer legacy system or develop new architecture possibly replace in phases

2. Incorporate as integral part of new application freeze maintenance

3. Encapsulate and use as server consider using Adapter design pattern


Options for Dealing with Legacy Systems

Legacy Architectures

LegacyApplication

New system

Extensions

Modifications

EncapsulationIncorporation

(fig i)0

wrapper

Legacy Architectures

LegacyApplication

New system

Extensions

LegacyApplication

Modifications

uses...

LegacyApplication

EncapsulationIncorporation

(fig i)

(fig ed)

(fig ew)

New system

New application

Adapter 3Adapter 2Adapter 1

New system

New application

Adapter 3Adapter 2Adapter 1


IEEE standard 840-1992:

Table of Content

1. Problem identification 1.1 Input 1.2 Process 1.3 Control 1.4 Output 1.5 Quality factors 1.6 Metrics2. Analysis 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 1.1 Input 1.2 Process 1.3 Control 1.4 Output 1.5 Quality factors 1.6 Metrics2. Analysis 2.1 Input 2.2 Process 2.2.1 Feasibility analysis 2.2.2 Detailed analysis


3. Design 3.1-3.6 Input, Process, Control, Output, Quality factors, Metrics.

4. Implementation 4.1 Input 4.2 Process 4.2.1 Coding and & testing 4.2.3 Risk analysis & review 4.2.4 Test-readiness review


5. System test 5.1-5.6 Input, Process, Control, Output, Quality factors, Metrics.

6. Acceptance test 6.1-6.6 Input, Process, Control, Output, Quality factors, Metrics.

7. Delivery 7.1-7.6 Input, Process, Control, Output, Quality factors, Metrics.

Five Attributes of Each Maintenance Step (IEEE)

1. Problem identification

2. Analysis

3. Design

4. Implementation

5. System test

6. Acceptance test

7. Delivery

Step

Five Attributes of Each Maintenance Step (IEEE)

1. Problem identification

2. Analysis

3. Design

4. Implementation

5. System test

6. Acceptance test

7. Delivery

Step Attributes

a. Input life cycle arti-facts for this step

b. Process required for this step

c. How the process is controlled

d. Output life cycle artifacts

e. Process quality factors involved

f. Metrics for this step

IEEE 1219-1992Maintenance phase 1: Problem

Identification

a. Input • The Maintenance Request (MR)

b. Process

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

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

d. Output • Validated MR

e. Selected quality factors

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

f. Selected metrics

• Number of omissions in the MR • Number of MR submissions to date • Number of duplicate MR's • Time expected to confirm the problem

IEEE 1219-1992Maintenance phase 2: Problem Analysis

a. Input • Original project documentation • Validated MR from the identification phase

b. Process

• Study feasibility of the MR • Investigate impact of the MR • Perform detailed analysis of the work required • Refine the MR description

c. Control

• Conduct technical review • Verify …

…test strategy appropriate…documentation updated

• Identify safety and security issues

d. Output

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

e. Selected quality factors • Comprehensibility of the analysis

f. Selected metrics

• Number of requirements that must be changed • Effort (required to analyze the MR) • Elapsed time

IEEE 1219-1992Maintenance phase 3: Design

a. Input • Original project documentation • Analysis from the previous phase

b. Process• Create test cases • Revise …

…requirements…implementation plan

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

d. Output

• Revised ……modification list…detailed analysis…implementation plan

• Updated ……design baseline…test planse. Selected

quality factors• Flexibility (of the design) • Traceability • Reusability• Comprehensibility

f. Selected metrics

• Effort in person-hours • Elapsed time • Number of applications of the change

EncounterEnvironment Package (Before Modification)

GameEnvironment

GameCharacterGameArea

EncounterEnvironment

Area


GameAreaConnection

EncounterAreaConnection


Abstract Factory Applied to Encounter

Area

Level3Area

Level3FactorygetArea()getAreaConnection()

EnvironmentFactorygetArea()buildConnection()


Client1..n

Abstract Factory Applied to Encounter

Area

Level2AreaLevel1Area Level3Area





EnvironmentFactorygetArea()getConnection()


Level1AreaConnectionLevel2AreaConnection

Client

Level3AreaConnection

«create»

1..n


Migration Plan for Level-based Graphics

Area






Phase 2: Introduce Subclasses of Area and …Connection

Area



Start: Existing Model

Migration Plan for Level-based Graphics

Area


Level1FactorygetArea()




EnvironmentFactorygetArea()



Phase 3: Introduce The ...Builder Class and Subclasses


Area







EnvironmentFactorygetArea()



Final Phase: Activate buildArea() and buildAreaConnection()

Area






Phase 2: Introduce Subclasses of Area and …Connection

Area



Start: Existing Model


IEEE 1219-1992Maintenance phase 4: Implementation

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

b. Process

• Make code changes and additions • Perform unit tests • Review readiness for system testing

c. Control

• Inspect code • Verify

CM control of new codeTraceability of new code

d. Output

• Updated ……software…unit test reports…user documents

e. Selected quality factors

• Flexibility • Traceability • Comprehensibility • Maintainability • Reliability

f. Selected metrics

• Lines of code • Error rate

The management of maintenance

A Typical Maintenance Flow

Proposed M. R.’s

Approved M. R.’s

Modified source & documentation

Current source & documentation

Change control boardMaintenanceengineer

Written MR’s

Customer

Help desk

nominal path


A Typical Maintenance Flow

Proposed M. R.’s

Approved M. R.’s

Modified source & documentation

Current source & documentation

Change control boardMaintenanceengineer

Written MR’s

Maintenance manager

Marketing

Rejected MR’s

Customer

Help desk

nominal path

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.Graphics reproduced with permission from Corel.

Maintenance& Patching

Help desk

1. Interface with customer

Complaints Marketing

Patch (optional)

Execute with patch

Docu-mentpatch

Maintenance& Patching

1. Get maintenance request

2. Approve changesCreate patch

3. Plan changes

Assessimpact

4. Change code and documentation

Coordinate

Test changesImplement

Update documentation

Remove patch

Docu-mentpatch

optional

Execute with patch

ReleaseDocument

patch removal


disadvantages

Keeps customers satisfied in the short run

Enables continued operation and testing without repeated prevalence of the defect

Avoids masking other defects

Enables test of fix

Duplicates work patch and final fix both

implemented Sometimes never

replaced proper fix deferred

forever! Complicates final fix

must remove Complicates

documentation process

advantagesMaintenance Patches


Ranked Problems in Maintenance (Deklava)

1. Changing priorities

2. Testing methods3. Performance

measurement3. Incomplete or

non-existent system documentation

5. Adapting to changing business requirements

6. Backlog size

7. Measurement of contributions

8. Low morale due to lack of recognition or respect

9. Lack of personnel, especially experienced

10. Lack of maintenance methodology, standards, procedures and tools . . . . .

Examples of Changing PrioritiesTop priority . . .. . . 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


Qualities in maintenance

Maintenance Metrics

Number of lines of code

under maintenance

Person-months to perform

various maintenance tasks

Defect count


Goal Question Selected Corresponding MetricsNote: The numbered metrics are from the IEEE.

Maximize customer

satisfaction

How many problems are affecting the customer?

• (1) Fault density • (30) Mean time to failure • Break / fix ratio

[ Number of defects introduced by maintenance actions ] / [Number of defects repaired ]

How long does it take to fix a problem?

• Fault closureAverage time required to correct a defect, from start of correction work.

• Fault open duration Average time from defect detection to validated correction.

Where are the bottlenecks?

• Staff utilization per task type: Average person-months to (a) detect each defect and (b) repair each defect.

• Computer utilizationAverage time / CPU time per defect.

Optimize effort and schedule

Where are resources being used?

Effort and time spent, per defect and per severity category …

o … planning o … reproducing customer finding o … reporting error o … repairing o … enhancingMinimize

defects (continue focused

development-type testing)

Where are defects most likely to be found?

• (13) Number of entries and exits per module • (16) Cyclotomic complexity

Maintenance Metrics Classified by Goal

Predicting Relative Maintenance Effort

0

10

20

30

40

50

60

70

80

90

AccountsReceived

Timesheet Sick dayrecorder

Benefitsreporter

Module size as % of total l.o.c.

% non-commented l.o.c. inmodule

Expect high maintenance

costs

Expect low maintenance

costs

Modules:


Managing MaintenanceExample profile of “fixing”-type MR’s

0

100

200

300

400

500

600

700

800

1993 1994 1995 1996

# MR's received# MR's completed# MR's cancelled# MR's open


Profiles of Open Maintenance RequestsJa

nuar

y

Febr

uary

Mar

ch

April

May

June

July

Augus

t

“Fixing” MR’s

Enhancement MR’s

# weeks open

5

10

E.g., in April, the average enhancement MR had been open for 8 weeks.


Profiles of Open Maintenance RequestsJa

nuar

y

Febr

uary

Mar

ch

April

May

June

July

Augus

t

“Fixing” MR’s

Enhancement MR’s

# weeks open

5

10

E.g., in April, the average enhancement MR had been open for 8 weeks.


SYST EM COM PONENT

CONTROL STRUCT URE

SYST EM COM PONENT

INFORM AT IONSTRUCT URE

SYST EM COM PONENT

CODE DET AIL

SOURCE CODE

Effects on Maintainability of Source Code Properties

From Oman [Om1]

. . . .

Effects on Maintainability of Source Code Properties

• statement formatting -- affects a product’s maintainability, (but more is not necessarily better)

• vertical spacing• horizontal spacing• + intra-module commenting -- usually, more comments with the code make a product more maintainable From Oman [Om1]

The maintainability of a product is affected by this property.

“+” means that more of this property usually makes an application more maintainable;

“-” means that more of the property usually makes an application less maintainable.

S Y S T E M C O M PO N E NT

C O N T R O L ST R U C T U RE


IN F O R M A T IO NS T R U C T U R E


C O D E D E T A IL

S O U R C E C O D EAspects of source code

SYST EM COM PONENT

CONTROL STRUCT URE

SYST EM COM PONENT

INFORM AT IONSTRUCT URE

SYST EM COM PONENT

CODE DET AIL

SOURCE CODEEffects on Maintainability of Source Code Properties

+modularity

-complexity

+consistency

-nesting

-control coupling

+encapsu-lation

+module re-use

-complexity

+use of structured constructs

-use of un-conditional branching

-nesting

+cohesion

-global data types

-global data structures

+data flow consistency

+data type consistency

-nesting

-I/O complexity

-local data types

-local data structures

-span of data

+data initialized

+overall program formatting

+overall program commen-ting

+module separation

naming

symbol and case

statement formatting

vertical spacing

horizontal spacing

+intra-module commen-ting

From Oman [Om1]

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

Examples:

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


Reference http://www.clarityincode.com/software-mainte

nance/

http://cnx.org/content/m14719/latest/ www.cs.vu.nl/~hans/SEslides/maint.ppt http://

www.se-cure.ch/images/CSE-F-SM-D-V2.0.pdf Grubb Takang software maintenance chapter

5






http://www.se-cure.ch/images/CSE-F-SM-D-V2.0.pdf

http://www.se-cure.ch/images/CSE-F-SM-D-V2.0.pdf

Documents

Introduction to Software Maintenance. Software Maintenance Definition One of the phases in the software development process, and follows deployment