Chapter 13 Software Maintenance

8/11/2019 Chapter 13 Software Maintenance

1/51

Computing and SE II

Chapter 13: Software Maintenance

Er-Yu Ding

Software Institute, NJU


2/51


3/51

1. What is Software

Maintenance? Software EvolutionSoftware development does not stop whena system is delivered but continues

throughout the lifetime of the system.

(Sommerville, 2004)

The system changes relate to changing businessand user needs

The system evolves throughout its lifetimethrough a seamless process

The process is a spiral process involvingrequirements, design & implementation

throughout the lifetime of the system


4/51

1. What is Software

Maintenance? IEEE91 Definition: the process of modifying the software

system or component after delivery to

correct faults, improve performance orother attributes, or adapt to a change in

the environment.

SM is concerned with modifyingsoftware once it is delivered to a

customer


5/51

1. What is Software

Maintenance? Four categories:1. Perfective maintenance:changes required as

a result of user requests (a.k.a. evolutivemaintenance)

2. Adaptive maintenance:changes needed as aconsequence of operated system, hardware,or DBMS changes

3. Corrective maintenance:the identification

and removal of faults in the software4. Preventative maintenance:changes made to

software to make it more maintainable

The majority of SM is concerned withevolution deriving from user requested


6/51

1. What is Software

Maintenance?


7/51


8/51

2. Life cycles and

maintenance


9/51

2. Life cycles and

maintenance


10/51

2. Life cycles and maintenance

---Initial development first version of the software system is

developed may be lacking some features

software architecture is established likely to persist thought the rest of the life of

the program in one documented instance, we studied a

program that underwent substantial changesduring its 20 years of existence, but it still

possesses the architecture of the original firstversion.

programming team acquires the knowledgeof application domain, user requirements, role of

the application in the business process,solutions and al orithms data formats


11/51


--- challenges for initial

development To build evolvable software in the evolvable architecture, the cost of

making the change is proportional to the

size of the change, not to the size of theoverall software system

evolvable software can handleunanticipated changes

design for change should bepredominantly aimed at strategicevolution, not code level servicing


12/51


--- Design for change

A strategy to set a certain rules during

the Software development.

It eases the maintainability of the

system

Three main Factors that we have to

ensure during the design of the

Software:

Understandability,

Modifiability,

Stability.


13/51


14/51


---Servicing the program is no longer evolvable

changes are limited to patches andwrappers

they are less costly they further deteriorate the architecture.

Senior designers and architects do not needto be available

Tools and processes are very different fromevolution

A typical engineer will be assigned only partof the software to support

will have partial knowledge of the system.


15/51


--- Phase-out and close down

stages phase-out no more servicing is being undertaken, but the

system still may be in production

the users must work around known deficiencies

close-down the software use is disconnected

the users are directed towards a replacement.

business issues:

Can any of the software be re-used? exit strategy is needed.

once an organization commits to a system, changingto another is expensive, technically difficult, andtime consuming.

What to do with corporate data?


16/51


--- System Assessment

To determine whether a business still needs a systemthe system needs to be assessed for:

business value and system quality

Low quality, low business value

system should be scrapped

Low quality, high business value

should be re-engineered or replaced High quality, low business value

normal maintenance unless maintenance expensive then scrap

High quality, high business value

normal maintenance


17/51


--- Strategic Guidelines for Implementing

Alternatives Scrap the system completelyThe system is not making an effective

contribution to business processes

Leave the system unchanged and

continue with regular maintenance

Choose when the system is still required, is

relatively stable and has few changerequests


18/51

.--- Strategic Guidelines for Implementing

Alternatives

Complete redesign and rewrite

Use when:

more than 20% of the program must be changed

program is being upgraded to new technology

Do not use when:

the design and function of the program is not known

Restructuring to improve maintainability use on highly maintenance prone programs


19/51

.--- Strategic Guidelines for Implementing

Alternatives

Partial restructuring integrated with adaptive

maintenance use for orderly improvement with each system release

Retirement of the system and complete

redevelopment

Use when: moving to a new technology

the costs of maintaining the software and the hardware

exceed the cost of re-development


20/51

3. Problems of software

maintenance

---Software Maintenance is

important

Direct software costs

Major economic importance: 40 90%

of the total lifecycle costs

50-80% of the time of an estimated onemillion programmers or programming

managers spent on maintenance. ...

[Corbi89]

for every $1 allocated for a new

development project, $9 will be spent on

maintenance for the life cycle of the

project. [Mit]


21/51


maintenance

---Software Maintenance is

important

It is necessary to add, to the direct cost of

maintenance, the consequences of the

maintenance...

Deterioration of software Lost of software structure because of

maintenance

May imply software death and its benefits

May have catastrophic consequences Client dissatisfaction

Difficulty to deal with all the modification

requests

Even if indirect costs are difficult to


22/51


maintenance

--- Software maintenance is

problematic

Problems of software maintenance

a neglected topic !

Too many factors

Maintainability is difficult to measured

Requirements is volatile


23/51


maintenance

--- A neglected topic No interest Industry

Do you want to work in a software maintenanceproject ?

Few resources devoted to softwaremaintenance teams

90% of managers complain about theemployees lack of interest

Research Projects focus on development

Only few conferences and books on softwaremaintenance

University


24/51


25/51


maintenance

--- Maintainability is difficult to

measured Respect of Metrics

Software maintenance should be

measured and managed using metrics toreach a quality software.

However, we don't know how to

measure maintainability because its a

service.


26/51


maintenance

--- Requirements is volatile Requirements are the foundation ofthe software release process.

Changing requirements during the

software maintenance process impactsthe cost, schedule, and quality of theresulting product.

Build model to make planning of

customer communications (predictions). A focus is made on non volatile

requirements.


27/51

4. The Maintenance Process

begins

when a request for change is initiated by a user

endswhen the system passes testing, is accepted by theuser and is released for operation

in between

there are many activities that must be planned and

co-ordinated by use of

Change Management


28/51


Seven-step approach [IEEE-1219]: Step 1 - Problem/modification identification, classification, and

prioritization. Change Management

Step 2 - Analysis Step 2.1 feasibility analysis

Impact Analysis

Step 2.2 detailed analysis System Release Planning

Step 3 Design (the Changes)

Step 4 - Implementation Code the Changes

Step 5 - Regression/system testing

Step 6 - Acceptance testing.

Step 7 - Delivery System Release


29/51


---Step 1 - Change Management

to uniquely identify, describe and trackthe status of each requested change

in an organisation

change requestsare recorded and trackedthrough all stages of the maintenanceprocess in a Change Management TrackingSystem

Project Management and the QualityAssurance team receive information aboutthe status of the Change Requests


30/51


---Step 1 - Change Management

Change Request

basic tool (manual or electronic) of change

management

documents all information about changes

updated throughout the maintenance

process to help manage the system release

for the analysis of the types and frequency of

defects

to communicate to maintainers, managers and

clients


31/51


32/51


---Step 2.1 - Impact Analysis ...

Aims:

to determine the scopeof the requested change forplanning and implementation of the change

to develop accurate estimates of resources

to analyse cost/benefitsof the change

to communicate the complexityof the change

h


33/51


---Step 2.1 - Impact Analysis...

1. Evaluate Change Requests

look for potential impacton:- existing systems, other systems, hardware, documentation,

data structures and humans

without analysis of the changes the change may insertdefects that are not immediately apparent

Problems: documentation doesnt exist and must be created

documentation is out of date or incorrect leading toincorrect design decisions


34/51



2. Estimate Resources

In an organisation, a project manager must estimate:

Number of people required to complete the system

The equipment required eg PCs, printers, copiers etc

Other facilities such as offices, support staff etc Cost of the system etc


35/51



To Estimate Resources need to know:

Size of required changes measured as

LOC and/or

Function Points and/or Proxies such as classes and routines

(Impact Analysis will give this information)

Historical information

eg Productivity Rate, Average LOC per Routine

Time required to complete the system changes

Size of system and productivity rate

4 Th M i t P


36/51


---Step 2.2 - System Release Planning

Aims:

to establish the schedule of system releases

to determine the contents of a system release

System Release/Version Description Document

describes the contents / timing of a system release

communicates between maintainers and users used by operations to plan hardware, operational procedures

and backup procedures

4 Th M i t P


37/51


---Step 3 - Design Changes

Aims:

to develop a revised logical and physical

design

analyse and design the changes

update the documentation

update the configuration management

system

update the change request for management

to design the changes for each of the

different types of maintenance


38/51

4 Th M i t P


39/51


---For Corrective Maintenance

Problems repairing defects:

cleanly repairing a defect

repairing a defect has a 20-50% change of

introducing another defect

because:

Ripple-effect may be overlooked

person who makes the repair is not generally the

person who wrote the code

increased testingEvery solution causes new problems

4 Th M i t P


40/51


---Design Changes ...

For Adaptive Maintenance:

Aimsto evolve systems to meet user and business needs

Essentially the same as a new development exceptthat system understanding is needed first

Requirements then Design: - Systems, Data, Program and

Module

At each stageconduct design and code reviews.

4 Th M i t P


41/51


--- Design Changes ...

For Perfective Maintenance ...

includes all efforts to polish or refine thequality of the software or the

documentation

includes re-engineering

rewriting and upgrading documentation

restructuring poorly written code

important that the improvementreduces the system maintenance costs

4 Th M i t P


42/51


---Step 4 Code the Changes

Aim: to clarify existing code and simplify changing it

Re-Engineering Source Code

Restructuring

Redesign and rewrite code

Remember design and code reviews

4 The Maintenance Process


43/51


---Step 5,6 Test the Changes

Maintenance / Development Differences

For Maintenance:

only changes need to be reviewed

only new test cases that exercise the changes need to be

developed

existing and new test cases are required to test the changes

test results are compared against previous test results

(Regression Testing)

4 The Maintenance Process


44/51


---Step 7 - System Release

Aims:

package the system for release including:

documentation

software

training

other products

hardware

deliver the system to the user

install with backup procedures


45/51

5. Legacy Systems, Reverse Engineer and Re-

engineering

---Legacy Systems Legacy problems a legacy system istypically:

very old and large

has been heavily modified

based on the old technology

documentation not be available

none of the original members of the softwaredevelopment team may still be around

often support very large quantities of live data the software is often at the core of the business

and replacing it would be a hugeexpense.

Dealing with legacy system is very hard and

there are some solutions.


46/51


engineering

--- Legacy Systems Solutions for the legacy system: discarding the legacy system and

building a replacement system;

freezing the system and using it as acomponent of a new larger system;

carrying on maintaining the system foranother period;

modifying the system to give it anotherlease of life

Reverse Engineer the legacy system anddevelop a new software suite.the mostfruitful solution!


47/51


engineering

--- Reverse Engineering Definition: Reversing Engineering The process of analyzing a subject system to

identify the systems components and their inter-relationships, and to create representations of thesystem in another form or at higher levels of

abstraction.( by Chikofsky & Cross)

Two types of Reverse Engineering:

1. Redocumentation: the creation or revision of asemantically equivalent representation within thesame relative abstraction layer;

2. Design Recovery: involves identifying meaningfulhigher level abstractions beyond those obtaineddirectly by examining the system itself.

The main motivation is to provide help in program

comprehension


48/51


engineering

--- Reverse Engineering reverse engineering has been successfullyapplied include identifying reusable assets

finding objects in procedural programs

discovering architectures deriving conceptual data models

detecting duplications

transforming binary programs into source

code renewing user interfaces

parallelizing sequential programs

Translating, downsizing, migrating andwrapping legacy code


49/51


engineering

--- Re-engineering Software Re-engineering is any activity that: (1) improves

ones understanding of software, or (2) prepares or improves

the software itself, usually for increased maintainability,

reusability, or evolvability. Re-engineering can involve:

Re-documenting

Organising and restructuring the system Translating to a more modern programming language

Modifying the structure of the data

The old system forms the specification for the new system


50/51


engineering

---Reverse engineering and re-engineering.


51/51

The End

Recommend papers

software maintenance

The next lecture

Project Management

Documents

Chapter 13 Software Maintenance