SOFTWARE

EVOLUTION
ITC-706
PREREQUISITES

• This is an advanced Master level course. Students are

expected to have the following required prior knowledge:
• Basic Software Engineering Concepts
COURSE OBJECTIVES

• Important challenges associated with software evolution;

• Discuss methods and tools addressing these challenges, their
advantages and disadvantages;
• Apply the methods and tools to existing software systems;
• Interpret the results obtained in a scientifically responsible way.
COURSE ORGANISATION

• Lectures
• Assignments
• Surprise Quiz
• Discussion
COURSE CONTENTS
• Introduction
• Identifying and removing software clones
• Predicting bugs from histories
• Object oriented reengineering
• Migration of legacy information system
• From legacy to three-tire and services
• Software testing and evolution
• Evolution issues in aspect oriented programming
• Software architecture evolution
• Empirical studies of open source evolution
REFERENCE MATERIAL

Books
Software Evolution
Tom Mens and Serge Demeyer
DEFINITION
Evolution in general parlance implies that something has changed for the
better.
A process of continuous change from a lower, simpler,
or worse to a higher, more complex, or better state
Software maintenance is the modification of a software product after
delivery to correct faults, to improve performance or other attributes.
ISO/IEC 14764:2006 Software Engineering —
Software Life Cycle Processes — Maintenance
TYPES OF SOFTWARE OR SOFTWARE
EVOLUTION

• S-Type
• P-Type
• E-Type
S-TYPE

• Well known specification and well known solutions

• 100% correct solution
• It works exactly according to the requirement and specification,
the chances of getting changes is very less approximately null.
• E.g. Calculator software, Sequential or bubble sort algorithm, or it
can by any mathematical equation
P-TYPE

• Well known specification and well known solutions

• But practically it is infeasible to implement the solution,
the solution is interactable
• It works on procedures and described specification,
changes might be needed ahead.
• E.g. Gaming software, Chess etc
E-TYPE

• It works on real world problems, environment

• No any specification for the 100% correctness of the solution
• Not because of uncertainty, but these are operating in an
environment which is subject to change
• The specifications are not stable
• E.g Banking Software, trading software, user interfaces etc.
WHY SOFTWARE EVOLUTION OR
MAINTENANCE

• Software Maintenance is important

• Software Maintenance is poorly understood
• Software Maintenance is poorly performed
Evolution is change from maintenance because Maintenance seems
to indicate that the software itself is deteriorating, which is not the
case
SOFTWARE EVOLUTION

• For hardware, maintenance is replacement of used

parts
• For software:
– Source code doesn't wear (erode)
– Maintenance is mainly evolution
SOFTWARE EVOLUTION

• Software systems must be continually adapted or they

become progressively less satisfactory
First law of software evolution
[Lehman, 1974]
SOFTWARE EVOLUTION

A system works within the real world

• The world change:
• New business opportunities
• Growing user expectations
• New laws
• –…
SOFTWARE EVOLUTION

• Software systems must evolve or die (not useful)

• Maintenance is mainly due to external causes
• Maintenance (evolution) is unavoidable
• Better (or perfect) software development cannot change that

Maintenance is a sign of success ! The system is used and

useful, the users want more
 MAJOR PROBLEMS IN SOFTWARE
DEVELOPMENTS …

The requirements The developers This is how the problem is

This is how the
specification was understood it in solved now
that way problem was
defined like this
solved before.

That is the program after This is how the program is

This, in fact, is what the
debugging described by marketing
customer wanted … ;-)
department
MAINTENANCE VS EVOLUTION VS
PRESERVATION
DEFINITION

Legacy software: A system which continues to be used

because of the cost of replacing or redesigning it, and
often despite its poor competitiveness and compatibility
with modern equivalents. The implication is that the
system is large, monolithic and difficult to modify.
mondofacto.com/facts/dictionary
LEGACY SOFTWARE

• 1 sheet ≃ 60 lines of code (LOC)

• both sides = 120 LOC

• 10 sheets = 1200 LOC

• (1.2 KLOC)
LEGACY SOFTWARE
LEGACY SOFTWARE

• 10 sheets = 1200 LOC

• (1.2 KLOC)

Linux kernel 3.6 16 MLOC

MacOS X 10.4 86 MLOC
Debian 5.0 324 MLOC
TRUE/FALSE ?

Maintenance can be eliminated with perfect

development
MAINTENANCE TYPES

• Perfective maintenance is any modification of a software product after

delivery to improve performance or maintainability.
• Corrective maintenance is the reactive modification of a software product
performed after delivery to correct discovered faults.
• Adaptive maintenance is the modification of a software product performed
after delivery to keep a computer program usable in a changed or changing
environment.
• Preventive maintenance refers to software modifications performed for the
purpose of preventing problems before they occur.
MAINTENANCE CATEGORIES
DISTRIBUTION OF MAINTENANCE EFFORT
• Corrective(approx. 21%)
• 12.4% emergency debugging
• 9.3% routine debugging
• Adaptive(approx. 25%)
• 17.3% data environment adaptation
• 6.2% changes to hardware or operating system
• Perfective(approx. 50%)
• 41.8% enhancements for users
• 5.5% improve documentation
• 3.4% other
• Preventive(approx. 4%)
• 4.0% improve code efficiency
STAGED PROCESS MODEL
SOFTWARE STAGES: EVOLUTION AND
SERVICING
• 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.
28
AGILE METHOD
Software evolution is also a crucial ingredient of agile software development
• Focus on the code rather than the design.
• Based on an iterative approach to software development.
• Intended to deliver working software quickly.
• Evolve quickly to meet changing requirements.
• There are claims that agile methods are probably best
suited to small/medium-sized business systems or PC
products.
AGILE METHOD
• Agile proponents believe:
• Current software development processes are too heavyweight or cumbersome
• Too many things are done that are not directly related to software product being produced
• Current software development is too rigid
• Difficulty with incomplete or changing requirements
• Short development cycles (Internet applications)
• More active customer involvement needed

• Agile methods are considered

• Lightweight
• People-based rather than Plan-based
PROBLEMS WITH INCREMENTAL
DEVELOPMENT (FROM A WATERFALL EYE…)
• Management problems
• Progress can be hard to judge and problems hard to find because there is no
documentation to demonstrate what has been done.
• Contractual problems
• The normal contract may include a specification; without a specification, different
forms of contract have to be used.
• Validation problems
• Without a specification, what is the system being tested against?
• Maintenance problems
• Continual change tends to corrupt software structure making it more expensive to
change and evolve to meet new requirements.
FORWARD ENGINEERING

• Following the forward steps of SDLC

• In SDLC, we start from specification phase, analysis, design and implementation
REVERSE ENGINEERING
• The process of creating the design document from source code and the specification documents from
the design document
• Activity needed to understand the architecture /behavior of a large software system, when only reliable
source of information available is source code.
• Activities:
• Program comprehension/understanding
• Task modeling
• User interface issue
• Many others
• Building of mental models of
• Overall software architecture
• Structure
• Behaviors
• Input:
• Source code or some specifications
• Output:
• Higher-level more abstract,
• Why:
• First, reverse engineering may be necessary when the technological platform of the software system (language, tools, machines, operating system) is
outdated, or when the original developers are no longer available.

• When:
• Reverse engineering can also be regarded as the initial phase in the process of software reengineering
RE-ENGINEERING

• It is an activity that improves ones understanding/prepares/improves of/the

software itself usually for increased maintainability, reusability and evolvability
• Activities:
• Reverse Engineering
• Restructuring or refactoring
• Forward Engineering
• Input:
• Existing system/legacy system
• Output:
• New Software
• Why:
• Required for Improved or evolved software having more functionality than the original
software
• When:
• Required when have to deal with legacy system
RE- STRUCTURING AND REFACTORING

• Re- structuring:
• Improves the crucial aspects of the system
• Transformation from one representation form [of a software system] to
another, at the same relative abstraction level, while preserving the
subject system’s external behavior (functionality and semantics).
• Refactoring:
• It is the object-oriented specialization of restructuring.
• When applied to source code, the goal of both is to improve the internal
structure (for example, reduce complexity) of software to make it easier to
understand and modify.
HORSESHOE PROCESS MODEL FOR RE-
ENGINEERING
MODEL EVOLUTION

• Requirements evolution
• Architecture evolution
• Data evolution
• Runtime evolution(runtime evolution, runtime reconfiguration, dynamic adaptation and dynamic
upgrading)

• Service-oriented architectures (SOA)

• Language evolution