Software change Importance of evolution

 Software change is inevitable  Organisations have huge investments in their software

▪ New requirements emerge when the software is used;
systems - they are critical business assets.
▪ The business environment changes;  To maintain the value of these assets to the business,
▪ Errors must be repaired; they must be changed and updated.
▪ New computers and equipment is added to the system;  The majority of the software budget in large companies
▪ The performance or reliability of the system may have to be is devoted to changing and evolving existing software
improved. rather than developing new software.
 A key problem for all organizations is implementing and
managing change to their existing software systems.

30/10/2014 Chapter 9 Software Evolution 3 30/10/2014 Chapter 9 Software Evolution 4

Evolution processes Change implementation

 Software evolution processes depend on  Iteration of the development process where the revisions
▪ The type of software being maintained; to the system are designed, implemented and tested.
▪ The development processes used;  A critical difference is that the first stage of change
▪ The skills and experience of the people involved. implementation may involve program understanding,
 Proposals for change are the driver for system evolution. especially if the original system developers are not
▪ Should be linked with components that are affected by the responsible for the change implementation.
change, thus allowing the cost and impact of the change to be  During the program understanding phase, you have to
estimated.
understand how the program is structured, how it
 Change identification and evolution continues throughout delivers functionality and how the proposed change
the system lifetime. might affect the program.

30/10/2014 Chapter 9 Software Evolution 9 30/10/2014 Chapter 9 Software Evolution 13

Urgent change requests Legacy systems

 Urgent changes may have to be implemented without  Legacy systems are older systems that rely on
going through all stages of the software engineering languages and technology that are no longer used for
process new systems development.
▪ If a serious system fault has to be repaired to allow normal  Legacy software may be dependent on older hardware,
operation to continue;
such as mainframe computers and may have associated
▪ If changes to the system’s environment (e.g. an OS upgrade)
legacy processes and procedures.
have unexpected effects;
▪ If there are business changes that require a very rapid response  Legacy systems are not just software systems but are
(e.g. the release of a competing product). broader socio-technical systems that include hardware,
software, libraries and other supporting software and
business processes.

30/10/2014 Chapter 9 Software Evolution 14 30/10/2014 Chapter 9 Software Evolution 19

Legacy system components Legacy system components

 System hardware Legacy systems may have been  Business processes These are processes that are used
written for hardware that is no longer available. in the business to achieve some business objective.
 Support software The legacy system may rely on a  Business processes may be designed around a legacy
range of support software, which may be obsolete or system and constrained by the functionality that it
unsupported. provides.
 Application software The application system that  Business policies and rules These are definitions of how
provides the business services is usually made up of a the business should be carried out and constraints on
number of application programs. the business. Use of the legacy application system may
be embedded in these policies and rules.
 Application data These are data that are processed by
the application system. They may be inconsistent,
duplicated or held in different databases.
30/10/2014 Chapter 9 Software Evolution 21 30/10/2014 Chapter 9 Software Evolution 22

Figure 9.13 An example of a legacy system

Legacy system management
assessment

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

30/10/2014 Chapter 9 Software Evolution 26 30/10/2014 Chapter 9 Software Evolution 27

Legacy system categories Business value assessment

 Low quality, low business value  Assessment should take different viewpoints into
▪ These systems should be scrapped. account
 Low-quality, high-business value ▪ System end-users;
▪ Business customers;
▪ These make an important business contribution but are
expensive to maintain. Should be re-engineered or replaced if a ▪ Line managers;
suitable system is available. ▪ IT managers;
 High-quality, low-business value ▪ Senior managers.

▪ Replace with COTS, scrap completely or maintain.  Interview different stakeholders and collate results.
 High-quality, high business value
▪ Continue in operation using normal system maintenance.

30/10/2014 Chapter 9 Software Evolution 28 30/10/2014 Chapter 9 Software Evolution 29

Issues in business value assessment System quality assessment

 The use of the system  Business process assessment

▪ If systems are only used occasionally or by a small number of ▪ How well does the business process support the current goals of
people, they may have a low business value. the business?
 The business processes that are supported  Environment assessment
▪ A system may have a low business value if it forces the use of ▪ How effective is the system’s environment and how expensive is
inefficient business processes. it to maintain?
 System dependability  Application assessment
▪ If a system is not dependable and the problems directly affect ▪ What is the quality of the application software system?
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.
30/10/2014 Chapter 9 Software Evolution 30 30/10/2014 Chapter 9 Software Evolution 31

Business process assessment Factors used in environment assessment

 Use a viewpoint-oriented approach and seek answers

from system stakeholders Factor Questions
Supplier stability Is the supplier still in existence? Is the supplier financially stable and
▪ Is there a defined process model and is it followed? likely to continue in existence? If the supplier is no longer in business,
▪ Do different parts of the organisation use different processes for does someone else maintain the systems?
the same function? Failure rate Does the hardware have a high rate of reported failures? Does the
support software crash and force system restarts?
▪ How has the process been adapted?
Age How old is the hardware and software? The older the hardware and
▪ What are the relationships with other business processes and support software, the more obsolete it will be. It may still function
are these necessary? correctly but there could be significant economic and business
▪ Is the process effectively supported by the legacy application benefits to moving to a more modern system.
software? Performance Is the performance of the system adequate? Do performance
problems have a significant effect on system users?
 Example - a travel ordering system may have a low
business value because of the widespread use of web-
based ordering.

30/10/2014 Chapter 9 Software Evolution 32 30/10/2014 Chapter 9 Software Evolution 33

Factors used in environment assessment Factors used in application assessment

Factor Questions
Support requirements What local support is required by the hardware and
Factor Questions
software? If there are high costs associated with this
support, it may be worth considering system replacement. Understandability How difficult is it to understand the source code of the current
system? How complex are the control structures that are used?
Maintenance costs What are the costs of hardware maintenance and support
Do variables have meaningful names that reflect their function?
software licences? Older hardware may have higher
maintenance costs than modern systems. Support software Documentation What system documentation is available? Is the documentation
may have high annual licensing costs. complete, consistent, and current?
Interoperability Are there problems interfacing the system to other systems? Data Is there an explicit data model for the system? To what extent is
Can compilers, for example, be used with current versions data duplicated across files? Is the data used by the system up to
of the operating system? Is hardware emulation required? date and consistent?
Performance Is the performance of the application adequate? Do performance
problems have a significant effect on system users?

30/10/2014 Chapter 9 Software Evolution 34 30/10/2014 Chapter 9 Software Evolution 35

Factors used in application assessment System measurement

 You may collect quantitative data to make an

Factor Questions assessment of the quality of the application system
Programming language Are modern compilers available for the programming
language used to develop the system? Is the programming ▪ The number of system change requests; The higher this
language still used for new system development? accumulated value, the lower the quality of the system.
Configuration Are all versions of all parts of the system managed by a ▪ The number of different user interfaces used by the system; The
management configuration management system? Is there an explicit
more interfaces, the more likely it is that there will be
description of the versions of components that are used in
the current system? inconsistencies and redundancies in these interfaces.
Test data Does test data for the system exist? Is there a record of ▪ The volume of data used by the system. As the volume of data
regression tests carried out when new features have been (number of files, size of database, etc.) processed by the system
added to the system?
increases, so too do the inconsistencies and errors in that data.
Personnel skills Are there people available who have the skills to maintain the
application? Are there people available who have experience ▪ Cleaning up old data is a very expensive and time-consuming
with the system? process

30/10/2014 Chapter 9 Software Evolution 36 30/10/2014 Chapter 9 Software Evolution 37

Software maintenance Types of maintenance

 Modifying a program after it has been put into use.  Fault repairs
 The term is mostly used for changing custom software. ▪ Changing a system to fix bugs/vulnerabilities and correct
deficiencies in the way meets its requirements.
Generic software products are said to evolve to create
new versions.  Environmental adaptation
▪ Maintenance to adapt software to a different operating
 Maintenance does not normally involve major changes to
environment
the system’s architecture.
▪ Changing a system so that it operates in a different environment
 Changes are implemented by modifying existing (computer, OS, etc.) from its initial implementation.
components and adding new components to the system.  Functionality addition and modification
▪ Modifying the system to satisfy new requirements.

30/10/2014 Chapter 9 Software Evolution 39 30/10/2014 Chapter 9 Software Evolution 40

Maintenance prediction Change prediction

 Maintenance prediction is concerned with assessing  Predicting the number of changes requires and
which parts of the system may cause problems and have understanding of the relationships between a system
high maintenance costs and its environment.
▪ Change acceptance depends on the maintainability of the  Tightly coupled systems require changes whenever the
components affected by the change;
environment is changed.
▪ Implementing changes degrades the system and reduces its
maintainability;  Factors influencing this relationship are
▪ Maintenance costs depend on the number of changes and costs ▪ Number and complexity of system interfaces;
of change depend on maintainability. ▪ Number of inherently volatile system requirements;
▪ The business processes where the system is used.

30/10/2014 Chapter 9 Software Evolution 44 30/10/2014 Chapter 9 Software Evolution 46

Complexity metrics Process metrics

 Predictions of maintainability can be made by assessing  Process metrics may be used to assess maintainability
the complexity of system components. ▪ Number of requests for corrective maintenance;
 Studies have shown that most maintenance effort is ▪ Average time required for impact analysis;
spent on a relatively small number of system ▪ Average time taken to implement a change request;
components. ▪ Number of outstanding change requests.

 Complexity depends on  If any or all of these is increasing, this may indicate a

decline in maintainability.
▪ Complexity of control structures;
▪ Complexity of data structures;
▪ Object, method (procedure) and module size.

30/10/2014 Chapter 9 Software Evolution 47 30/10/2014 Chapter 9 Software Evolution 48

Software reengineering Refactoring

 Restructuring or rewriting part or all of a  Refactoring is the process of making improvements to a

legacy system without changing its program to slow down degradation through change.
functionality.  You can think of refactoring as ‘preventative
 Applicable where some but not all sub-systems maintenance’ that reduces the problems of future
of a larger system require frequent change.
maintenance.  Refactoring involves modifying a program to improve its
 Reengineering involves adding effort to make structure, reduce its complexity or make it easier to
them easier to maintain. The system may be re- understand.
structured and re-documented.
 When you refactor a program, you should not add
functionality but rather concentrate on program
improvement.
30/10/2014 Chapter 9 Software Evolution 49 30/10/2014 Chapter 9 Software Evolution 55