Unit 9:

Software Evolution (3 Hrs.)

Compiled by : Madan Nath (B.Sc. CSIT, TU)

1
 Contents:
q Evolution Process;
q Legacy Systems;
q Software Maintenance;

2
Compiled by : Madan Nath (B.Sc. CSIT, TU)
 Unit 9:
Software Evolution
There are many reasons why 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.

3
Compiled by : Madan Nath (B.Sc. CSIT, TU)
 Unit 9:
Software 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.
• A Spiral model of development and evolution represents
how a software system evolves through a sequence of
multiple releases.

4
Compiled by : Madan Nath (B.Sc. CSIT, TU)
 Unit 9:
Software Evolution

5 Fig: Spiral Model for software Evolution

Compiled by : Madan Nath (B.Sc. CSIT, TU)
 Evolution processes

Software 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. These
should be linked with components that are affected by the
change, thus allowing the cost and impact of the change to be
estimated. Change identification and evolution continues
throughout the system lifetime.

6
Compiled by : Madan Nath (B.Sc. CSIT, TU)
 Evolution processes

Fig: Software Evolution Process

7
Compiled by : Madan Nath (B.Sc. CSIT, TU)
 Evolution processes

• Change implementation can be viewed as an iteration of the

development process where the revisions to the system are
designed, implemented and tested.
• A critical difference is that the first stage of change
implementation may involve program understanding,
especially if the original system developers are not responsible
for the change implementation.
• During the program understanding phase, you have to
understand how the program is structured, how it delivers
functionality and how the proposed change might affect the
program.
8
Compiled by : Madan Nath (B.Sc. CSIT, TU)
 Evolution processes

• Agile methods are based on incremental development so the

transition from development to evolution is a seamless one.
• Evolution is simply a continuation of the development
process based on frequent system releases.
• Automated regression testing is particularly valuable when
changes are made to a system.
• Changes may be expressed as additional user stories.

9
Compiled by : Madan Nath (B.Sc. CSIT, TU)
 Program evolution dynamics

• Program evolution dynamics is the study of the processes of

system change.
• The system requirements are likely to change while the
system is being developed because the environment is
changing, therefore a delivered system won't meet its
requirements.
• Systems are tightly coupled with their environment. When a
system is installed in an environment it changes that
environment and therefore changes the system requirements.
• Systems MUST be changed if they are to remain useful in an
environment.
10
Compiled by : Madan Nath (B.Sc. CSIT, TU)
 Program evolution dynamics

• After several major empirical studies, Lehman and Belady

proposed that there were a number of 'laws' which apply to all
systems as they evolved.
• There are sensible observations rather than laws. They are
applicable to large systems developed by large organizations.

11
Compiled by : Madan Nath (B.Sc. CSIT, TU)
 Program evolution dynamics

Law Description
A program that is used in a real-world environment must
Continuing
necessarily change, or else become progressively less
change
useful in that environment.
As an evolving program changes, its structure tends to
Increasing
become more complex. Extra resources must be devoted
complexity
to preserving and simplifying the structure.
Program evolution is a self-regulating process. System
Large program attributes such as size, time between releases, and the
evolution number of reported errors is approximately invariant for
each system release.
Over a program's lifetime, its rate of development is
Organizational
approximately constant and independent of the resources
12 stability
devoted to system development.
Compiled by : Madan Nath (B.Sc. CSIT, TU)
 Program evolution dynamics

Law Description
Conservation Over the lifetime of a system, the incremental change
of familiarity in each release is approximately constant.
Continuing The functionality offered by systems has to continually
growth increase to maintain user satisfaction.
The quality of systems will decline unless they are
Declining
modified to reflect changes in their operational
quality
environment.
Evolution processes incorporate multi agent, multi loop
Feedback feedback systems and you have to treat them as
system feedback systems to achieve significant product
improvement.
13
Compiled by : Madan Nath (B.Sc. CSIT, TU)
 Software maintenance

• Software maintenance focuses on modifying a program after

it has been put into use.
• The term is mostly used for changing custom software.
• Generic software products are said to evolve to create new
versions.
• 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.

14
Compiled by : Madan Nath (B.Sc. CSIT, TU)
 Software maintenance

Types of software maintenance include:

• Maintenance to repair software faults: changing a system to
correct deficiencies in the way meets its requirements.
• 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.
• Maintenance to add to or modify the system's functionality:
modifying the system to satisfy new requirements.

15
Compiled by : Madan Nath (B.Sc. CSIT, TU)
 Software maintenance

• Maintenance costs are usually greater than development costs

(2x to 100x depending on the application). Costs are affected
by both technical and non-technical factors; they tend to
increase as software is maintained.
• Maintenance corrupts the software structure making further
maintenance more difficult. Aging software can have high
support costs (e.g. old languages, compilers etc.).

16
Compiled by : Madan Nath (B.Sc. CSIT, TU)
 Software maintenance

Maintenance cost factors include:

• 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.

17
Compiled by : Madan Nath (B.Sc. CSIT, TU)
 Software maintenance

Maintenance prediction is concerned with assessing which

parts of the system may cause problems and have high
maintenance costs.
Predicting the number of changes requires and 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.
18
Compiled by : Madan Nath (B.Sc. CSIT, TU)
 Software maintenance

Predictions of maintainability can be made by assessing the

complexity of system components. Studies have shown that most
maintenance effort is spent on a relatively small number of system
components. Complexity depends on:
• Complexity of control structures;
• Complexity of data structures;
• Object, method (procedure) and module size.
Process metrics may be used to assess maintainability; if any or all of
these is increasing, this may indicate a decline in maintainability:
• Number of requests for corrective maintenance;
• Average time required for impact analysis;
• Average time taken to implement a change request;
19 • Number of outstanding change requests.
Compiled by : Madan Nath (B.Sc. CSIT, TU)
 System reengineering

System reengineering refers to restructuring or rewriting part or

all of a legacy system without changing its functionality. It is
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
restructured and redocumented. Advantages of reengineering
include:
• 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 reengineering is often significantly
20 less than the costs of developing newCompiled
software.
by : Madan Nath (B.Sc. CSIT, TU)
 System reengineering

Reengineering process activities include:

• Source code translation: convert code to a new language;
• Reverse engineering: analyze the program to understand it;
• Program structure improvement: restructure automatically
for understandability;
• Program modularization: reorganize the program structure;
• Data reengineering: clean-up and restructure system data.

21
Compiled by : Madan Nath (B.Sc. CSIT, TU)
 Software 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.
• Reengineering takes place after a system has been maintained
for some time and maintenance costs are increasing.
22
Compiled by : Madan Nath (B.Sc. CSIT, TU)
 Software Refactoring

• You use automated tools to process and reengineer 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.

23
Compiled by : Madan Nath (B.Sc. CSIT, TU)
 Software Refactoring

'Bad smells' of code are stereotypical situations in which the code

of a program can be improved through refactoring:
• Duplicate code or very similar code may be included at
different places in a program; it can be removed and implemented
as a single method or function that is called as required.
• Long methods should be redesigned as a number of shorter
methods.
• Switch(case) statements often involve duplication, where the
switch depends on the type of a value or the switch statements
may be scattered around a program. In object-oriented languages,
you can often use polymorphism to achieve the same thing.
24
Compiled by : Madan Nath (B.Sc. CSIT, TU)
 Software Refactoring

• Data clumping occurs 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 occurs when developers include
generality in a program in case it is required in the future. This
can often simply be removed.

25
Compiled by : Madan Nath (B.Sc. CSIT, TU)
 Legacy system management

Organizations that rely on legacy systems must choose a strategy

for evolving these systems. The chosen strategy should depend on
the system quality and its business value:
• Low quality, low business value: should be scrapped.
• Low-quality, high-business value: 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.
26
Compiled by : Madan Nath (B.Sc. CSIT, TU)
 Legacy system management

27
Compiled by : Madan Nath (B.Sc. CSIT, TU)
 ~ END ~

28
Compiled by : Madan Nath (B.Sc. CSIT, TU)