Software change

transcript

©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

Spiral maintenance model

Specification Implemention

ValidationOperation

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

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

Software change

Documents