Software change

Managing the processes of
software system change
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 27
Slide 1
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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 27
Slide 4
Software change strategies





Software maintenance
Architectural transformation
Software re-engineering
These strategies may be applied separately or
together
Alternative – complete replacement from scratch
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 27
Slide 5
Program evolution dynamics



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.
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 27
Slide 6
Lehman’s First Law


Continuing Change
• Environment changes
• New requirements
Not controversial
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 27
Slide 8
Lehman’s Second Law




Increasing Complexity
To combat this takes effort
Such extra effort is rarely done
Not controversial
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 27
Slide 9
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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 27
Slide 10
Lehman’s Fourth Law




Organization Stability
Rate of development approximately constant
Determined by organizational practices and
system structure
Is controversial
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 27
Slide 11
Lehman’s Fifth Law


Conservation of familiarity
Over lifetime of system, incremental change in
each release is approximately constant
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 27
Slide 12
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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 27
Slide 13
27.2 Software maintenance



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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 27
Slide 14
Maintenance is inevitable



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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 27
Slide 15
Types of maintenance



Repair software faults
Adapt software to a different operating environment
Add to or modify the system’s functionality
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 27
Slide 16
Distribution of maintenance effort
Fault repair
(17%)
Software
adaptation
(18%)
©Ian Sommerville 2000
Functionality
addition or
modification
(65%)
Software Engineering, 6th edition. Chapter 27
Slide 17
Spiral maintenance model
Implemention
Specification
Start
Release 1
Operation
Validation
Release 2
Release 3
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 27
Slide 18
Maintenance costs




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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 27
Slide 19
Development/maintenance costs
System 1
System 2
0
50
100 150
Development costs
©Ian Sommerville 2000
200 250
300
350 400 450
500
Maintenance costs
Software Engineering, 6th edition. Chapter 27
Slide 20
$
Maintenance cost factors




Team stability
Contractual responsibility
Staff skills
Program age and structure
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 27
Slide 21
The maintenance process
Change
requests
©Ian Sommerville 2000
Impact
analysis
System release
planning
Change
implementa tion
Perfective
maintenance
Adaptive
maintenance
Corrective
maintenance
Software Engineering, 6th edition. Chapter 27
System
release
Slide 23
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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 27
Slide 24
Change implementation
Proposed
changes
Requirements
analysis
Requirements
updating
Software
development
Emergency repair
Change
requests
©Ian Sommerville 2000
Analyze
source code
Modify
source code
Software Engineering, 6th edition. Chapter 27
Deliver modified
system
Slide 25
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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 27
Slide 27
Maintenance prediction
What parts of the system are
most likely to be affected by
change requests?
What parts of the system
will be the most expensive
to maintain?
Predicting
maintainability
Predicting system
changes
Predicting
maintenance
costs
What will be the costs of
maintaining this system
over the next year?
How many change
requests can be
expected?
©Ian Sommerville 2000
What will be the lifetime
maintenance costs of this
system?
Software Engineering, 6th edition. Chapter 27
Slide 28
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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 27
Slide 29
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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 27
Slide 30
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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 27
Slide 31
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.
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 27
Slide 32
Distribution factors
Factor
Description
Business importance Returns on the investment
System age
Older systems harder to modify
System Structure
Modularity aids change
Hardware
Replacement of mainframes suggests
Procurement Policies change
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 27
Slide 34
Legacy system structures
User interface
User interface
Services
Services
Database
Database
Ideal model for distribution
©Ian Sommerville 2000
Real Legacy Systems
Software Engineering, 6th edition. Chapter 27
Slide 36
Legacy system distribution
Desktop PC clients running application
Legacy system
Application
services
Database
Middleware layer (wrapper)
User interface
Legacy system
Character terminals
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 27
Slide 38
Layered distribution model
Presentation
Data validation
Interaction control
Application services
Database
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 27
Slide 39
Distribution option spectrum
Server: Interaction control
Data validation
Services
Database
Server: Services
Database
Server:Database
Client: Presentation
Client: Presentation
Interaction control
Data validation
Client: Presentation
Interaction control
Data validation
Services
Increasing cost
and effort
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 27
Slide 41
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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 27
Slide 42
User interface distribution
Screen descriptions
Desktop PC clients with
GUI interface
Legacy system
Application
services
Database
Screen management
middleware
User interface
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 27
Slide 43
UI Migration Strategies
Strategy
Using
window
management
system
Using WWW
browser
©Ian Sommerville 2000
Advantages
Flexible UI Design
Better UI Performance

Platform independent
Lower Training Costs
Browser Availability
Easier Interface
Consistency

Disadvantages
Platform dependent
Interface consistency

Poorer UI Performance
Interface design
constrained by browsers

Software Engineering, 6th edition. Chapter 27
Slide 44