Evolution-2.ppt

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 21 Slide 1
Software evolution 2

Evolution processes
 Evolution processes depend on
• The type of software being maintained;
• The development processes used;
• The skills and experience of the people
involved.
 Proposals for change are the driver for
system evolution. Change identification and
evolution continue throughout the system
lifetime.

Change identification and evolution

The system evolution process

Change implementation

Urgent change requests
 Urgent changes may have to be
implemented without going through all
stages of the software engineering process
• If a serious system fault has to be repaired;
• If changes to the system’s environment (e.g. an
OS upgrade) have unexpected effects;
• If there are business changes that require a
very rapid response (e.g. the release of a
competing product).

System re-engineering
 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.
 Re-engineering involves adding effort to make
them easier to maintain. The system may be re-
structured and re-documented.

Advantages of reengineering
 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 and re-engineering

The re-engineering process

Reengineering process activities
 Source code translation
• Convert code to a new language.
 Reverse engineering
• Analyse the program to understand it;
 Program structure improvement
• Restructure automatically for understandability;
 Program modularisation
• Reorganise the program structure;
 Data reengineering
• Clean-up and restructure system data.

Re-engineering approaches

Reengineering cost factors
 The quality of the software to be
reengineered.
 The tool support available for reengineering.
 The extent of the data conversion which is
required.
 The availability of expert staff for
reengineering.
• This can be a problem with old systems based
on technology that is no longer widely used.

Legacy system evolution
 Organisations that rely on legacy systems must
choose a strategy for evolving these systems
• Scrap the system completely and modify business
processes so that it is no longer required;
• Continue maintaining the system;
• Transform the system by re-engineering to improve its
maintainability;
• Replace the system with a new system.
 The strategy chosen should depend on the system
quality and its business value.

System quality and business value

Legacy system categories
 Low quality, low business value
• These systems should be scrapped.
 Low-quality, high-business value
• These make an important business contribution but are
expensive to maintain. Should be re-engineered or
replaced if a suitable system is available.
 High-quality, low-business value
• Replace with COTS, scrap completely or maintain.
 High-quality, high business value
• Continue in operation using normal system maintenance.

Business value assessment
 Assessment should take different viewpoints
into account
• System end-users;
• Business customers;
• Line managers;
• IT managers;
• Senior managers.
 Interview different stakeholders and collate
results.

System quality assessment
 Business process assessment
• How well does the business process support
the current goals of the business?
 Environment assessment
• How effective is the system’s environment and
how expensive is it to maintain?
 Application assessment
• What is the quality of the application software
system?

Business process assessment
 Use a viewpoint-oriented approach and seek
answers from system stakeholders
• Is there a defined process model and is it followed?
• Do different parts of the organisation use different
processes for the same function?
• How has the process been adapted?
• What are the relationships with other business processes
and are these necessary?
• Is the process effectively supported by the legacy
application software?
 Example - a travel ordering system may have a low
business value because of the widespread use of
web-based ordering.

Environment assessment 1

Environment assessment 2

Application assessment 1

Application assessment 2

Key points
 The process of evolution is driven by requests
for changes from system stakeholders.
 Software re-engineering is concerned with re-
structuring and re-documenting software to
make it easier to change.
 The business value of a legacy system and its
quality should determine the evolution strategy
that is used.

Evolution-2.ppt

More Related Content

Similar to Evolution-2.ppt (20)

Recently uploaded (20)

Evolution-2.ppt