Chapter 9 – Software Evolution

30/10/2014 Chapter 9 Software Evolution 1

Topics covered

 Importance of evolution
 Legacy systems
 Software maintenance

30/10/2014 Chapter 9 Software Evolution 2

Software change

 Software change is inevitable

 New requirements emerge when the software is used;
 The business environment changes;
 Errors must be repaired;
 New computers and equipment is added to the system;
 The performance or reliability of the system may have to be
improved.
 A key problem for all organizations is implementing and
managing change to their existing software systems.

30/10/2014 Chapter 9 Software Evolution 3

Importance of evolution

 Organizations have huge investments in their software

systems - they are critical business assets.
 To maintain the value of these assets to the business,
they must be changed and updated.
 The majority of the software budget in large companies
is devoted to changing and evolving existing software
rather than developing new software.

30/10/2014 Chapter 9 Software Evolution 4

Maintenance vs Evolution

 The literature is conflicted over the use of maintenance

and evolution. A possible distinction is:
• Software maintenance being about fixing the software so
that it is close to working as intended (adaptive,
corrective, and preventive), whereas evolution is about
changing its intended behavior (perfective).

https://cs.gmu.edu/~offutt/classes/437/maintessays/maintEvolutionOverview.html#:~:text=A%20possible
%20distinction%20is%3A,a%20higher%20or%20better%20state.
 Legacy systems

30/10/2014 Chapter 9 Software Evolution 6

Legacy systems

 Legacy systems are older systems that rely on

languages and technology that are no longer used for
new systems development.
 Legacy software may be dependent on older hardware,
such as mainframe computers and may have associated
legacy processes and procedures.
 Legacy systems are not just software systems but are
broader socio-technical systems that include hardware,
software, libraries and other supporting software and
business processes.

30/10/2014 Chapter 9 Software Evolution 7

The elements of a legacy system **(FYI)**

30/10/2014 Chapter 9 Software Evolution 8

Legacy system management

 Legacy system replacement is risky and expensive, so

businesses continue to use these systems
 Organisations that rely on legacy systems must choose
a strategy for evolving these systems
 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.

30/10/2014 Chapter 9 Software Evolution 9

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.

30/10/2014 Chapter 9 Software Evolution 10

 Software maintenance

30/10/2014 Chapter 9 Software Evolution 11

Software maintenance

 Software maintenance is the general process of

changing a system after it has been delivered.
 The changes made to the software may be simple
changes to correct coding errors, more extensive
changes to correct design errors, or significant
enhancements to correct specification errors or to
accommodate new requirements.
 Changes are implemented by modifying existing
components and adding new components to the system.

30/10/2014 Chapter 9 Software Evolution 12

Types of maintenance

 Fault repairs
 Changing a system to fix bugs/vulnerabilities and correct
deficiencies in the way meets its requirements.
 Environmental adaptation
 Maintenance to adapt software to a different operating
environment
 Changing a system so that it operates in a different environment
(computer, OS, etc.) from its initial implementation.
 Functionality addition and modification
 Modifying the system to satisfy new requirements.

30/10/2014 Chapter 9 Software Evolution 13

Maintenance effort distribution

 Figure 9.12 shows an approximate distribution of

maintenance costs, based on data from the most recent
survey available.
 Repairing system faults is not the most expensive
maintenance activity.
 Evolving the system to cope with new environments and
new or changed requirements generally consumes most
maintenance effort.

30/10/2014 Chapter 9 Software Evolution 14

Maintenance effort distribution

30/10/2014 Chapter 9 Software Evolution 15

 Maintenance costs

 Maintenance cost usually greater than development costs

(2* to 100* depending on the application).
 It is usually more expensive to add new features to a system
during maintenance than it is to add the same features
during development. The reasons for this are:
 A new team has to understand the programs being maintained
 Separating maintenance and development means there is no
incentive for the development team to write maintainable
software
 Program maintenance work is unpopular
 As programs age, their structure degrades, and they become
harder to change
30/10/2014 Chapter 9 Software Evolution 16
Maintenance prediction

 Maintenance prediction is concerned with assessing

which parts of the system may cause problems and have
high maintenance costs
 Change acceptance depends on the maintainability of the
components affected by the change;
 Implementing changes degrades the system and reduces its
maintainability;
 Maintenance costs depend on the number of changes and costs
of change depend on maintainability.

30/10/2014 Chapter 9 Software Evolution 17

Maintenance prediction

30/10/2014 Chapter 9 Software Evolution 18

Software reengineering

 Software maintenance involves understanding the

program that has to be changed and then implementing
any required changes.
 However, many systems, especially older legacy
systems, are difficult to understand and change. The
programs may have been optimized for performance or
space utilization at the expense of understandability, or,
over time, the initial program structure may have been
corrupted by a series of changes.
 To make legacy software systems easier to maintain,
you can reengineer these systems to improve their
structure and understandability.
30/10/2014 Chapter 9 Software Evolution 19
Software reengineering

 Restructuring or rewriting 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.
 Reengineering involves adding effort to make
them easier to maintain. The system may be re-
structured and re-documented.

30/10/2014 Chapter 9 Software Evolution 20

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.

30/10/2014 Chapter 9 Software Evolution 21

The reengineering process

30/10/2014 Chapter 9 Software Evolution 22

Refactoring

 Refactoring is the process of making improvements to a

program to slow down degradation through change.
 You can think of refactoring as ‘preventative
maintenance’ that reduces the problems of future
change.
 Refactoring involves modifying a program to improve its
structure, reduce its complexity or make it easier to
understand.
 When you refactor a program, you should not add
functionality but rather concentrate on program
improvement.
30/10/2014 Chapter 9 Software Evolution 23
Refactoring and reengineering

 Although reengineering and refactoring are both intended

to make software easier to understand and change, they
are not the same thing.
 Re-engineering takes place after a system has been
maintained for some time and maintenance costs are
increasing. You use automated tools to process and re-
engineer a legacy system to create a new system that is
more maintainable.
 Refactoring is a continuous process of improvement
throughout the development and evolution process. It is
intended to avoid the structure and code degradation that
increases the costs and difficulties of maintaining a system.
30/10/2014 Chapter 9 Software Evolution 24
‘Bad smells’ in program code

 Examples of bad smells that can be improved through

refactoring include:
 Duplicate code
 Long methods
 Switch (case) statements
 Data clumping
 Speculative generality

30/10/2014 Chapter 9 Software Evolution 25

‘Bad smells’ in program code

 Duplicate code
 The same or very similar code may be included at different
places in a program. This can be removed and
implemented as a single method or function that is called
as required.
 Long methods
 If a method is too long, it should be redesigned as a
number of shorter methods.
 Switch (case) statements
 These often involve duplication, where the switch depends
on the type of a value. In object-oriented languages, you
can often use polymorphism to achieve the same thing.
30/10/2014 Chapter 9 Software Evolution 26
‘Bad smells’ in program code

 Data clumping
 Data clumps occur when the same group of data items (fields in
classes, parameters in methods) re-occur in several places in a
program. These can often be replaced with an object that
encapsulates all of the data.
 Speculative generality
 This occurs when developers include generality in a program in
case it is required in the future. This can often simply be
removed.

30/10/2014 Chapter 9 Software Evolution 27

Key points

 The process of software evolution is driven by requests

for changes and includes change impact analysis,
release planning and change implementation.
 Legacy systems are older software systems, developed
using obsolete software and hardware technologies, that
remain useful for a business.
 It is often cheaper and less risky to maintain a legacy
system than to develop a replacement system using
modern technology.

30/10/2014 Chapter 9 Software Evolution 28

Key points

 The business value of a legacy system and the quality of

the application should be assessed to help decide if a
system should be replaced, transformed or maintained.
 There are 3 types of software maintenance, namely bug
fixing, modifying software to work in a new environment,
and implementing new or changed requirements.

30/10/2014 Chapter 9 Software Evolution 29

Key points

 Software re-engineering is concerned with re-structuring

and re-documenting software to make it easier to
understand and change.
 Refactoring, making program changes that preserve
functionality, is a form of preventative maintenance.

30/10/2014 Chapter 9 Software Evolution 30