SE 200

Software Evolution

Ayesha Kanwal
Software Evolution
 Software development does not stop when a system is delivered
 After a system has been deployed, it inevitably has to change if it is to
remain useful
 Business changes and changes to user expectations generate new
requirements for the existing software
 Parts of the software may have to be modified to correct errors that are
found in operation
 To adapt it for changes to its hardware and software platform
 Or to improve its performance or other non-functional
characteristics.
Software Evolution is Costly!
 Software evolution is important because organizations have invested large
amounts of money in their software
 They are now completely dependent on these systems
 Their systems are critical business assets
 and they have to invest in system change to maintain the value of
these assets
What triggers Software Evolution?
 Software evolution may be triggered:
 When software defects are reported
 Changing business requirements
 Changes in other systems in a software system’s environment
Lifetime of Software Evolution
 Useful software systems often have a very long lifetime.
 For example, large 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.
 Software cost a lot of money so a company has to use a software system for
many years to get a return on its investment.
 Obviously, the requirements of the installed systems change as the business
and its environment change.
 Therefore, new releases of the systems, incorporating changes, and
updates, are usually created at regular intervals.
Evolution processes
Evolution Processes
 Software evolution processes vary depending on:
 The type of software being maintained
 The development processes used in an organization
 The skills of the people involved
 System change proposals are the driver for system
evolution in all organizations

 Change proposals may come from 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
Evolution Processes
 The processes of change identification and system evolution are cyclic and
continue throughout the lifetime of a system
Evolution Processes

 The process includes the fundamental activities of change analysis, release

planning, system implementation, and releasing a system to customers.
 The cost and impact of these changes are assessed to see how much of the
system is affected by the change and how much it might cost to implement
the change
Evolution Processes

 If the proposed changes are accepted, a new release of the system is

planned.
 During release planning, all proposed changes (fault repair, adaptation,
and new functionality) are considered.
 A decision is then made on which changes to implement in the next
version of the system.
Change Implementation

 The process then iterates with a new set of changes proposed for the next
release.
Change requests
 Change requests sometimes relate to system problems that have to be
tackled urgently. These urgent changes can arise for three reasons:
Failure
If a serious system fault occurs that has to be repaired to allow normal
operation to continue.

Ripples
If changes to the systems operating environment have unexpected
effects that disrupt normal operation

Business
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.
Change requests
 In these cases, the need to make the change quickly means that you may
not be able to follow the formal change analysis process.
 Rather than modify the requirements and design, you make an
emergency fix to the program to solve the immediate problem

 However, the danger is that the requirements, the software design, and
the code become inconsistent.
Change requests
 Agile methods and processes, may be used for program evolution as well
 Evolution simply involves continuing the agile development process.
Change requests
 However, problems may arise in situations in which there is a handover
from a development team to a separate team responsible for evolution.
 There are two potentially problematic situations:

1. Agile to Plan Driven

 Where the development team has used an agile approach but the
evolution team is unfamiliar with agile methods and prefers a plan-
based approach.
 The evolution team may expect detailed documentation to support
evolution and this is rarely produced in agile processes.
 There may be no definitive statement of the system requirements that
can be modified as changes are made to the system.
Change requests
2. Plan Driven to Agile
 Where a plan-based approach has been used for development but the
evolution team prefers to use agile methods.
 In this case, 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.
 In this case, some reengineering may be required to improve the
code before it can be used in an agile development process.
Software Maintenance
Software Maintenance
 Software maintenance is the general process of changing a system after it
has been delivered.
 The changes made to the software:
 May be simple changes to correct coding errors
 More extensive changes to correct design errors
 Significant enhancements to correct specification errors
 Or accommodate new requirements
 Changes are implemented by modifying existing system components and by
adding new components to the system.
Software Maintenance
 There are three different types of software maintenance:

Fault repairs
 Coding errors are usually relatively cheap to correct
 Design errors are more expensive as they may involve rewriting
several program components
 Requirements errors are the most expensive to repair because of the
extensive system redesign which may be necessary.
Software Maintenance
Environmental Adaptation
 This type of maintenance is required when some aspect of the
system’s environment is changed such as:
 The hardware
 The platform operating system
 Other support software
 The application system must be modified to adapt it to cope with
these environmental changes
Software Maintenance
Functionality Addition
 This type of maintenance is necessary when the system requirements
change in response to organizational or business change
 The scale of the changes required to the software is often much
greater than for the other types of maintenance.
Software Maintenance
 These types of maintenance are also generally recognized with different
names:
 ‘Corrective maintenance’ is universally used to refer to maintenance for
fault repair.
 ‘Adaptive maintenance’ means adapting to a new environment and
adapting the software to new requirements.
 ‘Perfective maintenance’ means perfecting the software by
implementing new requirements
 It also means maintaining the functionality of the system by
improving its structure and its performance.
Software Maintenance
 When you adapt the system to a new environment, you may add
functionality to take advantage of new environmental features.
 Software faults are often exposed because users use the system in
unanticipated ways.
 Changing the system to accommodate their way of working is the best
way to fix these faults.
Software Maintenance
 It is usually cost effective to invest effort in designing and implementing a
system to reduce the costs of future changes.
 Adding new functionality after delivery is expensive because you have to
spend time learning the system and analyzing the impact of the proposed
changes.
 Therefore, work done during development to make the software easier
to understand and change is likely to reduce evolution costs.
 Good software engineering techniques, such as precise specification,
the use of object-oriented development, and configuration
management, contribute to maintenance cost reduction.
Software Maintenance
 It is usually more expensive to add functionality after a system is in
operation than it is to implement the same functionality during
development.
 The reasons for this are:

Team stability
 After a system has been delivered, it is normal for the development
team to be broken up and for people to work on new projects.
 The new team or the individuals responsible for system maintenance
do not understand the system or the background to system design
decisions.
 They need to spend time understanding the existing system before
implementing changes to it.
Software Maintenance
Poor development practice
 The contract to maintain a system is usually separate from the system
development contract.
 The maintenance contract may be given to a different company
rather than the original system developer.
 This factor (along with the lack of team stability) means that there is
no incentive for a development team to write maintainable software.
 If a development team can cut corners to save effort during
development it is worthwhile for them to do so
 Even if this means that the software is more difficult to change in
the future.
Software Maintenance
Staff Skills
 Maintenance staff are often relatively inexperienced and unfamiliar
with the application domain.
 Maintenance has a poor image among software engineers.
 It is seen as a less-skilled process than system development and is
often allocated to the most junior staff
 Furthermore, old systems may be written in obsolete
programming languages.
 The maintenance staff may not have much experience of
development in these languages and must learn these languages
to maintain the system.
Software Maintenance
Program age and structure
 As changes are made to programs, their structure tends to degrade
 Consequently, as programs age, they become harder to
understand and change.
 Some systems have been developed without modern software
engineering techniques.
 They may never have been well structured and were perhaps
optimized for efficiency rather than understandability.
 System documentation may be lost or inconsistent.
 Old systems may not have been subject to thorough configuration
management so time is often wasted finding the right versions of
system components to change.
Software Re-Engineering
Software Re-Engineering
 The process of system evolution involves understanding the program that
has to be changed and then implementing these changes.
 However, are difficult to understand and change.
 The programs may have been optimized for performance or space
utilization at the expense of understandability,
 Or the initial program structure may have been corrupted by a
series of changes
Software Re-Engineering
 To make them easier to maintain, you can reengineer these systems to
improve their structure and understandability.
 Reengineering may involve
 Re-documenting the system
 Refactoring the system architecture
 Translating programs to a modern programming language
 And modifying and updating the structure and values of the
system’s data.
 The functionality of the software is not changed and, normally, you
should try to avoid making major changes to the system architecture.
Software Re-Engineering
 There are two important benefits from reengineering rather than
replacement:
Reduced risk
 There is a high risk in redeveloping business-critical software.
 Errors may be made in the system specification or there may be
development problems.
 Delays in introducing the new software may mean that business is
lost and extra costs are incurred.
Software Re-Engineering
Reduced cost
 The cost of reengineering may be significantly less than the cost of
developing new software.
 With modern software technology, the relative cost of
reimplementation is probably less than this but will still
considerably exceed the costs of reengineering
Reengineering Process Model

Source code translation

 Using a translation tool, the program is converted from an old programming
language to a more modern version of the same language or to a different
language
Preventative Maintenance by Refactoring
 Although reengineering and refactoring are both intended to make
software easier to understand and change, they are not the same thing
 Reengineering takes place after a system has been maintained for
some time and maintenance costs are increasing.
 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.
Legacy System Management
 Legacy systems are old systems that are still useful and are
sometimes critical to business operation.
 They may be implemented using outdated languages and
technology or may use other systems that are expensive to
maintain. Often their structure has been degraded by change and
documentation is missing or out of date.
 Nevertheless, it may not be cost effective to replace these systems.
They may only be used at certain times of the year or it may be too
risky to replace them because the specification has been lost.
Legacy system management
 Most organizations usually have legacy systems that they use, with a
limited budget for maintaining and upgrading these systems.
 They have to decide how to get the best return on their investment.
 This involves making a realistic assessment of their legacy systems and
then deciding on the most appropriate strategy for evolving these
systems.
 There are four strategic options:

1. Scrap the system completely

 This option should be chosen when the system is not making an
effective contribution to business processes.
 This commonly occurs when business processes have changed since
the system was installed and are no longer reliant on the legacy
system.
Legacy system management
2. Leave the system unchanged and continue with regular maintenance
 This option should be chosen when the system is still required but is
fairly stable and the system users make relatively few change requests.

3. Reengineer the system to improve its maintainability

 This option should be chosen when the system quality has been
degraded by change
 And where a new change to the system is still being proposed.
 This process may include developing new interface components so that
the original system can work with other, newer systems.
Legacy system management
4. Replace all or part of the system with a new system
 This option should be chosen when factors, such as new hardware,
mean that the old system cannot continue in operation
 Or where off-the-shelf systems would allow the new system to be
developed at a reasonable cost.
 In many cases, an evolutionary replacement strategy can be adopted in
which major system components are replaced by off-the- shelf systems
with other components reused wherever possible.
questions