CHAPTER 9

SOFTWARE
EVOLUTION
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 are
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.
 • Organizations have huge investments in
their software systems - they are
critical business assets.
• To maintain the value of these assets to
Importance of the business, they must be changed
and updated.
Evolution • 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
 • Evolution
• The stage in a software system’s life cycle
where it is in operational use and is
evolving as new requirements are
proposed and implemented in the system.
Evolution And • Servicing

Servicing • At this stage, the software remains useful

but the only changes made are those
required to keep it operational, i.e. bug
fixes and changes to reflect changes in the
software’s environment. No new
functionality is added.
• Phase-out
• The software may still be used but no
further changes are made to it.
 • Software evolution processes depend on
• The type of software being
maintained.
• The development processes used.
• The skills and experience of the people
involved.
Evolution • Proposals for change are the driver for
Processes system evolution
• 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.
Change Identification And Evolution
Processes
The Software Evolution Process
 • Iteration of the development process
where the revisions to the system are
designed, implemented and tested.
• A critical difference is that the first
Change stage of change implementation may
involve program understanding,
Implementation 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.
 • Urgent changes may have to be
implemented without going through all
stages of the software engineering
process
Urgent Change • If a serious system fault has to be
repaired to allow normal operation
Requests to continue.
• 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).
 • 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
Software new versions.

Maintenance • 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.
 • 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
Types of • Changing a system so that it
Maintenance 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.
 • Corrective maintenance - with fixing errors
that are observed when the software is in
use.
• Adaptive maintenance - change in the
software that takes place to make the
software adaptable to new environment
Types of such as to run the software on a
new operating system.
Maintenance • Perfective maintenance - change in the
software that occurs while adding new
functionalities in the software.
• Preventive maintenance - implementing
changes to prevent the occurrence of
errors (documentation updating, code
optimization, and code restructuring).
Maintenance Effort Distribution
 • Usually greater than development
costs (2* to 100* depending on the
application).
• Affected by both technical and non-
technical factors.
Maintenance • Increases as software is maintained.
Costs Maintenance corrupts the software
structure so makes further
maintenance more difficult.
• Aging software can have high support
costs (e.g., old languages, compilers
etc.).
Development And 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
Maintenance so there is no incentive to design for
future change.
Cost Factors • 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 prediction is concerned
with assessing which parts of the
system may cause problems and have
high maintenance costs
• Change acceptance depends on the
Maintenance maintainability of the components
affected by the change.
Prediction • Implementing changes degrades
the system and reduces its
maintainability.
• Maintenance costs depend on the
number of changes and costs of
change depend on maintainability.
Maintenance Prediction
 • 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
Change changed.

Prediction • 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.
 • Predictions of maintainability can be
made by assessing the complexity of
system components.
• Studies have shown that most
maintenance effort is spent on a
Complexity relatively small number of system
components.
Metrics • 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
• Number of requests for corrective
maintenance.
Process • Average time required for impact
analysis.
Metrics • Average time taken to implement a
change request.
• Number of outstanding change
requests.
 • Re-structuring or re-writing part or all
of a legacy system without changing its
functionality.
• Applicable where some but not all sub-
System Re- systems of a larger system require
frequent maintenance.
engineering • Re-engineering involves adding effort
to make them easier to maintain. The
system may be re-structured and re-
documented.
 • Reduced risk
• There is a high risk in new software
development. There may be
development problems, staffing
problems and specification
Advantages of problems.
Re-engineering • Reduced cost
• The cost of re-engineering is often
significantly less than the costs of
developing new software.
The Re-engineering Process
Re-engineering Process Activities
• 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.
 • The quality of the software to be
reengineered.
• The tool support available for
reengineering.
Re-engineering • The extent of the data conversion
which is required.
Cost Factors • The availability of expert staff for
reengineering
• This can be a problem with old
systems based on technology that
is no longer widely used.
 • Refactoring is the process of making
improvements to a program to slow
down degradation through change.
• You can think of refactoring as
‘preventive maintenance’ that reduces
Preventive the problems of future change.
Maintenance • Refactoring involves modifying a
program to improve its structure,
By Refactoring 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.
 • 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
Refactoring system to create a new system that is
more maintainable.
and Re- • Refactoring is a continuous process of
engineering 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.
“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. The switch statements may be scattered around a program. In object-
oriented languages, you can often use polymorphism to achieve the same
thing.
‘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.
 • Organizations 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;
Legacy System • Continue maintaining the system;
• Transform the system by re-
Management 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.
An Example of A Legacy System Assessment
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.
 • Assessment should take different
viewpoints into account
• System end-users.
• Business customers.
Business Value • Line managers.
Assessment • IT managers.
• Senior managers.
• Interview different stakeholders and
collate results.
Issues In Business Value Assessment
• The use of the system
• If systems are only used occasionally or by a small number of people, they may have a low
business value.
• The business processes that are supported
• A system may have a low business value if it forces the use of inefficient business processes.
• System dependability
• If a system is not dependable and the problems directly affect business customers, the system
has a low business value.
• The system outputs
• If the business depends on system outputs, then the system has a high business value.
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?
 Factors Used In Environment Assessment
Factor Questions
Supplier stability Is the supplier still in existence? Is the supplier financially stable and likely to continue in existence? If the
supplier is no longer in business, does someone else maintain the systems?
Failure rate Does the hardware have a high rate of reported failures? Does the support software crash and force
system restarts?
Age How old is the hardware and software? The older the hardware and support software, the more obsolete it
will be. It may still function correctly but there could be significant economic and business benefits to
moving to a more modern system.
Performance Is the performance of the system adequate? Do performance problems have a significant effect on system
users?
Support requirements What local support is required by the hardware and software? If there are high costs associated with this
support, it may be worth considering system replacement.
Maintenance costs What are the costs of hardware maintenance and support software licences? Older hardware may have
higher maintenance costs than modern systems. Support software may have high annual licensing costs.
Interoperability Are there problems interfacing the system to other systems? Can compilers, for example, be used with
current versions of the operating system? Is hardware emulation required?
 Factors Used In Application Assessment

Factor Questions
Understandability How difficult is it to understand the source code of the current system? How complex are the control
structures that are used? Do variables have meaningful names that reflect their function?
Documentation What system documentation is available? Is the documentation complete, consistent, and current?
Data Is there an explicit data model for the system? To what extent is data duplicated across files? Is the
data used by the system up to date and consistent?
Performance Is the performance of the application adequate? Do performance problems have a significant effect
on system users?
Programming language Are modern compilers available for the programming language used to develop the system? Is the
programming language still used for new system development?
Configuration management Are all versions of all parts of the system managed by a configuration management system? Is there
an explicit description of the versions of components that are used in the current system?
Test data Does test data for the system exist? Is there a record of regression tests carried out when new
features have been added to the system?
Personnel skills Are there people available who have the skills to maintain the application? Are there people
available who have experience with the system?
 • You may collect quantitative data to
make an assessment of the quality of
the application system
System • The number of system change
requests.
Measurement • The number of different user
interfaces used by the system.
• The volume of data used by the
system.
End of chapter