1. SOFTWARE EVOLUTION
1

2. 2

3. 3

4. 4

5. 5

6. 6

7. 7

8. 8

9. WHAT ARE LEGACY SYSTEMS?
9

10. What are legacy systems?
• Systems developed for a specific client that have been in
service for a long-time
• Many of these systems were developed years ago using
obsolete technologies
• They are likely to be business critical systems required
for normal operation of a business
• These are the systems that everyone worried about
when the Y2K concerns became public
10

11. Legacy System Replacement
• The business risks associated with the strategy of
scrapping a legacy system and replacing it with a
new one are not insignificant
– legacy systems rarely have complete specifications
– changes are not likely to be documented well at all
– business processes are reliant on the system
– the legacy system may contain embedded business
rules that are not formally documented elsewhere
– software development is risky and not is always
successful
11

12. Changing Legacy Systems
• All systems must change to remain useful
• Changes to legacy systems can be very expensive
– components may be implemented with different programming
styles as changes are implemented
– system may be written in an obsolete language
– system documents often out-of-date
– system structure may be corrupted by years of maintenance
activities
– techniques used to save space or increase speed may have
obscured understandability
– file structures used may be incompatible with each other
12

13. Legacy System Risks
• Replacing a legacy system is both expensive and risky
• Maintaining a legacy system is also expensive and risky
• Sometimes a the decision is made (based on the costs
and risks involved) to extend system life-time using
techniques like re-engineering
13

14. Socio-Technical Systems
• Lagacy systems are more than just software systems
• Sommerville describes legacy systems as socio-
technical systems
• Socio-Technical System Layers
– business processes
– application software
– support software
– hardware
14

15. Legacy System Structures
1. System Hardware
– could be a mainframe
1. System Software
2. Application Software
3. Application Data
– business critical data often used by several programs
1. Business Processes
– processes that support a business objective and rely on the legacy
systems hardware and software
1. Business Policies and Rules
– business operation constraints
15

16. Legacy System Components
E beds
m
know dge of
le
Uses
Sup port Application Busin po
ess licies
software softw are and rules
Runs-on Runs-on Uses Uses Constrains
System Application Business
ha are
rdw data processes
16

17. System Change
• In theory
– it should be possible to replace one layer in a socio-technical system
without making any changes to the other layers
• In practice
– changing one layer introduces new facilities that must be used in higher
level layers
– changing the software may require hardware changes to maintain system
performance
– it may be impossible to maintain hardware interfaces because of the huge
differences between mainframe and client-server architectures
17

18. Legacy Application System
Pro am1
gr Program2 Program3
File 1 File 2 File 3 File 4 File 5 File 6
Pro am4
gr Pr am5
ogr Program6 Program7
18

19. Database Management System
P gra
ro m Pogr m
r a P gra
ro m Pogr m
r a
1 2 3 4
D ta a
a b se d sc s
e ribe Logic l a d
a n
m n ge e t
a a mn ph ic l
ys a
sy m
ste da m de
ta o ls
19

20. Transaction Processing
Account queries
and updates
Serialised
transactions
Teleprocessing Accounts
monitor database
ATMs and terminals
20

21. Legacy Data Concerns
• File-based systems may have several programs accessing
and modifying incompatible data files
• It would be common to move from a file-based system to a
database management system (DBMS)
• It is possible that the DBMS itself has become obsolete
and needs to be replaced
• The DBMS may be incompatible with other database
systems used in the business
• The teleprocessing monitor used in a transaction
processing system may only work with a particular DBMS
and mainframe environment
21

22. Legacy System Design
• Most legacy systems were designed without using object-oriented
techniques
• A legacy system is not likely to have been designed as a set of
interacting objects
• A legacy system is more likely to be designed using a function-
oriented design strategy
• Many software engineering methods and CASE tools support
function-oriented design
• Function-oriented design is common in MIS applications
22

23. A Function-Oriented View of Design
Shared m o
em ry
F1 F2 F3
F4 F5
23

24. Functional Design Process
• Dataflow Design
– used to model information flow
• Structural Decomposition
– decomposition of functions into sub-functions shown
using graphical structure chart that makes use of the
input-process-output model
• Detailed Design
– the entities and their interfaces are recorded in the data
dictionary and the processing detail is represented
using a program design language (PDL)
24

25. Input-Process-Output Model
S te
ys m
In t
pu P e
roc ss O ut
utp
25

26. Input-Process-Output
• Input Components
– read and validate data received file or device
• Processing Components
– carry out transformations on the input data
• Output Components
– format and display results of the data transformations
• Input, process, and output can be represented as
functions with data flowing between them and as
a bubble in the dataflow diagram
26

27. Using Function-Oriented
Design
• For some systems (e.g. transaction processing systems)
a function-oriented approach may be more natural than
an object-oriented approach
• Companies with a heavy investment in CASE tools that
support function-oriented design may not want to pay the
price of moving to an object-oriented approach
27

28. Legacy System Assessment
• Companies that rely on legacy systems must have a
strategy for evolving these systems
– scrap the system and modify business practices so it is not
needed
– continue maintaining the old system
– re-engineer the old system to improve maintainability
– replace the old system with a new system
• The strategy chosen depends on the quality of the
system and its business value
28

29. Business Value Assessment
• Need to take different viewpoints into account
– system end-users
– business customers
– business managers
– IT managers
– senior management
• Process is similar to system feasibility assessment
– Interview stakeholders and collate the results
29

30. System 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 environment?
– How costly is it to maintain?
• Application Assessment
– What is the quality of the application software system?
30

31. Business Process Assessment
• Interview representatives from each group of
stakeholders and ask
– Is there a defined process model and is it followed?
– Does everyone in the company use the same
processes to achieve the same function?
– How has the process been adapted to meet local
needs?
– What are the relationships between this process and
other business processes?
– Is the process supported effectively by the legacy
system? 31

32. Environment Assessment
• System software or hardware supplier stability
• Hardware failure rate
• Age of hardware and software
• Performance of system
• Support requirements for hardware and software
• Maintenance costs
• Interoperability with other business systems
32

33. Application Assessment
Factors
• Understandability of source code
• Documentation quality
• Data model (existence and duplication)
• Performance
• Programming language used
• Configuration management controls
• Test data existence and regression test results
• Team members capable of maintaining application
33

34. System Measurement
• Collecting quantitative data can help assess the quality
of the application
– number of system change requests made
– number of user interfaces in the system
– volume of data used by system
– reliability measures
– defect detection or removal rates
34

35. System quality and business value
Business value
High business value
Low quality High business value
High quality
9
10 8
6
7
Low business value Low business value
Low quality High quality
2 5
1 3 4
System quality
35

36. Legacy System Categories
• Low quality, Low business value
– scrap the system
• Low quality, High business value
– should be re-engineered or replaced if a suitable
system is available
• High-quality, Low business value
– replace with COTS, scrap system, or maintain
• High-quality, High business value
– continue operation using normal maintenance practices
36

37. Learning Outcomes
• Definition of a “legacy system”
• Risks associated with replacing and risks keeping and
maintaining legacy systems
• Legacy system assessment
• Legacy system architectures
37

38. Background Reading
• Ian Sommerville: Software Engineering 8 ed.
– 2.4 - Legacy Systems
– 21.4 - Legacy System Evolution
– 13.1- Data Processing Systems
– 13.2 - Transaction Processing Systems
38

39. Definition
• A ‘Legacy System’ refers to any computer system
(typically, although not always a mini or mainframe
computer system), which has been in existence for a
long time.
• ‘Legacy Data’ relates to information collected by an
organisation, which is of value to that organisation, but
which has been created or stored by the use of software
and/or hardware that has been rendered outmoded or
obsolete.
39

40. Background to legacy systems
• Software systems are a major investment
• Systems may be long lived to obtain return on
investment (ROI) and thus become “legacy in
nature”
• They may be critical for operation of an organisation
• Legacy systems may have evolved over many years
(customisations)
40

41. Socio Technical Systems
• Legacy Systems have been called “Socio Technical
Systems”
– Systems that include technical systems but also
operational processes and people who use and interact
with the technical system. Socio-technical systems are
governed by organizational policies and rules.
41

42. Socio Technical System
Characteristics
• Emergent properties
– Properties of system as a whole that depend on the system
components and their relationships.
• Non-deterministic
– Same input does not always produce the same output
because system’s behavior is partially dependent on human
operators.
• Complex relationships with organizational objectives
– The extent to which the system supports organizational
objectives does not just depend on the system itself.
42

43. Examples of Emergent Properties
Property Description
Volume The volume of a system (the total space occupied) varies depending on how the
component assemblies are arranged and connected.
Reliability System reliability depends on component reliabilit y but unexpected interactions can
cause new types of failure and therefore affect the reliability of the system.
Security The security of the system (its ability to resist attack) is a complex property that
cannot be easily measured. Attacks may be devised that were not anticipated by the
system designers and so may defeat built-in safeguards.
Repairabilit y This property reflects how easy it is to fix a problem with the system once it has been
discovered. It depends on being able to diagnose the problem, access the components
that are faulty and modify or replace these components.
Usability This property reflects how easy it is to use the system. It depends on the technical
system components, its operators and its operating environment.
43

44. Replacing a Legacy System
• Risks
– Difficulty in obtaining specification of legacy system - to
clarify new system features
– Changes to business processes may be required - existing
BP may have evolved to take account peculiarities of legacy
system
– Identifying business rules embedded in legacy system and
not documented elsewhere
– Risks with developing/purchasing new systems
44

45. Keeping a Legacy System
• Risks associated with maintenance:
– Inconsistencies in how parts of system have been
implemented/changed over the years.
– May use obsolete languages or technologies
– Poor system documentation available
– Years of maintenance may have made system difficult to
understand
– Optimisations for space or speed may make system
difficult to understand
– Use of multiple file structures, data duplication
45

46. Dilemma
• Businesses with multiple legacy systems face a
dilemma
– Continue using Legacy systems - increased maintenance
costs.
– Replace Legacy Systems - costly, risks associated with
changing business systems
• Alternative is to use modern software engineering
techniques to extend lifetime of legacy systems
46

47. Legacy System Assessment
• Strategies for obtaining best ROI
– Scrap Legacy System : system is not making a
contribution to business
– Continue maintaining system: system is stable and
minimal changes being requested
– Transform system to improve maintainability: changes
are degrading quality and changes are still required
– Replace System: modern systems / technology provide a
viable cost effective alternative
47

48. Legacy System Assessment
• Low quality, low business value: Expensive to maintain
with low business value so candidates for scrapping.
• Low quality, high business value: Expensive to maintain
but high business value thus cannot be scrapped.
Candidates for system transformation or replacement.
• High quality, low business value: Inexpensive to maintain
with low business value. Avoid risk of replacement by
maintaining or scrapping.
• High quality, high business value: Must be kept in
operation; high quality so transformation or system
replacement not necessary. Maintain system.
48

49. Business Value Assessment
• Establish business value of legacy system by
consulting:
– End-users: establish level of system usage and
perceived effectiveness.
– Customers: establish level of transparency; flexibility;
responsiveness; errors
– Line managers: Establish benefits to business unit; are
costs justified; criticality of system.
– IT managers: Establish skills availability; level of
resource usage
– Senior managers: Establish the level of the systems
contribution to the business goals
49

50. Business Value Assessment
• System usage: if legacy system usage is low then it
has a low business value.
• Business processes: legacy system may not be
flexible in accommodating changing business
processes, thus has a low business value
• System dependability: if legacy system is unreliable
then it has a low business value
• System outputs: business depends on legacy
system outputs (high business value), if output can
be produced in alternate way (low business value)
50

51. Environmental Assessment
• Supplier stability: Still in existence? Financially stable?
Alternate supplier providing system maintenance?
• Failure rate: Level of failure (reboot v’s random app failure).
Hardware / software failures.
• Age: With age comes obsolescence, increased maintenance
costs
• Performance: Is performance adequate?
• Support requirements: Is a high level of support required? Are
costs high?
• Maintenance costs: Costs of hardware/software maintenance
increase with system age.
• Interoperability: Are there issues interfacing with other
systems 51

52. Application Technical Assessment
• Clarity of source code (understandable?)
• Documentation (consistency, quality)
• Data (data model?, level of duplication)
• Performance (adequate, poor)
• Programming Language (modern/obsolete)
• Level of Configuration Management (complete, partial,
none)
• Test Data ( data & regression test availability)
• Personnel Skills (availability?)
52

53. Legacy System Components
• Legacy systems include software, hardware, data
and business processes.
• Changes to one part of the system inevitably involve
further changes to other components
53

54. Legacy System Components
• System hardware: Possibly obsolete,
• Support software: range of tools, utilities, compilers
etc. Possibly obsolete.
• Application software: Multiple programs developed
at different times. Legacy system may mean the
application software system rather than the entire
system.
• Application data: Data processed by application
system. May be large volume of data accumulated
over time. May be inconsistent and may be duplicated
in different files.
54

55. Legacy System Structures (cont)
• Business processes: Processes used in the
business to achieve some business objective. An
example of a business process in an insurance
company would be issuing an insurance policy.
• Business policies and rules: These are definitions
of how the business should be carried out and
constraints on the business. Use of the legacy
application system may be embedded in these
policies and rules.
55

56. Legacy System Layers
• A legacy system may be viewed as a set of layers
• Each layer depends on and interfaces with the layer
below
• If interfaces are “clean” then “in theory” you should be
able to make changes within a layer without affecting
other layers. Rare in practice!
Business processes
Application software
Support software
Hardware
56

57. Legacy System Application Software
• Typically a legacy system will consist of multiple
application programs.
• This is especially true in main-frame based legacy
systems (.e.g multiple COBOL programs)
• These programs may utilise multiple data
files/sources
57

58. Utilisation of Databases
• Many legacy systems are centralised around a
database system. Advantages include:
– Availability of logical and physical data models.
– Reduce redundancy and data duplication
– Easier to assess the impact of system changes
– Databases also provide transaction-processing**
58

59. Utilisation of Databases (cont)
• Legacy DBMS may be obsolete and incompatible with
other DBMS’s used by a business.
– Hierarchical or Network DBMS are common in mainframe
legacy systems.
– Optimised for performance not simple data management
• Relational DBMS now most effective database
management systems for business applications.
• Costs of changing to a relational data model are very
high.
59

60. Case Study 1:
• Scenario
– A bank needs to handle 1000’s of concurrent updates to
database systems from branch terminals and ATM’s
– A TP monitor job was to serialise requests, buffer
transactions and present them as a serialised list to
update the database and confirms the transaction.
• e.g IBM CICS, Unix Tuxedo
60

61. Case Study 1 (cont)
• TP monitor may only work with particular database
system.
• Migration to new RDBMS may not therefore be
feasible.
IMPLICATION: Technical limitations on possible
migration from legacy system 61

62. Case Study 2
• Some times a sales contract can be dependant on
supporting a legacy system
• Company designs hardware devices to monitor
fixed or movable devices.
• Contract with major customer
– Caveat - requirement to support legacy system
delivering reports via satellite feed
62

63. Case Study Configuration
SMTP
Internet
HTTP
GPRS
Email Server
Asynchronous Message Monitor Server
34 15 00 34 56 08
63

64. Case Study Issues
• How do we access satellite feed?
– Delivery via SMTP as asynchronous email attachment
data packet
• Data format
– How to decode data packet? Code available?
– Any test data to confirm decoding algorithms
• Costs?
• IMPLICATION: Legacy Systems Integration
knowledge can win/lose contracts
64

65. Summary
• Legacy system: an “old system” still providing essential
business services.
– Encompass business processes, application software, support software
and system hardware.
– May be a collection of applications and shared data using files or
obsolete database management system
• Assess business value and quality of a legacy system
hardware/software before decision to replace, transform or
maintain the system.
– Business value of a system is an assessment of the effectiveness of the
system in supporting business goals.
– System Quality is determined by business processes, application
software and hardware and support software.
65

66. A Software Process is
A structured set of activities
required to develop a software
system
66

67. Ad hoc Software Development
• Developing software without planning for each phase,
and without specifying tasks, deliverables, or time
constraints.
• Relies entirely on the skills and experience of the
individual staff for performing the work.
• The software process is constantly changed or
modified as the work progresses.
67

68. Software Process Model
A Software process Model which is
“an abstract representation of a process. It presents a
description of a process from some particular
perspective.”
It provides guidelines to organize how software process
activities should be performed and in what order.
68

69. SW Process Models
• Waterfall model
• Evolutionary models
• Component-based development model
• Iterative Model
69

70. The Waterfall Model
• Oldest model, it’s been around since 1970.
• Called “Linear Sequential Model”.
• Most widely used model for SW engineering
• Documentation is produced at each stage.
70

71. Phases
1. Requirements analysis and definition
2. System and software design
3. Implementation and unit testing
4. Integration and system testing
5. Operation and maintenance
71

72. Waterfall model diagram
72

73. Disadvantages
• Inflexible partitioning of the project into distinct stages
makes it difficult to respond to changing customer
requirements.
• Only appropriate when the requirements are well-
understood and changes will be fairly limited during
the design process.
• The waterfall model is mostly used for large systems
engineering projects.
73

74. Evolutionary Models
74

75. The Exploratory Model
Objective is to work with customers and evolve a
final system from an initial outline specification.
Should start with well-understood requirements
and add new features as proposed by the
customer.
75

76. The Exploratory Model
Concurr ent
activities
Initial
Specification version
Outline Intermedia te
description Development versions
Final
Valida tion version
76

77. The Exploratory Model
• Problems
– Lack of process visibility;
– Systems are often poorly structured;
• Applicability
– For small or medium-size interactive systems;
– For parts of large systems (e.g. the user interface);
– For short-lifetime systems.
77

78. The Prototyping Model
When a customer defines a set of general objectives
for a software but does not identify detailed input,
processing, or output requirement.
It consists of the iterating phases:
1. Requirements gathering
2. Design and build SW prototype
3. Evaluate prototype with customer
4. Refine requirements
78

79. The Prototyping Model
79

80. The Prototyping Model
• Advantages
– Users get a feel for the actual system
– Developers get to build something immediately
– Specifications can be developed incrementally
• Disadvantages
– The developer may make implementation compromises in
order to get a prototype working quickly.
– The process in not visible (few documents that reflect every
version of the system)
– Systems poorly structured
80

81. Component Based Software
Engineering (CBSE)
• Based on systematic reuse where systems are
integrated from existing components.
• Process stages
– Component analysis;
– Requirements modification;
– System design with reuse;
– Development and integration.
• This approach is becoming increasingly used as
component standards have emerged.
81

82. Component Based Software
Engineering (CBSE)
Requirements Component Requirements System design
specification analy sis modification with reuse
Development Sy stem
and integ ration validation
82

83. Component Based Software
Engineering (CBSE)
• Advantages:
– Reduce amount of software to be developed
– Reduce costs and risks
– Faster delivery
• Disadvantages:
– Requirements compromises, system does not meet real
needs of users
– Limited features
83

84. Iterative Models
84

85. The Incremental Model
Rather than deliver the system as a single delivery, the
development and delivery is broken down into
increments with each increment delivering part of the
required functionality.
User requirements are prioritised and the highest priority
requirements are included in early increments.
Once the development of an increment is started, the
requirements are frozen though requirements for later
increments can continue to evolve.
85

86. The Incremental Model
Define outline Assign requirements Design sy stem
requirements to increments architectur e
Develop sy stem Valida te Integ rate Validate
increment increment increment sy stem
Final
sy stem
Sy stem incomplete
86

87. The Incremental Model
Advantages:
• Customer value can be delivered with each increment so
system functionality is available earlier.
• Early increments act as a prototype to help elicit
requirements for later increments.
• Lower risk of overall project failure.
• The highest priority system services tend to receive the
most testing.
87

88. The Incremental Model
Disadvantages:
• Increments should be relatively small (20,000 lines of
code)
• Can be difficult to map the customer’s requirements
onto increments of the right size
• Hard to identify common functions
88

89. The Spiral Model
• Defined by Barry Boehm in his 1988 article A Spiral
Model of Software Development and Enhancement.
• Process is represented as a spiral rather than as a
sequence of activities with backtracking.
• Each loop in the spiral represents a phase in the
process.
• Suitable for large, expensive and complicated projects
89

90. The Spiral Model
Deter mine objecti ves,
Evalua te alterna tives,
alterna tives and
identify, resolv e risks
constr aints Risk
anal ysis
Risk
anal ysis
Risk
Oper a-
anal ysis
Pr ototype 3 tional
Prototype 2 protoype
Risk
REVIEW anal ysis Proto-
type 1
Requir ements plan Simula tions , models , benchmar ks
Life-cy cle plan Concept of
Oper a tion S/W
requir ements Product
design Detailed
Requir ement design
De velopment
plan valida tion Code
Unit test
Integ ra tion Design
V&V Integ ra tion
and test plan
Plan ne xt phase test
Acceptance 90
Service test De velop , verify
ne xt-le vel pr oduct

91. The Spiral Model
• Objective setting
– Specific objectives for the phase are identified.
• Risk assessment and reduction
– Risks are assessed and activities put in place to reduce the key risks.
• Development and validation
– A development model for the system is chosen which can be any of
the generic models.
• Planning
– The project is reviewed and the next phase of the spiral is planned.
91

92. The Spiral Model
• Risk driven process model
– Different risk patterns can lead to choosing different process
models
• What is a risk?
– Situations or possible events that may cause a project to fail to
meet its goal.
– Example risks:
• Experienced staff leave the project
• Hardware which is essential for the system will not be delivered on
schedule
– (more about risks in Chapter 3)
92

93. The Spiral Model
Advantages:
• Risks are explicitly assessed and resolved throughout
the process.
• Software engineers can start working on the project
earlier rather than wading through a lengthy early
design process.
93

94. The Spiral Model
Disadvantages:
• Requires highly skilled people in risk analysis and
planning
• Requires more time, and is more expensive
• Estimates of budget and time are harder to judge at
the beginning of the project since the requirements
evolve through the process
94