Lecturer: A.Prof. Dr.
Amr Thabet
Reference: Ian Sommerville, “Software engineering”, 10th edition, 2015
1
Chapter 9 –
Evolution
Software
LECTURER: A.PROF. DR. AMR THABET
Topics covered 2
Reference: Ian Sommerville, “Software engineering”, 10th edition, 2015
Evolution processes
Change processes for software systems
Lecturer: A.Prof. Dr. Amr Thabet
Program evolution dynamics
Understanding software evolution
Software maintenance
Making changes to operational software systems
Legacy system management
Making decisions about software change
Software change 3
Reference: Ian Sommerville, “Software engineering”, 10th edition, 2015
Software change is inevitable
New requirements emerge when the software is
Lecturer: A.Prof. Dr. Amr Thabet
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.
Importance of evolution 4
Reference: Ian Sommerville, “Software engineering”, 10th edition, 2015
Organisations have huge investments in their
software systems - they are critical business assets.
Lecturer: A.Prof. Dr. Amr Thabet
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.
Lecturer: A.Prof. Dr. Amr Thabet
Reference: Ian Sommerville, “Software engineering”, 10th edition, 2015
5
Evolution and servicing
Evolution and servicing 6
Reference: Ian Sommerville, “Software engineering”, 10th edition, 2015
Evolution
The stage in a software system’s life cycle where it is in
Lecturer: A.Prof. Dr. Amr Thabet
operational use and is evolving as new requirements
are proposed and implemented in the system.
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.
Evolution processes 7
Reference: Ian Sommerville, “Software engineering”, 10th edition, 2015
Software evolution processes depend on
The type of software being maintained;
Lecturer: A.Prof. Dr. Amr Thabet
The development processes used;
The skills and experience of the people involved.
Proposals for change are the driver for 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.
Lecturer: A.Prof. Dr. Amr Thabet
Reference: Ian Sommerville, “Software engineering”, 10th edition, 2015
8
and evolution processes
Change identification
Lecturer: A.Prof. Dr. Amr Thabet
Reference: Ian Sommerville, “Software engineering”, 10th edition, 2015
9
The software evolution
process
Lecturer: A.Prof. Dr. Amr Thabet
Reference: Ian Sommerville, “Software engineering”, 10th edition, 2015
10
Change implementation
Change implementation 11
Reference: Ian Sommerville, “Software engineering”, 10th edition, 2015
Iteration of the development process where the
revisions to the system are designed,
Lecturer: A.Prof. Dr. Amr Thabet
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.
Urgent change requests 12
Reference: Ian Sommerville, “Software engineering”, 10th edition, 2015
Urgent changes may have to be implemented
without going through all stages of the software
Lecturer: A.Prof. Dr. Amr Thabet
engineering process
If a serious system fault has to be repaired to allow
normal operation 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).
Lecturer: A.Prof. Dr. Amr Thabet
Reference: Ian Sommerville, “Software engineering”, 10th edition, 2015
13
The emergency repair
process
Agile methods and 14
evolution
Reference: Ian Sommerville, “Software engineering”, 10th edition, 2015
Agile methods are based on incremental
development so the transition from development
Lecturer: A.Prof. Dr. Amr Thabet
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.
Handover problems 15
Reference: Ian Sommerville, “Software engineering”, 10th edition, 2015
Where the development team have used an
agile approach but the evolution team is
unfamiliar with agile methods and prefer a plan-
Lecturer: A.Prof. Dr. Amr Thabet
based approach.
The evolution team may expect detailed
documentation to support evolution and this is not
produced in agile processes.
Where a plan-based approach has been used for
development but the evolution team prefer to
use agile methods.
The evolution team may have to start from scratch
developing automated tests and the code in the
system may not have been refactored and
simplified as is expected in agile development.
Software maintenance 16
Reference: Ian Sommerville, “Software engineering”, 10th edition, 2015
Modifying a program after it has been put into
use.
Lecturer: A.Prof. Dr. Amr Thabet
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.
Types of maintenance 17
Reference: Ian Sommerville, “Software engineering”, 10th edition, 2015
Maintenance to repair software faults
Changing a system to correct deficiencies in the
Lecturer: A.Prof. Dr. Amr Thabet
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.
Lecturer: A.Prof. Dr. Amr Thabet
Reference: Ian Sommerville, “Software engineering”, 10th edition, 2015
18
Figure 9.8 Maintenance
effort distribution
Maintenance costs 19
Reference: Ian Sommerville, “Software engineering”, 10th edition, 2015
Usually greater than development costs (2* to
100* depending on the application).
Lecturer: A.Prof. Dr. Amr Thabet
Affected by both technical and non-
technical
factors.
Increases as software is maintained.
Maintenance corrupts the software structure
so
makes further maintenance more difficult.
Ageing software can have high support costs
(e.g. old languages, compilers etc.).
Maintenance cost factors 20
Reference: Ian Sommerville, “Software engineering”, 10th edition, 2015
Team stability
Maintenance costs are reduced if the same staff are
involved with them for some time.
Contractual responsibility
Lecturer: A.Prof. Dr. Amr Thabet
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.
Maintenance prediction 21
Reference: Ian Sommerville, “Software engineering”, 10th edition, 2015
Maintenance prediction is concerned
with assessing which parts of the system
Lecturer: A.Prof. Dr. Amr Thabet
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.
Lecturer: A.Prof. Dr. Amr Thabet
Reference: Ian Sommerville, “Software engineering”, 10th edition, 2015
22
Maintenance prediction
Change prediction 23
Reference: Ian Sommerville, “Software engineering”, 10th edition, 2015
Predicting the number of changes requires
and understanding of the relationships
Lecturer: A.Prof. Dr. Amr Thabet
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.
System re-engineering 24
Reference: Ian Sommerville, “Software engineering”, 10th edition, 2015
Re-structuring or re-writing part or all of a
legacy system without changing its
Lecturer: A.Prof. Dr. Amr Thabet
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 25
reengineering
Reference: Ian Sommerville, “Software engineering”, 10th edition, 2015
Reduced risk
There is a high risk in new software development.
Lecturer: A.Prof. Dr. Amr Thabet
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.
Refactoring and 26
reengineering
Reference: Ian Sommerville, “Software engineering”, 10th edition, 2015
Re-engineering takes place after a system has
been maintained for some time and
Lecturer: A.Prof. Dr. Amr Thabet
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.
Legacy system 27
management
Reference: Ian Sommerville, “Software engineering”, 10th edition, 2015
Organisations that rely on legacy systems
must choose a strategy for evolving these
Lecturer: A.Prof. Dr. Amr Thabet
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.
Legacy system categories 28
Reference: Ian Sommerville, “Software engineering”, 10th edition, 2015
Low quality, low business value
These systems should be scrapped.
Lecturer: A.Prof. Dr. Amr Thabet
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.
Key points 29
Reference: Ian Sommerville, “Software engineering”, 10th edition, 2015
There are 3 types of software maintenance, namely
bug fixing, modifying software to work in a new
environment, and implementing new or changed
Lecturer: A.Prof. Dr. Amr Thabet
requirements.
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.
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.
