SOFTWARE ENGINEERING

HEX GROUP

“The Inevitable”

SOFTWARE EVOLUTION
Motivation for studying software evolution
Motivation for studying software evolution

3
Motivation for studying software evolution

4
Motivation for studying software evolution

5
Motivation for studying software evolution

6
 OBJECTIVES
To explain why change is inevitable if software systems are to remain useful

To discuss software maintenance and maintenance cost factors

To describe the processes involved in software evolution

To discuss an approach to assessing evolution strategies for legacy systems

To Relate the evolution process to our software engineering projects.

7
 SOFTWARE CHANGE
 Software change is inevitable

New requirements emerge when the software is 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 organisations is implementing and managing change to their existing
software systems.

8
 IMPORTANCE OF SOFTWARE EVOLUTION
Organizations 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 evolving

existing software rather than developing new software.

9
THE SPIRAL MODEL OF EVOLUTION

10
 PROGRAM EVOLUTION DYNAMICS
Program evolution dynamics is the study of the processes of system change.

After major empirical studies, Lehman and Belady proposed that there were a
number of ʻlawsʼ which applied to all systems as they evolved.

There are sensible observations rather than laws. They are applicable to large
systems developed by large organisations. Perhaps less applicable in other cases.

11
 LEHMAN’S LAWS
Continuing change
 A program that is used in a real-world environment necessarily must change or become
progressively less useful in that environment.

Increasing complexity
 As an evolving program changes, its structure tends to become more complex. Extra resources
must be devoted to preserving and simplifying the structure.

Large program evolution

 Program evolution is a self-regulating process. System attributes such as size, time between
releases and the number of reported errors is approximately invariant for each system release.

12
 LEHMAN’S LAWS
Organisational stability
 Over a program’s lifetime, its rate of development is approximately constant and independent of the
resources devoted to system development.

Conservation of familiarity
 Over the lifetime of a system the incremental change in each release is approximately constant.

Continuing growth
 The functionality offered by systems has to continually increase to maintain user satisfaction.

13
 LEHMAN’S LAWS
Declining quality
 The quality of systems will appear to be declining unless they are adapted to changes in their
operational environment.

Feedback system
 Evolution processes incorporate multi-agent, multi-loop feedback systems and you have to
treat them as feedback systems to achieve significant product improvement.

14
 LEHMAN’S SYSTEM TYPES
S-SYSTEM: static
 The type of software evolution which works exactly according to the requirements and
specification, the chances of getting changes are very little.

 Example a calculator

P-SYSTEM: practical
 requirements based on approximate solution to a problem, but real-world remains stable.

 Example Chess program

15
 LEHMAN’S SYSTEM TYPES

E-SYSTEM: embedded
 The type of software evolution which works on real world problems and changes
as the world changes.

 Example is banking software

1
6
 APPLICABILITY OF LEHMAN’S LAWS

Lehmanʼs laws seem to be generally applicable to large, tailored systems

developed by large organisations.
 Confirmed in more recent work by Lehman on the FEAST (Feed back evolution and
software technology) project.

 It is open on how they should be modified for

 Shrink-wrapped software products;

 Systems that incorporate a significant number of COTS components;

 Small organisations;

 Medium sized systems.

1
7
 SOFTWARE CHANGE STRATEGIES

Software maintenance
Changes are made in response to changed requirements but the
fundamental software structure is stable
Architectural transformation
The architecture of the system is modified
Generally from a centralised to a distributed architecture
Software re-engineering
No new functionality is added to the system but it is restructured and
reorganised to facilitate future changes
These strategies may be applied separately or together

1
8
 SOFTWARE MAINTAINANCE
Modifying a program after it has been put into use
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

1
9
 MAINTAINANCE IS INEVITABLE

The system requirements are likely to change while the system is being
developed because the environment is changing. Therefore a delivered
system won't meet its requirements!
Systems are tightly coupled with their environment. When a system is
installed in an environment it changes that environment and therefore
changes the system requirements.
Systems MUST be maintained therefore if they are to remain useful in
an environment.

2
0
 TYPES OF MAINTAINANCE

Maintenance to repair software faults.

 Changing a system to correct deficiencies in the 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.
Preventive maintenance: Modification of a software product after delivery to
detect and correct latent faults in the software product before they become
effective faults.

2
1
 ISO/IEC 14764 - maintenance types
•. Corrective
• Maintenance to repair software faults Fault repair
(17%)
• Adaptive
• Maintenance to adapt software to a Software
Functionality
addition or
different operating environment adaptation modification
(18%) (65%)
• Perfective
• Maintenance to add to or modify the
system’s functionality

Change Impact System release Change System

requests analysis planning implementa tion release

Perfective Adaptive Corrective

maintenance maintenance maintenance
22
 SYSTEM EVOLUTION VS DECLINE
Is the cost of maintenance too high?
 Is the system reliability unacceptable?
 Can the system no longer adapt to further change, and within a reasonable
amount of time?
 Is system performance still beyond prescribed constraints?
Are system functions of limited usefulness?
 Can other systems do the same job better, faster or cheaper?
 Is the cost of maintaining the hardware great enough to justify replacing it with
cheaper, newer hardware?

23
SYSTEM EVOLUTION VS DECLINE (case study)
Consider the case of Nokia and the Symbian OS
Symbian is a discontinued mobile operating system (OS) and computing
platform designed for smartphones.
As a pioneer that established the smartphone industry, it was the most popular
smartphone OS on a worldwide average until the end of 2010.
The Symbian Foundation disintegrated in late 2010 and Nokia took back control of
the OS development.
 In February 2011, Nokia, by now the only remaining company still supporting
Symbian outside Japan, announced that it would use Microsoft's Windows Phone
7 as its primary smartphone platform, while Symbian would be gradually wound
down.

24
 MAINTENANCE TEAM RESPONSIBILITIES
understanding the system
 locating information in system documentation
 keeping system documentation up-to-date
extending existing functions to accommodate new or changing
requirements
adding new functions to the system
 finding the source of system failures or problems

25
 MAINTENANCE TEAM RESPONSIBILITIES
locating and correcting faults
 answering questions about the way the system works
 restructuring design and code components
 rewriting design and code components
 deleting design and code components that are no longer useful
managing changes to the system as they are made

26
 MAINTENANCE PROBLEMS
Staff problems
Limited understanding
 Management priorities
Morale

Technical problems
 Artifacts and paradigms
Testing difficulties

27
FACTORS AFFECTING MAINTENANCE EFFORT
Application type
 System novelty
Turnover and maintenance staff ability
 System life span
 Dependence on a changing environment
 Hardware characteristics
Design quality
 Code quality
 Documentation quality
 Testing quality
28
 MEASURING MAINTAINABILITY

NECESSARY DATA DESIRABLE DATA

• time at which problem is reported • ratio of total change implementation
• time lost due to administrative delay time to total number of changes
• time required to analyze problem
implemented
• time required to specify which changes are to be • number of unresolved problems
made
• time spent on unresolved problems
• time needed to make the change
• percentage of changes that introduce
• time needed to test the change
new faults
• time needed to document the change
• number of components modified to
implement a change

29
 MAINTENANCE COSTS
Usually greater than development costs (2* to 100* depending on the application)
Affected by both technical and non-technical factors
Increases as software is maintained
Maintenance corrupts the software structure, making further maintenance more
difficult
Ageing software can have high support costs
(e.g. old languages, compilers etc.)
Think of your software as continuously evolving

30
DEVELOPMENT/MAINTENANCE COSTS

31
 MAINTENANCE COST FACTORS
Team stability
 Maintenance costs are reduced if the same staff are involved with them for some time
Contractual responsibility
 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

32
 MAINTENANCE PREDICTION
Maintenance prediction is concerned with assessing which parts of the system
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

33
MAINTENANCE PREDICTION

34
 CHANGE PREDICTION
Predicting the number of changes requires and understanding of the
relationships 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.

35
 COMPLEXITY METRICS
Predictions of maintainability can be made by assessing the complexity of system
components.

Studies have shown that most maintenance effort is spent on a relatively small
number of system components.

Complexity depends on
 Complexity of control structures;
 Complexity of data structures;
 Object, method (procedure) and module size.

36
 PROCESS METRICS
Process measurements may be used to assess maintainability
Number of requests for corrective maintenance;
Average time required for impact analysis;
Average time taken to implement a change request;
Number of outstanding change requests.

If any or all of these is increasing, this may indicate a decline in maintainability.

37
 SOFTWARE EVOLUTION Process
Evolution processes depend on
The type of software being maintained;
The development processes used;
The skills and experience of the people involved.

Proposals for change are the driver for system evolution. Change
identification and evolution continue throughout the system lifetime.

38
CHANGE IDENTIFICATION AND EVOLUTION

39
THE SYSTEM EVOLUTION PROCESS

40
CHANGE IMPLEMENTATION

41
 URGENT CHANGE REQUESTS
Urgent changes may have to be implemented without going through
all stages of the software engineering process
 If a serious system fault has to be repaired;
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).

42
EMERGENCY REPAIR

43
 CONFIGURATION CONTROL PROCESS
Problem discovered by or change requested by user/ customer/developer, and recorded
 Change reported to the Configuration Control Board (CCB)
CCB discusses problem: determines nature of change, who should pay
CCB discusses source of problem, scope of change, time to fix; they assign
severity/priority and analyst to fix
Analyst makes change on test copy
Analyst works with librarian to control installation of change
 Analyst files change report

44
 CHANGE CONTROL ISSUES
Synchronization: When was the change made?
 Identification: Who made the change?
 Naming: What components of the system were changed?
 Authentication: Was the change made correctly?
 Authorization: Who authorized that the change be made?
 Routing: Who was notified of the change?
Cancellation: Who can cancel the request for change?
 Delegation: Who is responsible for the change?
Valuation: What is the priority of the change?
45
 IMPACT ANALYSIS
Impact analysis is the evaluation of the many risks
associated with the change, including estimates of effects on
resources, effort, and schedule.
 Work product
any development artifact whose change is significant, e.g.
requirements, design and code components, test cases, etc.
the quality of one can affect the quality of others
 Horizontal traceability
 relationships of components across collections of work
products
Vertical traceability
 relationships among parts of a work product
46
 ARCHITECTURAL EVOLUTION
There is a need to convert many legacy systems from a centralised
architecture to a distributed (e.g., client-server) architecture
Change drivers
Hardware costs. Servers are cheaper than mainframes
User interface expectations. Users expect graphical user interfaces
Distributed access to systems. Users wish to access the system from different,
geographically separated, computers

47
 SOFTWARE REENGINEERING
Reorganising and modifying existing software systems to make them
more maintainable
Re-structuring or re-writing part or all of a legacy system without
changing its functionality
Applicable where some but not all sub-systems
of a larger system require frequent maintenance
When to re-engineer
 When system changes are mostly confined to part of the system then re-engineer that part
 When hardware or software support becomes obsolete
 When tools to support re-structuring are available

48
 REENGINEERING ADVANTAGES
Reduced risk
There is a high risk in new software development. 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

49
FORWARD VS REENGINERING

50
REENGINERING PROCESS

51
 REENGINEERING PROCESS ACTIVITIES
 Source code translation
Convert code to a new language.
 Reverse engineering
 Analyze the program to understand it;
 Program structure improvement
 Restructure automatically for understandability;
 Program modularization
Reorganize the program structure;
 Data reengineering
Clean-up and restructure system data.

52
 REENGINEERING APPROACHES
Automated progr am Program and data
restructuring restructuring

Automated source Automated r estructuring Restructuring plus

code conversion with manual changes architectural changes

Increased cost

53
 REENGINEERING COST FACTORS
 The quality of the software to be reengineered.
The tool support available for reengineering.
The extent of the data conversion which is required.
The availability of expert staff for reengineering.
 This can be a problem with old systems based on technology
that is no longer widely used.

54
 SOURCE CODE TRANSLATION
• Involves converting the code from one language (or language version)
to another e.g. FORTRAN to C
• May be necessary because of:
• Hardware platform update
• Staff skill shortages
• Organisational policy changes
• Only realistic if an automatic translator is available
PROGRAM RESTRUCTURING – SPAGHETTI LOGIC

Start: Get (Time-on, Tim e-off, Time, Setting, Tem p, Switch)

if Switch = off goto o ff
if Switch = on g oto on
go to Cntrl d
off: if Heating-s tatus = on go to Sw-off
go to loop
on : if Heating-s tatus = o ff g o to Sw-on
go to loop
Cntrld: if Time = Time-on goto o n
if Time = Time-off goto off
if Time < Time-on goto Start
if Time > Time-off goto Start
if Te mp > Setting then goto o ff
if Te mp < Setting then goto o n
Sw-off: Heatin g-sta tu s := off
go to Switch
Sw-on: Heatin g-status := o n
Switch: Switch-heating
loop: go to Start
PROGRAM RESTRUCTURING – STRUCTURED CONTROL LOGIC
loop
-- The Get statement finds values for the given variables from the system’s
-- environment.
Get (Time-on, Time-off, Time, Setting, Temp, Switch) ;
case Switch of
when On => if Heating-status = off then
Switch-heating ; Heating-status := on ;
end if ;
when Off => if Heating-status = on then
Switch-heating ; Heating-status := off ;
end if;
when Controlled =>
if Time >= Time-on and Time < = Time-off then
if Temp > Setting and Heating-status = on then
Switch-heating; Heating-status = off;
elsif Temp < Setting and Heating-status = off then
Switch-heating; Heating-status := on ;
end if;
end if ;
end case ;
end loop ;
Program restructuring – Condition simplification

-- Complex condition
if not (A > B and (C < D or not ( E > F) ) )...

-- Simplified condition
if (A <= B and (C>= D or E > F)...
 Program modularisation
• The process of re-organising a program so that related program parts
are collected together in a single module
• Usually a manual process that is carried out by program inspection
and re-organisation
 Recovering data abstractions
• Many legacy systems use shared tables and global data to save
memory space
• Causes problems because changes have a wide impact in the system
• Shared global data may be converted to objects or ADTs
• Analyse common data areas to identify logical abstractions
• Create an ADT or object for these abstractions
• Use a browser to find all data references and replace with reference to the
data abstraction
 Reverse engineering
• Analysing software with a view to understanding its design and
specification
• May be part of a re-engineering process but may also be used to re-
specify a system for re-implementation
• Builds a program data base and generates information from this
• Program understanding tools (browsers, cross-reference generators,
etc.) may be used in this process
 Why reverse engineer
• Reverse engineering often precedes re-engineering but is
sometimes worthwhile in its own right
• The design and specification of a system may be reverse
engineered so that they can be an input to the requirements
specification process for the system’s replacement
• The design and specification may be reverse engineered to
support program maintenance
 LEGACY SYSTEM EVOLUTION
● 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.
 LEGACY SYSTEMS
❍ Low quality, low business value
These systems should be scrapped.
❍ 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.
 BUSINESS ASSESSMENT
Assessment should take different viewpoints into account
 System end-users;
 Business customers;
 Line managers;
 IT managers;
 Senior managers.
 Interview different stakeholders and collate results.
 QUALITY ASSESSMENT
Business process assessment
 How well does the business process support the
current goals of the business?
 Environment assessment
 How effective is the systemʼs environment and how
expensive is it to maintain?
 Application assessment
 What is the quality of the application software
system?
 Key points
Software change strategies include software maintenance,
architectural evolution and software re-engineering
Lehman’s Laws are invariant relationships that affect the
evolution of a software system
Maintenance types are adaptive, perfective, and corrective
 Key points
The costs of software change usually exceed the costs of
software development
Factors influencing maintenance costs include staff stability, the
nature of the development contract, skill shortages and
degraded system structure
Architectural evolution is concerned with evolving centralised
to distributed architectures
Re-engineering reorganizes and modifies existing software
systems to make them more maintainable
THANK YOU