Software change

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27 Slide 1

Software change

Managing the processes of software system change


Software change Software change is inevitable

• New requirements emerge when the software is used• The business environment changes• Errors must be repaired• New equipment must be accommodated• The performance or reliability may have to be

improved A key problem for organisations is implementing and

managing change to their legacy systems


Software change strategies Software maintenance Architectural transformation Software re-engineering These strategies may be applied separately or

together Alternative – complete replacement from scratch


Study of the processes of system change Lehman and Belady proposed ‘laws’ concerning

the evolution of systems They are applicable to large systems developed

by large organizations.

Program evolution dynamics


Lehman’s First Law Continuing Change

• Environment changes• New requirements

Not controversial


Lehman’s Second Law Increasing Complexity To combat this takes effort Such extra effort is rarely done Not controversial


Lehman’s Third Law Large Program Evolution System attributes (size, time between releases, error

rates) are invariant from release to release Determined by organizational practices and system

structure Is controversial


Lehman’s Fourth Law Organization Stability Rate of development approximately constant Determined by organizational practices and

system structure Is controversial


Lehman’s Fifth Law Conservation of familiarity Over lifetime of system, incremental change in

each release is approximately constant


Applicability of Lehman’s laws This has not yet been established They are generally applicable to large, tailored

systems developed by large organisations It is not clear how they should be modified for

• Shrink-wrapped software products

• Systems that incorporate a significant number of COTS components

• Small organisations

• Medium sized systems


Modifying a program after it has been put into use Maintenance does not normally involve major changes to

the system’s architecture Changes are implemented by modifying existing

components and adding new components to the system

27.2 Software maintenance


The system requirements are likely to change When a system is installed it changes the

environment and therefore changes the system requirements.

Systems MUST be maintained therefore if they are to remain useful in an environment

Maintenance is inevitable


Repair software faults Adapt software to a different operating environment Add to or modify the system’s functionality

Types of maintenance


Distribution of maintenance effort

Functionalityaddition or

modification(65%)

Fault repair(17%)

Softwareadaptation

(18%)


Spiral maintenance model

Specification Implemention

ValidationOperation

Start

Release 1

Release 2

Release 3


Usually greater than development costs Affected by both technical and non-technical

factors Increases as software is maintained. Ageing software can have high support costs

Maintenance costs


Development/maintenance costs

0 50 100 150 200 250 300 350 400 450 500

System 1

System 2

Development costs Maintenance costs

$


Team stability Contractual responsibility Staff skills Program age and structure

Maintenance cost factors


The maintenance process

System releaseplanning

Changeimplementa tion

Systemrelease

Impactanalysis

Changerequests

Adaptivemaintenance

Correctivemaintenance

Perfectivemaintenance


Change requests Change requests are requests for system changes from

users, customers or management In principle, all change requests should be carefully

analysed as part of the maintenance process and then implemented

In practice, some change requests must be implemented urgently• Fault repair

• Changes to the system’s environment

• Urgently required business changes


Change implementation

Requirementsupdating

Softwaredevelopment

Requirementsanalysis

Proposedchanges

Modifysource code

Deliver modifiedsystem

Analyzesource code

Changerequests

Emergency repair


Maintenance prediction Change acceptance affected by the maintainability of

the components affected by the change Maintenance prediction is concerned with assessing

which parts of the system may cause problems and have high maintenance costs


Maintenance prediction

Predictingmaintainability

Predicting systemchanges

Predictingmaintenance

costs

What will be the lifetimemaintenance costs of this

system?

What will be the costs ofmaintaining this system

over the next year?

What parts of the systemwill be the most expensive

to maintain?

How many changerequests can be

expected?

What parts of the system aremost likely to be affected by

change requests?


Change prediction Requires an understanding of the relationships between

a system and its environment Tightly coupled systems require changes whenever the

environment is changed Factors influencing this relationship are

• Number and complexity of system interfaces• Number of inherently volatile system requirements• The business processes where the system is used


Maintainability Prediction Most maintenance effort on small number components Prediction of maintainability based on complexity Complexity metrics

• Complexity of control structures• Complexity of data structures• Procedure and module size

It may be beneficial to replace complex components


Maintainability Prediction via Process metrics

Process measurements may be used to assess maintainability• Number of requests for corrective maintenance• Average time required for impact analysis• Average time taken to implement a change request• Number of outstanding change requests

If any or all of these are increasing, this may indicate a decline in maintainability


Architectural evolution The architecture of the system is modified. There is a need to convert many legacy systems from a

centralized architecture to a client-server architecture Change “drivers”

• Hardware costs.

• User interface expectations.

• Distributed access to systems.


Distribution factors

Factor Description

Business importance Returns on the investment

System age Older systems harder to modify

System Structure Modularity aids change

Hardware Procurement Policies

Replacement of mainframes suggests change


Legacy system structures

Database

User interface

Services

Database

User interface

Services

Ideal model for distribution Real Legacy Systems


Legacy system distribution

User interface

Applicationservices

Database

Character terminals

Legacy system

Desktop PC clients running application

Middleware layer (wrapper)

Legacy system


Layered distribution model

Database

Application services

Interaction control

Data validation

Presentation


Distribution option spectrum

Increasing costand effort

Server: Interaction controlData validationServicesDatabase

Client: Presentation

Server:DatabaseServer: Services

Database

Client: PresentationInteraction controlData validation

Client: PresentationInteraction controlData validationServices


User interface distribution UI distribution takes advantage of the local

processing power on PCs to implement a graphical user interface

Where there is a clear separation between the UI and the application then the legacy system can be modified to distribute the UI

Otherwise, screen management middleware can translate text interfaces to graphical interfaces


User interface distribution

User interface

Applicationservices

Database

Desktop PC clients withGUI interface

Screen managementmiddleware

Legacy system

Screen descriptions


UI Migration Strategies

Strategy Advantages Disadvantages

Using window management system

Flexible UI DesignBetter UI Performance

Platform dependentInterface consistency

Using WWW browser

Platform independentLower Training CostsBrowser AvailabilityEasier Interface Consistency

Poorer UI PerformanceInterface design constrained by browsers

Date post:	06-Jan-2016
Category:	Documents
Upload:	calder
View:	57 times
Download:	0 times

Software change

Documents