Name any Major Local systems that have been modified over

time to add more functionality,beat competition or due to

change in technology
Software
Evolution
SOFTWARE ENGINEERING
Objectives

1. Software Change and reasons

2. Software evolution

3. Evolution processes

4. Software maintenance

5. Legacy system management

Software Change
Software change is inevitable
1. New requirements emerge when the software is used;
2. The business environment changes;
3. Errors must be repaired;
4. New computers and equipment is added to the system;
5. 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
Organisations have huge investments in their software
systems - 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.
Software development
It does not stop when a system is delivered but continues
throughout the lifetime of the system.
◦ Business changes, user expectaton changes etc
Heavy investment spent on the Software product
Evolution
◦ Evolution is the phase in which significant changes to the software
architecture and functionality may be made
Software Evolution
◦ It is the process of making significant changes to the software
architecture and functionality
Model for Software Evolution
software evolution can be seen as 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.
System Evolution Implementers
Internal staff within the organization once the system is deployed
Outsource a different company to offer the system evolution services

an alternative view of the software evolution life cycle to

differentiate between evolution and servicing
Alternative Software Evolution lifecycle
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.

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.
System Evolution Process
Software Evolution Process varies depending on the
◦ type of software being maintained

◦ the development processes used in an organization

◦ the skills of the people involved.

In small organization

May be an Informal Process

Large organization
Process is structured through use of Change Requests Proposals
System change proposals
are the driver for system evolution in all organizations.
May arise 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.
The software evolution process
CR originates from users of system
Impact analysis- The cost and impact of the changes are assessed.
◦ see how much of the system is affected by the change and
◦ how much it might cost to implement the change.
Release Planning-
◦ 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 revisions to the system are designed, implemented, and tested

System Release-
◦ a new version of the system is released
Change requests sometimes relate to system problems that
have to be tackled urgently. May not follow the process

1. If a serious system fault occurs that has to be repaired to allow

normal operation to continue.

2. If changes to the systems operating environment have unexpected

effects that disrupt normal operation{HW/SW}

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
System Maintenance
Software maintenance
◦ is the general process of changing a system after it has been delivered.
◦ Applied to custom software in which separate development groups are
involved before and after delivery
Can be
To correct coding errors,
To correct design errors, or
To correct specification errors or
To accommodate new requirements.
Types of Software Maintenance

1. Fault repairs –corrective maintenance

2. Environmental adaptation-Adaptive maintenance

3. Functionality addition-Perfective maintenance

Types of software maintenance

1. 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
2. Environmental adaptation
This type of maintenance is required when some aspect of the
system’s environment such as the hardware, the platform operating
system, or other support software changes.
 The application system must be modified to adapt it to cope with
these environmental changes.
3. 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.
Maintenance effort distribution

Cost implications

It is cost effective to invest effort in designing and implementing a

system to reduce the costs of future changes
Why the High cost of Functionality Addition
 Team stability
 Once the software is developed, the team breaks-up. At maintenance a
new team is onboard and need time to understand the system

 Poor development practice

 System development contract is different from system maintenance
contract

 Staff Skills
 May be inexperienced and unfamiliar to the software

 Program age and structure

 The software may have aged thus hard to understand and change
Preventive Software Maintenance
Intro,

Older legacy systems, are difficult to understand and change.

 To make legacy software systems easier to maintain, you

can reengineer these systems to
 improve their structure and understandability.
Intro,

Preventive Maintenance can be done through.

Re-engineering

Refactoring
Re-Engineering,

It 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.
Re-Engineering Activities,
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.
Reverse engineering
The program is analyzed and information extracted from it.

Program structure improvement

The control structure of the program is analyzed and modified to make it
easier to read and understand
Program modularization
Related parts of the program are grouped together and, duplication removed

Data reengineering
The data processed by the program is changed to reflect program changes
Advantages of reengineering

1. Reduced risk

 There is a high risk in new software development. There may be

development problems, staffing problems and specification
problems.

2. Reduced cost
◦ The cost of re-engineering is often significantly less than the costs of
developing new software
Refactoring

Refactoring
◦ is the process of making improvements to a program to slow down
degradation through change
◦ means modifying a program to improve its structure, to reduce its
complexity, or to make it easier to understand.

When you refactor a program, you should not add

functionality but should concentrate on program
improvement.
Refactoring helps address
Duplicate Code

Long methods

Many switch statements(use polymorphism)

Data Clumping(use encapsulation)

Refactoring vs reengineering

Re-engineering
◦ 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 system to
create a new system that is more maintainable.

Refactoring
◦ 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 system management
implies that the system is out of date or in need of replacement.

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.
A legacy system assessment Tool
Low quality, low business value
◦ Keeping these systems in operation will be expensive and the rate of the return to
the business will be fairly small. These systems should be scrapped

Low quality, high business value-

◦ These systems should be reengineered to improve their quality. They may be
replaced, if a suitable off-the-shelf system is available.

High quality, low business value

◦ These are systems that don’t contribute much to the business and may not be very
expensive to maintain.Proceed with normal maintenance or scrap

High quality, high business value

◦ These systems have to be kept in operation
Ways of Determining Business Value
The use of system-If rarely used then has low business value

Business processes supported

System dependability

System Outputs
Quote of the Day

Its not what happens that determine the quality or quantity of

life that we live, its what we do about it. What happens,
happens to us all.
◦ Personal issues,hard units,family issues etc.