Software
Engineering II
Lecture 07: Software Evolution
Ahmad Fahim Soltani
2025
Review
Outline
Evolution process
Legacy system
Software maintenance
Software Change
Large software systems usually have a long lifetime.
Military or infrastructure systems, such as air traffic
control systems, may have a lifetime of 30 years or
more.
Business systems are often more than 10 years old.
Enterprise software costs a lot of money, so a company
has to use a software system for many years to get a
return on its investment.
Successful software products and apps may have been
introduced many years ago with new versions released
every few years.
The first version of Microsoft Word was introduced in 1983, so it
has been around for more than 40 years.
Software Change
Software change is inevitable
New requirements emerge when the software is used;
The business environment changes;
Error 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 system.
Importance of Evolution
Organization have huge investment in their software system
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
A spiral model of development and
evolution
Software engineering is a spiral process with requirements, design,
implementation, and testing going on throughout the lifetime of the
system.
You start by creating release 1 of the system.
Once delivered, changes are proposed, and the development of
release 2 starts almost immediately.
In fact, the need for evolution may become obvious even before the
system is deployed, so later releases of the software may start
development before the current version has even been released.
Shorter Evolution Time
In the last 10 years, the time between iterations of the spiral
has reduced dramatically.
Before the widespread use of the Internet, new versions of a
software system may only have been released every 2 or 3
years.
Now, because of competitive pressures and the need to
respond quickly to user feedback, the gap between releases of
some apps and web-based systems may be weeks rather than
years.
Seamless Transition
This model of software evolution is applicable when the same
company is responsible for the software throughout its
lifetime.
There is a seamless transition from development to evolution,
and the same software development methods and processes
are applied throughout the lifetime of the software.
Software products and apps are developed using this
approach.
Software Maintenance
The evolution of custom software, however, usually follows a
different model.
There are likely to be discontinuities in the evolution process.
Software development and software evolution are done in
different companies.
Requirements and design documents may not be passed from
one company to another.
When the transition from development to evolution is not
seamless, the process of changing the software after delivery is
called software maintenance.
Evolution Process
Evolution Processes
Software evolution processes depend on
The type software being maintained;
The development processes used;
The skills and experience of the people involved.
For some types of system, such as mobile apps, evolution may
be an informal process, where change requests mostly come
from conversations between system users and developers.
For other types of systems, such as embedded critical systems,
software evolution may be formalized, with structured
documentation produced at each stage in the process
(proposals).
Cont.
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.
These proposals may be based on existing requirements that
have not been implemented in the released system, requests
for new requirements, bug reports from system stakeholders,
and new ideas for software improvement from the system
development team.
Change identification and evolution continues throughout the
system lifetime.
Change Identification and
Evolution Processes
A General Model of the Software
Evolution Process
Change Implementation
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 Request
change requests sometimes relate to problems in operational
systems that have to be tackled urgently. These urgent changes
can arise for three reasons:
1. If a serious system fault is detected that has to be
repaired to allow normal operation to continue or to
address a serious security vulnerability.
2. If changes to the systems operating environment have
unexpected effects that disrupt normal operation.
3. If there are unanticipated changes to the business running
the system, such as the emergence of new competitors or
the introduction of new legislation that affects the system.
The Emergency Repair Process
Agile Methods and Evolution
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.
Handover Problems
Where the development team have used an agile approach
but the evolution team is unfamiliar with agile methods and
prefer a plan-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.
Questions