©Ian Sommerville 2000 Software Engineering, 6th edition. Chapters 27 and 28Slide 1 Software Evolution l Managing the processes of software system change

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapters 27 and 28 Slide 1

Software Evolution Managing the processes of software system change Objectives

• To explain different strategies for changing software systems» Software maintenance

» Architectural evolution

» Software re-engineering

• To explain the principles of software maintenance


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

• Changes are made in response to changed requirements but the fundamental software structure is stable

Architectural transformation• The architecture of the system is modified• Generally from a centralised to a distributed architecture

Software re-engineering• No new functionality is added to the system but it is restructured and

reorganised to facilitate future changes

These strategies may be applied separately or together


Lehman’s lawsLaw DescriptionContinuing change A program that is used in a real-world environment

necessarily must change or become progressively lessuseful in that environment.

Increasing complexity As an evolving program changes, its structure tendsto become more complex. Extra resources must bedevoted to preserving and simplifying the structure.

Large program evolution Program evolution is a self-regulating process.System attributes such as size, time between releasesand the number of reported errors are approximatelyinvariant for each system release.

Organisational stability Over a program’s lifetime, its rate of development isapproximately constant and independent of theresources devoted to system development.

Conservation offamiliarity

Over the lifetime of a system, the incremental changein each release is approximately constant.


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

Software maintenance


Types of maintenance Corrective

• Maintenance to repair software faults

Adaptive • Maintenance to adapt software to

a different operating environment Perfective

• Maintenance to add to or modify the system’s functionality

Functionalityaddition or

modification(65%)

Fault repair(17%)

Softwareadaptation

(18%)

System releaseplanning

Changeimplementa tion

Systemrelease

Impactanalysis

Changerequests

Adaptivemaintenance

Correctivemaintenance

Perfectivemaintenance


Usually greater than development costs (2* to 100* depending on the application)

Affected by both technical and non-technical factors

Increases as software is maintained• Maintenance corrupts the software structure, making further

maintenance more difficult

Ageing software can have high support costs (e.g. old languages, compilers etc.)

Think of your software as continuously evolving

Maintenance costs


Team stability• Maintenance costs are reduced if the same staff are involved with them

for some time

Contractual responsibility• The developers of a system may have no contractual responsibility for

maintenance so there is no incentive to design for future change

Staff skills• Maintenance staff are often inexperienced and have limited domain

knowledge

Program age and structure• As programs age, their structure is degraded and they become harder to

understand and change

Maintenance cost factors


Architectural evolution There is a need to convert many legacy systems

from a centralised architecture to a distributed (e.g., client-server) architecture

Change drivers• Hardware costs. Servers are cheaper than mainframes

• User interface expectations. Users expect graphical user interfaces

• Distributed access to systems. Users wish to access the system from different, geographically separated, computers


Distribution factorsFactor DescriptionBusinessimportance

Returns on the investment of distributing a legacy systemdepend on its importance to the business and how long itwill remain important. If distribution provides more efficientsupport for stable business processes then it is more likely tobe a cost-effective evolution strategy.

System age The older the system the more difficult it will be to modifyits architecture because previous changes will have degradedthe structure of the system.

System structure The more modular the system, the easier it will be to changethe architecture. If the application logic, the datamanagement and the user interface of the system are closelyintertwined, it will be difficult to separate functions formigration.

Hardwareprocurementpolicies

Application distribution may be necessary if there iscompany policy to replace expensive mainframe computerswith cheaper servers. .


Legacy system structure Ideally, for distribution, there should be a clear separation between

the user interface, the system services and the system data management

In practice, these are usually intermingled in older legacy systems

Database

User interface

Services

Ideal model for distribution Real legacy systems

Database

User interface

Services


Layered distribution model

Database

Application services

Interaction control

Data validation

Presentation


Legacy system distribution

User interface

Applicationservices

Database

Character terminals

Legacy system

Desktop PC clients running application

Middleware layer (wrapper)

Legacy system


Distribution options The more that is distributed from the server to the

client, the higher the costs of architectural evolution

The simplest distribution model is UI distribution where only the user interface is implemented on the server

The most complex option is where the server simply provides data management and application services are implemented on the client


Distribution option spectrum

Increasing costand effort

Server: Interaction controlData validationServicesDatabase

Client: Presentation

Server:DatabaseServer: Services

Database

Client: PresentationInteraction controlData validation

Client: PresentationInteraction controlData validationServices


Software re-engineering Reorganising and modifying existing software

systems to make them more maintainable Re-structuring or re-writing part or all of a legacy

system without changing its functionality Applicable where some but not all sub-systems

of a larger system require frequent maintenance When to re-engineer

• When system changes are mostly confined to part of the system then re-engineer that part

• When hardware or software support becomes obsolete

• When tools to support re-structuring are available


Re-engineering advantages Reduced risk

• There is a high risk in new software development. There may be development problems, staffing problems and specification problems

Reduced cost• The cost of re-engineering is often significantly less than the

costs of developing new software


Forward engineering and re-engineering

Understanding andtransformation

Existingsoftware system

Re-engineeredsystem

Design andimplementation

Systemspecification

Newsystem

Software re-engineering

Forward engineering


Re-engineering approaches

Automated restructuringwith manual changes

Automated sourcecode conversion

Restructuring plusarchitectural changes

Automated programrestructuring

Program and datarestructuring

Increased cost


Source code translation Involves converting the code from one language

(or language version) to another e.g. FORTRAN to C

May be necessary because of:• Hardware platform update

• Staff skill shortages

• Organisational policy changes

Only realistic if an automatic translator is available


Program restructuring – Spaghetti logic


Program restructuring – Structured control logic


Program restructuring – Condition simplification

-- Complex conditionif not (A > B and (C < D or not ( E > F) ) )...

-- Simplified conditionif (A <= B and (C>= D or E > F)...


Program modularisation The process of re-organising a program so that

related program parts are collected together in a single module

Usually a manual process that is carried out by program inspection and re-organisation


Recovering data abstractions Many legacy systems use shared tables and global

data to save memory space Causes problems because changes have a wide

impact in the system Shared global data may be converted to objects or

ADTs• Analyse common data areas to identify logical abstractions

• Create an ADT or object for these abstractions

• Use a browser to find all data references and replace with reference to the data abstraction


Reverse engineering Analysing software with a view to understanding its

design and specification May be part of a re-engineering process but may also

be used to re-specify a system for re-implementation Builds a program data base and generates

information from this Program understanding tools (browsers, cross-

reference generators, etc.) may be used in this process


Why reverse engineer Reverse engineering often precedes re-

engineering but is sometimes worthwhile in its own right• The design and specification of a system may be reverse

engineered so that they can be an input to the requirements specification process for the system’s replacement

• The design and specification may be reverse engineered to support program maintenance


Key points Software change strategies include software

maintenance, architectural evolution and software re-engineering

Lehman’s Laws are invariant relationships that affect the evolution of a software system

Maintenance types are adaptive, perfective, and corrective


Key points The costs of software change usually exceed the

costs of software development Factors influencing maintenance costs include staff

stability, the nature of the development contract, skill shortages and degraded system structure

Architectural evolution is concerned with evolving centralised to distributed architectures

Re-engineering reorganizes and modifies existing software systems to make them more maintainable

Documents

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapters 27 and 28Slide 1 Software Evolution l Managing the processes of software system change